Управление разработкой в проектах по созданию сложных программных систем. Опыт использования MS Project и Team Foundation Server

    Многие программисты по мере своего развития выбирают для себя стезю управления разработкой, с сожалением ограничивая себя в творческом процессе изучения новых языков программирования и технологий.

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

    Итак, каждый из руководителей знает, что такое диаграмма Ганта, и каждый пользовался 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.
    ООО «ЦИТ» 51,52
    ИКТ-решения и сервисы для органов власти и бизнеса
    Поделиться публикацией
    Комментарии 10
    • +1
      Вот не поверите, только сегодня размышлял о том, что пора уже написать о том, что нужно отделять мух от котлет управление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.
      • +1
        Хорошо, но тогда надо организовать понятный интерфейс между этими слоями. А в условиях, когда все слишком заняты…
        • 0
          По моему опыту, сложности возникают всегда при попытке синхронизировать изменения между средством управления задачами (TFS, Jira, Redmine, Trac и т.п.) и инструментом управления проектом (как правило — Project, но может быть и Excel или даже бумажный лист). Ключевое слово — «приходится». Все эти сложности как бы намекают, что копаем не там где надо. И, хотя менеджерам, которые выросли из программистов (сам таким был) такая функция кажется очевидной, на самом деле ниоткуда не следует, что управление проектом и управление задачами работают в одних и тех же терминах.
          Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.

          Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
          • 0
            Ну, если средств нет, это ещё не означает, что это именно потому, что их в принципе быть не может. Того же Project'а и Excel'а тоже когда-то не было. Или более подходящий пример: не так давно фейсбука не было, а люди как-то между собой общались. Может быть, стоит отказаться от него сейчас? Мне кажется, нам, технарям вредно думать в направлении, что что-то сделать нельзя. Целесообразность создания средства может быть под вопросом. Но мне не так много не хватило в связке Project + TFS.

            Согласен с тем, что высокоуровневые проектные задачи и таски — это разные вещи. Не уверен, что это подчёркнуто в статье, но я это имел в виду, когда её писал.

            Борис, почему Вы считаете, что автоматическая синхронизация, хотя бы с вопросами пользователю (менеджеру) вредна? Я не вижу серьёзных аргументов в защиту этого тезиса. Это вот разные типы задач? Если внимательно посмотреть на первый скриншот, то план работ включает у меня и таски для дизайнеров, и для аналитиков. Что же касается, к примеру, написания документации, то можно как вести учёт работы по этой проектной задаче в системе контроля тасков, так и не вести.

            Мне не нравится, что в этой совместной работе менеджера проекта, тимлида и всех прочих лиц, как сейчас почти везде и происходит, появляются соглашения, суть которых может быть не зафиксирована в совместном опубликованном плане работ. Я встречал ситуацию, когда менеджер проектов и аналитик пошли и договорились, что они понимают под высокоуровневой задачей, и при этом никому не сказали, что конкретно нужно сделать в определённой итерации в определённом таске. Конечно, Вы сейчас скажете, что можно придумать управленческую технику, должны быть протоколы и т.п., но зачем заставлять себя придумывать 10 способов учёта, если можно было бы воспользоваться одной системой?

            Проблема в том, что вроде бы такой системы не существует. Почему бы сообществу не застартапить такой проект? Чем он хуже других отчаянных попыток автоматизировать любую область человеческой деятельности?

            Есть контр-аргументы создания такой системы. Проблемы делятся на две группы:
            1) Проектные подходы различаются, поэтому сделать систему, которая учитывает все нюансы, довольно трудозатратно
            2) Люди — это не ресурсы, а именно люди — и им тяжело выдерживать до конца тот цикл, в который их стараются погрузить

            На мой взгляд, совершенно очевидно то, что машину несложно научить исправлять ошибки планирования вида «таск X стала в два раза дольше, поэтому есть проблемы с закрытием итерации => существует риск закрытия этапа». Но программисты очень мало инвестируют в технологии для самих себя. С их точки зрения это очень длинные инвестиции, а текущая разработка принесёт прибыль здесь и сейчас. Именно по этой причине в статье я и обратился с критикой к гиганту — Microsoft — ведь у них есть система для управления проектами и система для управления разработкой. Microsoft до сих пор качественно их не объединила, но при этом затраты на «рутинный труд менеджеров» у них самих при выпуске продуктов должны быть грандиозными. Те же новости о срывах сроков производства Windows и Office появляются регулярно.
            • 0
              А вот тут ответ очень простой. Средства вполне могут быть. Но средства сами по себе никакую проблему не решают. Проблему (теоретически) смогут решить люди, которые эти средства будут использовать. Чтобы проблемы решались, эти люди должны уметь и понимать довольно много разных полезных вещей и еще больше делать. Чтобы был заметный эффект, потребуется не только система, которая что-то там умеет делать, но и реальное изменение в подходах к работе. Эти изменения коснутся не только менеджеров, но и программистов и руководителей. Людей способных и желающих провернуть подобные изменения в своих организациях слишком мало, чтобы сформировать рынок, который бы окупил создание подобной системы.
              Microsoft при первом релизе TFS запилили примитивную интеграцию TFS с Project, этим мало кто воспользовался — они и не стали развивать. Ничего личного. Просто бизнес.
              • 0
                И еще, забыл написать почему вредно :)
                Вредно, если кратко — потому что борьба с ветряными мельницами непродуктивна. Если все засинхронизировать, все планы будут прозрачно перетекать и обновляться, то возникнет ложное ощущение того, что все под контролем. А в управлении проектом, повторюсь, задачи разработки — они даже не на втором плане по важности. Отсутствие такой прозрачной автоматизации в мелочах порождает необходимость немножко поработать головой и руками. Мозг не умеет работать с большим количеством мелких артефактов, приходится их обобщать. А это помогает расширить угол зрения.
                • 0
                  С этим согласен. Вопрос — в проработке взаимосвязи. Можно и нужно сделать лучше.
          • 0
            Давно уже об этом (здесь и не только) твержу :)

            И да, статья весьма хороша.
            Ничего не предлагает.

            Всю жизнь в таких ситуациях выкручивался базовыми планами.
            • 0
              Спасибо! :)
              Не совсем, правда, понял, как вы выкручивались базовыми планами… уточните?
          • 0
            Хорошо бы еще добавить, сколько стоит то или иное решение в пересчете на одно рабочее место (или на группу из N).
            И кстати, есть еще IBM Rational Team Concert.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое