Team Foundation Server как и любой сложный инструмент требует некоторых организационных подходов в эксплуатации. Тем более что создавался он с целью предоставить свободу выбора команды, или как выразился Брайан Харри в одной из своих заметок, внедрить «Ваш процесс, Наш процесс, или Никакого процесса». Отчасти эта свобода может сыграть нехорошую шутку, когда команде кажется что TFS используется только в очень небольшом спектре своих возможностей. В данной заметке будет приведен ряд рекомендаций по развертыванию жизнеспособной среды ALM.
Определяемся с целями
Основное «кредо» TFS – это повышение предсказуемости во всех организационных процессах связанных с разработкой и частично эксплуатацией программного обеспечения. Предсказуемость в данном контексте означает буквально одно – вы в любой момент, воспользовавшись средствами TFS, можете посмотреть как у вас идут дела и сделать выводы. Сколько у вас есть ошибок, какие требования еще не закрыты, и так далее. Достоверность этой информации напрямую зависит от исходных данных — чем больше таких данных будет собрано TFS, тем качественнее вы сможете принимать последующие решения. Очень правильно представлять TFS как базу данных, в которую непрерывно стекается информация от различных источников. Где то в автоматическом режиме, где то требуя чтобы люди внесли эту информацию сами. При этом следует понимать, что чем больше информации вы соберете, тем больше в ней будет синергии и взаимосвязей.
Из этого следует, что основным фактором успешности внедрения TFS являются в первую очередь работоспособные отчеты на базе Reporting Services и OLAP, их информационная наполненность и умение делать на базе этих отчетов выводы с последующими действиями. Другими словами, если вы не используете Reporting Services, OLAP кубы с помощью Excel и не разбираетесь в перечне показателей, которые предоставляет TFS для анализа, то вы забиваете гвозди микроскопом.
Повышаем качество отчетов
Исходя из поставленной выше цели можно более детально разобраться как эксплуатировать компоненты TFS более интенсивно, и какие шаги необходимо предпринять чтобы в дальнейшем уровень этой эксплуатации повышался.
Данные которые могут фигурировать в отчетах можно сгруппировать в перечень, который и может представлять этапы постепенного улучшения уровня эксплуатации TFS:
Совсем не обязательно стремиться внедрить все эти компоненты и получить полную информацию в отчетах сразу. Вполне возможны поэтапные цикличные изменения в конфигурации ваших проектов и плавные организационные изменения. Не стоит бояться ошибок, как правило, они связаны только лишь с отсутствием практического опыта работы с TFS и быстро наверстываются.
Постепенное, итеративное включение в ваш ALM процесс возможностей TFS может быть разделен на небольшие циклы (нечто вроде «Кайдзен»), в каждом из которых вы постепенно подключаете функции и проверяете их работоспособность с помощью отчетов:
Неделя 1:
Неделя 2:
Неделя 3:
Тем самым на каждом коротком этапе достигается определенный результат, который очевиден для команды.
TFS это гибкое и универсальное средство. В комплект поставки входит два процессных шаблона (Agile и CMMI) помимо этого можно устанавливать другие шаблоны процессов. У многих команд появляется соблазн доработок в этих шаблонах, так как, по их мнению, реализация в TFS не соответствует принятым в этой организации практикам. Это вполне допустимая ситуация, но не стоит вдаваться в крайности, например, полностью переделывая состояния и основания переходов у рабочих элементов. Как правило, это приводит к очень печальным последствиям если у вас вообще не было опыта серьезной работы с системами автоматизации ALM.
Вообще же, очень может быть что практики, которые вы используете, вполне ложатся в текущий вариант реализации процессов и у вас просто какие либо терминологические разночтения. В любом случае попробуйте оценить планируемые изменения в виде затрат: что проще, договориться о новой организации работы на совещании или внести изменения в TFS.
Автоматизация ALM может быть не такой уж сложной задачей, если использовать подход постепенных улучшений. Благодаря тому, что TFS это интегрированный комплекс, который собирает информацию от различных компонент. Чем больше данных удается собрать, тем более эффективно можно понимать текущую ситуацию на проектах, и значит более эффективно управлять процессами разработки программного обеспечения. Более подробно о Application Lifecycle Management можно узнать из документации MSDN и обсудить на форуме.
Определяемся с целями
Основное «кредо» TFS – это повышение предсказуемости во всех организационных процессах связанных с разработкой и частично эксплуатацией программного обеспечения. Предсказуемость в данном контексте означает буквально одно – вы в любой момент, воспользовавшись средствами TFS, можете посмотреть как у вас идут дела и сделать выводы. Сколько у вас есть ошибок, какие требования еще не закрыты, и так далее. Достоверность этой информации напрямую зависит от исходных данных — чем больше таких данных будет собрано TFS, тем качественнее вы сможете принимать последующие решения. Очень правильно представлять TFS как базу данных, в которую непрерывно стекается информация от различных источников. Где то в автоматическом режиме, где то требуя чтобы люди внесли эту информацию сами. При этом следует понимать, что чем больше информации вы соберете, тем больше в ней будет синергии и взаимосвязей.Из этого следует, что основным фактором успешности внедрения TFS являются в первую очередь работоспособные отчеты на базе Reporting Services и OLAP, их информационная наполненность и умение делать на базе этих отчетов выводы с последующими действиями. Другими словами, если вы не используете Reporting Services, OLAP кубы с помощью Excel и не разбираетесь в перечне показателей, которые предоставляет TFS для анализа, то вы забиваете гвозди микроскопом.
Повышаем качество отчетов
Исходя из поставленной выше цели можно более детально разобраться как эксплуатировать компоненты TFS более интенсивно, и какие шаги необходимо предпринять чтобы в дальнейшем уровень этой эксплуатации повышался.
Данные которые могут фигурировать в отчетах можно сгруппировать в перечень, который и может представлять этапы постепенного улучшения уровня эксплуатации TFS:
- Информация обо всех рабочих элементах, которые фигурируют на ваших проектах. Эти данные включают в себя информацию о задачах, требованиях, ошибках и TFS хранит полную историю изменений полей этих рабочих элементов. На основе этой информации вы можете понять, какие текущие задачи стоят перед вами. На этом этапе вы будете способны отслеживать время и планировать загрузку команды. Не стоит забывать что качество этих данных напрямую зависит от людей. И на этом этапе обязательно необходимо обучение работе с запросами в TFS, пояснение механизма перехода состояний рабочих элементов, использование интегрированных средств, например таких как Excel.
- Информация об изменениях исходных файлов проектов. Все добавления, изменения, удаления строчек исходного кода. Кто, когда и на каком основании сделал ту или иную операцию. Важно отметить «на основании» так как TFS позволяет увязать (ассоциировать) изменения в исходных текстах с ошибками, задачами и другими рабочими элементами. Уже на этом этапе вы сможете видеть сколько строк кода потребовала реализация того или иного требования или фиксация ошибки. Здесь так же важно отметить участие человека в формировании этой информации, пояснить программистам важность ассоциаций изменений в коде с задачами которые они выполняют.
- Информация о сборках. TFS включает в себя очень гибкую среду автоматической сборки проектов. Как только вы настроите автоматическую сборку, произойдет увязка информации связанной с рабочими элементами и изменениями в коде, которые соответственно будут давать вам возможность понимать уровень и масштаб изменений в том или ином билде. На этом этапе включаются механизмы непрерывной интеграции (“Continuous Integration”) которые позволяют на более качественном уровне понимать прогресс проекта, делать прогнозы долгосрочного характера.
- Информация о тестах и покрытии кода тестами. Тестирование – очень важный механизм обеспечения качества вашего продукта. Тесты могут быть увязаны с требованиями, изменениями в коде и сборками. Как только будут включены эти механизмы, вы сразу же получите возможность оценивать дееспособность вашего текущего билда и не давать его в ручное тестирование, так как он не прошел требуемых автоматических тестов, тем самым снизив нагрузку с тестеров. Помимо этого вы будете получать информацию об уровне качества тестирования (благодаря Code Coverage).
Совсем не обязательно стремиться внедрить все эти компоненты и получить полную информацию в отчетах сразу. Вполне возможны поэтапные цикличные изменения в конфигурации ваших проектов и плавные организационные изменения. Не стоит бояться ошибок, как правило, они связаны только лишь с отсутствием практического опыта работы с TFS и быстро наверстываются.
Пример плана по улучшению уровня эксплуатации TFS
Постепенное, итеративное включение в ваш ALM процесс возможностей TFS может быть разделен на небольшие циклы (нечто вроде «Кайдзен»), в каждом из которых вы постепенно подключаете функции и проверяете их работоспособность с помощью отчетов:
Неделя 1:
- Провести получасовой семинар по состояниям рабочих элементов и работе с запросами
- Разработать перечень областей проекта (Area)
- Внести в регламент работы с задачами обязательное заполнение поля Area
- Создать первый автоматический билд системы
- Проверить входит ли в отчет информация о изменениях в билде в разрезе выполненных задач
Неделя 2:
- Провести получасовой семинар по привязке рабочих элементов (Master/Child)
- Разработать перечень итераций проекта (Iterations)
- Внести в регламент работы с задачами подчиненными требованиям обязательное заполнение поля планируемых и затраченных часов
- Внести в регламент обязательную ассоциацию задач и требований с изменяемым кодом
- Проверить входит ли в отчет информация об объемах изменения кода в разрезе требований. Вводим KPI – количество изменений в коде без ассоциаций и требуем снижения этого показателя от команды.
Неделя 3:
- Провести получасовой семинар по концепции Code Coverage
- Сформировать первичный список тестов, подготовить 2-3 теста
- Внести в регламент работ с требованиями обязательное создание ручного теста к этому требованию
- Создать новое определение билда с включенной подсистемой тестов
- Проверить входит ли в отчет информация об уровне прохождения тестов и проценте покрытия кодов
Тем самым на каждом коротком этапе достигается определенный результат, который очевиден для команды.
Изменения в процессах и конфигурация TFS
TFS это гибкое и универсальное средство. В комплект поставки входит два процессных шаблона (Agile и CMMI) помимо этого можно устанавливать другие шаблоны процессов. У многих команд появляется соблазн доработок в этих шаблонах, так как, по их мнению, реализация в TFS не соответствует принятым в этой организации практикам. Это вполне допустимая ситуация, но не стоит вдаваться в крайности, например, полностью переделывая состояния и основания переходов у рабочих элементов. Как правило, это приводит к очень печальным последствиям если у вас вообще не было опыта серьезной работы с системами автоматизации ALM.
Вообще же, очень может быть что практики, которые вы используете, вполне ложатся в текущий вариант реализации процессов и у вас просто какие либо терминологические разночтения. В любом случае попробуйте оценить планируемые изменения в виде затрат: что проще, договориться о новой организации работы на совещании или внести изменения в TFS.
Заключение
Автоматизация ALM может быть не такой уж сложной задачей, если использовать подход постепенных улучшений. Благодаря тому, что TFS это интегрированный комплекс, который собирает информацию от различных компонент. Чем больше данных удается собрать, тем более эффективно можно понимать текущую ситуацию на проектах, и значит более эффективно управлять процессами разработки программного обеспечения. Более подробно о Application Lifecycle Management можно узнать из документации MSDN и обсудить на форуме.
