PO - 08 - Оценка

Цель

Понять роль ПО в оценке BI

Тезисы

Оценка в общем, DoD & WBS

Причины почему реальность не совпадает с оценками?

• Не понимали что делать/делали не то/пришлос переделывать
• Слишком большой кусок для оценки, потерялись, не справились
• Просто забыли/заранее не знали часть работ которые надо делать

Первые два в принципе покрываются отвественностью ПО за постановку целей, за оценку и оптимизиацию value, за организацию и проведение refinement.

На интересует третье:

Аксиома: команда отвественна за выдачу оценок (estimation), и PO не может и не должен навязывать свою оценку.

Однако означает ли это что PO совсем не должно заботить насколько качественная оценка? Конечно же нет.

1) PO в том числе отвечает что бы у команды был definition of done который бы устраивал пользователей, стейкхолдеров и споносоров.

2) PO в праве требовать чтобы оценка учитывала DoD.

Полезно составить DoD куда бы вошли все важные этапы: анализ, архитектура, дизайн технический, дизайн UI и UX, учет имеющейся codebase, собственно разработка, тестовое покрытие, поиск и отслеживание рисков, документация техническая, документация пользовательская, тестирование через реалистичные сценарии, интеграция, выпуск, мониторинг и поддержка на продакшн

ВАЖНО #1: При этом НЕ делать работу за них. Даже если знаем - намного лучше не дать им готовый ответ "вам нужно тестирование", а задать вопрос "а запланировали ли мы время, на то, чтобы убедиться что код работает". И не только потому что мы типа надругаемся над их автономностью, а потому что сделаем за них раз - сядут и ножки свесят, и еще отвественность на нас переложат.

ВАЖНО #2: НЕ НАДО бояться требовать от команды соотвествия DoD. То что они "не могут" - это их проблема, должны подтягивать свой уровень. Одна из причин по которой у команд бывает "корона на голове" - как раз потому что PO не достаточно требовательны в соблюдении DoD.

А когда всё равно нельзя оценить?

Бывает такое, на то у нас и эмпирический процесс.

Что важно помнить:

1) Буфер - это предосудительная практика. Показатель непрофессионализма.

Правильно: - Отражать уверенность в оценке давая её в диапазоне. Чем выше уверенность - тем уже диапазон. Cone of uncertainty.

- Выявление рисков которые могут повлиять на оценку и закладывание резерва под конкретные риски (в этом отличие от буфера).

2) Основная часть по подготовке к оценке должна проводиться на refinement! Если надо - следует создавать architecture spike and business spike

3) Методики типа PERT ( (optimistic + 4 * average + pessimistic) / 6 )

Пример подхода с неясными требованиями:

1) Выявить MVP ("без этих функций всё равно никому не надо") и оценить его.

2) Получить "другую" сторону оценки

Пример варианта. Выявить оптимальный (например "как у всех") и/или максимальный ("больше не о чем мечтать") варианты и оценить их тоже, получив cone of uncertainty.

Пример варианта. Выявить по одному примеру из каждой категории размера требований и оценить их. Это даст возможность заказчику представить себе насколько добавление требований приведет к росту бюджета и сроков.

ВАЖНО: Прирост точности оценки НЕ ЛИНЕЙНО зависит от вложенных усилий. Если сначала дополнительные усилия значительно уточняют оценку (e.g. потратить всего пять минут или потратить целый час вполне себе даст оценку точнее в 10 раз), то с какого момента дополнительные усилия не дадут (e.g. потратить одну неделю или две - не даст в два раза более точной оцеки).

Граница - в тот момент когда у мы полностью ушли от цифр "от фонаря" и получили какие-то обоснованные оценки, например на основе:

• Построения плана работ/WBS
• Сравнения с решениями сделаными раньше
• Сравнения с чужим опытом
• Проведения эксперимента
• Использования практических стандартов и нормативов

Быстрые методы оценки в Agile

Традиционно в Agile методы оценки не включают в себя построение WBS, более того это считается анти-Agile практикой, потому что содержит в себе предсказательный элемент.

Методы оценки в Agile исходят из того, что команда у нас кросс-функциональна, т.е. обладает всеми знаниями и опытом, необходимыми для завершения работ. В этом случае полу-интуитивная оценка разработчиков, оценивающих хорошо знакомый им тип задач вполне достоверна и создание WBS превращается в ненужную работу.

Примерами Agile методов оценки могут быть Planning Pocker и White Elephant.

Planning pocker - метод коллективной оценки, при котором команде даются PBI для оцеки, и команда оценивает каждый отдельно.

При оценке PBI команда использует набор карточек с условной сложностью (например в идеальных командо-днях или в story points), причем карточки обычно делают на основе чисел фибоначи (1/2, 1, 2, 3, 5, 8, 13, 21...). Цифры не круглые и не регулярные умышленно, чтобы не создавалось иллюзии что это точная оценка и чтобы отразить что чем больше задача, тем меньше точность. Все члены команды имеют свою "колоду" и одновременно выкладывают карту, которая соотвествует сложности обсуждаемой PBI. Если оценки совпали - ок, если расходятся - то просят обосновать своё решение тех, кто выкинул минимальную и максимальные оценки. Делается это потому что нам не важно почему команда пришла к консенсусу - оценка это их внутрнее дело и их accountability. Важно чтобы ничего не упустили. Если больше 3-5 rounds не могут придти к согласию - карточка снимается с голосования от правляется на доработку.

