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

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

Из сегодняшнего дня я вынес пару конкретных техник, из блица Асхата и доклада Юли Нечаевой, которые буду предлагать в компании, отдельными постами, чтобы не мешать информацию. И еще взял на заметку метод коучинга GROW, о котором рассказывал Евгений Афонин.

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

 Что особенно понравилось

 

Техники ретроспектив (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 Доклад про тестирование. По сравнению с предыдущими скучноватый, но зато понятный. Критерии тестирования, измеримые, на итерацию, как тестирование обеспечивает процесс. Измеримость — важна, пример из зала: «Не опаздывать» — не кейс, потому что нужна наблюдаемая формулировка что цель достигнута. И важно мониторить показатели качества не только постфактум, но и в процессе итерации. И другие подобные кейсы и детали качественной организации тестирования.