Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)

Короткая ссылка: Agile-tools-2010

Ссылки сюда (3) →

12 мая в нашей компании прошла очередная миниконференция/встреча сообщества AgileRussia.ru.

Тема была заявлена достаточно широкая, «Инструменты в Agile», но в основном это были рассказы об используемых трекерах и процессах построенных вокруг них (планирование/коммуникация/мониторинг). Т.е. системы контроля версий, вики-системы, скайп и мессенджеры упоминались, но центром обсуждения оказались трекеры — TrackStudio, Redmine, Jira+GreenHopper, DevProm (ну и упоминались OTRS, Mantis, Bugzilla и даже Excel).

Так как каждый докладчик рассказывал о нескольких инструментах, мы структурировали отчет и видеофайлы «по докладчикам», и постарались кратко описать (в меру собственного понимания, разумеется), основные тезисы выступающих.

На возможный вопрос — а почему мы сами не рассказали об используемых у нас инструментах, ответим, что

• Во-первых, мы только что рассказывали о них на двух конференциях подряд, и оба эти доклада опубликованы:
  • Свободные системы, спасающие разработчиков (РИТ-2010)
  • Knowledge Management: От Склада к Потоку (Software People-2010)
• Во-вторых, мы бы не хотели злоупотреблять положением принимающей стороны, поэтому приоритет мы всегда отдаем нашим гостям.

Как обычно, мы опубликовали все возможные материалы — слайды, видео для вебпросмотра, видео в лучшем качестве для скачивания и сопроводили выступления нашей краткой рецензией.

Евгений Курышев

• Евгений Курышев,
• «Agile-зоопарк проекта МойКруг»
• JIRA, GreenHopper, Etherpad, Skype, Zabbix, OTRS и другие звери.

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/12129612?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe>

Собственно уже в слегка пренебрежительном названии, Евгений заложил основную идею доклада — рулят правильные люди и их коммуникация, а не волшебные инструменты, которых часто гораздо лучше заменить «шестью потолочными плитками», «пробковой стеной» или набором ватманов. К сожалению, «комнатные/ручные» технологии отказывают, когда возникает такая неприятная штука, как распределенность (отказаться от этого пришлось из-за распределенности — тестировщики в питере):

Мы вынужденно на это перешли, ранее мы использовали более удобный и элегантный инструмент — потолочную плитку, на которую мы клеили листочки с помощью иголочек… Шесть потолочных плиток гораздо удобней, чем эта штука, которая, к тому же оказывается, платная… У нас было 6 плиточек, а стало 28 кнопочек, которые AJAXом разворачиваются… … Мы бы попробовали что-нибудь более легкое, чем GreenHopper, на наш вкус он несколько тяжеловат …

… а таскборд должен быть доступен! Только в плохих случаях (распределенность или недоступность таскборда) становятся востребованы инструменты типа Jira.

Перейти же им пришлось на JIRA c плагином GreenHopper, представляющим собой веб-AJAX-SCRUM доску, и как все это выглядит Евгений и показывал на слайдах:

• «Если сильно присматриватся, то тут всякое NDA написано, так что старайтесь не присматриваться».
• «Статусов, больше чем три, поэтому не очень удобно раскладывать их на доске» — все-таки электронные доски удобны когда состояний (вертикальных колонок), да и задач в целом — мало.

«А много задач это сколько? Очень много это типа тридцать?

«Ага, тогда в GreenHopper появляется и склоллбар и pagination — непонятно, почему и то и другое».

Видно, что куда не ткни, JIRA явно не дотягивает по usability до высоких стандартов Яндекса: «Поиск? Там есть какой-то аналог полнотекстового поиска, но работает он нехорошо, совсем не так, как поиск Яндекса, качество на три с плюсом.».

Ну и очевидно, Евгений сторонник комфортной разработки, без авралов и напрягов, с максимальным креативом и удовольствием для разработчиков:

• «В команде 7 человек, не считая разного рода администраторов… да, я считаю за людей, только тех, кто в команде на 100%».
• Планирование — классический Planning Poker: «мы в итерацию берем задач на 30 часов … У нас один идеальный час равен трем реальным в среднем, и мы работаем быстрее, чем многие другие команды… Отдельно есть призовые/запасные задачи» — т.е. это подход — запланировать меньше, чтобы осталось время на запасные задачи, чем лучше, чем запланировать больше и не успеть.
• Планирование версий минимальное — «текущее», «беклог», «экстренное» (все, что задерживает релиз).
• Графики? — «Да, мы иногда заглядываем в графики, но обычно смотрим на полосочку» (распределение задач по статусам, см. картинку выше).
• Регистрация задач в JIRA на самом деле необязательна: «Васе и Феде надо писать таски в джире, а Мариночка все сделает и так». Плюс тестирование вне обычного планирования — «Тестирование не планируется, иногда пытаемся накинуть навскидку часов тестировщику… отдельный тикет на тестирование почти никогда не создается».

