Що ви пропонуєте в перших двох ітераціях Agile?

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

Але на ранніх ітераціях ви можете побудувати основу або основи, на яких буде стояти додаток, щоб це було щось важливе, але не видно користувачам.

Що доставляється клієнту в цих перших ітераціях? Як ви показуєте прогрес у правильному напрямку, коли будуєте код будівельних лісів?

Типово проводити 2-тижневі спринти.

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

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

Можливо, ви не змайструєте кожен предмет ешафот в першому спринті або 2. Можливо, частини можуть почекати і бути додані пізніше.

Можливо, у вашому першому спринті є "Створити веб-сторінку X з фіктивними даними", щоб ви могли отримати щось блискуче, щоб показати своєму клієнту. А потім наступний спринт має "Змінити веб-сторінку X для використання даних із бази даних".

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

Чому? Ну, крім іншого, дизайнери та розробники часто стають жертвою витрачати багато часу на предмети YNNI (вам це ніколи не знадобиться). На жаль, ті рамки, про які ви говорите, часто є великою відповідальністю у цій галузі. Розробники починають будувати все, що має підтримувати рамка, і раптом вам 3 місяці, і ви не маєте для цього нічого ділового значення. Тоді виявляється, що рамки навіть не дуже підтримують те, що їм в кінцевому підсумку потрібно.

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

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

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

Що доставляється клієнту в цих перших ітераціях?

Що має найбільшу цінність для користувача. Наприклад, якщо додатки мають складні бізнес-правила, перша ітерація (и) міститиме лише ті правила бізнесу, закодовані у вигляді коду. Клієнт повинен бути задоволений, якщо у вас є код для цих правил бізнесу. (Проблема фактично переконати клієнта прийняти таку річ - це зовсім інша справа.) Наприклад, ви можете показати бізнес-експертам клієнта свій тест / прийом тестів, який виражає те, що повинен робити домен, і який код передає йому зелений результат. Або ще краще, змусіть бізнес-експертів допомогти створити ці тести.

Є також питання про

ви можете побудувати рамку або основи

Я вважаю, що набагато важливіше, ніж те, що насправді доставлено. В Evolutionary Design є велика річ , яка говорить про те, що ви повинні створювати архітектуру з часом, а не намагатися створити її на початку. Що стосується фундаменту, то це зазвичай означає якусь базу даних або фреймворк інтерфейсу користувача. У такому випадку існує ідея " Гарна архітектура - це та, яка дозволяє відкласти важливі рішення ". І вибір бази даних або інтерфейсу є важливим рішенням. Наприклад, у вас може бути добре просто зберігання даних у пам'яті, замість того, щоб спробувати використовувати БД з першої ітерації.

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

• Налаштуйте процедуру доставки (завжди одна з найскладніших частин imho) (знайдіть середовища, сервери на місці, оновіть безпеку для цього середовища). Оскільки ми будемо часто виступати, важливо досягти цього права якнайшвидше.
• Дайте користувачам перші уявлення про те, як буде виглядати програма. Це допомагає користувачам та розробникам зрозуміти, що вони насправді хочуть і потребують.
• Майте базове уявлення про те, як буде виглядати архітектура програми (програма повинна охоплювати основні 'шари' або компоненти програми).

Але на ранніх ітераціях ви можете побудувати основу або основи, на яких буде стояти додаток, щоб це було щось важливе, але не видно користувачам.

Це неправильно, оскільки вам не потрібно будувати рамки, які ви можете використовувати в майбутньому. Ідея полягає в тому, щоб будувати лише те, що потрібно (див. Також YAGNI ).

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

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

Що доставляється клієнту в цих перших ітераціях? Як ви показуєте прогрес у правильному напрямку, коли будуєте код будівельних лісів?

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

Якщо у вас запитання "як вибрати те, що переходить в ітерацію X?", Погляньте на ці відеопередачі (відео для ітерації 0 A та частини B).

Ви можете доставити майже все, що завгодно. Ідея побудови інфраструктури просто неправильна / не спритна / нестійка.

Наприклад: створення повністю функціональної програми Hello World може бути побудовано за години. Вивести сервер (навіть тимчасово) у хмару або як VM можна за години.

Цього достатньо, щоб почати розвиватися . Потім, якщо вам потрібен інтерфейс користувача, ви можете додати історію CI, якщо вам потрібен фізичний сервер, обов'язково додайте історію для цього.

Але почніть доставку з першого дня і ніколи не зупиняйтеся!

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

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

Частина підходу Agile полягає в тому, щоб клієнт був закритий, тому документація не потрібна, оскільки все, що вам потрібно зробити, - це забрати телефон / надіслати електронну пошту, і це очікується. Очікування клієнтів повинні бути встановлені відповідним чином, а будь-яка завершена робота повинна бути дуже короткою та НЕОБХІДНОЮ . Ні позолочення, ні "Вам це може знадобитися" тощо. Побудуйте те, що вам потрібно в A, щоб перейти на B.

Залежно від того, як ви атакуєте проект, ви можете створити необхідний фундамент лише для того, щоб виконати певний модуль, тож під час зустрічі зі планування спринту ви могли б викласти плани поточного спринту на основі пріоритетів, визначених Замовник, залежно від того, що потрібно для цього спринту, можуть бути деякі основоположні вимоги, тому ось що переходить у спринт 1. Після завершення 1-го спринту та побудови A, а потім планування завершення B.

Якщо ви домовилися про часовий графік із замовником, поки ви збираєтесь виконувати цю угоду, клієнту, ймовірно, не буде байдуже, що ви робите 1-го чи 2-го. Ви завжди можете показати їм результати тестування одиниці, але якщо ви скажете, що після спринту 2 (або 3) вам доведеться щось побачити, і ви поставите його, це встановить сильний пріоритет. Очікується, що клієнти будуть розумними стільки, скільки розробники, і обидва працюють над досягненням однієї мети. Завершений проект, який відповідає потребам замовника та працює як очікується. Тож хвилюється, що після спринту 1 нічого не бачити - це суперечливий момент, оскільки замовник просто хоче переконатися, що після спринту 20 проект буде виконано (-іш).