Методологія Agile. Матір драконів або всіх гнучких методологій

• Пріоритет людей і спілкування над інструментами та процесами;
• Пріоритет працюючого продукту над повною документацією;
• Пріоритет співпраці із замовниками над затвердженням контракту;
• Пріоритет готовності змінюватися над дотриманням спочатку створеного плану. ​​​​​​​​​​​​​

1. Виберіть власника продукту — він знає про мету проєкту та очікуваний результат. 
2. Зберіть команду — до 10 осіб із необхідними для створення працездатного продукту навичками.
3. Знайдіть скрам-майстра — він стежить за перебігом проєкту, допомагає проєктній команді боротися з труднощами.
4. Складіть беклог продукту — на Agile-дошці розставте пріоритети за кожною вимогою до продукту. У цьому велику роль відіграє власник продукту, який збирає побажання до продукту для оцінки командою беклогу. 
5. Заплануйте спринти (ітерації) — відрізки часу на виконання певної низки завдань. 
6. Організовуйте щоденні п’ятнадцятихвилинні «міт-апи» — ставте по 3 запитання кожному з команди: що робив учора, що буде сьогодні, що заважає виконати завдання.
7. Робіть огляди робочих частин продукту — із залученням до перегляду та обговорення стейкхолдерів.
8. Проводьте ретроспективу — обговорення проблеми і пошук рішення після кожного спринту. Отриманий план зміни впроваджуєте на наступному спринті.​​​

• Product Backlog — список вимог за проєктом
• Sprint Backlog — список вимог, які потрібно виконати в найближчий спринт
• Sprint Goal — мета спринту
• Sprint Burndown Chart — діаграма, яка оновлюється в міру завершення завдань. За нею легко зрозуміти динаміку і рівень просування команди в проєкті​​​​​​​​​​​​

1. кодування — згідно з єдиними в команді стандартами оформлення;
2. тестування — тести пишуться самими програмістами до написання коду, який будуть тестувати;
3. планування — як фінального білда, так і окремих ітерацій. Останнє відбувається в середньому раз на два тижні. 
4. слухання — як розробників, так і клієнта, під час якого зникають незрозумілості, визначаються вимоги та цінності.​​​​​​​​​​​​

1. швидка доставка робочого коду — розвиток ідеї ітеративної моделі розробки Agile.
2. досконалість через рефлексію — нова версія ПЗ поліпшується на основі даних про попередню.
3. «осмотична» взаємодія — нововведення Алістера, метафора комунікації та обміну інформацією між розробниками ПЗ в одній кімнаті. ​​​​​​​

• часті випуски робочих версій продукту
• автономність розробників у плані прийняття рішень
• тестування протягом усього робочого циклу. ​​​​​

1. цикл функціональної моделі — створення аналітичної документації та прототипів.
2. цикл проєктування і конструювання — приведення системи в робочий стан.
3. цикл реалізації — розгортання системи. ​​​​​​

Feature Driven Development (FDD)​​​​​​​​​​​​​​

• більше уваги попередньому моделюванню
• підвищена (порівняно з Agile) важливість побудови звітності та графіків
• націлене на корпоративну розробку.​​​​​​​​​​​​

1. Створення загальної моделі — бачення проєкту на основі попередніх даних.
2. Розробка списку властивостей — аналог product backlog у методиці скрам. 
3. Планування за властивостями — оцінка складності властивостей кожним членом команди.
4. За кожною властивістю — технічний дизайн і реалізація — фінальна стадія, по закінченню якої властивість йде в продукт і цикл повторюється.​​​​​​​​

1. позбавлення від втрат — усе, що не додає цінності продукту для кінцевого споживача.
2. постійне навчання — безперервний розвиток команди збільшує можливості ефективного виконання завдань.
3. прийняття рішення так пізно, як тільки можна — пріоритет не спонтанним рішенням, а продуманим, розробленим на основі отриманих знань.
4. швидка доставка — по суті основа ітеративної моделі.
5. посилення команди — один із принципів «Маніфесту…» свідчить, що люди і взаємодія важливіші за процеси та інструменти. Проєктна команда — основа успішного завершення завдань.
6. цілісність і якість — потрібно від самого початку робити якісний продукт, щоб не витрачати час і ресурси на подальше тестування і позбавлення від багів.
7. бачення цілісної картини — розбиття проєкту на окремі частини неможливе без розуміння поточного статусу розроблення, цілей, концепції та стратегії ПЗ, що розробляється.​​​​​​​​​​​​​​​

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