Продуктивность — это когда убрано максимум waste — ненужных затрат.

• «Вики — есть уже у всех».
• «А как вы документируете unit-тесты? — а мы вообще мало чего документируем.»

В целом, эта самописная вики используется вполне классическим образом: «UserStory, и все, что больше полстраницы текста — в вики, в JIRA только таски».

Из инструментов, Евгений больше всего уважает инструменты для коммуникации и погружения команды в контекст:

• «Etherpad со вкусом яндекса (после того, как он стал open-source) — добавил продуктивности гораздо больше, чем JIRA … Один человек не успеет это записать, а несколько человек из команды одновременно записывают предложения от важных дядек».

---

На мой лично (Стас Фомин) взгляд, это как-то негуманно — инструмент не автоматизирует проблему («неуспеваем зафиксировать в электронной форме пожелания важных людей»), а лишь позволяет «бросить в пекло побольше пехоты». Тут можно было бы использовать майндмаппинг + скринкаст со звуком — т.е. записывать не дословно, а фиксировать ключевые слова, их важность и структуру. Если что-то забудется — по скринкасту со звуком легко найти место, где появился «забытый узел», и прослушав звук, вспомнить, о чем там речь (и ни копейки не пропадет). С другой стороны — структурированный майндмап «важным людям» гораздо удобней обозревать и верифицировать («забыли то-то», «нет, это важнее, сделай это крупней», «это связано с тем-то»), чем «разноцветное письмо из Простоквашино» (невычитанный текст, полный опечаток, ошибок, лишних слов, не влезет на экран,…). Ну и это требует ресурсы только одного участника-майндмаппера, а остальные вполне могут использовать разум на 100% для realtime-анализа. И кстати, на худой процесс можно запаралеллить и майндмаппинг — использовать например, ShareMind (коллоборативный fork FreeMind).

С другой стороны, Etherpad — open source → разумно попробовать.

---

• «Feedback в SCRUM очень важен — эзерпад помогает фиксировать».

Впрочем, для сбора фидбека, благо сервис общедоступный и массовый, используются и массовые сервисы — поиск по блогам «Мойкруг — говно», либо, для тех, кто в теме — по хештегу #mkbug (явно более предпочтительный способ привлечь внимание к проблеме, чем жаловаться в support — разумный читатель уже понял profit).

Ребята активно используют Skype, причем именно с видео, более того, они как-то ухитрялись транслировать через Skype свои SCRUM-доски, когда они еще были на потолочных плитках.

Мы лично пробовали транслировать доски (с бумажками или рисунками) через Skype с «HD-разрешением» (640x480) — качество было не очень.

Кроме активной коммуникации, Евгений проповедует метод «постоянного погружения» разработчиков в контекст проекта, чтобы куда бы разработчик не кинул взор, были станки, станки, станки графики и схемы проекта, большие плазменные мониторы с данными о сборках и онлайн-мониторинге.

И разумеется, для этого тоже не обязательны информационные системы, рулят предметы материального мира — в Яндексе отдельные стены полностью покрыты пробкой (и можно прикреплять листочки — SCRUM/Kanban доски и т.п.), отдельные стены представляют собой огромный whiteboard многоразового использования.

— «Очень большой whiteboard — целая стена! Можно нарисовать всю схему проекта! Гипнотический эффект на всех посетителей, включая менеджеров!»

И да, Евгений считает, что это (пробковые и рисовальные стены) не какая-то прихоть избалованных разработчиков — а необходимое условие, иначе — просто издевательство над здравым смыслом и разработчиками:

«…Я работал на Таганке, мы оттяпали помещение какой-то конторы на первом этаже, и это называлось Яндекс.Ад — помещение не было задизайнено по разработку, туда ссылали… У нас была целая пробковая стена — но оказалось ее заставили какими-то шкафами… »

«А что лучше — пробковая стена или рисовальная? — Я люблю и рисовать и пробковую доску».

«В разные периоды у нас было по-разному, было по две плазмы на один проект, была одна плазма...»

