Планування проектів

у реальному світі:

чому Agile?

Що розповім:

• Хто я (1)
• Невеличкий приклад із історії (2)
• Різноманіття IT-проектів (1)
• Фактори розробки ПО (7)
• В чому проблема waterfall (6)
• Проблеми у прикладі ІПЗ (6)
• А навіщо вам це? (2)
• Як в теорії працює Agile? (12)
• Як на практиці працюють компанії? (3)
• Як на практиці працює Agile? (27)
• Підсумки (4)

• Розробник, ~9 років стажу, 6 різних компаній.
• ~2 роки із них — техлід + трохи продуктового дизайну
• Ніколи не займав позицію проектного менеджера*

*але є друг

продакт-лід

Життя буремне

Oxford English Dictionary

Oxford English Dictionary

Різноманіття IT-проектів

• Desktop, mobile, web
• Короткострокові проекти з чітким ТЗ
• Проекти без ТЗ та без можливості економічного обгрунтування
• Різні типи продуктів за користувачами: внутрішні, b2b, b2c
• Кількість замовників може бути більше одного. Користувачі належать до різних груп. 
• Продукти проходять різні фази: ріст, стабільний розвиток, підтримка

Фактори розробки ПО

або «чому все погано?»

Унікальність проектів

Унікальність проектів

• продуктів одного типу — ~1000 за 10 років
• є декілька замовників? — є один продукт
• такий продукт вже є? — а навіщо новий?

Унікальність проектів

Фізичні речі

= чертеж

+ виробництво

+ експлуатація

ПО

= чертеж

+ експлуатація

чертеж=виробництво

Унікальність технологій

1950 (70 років назад)

• MS SQL — 1989 (33 роки назад)
• C# — 2000 (22 роки назад)
• MongoDB — 2009 (13 років назад)
• Elastic — 2010 (12 років назад)
• Typescript — 2012 (10 років назад)
• React — 2013 (9 років назад)

Унікальність технологій

ніхто не пише сортування в кожному новому бізнес-проекті

алгоритми виносять в бібліотеки і далі перевикористовуються

Унікальність алгоритмів

Результат

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

по технологіям трохи краще, але все одно

Waterfall

waterfail

Waterfall

200 000$ — 3 000 000$

не закриває потреби реальних користувачів

Waterfall

описані вимоги не можливо реалізувати

Waterfall

помилки на початку розробки вбивають проект

Waterfall

не можна зробити ТЗ, бо немає даних про користувачів та їх потреби

Waterfall

естімейт більше ніж чоловікорік скоріше фантастика

Waterfall

Analysis

Development

Проблеми у прикладі ІПЗ

WTF?

Працює для

min=2, mostLikely=10, max=18

Погано працює для

min=2, mostLikely=10, max=26

https://erikbern.com/2019/04/15/why-software-projects-take-longer-than-you-think-a-statistical-model.html

formulas use mean

developers use median

The mean time to complete a task we know nothing about is actually infinite.

А навіщо?

• Дедлайни
• Фіксований бюджет
• … а що ще?

А навіщо?

agile в теорії

від початку роботи над вимогами

до моменту користування замовником

мусить бути якомога менше часу

визнання, що планування працює не так добре, як здається

= трохи waterfall

+ але short cycled iterations (1/2/3/4 weeks)

– focus on formal stuff

+ focus on business

+ strategic planning

± деякі особливості

Scrum

• Product Owner
• Scrum Master
• Development Team
• Stake holders

Scrum

Scrum

Idea: як продавець, я хочу продавати бандли зі знижкою

Acceptance criteria:

1. Продавець може увійти на нову сторінку «Бандли»

1.1 …

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

2.1 …

Реалізація

Фідбек

Scrum Meetings

• Sprint Planning
• Daily Standup
• Sprint Review (demo)
• Sprint Retrospective

story points (попугаи)

замість годин

і це навіть фіксується в контрактах

Agile (Scrum)

agile

+ prerequisites

Kanban

Теорія

Практика

Практика

• Різні проекти — різні методології
• Методологій 1-в-1 ніхто не дотримується
• Один продукт — багато проектів
• Один продукт — суміш методологій
• Короткострокові проекти — waterfall-like
• Чіткі дедлайни — waterfall-like
• Продукти у фазі росту — agile
• Клієнти приходять коли їм зручно, а не до планування

agile на практиці

