Планирование и отслеживание итеративной разработки с помощью Microsoft Project
| March 16, 2012 | Posted by admin under Практики, Статьи |
Статья из блога Сергея Рогачева : http://rsn81.wordpress.com/2012/03/15/planning-and-tracking-agile-by-microsoft-project/
В заметке описывается вариант планирования и отслеживания итеративной разработки с помощью Microsoft Team Foundation Server 2010 и Microsoft Project 2010. Про TFS, как инструмент управления жизненным циклом приложения (ALM, Application Lifecycle Management), будет сказано немного. В принципе, не важно, какое хранилище вы используете для структурирования и хранения ваших работ (WBS, Work Breakdown Structure), описанный материал должен быть вам равнозначно полезен. Вместо TFS у вас может быть, к примеру, Atlassian Jira. Также я не собираюсь повторять в своем исполнении статьи Microsoft про интеграцию TFS и Project. Речь пойдет о том, как использовать Project, традиционно воспринимаемый в качестве инструмента долгосрочного планирования, в качестве калькулятора, упрощающего планирование и отслеживание итераций согласно всем канонам гибкой методологии Scrum, описанным Хенриком Книбергом в легендарной книгеScrum и XP: заметки с передовой. Этот рецепт был изобретен еще 3 года назад при работе с предыдущими версиями указанных программ, то есть практически также работает на TFS 2008 и Project 2007. Материал предназначен для менеджеров по разработке, руководителей групп разработки и ведущих разработчиков, которые хотя бы примерно понимают все, что написано в этом абзаце текста.
К чему это все?
Поводом для публикации стали бесконечные, настойчивые и даже слегка агрессивные заявления слепых приверженцев Agile, а то даже и тренеров известных компаний, предоставляющих консалтинговые услуги по внедрению гибких методологий, на профильных ресурсах Интернет о том, что Agile, в основе которого лежит открытость и готовность к постоянным изменениям, и Project – вещи несовместимые, так как “этот инструмент применяют недалекие менеджеры для создания рисунка колбасок взаимосвязанных работ на диаграмме Ганта, который они называют календарным планом разработки и который по их глубочайшему убеждению, рожденному во враждебной секте доисторического и уже не модного водопадного планирования, меняться не может, а если и меняется, то это целиком вина балбесов-разработчиков, не умеющих оценивать трудоемкость задач или безответственно срывающих сроки”.
Я думаю, что это действительно следствие нехорошего опыта работы в прошлом с такими вот “недалекими менеджерами”. Но, кроме того, в этом прослеживается распространенный по причине своего коварного удобства миф о том, что планировать гибкую работу не нужно, так как это бессмысленно.
К сожалению, словами доказать обратное по-моему невозможно. Думаю, к этому менеджер может прийти только на основе личного опыта. К примеру, так повезет в жизни, что вам поручат инновационный проект. Это будет не очередной веб-сайт или редактор базы данных, которых ваши разработчики сделали уже столько, что могут легко угадывать срок реализации, а все ваше гибкое планирование потенциальных изменений и недоверия к оценкам разработчиков в которых сводится к умножению этого срока на 2. Так как оценить то, что ни разу не делал и не знаешь, как делать? Или как в этом же проекте спланировать ресурсы для защиты бюджета, когда у вас в компании нет всемогущего пула, из которого вам по запросу тут же могут отгрузить разработчика? Конечно, на помощь приходит оценка производительности проектной команды, управление рисками (в частности, неизвестностью), прогнозирование и прочие методики планирования в динамике, на которых на самом-то деле и основаны гибкие методологий: Agile говорит о бессмысленности предварительного долгосрочного планирования, результатом которого должен стать железобетонный неизменяемый план, но вовсе не говорит о том, что планировать работы, озвучивать сроки и укладываться в них теперь не нужно.
В конце концов, кто вы, менеджер по разработке, как не эксперт по планированию, пусть даже гибкому? Умножать оценки на 2 может калькулятор. Не доверять разработчикам, а также дергать их по любому поводу может любой, кому за честную зарплату нечем занять себя в рабочее время. “Головняки” обещаний сроков, выданных после многозначительной паузы, потраченной на разглядывание потолка, и смиреной готовности к неминуемому вызову на ковер к руководству в случае срывов сроков можно повесить на девушку без нервов с должностью администратора проекта.
Завершаю лирическое вступление. Итак, рамки данной заметки: как планировать и отслеживать итерации в Scrum с помощью TFS и Project – прогнозирование сроков всего проекта сейчас не рассматриваем.
Приступаем к планированию
Что на входе?
Внедрен процесс итеративной разработки, к примеру, Scrum. Как минимум, должны быть стабильные итерации (спринты). Как максимум, регулярно производится оценка производительности команды, то есть по итогам итерации уточняется цифра, так называемого, фокус-фактора.
Рабочие элементы, которые планируются на итерацию, хранятся в TFS или иной ALM, по возможности имеющей интеграцию с Project.
В рамках планирования итерации исполнители оценили трудоемкость рабочих элементов в идеальных часах или прочих разновидностях попугаев вроде story points.
На какие вопросы будет ответ по завершению?
Успеем ли мы сделать все задачи, что запланировали?
Запланировали ли мы полную и равномерную загрузку членов команды? Не выйдет ли так, что менеджер даже и не заметит, что один разработчик будет всю итерацию работать не покладая рук на успех демонстрации по итогам итерации, а второй от недостатка задач будет заниматься больше саморазвитием, разумеется, в рамках поставленных ему задач.
На какие вопросы нужно регулярно получать ответы?
Мы все еще успеваем сделать все запланированное до конца итерации? Если так, то что конкретно и какие у нас есть варианты неизбежного перепланирования?
А, быть может, мы запланировали мало работы, и имеет смысл взять в работу дополнительные задачи? Если так, то сколько работы можно взять, чтобы успеть ее сделать?
Какие инструменты нужны?
В начале заметки я приводил ссылку на статью Microsoft, в которой подробно описан перечень требуемого программного обеспечения для возможности планирования и отслеживания проектов TFS в Project. Разумеется, нужен сервер TFS. На рабочую станцию минимально достаточно установить Microsoft Visual Studio Team Explorer 2010 и Microsoft Project Standard 2010. По завершению рекомендую запустить Windows Update: придет и установится очень много всего полезного.
Что возьмем в качестве примера?
В качестве примера я возьму нашу текущую уже завершающуюся 2-недельную итерацию. Дело в том, что она очень показательна с точки зрения сложности планирования по причине большого количества дополнительных факторов, учесть которые непросто: на первой неделе итерации с 5 по 11 марта были укороченные дни и праздничные дни, в начале второй недели ровно посередине итерации в команду влился новый разработчик, руководитель группы разработки примерно 10% своего времени тратит на собеседование разработчиков – сюда можно добавить и более сложные факторы, которые меня ждут впереди, к примеру, привлечение внешних ресурсов на часть работ по итерации, доступность которых в момент планирования итерации можно оценить только приблизительно.
Знаю, что сектанты от Agile скажут: и не нужно учитывать все эти мелочи, ведь планирование всего этого, тем более автоматизированными инструментами, похоже на расстрел воробьев из пушки. Таким образом, основной тезис: это сложно, а потому бессмысленно. А хотите увидеть, как легко все эти факторы может учесть в калькуляции Project, предоставив нам четкую картину прогноза итерации и текущего ее состояния в течении всей итерации?
Примечательно также, что Microsoft в новой версии TFS 2011, находящегося сейчас в стадии бета-тестирования, все-таки реализовали упрощенный сценарий того, что будет описано ниже с применением Project: Plan an Iteration.
Планируем
Итак, что я сделаю?
Я открою запланированные на итерацию рабочие элементы, трудоемкость которых оценили исполнители, в Project, укажу необходимые параметры: дату начала и окончания итерации, доступность ресурсов, в том числе праздники и отгулы, фокус-фактор команды и прочие параметры – и попрошу Project ответить на озвученные выше вопросы.
Автоматическое планирование
Прежде всего нужно убедиться, что в Project по умолчанию настроено использование режима автоматического планирования новых задач. Если после запуска Project возникает вот такое всплывающее уведомление:
– то выбираем пункт Параметры в меню Файл, в открывшемся окне Параметры Project переходим на закладку Расписание, затем в раскрывающемся спискеПараметры планирования для этого проекта выбираем пункт Все новые проекты, а в раскрывающемся списке Новые задачи пункт Автоматическое планирование, после чего нажимаем кнопку OK.
Это позволит Project самостоятельно рассчитывать даты начала и окончания задач на основании ссылок, ограничений и других факторов, которые мы собираемся учесть.
Это достаточно важный момент. Ручное планирование и отслеживание задач менеджером внутри итерации очень трудоемко и практически бессмысленно. Кроме того, с этой задачей прекрасно справляется сама команда, обсуждая текущий статус задач на ежедневном Scrum-собрании, окружив доску задач. Мы используем для этого виртуальную доску TFS Workbench: каждое утро каждый из нас рассказывает остальным про статус своих задач, указывая на соответствующие им “бумажки” (sticky notes) на доске задач, при необходимости изменяя их статус (взял в работу, завершил) и оценку оставшихся трудозатрат, отражая прогресс или указывая новой оценкой факт недооценки.
По сути ежедневный Scrum и является ручным планированием и отслеживанием в итеративной разработке, но по сравнению с мучениями менеджера, вручную управляющего разработкой, а вернее разработчиками, в данном варианте все происходит автоматически. Кроме того, нагрузка по выполнению этой работы равномерно распределяется между членами команды, а времени на это уходит всего 15+ минут в день. Эффект замены ручной на автоматическую коробку передач автомобиля.
К слову, TFS Workbench мы используем временно, так как с нетерпением ждем выхода TFS 2012, в котором виртуальная доска задач реализована из “коробки”.
Определяем параметры итерации
Теперь нам нужно определить параметры итерации, которые Project будет использовать для расчета проекта.
Дата начала итерации
На панели инструментов переходим на закладку Проект, нажимаем на кнопкуСведения о проекте и в открывшемся окне указываем дату начала итерации в поле ввода Дата начала. Хоть итерации и начинается с 5 марта, тем не менее, как видите, я указал в качестве даты начала следующий день. Так я бронирую примерно день работы всей команды на отнимающие много времени встречи: планирование, демонстрация и ретроспектива – тем самым, Project остается без целого дня для калькуляции.
Доступные человеко-часы
На панели инструментов нажимаем кнопку Изменить рабочее время, в открывшемся окне указываем все сложности, которые нам принес международный женский день. Как видите, я создал следующие исключения: укороченный на час день 7 марта, нерабочие дни 8-9 марта, рабочий день 11 марта.
Кроме того, здесь же можно указать запланированные отгулы, болезни, походы на конференции и прочие виды заранее известной недоступности конкретных членов команды. Для этого в выпадающем списке Для календаря выбираем название ресурса, которое используется в TFS, и настраиваем нужные исключения.
Нажимаем кнопку OK. Все, теперь о доступном рабочем времени на итерации нам беспокоиться не нужно, Project все учтет. Но нужно определить еще доступность ресурсов, чтобы Project в итоге смог посчитать доступные человеко-часы по каждому члену команды и учитывать это при планировании задач, назначенных на них.
На панели инструментов переходим на основную закладку Задача и нажимаем первую кнопку Диаграмма Ганта, после чего в выпадающем списке выбираем представление Лист ресурсов.
Вот как это выглядит.
В данном представлении отображаются все ресурсы, на которые в итерации назначен хотя бы один рабочий элемент. Не правда ли, отличная у меня команда, с такой просто горы можно с места сдвигать? Тем не менее, все имена вымышлены, любое совпадение считать случайностью.
Здесь я определяю доступность членов команды на итерации, а также ввожу выбранный на итерацию фокус-фактор. Рассмотрим каждый ресурс подробно.
Я на проекте выполняю функции ролей Product Manager и Program Manager (терминология методологии Microsoft Solution Framework 3.1, по которой на самом деле мы “живем”, а по Scrum лишь “разрабатываем”), потому на итерации я “бездельничаю” как все курицы из анекдота, часто рассказываемого Scrum-тренерами. Конечно, это не правило, иногда я беру некоторые работы на себя, но конкретно в данной итерации на момент планирования потребности во мне как исполнителе не было. Поэтому столбце Макс. единиц напротив себя я указал 0%. Кроме того, это помогает Project отлавливать попытки назначить на меня какие-то задачи итерации по ошибке и выводить соответствующее предупреждение.
Теперь перейдем к более сложному случаю.
Ballmer Steve у нас руководит группой разработки, а потому привлекается к техническому собеседованию разработчиков, активным поиском которых мы сейчас занимаемся. По статистике, специально собранной на прошлой итерации, он отвлекался на общение с соискателями в среднем на 10%. Поэтому основываясь на статистике HR о том, что количество желающих или решивших сменить наконец-то работу в начале весны может только расти, и принципе “вчерашней погоды”, мне нужно заложить доступность ресурса Ballmer Steve на 90%.
Но я же еще хотел заложить в расчет фокус-фактор. Обычно тренеры рекомендуют фокус-фактором уменьшать количество доступных для планирования попугаев, указанных в story points. Но для этого их нужно вначале посчитать, а как-то лениво: ведь выше я уже передал все данные, пусть Project сам считает. Поэтому я придумал закладывать показатель производительности просто в доступность всех ресурсов. Та же яичница, только вид сзади. По итогам прошлой итерации фокус-фактор составил 45%, но при планировании этой итерации мы решили стандартным образом попытаться заставить себя чуть-чуть лучше фокусироваться на целях итерации, а потому заложили фокус-фактор в 50%. Таким образом, Ballmer Steve, которого никто не отвлекает, особенно я, доступен на итерации на 90%, но всего из них по прогнозу “вчерашней погоды” с небольшой добавленной оптимистичностью он будет “доступен” только на 50%. Итого, получаем 45%.
С точки зрения вклада в работу по данной итерации Gates Bill просто стахановец, соответственно, полностью “доступен” с учетом фокус-фактора на 50%.
Аналогично и “доступность” Guthrie Scott, вот только парень присоединится к нам только на второй неделе итерации. Двойным нажатием по ресурсу вызываем окноСведения о ресурсе и указываем этот хитрый вариант доступности ресурса. На первой неделе до начала праздников его не будет: 0% до 10 марта – конечно, выходить на новое место на непонятные 3 дня смысла мало. Итого, он присоединится к нам в жуткое для всей страны постпраздничное воскресенье: 50% с учетом фокус-фактора с 11 марта. Обратите внимание, что благодаря такой настройке в представлении Лист ресурсов вплоть до 11 марта напротив ресурса будут светиться 0%.
Загружаем рабочие элементы
Теперь необходимо загрузить в Project рабочие элементы, оцененные исполнителями и запланированные на итерацию в TFS. Самый простой вариант описан в статье:Планирование задач и назначение ресурсов с помощью приложения Microsoft Project.
Тем не менее, лучше загружать задачи непосредственно из самого Project. В этом случае заложенные “доступности” ресурсов будут автоматически проставлены в столбец Названия ресурсов по всем загруженным задачам, иначе придется проставлять вручную. Подробности см. в статье Создание плана Microsoft Project из рабочих элементов Team Foundation.
Все, я передал Project для калькуляции все необходимые в этом конкретном примере данные, теперь его пора прийти на помощь. Переходим на закладку Ресурс, жмем кнопку Параметры выравнивания и в открывшемся окне указываем параметры расчета. Жмем кнопку OK, и нажимаем на панели инструментов, пожалуй, самую магическую кнопку в Project – Выровнять все. При этом Project вычисляет такие даты задач, при которых соблюдаются все заданные ранее параметры, взаимосвязи задач в TFS, а также желание побыстрее все успеть при нормальной загрузке всех ресурсов. Вот даже Project по умолчанию чтит трудовой кодекс.
Project справляется с расчетом в доли секунды, после чего снова начинаются мои мучения. Обычно все-таки на итерацию планируется “на глаз” большее количество работы, чем сможет осилить команда в нормальном темпе работы. Хотя бывает и обратное. Соответственно, дата завершения всего проекта уплывает за дату окончания итерации или встает как вкопанная за несколько дней до нее. Переходим на закладку Формат панели инструментов и устанавливаем переключательСуммарная задача проекта, после чего отобразится корневая задача, по столбцуОкончание которой можно сразу видеть рассчитанную дату окончания всех работ. Как следствие, мучаемся над вопросом, что можно выкинуть из перегруженной или добавить в недогруженную итерацию.
Кроме того, бывает, что при планировании сразу же прогнозируется, кто и какие задачи будет выполнять. Все понимают, что в течение итерации самую приоритетную задачу может схватить любой освободившийся член команды. Тем не менее, есть “любимые” и “нелюбимые” задачи, есть эксперты и прочие варианты индивидуальных желаний или нежеланий забрать конкретные задачи. Конечно, идеальным вариантом было бы назначать все задачи на один и тот же ресурс, к примеру, руководителя группы разработки: в момент планирования это означает назначение задач команде, а не конкретным исполнителям – в течение итерации члены команды разбирают задачи самостоятельно или по просьбе руководителя группы разработки. В этом случае ресурсу Ballmer Steve я просто бы проставил “доступность”, равную суммарной доступности всех членов команды. Но так сделать получается не всегда, в итоге, приходится учитывать в том числе и индивидуальную нагрузку каждого ресурса. На панели инструментов переходим на основную закладку Задача и нажимаем первую кнопку Диаграмма Ганта, после чего в выпадающем списке выбираем представление График ресурсов.
Как видите, Gates Bill – труженик, работающий по полной каждый день. Напомню, что размер этой “по полной” был задан нами в виде “доступности” ресурса в 50%. И Project тоже молодец: не заставил работягу выходить на работу в праздники на первой неделе и выходные на второй – зато он нашел его неизбежные переработки 12 и 14 марта, практически по 16 часов в день. С помощью других представлений, в принципе, можно будет найти, что так Project пришлось сделать, так как, к примеру, на завершение каких-то работ Gates Bill завязаны задачи, к примеру, Ballmer Steve, которые тоже нужно успеть сделать в срок без переработок. Но это только ради академического интереса, ну то есть от нечего делать. На самом деле уже итак понятно, что ресурс на критическом пути и что нужно переносить какие-то задачи с него на других, у кого есть свободное время в итерации. Курсором перемещаемся на график другого ресурса, таким образом, быстро вычисляем “бездельника” и передаем ему часть задачи с перегруженного.
Я описал только некоторые варианты, но с помощью приведенных выше представлений, включенных мозгов и коллективного обсуждения обычно быстро удается прийти к финальному варианту. Вот, как он выглядит. Идеально, не правда ли? На самом деле, если вы обратите внимание на отметку Сегодня на временной шкале, то поймете, что это срез на конец итерации. И нам все-таки пришлось перепланировать итерацию на последней неделе из-за предварительной переоценки трудозатрат.
Вот, собственно, и все.
Ах, да, еще я обещал отслеживание работ по итерации. Здесь я предпочитаю пользоваться стандартным отчетом Burndown and Burn Rate: реагируя только на сильное расхождение палочек идеального и реального трендов, удается хоть на некоторое время отключать мозг на работе.
Тем не менее, более детальный статус работ можно отслеживать с помощью Project, просто выполняя обновление задач изменениями рабочих элементов в TFS. Кроме того, к сохраненному после планирования MPP-файлу можно возвращаться при перепланировании: по сути, в этот момент производится ровно та же самая работа, что и при планировании.
Надеюсь, мне удалось продемонстрировать Project как очень мощный инструмент для решения определенных проблем в том числе и в гибкой разработке. Пусть это и просто калькулятор, но очень удобный!
Pingback: Планирование и отслеживание итеративной разработки с помощью Microsoft Project « Рогачев Сергей()