• Статья

Разработка в облаке (TFS in da cloud)

Удачного и полезного времяпрепровождения всем читателям этой статьи. Очень давно не было у меня времени писать в блоге, но прихожу к выводу, что выделять его все-таки необходимо. Тем более что жизнь начинает налаживаться в плане быта.

Одной из самых актуальных рабочих тем сегодня является ALM (Application Lifecycle Management, управление жизненным циклом ПО) – это моя основная зона ответственности на новой работе. ALM – интересная наука, ей посвящены толстые тома от умных теоретиков и заслуженных практиков и не мало их пришлось мне прочитать при подготовке к диссертации. Но идти по моим стопам и читать их все (ИМХО) не нужно большинству. Большинству нужны реальные примеры, практики и инструменты помогающие создавать и сопровождать ПО быстрее, проще и качественнее. Постараюсь следовать этой мысли и меньше теоретизировать, а если уже говорить о теории, то с картинками и попроще. Кстати вот картинка:

Так выглядит идеальный жизненный цикл с точки зрения апологетов Майкрософт сегодня. Обратите внимание насколько эта модель красивее классических моделей преподаваемых в университетах:

Хотя, если серьезно, модель, которую сейчас часто показывают на слайдах евангелисты, говоря об ALM, вовсе не нова – это обычная итеративная модель базирующаяся на понятиях из методологии SCRUM - она просто рассматривает ЖЦ ПО на самом общем уровне. И вот что получается:

  1. В начале появляется Product Manager и доказывает всем стейкхолдерам, что нужно написать ПО. Совместно они формируют и утверждают небольшой (страниц на 10) документ называемый Устав проекта (или Видение проекта, кому как приятнее). В нем отражаются основные цели проекта (очень желательно SMART), категории пользователей, автоматизируемые процессы, главные фичи будущего продукта, позиционирование на рынке, бизнес-модель.
  2. Далее все тот же Product Manager начинает бурную деятельность по формированию Product Backlog-а перечня функциональных возможностей продукта описанных кратко, но четко, желательно в виде сценариев работы пользователя с системой, соблюдая правила однозначности, непротиворечивости и полноты. Тут книга Карла Вигерса ему в помощь.
  3. Пополнение Backlog-а процесс постоянный, ждать его завершения бесполезно, поэтому как только появляются описания каких-то сценариев работы системы запускается спринт. В начале спринта project manager и архитектор (а в случае эталонного agile вся команда разработчиков коллегиально) формируют перечень задач необходимых для реализации наиболее приоритетных требований в backlog-е. Для каждой задаче проставляется оценка трудозатрат на ее реализацию.
  4. Далее стартует спринт. Каждый разработчик берет задачу, реализует ее, тестирует и берет новую задачу. Тут возможны разночтения (даже в рамках гибких методологий). Кто-то за индивидуальную разработку, кто-то за парное программирование. Кто-то практикует обязательные ревью кода.
  5. Важно, что спринт обязательно завершается по истечении заранее определенного времени (две недели, например). После этого подводится итог. Нереализованные задачи переносятся на следующий спринт, добавляются новые задачи исходя из наверняка изменившегося за последнее время содержимого backlog-а и найденных на текущий момент багов. И процесс повторяется. Повторяется до тех пор пока не получится продукт, удовлетворяющий хотя бы части целей в Уставе и готовый по мнению Product Manager-а к передачи в эксплуатацию.
  6. Далее запускается процесс эксплуатации. Он тоже не такой уж и простой: нужно сформировать перечень необходимых действий по работе с продуктом (которые должны попасть в Operations Backlog), развернуть и сделать доступным продукт для пользователей, при необходимости обучить их.
  7. И мониторить, мониторить, мониторить ситуацию, выявляя проблемные места, ошибки, отказы системы. Получать и регистрировать отзывы и пожелания пользователей. Обычно этим занимается техподдержка.
  8. Периодически вся накопленная в процессе эксплуатации информация в переработанном виде сгружается в голову Product Manager-у. И он снова начинает порождать и изменять требования, замыкая круг.

