|
Персональные инструменты |
|||
|
Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)Материал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Короткая ссылка: Agile-tools-2010 12 мая в нашей компании прошла очередная миниконференция/встреча сообщества AgileRussia.ru. Тема была заявлена достаточно широкая, «Инструменты в Agile», но в основном это были рассказы об используемых трекерах и процессах построенных вокруг них (планирование/коммуникация/мониторинг). Т.е. системы контроля версий, вики-системы, скайп и мессенджеры упоминались, но центром обсуждения оказались трекеры — TrackStudio, Redmine, Jira+GreenHopper, DevProm (ну и упоминались OTRS, Mantis, Bugzilla и даже Excel). Так как каждый докладчик рассказывал о нескольких инструментах, мы структурировали отчет и видеофайлы «по докладчикам», и постарались кратко описать (в меру собственного понимания, разумеется), основные тезисы выступающих. На возможный вопрос — а почему мы сами не рассказали об используемых у нас инструментах, ответим, что
Как обычно, мы опубликовали все возможные материалы — слайды, видео для вебпросмотра, видео в лучшем качестве для скачивания и сопроводили выступления нашей краткой рецензией. Содержание[убрать]Евгений Курышев
Видео в HD-качестве, смотрите в полноэкранном режиме. HTML-код включения <iframe src="http://player.vimeo.com/video/12129612?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe> Скачать → на странице видео на vimeo, кнопка «Download» Собственно уже в слегка пренебрежительном названии, Евгений заложил основную идею доклада — рулят правильные люди и их коммуникация, а не волшебные инструменты, которых часто гораздо лучше заменить «шестью потолочными плитками», «пробковой стеной» или набором ватманов. К сожалению, «комнатные/ручные» технологии отказывают, когда возникает такая неприятная штука, как распределенность (отказаться от этого пришлось из-за распределенности — тестировщики в питере):
«А много задач это сколько? Очень много это типа тридцать? «Ага, тогда в GreenHopper появляется и склоллбар и pagination — непонятно, почему и то и другое». Видно, что куда не ткни, JIRA явно не дотягивает по usability до высоких стандартов Яндекса: «Поиск? Там есть какой-то аналог полнотекстового поиска, но работает он нехорошо, совсем не так, как поиск Яндекса, качество на три с плюсом.». Ну и очевидно, Евгений сторонник комфортной разработки, без авралов и напрягов, с максимальным креативом и удовольствием для разработчиков:
Продуктивность — это когда убрано максимум waste — ненужных затрат.
В целом, эта самописная вики используется вполне классическим образом: «UserStory, и все, что больше полстраницы текста — в вики, в JIRA только таски». Из инструментов, Евгений больше всего уважает инструменты для коммуникации и погружения команды в контекст:
На мой лично (Стас Фомин) взгляд, это как-то негуманно — инструмент не автоматизирует проблему («неуспеваем зафиксировать в электронной форме пожелания важных людей»), а лишь позволяет «бросить в пекло побольше пехоты». Тут можно было бы использовать майндмаппинг + скринкаст со звуком — т.е. записывать не дословно, а фиксировать ключевые слова, их важность и структуру. Если что-то забудется — по скринкасту со звуком легко найти место, где появился «забытый узел», и прослушав звук, вспомнить, о чем там речь (и ни копейки не пропадет). С другой стороны — структурированный майндмап «важным людям» гораздо удобней обозревать и верифицировать («забыли то-то», «нет, это важнее, сделай это крупней», «это связано с тем-то»), чем «разноцветное письмо из Простоквашино» (невычитанный текст, полный опечаток, ошибок, лишних слов, не влезет на экран,…). Ну и это требует ресурсы только одного участника-майндмаппера, а остальные вполне могут использовать разум на 100% для realtime-анализа. И кстати, на худой процесс можно запаралеллить и майндмаппинг — использовать например, ShareMind (коллоборативный fork FreeMind). С другой стороны, Etherpad — open source → разумно попробовать.
Впрочем, для сбора фидбека, благо сервис общедоступный и массовый, используются и массовые сервисы — поиск по блогам «Мойкруг — говно», либо, для тех, кто в теме — по хештегу #mkbug (явно более предпочтительный способ привлечь внимание к проблеме, чем жаловаться в support — разумный читатель уже понял profit). Ребята активно используют Skype, причем именно с видео, более того, они как-то ухитрялись транслировать через Skype свои SCRUM-доски, когда они еще были на потолочных плитках. Мы лично пробовали транслировать доски (с бумажками или рисунками) через Skype с «HD-разрешением» (640x480) — качество было не очень.
И разумеется, для этого тоже не обязательны информационные системы, рулят предметы материального мира — в Яндексе отдельные стены полностью покрыты пробкой (и можно прикреплять листочки — SCRUM/Kanban доски и т.п.), отдельные стены представляют собой огромный whiteboard многоразового использования. — «Очень большой whiteboard — целая стена! Можно нарисовать всю схему проекта! Гипнотический эффект на всех посетителей, включая менеджеров!» И да, Евгений считает, что это (пробковые и рисовальные стены) не какая-то прихоть избалованных разработчиков — а необходимое условие, иначе — просто издевательство над здравым смыслом и разработчиками:
Слушатели открыто завидовали. Впрочем, для «жертв помещений не задизайненых под разработку» Евгений предлагает дешевый лайфхак — накупить побольше ватманов (дешево и заменяемо) и развесить их на стены. Надо бы попробовать — но, кажется, расставленные у стен столы будут мешать рисовать… Разумеется, обстановка в правильной комнате для разработчиков включает не только копеечные ватманы и потолочную плитку, но и пару плазменных экранов, на которых выводят результаты прогона тестов, мониторинг онлайн нагрузки и т.п.
К сожалению, хитрые администраторы повесили экраны под потолок — и их стало очень сложно использовать совместно с игровыми приставками (разработчики, не повторяйте этой ошибки, менеджеры — ну вы поняли…). Да, на плазмах запущен:
Вот в целом и все — если хотите подробнее — смотрите видео, листайте слайды: (Еще было сказано пару слов про OTRS, но это были не очень хвалебные слова, и было это на последнем докладе). Александр Сербул
Видео в HD-качестве, смотрите в полноэкранном режиме. HTML-код включения <iframe src="http://player.vimeo.com/video/12128323?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe> Скачать → на странице видео на vimeo, кнопка «Download»
Ну да, были и сравнения с спецназом и армией («краповые береты» и т.п.). А так, команда практикует классический скрам, с планированием через планинг-покер (и т.п.). Наверняка личность Александра, и практикуемый им подход к менеджменту в большой степени определили и выбор инструментов — нет раздолбайства, достаточно строгая регистрация всех артефактов, но при этом сложные (и потенциально более мощные) инструменты были заменены простыми, но надежными. Так, например, от TrackStudio они перешли к Redmine. С другой стороны, после перехода у них появился в дополнение к SVN GIT-репозиторий (Redmine + SVN + GIT), но похоже работа с ним оказалась неоправданно сложной, в отличие от работы с «эсвэночкой» (так ласково именовал Александр Subversion). Цитаты:
Т.е. надежность, надежность и еще раз надежность. Ведется даже план управления рисками (в общем-то, редкость для Agile-команд), реализована трехзвенная система тестирования и деплоймента. Отражение SCRUM-сущностей на инструменты достаточно классическое: UserStory живут в вики, задачи — в трекере (причем backlog тоже живет в трекере) ну и все связано (репозитории интегрированы, есть связь файлов с тикетами). Внескрамовское применение инструментов тоже вполне ожидаемое:
Тут мы отметим, что да, применять GIT или любую для редактирования документов (пока?) невозможно, ибо невозможно заблокировать документ на изменение, но то, что очень много документов-артефактов под SVN, выдает слабость встроенной в RedMine вики-системы, не годящейся для полноценных документов с иллюстрациями, диаграммами, схемами. Касательно выбора легковесного трекера, то команда Александра предпочла Redmine Trac-у. И все же отмечают, что Redmine расcчитан на дружелюбную среду — опенсорс-разработка или «дисциплинированный заказчик», которого не надо сильно строить, и от которого не надо все прятать. Из других инструментов групповой коммуникации:
Еще одна актуальная тема «Аналитик в Agile» — куда девать аналитиков (в команде/отдельный отдел, объединять с тестировщиками или менеджерами…), нужно ли планировать и учитывать аналитику (если да — то отдельными задачами или вместе), и т.п. У них аналитику с разработкой в тикетах не мешают. В одном тикете может быть аналитика с тестированием.
Дополнительно к видео можно скачать и слайды доклада: Дмитрий Лобасев
Видео в HD-качестве, смотрите в полноэкранном режиме. HTML-код включения <iframe src="http://player.vimeo.com/video/12121431?byline=0&portrait=0" width="640" height="640" frameborder="0"></iframe> Скачать → на странице видео на vimeo, кнопка «Download» Надо признаться, что с выступлением Дмитрия у нас возникла накладка — несмотря на всевозможные переходники (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, рассматривавшемуся первым докладчиком) досталось и за ее баги, и за ее фичи:
… Перечислять критику можно долго, если хочется посмотреть подборку критики JIRA, то наверное разумно заглянуть сюда, а за критикой всех существующих трекеров — сюда. Ну и после такой критики, Дмитрий перешел к «гвоздю программы» — системе DevProm (увы, уже не являющейся условно-бесплатной, в смысле наличия ее исходников в распределенной системе контроля версий ru-tracker.org, но допускающей бесплатное использование для небольших команд). Дмитрий утверждал, что она лучше чем JIRA, хотя бы по следующим пунктам:
Я лично не совсем понял формулу, но было продемонстрирована живьем группа задач, для которых показана расшифрованная формула Срок выполнения 212.3 дня = (624 часа * 1.58) / (5.4 * 0.86) У меня есть гипотезы, но я в них не уверен — зрители, присылайте мне свои, потом, может узнаем правильный ответ. Кроме задач ведется также учет релизов и даже отдельных сборок, есть интеграция с SVN, связь вики-статей с тикетами и т.п. («Здесь все связано со всем…»). При всех изменениях работают оповещения через почту («Я через почту контролирую весь ход проекта») — впрочем, для любого современного трекера это не удивительно. Есть система прав и частичная изоляция информации: «Заказчик, на мой взгляд, не должен видеть фактические часы, … только запланированные». Впрочем, были и критические нотки:
Вероятно имелся в виду Pivotal Tracker, и у него есть ключевая проблема — нет прав. Вернее нет системы прав, т.е. права есть, и есть они у всех, все могут все.
Вероятно это не очень распространенный кейс, поэтому я поясню (я, Стас Фомин, кажется понял, о чем спрашивали). В Bugzille, например, это реализуется через механизм флагов, в частности, флаг «вопрос», который «ставится» на участника (иногда даже представителя заказчика), от которого требуется ответ, а он, соответственно, отвечает, и «закрывает» этот флаг. Таким образом, сами вопросы не теряются в стремительном информационном потоке, а ответы на такие вопросы получают больший приоритет, и работа по задачам, требующим дополнительной информации, не блокируется. Вообще, собравшихся очень интересовали вопросы эффективного планирования, настолько, что после окончания этого последнего доклада в тщетной надежде задавали вопросы — есть ли идеальная система для планирования в сфере разработки? (Мы то с вами знаем, что «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)» |
||