2013-03-30: AgileDays 2013 - между скрамом и будущим
Конференция AgileDays. Как всегда - на хорошем уровне, много общения и интерактива, живых докладов. Чувствуешь тренды отрасли, открываешь для себя полезные практики. Основных трендов два: разочарование в SCRUM-Канбан и gamification, о них далее. Мне они не так, чтоб нравились, но глупо обижаться на пейзаж за окном, и тем более на само окно, которое его показывает.
А сначала - пара слов о том, зачем я хожу на конференции. Живое общение позволяет реально увидеть и оценить тренды, соотнести между собой. А рассказы об использовании практик в реальных ситуациях, которые накладываются на твою, показывают неожиданные грани практик, о которых мог знать раньше, не предавая особого значения этому теоретическому знанию. А еще выключение из рабочего процесса и целенаправленное восприятие информации иногда производит инсайт, осознание или даже создание новых идей, которые ты решаешь претворять в практику почти немедленно.
Да, сама конференция - многолюдная. 667 участников, 54 доклада. Реально переполненные залы. Были косяки, но ко второму дню организаторы учли уроки, и, главное, организовали трансляцию из второго зала в холл, что позволило желающим слушать доклад хотя бы из-за двери. Как они шутили "fast fail у нас был - значит дальше будет хорошо".
И лично мне очень понравились блиц-доклады, по 15 минут в главном зале. Потому что когда время так сокращается, от доклада остается суть. И даже если она не очень актуальна, времени не так жалко. Так что я бы приветствовал этот формат и дальше.
А теперь - о трендах и обзор докладов, на которых я был.
Содержание
Конференция разочарованных
Ощущение, что нынешняя AgileDays - конференция разочарованных возникло в первый день. Было почти дежа вю - то, что лет 5-6 назад говорили про проблемы традиционного процесса, говорят про agile, scrum: люди не общаются, непонятные метрики. Отрицание цельности, слова про сборник практик, из которых вы сами выбираете (привет, PMBOK). Gojko Adzic, Zuzi Sochova - характерно, но не только они.Рассказы о граблях и неудачах, одних и тех же. В целом это показывает разочарование.
А произошло оно потому, что те люди, которые хотят успешного процесса без приложения головы - поняли-таки, scrum его не дает. Ищут новый такой процесс, тренд - gamification. Да, у тех, кто голову прикладывают - все хорошо, хотя и непросто, Джефф Паттон - яркий пример, Книберг, кстати, тоже, но на конференции было много практиков, которые успешно применяют скрам и другие процессы, ищут решений в рамках них.
Я об этом написал об этом на фейсбук - пост и его копии вызвали одобрение и обсуждение там и устно. И ко второму дню у меня сложилась более сложная картинка. Дело не только в разочаровании тех, кто не хотел применять голову к организации процесса.
Еще - произошло накопление опыта. Стало понятно, насколько люди в среднем могут воспринять и использовать SCRUM, Канбан и прочее. Далеко не так хорошо, как мыслилось авторам и евангелистом. Ну, что поделать, "других людей - нет". Еще надо понимать, что при внедрении процессов имеется явный плацебо-эффект, когда улучшения связаны не с новым процессом, а просто с изменениями, которые служат основой для запуска мозга, осмысления ситуации. И этот эффект напрямую связан с новизной и силой бренда - которая уменьшается.
А еще сейчас при внедрении новичку сложно внести свой вклад в методологию, он во многом ограничен рамками своей компании. Если лет 5-7 назад внедрение SCRUM и его адаптация давала новый опыт не только тем, кто внедрял, собранные грабли и способы работы с ними были интересны всем - опыта ни у кого не было. Сейчас же гуру и тренеры эти грабли опознают, и объясняют, как с ними работать, почти сразу. И даже рассказывают, где это было написано. В результате того драйва от внедрения, связанного с освоением нового не только для себя, а для отрасли в целом - его уже нет. Что тоже вносит разочарование.
А обстановка в отрасли - тоже изменилась. Возросли ожидания заказчиков. И этому способствовали успехи SCRUM и Kanban. "У тех - получается - нам надо так же". А если получалось хорошо - то ожидания еще возрастали, потому что идеальное ИТ-производство - это то, которое поставляет результат сразу после возникновения идеи у бизнеса, тут предела нет, есть только гигиенические факторы сложности смены версий.
Появилось много проектов, ориентированных на производство продукта для рынка. Выполняемых силами небольшой группы людей, на свой риск, во всяком случае на начальном этапе. И наиболее способные и амбициозные люди уходят туда из больших проектов. Именно поэтому тема небольших команд и процесса для них - она очень актуальна. А в больших проектах - остался те, кто остался. Среди них тоже много замечательных людей, которым именно большие проекты нравятся по разным причинам, просто раньше маленьких-то - почти не было.Кстати, особенно много в малые проекты ушло тех, кто умеет самоорганизовываться. Поэтому в других областях их осталось очень мало.
Но как следствие - требования в больших проектах - уже не получается удовлетворить относительно простым способом. Было понятно, чего достичь можно, и если для некоторых проектов это - прорыв, для других - этого недостаточно. Это решают комбинацией практик, строя сложные конструкции, существенно зависящие от конкретных людей, ориентированных на них. И это рождает потребность в новом шаге.
Поэтому в целом люди ждут чего-то нового, по разным причинам. Одни ищут новую серебряную пулю, другие - хотят научиться проще решить более сложные задачи, которые появились, понимая ограниченность существующих инструментов. А понимание ограниченности - тоже разочарование. Я, кстати, отмечал это состояние ожидания нового еще на прошлой конференции, по докладам на темы ценностей - но нотка разочарования тогда не звучала столь явным образом.
Геймификация
Gamification - привнесение в процесс элементов игры, создание движухи. Это уже несколько лет - новый привлекательный тренд отрасли. Кстати, одна из причин привлекательности в том что он - новый и люди экспериментируют. Это, правда, эксперимент на людях, но это далеко не всех смущает. И хотя потенциальные грабли описаны в книгах по психологии, менеджменту и другой специальной литературе - их особо не читают. Попробовать - лучший способ. Тут программисты переносят на работу с людьми свой подход по работе с системами: попробуй, зачем читать мануал.
Но это - поверхностный уровень, а есть и более глубокий, о говорил Максим Коробцев в докладе и мастер-классе.
Индустрия создания компьютерных игр, и, особенно, online игр накопила большое количество знаний о поведении людей. Которые используются для конструирования игр для вовлечения игроков в процесс и удержания там. И эти знания и техники можно использовать при организации реальных рабочих процессов.
Эффективные области применения велики
- борьба с разобщенностью и командообразование
- понимание целей (вне рутины)
- обратная связь, особенно положительная
- работа с личностным ростом
И это - неполный список.
Конечно, надо быть осторожным, потому что у тебя реальная жизнь, а не игра. С другой стороны, online-игры для многих людей - тоже приличный кусок жизни, а никакая не игра. И два-три года работы в компании вполне сравнимы со сроком увлечения определенной игрой. В любом случае, геймификация - лишь инструмент, и он нейтрален, вопрос в целях применения. Можно и отказаться от него, но тогда ты теряешь потенциальное преимущество, получаемого при правильном применении.
Возможно, геймификация - это следующий тренд отрасли, приходящий на смену скраму. Он массово пошел на западе в 2009, и Gartner прогнозирует, что к 2015 до половины организаций, работающих с инновациями, его попробуют. Но при этом в вики там речь преимущественно о гигантах (IBM, SAP, Samsung, Deloitte), среди которых много IT, включая Microsoft. Проблема в том, что качественное применение требует достаточно глубокого понимания, а формальное - слишком опасно. А если люди привыкнут и перестанут разочаровываться, то слишком снизиться и позитивный эффект. И потом, других кандидатов пока не видно, а должен же быть новый тренд, без этого сейчас невозможно :)
А что еще интересного
Еще с конференции я для себя вынес следующие вещи.
DevOps. Это некоторый новый, хотя локальный тренд. На западе возник в 2009, и уже какой-то манифест появился. Относится к устранению стены непонимания между разработчиками, у которых квантованная работа по релизам, и эксплуатацией, живущей в операционном потоке. В России понятие только появляется, и даже Юферев в докладе на эту тему в 2011 на softwarepeople говорил лишь manageability продукта, не употребляя термин DevOps. Соответственно, с этим надо разбираться как с трендом. С фактурой у нас в компании все хорошо, потому что проекты живут в потоке развития и эксплуатации, и разработчики это понимают, тут проблем нет.
Практика simple design XP. О ней рассказывал Вячеслав Москаленко, воспроизводя ее в варианте Кена Бека:
- все тесты - срабатывают
- без дублирования кода
- выражает намерения программиста
- минимальное число классов и методов
Вячеслав подробно рассказывал, что она для него означает, и мне это близко. А актуально мне это, потому что я сейчас много занимаюсь оценкой кода. Представления же о хорошем коде - они разные, и тут много вкусов, а формулировки в виде правил встречаются редко. Кстати, экспресс-обзор показал, что последователи создавали свои интерпретации различной сложности, например, high cohesion and low coupling, и уходя от не слишком формализуемого "выражает намерения программиста".
Доклады, которые особенно понравились
Максим Коробцев (GameTrek) Геймификация цикла непрерывных улучшений процесса или как заставить цикл выполняться Мастер-класс и доклад на ту же тему. Был квалифицированный и подробный рассказ про применение различных методик, наработанных разработчиками игр для организации процессов разработки.
WoW - миллионы лет. И википедия по WoW созданая ими - вторая по объему статей! И эмоциональное удовлетворение.
Геймификация - это создание игровой оболочки, и включение ее в процесс.
Что решаем.
- разобщенность
- понимание целей (вне рутины)
- обратная связь, особенно положительная
Упомянутые методики.
- Повышение уровня, прогресс-бары
- Свобода выбора - но в сценарии игры, все равно окажешься в целевой точке
- Миссии. Наделение фрагмента действий в процессе осмысленностью.
- Виртуальная экономика
- Соревнования. При этом позитивно - вместе против внешнего врага, с конкурентами, а не между собой.
- Открытие контента. Дозированность информации.
Дальше есть смысл смотреть презентацию. Надо раскладывать ваш процесс на принятые термины и можно проводить анализ с этой точки зрения, достраивать. И применять конкретные методы. Дополнительно - проясняем позиционирование. Желаемое поведение может быть через правила игры, а можно - через управление бонусами.
Прокачка умений тоже на это ложиться, многомерное пространство. И дальше можно применять известные модельки.
Никита рассказал - они геймифицировали обучение английскому в одной из школ, и преподаватели взвыли - все ученики стали делать домашние задания чтобы получить всякие бонусы - а их же проверять и оценивать.
Антон Волков (AlternativaPlatform) Свобода и ответственность: Опыт TankiOnline в создании Agile-культуры Совершенно неожиданный доклад. Высокий качественный уровень был виден с самого начала, хотя началось все с вполне понятных вещей.
Внедрение agile (scrum канбан) часто превращается в ребрендинг. Менеджеры изыскивают в практиках знакомое подходящее и начинают использовать dsm как планерку, а ретро как разбор полетов и т.п. И сотрудники быстро это просекают, и относятся соответственно. Не работает.
Примеры ретро. Причины всегда находят, и остается реагировать в стиле кэпа.
- Надо закладывать время на тесты
- Надо писать только хороший код, а плохой не писать вовсе
Сколько раз писали ценности компании. Написаны. Люди их разделяют. И что? Дисциплины нет. Это как люди пробуют пойти в спортзал.
А еще - люди разные. Одним - кончить во-время. другим - код хороший, третьим - процесс. И в этом надо работать. Как?
Собственно, поняли, что есть 4 варианта.
- Жесткий отсев только ответственных. Только рынок не позволит - не найдешь.
- Можно смириться, выросли мы из agile, пойдем в классику.
- Ограничить размер компании, например, 15 человек.
- Их решение - попробовать-таки передать запал стартапа в большую компанию.
После этого и началась неожиданная часть. Рассказ, как они сделали свой вариант VALVe.
Ответственность. Это - не кто виноват. Реально ответственность - она ДО а не ПОСЛЕ. Они поняли, понимали гибкость как работу работу в ближнем свете фар, ведь ситуация меняется. А если ответственно подходить - то это - дальние цели, учет рисков. Среда ответственности. И они стали на это работать.
- Ответственность - нельзя дать, ее принимают, или нет.
- Принятие должно быть в условиях свободы выбора.
- Ответственность возникает при наличии ограничений.
- Ответственность - реально общая. Не бывает, что отдел тестирования ответственный, а директора - нет. Я: не так это
- Ответственность реально воспитывается только через последствия. Я: тут тоже спорно, во всяком случае сложно. Аналогия с детьми уместна.
Про последствия. Тут сложно. Бунт на форуме, пользователи не заплатили - это нельзя просто перекладывать в зарплату разработчиков. Но и изолировать их совсем, как у них было - нельзя. А еще: глупо нанимать умных людей, а потом - указывать им что делать. Стив Джобс
Действия
- Убираем оперативное влияние директоров из текучки. Лишаем права приказа.
- Заодно - переключаем директоров на стратегический уровень. Цели, планирование, работа с клиентами.
- Научились доверять коллективу.
Важно: решения должны прийти к управленцам самостоятельно. Их нельзя навязать. Это был непростой процесс.
Люди сами определяют распорядок дня, и многое другое.
Соглашение - договор о решении задачи между заказчиком (компанией) и командой.
- Критерии завершения - позитивные результаты
- Риски - негативные результаты
- Состав команды, трудозатраты - оценка задачи
Соглашения есть у всех - у директоров, у маркетинга. Это обеспечивает комплексную систему. На поездку на AgileDays - тоже есть соглашение, он его показал. Принципиально: если какая-то из сторон не согласна - работа не начинается. Соглашение - добровольно. По сути, есть внутренние рынки сотрудников по проектам.
Карма. Есть у всех в компании, включая директоров. И, реально, это оценка существовала всегда. В частности у каждого из директоров. И они сделали ее прозрачной. А в соглашении - определяется изменения кармы, для каждого участника ее изменения. Он знает критику, что деньги не мотивируют. Но их карма - она связана с деньгами достаточно сложно.
Результаты
- Есть план работ на полгода
- Прозрачная деятельность. кто, что делает, какие ресурсы. MMF
- Появилась самоорганизация. Сами появляются SM. Пропадает феодальность, потому что дефицит ресурсов команда расшивает
- Ответственность. Резервирование ресурсов. Переговоры по соглашениям - недавно ему предложили scrollbar за три недели
- Команды начали убирать ненужных людей. Команды их не берут, а они не могут взять соглашение в одиночку. И найм тоже "берете в команду?"
- Понимание прогресса
- Бережливое отношение к ресурсам. Личные календари. Слайды он рисовал сам - художник был занят. Начали попадать в сроки. Видно, кто недогружен и кто перегружен
- И именно в этой среде стали появляться agile-практики. Потому что люди захотели быть лучше.
В целом - очень интересно. И еще более интересно - что получится дальше. Потому что сейчас системе полгода, влияние кармы на деньги - только месяц. И понятно, что у системы есть ограничения по области применения. В частности, как только внутренний рынок начинает конкурировать с внешним - ты теряешь преимущество единой компании. Но это Антон тоже понимает, и у них "не совсем рынок". Плюс они - в Перми, и это для них определенное кадровое преимущество.
Антон после доклада больше трех часов отвечал на вопросы про разные аспекты внутреннего устройства, в частности раскрыл пересчет кармы в деньги и многое другое.
Jeff Patton. Co-making Great Products. Обзорный доклад. Начиная от водопада, и далее. На очень хорошем уровне. Я лично это себе вполне представляю, но я знаю, насколько мало людей мыслят на этом уровне и на таком горизонте. Что интересно - SCRUM сначала был просто выявлен в якобы-водопадном процессе. Книга японцев 1986 года, которая зафиксировала реальное перекрытие фаз и активный характер взаимодействия. И уже дальше - раз в реалиях оно происходит все равно так - давайте организовывать в этих реалиях.
Далее - совместная работа, командой. Создание дизайна. Или вы его создаете, или он приходит как требования. Discovery product. Пространство для совместной работы. Схемы на стенах - чтобы визуальные образы были перед глазами. Чтобы разделять понимание. Как результат - команды любят и думают о продукте. И это провоцирует открытия в командах - за счет вовремя брошенного взгляда.
Вячеслав Москаленко (Luxoft). Простота Дизайна - не раскрученная XP практика Люди считают, что их проекты - тяжелые, и это оправдывает сложность реализации. И у него часто встречаются проекты, которые напоминают запутанные конструкции, сложные связи и дизайн. Поэтому он любит практику simple design XP, которая реально развернута слабо.
Практика, как ее сформулировал Кен Бек, включает в себя следующее.
- все тесты - срабатывают
- без дублирования кода
- выражает намерения программиста
- минимальное число классов и методов
А дальше Вячеслав рассказал о содержании пунктов, как он их понимает.
Про тесты. Пишите, не пишите большие и сложные - а то будут часто падать и будет сложно читать. К тестам требования простоты дизайна тоже применимы. Примеры тестов - в BDD, не очень unit и это тоже важно.
Не покрывайте тестами все классы, делайте функциональные тесты на ключевых точках.
Без дублирования кода - в пользу уменьшения количества в целом. Шаблоны проектирования. Я: хотя пример там тоже увеличивает код у него, на мой взгляд - не слишком хороший в коротком виде - но из объяснений понятен.
Выражает намерения программиста - включая возможность хорошего code review. Именование - сюда же. Clean code.
Минимальное число классов и методов. Не плодить сущности, не бояться больших кусков кода, разделяя просто потому что большие. Примеры - стратегия с одной реализацией, библиотеки которые не используются, дополнительные абстракции "на потом". Даже стандартные интерфейсы библиотек, если используются ограниченно-специализированно - можно обернуть.
Стас Фомин (ROSALab) Информационная алхимия Стас зажег. Рассказ под видео, с активным рядом на заднем плане. Об инструментах эффективной совместной работы с информацией распределенно. С кейсами планирования конференции и работы у них в команде. Современные online collaboration инструменты. Логированием времени по потоку распределенных сохранений. Комбинированная запись совещаний - mindmap + видео в несколько потоков с автоматической обработкой. С мониторингом распространения через фиксацию чтения статьи.
Николай Алименков (XP Injection/ZoralLabs) Портрет профессионального разработчика Очень хороший доклад про то, каким правильно быть профессиональному разработчику. С учетом трендов современного мира, таких как облачная разработка и распределенная команда - они ставят свои акценты. Включая умение работать с разными людьми. В общем, очень симпатичный refresh правильных ценностей.
Игорь Клейнер (Майкрософт) Гибкая разработка - психология и псевдопсихология? В презентации - "мифы и рифы". Рассказ был о типовых ошибках интуиции, двух самых распространенных
- после этого не значит из-за этого
- регрессия к среднему
Про третью - эвристика доступности - сказал, что прочитаем в презентации сами, это был блиц.
Мне ошибки известны, более того, иллюстрации первой ошибки, на мой взгляд были странны и скорее касались некритичного отношения к мнениям авторитетов. Ну разве что подразумевалось, что это сами авторитеты впали в такую ошибку.
Как быть: научный подход, здравый скептицизм, общечеловеческие заблуждения и ошибки, защитные средства...
И одна методика рассказана. Meta Learning, на стыке математики и психологии. Математик разработал мат.модель. Психологи проверили на практике, потом - в бою. Одна из характеристик, которая снимается максимально просто - отношение позитива к негативу Индекс Лосада, он должен быть 2.9-11.3. Считаем на любой встрече отношения числа позитивных высказываний к негативных. Отношение не должно быть меньше. Вообще подробности и даже картинку с моделью можно посмотреть здесь, это сайт автора.
А потом - был обзор книжек.
Павел Шишкин (Яндекс) Коллектив Яндекс. Картинок и Adoption Curve 30+ человек, год работает канбан. Команда растет, ретро скучно, печальки на стендапе. За год накопились ракушки, их надо почистить, плюс собрать новое. Для улучшения важно признание результата людьми. А команда большая. Поэтому они взяли методику из маркетинга, двухуровневая схема: качественный опрос, потом количественный и провели исследование.
Качественно - один на один, меньше говорить больше записывать. Часто молчуны выдавали неожиданно глубокие проблемы и возможные решения. Для опроса достаточно 5-10 человек из любой команды. И опрашивающих должно быть несколько - разный взгляд.
Спрашивали
- Чем довольны, что нельзя убирать
- Какие проблемы
Кластеризовали. 10 плюсов и минусов. Потом - голосование на вики (да/нет/да очень/...)
Получили топ-3 минуса и топ-3 плюса, он их привел. Некоторые формулировки странные - потому что они сохраняли их в исходном виде, от опросов. Если хочешь признания результатов, как раз важно не менять.
С минусами - начали работать. Например, по инфы о причинах блокировки задач. Оказалось, часто человек просто перебирает задачи, перегруз. Плюсы - озаботились сохранить. Например, было оценено, что все представляют, что происходит в сервисе. Механизм - 2 раза в неделю стендап на всю команду 30+ и он давал эту функцию. Понятно, что были идеи такой стендап отменить.
Adoption curve - смотрят на принятие изменений. Делят на Adopter и Laggard Показывает кучность команды. Может там слишком разные люди. Несколько людей разметили, посмотрели их ответы на вопросы и все остальные. За счет этого выявили скрытых адоптеров, в том числе скрытых. Смирились с некоторыми laggard'ами - не ходят на стендапы - и ладно. А еще - выяснили. что есть неадаптированные, для них - курс молодого бойца.
Анна Мининкова (Яндекс) Как agile команде выжить в enterpise? История о том, как agile-команда перешла в сегмент яндекса, где издавна был водопад. И запустили партизанское внедрение снизу. попробовали разные практики (scrum, канбан), попробовали сменного скрам-мастера, экспериментировали с требованиями.
Может быть противодействие руководством, которому удобно в водопадном мире. Совет - не берите знамя и не идите на баррикады. Показывайте практики, общие. Требования перевели на истории, стендапы называют статусами и много чего. Не употребляют спринт и скрам-мастер.
Но водопад - он все равно подстерегает. Водопад в начале. Проблемы на старте - многотомные спецификации. Будьте краткими, создавайте продуктовое видение на этом этапе. Не относитесь как к дурацкому требованию. Водопад в конце. Приемочное тестирование. Воспринимайте его как итерации, замечания - как задачи. Водопад в тандеме - когда есть компонентные команды-партнеры. Хинт - звать менеджера на планирование спринтов. Партнер может потребовать больших митингов и фиксации интерфейсов. Адаптируйтесь.
Люди, модель Джонсона. Консерваторы, Прагматики, ранние последователи. Прагматики: Докажите мне/Наблюдатели/Скептики. И прагматиков можно перетянуть, последовательно показывая достижения.
Стройте минимальный жизнеспособный процесс. Используйте общезначимые практики, в agile их много.
Наталья Ядренцева (targetprocess) Вижу! Вопросы визуализации очень важны. Можно видеть в целом, быстро принимать решения. Можно читать сложные истории очень просто.
Виды
- Сети. Включая майндмеп. Зависимости и прочее. Представление структуры проекта, например.
- Карты
- Работа с многими переменными - самое сложное.
- Примеры всяких индексов в для рыночного состояния. Самая простая - когда две переменные, частотные диаграммы и прочее.
- Показ корреляций. Только надо правильно выбирать переменные: матрица количества тесткейсов на фичу с количеством багов - не характерна, надо добавить размер фичи.
- Пример - доска. Стикеры - проекты, их фазы, и еще разноцветные стикеры по бюджету и прочему. И по командам.
- Таймлайны.
- взаимодействие героев властелина колец - говорят, висел в инете, забавно.
- таймлайны выпуска фичи - бумага и разноцветные стикеры на ней, факт. И тоже комплексная инфографика - и команды и прочее.
- Комбинация. Доска с фичами, а внутри прогресс-бары или спарк-лайны.
Я потом спрашивал - они делают свой продукт для поддержки agile-процесса. Белорусская компания, но продукт на западный рынок - Штаты, Европа. С 2005 года, когда это было новым и востребованным, и сейчас конкурируют за счет клиентской базы, есть облачная версия. Визуализация как раз - текущий приоритет. Но в докладе продукт вообще не упоминался.
Остальные доклады
В хронологическом порядке.
Асхат Уразбаев (ScrumTrek) Современные тренды разработки ПО - это должен знать каждый(Agile, Lean, Lean Startup, Gamification) Тоже обзор развития процессов, тренды. Это доклад для начинающих, который обычно ставят в начале Agile Days параллельно основному докладу. Не так глубоко, как у Джеффа - и по уровню и по историческому горизонту.
Анна Обухова (Luxoft) Скрам-Мастер технологии влияния: как создать команду изнутри Практическая производственная психология. Начальник-подчиненный против самооценки, агрессия, выливающаяся в саботаж и так далее. Зачем записывать решение на доске. Для меня - на достаточно очевидном уровне. Но зал тоже реально переполнен.
Gojko Adzic. Reinventing software quality. Про agile с маленькой буквы - который здравый смысл. Для начала было много про недостатки agile. При этом часть из них - те недостатки и опасности, о которых с самого начала говорили как об имеющихся граблях формального внедрения. А другие - развились позднее, но характерны вообще для процессов без применения головы, как многочисленные ненужные метрики - эта общая болезнь менеджмента, и что agile ей тоже заразился - не его проблема. Много рассказывали на забавной метафоре поездки из Питера в Москву, где вместо выхода - поставка километров пути. Например, что время поездки ничего не говорит о приближении к цели, хотя меряется проще.
А дальше - переход к ценностям. Которые упрощенно сводятся к бизнес-целям, которые должны быть в каждой userstory. Что цели чаще смещают, заменяя способом, который не очевидно ведет к цели (вместо увеличить продажи ставят увеличить число рассылок). И про измерения как средство договаривать бизнесов, когда они не могут согласовать цели: оцениваешь риск недостижения и все ясно. По-моему, крайне сомнительно. В общем, мне не слишком понравилось.
Кирилл Климов (Люксофт) СанФранциско-Киев: история внедрения распределенного проекта 100+ Рассказ о распределенная разработка, разработчики в Киеве, PO - Сан-Франциско и Женева. Команды - на одном продукте, есть продукты на несколько команд - тогда один PO и Backlog. В командах - разработчики, тестировщики. Proxy PO. Различные инструменты. На мой взгляд, все рассказанное - подходы, способы, инструменты - достаточно известно и описано, никаких особенностей в докладе не было. Просто история.
Олеся Лемешко (Центр финансовых технологий) Рождение и Жизнь в переходный период Agile-команды – через тернии к звездам Еще одна история внедрения scrum. C понятным провалом первой итерации, на которой все было как всегда, но местами называлось по-другому. А потом занялись командным духом с движухой вокруг...
Zuzi Sochova (Lotofidea) Agile communication: Communication conspiracy Доклад о том, что коммуникации - нужны, а то все уткнулись в свои компьютеры... Об этом писали и говорили на заре agile, и даже много раньше, и в докладе лично я не услышал ничего нового, более того, сами проблемы мне показались устаревшими.
Алексей Пименов (R-Style) Стереотипы на слом. Что придётся сломать при переходе к кросс-функциональным командам. Куча гадких стереотипов о том, как плохо люди воспринимают друг друга, и о том, что все это придется сломать, чтобы сделать из них команду. Не жизненно, потому что если они так воспринимают - команды не получится. А если это лишь легкий налет непонимания, то сломать - совершенно неверное слово и действо. Да и сами стереотипы гротескны и в жизни - не встречаются.
Никита Филиппов (ScrumTrek) Менеджер - глупая идея! Доклад о том, что менеджер, который единоличный руководитель - глупая идея. Я тут не согласен, она не глупая, просто людей, способных стать хорошими менеджерами в ИТ - мало относительно потребностей отрасли. А позитив был в том, что менеджер должен быть как хороший продюсер, продавать результат программиста за кучу денег, ну и себе может немного брать. Как у Битлз. А это, по-моему, общая мечта непризнанных гениев - чтобы они делали, что хотят, а кто-нибудь это продавал за большие деньги и скромный процент,потому как вдруг оказалось, что они реально гении. И она не сбывается, потому как большинство гениев - вовсе не зря непризнанны.
Алексей Пикулев (Agile Technologies) Управление рисками в Agile-проектах С рисками должен работать менеджер, но его в agile нет. Но реально agile содержит кучу инструментов работы с рисками. И они попробовали инструменты.
- Karmas day - для вовлечения команды. В каждом проекте есть и положительные риски, возможности - их можно развивать. И дальше доска, и чтобы команда сама называла риски, примеряя их.
- Качественный анализ, Количественный анализ (вероятность на ущерб). А дальше можно меры противодействия тоже оценивать, и сравнивать. И таким образом обосновывают помещение в PBL задач по предотвращению риска.
- Задачи по предотвращению риска - берите в каждой итерации.
В целом оно - метод. Можно и так работать.
Дмитрий Паньшин (Афиша) Темная сторона Agile: история о том, как Agile не помогает. Еще один докладчик рассказывает, как они думали, что agile - простой процесс, а потом поняли, что голова нужна. В докладе много конкретных кейсов, только, увы, без диагностики - в чем, собственно, ошибка. А по-моему как раз в том, что во многих случаях не думали.
Даниил Колесников (Объединенная компания Афиша-Рамблер) Как перестать мотивировать персонал Что для творческих задач мотивация деньгами не работает. Что нужны ценности компании. С кем вы бы хотели работать. Профессионализм, Общие интересы, Ирония... Тем кто приходит на AgileDays это очевидно, а те, кто думает иначе - туда не ходят. Так что получается доклад кэпа.
Надежда Свирновская (ExigenServices) Velocity как инструмент планирования и управления проектом: предсказываем, измеряем, оцениваем. Опыт SM и ProxyPM. В докладе - правильные и работающие методы мониторинга скорости проекта. И ценные - как оценить в условиях неопределенности, или без команды.
Но эмоционально впечатление - тягостная, такая жизнь под давлением, с постоянной погоней за скоростью, чтобы не вывалиться из сроков и бюджета, когда все остальное - где-то в соседней жизни... У нас такого - нет, при том, что местами мы работаем в более жестких условиях, с изъятием ключевых персон на новые стартующие проекты, на которые к тому же команды нет, а сроки - есть. Потому что мы поставляем ценное бизнес-value, а тогда остальное - прикладывается при переговорах из совместных интересах.
Виктор Стрелков (Позитив Текнолоджиз) Внедряем SCRUM по SCRUM: гибкий подход к внедрению гибких методологий. Внедрение agile-процесса вместе с TFS, который выбрали внутренним тендером. Не только для разработки, но и для процессных подразделений компании, таких как бухгалтерия. Само внедрение тоже было организовано как agile-процесс. История с ожидаемыми методами и результатами. Хотя клубы SM PO TDD и другие, которые тоже появились - не слишком распространены.
Интересно, что внедрение скрам было прежде всего как способ геймификации и удержания персонала, без этого начали смотреть на сторону. А потом уже долгосрочное планирование. А также однородность технологий, экспертные центры.
Наталья Тренина (SCRUMguides) Feedback for good - как улучшать культуру обратной связи в команде Мастер-класс с нормальной учительницей. Класс чисто коммуникативный, разговоры, споры по утверждениям. После Джеффа - пресно. И даже после Орлопанков. Но участники наверняка получили много ценного.
Алексей Кривицкий (SCRUMguides) Новейшая история менеджмента. От эры стагнации к периоду ренессанса. В начале - о том, что компания с функциональной организацией, передачей продукта и KPI работает только за счет горизонтальных связей по низам, а то развалилась бы. Что, по-моему, не подтверждается практикой, а в теории выглядит так только если предположить, что топ-менеджмент там - дебилы. Что опять-таки, большая редкость. Кстати, Алексей уподобляет такую конструкцию феодализму, забывая что феодалы - натуральное хозяйство, никакой передачи продукта, так что феодализму больше соответствует SCRUM.
Дальше пошло про Битлз. В пику Филиппову: продюсер - хорошо, но на самом деле менеджеров было два, один управлял технологиями, другой - результатом, а еще куча самоорганизации.
А вообще он считает, что должно быть 3 менеджера: do rights thing, do things right, do things better. Ну и предлагается дальше матричная структура, с одной стороны - те, кто управляет продуктами, с другой стороны - те, кто управляет специалистами (аналитики, разработка, качество...). И еще коучи. Вроде правильно, но реально матричная структура - это непросто, и картинки тут явно недостаточно. Потому как практически вопрос разделения ответственности, разрешения конфликтов и умения договариваться. И сложность именно в этом, а тема - не раскрыта.
Вместо этого - переход к типичным ошибкам, например, что не надо менеджить проблемы, назначая каждой отдельного менеджера. Да, не надо, но как связано с предыдущим? И почему тогда было про трех менеджеров, чем качество и скорость - не проблемы? Так что эклектика в докладе присутствует в большом количестве, а работающие практические конструкции - не очень.
Дмитрий Андреев. Опыт ALM Rangers Рассказ про TFS и его внедрение. Включая ограничение кастомизации, управление ей. Но вот основной посыл тут: ничем вы не особенные, не выпендривайтесь. А это - пренебрежение в исходной позиции, мне лично - не нравится. Особенно от того, кто внедряет процессы.
Владимир Завертайлов (Сибирикс) Геймифицируй это: игровые механики в процессах повседневных процессах Зал совсем переполнен, даже сзади не приткнуться. А доклад - набор всяких практик. Типа есть проблема: И программист работает, молчит на ретрах, потом увольняется. А давайте повесим доску с портретами менеджеров и красными-желтыми-зелеными кнопками, где каждый может проткнуть менеджера, и будет еще такая обратная связь.
При этом еще практики - потенциально опасные, очень легко спровоцировать конфликты, уменьшить настроение. Итого - рассказ об экспериментах на сотрудниках-кошечках. По-моему, такая геймификация - это свидетельство непрофессионального отношения к людям.
Тимур Маркунин (IBM) Опыт внедрения agile методологии в IBM Rational. Поддержка собственными инструментальными средствами Неплохой, но скучноватый рассказ про особенности agile в больших организациях, таких как IBM. Особенности в части планирования и выпуска версий, правда нарисованы, а не раскрыты. Достигнутые при внедрении результаты - оперативность реакции на запросы.
Андрей Ребров (ScrumTrek) DevOps - очередное красивое слово или следующая ступень эволюции? Введение - модель человеческих отношений, проблемы неприятия ответственности. Разница между разработчиками с проектной, этапной деятельностью и эксплуатацией, админами с работой в потоке задач. Эта разница воздвигает стену непонимания, коммуникаций. Эту стена - мешает, ее надо разобрать. Идея решения - на основе ценностей, которые разделялись теми и другими. Правда, дальше пошел некоторый флейм про деградацию ценностей и опасность формального подхода. Для меня интерес в том. что услышал новое слово, погуглил и посмотрел материалы.
Никита Ефимов (Wrike, Inc.) Как найти время на юзабилити-тестирование во время спринта Хороший доклад про юзабилити-тестирование. У них - мобильное приложение. Для начала - про типовые отмазки: долго и дорого, много людей, сложно анализировать, спецоборудование, пользователи-то по всему миру... А потом - как они поступают.
Реально - надо тестировать, и не ждать готового функционала - главное. Чаще, на том, что есть. Реально они провели много тестирования уже на бумажных постановках интерфейсов для мобильных телефонов. Макеты и прототип - очень хорошо. Да, все надо делать уместно, на бумажках - тяжело тестировать (зато - рано). У них тестируют группа пользователей. Начиная с бумажек.
Тестировать уместно 2 раза в спринте. Сначала - гипотезу, потом - исправление ошибок. Почему-то исправление ошибок часто ухудшает ситуацию. При этом нужно планировать, на регулярной основе. Только не понедельник и пятница.
Тестируют сначала - стейкхолдерам и команде. Казалось бы, очевидно. Но - забывают. Стейкхолдеры могут забраковать, потому что конкуренты сделали так же. А команда - потому что суперсложно. Дальше - лояльные пользователи. Если продукт новый - тогда персоны. Можно их поискать рядом. И не надо 100 людей, 3-4 человека дадут 70-80% проблем. И маленькие кусочки, не полчаса, а 5 минут, кусочек. Правда полное тестирование, не только кусочки - тоже надо, но это - отдельно. А мобильное приложение - просто web-камеру ноута направляешь на планшет или телефон - и через скайп видишь, как работаешь.
Александр Паздников (Positive Technologies) Качество включенО Жуткий проект. Где постоянно искали баги, делали заплатки. Развитие - только 20% Команда работала интенсивно, но неэффективно. Сбежать на новую работу - не вариант, потому что в других местах все так же. Уверенность. По-моему - ложная, у нас - по-другому, хотя может он просто сильно сгущал краски.
Выход из ситуации - всегда личный выбор. Вытащить себя из болота надо самому. И если ты не делаешь его сам - его сделают за тебя.
Главные практики: инспекция кода и модульное тестирование. Все. Инспекция кода - что делаем сначала. Инспекция заодно помогает смириться с кодом. Модульное тестирование - выбрать фреймворк и настроить. Убивают протухание, крупные тесты и 100%покрытие, особенно когда это самоцель.
В целом симпатичный доклад, а настрой автора вызывает уважение. Но вот конструкцию "сделать достойную работу вопреки глупому начальству", я считаю неправильной. Лучше пойти туда, где это востребовано. А еще эти практики - только начало. По опыту - их недостаточно для поддержания качественного продукта, хотя, конечно с ними - сильно лучше, чем без них.
Алексей Пименов (R-Style) Agile Management. Теория и практика спасения крупного проекта История спасения крупного проекта с применением разных правильных практик. Практик, в общем, много, они - известны. Стена плача, roadmap проекта, открытая политика управленческих решений. Пересмотр управленческих решений - подобно законам, они тухнут.
Все это не значит, что их легко было применить, но эта часть как раз не раскрыта: просто впечатление, что Алексей их знал, а те, кто проект завел в плохое состояние - не знали, глупые были. Может, оно конечно так, но часто ситуация сложнее.
Александр Мартюшев (АСКОН) Коммуникации - жизненная сила IT проектов Проблемы понимания документов. Автор - понимает. А читатели - не всегда. Неэффективная коммуникация по электронной почте. Многодневная с отступами. почему? А потому что важно все прикрывать. Но! если достигаете двух целей: прикрыть и договориться, то не достигается не одной. Не надо смешивать. Договоритесь, а потом - зафиксируйте. Есть инструменты чтобы договориться, чтобы зафиксировать, чтобы визуализировать, не надо все смешивать. Для эффективных коммуникаций - чаще коммуницируйте. Перевертывающийся флип-чарт - зло. Вешайте на стенах - чтобы было перед глазами. Все правильно, но это первый уровень. Когда он пройден, может возникнуть избыток коммуникаций, и вот тогда есть реально сложная задача поиска эффективной комбинации из письменной и устной коммуникации, своевременного переключения между разными формами.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.