Слушатели открыто завидовали. Впрочем, для «жертв помещений не задизайненых под разработку» Евгений предлагает дешевый лайфхак — накупить побольше ватманов (дешево и заменяемо) и развесить их на стены.

Надо бы попробовать — но, кажется, расставленные у стен столы будут мешать рисовать…

Разумеется, обстановка в правильной комнате для разработчиков включает не только копеечные ватманы и потолочную плитку, но и пару плазменных экранов, на которых выводят результаты прогона тестов, мониторинг онлайн нагрузки и т.п.

«В разные периоды у нас было по-разному, было по две плазмы на один проект, была одна плазма... Используются конкурентно — таскборд, заббикс, череп, снова такскборд... »

К сожалению, хитрые администраторы повесили экраны под потолок — и их стало очень сложно использовать совместно с игровыми приставками (разработчики, не повторяйте этой ошибки, менеджеры — ну вы поняли…).

Да, на плазмах запущен:

• Мониторинг сервиса через Zabbix — постоянная трансляция на экран, причем постоянность трансляции (а не то, что можно где-то там посмотреть) — это очень важно:

• PHPUnit — на плазму выводится результат прогона тестов (если что-то упало, показывает огромный анимированный череп, подзывающий пальцем прохожих — не заметить просто невозможно).

• JSLint — постоянная проверка стиля и статический поиск ошибок в Javascripte — это и поддерживает у них непрерывный рефакторинг кучи JavaScript-кода. Его они тоже непрерывно крутят на сервере, исползуя SpiderMonkey.

Вот в целом и все — если хотите подробнее — смотрите видео, листайте слайды:

(Еще было сказано пару слов про OTRS, но это были не очень хвалебные слова, и было это на последнем докладе).

Александр Сербул

• Александр Сербул, компания Softline.
• Инструменты: TrackStudio, GIT, SVN, Redmine.

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/12128323?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe>

Александр демонстрировал паттерн «патерналистический SCRUM» (вот такая псевдотавтология, на докладе же прозвучало определение «Суверенный SCRUM»): «отец солдатам», «огражу разработчика от бизнес-менеджеров, но спрошу строго сам». Цитаты из выступления:

• «Вообще, я сторонник жесткого, управляемого, Agile».
• «С любовью, но строго».
• «Вообще, я не верю в кроссфункциональность».
• и даже — «Главное тут человека не сломать, … ну то есть разработчика».

Ну да, были и сравнения с спецназом и армией («краповые береты» и т.п.). А так, команда практикует классический скрам, с планированием через планинг-покер (и т.п.).

Наверняка личность Александра, и практикуемый им подход к менеджменту в большой степени определили и выбор инструментов — нет раздолбайства, достаточно строгая регистрация всех артефактов, но при этом сложные (и потенциально более мощные) инструменты были заменены простыми, но надежными. Так, например, от TrackStudio они перешли к Redmine. С другой стороны, после перехода у них появился в дополнение к SVN GIT-репозиторий (Redmine + SVN + GIT), но похоже работа с ним оказалась неоправданно сложной, в отличие от работы с «эсвэночкой» (так ласково именовал Александр Subversion).

Цитаты:

• «Общение неформальное, давления никакого нет, но документики мы все сохраняем… Письма и так далее… Сохраняем в SVN.»
• «TrackStudio — инструмент для гениев, GIT в мире трекеров». «TrackStudia стоит того, чтобы ее изучить. Развивает головной мозг». «GIT - инструмент для богов».
• «…После того, как мы убедились, что не все люди боги…»

Т.е. надежность, надежность и еще раз надежность. Ведется даже план управления рисками (в общем-то, редкость для Agile-команд), реализована трехзвенная система тестирования и деплоймента.

Отражение SCRUM-сущностей на инструменты достаточно классическое: UserStory живут в вики, задачи — в трекере (причем backlog тоже живет в трекере) ну и все связано (репозитории интегрированы, есть связь файлов с тикетами).

Внескрамовское применение инструментов тоже вполне ожидаемое:

• Вики — база знаний, стандарты, регламенты, технологии.
• SVN для документов, GIT для кода.

Тут мы отметим, что да, применять GIT или любую для редактирования документов (пока?) невозможно, ибо невозможно заблокировать документ на изменение, но то, что очень много документов-артефактов под SVN, выдает слабость встроенной в RedMine вики-системы, не годящейся для полноценных документов с иллюстрациями, диаграммами, схемами.

