Тренінг

Управління вимогами в Agile проєктах

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

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

У випадку легковагових підходів рівень вимог дуже загальний і недеталізований – цілком обґрунтовано, до речі. Управління вимогами наражене на дуже сильні ризики, управління якими досить витратне, але, як показує досвід важковагових підходів, не завжди ефективне. Тим паче що коренева для легковагових підходів концепція перевірки ідей продукту через його виробництво (A/B testing або split testing) спонукає розробників оперувати одразу на рівні сценаріїв поведінки, що створює перспективу втрати супроводжуваності отриманого коду та здорожчання його змін через деградацію внаслідок великої кількості дрібних і великих помилок, компромісних і тупикових рішень, отриманих методом спроб і помилок. Відносно молоді продукти втрачають темп розвитку й потребують серйозних переробок.

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

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

Ви отримаєте квінтесенцію підходів, які еволюціонували протягом останніх 5 років. Почнемо, звісно, з теорії управління вимогами, окремо зупиняючись на економічному обґрунтуванні тих чи інших практик в умовах різних продуктів і команд. Але основне завдання – практичне застосування. Ми візьмемо реальні завдання й зберемо, проаналізуємо та протестуємо вимоги, попутно керуючи ризиками, а у фіналі подивимося, наскільки простішим стає перехід до сценаріїв поведінки та архітектури. Також обговоримо вплив представлених практик на подальше життя проєкту. Обов’язково обговоримо недоліки й можливі шляхи розвитку представлених практик.

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

Цільова аудиторія
розробники, тимліди, менеджери
Вартість
200 $за учасника
Дата та час
8 годин / 1 день

Замовити для компанії

Детальна програма

  • Знайомство, організаційні питання
  • Синхронізація цілей та очікувань
  • “Хвилина слави” кожного учасника (за бажанням) – збираємо ваші проблеми в роботі з вимогами
  • Проблематика вимог
  • Теорія управління вимогами:
    • вимога
    • критерії якості вимог
    • управління вимогами
    • ризики управління вимогами
    • економіка управління вимогами
    • вплив на ризики продукту
  • Практики аналізу вимог
  • Практики управління змінами вимог
  • Практики управління ризиками вимог
  • Вправляємося в аналізі та управлінні вимогами
  • Вправляємося в аналізі та управлінні ризиками вимог
  • Аналіз застосовності та успішності випробуваних практик до проблем учасників тренінгу, зібраних під час “хвилини слави”
  • Відповіді на запитання
  • Література, “домашні завдання”