Закончилась конференция Agile Days-2012. Второй день был определенно не хуже первого. В нескольких докладах я услышал конкретные идеи, которые можно применить на практике, другие - влекли размышления. Так что, если говорить о конференции в целом - она удалась. И по реакции других участников, они почерпнули для себя много нового. Потому что в целом конференция предназначена все-таки для более молодых, ищущих новые пути и осваивающих новые идеи. Это было видно и по реакции зала на доклады, и по активному общению.

Сегодня был доклад Коли Гребнева из нашей компании про эффективные обсуждения. Доклад был в тему, слушали, задавали вопросы, обсуждали. Потому что тема эффективного проведения совещаний, включая те которые входят в SCRUM - ретро, планирование, DSM - она актуальная.

Дальше про доклады, разделенные, как и вчера, на две категории - что особенно понравилось и все остальное. Пара последних слотов отсутствует, потому как сам продуктивно общался по разным темам.

Техники ретроспектив (openspace)

Совершенно неожиданно случившийся openspace с участием Дэна и Линды на тему техник ретроспектив. Проходил по английски. В целом конструкция была понятна, интересны различные техники для старта:

• Идеи - не высказывать. Каждый пишет на стикере и вывешивает на доске, потом вместе обсуждают.
• Начинать с самооценки
• Стартовать в парах и уже оттуда - нечто предлагать
• Для оценки идей - разноцветные карточки для оценки (angry-красная, happy-зеленая, surprise-желтая и т.п.)

А еще был экспрессивный спич Линды на тему того, что для ретро, дескать, жалко времени (2 часа на 2 недели).

Надо сказать, что накладные расходы на SCRUM - вызывают проблемы при общении с некоторыми заказчиками. Но на самом деле, проблема больше в том, что они - четко отделены, и потому их легко посчитать, в отличие, например, от обычного управления, в котором их запросто можно растворить в прочем. А раз так - то они легко поддаются примитивному сокращению - против чего SCRUM категорически и правильно возражает. Но в целом при жестком timebox'инге имеем на 2 недели: 2 демо + 2 план + 2 ретро = 6 часов (7.5%), плюс 0:15*10=2.5 часа DSM (3%). Правда, следует признать, что по практике в нашей компании выдержать такой timebox - весьма сложно. Но это как раз поле для улучшений...

Юлия Нечаева, Наталья Курашкина. Создание инструментов повышения качества со стороны тестирования Очередной шаг развития тестирования в INNOVA, этот рассказ был не только про отдел игр, но и про другие проекты. Тестирование как сложная и организованная деятельность. Это совсем не то, что Тестер, тут во многом управление и аналитика, нацеленная на качество. Тестировщики - знают, что надо протестировать, и организуют этот процесс. Верстку дизайнер тестирует лучше, PO и целевые пользователи лучше знают, что именно ждут от этого релиза и т.п. Тестировщики пищут автотесты на основе unit-тестов, которые пишут разработчики - те используются как заготовки и комбинируются! Автотест пишется так, чтобы воспроизводимость была быстрой. Тестирощики делают среду тестирования и держат ее. Это - дорого, но затраты - окупаются.

А еще тестировщики - знают, где имеют обыкновения водится баги. Анализируют это. Например, дизайнеры - на маках, и потому в IE верстку часто не смотрят. Зная места - их смотрят сначала. А еще - ведут активную работу чтобы устранялись причины. Чтобы релиз на тесты приходил без багов. Через ретро, но это тяжелая артилерия. Лучше - формулировать улучшения как задачи и вкидывать их в команду, в PBL. Владелец задач - тестировщики.

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

Дмитрий Лобасев. Когда компания мешает работать Блиц про антипатерны компаний, в которых не стоит работать. О стремлении к стабильности, когда корпоративная культура затягивает как болото. О том что люди работают "а куда я пойду: жена, ипотека", и это не в 50, а в 25 при нынешнем дефиците на рынке труда программистов. Очень правильно.

Асхат Уразбаев. Процесс улучшения процесса улучшения процесса Блиц о применении идей улучшения lean к самому agile-процессу. Две конкретных идеи. Первая - к ретрам применили Value Stream Map, получили путь: Проблема - Анализ - Изменение - Реализация - Сделано, который дальше визуализировали доской, на которой еще Сделано поделили на Круто и Отстой. Важно: это не задачи на улучшение, которые принимают по результатам ретро, карточка на доске появляется как только заметили проблему. А дальше - живет, на ретро принимаем решение, что с ней делать, а анализ может и раньше пройти. В результате процесс улучшений визуализируется и проявляется, и это хорошо. Вторая идея - доска для DoD: поделить тезисы DoD на Используется-Пилотируется-Идея, фиксировать статус.

Евгений Афонин. Модель GROW – мастерство вопросов Доклад начался с вопроса - какой вы знаете процесс с перечисленными ценностями (нацеленность на результат, открытость, уважение и так далее), но не SCRUM. Оказалось - коучинг. Процесс управлется заказчиком - самим коучимым. Ценности - такие же как в agile. Поэтому его легко и естественно применять.

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

Докладчик рассказывал про модель GROW - Goal-Reality(проблема)-Options(решение: пути, способы, экология)-Way forward(план решения, первые шаги). Достаточно подробно, с шагами применения и результатом. Я взял на заметку, хотя пока такая деятельность - вне моих интересов.

Как я уже отмечал, практически все доклады - хорошие, вызывали живую реакцию зала. Просто лично меня цепляло не все, во многом потому что я много хожу на конференции и вообще давно и активно работаю.

