Планирование, учитывающее предыдущие результаты

Даже не знаю, как можно правильно перевести термин "Evidence Based Scheduling"... Джоэль Спольски разразился в своем блоге отличной статьей, посвященной объяснению вот этой вот самой штуки. Термин "Evidence Based Scheduling", похоже, придуман Джоэлем и его командой, а сам метод планирования внедрен и активно продвигается в их продукте FogBugz 6.0 (демо, которое заслуживает отдельных похвал, можно глянуть здесь, а запись выступления Джоэля - здесь). Итак, для тех, кто не любит читать "много букофф", вкратце, что же это такое и с чем его едят. Evidence Based Scheduling - это метод планирования проекта, основанный на 2-х основных принципах:

• учет предыдущих результатов для получения реальной оценки (estimate) времени, которое будет затрачено на разработку продукта
• прогнозирование вероятности релиза продукта в конкретный день (с использованием метода Монте-Карло)

По первому пункту, в принципе, все понятно. Есть люди, склонные переоценивать свои силы и недооценивать их, и это нужно учитывать при планировании проекта. Каждый грамотный team/dev/QA/project lead (нужное подчеркнуть) более-менее хорошо знает свою команду и может на основании эмпирических фактов проставить каждому девелоперу/QA коэффициент, на который нужно домножить его собственный estimate. Однако существует еще очень много факторов, которые могут повлиять на то, что проект затянется во времени и мы выпадем из графика или бюджета. Часть из них являются непроизводственными, например, прогулки по Интернету, общение в команде, кофе/чай, "а глянь какие фотки мы сделали на выходных!", часть - абсолютно честно относятся к разработке продукта: изучение новой технологии, митинги в команде, философские дискуссии с QA, что есть баг, а что фича и др. естественные, но от того не менее опасные для развития проекта активности. Все это невозможно предусмотреть заранее. Однако, если трекать процесс разработки продукта, то потом можно сравнить estimate с реальными данными и на основании этого сравнения сделать определенные выводы на будущее. Второй пункт вызывает больше интереса. Честно говоря, я не видел еще подобного способа прогнозирования дат релиза и отдельных mileston'ов (кто видел, подскажите продукт или где почитать). Как мы обычно планируем проект? У нас есть нижняя и верхняя граница оценки определенной задачи, мы выбираем цифру от 0.5 до 1 на этом отрезке (думаю, меньше 0.5 никто не выбирает :)), а затем устанавливаем ее для этой задачи в MS Project или кто чем пользуется. Строим диаграмму Ганта и в результате получаем приблизительные даты mileston'ов и релизов. Джоэль предлагает другой подход, который состоит в вычислении вероятности различных будущих, основанном на методе Монте-Карло. Данный подход достаточно тесно связан с предыдущими результатами работы наших программистов, которые у нас есть. Если мы случайным образом возьмем одно из предыдущих значений отношения оценки выполнения какой-либо задачи к реально затраченному времени (в идеале оно будет равно 1, но, конечно же, будут вариации), и разделим на него текущую оценку новой задачи, то мы получим другое число с учетом предыдущего результата. А теперь представим себе, что мы рассматриваем все задачи всех программистов и для каждой задачи вычисляем 100 различных новых значений, каждое с вероятностью в 1%. Тогда, сложив вместе эти значения (с учетом графика выполнения работ, выходных, праздников и т.д.), мы получим 100 вариантов развития события, 100 вариантов будущего нашего проекта. А уже сопоставив эти 100 графиков мы можем дать вероятность того, что наш проект завершится 10 декабря, 15 января или вообще 30 апреля. У такого подхода есть ряд преимуществ перед обычным, т.к. он дает большую гибкость и учитывает больше факторов, что, соответственно, делает результат более точным. Дальше нам остается только сказать себе, что вероятности 90% нам достаточно и мы можем поставить milestone в данную точку времени и пространства. Кроме этих интересных вещей, Джоэль также дает несколько советов по оценке задач:

• только программист, который будет реализовывать функциональность, должен оценивать ее - известный совет, которым, тем не менее, часто пренебрегают, что влечет либо к тому, что lead оценивает задачи с точки зрения "среднестатистического" программиста, либо вообще себя, а потом этим занимается либо более слабый, либо просто менее знакомый с данной предметной областью/технологией программист и весь график летит в тартарары
• время, затраченное на исправление ошибки в определенной функциональности, должно добавляться ко времени, потраченному на эту функциональность в целом - помогает хранить более точные результаты для будущей оценки и вычисления вероятностей
• не давать менеджерам загонять программистов в более узкие оценки с целью зарелизить продукт быстрее/дешевле - это вообще отдельная песня... "а можешь ли ты скроить шапку из этого куска шкуры?" - "могу" - "а 2 шапки?" - "могу" - "а 3 шапки?" - "и 3 могу"
• план проекта это коробка с бревнами - пункт, связанный с предыдущим: если у нас есть куча бревен и они не помещаются в коробку, но нужно либо убрать часть бревен из коробки, либо взять коробку побольше, но уж никак не пытаться уменьшить бревна в размерах

