Чи має сенс Scrum при впровадженні нового бекенда компілятора?

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

Повторне написання бекенда - це значна кількість роботи. Я не бачу способу розбити це на розсудливі історії, не порушуючи критеріїв INVEST.

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

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

Я планую спробувати слідувати за Scrum, але чи я просто переглядаю рухи?

Чи є рекомендовані практики для такого роду проектів?

Майте на увазі, що головна причина, що були створені Agile процеси, полягала в тому, щоб впоратися зі зміною вимог. Якщо вимоги встановлені в камені (справді фіксовані вимоги зустрічаються рідко, але я візьму вас на слово тут!), То деякі найкращі практики поводження зі зміною вимог - наприклад, переговорні історії - стають дещо неактуальними. Однак, після виконання робочого процесу в Scrum все ще є велика потенційна цінність щодо планування та надання результатів. Навіть якщо ваші товари не будуть представляти собою повністю корисний продукт протягом певного часу, все одно можна сказати, що зможете продемонструвати прогрес своєму клієнту (та команді!).

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

Перш за все, не зациклюйтеся на спробі змусити кожну ситуацію вписатись у дуже узагальнений підхід. Agile повинен працювати для вас, а не навпаки!

Звичайно, Scrum корисний. Це методологія, яка робить для вас дві речі:

1. Це дозволяє вашому проекту адаптуватися до змін і
2. Це дозволяє відстежувати прогрес і отримувати уявлення про те, коли він буде закінчений

Отже, є деяке значення в його використанні.

Я думаю, що деякі ваші передумови невірні, і саме там ви втрачаєтесь.

Я не бачу, як кожна історія може бути переговорною - всі вони потрібні робочому компілятору

Це не правда. Ви можете підтримувати підмножину мови та все ще мати компілятор, який працює за певних умов. Безумовно, менш цінний, ніж повний компілятор, але все-таки цінний.

Крім того, ви неправильно розумієте, що означає "договірні": це не обов'язково означає "необов'язково", і немає вимоги, щоб історії були необов'язковими в INVEST. Історія є цінною ціллю, і переговори про те, як досягти цієї мети. Безумовно, це буде більше, ніж спосіб впровадження кожної мовної функції. Там потрібні переговори.

Усі історії мають однаковий пріоритет, і не має значення, в якому порядку я їх доставляю.

Це невірно, як ви кажете нижче, що деякі історії не мають "бути обов'язковими", тому деякі, мабуть, є менш цінними. Але навіть у категорії "must have": деякі мовні особливості набагато основніші, ніж інші, і помірно.

Один із способів виміряти це - "скільки ще рядків коду ми можемо скласти на існуючій кодовій базі" або "скільки ще тестів пройде", якщо у вас є попередньо визначений набір тестів.

Є й інші варіанти. Якщо ви збирали мову, схожу на С, строго кажучи, вам потрібні лише контур ifі gotoцикл, щоб мати (ледь) функціональну мову, і ви можете реалізувати while, forіrepeat як макроси. Якщо припустити, що досить просто написати попередній компілятор, ви можете придбати дешеве рішення про зупинку (ей, ми ведемо переговори ?:-)

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

На закінчення, щоб відповісти на ваше запитання прямо: чи потрібні вам гнучкі процеси, коли ваші вимоги незмінні? Точно ні! Вони придатні для використання? Напевно, так! Вони варті вашого часу? Напевно, ні - але чи не змінюються ваші вимоги? У моєму минулому досвіді "незмінні вимоги" => "власник лінивого продукту" - не правило, але варто пам’ятати.

TL; DR

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

Scrum - неправильний молот тут (не будь цвяхом)

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

Крім того, коли ви говорите:

Усі історії мають однаковий пріоритет, і не має значення, в якому порядку я їх доставляю. Мені потрібно робити їх усі.

ви маєте на увазі пару речей:

1. Проект має нульове значення, якщо всі історії не завершені на 100%.
2. Історії не залежать одна від одної.

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

Пропоновані альтернативи

Будь-який проект розвитку може потенційно отримати користь від спритних практик. Зокрема, у вашому конкретному випадку я рекомендую:

1. Переконайтесь, що всі ваші історії мають "визначення зробленого", яке включає тестування одиниці та приймання.
2. Інтегруйте та рефактор часто; не залишайте перед собою величезну інтеграційну задачу в кінці проекту.

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

Я розумію ваші занепокоєння, але я вважаю, що для вас все ще є користь у використанні scrum.

Справді, історії користувачів набагато більш виправлені, ніж у програмі, що стоїть перед споживачами. Тож цей аспект scrum забезпечить меншу цінність.

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

Я думаю, ви також отримали б користь від знання своєї швидкості . Після декількох спринтів, ви можете бачити, скільки балів зусиль ваша команда закінчує кожен спринт. Це дає вам об'єктивний показник, який допоможе визначити дату вашої доставки.

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

(Зверніть увагу, я ніколи не робив розбирань над проектом компілятора; прийміть поради з зерном солі.)

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

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