Просмотр исходного текста страницы Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)

12 мая в [http://www.custis.ru нашей компании] прошла очередная миниконференция/встреча сообщества [http://agilerussia.ru AgileRussia.ru].

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

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

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

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

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

<blockquote>
*  [http://evgenyq.moikrug.ru/ Евгений  Курышев],
*  «Agile-зоопарк проекта МойКруг»
*  <tt>JIRA</tt>, <tt>GreenHopper</tt>, <tt>Etherpad</tt>, <tt>Skype</tt>, <tt>Zabbix</tt>, <tt>OTRS</tt> и другие звери.
</blockquote>

{{vimeoembed|12129612|640|640}} 

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

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

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


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

[[Файл:Agile зоопарк проекта МойКруг (Евгений  Курышев).pdf|page=3|512px|center]]

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

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

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

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

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

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



[[Файл:Agile зоопарк проекта МойКруг (Евгений  Курышев).pdf|page=5|256px|right]]
Продуктивность — это когда убрано максимум ''waste'' — ненужных затрат.
* «Вики  — есть уже у всех».
* «А как вы документируете unit-тесты? — а мы вообще мало чего документируем.»
В целом, эта самописная вики используется вполне классическим образом:
«UserStory, и все, что больше полстраницы текста — в вики, в JIRA только  таски».

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

[[Файл:Agile зоопарк проекта МойКруг (Евгений  Курышев).pdf|page=4|384px|right]]
* «[http://etherpad.org/ Etherpad] со вкусом яндекса (после того, как он стал ''open-source'') — добавил продуктивности гораздо больше, чем JIRA … Один человек не успеет это записать, а несколько человек из команды  одновременно записывают предложения от важных дядек».

----
{{note}} На мой лично ([[Участник:StasFomin|Стас Фомин]]) взгляд, это как-то негуманно — инструмент не автоматизирует проблему («неуспеваем зафиксировать в электронной форме пожелания важных людей»), а лишь позволяет «бросить в пекло побольше пехоты». Тут можно было бы использовать майндмаппинг + скринкаст со звуком — т.е. записывать не дословно, а фиксировать ключевые слова, их важность и структуру. Если что-то забудется — по скринкасту со звуком легко найти место, где появился «забытый узел», и прослушав звук, вспомнить, о чем там речь (и ни копейки не пропадет). С другой стороны — структурированный майндмап «важным людям» гораздо удобней обозревать и верифицировать («забыли то-то», «нет, это важнее, сделай это крупней», «это связано с тем-то»), чем «разноцветное письмо из Простоквашино» (невычитанный текст, полный опечаток, ошибок, лишних слов, не влезет на экран,…). Ну и это требует ресурсы только одного участника-майндмаппера, а остальные вполне могут использовать разум на 100% для realtime-анализа.
И кстати, на худой процесс можно запаралеллить и майндмаппинг — использовать например, 
[http://code.google.com/p/sharedmind/wiki/UserGuide ShareMind] (коллоборативный fork [[FreeMind]]).

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

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

Впрочем, для сбора фидбека, благо сервис общедоступный и массовый, используются и массовые сервисы —   поиск по блогам «[http://blogs.yandex.ru/search.xml?text=%28%D0%BC%D0%BE%D0%B9%D0%BA%D1%80%D1%83%D0%B3%7Cmoikrug%29+%28%D0%B3%D0%BE%D0%B2%D0%BD%D0%BE%7C%D0%BE%D1%82%D1%81%D1%82%D0%BE%D0%B9%7C%D0%B1%D0%B0%D0%B3%29 Мойкруг —  говно]», либо, для тех, кто в теме — по хештегу [http://blogs.yandex.ru/search.xml?text=%23mkbug&ft=all #mkbug] (явно более предпочтительный способ привлечь внимание к проблеме, чем жаловаться в support —  разумный читатель уже понял profit).

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

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


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

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

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

[[Файл:Agile зоопарк проекта МойКруг (Евгений  Курышев).pdf|page=8|640px|center]]

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

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

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

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

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

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

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

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

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

Да, на плазмах запущен:
* Мониторинг сервиса через [http://www.zabbix.com/ Zabbix]  — постоянная трансляция на  экран, причем постоянность трансляции (а не то, что можно где-то там посмотреть) — это очень важно:

[[Файл:Agile зоопарк проекта МойКруг (Евгений   Курышев).pdf|page=12|640px|center]]

* [http://www.phpunit.de/ PHPUnit] — на плазму выводится результат прогона тестов (если что-то упало,  показывает огромный анимированный череп, подзывающий пальцем прохожих — не заметить просто невозможно).

* [http://www.jslint.com/lint.html  JSLint] — постоянная проверка стиля и статический поиск ошибок в Javascripte — это и поддерживает у них непрерывный рефакторинг кучи JavaScript-кода. Его они тоже непрерывно крутят на сервере, исползуя [http://www.mozilla.org/js/spidermonkey/ SpiderMonkey].

Вот в целом и все — если хотите подробнее — смотрите видео, листайте слайды: 
[[Файл:Agile зоопарк проекта МойКруг (Евгений   Курышев).pdf|512px|center]]

(Еще было сказано пару слов про [http://otrs.org OTRS], но это были не очень хвалебные слова, и было это на [[#Дмитрий Лобасев|последнем докладе]]).

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

<blockquote>
* [http://aleksandr-serbul.moikrug.ru/ Александр  Сербул], компания Softline. 
* Инструменты: <tt>TrackStudio</tt>, <tt>GIT</tt>, <tt>SVN</tt>, <tt>Redmine</tt>.
</blockquote>


{{vimeoembed|12128323|640|640}} 


Александр демонстрировал паттерн «патерналистический SCRUM» (вот такая псевдотавтология, на докладе же прозвучало определение «Суверенный SCRUM»): «отец солдатам», «огражу разработчика от бизнес-менеджеров, но спрошу строго сам». 
Цитаты из выступления:
* «Вообще,  я сторонник жесткого, управляемого, Agile». 
* «С любовью, но строго».
* «Вообще,  я не верю в кроссфункциональность». 
* и даже — «Главное тут человека не сломать, … ну то есть  разработчика». 
Ну да, были и сравнения с спецназом и армией («краповые береты» и т.п.).
А так, команда  практикует классический скрам, с планированием через  планинг-покер (и т.п.).

Наверняка личность Александра, и практикуемый им подход к менеджменту в большой степени определили и выбор инструментов — нет раздолбайства, достаточно строгая регистрация всех артефактов, но при этом сложные (и потенциально более мощные) инструменты были заменены простыми, но надежными.
Так, например, от <tt>[http://www.trackstudio.ru/ TrackStudio]</tt> они перешли к <tt>[http://www.redmine.org/ Redmine]</tt>.
С другой стороны, после перехода у них появился в дополнение к SVN GIT-репозиторий (<tt>Redmine</tt> + <tt>SVN</tt> + <tt>GIT</tt>), но похоже работа с ним оказалась неоправданно сложной, в отличие от работы с «эсвэночкой» (так ласково именовал Александр [[Subversion]]).

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

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

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

Внескрамовское применение инструментов тоже вполне ожидаемое:
* Вики — база знаний, стандарты,  регламенты, технологии.
* <tt>SVN</tt> для  документов, <tt>GIT</tt> для кода. 
{{note}} Тут мы отметим, что да, применять <tt>GIT</tt> или любую [[Категория:Системы_контроля_версий|DVCS]] для редактирования документов (пока?) невозможно, ибо невозможно заблокировать документ на изменение, но то, что очень много документов-артефактов под SVN, выдает слабость встроенной в <tt>RedMine</tt> вики-системы, не годящейся для полноценных документов с иллюстрациями, диаграммами, схемами.

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

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


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

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

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


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

Дополнительно к видео можно скачать и слайды доклада:
[[Файл:Инструменты_в_Agile_(Александр_Сербул).pdf|page=2|640px|center]]

== Дмитрий Лобасев ==
[[Категория:Дмитрий Лобасев|Дмитрий Лобасев]]
<blockquote>
* [[:Категория:Дмитрий Лобасев|Дмитрий Лобасев]]
* <tt>Excel</tt>, <tt>JIRA</tt>, <tt>DevProm</tt>
</blockquote>

{{vimeoembed|12121431|640|640}} 

----
Надо признаться, что с выступлением Дмитрия у нас возникла накладка 
— несмотря на всевозможные переходники (miniPort→RGB→DVI, miniPort→HDMI→DVI, …) 
не удалось подключить его МакБукМини к нашим проекторам.

Но в результате, получилось даже лучше! 
Ибо часть выступления со слайдами и игры с <tt>Excel</tt>-ом вполне удачно показались и с нашего компьютера, а заготовленная демонстрация системы <tt>DEVPROM</tt> на виртуальной машине и тестовых данных, была заменена на живую демонстрацию реальной системы с 
реальными же разработчиками, задачами и прочими артефактами.
----

Все выступление Дмитрий строил как ''Product Owner'', рассматривая плюсы и минусы инструментов именно с этой позиции.

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

Заметим, что несмотря на распространение веб-трекеров задач, многие Agile-команды 
по-прежнему продолжают вести бэклог в Excel, где его удобней 
заполнять, удалять, перестраивать и всячески крутить, таскать к заказчику и обратно, 
и только в после того, как задачи попадаются в ''Sprint'', они превращаются в ''Tasks'' в трекере или просто карточки на SCRUM-доске (иногда в то и и другое). 
Таким образом, для небольшой команды можно обойтись одним ''Excel''-ом (включая печать SCRUM-карточек, для задач и ''User Story''), что и продемонстрировал Дмитрий.

Затем Дмитрий перешел к настоящим трекерам, а именно к <tt>JIRA</tt>, рассматривая ее опять таки, как вполне общедоступный инструмент («JIRA, как мы все знаем, условно бесплатная, на ru-trackerе есть»).

Однако, несмотря на «бесплатность» JIRе (и примкнувшему к ней плагину GreenHopper, рассматривавшемуся [[#Евгений Курышев|первым докладчиком]]) досталось и за ее баги, и за ее фичи:
* Настраиваемый workflow — не нужен, и даже опасен: «Все хотят кастомизацию и получают совершенно неработающее… неработающий workflow»
* ''SubTask''и не меняют статус при закрытии родителя!
* У <tt>GREENHOPPER</tt>-а:
** тормоза! (даже на <tt>Google Chrome</tt>)!
** быстро не проставить результат планирования (свистелки и перделки на AJAX тормозят)
* нет импорта из Excel (если нет административного доступа к файловой системе на сервере)
* нет средней скорости разработки
* нельзя оценить/просуммировать произвольно выбранную группу фич.
* долго и неудобно формируется отчет-таймшит для заказчика. 
…

{{note}} ''Перечислять критику можно долго, если хочется посмотреть подборку критики JIRA, то наверное разумно заглянуть [http://www.trackstudio.ru/products-comparison.html сюда], а за критикой всех существующих трекеров — [http://aefimov.livejournal.com/210078.html сюда].''

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

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

----
{{note}} ''Я лично не совсем понял формулу, но было продемонстрирована живьем группа задач, для которых показана расшифрованная формула''
  Срок выполнения 212.3 дня = (624 часа * 1.58) / (5.4 * 0.86) 
''У меня есть гипотезы, но я в них не уверен — зрители, присылайте [http://belonesox.moikrug.ru мне] свои, потом, может узнаем правильный ответ.''
----

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

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

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

Впрочем, были и критические нотки:
* «… Возможно это не лучшая система для работы product owner-а… с точки зрения интерфейса…», на хабре была более красивая, но там нет интеграции 
{{note}} Вероятно имелся в виду [http://habrahabr.ru/blogs/pm/93137/ Pivotal  Tracker], и у него есть ключевая проблема — нет прав. Вернее нет системы прав, т.е. права есть, и есть они у всех, все могут все.
* «[SCRUM]-карточки печатать и нарезать здесь нельзя…»

 
Народ (несколько участников) интересовала возможность ''фокусированного'' общения между разработчиками и аналитиками с фиксацией «на чьей стороне мяч» (без передачи отвественности за саму задачу). Т.е. не просто поток комментариев, а выделение наиболее важных, требующих обратной реакции — так вот, похоже здесь этого пока нет (ну и видимо, не возникает потребности).
----
{{note}} Вероятно это не очень распространенный кейс, поэтому я поясню (я, [[Участник:StasFomin|Стас Фомин]], кажется понял, о чем спрашивали). В [[Bugzilla|Bugzille]], например, это реализуется через механизм флагов, в частности, флаг «вопрос», который «ставится» на участника (иногда даже представителя заказчика), от которого требуется ответ,  а он, соответственно, отвечает, и «закрывает» этот флаг.  Таким образом, сами вопросы не теряются в стремительном информационном потоке, а ответы на такие вопросы получают  больший приоритет, и работа по задачам, требующим дополнительной информации, не блокируется.
----

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

Под этим соусом прозвучало упоминание еще пары трекеров:
* «Серебряных пуль не существует, зато существует [[Mantis]]»
* «[http://www.otrs.org OTRS], это такое доисторическое животное, похожее на Mantis, 
старый Mantis, ну вот если установить Mantis и долго не трогать то из него получится OTRS».

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

== Резюме ==

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

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

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

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

Ну и под конец, для тех, кто осилил весь текст — оргвыводы. При зарегистрировавшихся 150 участниках, на собрании было порядка 80-100 человек<ref>оценка приблизительная, по количеству  используемых стульев</ref>, и похоже, это оптимально для  нашего зала — никакой  давки и сидения на подоконниках (как на [[Архитектор в Agile (встреча  AgileRussia.ru 2010-03-24)|прошлом  собрании]]), сидели на удобных креслах с подлокотниками и откидными  столиками, не более чем в пяти метрах от ближайшего экрана (два больших  экрана и два мощных проектора). Побежден и шум — докладчик обеспечен  петличным микрофоном, участникам для задания вопросов выдавался радио, и  все это озвучивалось через колонки. 

В будущем, надо будет сделать вменяемую систему регистрации участников, с  отметкой посещения —  так будет удобней планировать ожидаемую численность участников («этот  участник ходит всегда», а «этот только каждый третий раз»), возможно  даже с отчислением злобных «динамщиков». Скорее всего это будет [http://timepad.ru TimePad], с представителями которого удалось обсудить эту проблему [http://kapterev.livejournal.com/685572.html?thread=5804292#t5804292], и которые, похоже, первыми предложат миру такой сервис (и спасут нас от изобретения велосипеда)<ref>Если вы знаете другой сервис с таким функционалом — дайте [mailto:stas-fomin@yandex.ru|мне] знать.</ref>.

== Примечания ==
<references/>

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

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

{{note}} Если мы кого-то упустили — присылайте [http://belonesox.moikrug.ru мне] ссылки на ваши отчеты, я их добавлю.

{{ActualBanner}}
{{replicate-from-custiswiki-to-lib}}

[[Категория:Собрания AgileRussia.ru]]