Многие программисты по мере своего развития выбирают для себя стезю управления разработкой, с сожалением ограничивая себя в творческом процессе изучения новых языков программирования и технологий.
И, начиная с этого момента, мы уже как руководители вынуждены бороться со сложностью разработки программных проектов, сложностью их однородного понимания всеми участниками и сложностью учёта изменений, происходящих постоянно при изменениях внешней среды. Ориентируясь на пророческое утверждение Брукса о том, что серебряной пули нет, мы всё же ищем способ найти управленческую технику, увеличивающую, хотя бы и не на порядок, производительность, надёжность и простоту в разработке программного обеспечения.
Итак, каждый из руководителей знает, что такое диаграмма Ганта, и каждый пользовался MS Project. Ещё больше читателей, программистов, использует систему управления задачами. И практически все программисты-не одиночки используют систему управления исходным кодом.
Перед нами стоит вполне прагматическая задача обеспечить единый процесс разработки, когда при учёте каждого нового изменения требований можно наглядно увидеть изменение параметров проекта.
Сформулируем эту задачу на прикладном уровне. Представим проект как набор этапов, которые в свою очередь состоят из перечня высокоуровневых задач, каждая из которых включает ряд пользовательских сценариев, стори, а те – декомпозируются в таски. Мы нарочно и дальше будем использовать в статье такую смешанную терминологию, не то ГОСТ, не то Agile, так как заказчики смотрят на проект примерно на уровне детализации этапов, и им вообще не интересно знать, что такое Agile, а разработчики смотрят на задачи примерно на уровне тасков и им в свою очередь не интересно думать о ГОСТах.
Далее, мы должны добиться того, чтобы при поступлении новых данных о проекте репланнинг с учётом всей доступной информации проходил максимально быстро, и мы могли получить максимально быструю обратную связь по проекту в целом, чтобы предоставить её Заказчику (или учесть в собственных маркетинговых ожиданиях при разработке собственного продукта).
Какими инструментальными средствами должны теперь мы воспользоваться для того, чтобы достигнуть цели? Представлю следующие критерии выбора этих инструментальных средств:
1) Необходима диаграмма Ганта как визуальное средство и как инструмент для планирования этапов
2) Инструментальные средства должны позволять проводить декомпозицию высокоуровневых задач в пользовательские сценарии, а их – в таски для программистов и аналитиков
3) Инструментальные средства должны автоматизированным способом обеспечивать взаимосвязь при изменениях между задачами в высокоуровневой диаграмме Ганта и тасками. Например, если мы ошиблись с оценкой одного из тасков, и у программиста на задачу ушло времени в два раза больше, то это может привести и к увеличению продолжительности одного из высокоуровневых этапов. А поскольку мы не хотим, чтобы сроки высокоуровневого этапа были сорваны, то мы должны провести анализ критического пути, чтобы заново сбалансировать требования и ресурсы. Наши инструментальные средства, благодаря взаимосвязям между уровнями, должны помочь нам увидеть проблему с возможными срывами сроков на диаграмме Ганта
4) Желательна также возможность отслеживания связей между тасками программистов и исходным кодом в системе управления исходным кодом
5) Система управления исходным кодом в свою очередь должна поддерживать модель бранчинга, например, подойдёт связка git+gitflow
6) В системе управления задачами необходима возможность отмечать фактически назначенное время и учитывать величину остатка по времени, а также получать отчёты о ходе выполнения работ
Существует несколько вариантов выбора подобных инструментальных средств, рассмотрим три из них, которые кажутся нам наиболее подходящими:
1) MS Project + Team Foundation Server
2) Jira
3) Redmine
Jira и Redmine рассмотрим в следующих статьях, а в этой сосредоточимся на MS Project + Team Foundation Server (+ Visual Studio).
Установка Team Foundation Server 2013 сама по себе тривиальна. Заранее установите SQL Server, чтобы использовать его в качестве репозитория. Отметим, что для настройки TFS нужно использовать и Web-приложение Панель управления, доступное через http://hostname:8080/tfs (по умолчанию), и Windows-приложение Administration Console. Например, из Панели управления можно раздавать доступ до коллекций, а создавать коллекции можно только в Administration Console.
Предположим, что мы работаем на Государственное Ведомство, и после совещания мы получили задачу через неделю выкатить сайт, который под нагрузкой сможет держать «всех граждан нашей страны, которые туда зайдут» и мобильное приложение.
Работа есть работа, в Project создаём следующий план:
В этом плане мы видим задачки на разработчиков, аналитиков, дизайнера, верстальщика, тестера и инженера. Задачи сбалансированы по порядку следования, не пересекаются для отдельных исполнителей, содержат в одном из случаев разрыв для эффективного распределения нагрузки.
Все специалисты полны энергии и рвутся в бой, поэтому нужно получить из этого плана список задач в TFS. В TFS предварительно должна быть создана Коллекция, в ней создан Проект (а его надо создавать в Visual Studio, я выбрал в качестве шаблона процесса MSF for Agile Software Development 2013.4).
Для настройки выгрузки в TFS, переходим в Project на вкладку Team, которая появляется после установки TFS, и выбираем командный проект:
Дальше публикуем задачи:
… и сталкиваемся с проблемой:
Ну, канешна, как же я сразу не догадался: надо ведь определить типы элементов для TFS! Чтобы это сделать, необходимо добавить столбец Work Item Type в Project, который появился там после установки TFS. Обратите внимание на то, что для правильной группировки элементов в TFS тип объемлющих задач должен быть User Story, а у содержащихся в них задач – Task.
На скриншоте видно, что я добавил не только Work Item Type, но ещё и Area Path, и Iteration Path. Эти поля также необходимы, чтобы создать задачи в TFS, они характеризуют, соответственно, модуль в разрабатываемой системе и версию.
Нужно привязать указанные ячейки по смыслу, отследив, чтобы и соответствующие ресурсы были в AD, и Area Path, и Iteration Path были созданы:
… и попробуем опубликовать данные ещё раз. Для просмотра задач необходимо также воспользоваться Visual Studio, там всё стандартно, подключаемся к Коллекции, Проекту и выполняем запрос (Query) для того, чтобы посмотреть список задач
Также можно заметить, что в столбце Work Item ID в Project появились соответствующие идентификаторы элементов, которые затем могут использоваться для синхронизации данных между Project и TFS
В столбце Длительность вместо планируемых трудозатрат появились нули. Дело в том, что у Work Item в TFS для определения длительностей задач используются другие поля: Original Estimate, Completed Work и Remaining Work. По смыслу длительности в первом приближении наиболее соответствует поле Original Estimate, которое маппится на поле Базовые трудозатраты в Project
И, раз уж мы добрались до маппинга, то есть соответствия между столбцами Project и полями TFS, в двух словах упомянем, как его можно поменять. В одной статье на MSDN описан файл маппинга полей Project, а в другой статье – описан экспорт и импорт этого файла в TFS.
А для того, чтобы разобраться с переносом длительности в трудозатраты, воспользуемся материалами ещё одной статьи с MDSN), т.к. без документации тут уже не разобраться. Зададим, как рекомендуется в этой статье, базовые настройки планировщика в Project (Файл->Параметры->Расписание)
… и определим на основе длительности задач базовые трудозатраты
В итоге колонка Базовые трудозатраты будет заполнена соответствующими значениями
А затем публикуем изменения в TFS.
Так мы и получили в MS Project диаграмму Ганта, а в TFS – набор связанных задач, к которым специалисты могут получить доступ через привычные инструменты, то есть через Visual Studio.
Все пункты наших требований выполнены? Да, в TFS встроена система контроля версий, которую можно также заменить на GIT, так что пункты 4 и 5 автоматически из списка критериев также автоматически поддерживаются в такой схеме. И всё вроде бы хорошо, если бы не
Критика – не самое приятное занятие, однако в данном случае объективности требует от нас формат статьи. Всё же это не Tutorial по Project и TFS, и мы должны рассмотреть эту связку как средство, которое действительно снижает трудозатраты при работе с планом, а для этого мы должны избежать лишних сложностей в использовании инструментов.
Рассмотрим несколько кейсов, которые возникают при реальном использовании Project и TFS.
Предположим, что в текущую итерацию в TFS добавлен баг, которого в природе не существует. Ошибки случаются, с этим ничего не поделаешь. Или баг оказался не багом, а фичей. Такого у вас не бывало? Аналитик дочитал свою постановку до конца и что-то понял, тестировщик открыл все привязанные к таску файлы, программист решил задать все вопросы, которые его давно мучали (давайте не вспоминать про TDD, пример условный).
Что делать в этом случае в нашем планировании? Баг можно спокойно закрыть в TFS, но если мы обновим изменения в Project (Refresh), то он никуда из плана не исчезнет. Вроде бы логично, сущности никуда не удаляются. А как быть с единым планом проекта? Придётся всё править руками.
Вывод. Если Work Item по ошибке добавлен в TFS, из Project удалить его в автоматическом режиме не выйдет.
Тоже из опыта… Помните Заказчика из начала статьи? На следующем совещании он сократил сроки на итерацию с двух недель до недели. Понятно, что надо идти и скорее работать, но мы по-хорошему хотим сначала актуализировать план. Зайдём и сократим итерацию в TFS. Как отразилось на тасках? Не отразилось. Таски не понимают, что они не умещаются во временные рамки итераций. Окей, майкрософт, давай загрузим изменения в Project.
И что поменялось? Ничего, Project слышал только о названиях итераций в TFS и ничего не знает о сроках.
Вывод. При изменении сроков итерации разбираться со сроками по таскам придётся в ручном режиме.
Замечу, что здесь, на Хабре-Мегамозге, есть прекрасная статья пользователя ganouver, в которой он описывает использование Project для управления проектами. В частности, там можно прочитать про балансировку плана, хитроумные тактики борьбы с Project, а в комментариях найти фразу о том, что
Помимо изменения типов Work Item, удаления лишних задач и т.п., в реальном проекте план может поменяться почти полностью, как по составу тасков в высокоуровневых задачах (стори), так и по длительности и составу итераций. Что предлагает нам Project и TFS, чтобы учесть эти изменения, морфировать таски, сбалансировать заново план, посчитать ресурсы, учитывая изменения в длительности итераций и подготовить новый план по релизам? Ничего не предлагает.
Решение от Microsoft для управления проектами и разработкой ПО в виде совместного использования продуктов Project + TFS + Visual Studio может использоваться для однократного планирования работы и плохо подходит для постоянного автоматизированного репланнинга.
Размышляя над тем, стоит ли публиковать статью с выводом о том, что рассматриваемый стек технологий Project + TFS не очень подходит для решения поставленной задачи, я решил, что отрицательный опыт – это тоже опыт, и он, по крайней мере, позволит читателям сделать свой выбор.
Итак, решать задачу полного управления разработкой на этих инструментах можно лишь при первом составлении плана и затем на основе полуавтоматизированного труда руководителя или его помощника, при этом любой репланнинг будет отнимать время на рутинные операции.
В следующих статьях рассмотрим другие наборы инструментальных средств, первыми кандидатами являются Jira и Redmine.
И, начиная с этого момента, мы уже как руководители вынуждены бороться со сложностью разработки программных проектов, сложностью их однородного понимания всеми участниками и сложностью учёта изменений, происходящих постоянно при изменениях внешней среды. Ориентируясь на пророческое утверждение Брукса о том, что серебряной пули нет, мы всё же ищем способ найти управленческую технику, увеличивающую, хотя бы и не на порядок, производительность, надёжность и простоту в разработке программного обеспечения.
Итак, каждый из руководителей знает, что такое диаграмма Ганта, и каждый пользовался MS Project. Ещё больше читателей, программистов, использует систему управления задачами. И практически все программисты-не одиночки используют систему управления исходным кодом.
Перед нами стоит вполне прагматическая задача обеспечить единый процесс разработки, когда при учёте каждого нового изменения требований можно наглядно увидеть изменение параметров проекта.
Сформулируем эту задачу на прикладном уровне. Представим проект как набор этапов, которые в свою очередь состоят из перечня высокоуровневых задач, каждая из которых включает ряд пользовательских сценариев, стори, а те – декомпозируются в таски. Мы нарочно и дальше будем использовать в статье такую смешанную терминологию, не то ГОСТ, не то Agile, так как заказчики смотрят на проект примерно на уровне детализации этапов, и им вообще не интересно знать, что такое Agile, а разработчики смотрят на задачи примерно на уровне тасков и им в свою очередь не интересно думать о ГОСТах.
Далее, мы должны добиться того, чтобы при поступлении новых данных о проекте репланнинг с учётом всей доступной информации проходил максимально быстро, и мы могли получить максимально быструю обратную связь по проекту в целом, чтобы предоставить её Заказчику (или учесть в собственных маркетинговых ожиданиях при разработке собственного продукта).
Какими инструментальными средствами должны теперь мы воспользоваться для того, чтобы достигнуть цели? Представлю следующие критерии выбора этих инструментальных средств:
1) Необходима диаграмма Ганта как визуальное средство и как инструмент для планирования этапов
2) Инструментальные средства должны позволять проводить декомпозицию высокоуровневых задач в пользовательские сценарии, а их – в таски для программистов и аналитиков
3) Инструментальные средства должны автоматизированным способом обеспечивать взаимосвязь при изменениях между задачами в высокоуровневой диаграмме Ганта и тасками. Например, если мы ошиблись с оценкой одного из тасков, и у программиста на задачу ушло времени в два раза больше, то это может привести и к увеличению продолжительности одного из высокоуровневых этапов. А поскольку мы не хотим, чтобы сроки высокоуровневого этапа были сорваны, то мы должны провести анализ критического пути, чтобы заново сбалансировать требования и ресурсы. Наши инструментальные средства, благодаря взаимосвязям между уровнями, должны помочь нам увидеть проблему с возможными срывами сроков на диаграмме Ганта
4) Желательна также возможность отслеживания связей между тасками программистов и исходным кодом в системе управления исходным кодом
5) Система управления исходным кодом в свою очередь должна поддерживать модель бранчинга, например, подойдёт связка git+gitflow
6) В системе управления задачами необходима возможность отмечать фактически назначенное время и учитывать величину остатка по времени, а также получать отчёты о ходе выполнения работ
Существует несколько вариантов выбора подобных инструментальных средств, рассмотрим три из них, которые кажутся нам наиболее подходящими:
1) MS Project + Team Foundation Server
2) Jira
3) Redmine
Jira и Redmine рассмотрим в следующих статьях, а в этой сосредоточимся на MS Project + Team Foundation Server (+ Visual Studio).
Использование MS Project и Team Foundation Server
Установка Team Foundation Server 2013 сама по себе тривиальна. Заранее установите SQL Server, чтобы использовать его в качестве репозитория. Отметим, что для настройки TFS нужно использовать и Web-приложение Панель управления, доступное через http://hostname:8080/tfs (по умолчанию), и Windows-приложение Administration Console. Например, из Панели управления можно раздавать доступ до коллекций, а создавать коллекции можно только в Administration Console.
Предположим, что мы работаем на Государственное Ведомство, и после совещания мы получили задачу через неделю выкатить сайт, который под нагрузкой сможет держать «всех граждан нашей страны, которые туда зайдут» и мобильное приложение.
Работа есть работа, в Project создаём следующий план:
В этом плане мы видим задачки на разработчиков, аналитиков, дизайнера, верстальщика, тестера и инженера. Задачи сбалансированы по порядку следования, не пересекаются для отдельных исполнителей, содержат в одном из случаев разрыв для эффективного распределения нагрузки.
Все специалисты полны энергии и рвутся в бой, поэтому нужно получить из этого плана список задач в TFS. В TFS предварительно должна быть создана Коллекция, в ней создан Проект (а его надо создавать в Visual Studio, я выбрал в качестве шаблона процесса MSF for Agile Software Development 2013.4).
Для настройки выгрузки в TFS, переходим в Project на вкладку Team, которая появляется после установки TFS, и выбираем командный проект:
Дальше публикуем задачи:
… и сталкиваемся с проблемой:
Ну, канешна, как же я сразу не догадался: надо ведь определить типы элементов для TFS! Чтобы это сделать, необходимо добавить столбец Work Item Type в Project, который появился там после установки TFS. Обратите внимание на то, что для правильной группировки элементов в TFS тип объемлющих задач должен быть User Story, а у содержащихся в них задач – Task.
На скриншоте видно, что я добавил не только Work Item Type, но ещё и Area Path, и Iteration Path. Эти поля также необходимы, чтобы создать задачи в TFS, они характеризуют, соответственно, модуль в разрабатываемой системе и версию.
Нужно привязать указанные ячейки по смыслу, отследив, чтобы и соответствующие ресурсы были в AD, и Area Path, и Iteration Path были созданы:
… и попробуем опубликовать данные ещё раз. Для просмотра задач необходимо также воспользоваться Visual Studio, там всё стандартно, подключаемся к Коллекции, Проекту и выполняем запрос (Query) для того, чтобы посмотреть список задач
Также можно заметить, что в столбце Work Item ID в Project появились соответствующие идентификаторы элементов, которые затем могут использоваться для синхронизации данных между Project и TFS
В столбце Длительность вместо планируемых трудозатрат появились нули. Дело в том, что у Work Item в TFS для определения длительностей задач используются другие поля: Original Estimate, Completed Work и Remaining Work. По смыслу длительности в первом приближении наиболее соответствует поле Original Estimate, которое маппится на поле Базовые трудозатраты в Project
И, раз уж мы добрались до маппинга, то есть соответствия между столбцами Project и полями TFS, в двух словах упомянем, как его можно поменять. В одной статье на MSDN описан файл маппинга полей Project, а в другой статье – описан экспорт и импорт этого файла в TFS.
А для того, чтобы разобраться с переносом длительности в трудозатраты, воспользуемся материалами ещё одной статьи с MDSN), т.к. без документации тут уже не разобраться. Зададим, как рекомендуется в этой статье, базовые настройки планировщика в Project (Файл->Параметры->Расписание)
… и определим на основе длительности задач базовые трудозатраты
В итоге колонка Базовые трудозатраты будет заполнена соответствующими значениями
А затем публикуем изменения в TFS.
Так мы и получили в MS Project диаграмму Ганта, а в TFS – набор связанных задач, к которым специалисты могут получить доступ через привычные инструменты, то есть через Visual Studio.
Все пункты наших требований выполнены? Да, в TFS встроена система контроля версий, которую можно также заменить на GIT, так что пункты 4 и 5 автоматически из списка критериев также автоматически поддерживаются в такой схеме. И всё вроде бы хорошо, если бы не
Бочка дёгтя, или Microsoft, ну, как же так?
Критика – не самое приятное занятие, однако в данном случае объективности требует от нас формат статьи. Всё же это не Tutorial по Project и TFS, и мы должны рассмотреть эту связку как средство, которое действительно снижает трудозатраты при работе с планом, а для этого мы должны избежать лишних сложностей в использовании инструментов.
Рассмотрим несколько кейсов, которые возникают при реальном использовании Project и TFS.
Кейс 1. По ошибке добавлен несуществующий баг
Предположим, что в текущую итерацию в TFS добавлен баг, которого в природе не существует. Ошибки случаются, с этим ничего не поделаешь. Или баг оказался не багом, а фичей. Такого у вас не бывало? Аналитик дочитал свою постановку до конца и что-то понял, тестировщик открыл все привязанные к таску файлы, программист решил задать все вопросы, которые его давно мучали (давайте не вспоминать про TDD, пример условный).
Что делать в этом случае в нашем планировании? Баг можно спокойно закрыть в TFS, но если мы обновим изменения в Project (Refresh), то он никуда из плана не исчезнет. Вроде бы логично, сущности никуда не удаляются. А как быть с единым планом проекта? Придётся всё править руками.
Вывод. Если Work Item по ошибке добавлен в TFS, из Project удалить его в автоматическом режиме не выйдет.
Кейс 2. Поменялась длительность итерации
Тоже из опыта… Помните Заказчика из начала статьи? На следующем совещании он сократил сроки на итерацию с двух недель до недели. Понятно, что надо идти и скорее работать, но мы по-хорошему хотим сначала актуализировать план. Зайдём и сократим итерацию в TFS. Как отразилось на тасках? Не отразилось. Таски не понимают, что они не умещаются во временные рамки итераций. Окей, майкрософт, давай загрузим изменения в Project.
И что поменялось? Ничего, Project слышал только о названиях итераций в TFS и ничего не знает о сроках.
Вывод. При изменении сроков итерации разбираться со сроками по таскам придётся в ручном режиме.
Кейс 3. Обобщение проблемы: репланнинг
Замечу, что здесь, на Хабре-Мегамозге, есть прекрасная статья пользователя ganouver, в которой он описывает использование Project для управления проектами. В частности, там можно прочитать про балансировку плана, хитроумные тактики борьбы с Project, а в комментариях найти фразу о том, что
… связка TFS – Project работает как-то топорно и неудобно.И ещё в его статье встречается высказывание, которое так же хорошо описывает управление разработкой, как Том Кайт описывает СУБД Oracle:
Главное – это регулярное обновление плана.
Помимо изменения типов Work Item, удаления лишних задач и т.п., в реальном проекте план может поменяться почти полностью, как по составу тасков в высокоуровневых задачах (стори), так и по длительности и составу итераций. Что предлагает нам Project и TFS, чтобы учесть эти изменения, морфировать таски, сбалансировать заново план, посчитать ресурсы, учитывая изменения в длительности итераций и подготовить новый план по релизам? Ничего не предлагает.
Заключение
Решение от Microsoft для управления проектами и разработкой ПО в виде совместного использования продуктов Project + TFS + Visual Studio может использоваться для однократного планирования работы и плохо подходит для постоянного автоматизированного репланнинга.
Размышляя над тем, стоит ли публиковать статью с выводом о том, что рассматриваемый стек технологий Project + TFS не очень подходит для решения поставленной задачи, я решил, что отрицательный опыт – это тоже опыт, и он, по крайней мере, позволит читателям сделать свой выбор.
Итак, решать задачу полного управления разработкой на этих инструментах можно лишь при первом составлении плана и затем на основе полуавтоматизированного труда руководителя или его помощника, при этом любой репланнинг будет отнимать время на рутинные операции.
В следующих статьях рассмотрим другие наборы инструментальных средств, первыми кандидатами являются Jira и Redmine.