Dan Rawsthorne. From Usability Studies to Stories Дэн рассказывал про технику работы с требованиями - превращение usecase со сценарияями в implementation story различных типов, которые идут в разработку. Приводя достаточно развесистую метамодель, описывающую это представление. Структура: usecase-scenario (some has backbone - architecture and so on) implemented stories - various Storyotypes: for main scenarion, alt, backbone, improve (add business rules), redo.

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

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

Антон Бевзюк. Бодрое планирование Зашел на кусочек, он был параллельно с Дэном. Антон рассказывал о конкретном успехе - как планирование релизов довели до 1-2 часов, а раньше не успевали за день. О подводных камнях и проблемах, которые они проходили. Закладывают 20% на запас и в целом - успевают. Внутри у них итерации без планирования, задачи разбиваются на технические таски, которые примерно на 2 часа, не оцениваются, а если зависают - то разбираются.

Из любопытного - Антон отметил парадокс шкалы Фиббоначи: разбив историю на 8 получаешь две по 5. Выделив маленькую историю на 2 из 8 - не уменьшаешь большую. Это непривычно, но соответствует физике процесса.

Алекс Трошин. Как уговорить марсианина: практические примеры В докладе мне сильно не понравилась метафора: разработчики суть туземцы, к которым пришли мореплаватели - заказчики и руководители, включая SM и PO. Или, проектируя на наше время - не мореплаватели, а марсиане. Которые все равно обеспечат что им надо, и единственный шанс для разработчика - научиться говорить на их языке.

Лично мне такая метафора активно не нравится. Тем более, что языки этих марсиан были гротескно-упрощенные. И хотя я понимаю, что в некоторых организациях это - правда, я бы полагал, что там просто не надо работать.

Дмитрий Овечкин. SCRUM + KANBAN = SCRUMBAN. Лучшее из обеих методологий Весьма интересная конструкция agile-управления для компании, в которой проекты web-разработки идут через специализированные отделы - дизайнеры, кодеры, тестировщики и так далее.

Инструменты:

• Канбан-доска, отражающая путь
• Оценка задачи по каждой стадии
• Общая оценка, учет сдвига и учет мощности ресурсов - получается срок. И 30% резерва.
• Большой проект - делят на спринты, но это скорее приоритезация, обеспечение порядка. Нет жестких границ истории по спринту.

Антон Зотин. Где моя спецификация, чувак? Вполне понятный доклад для начинающих о том, что работа с требованиями через активные коммуникации - гораздо эффективнее чем через документы или почту. А если лично нельзя - есть эффективные технические средства. И о том, что слона, то есть большую постановку, надо есть по частям. К сожалению, у всего этого есть обратная сторона - помимо коммуникаций нужна фиксация существенных моментов на будущее (схемы, концепции), декомпозиция осложняется связностью системы и тому подобные трудности. И мне интересен уже этот уровень рассмотрение, а до него не дошли.

Александр Мартюшев. Необходимые навыки технического лидера в Agile проектах Тоже вполне понятный доклад о том, что надо бороться с постепенно возникающим кошмаром дизайна в инкрементальной разработке. При этом на каждом шаге мы имеем локальную оптимизацию. Вопрос в том, когда начинать исправлять. Когда стал кошмар - уже поздно, во-первых дорого, а во-вторых уже раньше на тяжелый дизайн были накладные расходы.

А еще есть психология. Социальные эксперименты по помощи. Один человек - 75-85% помощи, группа - 35-40%, вероятность уменьшается, а группа с подсадными равнодушными - 10%. Поэтому если вы в код добавили глобал, не удивляйтесь, что добавиться вторая и третья. Так же: вы увидели код, он не понравился, решили - исправлю потом. Другой сотрудник - это решение скопировал. И мусор распространяется. Теория разбитых окон: одно разбитое окно провоцирует другие, потом начинается мародерство. Подтверждено многочисленными экспериментами. При чем там есть корреляции, одни нарушения влекут другие, глобал провоцирует плохую обработку исключений.

Поэтому, с учетом психологии, надо реально исправлять сначала. И речь шла о конкретных приемах по исправлению. Правда, касались лишь технической стороны - как быть, если в моменте исправить нельзя или не видно решения. А на самом деле, проблема в том, что взгляд на качество кода у разработчиков реально разный. И, если уж речь зашла о психологии, то вопрос как с этим бороться - не далеко праздный. Код, вполне хороший на взгляд одного - неприемлем другому. И при любом решении будет провокация того самого гниения, на которое Александр указывал в обосновании немедленного исправления ситуации. Так что непросто оно.

Андрей Бибичев. Фрактальная природа IT-проектов Блиц про бесконечное увеличение размера проекта по мере углубления в детали за счет проработки и реализации всяких экзотических и дополнительных ситуаций, о которых, в общем-то не просили. Любопытно, но не более, в отличие от прошлогоднего блица о Пуассоновском горении сроков.

Стас Калканов. Инвалиды офисного труда или как не умереть в офисе Блиц об ужасах, кот орые проистекают из сидячей работы в кондиционированных офисах. Медицинские страшилки без особого выхода. Жить вообще вредно - от этого умираешь, и часто - больным. Позитивный лозунг: думайте больше - так вы сжигаете калории!

Наталья Руколь. Командная работа над качеством в Agile Доклад про тестирование. По сравнению с предыдущими скучноватый, но зато понятный. Критерии тестирования, измеримые, на итерацию, как тестирование обеспечивает процесс. Измеримость - важна, пример из зала: "Не опаздывать" - не кейс, потому что нужна наблюдаемая формулировка что цель достигнута. И важно мониторить показатели качества не только постфактум, но и в процессе итерации. И другие подобные кейсы и детали качественной организации тестирования.