• не висококваліфіковані розробники
• іноді це навіть схоже на waterfall з деплоєм час від часу
• часто не використовують story points
• іноді немає стратегічного планування зовсім
• кількість розробників більше, ніж рекомендовано agile (large-scale scrum)
• часто демо просто так, щоб перевірити, що працює, а не щоб зібрати фідбек
• деякі відмінності у процесі

agile на практиці

фактори стратегічного планування

1. Фінансове планування на рік
2. Світ живе по календарю
3. Цілі інвесторів та потреби клієнтів
4. Зрілість product vision

agile на практиці

фактори стратегічного планування

гроші від інвестора

→ цілі по метрикам від інвестора

→ пошук груп кліентів, яким можна продати

→ пошук конкретних кліентів

→ аналіз недостаючих можливостей 

agile на практиці

фактори стратегічного планування

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

* теж саме, якщо фірма має запас кешу

agile на практиці

фактори стратегічного планування

але, якщо ринок не зрілий, то продуктове бачення неможливо сформувати

→ треба слухати кліентів

agile на практиці

фактори стратегічного планування

agile на практиці

роадмап

1. Sales обожнюють роадмапи та таймлайни
2. Продакти та ліди — ні
3. Розробники обожнюють передбачуванність

Роадмап на рік без таймлайну

agile на практиці

роадмап

Лише 50%-70%* роботи заплановано в роадмапі

*включаючи роботи, які пов'язані з запланованими

agile на практиці

роадмап

часто

нові фічі > заплановані фічі

*чомусь нові клієнти приходять не до планування роадмапу, а після

agile на практиці

особливості планування

• 8-годинний робочий день насправді 6 годинний (-25%)
• буфер 20% на багфікс та технічний долг

agile на практиці

особливості планування

-25%

-50%

-20%

= 30%

*3.3x

agile на практиці

особливості планування

буфер на дедлайни (10%-15%)

тому що затримки не лише із-за того, що чиста робота довше йде

agile на практиці

пріорітети

хто формує:

в теорії один єдиний product owner

на практиці одного на всіх не вистачає 

agile на практиці

пріорітети

збір інформації:

ceo, support, sales, developers

agile на практиці

пріорітети

• Revenue / Cost Saving / Risk Reduction ($, *)
• Cost of doing (hours)
• Opportunity cost (lost revenue / cs / rr)
• Cost of not doing ($, -client)
• Forcing conditions (deadlines, contracts)
• Ability to execute (is that possible?)

+ Confidence Level

*Scale for money: 1-10, not $

agile на практиці

пріорітети

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

agile на практиці

репріорітезація

• коли є зміни
• і час від часу (рекомендовано раз в ітерацію)

agile на практиці

великі фічі

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

agile на практиці

взаємопов'язані фічі

є дві фічі

можна робити в будь-якому порядку

але коли робиться друга - її обов'язково треба синхронізувати з першою

— це приклад чому вимоги краще писати якомога пізніше

agile на практиці

залежності у роботі

та одночасна праця на одним і тим же

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

agile на практиці

естімейти

• в поганих випадках - ким-попало
• в середніх випадках - лідами
• в найкращих випадках - консенсус декількох розробників

agile на практиці

естімейти

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

agile на практиці

естімейти

• багато компаній користуються годинами
• але деякі таки користуються сторі-поінтам

agile на практиці

розробка вимог

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

agile на практиці

діаграми Ґанта

точності даних не вистачає, щоб будувати щось прив'язане до реальності

багато компаній навіть не намагаються використовувати

agile на практиці

виконання планів

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

2. якщо не хочеться нарушати дедлайн - не треба мати дедлайнів (крім вкрай необхідних)

agile на практиці

agile на практиці

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

у мене в робочому проекті була табличка, яку мусив заповнювати користувач, десь на строки 3-5

виявилось, що деякі реальні користувачі мають десяток таких табличок з кількістю строк в 20

підсумки

чому би не запланувати усе наперед?

1. Розробники не взаємозамінні
2. Розробники звільняються (а крім цього — ходять у відпустки)
3. Систематична похибка
4. Вимоги (див. далі)

підсумки

чому би не прописати усі вимоги наперед?

1. Немає часу
2. Під час планування проекту, немає магічної кулі, щоб сказати які ще нові клієнти та нові потреби з'являться
3. Старіння вимог

але чому ми плануємо?

крім контрактів є ще одна важлива причина:

щоб не загубитись

підсумки