|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)Материал из CustisWikiКороткая ссылка: Agile-tools-2010 12 мая в нашей компании прошла очередная миниконференция/встреча сообщества AgileRussia.ru. Тема была заявлена достаточно широкая, «Инструменты в Agile», но в основном это были рассказы об используемых трекерах и процессах построенных вокруг них (планирование/коммуникация/мониторинг). Т.е. системы контроля версий, вики-системы, скайп и мессенджеры упоминались, но центром обсуждения оказались трекеры — TrackStudio, Redmine, Jira+GreenHopper, DevProm (ну и упоминались OTRS, Mantis, Bugzilla и даже Excel). Так как каждый докладчик рассказывал о нескольких инструментах, мы структурировали отчет и видеофайлы «по докладчикам», и постарались кратко описать (в меру собственного понимания, разумеется), основные тезисы выступающих.
Как обычно, мы опубликовали все возможные материалы — слайды, видео для вебпросмотра, видео в лучшем качестве для скачивания и сопроводили выступления нашей краткой рецензией. СодержаниеЕвгений Курышев
Собственно уже в слегка пренебрежительном названии, Евгений заложил основную идею доклада — рулят правильные люди и их коммуникация, а не волшебные инструменты, которых часто гораздо лучше заменить «шестью потолочными плитками», «пробковой стеной» или набором ватманов. К сожалению, «комнатные/ручные» технологии отказывают, когда возникает такая неприятная штука, как распределенность (отказаться от этого пришлось из-за распределенности — тестировщики в питере):
Видно, что куда не ткни, JIRA явно не дотягивает по usability до высоких стандартов Яндекса: «Поиск? Там есть какой-то аналог полнотекстового поиска, но работает он нехорошо, совсем не так, как поиск Яндекса, качество на три с плюсом.». Ну и очевидно, Евгений сторонник комфортной разработки, без авралов и напрягов, с максимальным креативом и удовольствием для разработчиков:
 Продуктивность — это когда убрано максимум waste — ненужных затрат.