В общем и целом, это все. Советую прочитать статью Джоэля целиком (а также и другие его статьи), там еще много чего интересного. Вывод: FogBugz 6.0 из простой (пусть и удобной) системы багтрекинга превратился в полноценную систему управления проектами, с интересными и смелыми решениями. Интересно было бы попробовать ее в действии на реальном проекте, а то продукты MS уже как-то приелись :). Посмотрим, чем ответят разработчики других приложений. Kiwi :)

Mind maps и анализ требований

Наверняка многие слышали про mind maps и даже использовали их в жизни. Однако, в IT-проектах mind maps используются не очень широко. Недавно попробовал применять их для несколько иной задачи, чем простой брейнсторминг - для анализа требований и управления фазой проекта, чем и спешу поделиться.

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

Наш проект как раз и является таким «запутанным» случаем. Клиент хочет сделать низкоуровневые изменения, которые отразятся на многих компонентах. При этом клиент уже сам не очень хорошо помнит, как именно эта система работает и из каких частей состоит. Работает, и хорошо :). В результате мы получаем достаточно высокоуровневые требования, в которых детально описано лишь то, что клиент «вспомнил» и то, что он хочет получить в результате. Приходится потом сидеть и самому анализировать, какие компоненты системы будут затронуты и в каком объеме. Количество вопросов к клиентам увеличивается, потому что мы зачастую не знаем, как они захотят изменить старое бизнес-правило, чтобы оно работало в новой обстановке. Вследствие этого каждый вечер проводятся обсуждения, идут тучи писем, в документе требований появляются новые и исчезают старые пункты. Источников данных – тьма, вопросов – тоже, как за этим всем следить самым оптимальным способом и при этом не забыть чего-то важного – непонятно. Не говоря уже о том, что по пути мы занимаемся брейнстормингом в команде, и его результаты тоже нужно где-то записывать.

И вот здесь-то на помощь приходят различные способы компактного и по-возможности визуального представления данных. Одним из наилучших, на мой взгляд, являются mind maps. Вкратце, это способ представления различных задач, идей и прочих сущностей в произвольном формате. Единственное ограничение – это все-таки своеобразный граф, поэтому циклические зависимости представить в нем сложно. Применять mind maps можно в абсолютно разных случаях, начиная от планирования поездки в отпуск и заканчивая брейнстормингом на проекте запуска спутника в космос. Основной их фичей является то, что автор может помещать на дуги абсолютно любые слова, целые фразы, картинки, числа, даты, лишь бы между ними сохранялись семантические связи. Оказывается, это удобно и для анализа требований :). Например, вот, что у меня получилось при анализе новых требований и постепенного их обсуждения:

Приложение, которым я пользовался (кстати, абсолютно бесплатное, т.к. я специально не рассматривал платные варианты), позволяет добавлять ряд картинок к текстам, что очень удобно. Например, карандашиками я обозначил пункты, которые нам нужно заимплементить/сделать, warning'ами – различные предупреждения, знаками вопроса – требования, которые могут изменится, а числами в кружочках – фазы, в которых та или иная фича должна быть сделана. Здесь уже каждый волен обозначать пункты как ЕМУ удобнее для восприятия и понимания.

Преимущества подобного представления информации:

1. Подобную диаграмму всегда можно охватить «одним взглядом», в то время как 50-100-500-страничный документ – нет. Мозги не резиновые.
2. На диаграмме можно отображать абсолютно любую информацию: идеи, сомнения, риски, даты, степень выполнения и т.д. Я не призываю не пользоваться MS Project :), просто он предназначен для другого типа задач. Например, у нас сейчас на проекте есть документ требований, mind map и project plan – сосуществуют очень даже сносно.
3. Диаграмму можно изменить в любой момент времени, если что-то поменялось.
4. Диаграмму можно обновлять из разных источников. Пришло письмо с каким-то комментарием, меняем диаграмму. Пообщались с клиентом – снова меняем.
5. По диаграмме можно легко оценивать, сколько времени займет девелопмент, т.к. объем изменений и все взаимосвязи хорошо видны.
6. По диаграмме можно легко составлять списки вопросов клиентам и трекать состояние обсуждаемых вопросов.
7. Без сомнения, по диаграмме можно много еще чего, но до этого еще нужно добраться :)
   

Недостатки:

1. Приходится делать дополнительную работу на составление диаграммы. Впрочем, это еще вопрос, сколько она времени сэкономит в будущем. Плюс в этот момент мы «укладываем» требования в нашей голове, что позволяет быстрее их запоминать.

В общем и целом, впечатления от использования mind maps очень положительные. Mind maps - в массы? :)