White elephant это более быстрая версия покера. Для работы нужна доска, на которой рисуется таблица, включающая с колонками соотвествующими карточкам покера (1/2, 1, 2, 3, 5, 8, 13...) и дополнительными колонками "too big" и "unknown". Люди по очереди могут или взять новый PBI и поместить его в колонку или передвинуть уже расположенный кем-то другим PBI, кратко объяснив почему. Если карточку не двигают - значит по ней есть консенсус. Если двигают больше чем установленный лимит (например 3-5 раз) - значит карточка сниматеся с голосования.

С точки зрения ПО важные моменты:

• при внесении карточки важно убедиться что команда понимает приносимое value и как это value поддерживает цели проекта.

• при оценке можно сразу следить за тем, что усилия по карточке соотвествуют её ценности. нет никакого резона делать PBI который обойдется дороже чем принесет пользы

• отсутствие консенсуса возможно является одним из признаков не понимания карточки, так что первым делом в этом случае надо убедиться что есть единое мнение что именно мы собрались делать.

Обратите внимание что оба метода ограничивают время на споры по items, по которым не удается найти консенсуса и предлагают использовать другой, более аналитичный/точный метод оценки в этом случае. Это важная "фича" и если её упустить - то методы превращаются или в пустую трату времени, или в называние цифры от фонаря, лишь бы все это закончить.

Особый случай - жесткая минимизация WIP

Частный случай аналитического подхода - это применение lean принципа жесткой минимизации WIP - задачи должны быть настолько маленькими, чтобы бы завершаться в один день. Это дает два преимущества:

• настолько простые задачи легко оценить интуитивно даже при некотором недостатке знания и опыта

• получая результат настолько быстро - мы можем обнаруживать ошибки планирования очень быстро, в рамках одного дня.

Работа ведется в виде planning pocker (см выше), но всего с тремя карточками 1, NFC (no f.. clue, не знаю), TFB (too f... big, слишком много). Карточки NFC и TFB отправляются для дальнейшего refinement, пока они не станут "1".

Риски

Риск это событие которое может наступить и повлиять на наш план. Если событие наступит точно - то это issue, а не риск.

Если событие наступит скорее всего - то это не риск, а небрежное планирование в стиле "у меня есть план купить машину, но есть риск что я не выиграю в лотерею".

По рискам мы:

• Оцениваем вероятность возникновения. Еще раз вероятность скорее всего наступит - это ТОЧНО не риск.
• Оцениваем степень влияния.
• Формулируем критерии как мы сможем обнаружить наступление риска.
• Назначаем отвественного за обнаружение и разрешения риска.
• Планируем наши действия в случае наступления риска.

Пример риска: Сотрудник может заболеть.

Степень влияния: Работа заложенная на сотрудника не будет сделано. Если команда из двух человек - то это может удлинить сроки вдвое.

Как узнаем: Сотрудник не пришел на работу по причине болезни (это если в управлении мудаки сидят)

А на самом деле, если вдумчиво, на вскидку:

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

План. Тут важно помнить что есть разные способы действий в случае на риска, сразу английские названия чтобы источники искать:

• Avoid: Риск можно устранить. Например в сезон гриппа можно организовать вакцинацию. А в случае хронических болезней - хорошо помогает диспанцеризация.
• Mitigate: Можно устранить последствия риска. Например можно быть готовым подключить замену.
• Transfer: Можно делегировать риск. Например сделав так что в этом случае рискует заказчик, а не мы. Ну или что пострадает заболевший. В случае заболевания это конечно выглядит не красиво, но скажем если мы рассмотрим ситацию при которой человек потеряет работу потому что заказчики начали просить то, что он не утрудил себя изучением - вполне себе вариант.
• Accept: Можно принять риск. Например заложив в стоимость бюджет на покрытие штрафов от болезней.

Ну так если вообще не можем оценить. Не знаем, не понятно что оценивать

Эмпирический процесс и колонны скрам

А значит имеем дело со сложной системой. И скрам четко говорит нам что:

a) Надо установить прозрачность. Начиная прямо вот с того, чтобы четко обозначить что в сложившейся ситуации именно мы и именно эту задачу оценить не можем.

б) Надо принять accountability и проявить смелость предложив способ решения, например:

• Вовлекая заказчика в процесс (см. принцип Agile - разработчики и бизнес совместно работают над решением) и совместно формулируя гипотезы для оценки

• Выдвигая обоснованные гипотезы и планируя короткие эксперименты по их проверке (inspection, fail fast!) и сразу закладывая что гипотеза может оказаться неверной, и делая прозрачным как мы об этом узнаем и что мы будем делать (adaptation!)

И снова Inverted Iron Triangle

И этот подход требует смены способа мышления. Примеры хорошо показывают что чаще всего люди строят минимальный план выполнение которого они уверены приведет к успеху и начинают искать время и ресурсы на его достижение. Это подход водопада.

Подход agile прямо противоположный. Мы принимаем жесткое ограничение по времени и ресурсам, и выбираем как наилучшим образом мы можем сделать что-то полезное в этих рамках. Мы не ищем идеального решения. Мы предлагаем лучшее возможное решение в преложенных ограничениях!!!

Неправильный вопрос себе: "Сколько ресурсов/времени мне нужно?". "Сделали ли мы все что нужно?".

Правильный вопрос себе: "Сделал ли я то, то что доставит максимум возможного в отведенные рамки?". "Является ли это самым важным что надо получить?". "Если я не уверен точно - что именно и как именно я буду измерять что бы узнать что я не прав". "Что я буду делать если узнаю что выбранный вариант не доставляет ценности"? "Как быстро я об этом узнаю?".