Не следует думать, что разработчики отдыхают пока идет эксплуатация продукта. Обычно это совершенно не так – они уже делают следующую версию, в то время как product manager думает еще на шаг вперед. Работа непрерывно занимает всех участников проекта, пока проект не стабилизируется и полностью удовлетворит заказчика (что вряд ли) или не умрет за ненадобностью.

Вот такая была теория, а теперь практика. У нас в компании (ООО «Агент Плюс») в качестве основного средства для ALM используется Team Foundation Server 2010 – он достался нам бесплатно, как золотым партнерам Microsoft и является лидером в сфере программного обеспечения подобного класса. А вот в своих домашних проектах я до сих пор использовал бесплатные средства, которые предоставлял bitbucket.org. От них оставалось ощущение «чего-то не того», но пользоваться было можно.

И вот два месяца назад все изменилось. Мне достался инвайт на тестирование облачного TFS. Краткий результат можно сформулировать так: я очень не хочу обратно на bitbucket.

Облачный TFS – это версия TFS vNext (2011) размещенная в Windows Azure. Это сразу делает его доступным массе небольших команд, не обладающих необходимой инфраструктурой для развертывания полноценной среды командной разработки. Конечно можно утверждать что TFS 2010 доступен для установки и в небольших командах на компьютер пользователя работающий под управлением Windows 7, но живых людей использующих такой сценарий немного по крайней мере в России. Все-таки TFS - это серверное.

Сразу скажу, TFS vNext мне нравится гораздо сильнее, чем TFS 2010. Он стал сильно проще, чище, понятнее и самое главное теперь он наталкивает команду на правильное использование своих возможностей. Плюс шаблон по умолчанию для TFS теперь – это легковесный и гибкий SCRUM, а не MSF for CMMI, который все-таки в большинстве случаев излишне сложен. Посмотрите, как выглядит краткая информация о проекте: и текущее состояние ясно и прогресс. Сразу можно оформить новое требование или баг.

В версии TFS 2010 наши Product Manager-ы и тестировщики для работы с требованиями и багами наравне с программистами использовали интерфейс Visual Studio. Web-интерфейс, основанный на возможностях WSS 3.0, вообще никак не привлекал, был какой-то неповоротливый, некрасивый, даже слегка непредсказуемый. Сейчас все с точностью до наоборот. Простота внесения бага или требования в backlog просто удивляет – есть текстовое поле и кнопка «Добавить».

Далее элементы backlog-а можно приоритезировать и детализировать, назначать итерацию для исполнения, выставлять статусы и первоначальные оценки трудозатрат – делать это тоже удобнее в web-интерфейсе.

Product manager-ы не единственные счастливые пользователи нового web UI TFS. Программисты и project manager-ы наконец получили из-коробки то о чем давно мечтали – доску с задачами-стикерами. Можно рассматривать ее в двух вариантах: распределение задач по требованиям и распределения задач по исполнителям. Задачи можно добавлять «не отходя от кассы» прямо на доску. Менять статус задач можно просто перетаскивая их прямо в веб-интерфейсе.

Ну и конечно ядром TFS остается функциональность контроля версий исходного кода. Работа из Visual Studio не сильно отличается от предыдущих версий. Но просматривать файлы из выбранной ревизии опять-таки легко и просто можно прямо с web-консоли.

Как видно из этого очень уж беглого обзора возможностей функциональность TFS растет от версии к версии и сейчас покрывает все левую часть модели приведенной в начале статьи. Если вам посчастливится как мне получить приглашение на использование облачного TFS – попробуйте вести какой-нибудь из своих проектов там. Вам должно понравиться. Ну и не забывайте все что есть в облаке будет доступно и в «оффлайне». Именно такой TFS будет ждать нас в наступающем 2012.

Автор: Александр Морозов