• Ваша команда знає, що робить;
• Простота понад усе;
• Відповідність принципам гнучкої методології розробки;
• Сфокусованість на цінних для проєкту активностях;
• Незалежність у виборі інструментів;
• Індивідуальне налаштування AUP під потреби конкретного проєкту.​​​​​​​​

1. Дані — основа створення будь-якого застосунку.
2. Проблеми з проєктом — їх можна виявити тільки при чіткому розумінні мети та концепції проєкту.
3. Робочі групи — крім безпосередньої команди розробників є enterprise groups, які підтримують інші робочі групи.
4. Унікальність — немає ідеальної методики, під кожен проєкт потрібно комбінувати інструменти з різних методологій.
5. Робота в команді — спільна робота набагато ефективніша, ніж поодинці.
6. «Солодка пляма» — пошук оптимального вирішення проблеми («солодкої плями»), уникаючи крайнощів.​​​​​​​​​

• сценарій використання — опис поведінки системи.
• ітераційна розробка — створення робочих шматків коду короткими циклами в кілька тижнів.
• командні практики — спрямовані на згуртування команди та підвищення її ефективності.
• процесуальні практики — наприклад, «Думай глобально, починай з малого» або «Залучайте стейкхолдерів до бізнес-процесів». ​​​​​​​​​​​​

• можливостей
• опцій і налаштувань
• структури компанії
• зустрічей
• обіцянок.​​​​​​​​​​​​​​

• вимірювання швидкості роботи команди;
• проведення щоденних зустрічей і ретроспектив по завершенню ітерацій;
• концепція мікрокроків і раннього тестування з використанням чеклистів;
• методика гнучкого моделювання (AMDD). ​​​​​​​​​​​​​

1. узгодження інтересів і досягнення спільного бачення під час спільної роботи
2. безперервне вдосконалення через постійний зворотний зв’язок
3. фокусування на архітектурі застосунку на ранніх стадіях для мінімізації ризиків
4. максимізація цінності для кінцевого споживача. ​​​​​

1. Продуктивність — сюди відносяться Velocity і WIP. Перша підійде не для всіх проєктів, оскільки йде вимірюється кількість виконаних завдань за ітерацію, а вони нерівнозначні. Метрика Work-in-Progress визначає ліміт завдань на різних стадіях: і чим він вищий, тим гірше;
2. Прогнозування — метрика capacity: визначення кількості ідеальних годин, доступних у наступному спринті. Відповідно, можна зрозуміти, скільки часу є на роботу, наскільки ефективне виконання завдань і як спланувати кількість завдань для спринту;
3. Якість — наприклад, індекс стабільності вимог, який розраховується за формулою = (Загальна кількість оригінальних бізнес-вимог + Кількість вимог, які змінилися до цього часу + Кількість доданих вимог + Кількість прибраних вимог) / (загальна кількість оригінальних вимог). За допомогою метрики визначається кількість часу, витраченого на перероблення завдань;
4. Цінності — у кожному випадку прораховується індивідуально, залежно від формату проєкту. Наприклад, стартап AirBnb як метрику, що визначає кінцеву цінність продукту для користувачів, обрала кількість завантажених фотографій високої якості. З їхнім збільшенням пропорційно зростала і кількість споживачів.​​​​

1. залучення стейкхолдерів — у команди з’являється більше можливостей зрозуміти бажання клієнта. А рання і часта доставка ПЗ посилює довіру стейкхолдерів до проєктної команди і ще глибше залучає до проєкту.
2. рання і передбачувана доставка — модель розробки через ітерації (короткі проміжки від 1 до 6 тижнів) дає гнучкість, прискорює випуск релізу продукту.
3. фокусування на бізнес-цінності — колаборація з клієнтом забезпечує розуміння командою того, як зробити продукт максимально цінним для споживача.
4. безперервне поліпшення якості — тестування під час кожної ітерації, розподіл фінального білда на окремі шматки робочого коду дають змогу покращувати і справлятися з помилками ПЗ до виходу фінального продукту.​​​

• підвищені вимоги до команди і клієнтів — без тісної взаємодії між проєктною командою і користувачами неможливо домогтися виходу якісного продукту з високою цінністю. А велика кількість інструментів і методів в Agile для впровадження вимагає досвідчену команду.
• не підходить для аутсорсу і проєктів, де учасники взаємодіють один з одним тільки онлайн.
• ризик ніколи не випустити фінальну версію ПЗ — цей мінус, як не дивно, випливає з ітеративної розробки та безперервного вдосконалення продукту — плюсів Agile.
• не працює без чіткого бачення бізнес-цілей проєкту — оскільки Agile-команда орієнтується на стейкхолдерів, то без вироблення цілей і концепції продукту розробка неможлива.​​

Програми​​​​​​