Этот пост навеян оценкой большого технологического проекта, в которой мне довелось поучаствовать. Оценка началась катастрофически – после недель совещаний, сборов рабочих групп и размышлений тимлидов разработка представила оценку сроков разработки – с разбросом в 14 месяцев между минимальной и максимальной длительностью проекта.
Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.
И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.
Первый вопрос прояснился достаточно быстро – команда разработчиков оценивала проект по большому и подробному ТЗ, которое было подготовлено командой владельца продукта: менеджерами продукта и проекта, бизнес-аналитиком. На это ТЗ было истрачено достаточно много времени, но как и вся чрезмерная waterfall документация оно все-таки не давало цельного представления о задачах и их особенностях, которые в итоге и формируют сроки разработки.
Мы все знали, что люди не умеют оценивать. Мы также знали, что большинство оценок нашей команды разработки на предыдущих проектах расходились с реальностью вплоть до полугода.
Мы решили попробовать на действительно большом проекте в среде, где царил культ waterfall'a, гибкие техники оценок, и посмотреть, что из этого получится. Ведь хуже, чем 14 месяцев разброса в сроках проекта, быть уже не могло.
Идея о том, что разработчик может прочитать пятидесятистраничный документ и сделать покомпонентную оценку какого-либо продукта, всегда казалась мне неправдоподобной. Даже бизнес-аналитики начинают зевать от большинства технических заданий, с которыми приходится работать. Большинство из них написано муторным языком, который никак не призван облегчить задачу оценки. Но самое худшее в них – это то, что изначальное требование, сформировавшееся в голове владельца продукта успело претерпеть изменения и толкование того, кто написал это ТЗ, а после этого исказится восприятием разработчика, которому предложили это оценить.
Большое и красивое ТЗ вселяет в менеджмент проекта веру, что все будет хорошо. И одновременно изрядно уменьшает шансы на то, что проект будет завершен в срок и в соответствии с ожиданиями владельца продукта. Ведь в проектировании этих требований зачастую не участвовали (или участвовали недостаточно) те люди, которым придется делать реальную работу – дизайнеры, разработчики, тестировщики. И если у вас уже есть ТЗ – отложите его, и инвестируйте свое время в то, чтобы спроектировать требования с командой проекта.
Именно так сделали мы. Мы отбросили в сторону талмуд с техническим заданием, где описывались сценарии работы компонентов продукта, и засели с командой за проектирование требований и их оценку. Что мы попробовали?
В первую очередь мы отказались от feature-based оценок и попыток оценить, к примеру экран логина или оффлайн поиск по базе. Мы переформулировали все требования в пользовательские истории, определив для них критерии приемки, продумав тестовые сценарии и определив сценарии обработки ошибок, так что в итоге средняя история выглядела так:
Как администратор системы я могу отредактировать время работы организации, чтобы пользователи системы знали об актуальном расписании работы компании
Критерии приемки
Я могу указать рабочие дни организации.
Я могу указать рабочие часы каждого рабочего дня организации.
Я могу указать перерыв внутри каждого рабочего дня.
Тесты
Успешное редактирование рабочих дней организации
Успешное редактирование рабочих часов рабочего дня организации
Неуспешное редактирование рабочих часов рабочего дня организации
Успешное редактирование перерыва
Обработка ошибок
Попытка отправить пустые поля на сервер
Отсутствие сети при отправке данных на сервер
Отсутствие ответа или ошибка сервера
Мы написали более 90 пользовательских историй, распределив их по 20 эпикам (более высокоуровневым историям) и организовав все в огромную карту, которая начиналась с первых шагов действий пользователей в системе и заканчивалась на выходе из нее.
Мы устали. Но по итогу мы точно знали, что делать – у нас была оценка разработчиков, которые по сути сами придумали и досконально знали, как будет работать система (а не прочитали об этом с чужих слов). У нас была оценка дизайнеров, которые за время обсуждений успели сделать качественные прототипы всего UI, и оценка тестировщиков, которые при близком взаимодействии с разработкой и дизайны,
смогли подсказать риски и узкие места, на которых обязательно бы возникло отклонение от изначальной оценки за счет увеличения времени тестирования или просто от непродуманности какого-то момента.
Большинство проектных планов исходят из того, что мир и их организация стоят по стойке смирно в то время, пока идет работа над проектом. Impact или effect mapping можно толковать более широко, задаваясь вопросами о взаимосвязях продукта, пользователей, стейкхолдеров. Работая всей командой, и время от времени привлекая людей из сторонних компонентов, которые взаимодействовали с нашим продуктом, мы создали карту взаимодействий между историями в нашем проекте и чужими deliverables, которые нам нужно было получить к определенному времени. Имея на руках эту информацию, мы смогли перенести опасные «куски» проекта в его начало, чтобы иметь над ними больше контроля и не позволить им сильно сдвинуть наши планы посередине проекта.
Люди плохо оценивают в часах и днях, а эти оценки еще хуже ложаться на календарь. Ведь в один день разработчик или дизайнер может работать 8 часов без отвлечений и перерывов, а в другой – большую часть дня потратить на встречи и телефонные звонки.
Для начала мы поняли, что в самом лучшем случае наша команда работает 30 часов в неделю — порядка 10 часов уходит на промежуточные планирования, встречи, общение друг с другом и всякие незапланированные активности.
Потом мы определили фокус-фактор для каждого участника команды – к примеру, ведущий разработчик 4 часа дня участвует в нашем проекте и 4 часа занят функциональным руководством в своем отделе, а технический дизайнер шарится с еще двумя командами и может уделять проекту не более часа в день. Эта информация для многих стала внезапной – ведь раньше все оценки не задумываясь делались из соображений, что все работают 8 часов в день и 5 дней в неделю.
Мы начали оценивать задачи в абстрактных бананах и апельсина вместо часов и дней. Получив первые данные о нашей скорости (как много апельсинов и бананов мы успеваем произвести за неделю), мы смогли выдавать наружу данные об оценках и сроках в привычных днях, и позже регулярно корректировали их (скорость имеет свойство меняться от итерации к итерации). Очень интересно было бы услышать success story объяснений высшему руководству, почему проекты нужно оценивать в бананах или крокозяблах, но никак не в часах.
После каждой итерации мы замеряли нашу скорость, и корректировали даты работы. На нашей стороне была хорошо сработанная и технологически сильная команда, наши колебания скорости были с лихвой покрыты рисками, заложенными проектным менеджером.
Обратите внимание, что колебания скорости у команды, которая только начинает работать вместе или не обладает нужным опытом, могут быть очень и очень значительным. Ведь любая группа людей должна пройти все стадии forming-norming-performing, чтобы стать полноценной командой, а не сборищем разработчиков, дизайнеров и тестировщиков.
Более того, так как мы начали работать не над всем продуктом, а над его частью – по ретроспективной оценке мы смогли более точно спрогнозировать даты завершения всего проекта. Нам также удалось пошатнуть веру в big upfront design, и нам это понравилось.
Мы закончили всю оценку через 2 недели. Несколько двухнедельных итераций заняла ретроспективная корректировка – по результатам разработки первых пользовательских историй, мы подправили оценку нашей скорости. После этого мы проработали уже 6 итераций, и похоже, что наша работа по прежнему не потеряла связи с оценкой. Конечно, делать выводы о безусловной эффективности того, что мы попробовали рано, но это лучшее из того, что с нами происходило до этого.
В процессе работы на оценками мы также обнаружили, что нанесли серьезный удар по waterfall-у в нашей организации, и это неплохой бонус к пониманию того, когда завершится наш проект.
Использованные материалы
Dr. Cristoph Steindl, IBM – Estimation in Agile Projects
Tom Demarco and Timothy Lister – все работы без исключения
Коллективная мудрость моих блестящих коллег
P.S. Самый важный совет – во время оценок забирайте у ее участников ноутбуки, они убивают групповую динамику. Раздавайте всем много цветной бумаги, ручек и маркеров, группируйтесь возле большой доски, любите свой продукт, и у вас все получится.
Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.
И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.
Первый вопрос прояснился достаточно быстро – команда разработчиков оценивала проект по большому и подробному ТЗ, которое было подготовлено командой владельца продукта: менеджерами продукта и проекта, бизнес-аналитиком. На это ТЗ было истрачено достаточно много времени, но как и вся чрезмерная waterfall документация оно все-таки не давало цельного представления о задачах и их особенностях, которые в итоге и формируют сроки разработки.
Мы все знали, что люди не умеют оценивать. Мы также знали, что большинство оценок нашей команды разработки на предыдущих проектах расходились с реальностью вплоть до полугода.
Мы решили попробовать на действительно большом проекте в среде, где царил культ waterfall'a, гибкие техники оценок, и посмотреть, что из этого получится. Ведь хуже, чем 14 месяцев разброса в сроках проекта, быть уже не могло.
Качественная оценка всегда требует много времени
Идея о том, что разработчик может прочитать пятидесятистраничный документ и сделать покомпонентную оценку какого-либо продукта, всегда казалась мне неправдоподобной. Даже бизнес-аналитики начинают зевать от большинства технических заданий, с которыми приходится работать. Большинство из них написано муторным языком, который никак не призван облегчить задачу оценки. Но самое худшее в них – это то, что изначальное требование, сформировавшееся в голове владельца продукта успело претерпеть изменения и толкование того, кто написал это ТЗ, а после этого исказится восприятием разработчика, которому предложили это оценить.
Большое и красивое ТЗ вселяет в менеджмент проекта веру, что все будет хорошо. И одновременно изрядно уменьшает шансы на то, что проект будет завершен в срок и в соответствии с ожиданиями владельца продукта. Ведь в проектировании этих требований зачастую не участвовали (или участвовали недостаточно) те люди, которым придется делать реальную работу – дизайнеры, разработчики, тестировщики. И если у вас уже есть ТЗ – отложите его, и инвестируйте свое время в то, чтобы спроектировать требования с командой проекта.
Именно так сделали мы. Мы отбросили в сторону талмуд с техническим заданием, где описывались сценарии работы компонентов продукта, и засели с командой за проектирование требований и их оценку. Что мы попробовали?
User story mapping
В первую очередь мы отказались от feature-based оценок и попыток оценить, к примеру экран логина или оффлайн поиск по базе. Мы переформулировали все требования в пользовательские истории, определив для них критерии приемки, продумав тестовые сценарии и определив сценарии обработки ошибок, так что в итоге средняя история выглядела так:
Как администратор системы я могу отредактировать время работы организации, чтобы пользователи системы знали об актуальном расписании работы компании
Критерии приемки
Я могу указать рабочие дни организации.
Я могу указать рабочие часы каждого рабочего дня организации.
Я могу указать перерыв внутри каждого рабочего дня.
Тесты
Успешное редактирование рабочих дней организации
Успешное редактирование рабочих часов рабочего дня организации
Неуспешное редактирование рабочих часов рабочего дня организации
Успешное редактирование перерыва
Обработка ошибок
Попытка отправить пустые поля на сервер
Отсутствие сети при отправке данных на сервер
Отсутствие ответа или ошибка сервера
Мы написали более 90 пользовательских историй, распределив их по 20 эпикам (более высокоуровневым историям) и организовав все в огромную карту, которая начиналась с первых шагов действий пользователей в системе и заканчивалась на выходе из нее.
Мы устали. Но по итогу мы точно знали, что делать – у нас была оценка разработчиков, которые по сути сами придумали и досконально знали, как будет работать система (а не прочитали об этом с чужих слов). У нас была оценка дизайнеров, которые за время обсуждений успели сделать качественные прототипы всего UI, и оценка тестировщиков, которые при близком взаимодействии с разработкой и дизайны,
смогли подсказать риски и узкие места, на которых обязательно бы возникло отклонение от изначальной оценки за счет увеличения времени тестирования или просто от непродуманности какого-то момента.
Impact mapping
Большинство проектных планов исходят из того, что мир и их организация стоят по стойке смирно в то время, пока идет работа над проектом. Impact или effect mapping можно толковать более широко, задаваясь вопросами о взаимосвязях продукта, пользователей, стейкхолдеров. Работая всей командой, и время от времени привлекая людей из сторонних компонентов, которые взаимодействовали с нашим продуктом, мы создали карту взаимодействий между историями в нашем проекте и чужими deliverables, которые нам нужно было получить к определенному времени. Имея на руках эту информацию, мы смогли перенести опасные «куски» проекта в его начало, чтобы иметь над ними больше контроля и не позволить им сильно сдвинуть наши планы посередине проекта.
Относительная оценка и фокус-фактор
Люди плохо оценивают в часах и днях, а эти оценки еще хуже ложаться на календарь. Ведь в один день разработчик или дизайнер может работать 8 часов без отвлечений и перерывов, а в другой – большую часть дня потратить на встречи и телефонные звонки.
Для начала мы поняли, что в самом лучшем случае наша команда работает 30 часов в неделю — порядка 10 часов уходит на промежуточные планирования, встречи, общение друг с другом и всякие незапланированные активности.
Потом мы определили фокус-фактор для каждого участника команды – к примеру, ведущий разработчик 4 часа дня участвует в нашем проекте и 4 часа занят функциональным руководством в своем отделе, а технический дизайнер шарится с еще двумя командами и может уделять проекту не более часа в день. Эта информация для многих стала внезапной – ведь раньше все оценки не задумываясь делались из соображений, что все работают 8 часов в день и 5 дней в неделю.
Мы начали оценивать задачи в абстрактных бананах и апельсина вместо часов и дней. Получив первые данные о нашей скорости (как много апельсинов и бананов мы успеваем произвести за неделю), мы смогли выдавать наружу данные об оценках и сроках в привычных днях, и позже регулярно корректировали их (скорость имеет свойство меняться от итерации к итерации). Очень интересно было бы услышать success story объяснений высшему руководству, почему проекты нужно оценивать в бананах или крокозяблах, но никак не в часах.
Ретроспективная оценка
После каждой итерации мы замеряли нашу скорость, и корректировали даты работы. На нашей стороне была хорошо сработанная и технологически сильная команда, наши колебания скорости были с лихвой покрыты рисками, заложенными проектным менеджером.
Обратите внимание, что колебания скорости у команды, которая только начинает работать вместе или не обладает нужным опытом, могут быть очень и очень значительным. Ведь любая группа людей должна пройти все стадии forming-norming-performing, чтобы стать полноценной командой, а не сборищем разработчиков, дизайнеров и тестировщиков.
Более того, так как мы начали работать не над всем продуктом, а над его частью – по ретроспективной оценке мы смогли более точно спрогнозировать даты завершения всего проекта. Нам также удалось пошатнуть веру в big upfront design, и нам это понравилось.
Итог
Мы закончили всю оценку через 2 недели. Несколько двухнедельных итераций заняла ретроспективная корректировка – по результатам разработки первых пользовательских историй, мы подправили оценку нашей скорости. После этого мы проработали уже 6 итераций, и похоже, что наша работа по прежнему не потеряла связи с оценкой. Конечно, делать выводы о безусловной эффективности того, что мы попробовали рано, но это лучшее из того, что с нами происходило до этого.
В процессе работы на оценками мы также обнаружили, что нанесли серьезный удар по waterfall-у в нашей организации, и это неплохой бонус к пониманию того, когда завершится наш проект.
Использованные материалы
Dr. Cristoph Steindl, IBM – Estimation in Agile Projects
Tom Demarco and Timothy Lister – все работы без исключения
Коллективная мудрость моих блестящих коллег
P.S. Самый важный совет – во время оценок забирайте у ее участников ноутбуки, они убивают групповую динамику. Раздавайте всем много цветной бумаги, ручек и маркеров, группируйтесь возле большой доски, любите свой продукт, и у вас все получится.
