Мы, как и многие-многие команды, используем TFS для организации командной работы. Штука-то удобная. Но речь не об этом. А о том, что проект в TFS предполагает использование какой-либо методологии. Чаще всего это MS Agile, реже люди используют CMMI (эти два типа доступны в TFS сразу после установки), реже люди устанавливают и используют что-то свое.
Опять же, чаще всего выбор какой-либо из двух этих методологий (CMMI или Agile) производится неосознанно и только лишь потому, что нужно же что-то выбрать, иначе проект создать не получится. Поэтому часто бывает так, что следование методологии заканчивается на требовании каждый checkin привязывать к воркайтему. Получается так потому, что обе эти методологии, если ими пользоваться “как положено”, достаточно затратны, сами эти методологии недосточно “прозрачны” и, как следствие, отдача от них, в общем-то не слишком и велика.
Затратны потому, что слишком велико количество ролей в команде, слишком формализованы их взаимоотношения, на поддержание “курса” требуется ощутимое время.
Непрозрачны потому, что, с точки зрения разработчика плюсов практически не видно, его лишь заставляют следовать определенному набору правил, а почему и зачем..
Со стороны менеджера (того, который настоящий менеджер, а не того, который непонятный PM), в общем-то, тоже не ахти. В каком состоянии продукт прямо сейчас? Что нужно для того, чтобы успешно закончить проект? Сколько времени это займет? Непонятно. Нет, конечно, некоторое понимание есть…
Отсюда получается, что единственный человек, который понимает, что происходит – это тот самый непонятный PM, который ведет этот проект в рамках этой методологии.
Естественно, я утрирую – конечно, существуют организации, в которых все, как один, пронизаны духом той или иной методологии, прекрасно взаимодействуют друг с другом, отлично понимают, что делают и зачем. В этом случае и отдача есть. Но, думаю, утрирую я не сильно, ибо и мировой опыт применения CMMI, да и просто здравый смысл показывает, что таких команд мало.
Поэтому для очередного проекта (продукта, состоящего из нескольких проектов), было решено использовать что-нибудь очень простое, эффективное и максимально прозрачное.
Этим “чем-то” оказался Scrum. Scrum настолько прост, чтобы вся методология уместилась на одном листе А4, затраты на его поддержание выливаются в 10-15 минут в день, а прозрачность такова, что в любой момент любой (даже совершенно незнакомый с методологией) человек может увидеть и понять, в каком состоянии находится проект сейчас, что уже сделано, что еще будет сделано и сколько времени еще понадобится для того, чтобы получить продукт с нужной функциональностью.
При этом вся эта информаци доступна для понимания и дивелоперов, и менеджеров, и кастомеров. Всё гениальное просто, впрочем, поэтому Scrum и пользуется такой популярностью.
Впрочем, Scrum – это лишь методология, её еще необходимо связать с реальностью рабочим окружением. Да, он настолько прост, что достаточно Excel для полноценной его поддержки, но работать с TFS (удобно же!) и еще и с Excel параллельно тоже не хотелось (хотя недели три и это давало свои ощутимые плоды).
Для осуществления этой связи мы перебрали несколько шаблонов Scrum для TFS. В результате я нашел шаблон, который отлично соответствует как букве методологии (нехитрая терминология, жизненный цикл), так и ее духу (простота и прозрачность). Взять его можно вот здесь: http://www.scrumforteamsystem.com/en/default.aspx
Примечательно, один из наших тимлидов, который работал на “пилотном” для нас проекте Scrum, очень сильно проникся выгодой его применения и даже купил книжку от создателя этой методологии о том, как выгодно применять ее в enterprise-среде, когда увидел портрет при инсталляции темплейта закричал: “О! Это он! Это он!” :) Оказалось, что в создании этого шаблона автор методологии принимал участие лично :)
Конечно, шаблон “умеет” гораздо побольше Excel-проектика, особенно в части отчетности. Выполнен шаблон тоже очень качественно в части того, что из себя представляют воркайтемы, как они выглядят, какие имеют поля. Портал проекта тоже на высоте.
Что важно для меня как для дивелопера – наряду с тем, что интуитивно понятно, как заполнять тот или иной воркайтем, сами они перестали быть некими абстрактными единицами, как было ранее (разве что воркайтем Bug имел какой-то интуитивно понятный смысл), но приобрели какое-то значение, стали обладать, можно сказать, своей функциональностью и смыслом. А раз появился четко выраженный смысл и функциональность, то и отпадают всякие вопросы о том, какой воркайтем в каких условиях создается и в какое состояние когда переходит.
То есть, не как было с Task и Scenario – потому, что “вот так договорились, так предполагает Agile, а вообще-то, физически, разницы никакой”, а вполне себе четко, повторяюсь, интуитивно понятно и, главное, для проекта действительно _имеет_ смысл то, какой тип воркайтема ты создаешь.
Кроме этого темплейта у той же команды и еще одна интересная штука: Task Board. Это WPF-приложение, работающее с TFS посредством веб-сервисов и отлично визуализирующее процесс (и позволяющее управлять им). Вот оно: http://www.scrumforteamsystem.com/en/TaskBoardBeta/Default.aspx
Там есть видеоролики, наглядно демонстрирующие возможности, и скриншоты.
Словом, если у вас тоже есть команда (или несколько) из нескольких человек, вы хотите получить дополнительный ресурс в дивелоперскую команду (роли непонятного PM’а там нет, поэтому он сможет заняться делом вместо того, чтобы спрашивать “как продвигается”), если вы тоже пользуете Agile или CMMI-шаблон, но не используете саму паради��му, если вы хотите сделать проект прозрачным для себя, руководства и заказчиков и при этом не погрязнуть в формализации – есть смысл посмотреть на Scrum и на его “инкарнацию” в TFS :)