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

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

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

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

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

Содержание

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

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

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

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


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

Agile зоопарк проекта МойКруг (Евгений Курышев).pdf

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

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

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

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


Agile зоопарк проекта МойКруг (Евгений Курышев).pdf

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

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

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

Agile зоопарк проекта МойКруг (Евгений Курышев).pdf

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

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


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

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

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


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

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

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

Agile зоопарк проекта МойКруг (Евгений Курышев).pdf

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

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

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

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

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

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

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

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

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

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

Agile зоопарк проекта МойКруг (Евгений Курышев).pdf

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

Agile зоопарк проекта МойКруг (Евгений Курышев).pdf

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

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



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

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

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

Цитаты:

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

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

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

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

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

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


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

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

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


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

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

Инструменты в Agile (Александр Сербул).pdf

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


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

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

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

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


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

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

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


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

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

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

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

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


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


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


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

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

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

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

Резюме

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

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

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

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

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

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

Примечания

  1. оценка приблизительная, по количеству используемых стульев
  2. Если вы знаете другой сервис с таким функционалом — дайте [1] знать.

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

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



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)»