Касательно выбора легковесного трекера, то команда Александра предпочла Redmine Trac-у. И все же отмечают, что Redmine расcчитан на дружелюбную среду — опенсорс-разработка или «дисциплинированный заказчик», которого не надо сильно строить, и от которого не надо все прятать.

Из других инструментов групповой коммуникации:

• Используют Skype. Без видео. Иногда даже без звука — только чаты.
• Для «демонстрации экранов» используют TeamViewer.
• Для совместного рисования используют http://www.dabbleboard.com
• Для снятия и перебрасывания скриншотов — http://jetscreenshot.com
• Для скринкастов — CamStudio.

Но все же, несмотря на такое обилие инструментов, тоже наблюдается общий тренд — облегчение фиксации любой ценой (цитата — «Когда много инструментария, теряется дух Agile — начинаешь переживать за процесс»). Так, из метрик, используется только фокус-фактор.

Еще одна актуальная тема «Аналитик в Agile» — куда девать аналитиков (в команде/отдельный отдел, объединять с тестировщиками или менеджерами…), нужно ли планировать и учитывать аналитику (если да — то отдельными задачами или вместе), и т.п.

У них аналитику с разработкой в тикетах не мешают. В одном тикете может быть аналитика с тестированием.

Но вообще они за гранью стандартного разработческого SCRUMа (цитата — «Оценивать аналитику заранее невозможно…. За аналитиками я слежу. Они должны быть бодрыми, миролюбивыми и не спать»). В целом, аналитика идет «на опережение» (цитата — «Аналитики идут по плану вперед. План составляется на полгода»), хотя риски такого подхода тоже понятны — (реплика из зала: «Аналитики ушли вперед, на 3-4 месяца — а вы не боитесь, что постановки протухнут?»).

Дополнительно к видео можно скачать и слайды доклада:

Дмитрий Лобасев

• Дмитрий Лобасев
• Excel, JIRA, DevProm

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/12121431?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe>

---

Надо признаться, что с выступлением Дмитрия у нас возникла накладка — несмотря на всевозможные переходники (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, рассматривавшемуся первым докладчиком) досталось и за ее баги, и за ее фичи:

• Настраиваемый workflow — не нужен, и даже опасен: «Все хотят кастомизацию и получают совершенно неработающее… неработающий workflow»
• SubTaskи не меняют статус при закрытии родителя!
• У GREENHOPPER-а:
  • тормоза! (даже на Google Chrome)!
  • быстро не проставить результат планирования (свистелки и перделки на AJAX тормозят)
• нет импорта из Excel (если нет административного доступа к файловой системе на сервере)
• нет средней скорости разработки
• нельзя оценить/просуммировать произвольно выбранную группу фич.
• долго и неудобно формируется отчет-таймшит для заказчика.

…

Перечислять критику можно долго, если хочется посмотреть подборку критики JIRA, то наверное разумно заглянуть сюда, а за критикой всех существующих трекеров — сюда.

Ну и после такой критики, Дмитрий перешел к «гвоздю программы» — системе DevProm (увы, уже не являющейся условно-бесплатной, в смысле наличия ее исходников в распределенной системе контроля версий ru-tracker.org, но допускающей бесплатное использование для небольших команд).

Дмитрий утверждал, что она лучше чем JIRA, хотя бы по следующим пунктам:

• быстрее
• да, тоже есть AJAX, но тут он уместный и быстрый (для вставки аттачментов и т.п.).
• есть редактирование атрибутов в таблице просмотра.
• есть «быстрый фильтр»
• есть вычисление ожидаемых сроков по выбранной группе задач.

---

Я лично не совсем понял формулу, но было продемонстрирована живьем группа задач, для которых показана расшифрованная формула

 Срок выполнения 212.3 дня = (624 часа * 1.58) / (5.4 * 0.86) 

У меня есть гипотезы, но я в них не уверен — зрители, присылайте мне свои, потом, может узнаем правильный ответ.

---

Кроме задач ведется также учет релизов и даже отдельных сборок, есть интеграция с SVN, связь вики-статей с тикетами и т.п. («Здесь все связано со всем…»).

При всех изменениях работают оповещения через почту («Я через почту контролирую весь ход проекта») — впрочем, для любого современного трекера это не удивительно.

Есть система прав и частичная изоляция информации: «Заказчик, на мой взгляд, не должен видеть фактические часы, … только запланированные».

Впрочем, были и критические нотки:

• «… Возможно это не лучшая система для работы product owner-а… с точки зрения интерфейса…», на хабре была более красивая, но там нет интеграции