В целом, эта самописная вики используется вполне классическим образом: «UserStory, и все, что больше полстраницы текста — в вики, в JIRA только таски». Из инструментов, Евгений больше всего уважает инструменты для коммуникации и погружения команды в контекст: 
С другой стороны, Etherpad — open source → разумно попробовать.
Впрочем, для сбора фидбека, благо сервис общедоступный и массовый, используются и массовые сервисы — поиск по блогам «Мойкруг — говно», либо, для тех, кто в теме — по хештегу #mkbug (явно более предпочтительный способ привлечь внимание к проблеме, чем жаловаться в support — разумный читатель уже понял profit). Ребята активно используют Skype, причем именно с видео, более того, они как-то ухитрялись транслировать через Skype свои SCRUM-доски, когда они еще были на потолочных плитках.
И разумеется, для этого тоже не обязательны информационные системы, рулят предметы материального мира — в Яндексе отдельные стены полностью покрыты пробкой (и можно прикреплять листочки — SCRUM/Kanban доски и т.п.), отдельные стены представляют собой огромный whiteboard многоразового использования. — «Очень большой whiteboard — целая стена! Можно нарисовать всю схему проекта! Гипнотический эффект на всех посетителей, включая менеджеров!»  И да, Евгений считает, что это (пробковые и рисовальные стены) не какая-то прихоть избалованных разработчиков — а необходимое условие, иначе — просто издевательство над здравым смыслом и разработчиками:
Слушатели открыто завидовали. Впрочем, для «жертв помещений не задизайненых под разработку» Евгений предлагает дешевый лайфхак — накупить побольше ватманов (дешево и заменяемо) и развесить их на стены.
Разумеется, обстановка в правильной комнате для разработчиков включает не только копеечные ватманы и потолочную плитку, но и пару плазменных экранов, на которых выводят результаты прогона тестов, мониторинг онлайн нагрузки и т.п.
Да, на плазмах запущен:
Вот в целом и все — если хотите подробнее — смотрите видео, листайте слайды:  (Еще было сказано пару слов про OTRS, но это были не очень хвалебные слова, и было это на последнем докладе). Александр Сербул
Ну да, были и сравнения с спецназом и армией («краповые береты» и т.п.). А так, команда практикует классический скрам, с планированием через планинг-покер (и т.п.). Наверняка личность Александра, и практикуемый им подход к менеджменту в большой степени определили и выбор инструментов — нет раздолбайства, достаточно строгая регистрация всех артефактов, но при этом сложные (и потенциально более мощные) инструменты были заменены простыми, но надежными. Так, например, от TrackStudio они перешли к Redmine. С другой стороны, после перехода у них появился в дополнение к SVN GIT-репозиторий (Redmine + SVN + GIT), но похоже работа с ним оказалась неоправданно сложной, в отличие от работы с «эсвэночкой» (так ласково именовал Александр Subversion). Цитаты:
Т.е. надежность, надежность и еще раз надежность. Ведется даже план управления рисками (в общем-то, редкость для Agile-команд), реализована трехзвенная система тестирования и деплоймента. Отражение SCRUM-сущностей на инструменты достаточно классическое: UserStory живут в вики, задачи — в трекере (причем backlog тоже живет в трекере) ну и все связано (репозитории интегрированы, есть связь файлов с тикетами). Внескрамовское применение инструментов тоже вполне ожидаемое:
Касательно выбора легковесного трекера, то команда Александра предпочла Redmine Trac-у. И все же отмечают, что Redmine расcчитан на дружелюбную среду — опенсорс-разработка или «дисциплинированный заказчик», которого не надо сильно строить, и от которого не надо все прятать. Из других инструментов групповой коммуникации:
Еще одна актуальная тема «Аналитик в Agile» — куда девать аналитиков (в команде/отдельный отдел, объединять с тестировщиками или менеджерами…), нужно ли планировать и учитывать аналитику (если да — то отдельными задачами или вместе), и т.п. У них аналитику с разработкой в тикетах не мешают. В одном тикете может быть аналитика с тестированием.
Дополнительно к видео можно скачать и слайды доклада:  Дмитрий Лобасев
Надо признаться, что с выступлением Дмитрия у нас возникла накладка — несмотря на всевозможные переходники (miniPort→RGB→DVI, miniPort→HDMI→DVI, …) не удалось подключить его МакБукМини к нашим проекторам. Но в результате, получилось даже лучше! Ибо часть выступления со слайдами и игры с Excel-ом вполне удачно показались и с нашего компьютера, а заготовленная демонстрация системы DEVPROM на виртуальной машине и тестовых данных, была заменена на живую демонстрацию реальной системы с реальными же разработчиками, задачами и прочими артефактами. Все выступление Дмитрий строил как Product Owner, рассматривая плюсы и минусы инструментов именно с этой позиции. Сначала Дмитрий показал несколько трюков с Excel'ом, универсальным швейцарским ножом всех менеджеров, позволяющем вести учет задач (включая их важность, описание, тест-кейсы и т.п.), для небольшой команды или когда нет необходимости в конкурентных правках и стандартном веб-функционале («условно-бесплатный инструмент, можно считать что у всех есть»). Заметим, что несмотря на распространение веб-трекеров задач, многие Agile-команды по-прежнему продолжают вести бэклог в Excel, где его удобней заполнять, удалять, перестраивать и всячески крутить, таскать к заказчику и обратно, и только в после того, как задачи попадаются в Sprint, они превращаются в Tasks в трекере или просто карточки на SCRUM-доске (иногда в то и и другое). Таким образом, для небольшой команды можно обойтись одним Excel-ом (включая печать SCRUM-карточек, для задач и User Story), что и продемонстрировал Дмитрий. Затем Дмитрий перешел к настоящим трекерам, а именно к JIRA, рассматривая ее опять таки, как вполне общедоступный инструмент («JIRA, как мы все знаем, условно бесплатная, на ru-trackerе есть»). Однако, несмотря на «бесплатность» JIRе (и примкнувшему к ней плагину GreenHopper, рассматривавшемуся первым докладчиком) досталось и за ее баги, и за ее фичи:
…
Ну и после такой критики, Дмитрий перешел к «гвоздю программы» — системе DevProm (увы, уже не являющейся условно-бесплатной, в смысле наличия ее исходников в распределенной системе контроля версий ru-tracker.org, но допускающей бесплатное использование для небольших команд). Дмитрий утверждал, что она лучше чем JIRA, хотя бы по следующим пунктам:
Срок выполнения 212.3 дня = (624 часа * 1.58) / (5.4 * 0.86) У меня есть гипотезы, но я в них не уверен — зрители, присылайте мне свои, потом, может узнаем правильный ответ. Кроме задач ведется также учет релизов и даже отдельных сборок, есть интеграция с SVN, связь вики-статей с тикетами и т.п. («Здесь все связано со всем…»). При всех изменениях работают оповещения через почту («Я через почту контролирую весь ход проекта») — впрочем, для любого современного трекера это не удивительно. Есть система прав и частичная изоляция информации: «Заказчик, на мой взгляд, не должен видеть фактические часы, … только запланированные». Впрочем, были и критические нотки:
Вообще, собравшихся очень интересовали вопросы эффективного планирования, настолько, что после окончания этого последнего доклада в тщетной надежде задавали вопросы — есть ли идеальная система для планирования в сфере разработки? (Мы то с вами знаем, что «cеребряных пуль» увы, нигде в software engineering нету). Под этим соусом прозвучало упоминание еще пары трекеров:
старый Mantis, ну вот если установить Mantis и долго не трогать то из него получится OTRS». и собрание стало завершаться, так и не найдя святого Грааля — идеального трекера, но зато явно определив тему следующего собрания — «Планирование в Agile». Резюме
На мой взгляд, это было одно из самых полезных собраний сообщества — было очень конкретное обсуждение инструментов и процессов разработки. И если раньше процесс выбора был, в общем-то, интимный, все варились в своем соку, человек попробовавший пару-тройку системы мог считать себя экспертом, то сейчас за вечер участники получили больше информации, чем за полгода самостоятельных исследований и внутрикомпанейских обсуждений. Прослеживаются общие тренды — от «инструмента для процесса» движение к «инструменту для человека» — все, что мешает работе (сложный workflow, ограничения/запреты) отсекается (то, что в эпиграфе к этому разделу назвали complexitytax — налогом на сложность), остается только автоматизация помогающая разработчику (всякие разновидности Continuous Integration). Мало используются всякие метрики. Вернее, мало кто хочет измерять прошлое и настоящее, а вот оценить будущее хотят многие — все хотят надежного и удобного процесса планирования, о котором мы поговорим на следующем собрании сообщества. Ну и под конец, для тех, кто осилил весь текст — оргвыводы. При зарегистрировавшихся 150 участниках, на собрании было порядка 80-100 человек[1], и похоже, это оптимально для нашего зала — никакой давки и сидения на подоконниках (как на прошлом собрании), сидели на удобных креслах с подлокотниками и откидными столиками, не более чем в пяти метрах от ближайшего экрана (два больших экрана и два мощных проектора). Побежден и шум — докладчик обеспечен петличным микрофоном, участникам для задания вопросов выдавался радио, и все это озвучивалось через колонки. В будущем, надо будет сделать вменяемую систему регистрации участников, с отметкой посещения — так будет удобней планировать ожидаемую численность участников («этот участник ходит всегда», а «этот только каждый третий раз»), возможно даже с отчислением злобных «динамщиков». Скорее всего это будет TimePad, с представителями которого удалось обсудить эту проблему [2], и которые, похоже, первыми предложат миру такой сервис (и спасут нас от изобретения велосипеда)[2]. Примечания
Рецензии в рунете
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». Репликация: База Знаний «Заказных Информ Систем» → «Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)» |
 |
 |
 |
На возможный вопрос — а почему мы сами не рассказали об используемых у нас инструментах, ответим, что
«А много задач это сколько? Очень много это типа тридцать?
Мы лично пробовали транслировать доски (с бумажками или рисунками) через Skype с «HD-разрешением» (640x480) — качество было не очень.