вторник, 3 августа 2010 г.

Scrum в TrackStudio

Наши пользователи спрашивали, есть ли в TrackStudio возможность использовать SCRUM как методологию разработки. Вот в Jira есть GreenHopper, а у нас, мол, ничего нет. А я как раз давно хотел, да и TrackStudio 4.0 вышла, нужны примеры и конфигураций, и скриптов. Вооружился толковой книжкой про SCRUM на русском языке, и приступил к созданию новой конфигурации.

GreenHopper я видел. И атлассиановскую The Wall of Death. И еще тогда не понимал, в чем прикол разрабатывать ПО и пользоваться инструментами уровня детского сада: ножницы, клей, фломастер и стена. Да и офисы не у всех просторные. У некоторых офисы вообще дома, а работать надо.
В Scrum ведь главное - не стена, а общение в команде. А для общения есть куча всевозможного софта и социальных сетей.

Своей задачей я видел реализацию в TrackStudio технической стороны SCRUM: ведение бэклога, планирование спринтов и анализ их хода.
С ведением бэклогов никаких проблем: сколько хочешь категорий, процессы любой сложности и полная иерархия задач. Плюс фильтры.
Роли в методологии четко прописаны, с ними тоже проблем нет: Product Owner, Scrum Master и Team для команды (конечно один и тот же человек может быть и Scrum Master и Team - отдельные учетные записи создавать не нужно).
Product Owner составляет истории, указывает их важность и как продемонстрировать результат (это могут так же и участники команды редактировать). Это реализуется встроенными полями и двумя дополнительными: Integer для важности и Text для описания способа демонстрации.

Дальше по сценарию участники команды должны оценить трудоемкость каждой истории. Нам нужно где-то хранить эти оценки, как-то их систематизировать и как-то показывать пользователю, оценил он уже историю или нет.
Хранить оценки удобнее всего в поле budget: оно есть и у задачи, и у операции, так что история оценок реализуется сама собой. Для систематизации нужно что-то наглядное: любимый поклонниками Jira dashboard.
У нас есть дополнительные поля типа Text, в которых может отображаться HTML, плюс любое поле можно сделать вычисляемым. Получается такой мини-dashboard, в котором можно что угодно выводить.

Дальше по сценарию Scrum Master создает спринт и переносит в него задачи. В некоторых красивых приложениях это сделано через drag'n'drop. Передо мной задачи сделать красиво не стояло. Главное - сделать, чтобы работало и было удобно пользоваться.
Задачи в TrackStudio переносятся методом cut/paste: вы выбираете несколько задач (можно на разных страницах списка), жмете кнопку "Вырезать", переходите через дерево или по списку на нужную задачу и там жмете "Вставить". Достаточно просто. Но т.к. нам нужно будет не только вносить задачи в спринт, но и убирать их оттуда, и переносить в другой спринт, удобнее будет, если это будет делаться изнутри задачи, при ее редактировании или выполнении операции. А это можно сделать с помощью триггеров.
Но как при этом указать, в какой спринт переносить? Нужен список существующих спринтов. А это уже довольно редко используемый lookup-скрипт: он выводит поле со списком значений и пользователь может выбрать нужное. Почему это называется lookup - не знаю.

Итак, как перенести истории в спринт мы решили. Но какие именно истории переносить? Тут все просто: наиболее важные - в фильтре "Истории" делаем сортировку по важности. И переносим в спринт уже оцененные разработчиками истории. Переносим "на глазок", все равно оценки еще изменятся и мы либо добавим историй в спринт, либо уберем часть.

Для планирования спринта нам также понадобится "dashboard", похожий на тот, что в историях. В нем нам нужно подсчитывать общий бюджет историй в спринте и сравнивать его с бюджетом спринта. Кроме того, нам понадобится знать кое-то о нашей команде: ни для кого не секрет, что разные люди работают по-разному. Кто-то бабахает по 80 часов в неделю, а у кого-то семья. А кто-то работает на трех работах. А часть тестировщиков вообще работает по 10 часов в неделю. И это нужно учитывать при планировании.
В разных книжках и на разных сайтах предлагают вводить какие-то коэффициенты, "ненастоящие часы" и т.п. Мы пойдем другим путем. Мы сделаем для участников команды специальное поле, в которое запишем, сколько же часов в неделю они будут работать. Это поле мы сможем потом изменять, если кто-то, например, заболеет.

Итак, у нас есть спринт с оцененными историями, команда со своими заморочками, отраженными в поле "Степень занятости" и Scrum Master. В нашем dashboard мы все соединим, чтобы мастер понял, как распределить задачи по команде. Он будет видеть, насколько загружен каждый разработчик и во сколько часов он оценил каждую конкретную историю (или вообще не оценил). Разумно предположить, что тот, кто указал наименьшую оценку либо хорошо понял, что делать, либо очень хочет получить именно эту историю.

Допустим, Scrum Master распределил задачи, все договорились об оценках и т.п. Если спринт вписывается в бюджет - можно его запускать, если не вписывается - предстоит еще один раунд торговли.

После того, как спринт начат, и Scrum Master и участники команды захотят увидеть burndown chart. Но, увы, пока не увидят. Вместо burndown-диаграммы они увидят индикатор, показывающий, опережает команда план или опаздывает (и на сколько часов).

Вот, в общем, и все. Дальше команда реализует истории, подходит время демонстрации, все показывается Product Owner'у - все ровно по методике.


Руководство по эксплуатации и сама конфигурация с исходниками (документированными!) прилагается

Комментариев нет:

Отправить комментарий