Вероятно имелся в виду Pivotal Tracker, и у него есть ключевая проблема — нет прав. Вернее нет системы прав, т.е. права есть, и есть они у всех, все могут все.

• «[SCRUM]-карточки печатать и нарезать здесь нельзя…»

Народ (несколько участников) интересовала возможность фокусированного общения между разработчиками и аналитиками с фиксацией «на чьей стороне мяч» (без передачи отвественности за саму задачу). Т.е. не просто поток комментариев, а выделение наиболее важных, требующих обратной реакции — так вот, похоже здесь этого пока нет (ну и видимо, не возникает потребности).

---

Вероятно это не очень распространенный кейс, поэтому я поясню (я, Стас Фомин, кажется понял, о чем спрашивали). В Bugzille, например, это реализуется через механизм флагов, в частности, флаг «вопрос», который «ставится» на участника (иногда даже представителя заказчика), от которого требуется ответ, а он, соответственно, отвечает, и «закрывает» этот флаг. Таким образом, сами вопросы не теряются в стремительном информационном потоке, а ответы на такие вопросы получают больший приоритет, и работа по задачам, требующим дополнительной информации, не блокируется.

---

Вообще, собравшихся очень интересовали вопросы эффективного планирования, настолько, что после окончания этого последнего доклада в тщетной надежде задавали вопросы — есть ли идеальная система для планирования в сфере разработки? (Мы то с вами знаем, что «cеребряных пуль» увы, нигде в software engineering нету).

Под этим соусом прозвучало упоминание еще пары трекеров:

• «Серебряных пуль не существует, зато существует Mantis»
• «OTRS, это такое доисторическое животное, похожее на Mantis,

старый Mantis, ну вот если установить Mantis и долго не трогать то из него получится OTRS».

и собрание стало завершаться, так и не найдя святого Грааля — идеального трекера, но зато явно определив тему следующего собрания — «Планирование в Agile».

Резюме

Крупные компании одержимы приобретательством, пытаясь найти «безразмерные» инструменты для разработки. Конечно для крупной компании стандартизация инфраструктуры — вещь немаловажная. Но в какой-то момент стандартизированная инфраструктура становится помехой, а не достоинством. В особенности это относится к чрезмерно усложненным инcтрументам.

Я даже придумал специальный термин — налог на сложность (complexitytax). Это те дополнительные деньги, которые вы платите за акцидентальную сложность инcтрумента, умеющего больше, чем вам необходимо. Сколько проектов вязнет в трясине вынужденной сложности, благодаря инструментарию, приобретенному разработчикам во имя — чего бы вы думали? — повышения продуктивности. (См. Продуктивный программист. Как сделать сложное простым, а невозможное – возможным)

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

Прослеживаются общие тренды — от «инструмента для процесса» движение к «инструменту для человека» — все, что мешает работе (сложный workflow, ограничения/запреты) отсекается (то, что в эпиграфе к этому разделу назвали complexitytax — налогом на сложность), остается только автоматизация помогающая разработчику (всякие разновидности Continuous Integration). Мало используются всякие метрики. Вернее, мало кто хочет измерять прошлое и настоящее, а вот оценить будущее хотят многие — все хотят надежного и удобного процесса планирования, о котором мы поговорим на следующем собрании сообщества.

Ну и под конец, для тех, кто осилил весь текст — оргвыводы. При зарегистрировавшихся 150 участниках, на собрании было порядка 80-100 человек, и похоже, это оптимально для нашего зала — никакой давки и сидения на подоконниках (как на прошлом собрании), сидели на удобных креслах с подлокотниками и откидными столиками, не более чем в пяти метрах от ближайшего экрана (два больших экрана и два мощных проектора). Побежден и шум — докладчик обеспечен петличным микрофоном, участникам для задания вопросов выдавался радио, и все это озвучивалось через колонки.

В будущем, надо будет сделать вменяемую систему регистрации участников, с отметкой посещения — так будет удобней планировать ожидаемую численность участников («этот участник ходит всегда», а «этот только каждый третий раз»), возможно даже с отчислением злобных «динамщиков». Скорее всего это будет TimePad, с представителями которого удалось обсудить эту проблему [2], и которые, похоже, первыми предложат миру такой сервис (и спасут нас от изобретения велосипеда).

Примечания

Рецензии в рунете

• http://vpak.blogspot.com/2010/05/agile-agilerussia.html

Если мы кого-то упустили — присылайте мне ссылки на ваши отчеты, я их добавлю.

---

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.