Як ви ведете нефункціональну роботу з Scrum у вбудованих системах?

У мене є два питання із Scrum у вбудованих системах. По-перше, необхідно виконати багато завдань, особливо на ранніх етапах, які неможливо продемонструвати. Ми почали з плати розробки, без ОС, без дисплея, без послідовного зв’язку тощо. У нас не було екрану для шести спринтів.

Першими чотирма спринтами були:

• Початок роботи RTOS та роботи
• Створення завдань написання мережевих та послідовних драйверів
• Написання процедур переривання для кнопок, зв’язку тощо.
• Написання основних класів та методів бази даних
• Написання послідовного меню налагодження

Більшість із цих завдань не дуже підходять для розповідей користувачів. Насправді єдиним інтерфейсом у всій системі було серійне меню налагодження, вбудоване в спринті 3, тому в кінці спринтів не було що демонструвати. Навіть серійне меню призначене для внутрішнього використання, а не для кінцевого споживача. Тим не менш, я все ще хочу відстежувати та керувати цією розробкою через Scrum.

Ми закінчили писати фрази "Історії користувачів" на кшталт "Як розробник ...", якими я не задоволений, але у використанні цільового процесу (www.targetprocess.com) немає поняття про затримку, яке є завдання чи завдання.

По-друге, як ви обробляєте випуски та тестування? Для нас це справжній біль, тому що у тестувальників немає апаратних налагоджувальних приладів, тому для тестування нам потрібно створити флеш-версії коду та записати їх на дошках розробки. Тестери технічно не такі гострі, як розробники, і часто потребують великої підтримки в роботі над початковими етапами (скидання плати, підключення послідовного зв'язку тощо) або навіть у розумінні результатів.

Нарешті, що стосується визначення зробленого, спринт не може бути завершеним, поки всі історії не будуть завершені. Усі історії не завершені, доки їх не перевірять тестери. Немає способу уникнути "пограбування" часу розробника, щоб віддати тестерам. Іншими словами, якщо для останніх трьох історій користувача у спринті знадобиться п’ять днів для перевірки, вони повинні бути закодовані та одиничні випробування за п’ять днів до закінчення спринту. Що повинен робити розробник? Перестати працювати?

Я пильную, але це справжня проблема, намагаючись відповідати правилам. Тепер я впорядковую згинання правил, але проблема в мене полягає в тому, що він розкручує всі мої показники обтяження, якщо я не можу відзначити зроблені речі, поки вони не будуть перевірені.

Я хотів би почути, як інші вирішили ці ситуації.

Ви використовуєте методологію для продукту, який не сумісний IMHO.

У тому, як більшість людей визначають спритність, вся робота може бути обговорена на основі змін пріоритетів, які можуть бути повторно замовлені або замінені.

Те, як більшість людей визначає водоспад, полягає в тому, що роботи викладаються послідовно достроково, ніж значні зусилля архітектури на початку.

Завдання, які ви перераховуєте вище, здаються мені дуже водоспадними. Вони повинні бути в певному порядку, і вони не підлягають обороту.

Я не кажу, що ви повинні дотримуватися погляду кого-небудь на будь-який процес, але, принаймні, для цих завдань ви, здається, знаходитесь в не спритному проекті для мене. Намагатись пограти, що це спритний процес, у кращому випадку буде неохайним.

Якщо решта проекту добре підходить для гнучкості, я б не переймався надто поганим підходом до початкових налаштувань, але той факт, що ви згадуєте про RTOS та дошки розвитку, змушує мене підозрювати, що все це буде краще в чомусь більшому як водоспад (довга послідовність нерухомих залежностей).

Гаразд, тому я нічого не знаю про побудову вбудованих систем, але з того, що я бачу, немає нічого, що зробило б Scrum непридатним для такої розробки. Легко зациклюватися на тому, що ти не можеш працювати з користувачем, тому важко писати "історії користувачів" із користуванням користувачами. За винятком того, що історії користувачів насправді не є частиною Scrum - їх часто використовують із Scrum - але насправді лише як інструмент.

Що є частиною Scrum - це ідея забезпечити повноцінні функції, які повністю перевірені та потенційно реалізовані у прямому середовищі кожного спринту. Коли ви починаєте з нуля в перший день будь-якого проекту, фактична цінність будь-якого функціоналу, який ви можете забезпечити в Sprint 1, досить мала. Це тому, що кожна крихітна річ потребує тонн і тонн інфраструктури, побудованої для роботи. Але справа в тому, що ви будуєте лише достатню інфраструктуру для роботи кожної функції. А потім ви створюєте це, додаючи більше функцій.

Ідея полягає в тому, що ви спеціально НЕ витрачаєте місяці і місяці на будівництво інфраструктури, яка не може бути виявлена ​​поза системою. Чому? Тому що, поки ви не будуєте речі, які насправді роблять, ви не знаєте, якою саме інфраструктурою має бути. Це речі, які ви дізнаєтесь, будуючи фактичні особливості системи. Якщо ви будуєте інфраструктуру на початку, то ви будуєте її, коли ви знаєте щонайменше про систему.

Якщо ви готові писати історії користувачів, пам’ятайте, що користувачам не потрібно бути людьми. Отже, ви пишете такі матеріали, як "Як обробник переривань CMOS, мені потрібно вміти виявляти статус прапора модуляції стека Bingle, коли флюксотроний компресор сигналізує про пасивний байпасний байпас". Абсолютно не пишіть історії користувачів "Як розробник ...".

Ви використовуєте Scrum в дуже специфічній області і ви порушуєте передбачуваний процес на кожному кроці. Мабуть, ваше запитання має бути: чи існує інша гнучка методологія, яка краще відповідає моєму середовищу? Просто, дуже важко допомогти вам зробити Scrum краще, якщо ваше оточення цього не дозволяє. Проблеми, які я бачу у вашому описі:

• Немає демонстративних завдань, які можна розглядати як інфраструктурні завдання. Якщо вам потрібно кілька спринтів, щоб зробити щось, що не вважається діловою цінністю, то ваші історії користувачів, ймовірно, погано визначені. Якщо вам потрібно створити інструмент або що-небудь інше, щоб мати змогу доставити ділову цінність, то продукт можна розділити на дві частини / випуски - створення інструменту та побудова ділової цінності. У такому випадку ваші користувацькі історії "Як розробник ..." будуть повністю дійсними, оскільки для розробників створено інструмент.

  Проблема тут полягає в тому, як це зв’язати із замовником, оскільки його / її участь у першому випуску дорівнює нулю. Якщо для клієнтів немає жодної цінності бізнесу, як вони можуть брати участь? Як власник продукту може визначити пріоритет бізнесу?

  Я думаю, що головна проблема тут полягає в тому, що це не те, що підходить Scrum. Scrum спочатку намагається надати найважливіші особливості бізнесу, але для отримання першого вам потрібно два місяці. Scrum і цілий спритний охоплює зміни - що станеться, якщо після надання перших функцій клієнту потрібна певна зміна, яка повертається до всіх ваших початкових спринтів?

• Тестування. Ще одна невдача, оскільки команда в Scrum розглядається як група перехресних функціональних членів. Це означає, що всі займаються розробкою та тестуванням, і через це не існує ситуацій, описаних у вашій кінцевій точці (або хоча б не п’ять днів). Це не означає, що не може бути окремого контролю якості, щоб зробити кілька складніших і складніших тестів, але команда повинна надати вже перевірену / перевірену функцію. У вашому випадку справді виглядає, що Scrum - це не те, що вам потрібно. Вам потрібна окрема обробка та тестування та передача функцій між ними.