Revision as of 20:55, 21 January 2021

Цель

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

Тезисы

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

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

Первые два в принципе покрываются отвественностью ПО за постановку целей, за оценку и оптимизиацию 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! Если надо - следует создавать architecure spike and business spike

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