в каком случае можно отменить demo agile
Процессы по Scrum. Демо спринта
Продолжаю серию статей про Scrum. В прошлый раз мы рассмотрели, как выполняется ежедневный Scrum-митинг, читайте об этом здесь>>
Вспомним, какую ценность дает возможность команде работать короткими спринтами? Целью работы по спринтам является получение быстрой обратной связи от владельца продукта по тому, что сделано командой за спринт, а это, в свою очередь, дает возможность уточнения требований к продукту проекта.
Мне очень нравится эта практика, т.к. команда не тратит много времени на «причесывание» ТЗ, а работает непосредственно над продуктом, создавая быстрые прототипы и показывая как это работает. Однако, не все заказчики проектов готовы смотреть части продукта, а не готовый полностью продукт. Поэтому прежде чем что-то показывать представителям заказчика, скрам-мастеру лучше объяснить им, что при работе по скрам не стоит ожидать законченных и выверенных решений, т.к. команде важно получить быструю обратную связь и если что-то сделано не так, подправить это в следующем спринте.
Что делать, если Вы, как скрам-мастер, понимаете, что владелец продукта и его коллеги не готовы смотреть что-то незаконченное или полусырое? Я в таких ситуациях предпочитаю проводить демо не по окончании каждого спринта, а по завершении какой-то логической части продукта. Да, это совсем не в духе скрам, но не отменять же из-за того, что владелец продукта не может смотреть на незаконченные вещи, работу по скрам?!
Честно признаться, мне жутко нравится прототипировать, и я использую этот подход очень часто и не только в бизнесе. Я заметил, что мне гораздо проще обсуждать требования к чему-то, когда есть какая-то упрощенная модель этого чего-то. Вместе с тем, я понимаю, что концептуальное проектирование больше подходит интуитам, чем сенсорикам. (О том, кто такие интуиты и сенсорики, подробнее читайте здесь>> )
Таким образом, знание MBTI мне помогает определить типологические особенности владельца продукта. И, если я понимаю, что он сенсорик, то я не буду ждать от него положительной реакции на мое предложение просматривать концептуальные (читай «сырые») прототипы частей продукта, над которым работает команда проекта. Для сенсориков я буду предлагать смотреть достаточно хорошо сделанные части продукта, которые выглядят законченными.
Еще одно наблюдение: умение правильно показать сделанное при работе по скрам – это очень важный навык. С одной стороны, команде проекта не стоит тратить слишком много времени на подготовку к демо, с другой стороны, сделанное нужно показать так, чтобы владелец продукта понял, как это работает и дал обратную связь. Поэтому, очень важно чтобы кто-то в команде владел навыками презентации.
Во время проведения демо я рекомендую кому-то из участников команды записывать полученную обратную связь от владельца продукта (и его представителей, если он пришел не один) и в конце демо продемонстрировать все сделанные записи и получить подтверждение, что все записано верно. Обычно, если я выступаю в роли скрам-мастера, то записи в ходе демо веду я.
Ну и после подтверждения владельцем продукта всех сделанных записей по итогам демо он включает новые пожелания в журнал продукта и приоритезирует их.
Что в итоге дает демо спринта?
Владелец продукта получает подтверждение того, что команда делает то, что имеет первоочередную важность для развития продукта и вносит коррективы, если что-то сделано не так, а команда получает обратную связь от владельца продукта и быстро исправляет ошибки в интерпретации требований, полученных от владельца продукта. Таким образом, продукт проекта наращивает свою функциональность от спринта к спринту и имеет шанс к концу проекта полностью попасть в ожидания владельца продукта.
Возникли при прочтении статьи какие-то вопросы? Пишите, я готов обсудить их.
Удачи Вам в Ваших проектах и до связи!
Agile. Успешное демо в распределённой команде
Обзор проекта
Команда разрабатывает ключевой продукт, используемый повсеместно всей компанией. У него есть более 10 ключевых заинтересованных лиц в Москве и еще около 10 по всему миру. Более половины из них – высшее руководство (очень занятые люди). Product owner, руководители команд и аналитики находятся в Москве. Scrum Master и команда разработки (около 15 человек) находятся в Днепропетровске. 
Как это было
Итак, самый простой способ — просто попросить всех прийти и посмотреть. И именно этим путём пошла команда.
Однако произошло следующее:
Хаос на демо
• Не всем было понятно во сколько демо-сессия начинается и заканчивается
• Отсутствие чёткого плана демонстрации
• Отсутствие лидера демо-сессии
• Началось длительное обсуждение за пределами цели демо
• Никто до конца не понимал смысла этой встречи
Только участники из Москвы принимали активное участие
• Люди из других локаций не слышали обсуждений и не имели возможности общаться с другими участниками встречи
Отсутствие ясности и прозрачности
• Участники не понимали, что было показано
• Участники не понимали статус проекта целиком
• Участники получили большое количество сложных и неясных слайдов
Неверные пользовательские истории
• Часть невозможно было продемонстрировать
• Использование тестовых данных: “12345”, “qwerty”, “test surname_1”. Участники не понимали, как это будет работать в реальной жизни.
• Фактический объём пользовательских историй был не ясен. Было трудно понять выполнена эта история или нет.
• Причины выбора имплементации не были ясны
Технические истории были показаны абсолютно не техническим людям. Большое количество технических деталей было не приемлемо для такой аудитории.
Забытые Action Items. Было очень много пунктов, которые или были потеряны после встречи или неверно истолкованы.
Решения и методы, которые помогли
Итак, всем понятно, что эта встреча прошла не эффективно. Какие методы помогли улучшить ситуацию:
Создание повторяющихся встреч. Мы создали повторяющие встречи в Outlook – все участники всегда знали, где и во сколько будет следующее демо. Это позволило всем участникам заранее планировать своё расписание.
Внесение подготовки в расписание. Теперь каждый, кто был ответственен за проведение Демо, имел время для подготовки (старт аудио/видео конференции, проверка подключения, готовность конференц-зала и т.д.). Всё это делалось для того, чтобы, когда заинтересованные стороны пришли на встречу, всё уже было готово и мы могли начинать.
Определение условий для старта. Мы решили, что демо начинается именно тогда, когда ключевые участники(2-3 человека) присутствуют. Теперь все заинтересованные стороны знают, что мы начинаем именно тогда, когда придут ключевые участники и больше не будет никаких задержек.
Строгая агенда встречи. Демо следует согласно агенде. Агенда прописана в расписании и напоминается перед каждой встречей. Теперь все знают когда тот или иной пункт будет обсуждаться и не возникает хаотических дискуссий.
Рабочие соглашения. Это инструмент сохранения эффективности встречи и поддержания сосредоточенности на достижения цели встречи. Рабочие соглашения написаны на маркерной доске на каждом Демо. Демо-лидеры могут использовать их как инструмент управления дискуссией.
“Parking Lot”. Когда дискуссия уходит за пределы агенды или займёт слишком много времени, то лидер демо помещает его на «стоянку», как Action Item. Любые Action Items, возникшие во время встречи, также помещаются туда.
Раздаточные материалы. Мы напечатали красочные раздаточные материалы, чтобы каждый мог увидеть слайды презентации и быть в состоянии делать заметки для себя. Также полезно, чтобы на проектор выводилась не только презентация, но и работающее приложение.
Agile Графики. Мы изменили все слайды со статусом релиза или спринта. Ранее использовался «классический подход», мы сделали его более «agile». Это повысило понимание прогресса.
Было:
Стало:
Демо Лидер. Мы ввели роль лидера демо. Это только один ведущий в конференц-зале, который управляет демо, дает право голоса другим, следит за временем, повесткой дня и использует рабочие соглашения как инструмент управления демо. Теперь все знают, кто является лидером и кто имеет право управлять встречей.
Помощник в другой локации. Мы сделали одного из членов команды в Днепропетровске ассистентом Демо Лидера. Ассистент контролирует все, что отображается на экранах и может подключать членов команды к обсуждениям. Также помощник вручную добавляет Action Items на Parking Lot, чтобы каждый в режиме реального времени видел, что все написано и написано правильно.
Видео Мост. Мы отказались от скучной и неэффективной аудиоконференции и ввели видеомост. Презентацию и приложение показали с помощью проекторов. Сейчас заинтересованные стороны и члены команды не только видят приложение и слышат презентацию, но могут эффективно общаться, видя друг друга.
Удаление технических историй. Мы убрали технические историй из демо, потому что они не интересны для заинтересованных сторон и могут ввести их в заблуждение. Но для всех, кто хочет их увидеть(например, если среди заинтересованных сторон есть технические ребята) выделен временной интервал сразу после демо для их показа.
Вопросительные знаки. Знак вопроса – очень быстрый и действенный механизм остановки демо. Это работает лучше, чем попытки прервать говорящего человека из другой локации.
Приём пользовательских историй на другой встрече. Мы сделали еще одну встречу, перед демо для приемки историй(с использованием критериев приёмки, определённых владельцем продукта). Процесс детальной приёмки не интересен для заинтересованных сторон – им не интересна демонстрация каждой истории в деталях. Так что на демо мы показываем только принятые владельце продукта пользовательские истории, собираем отзывы.
Быстрая обратная связь. Мы просим заинтересованных сторон после демо дать быстрый отзыв о организации демо ( что было хорошо, а что нет). Это помогает нам улучшать качество демо непрерывно.
Ретроспектива демо. Мы проводим короткую ретроспективу после каждого демо. Это помогает улучшить слабые места.
Вот и всё. Нет магии, rocket science, комплексных решений – это всего лишь ряд простых, но мощных методов, которые помогли команде стать более эффективными в проведении демо и сделало их клиентов счастливыми.
Это не полный список того, что можно улучшить в проведении демо. Зачем в Agile демо, как его эффективно проводить и многое другое мы детально раскрываем на наших тренингах.
Как мы отменяли ретроспективы
Однажды для нашей команды перестали работать ретроспективы.
На ретро мы обсуждали вечные темы: надо лучше декомпозировать задачи, надо лучше оценивать задачи, надо перестать таскать долги между спринтами и т.д. Кто-то параллельно кодил, кто-то отвечал на сообщения, кто-то просто залипал в телефон. Звучит знакомо?
Это были мои первые спринты в роли скрам-мастера, и я чувствовал, у команды нет доверия к ретроспективам. Да и потребности тоже нет — есть жалобы на «скрам-день», забитый митингами. А работать-то когда?
Я решился на страшное для скрам-мастера: предложил команде отменить ретроспективы — и вот что из этого вышло.
Я, пытаюсь провести скучную ретроспективу
Привет! Меня зовут Павел, я занимаюсь фронтендом и скрамом в команде Wrike. Мы работаем по Scrum, сейчас у нас около 30 команд, в одной из которых я скрам-мастер. Я им стал уже больше года назад и хочу поделиться своим опытом. В этот раз — про ретроспективы.
Наши ретроспективы были похожи на карго-культ
Для полного погружения — пара слов про карго-культы. Вы знаете, островитяне во время Второй мировой войны осознали, что все самолеты (военные), которые прилетали к ним на остров (военную базу), на самом деле привозили множество замечательных предметов цивилизации именно для них, островитян. Когда война закончилась и самолеты перестали прилетать, их разочарованию не было предела.
Пытливый ум подсказал: чтобы вернуть самолеты, стоит попробовать сделать аэродром. Например, организовать взлетно-посадочную полосу в поле, разложить вдоль нее костры, соорудить радиовышку из пальмы, и, конечно, посадить диспетчера в шалаш. Все было сделано — но самолеты с дарами так и не прилетели.
Вот и у нас с ретроспективами вышла та же история. Они перешли по наследству от предыдущего скрам-мастера, и все внешние признаки соблюдались до сих пор: в конце каждого спринта команда собиралась, инспектировала себя, обсуждала план улучшений и следовала ему в следующем спринте. Только на практике мы обсуждали одно и то же в одном и том же формате, непонятно почему, непонятно для чего. Ребята не были вовлечены, в спринте потом все забывали про этот план, а скрам-мастер (я) все равно позитивно скакал вокруг доски каждую ретроспективу. Хуже всего, что в результате ничего не менялось.
Что мы сделали
Золотое правило скрам-мастера — не причинять команде скрам.
Окей: ретроспективы скучные, бесполезные, а вы все залипаете в ноутбуках. Давайте это узаконим и отменим следующую ретроспективу!
С таким посылом я и пришел к команде. Мне было важно понять, нужны ли ретроспективы самим ребятам и для чего. Если проблемы нет, то и не нужно искусственно ее «лечить». А если потребности нет, надо работать над ее здоровым формированием.
Моя гипотеза была в том, что при таком радикальном изменении команда сама расскажет, для чего ей нужна отмененная ретроспектива. Это было достаточно рискованно — отпустив команду тогда, я мог вообще не увидеть ее на следующих ретро. Но команда все сделала правильно.
Что получилось, когда мы отменили ретроспективы
Я, выясняю, зачем команде ретроспективы
Больше половины ребят с удовольствием меня поддержали и с формулировкой «конечно, лучше поработаем» расчехлили свои задачи на освободившееся время. Но три человека взбунтовались и привели такие аргументы:
Какие выводы мы сделали
Нужно верифицировать результат. Чтобы восстановить доверие команды к ретроспективам, нужно показать, что они приносят пользу. Команда не видела изменений после ретроспектив и поэтому перестала в них вкладываться. Какой толк что-то предлагать, если по опыту понятно, что мы это не реализуем? Если я хочу, чтобы команда начала лучше декомпозировать задачи — я и так буду это делать, а остальные все равно не начнут (а скрам-мастер не проконтролирует). Ребята так думали, потому что мы уже давно ничего такого не меняли, не улучшали.
Большим шагом стало то, что каждый Action Item мы стали заводить как отдельную задачу, брать в спринт, трекать его выполнение и верифицировать результат на следующем ретро. Началась долгая работа над тем, чтобы доказать команде: ретро работают, вот 10 закрытых экшн айтемов, которые вы предлагали, вот что мы поменяли.
Нужно разнообразить форматы. Классические плюсы-минусы, приехавшие от прошлого скрам-мастера, всем уже приелись. В конце концов, ретро — не только про прошедший спринт, это про улучшения. Когда команда уверена, что у нее все хорошо — можно построить колесо баланса и увидеть, что на самом деле — нет (и понять, над чем работать). Можно нарисовать кораблик и в игровой форме обсудить свои сильные и слабые стороны. Для команд в стадии forming плюсы-минусы скорее стоит заменить на синхронизацию ожиданий.
Есть куча идей, подходящих для разных целей. Они позволяют сделать ивент более драйвовым и вовлечь команду вместо того, чтобы терзать всех вопросами: «Ну что там из плюсов было в спринте? Что нам надо продолжать делать?». После перезапуска ретро мы попробовали разные форматы, стало весело, продуктивно, мы ушли от монотонных дискуссий, в которых участвует только 1-2 человека, и смогли вовлечь даже удаленных участников.
«Вечные темы» лучше обсуждать отдельно. «Как закрыть спринт без долгов», «как справляться с большими историями» — можно делать бинго, они всплывают у всех команд. Вместо того, чтобы постоянно мусолить их под видом «минусов спринта», мы зарезервировали под них отдельные ретроспективы — остальные стали чище, оживленнее и продуктивнее.
Заранее определять тему и цель ретроспективы. Если ребята бомбят — им не до моих колес баланса, надо разбираться с актуальными проблемами. Лучше выяснить это заранее, особенно если при сборе тем по ходу митинга начинается: «Ох, у меня что-то было на прошлой неделе, но я уже забыл» (туда же, в бинго).
Мы обсудили, что такие вещи лучше записывать по ходу спринта. Кто-то в шутку предложил сделать книгу жалоб.
Шутки шутками, но на следующий день я ее добыл и повесил на доске
Ребята заценили, но, естественно, никто ничего не написал. Зато прижилась книга жалоб в электронном виде — мы заранее создаем отдельную задачу на ретро и в описании фиксируем все моменты, которые нам надо не забыть обсудить. Важно, что ребята заполняют ее, идея прижилась и работает уже целый год.
Например, она может выглядеть вот так, если закрасить все, что должно остаться на самом ретро
Какую пользу принесли нам «обновленные» ретроспективы
За год с того момента мы закрыли десятки экшн айтемов, от понятных «обустроить комнату» и «сходить на тимбилдинг» до сложных «передать скоуп другой команде», «четко прописать план релиза». Мы берем их в спринт и верифицируем в начале следующей ретроспективы, чтобы подтверждать доверие.
За год мы накопили около 50 командных соглашений, к которым пришли через собственный опыт и ошибки:
А как у вас?
У каждой команды своя история ретроспектив и свои взаимоотношения со скрам-мастером. Например, мои друзья не понимают, зачем скрам-мастер нужен в их команде — он только заводит ненужные митинги и целый день пьет кофе. Точно ли это помогает команде вырасти? Точно ли это так видит сам скрам-мастер?
У всех свой положительный или отрицательный опыт. Делитесь своим в комментариях — и удачи в развитии вашей команды!
Как использовать Agile и Scrum для управления проектами
Agile и Scrum для руководителя проекта — основы гибких методологий, инструкция по ведению бэклога и спринтам, контроль процессов и организация работы.
Для чего внедрять гибкие методологии
Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.
Неожиданности появляются не только из-за бизнес-процессов, здесь работает и человеческий фактор. Например, представители заказчика могут намеренно затягивать внедрение ПО, преследуя личные цели. Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу. Плюс сейчас ПО требует мгновенной реакции на отзывы пользователей — подход с долгой тщательной подготовкой не работает.
Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.
Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.
Начните с бэклога
Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.
Вместо проектного задания используется бэклог — список функций, требований к системе, желаний заказчика. В Scrum они сортируются по приоритету. Это живой документ, добавляйте в него новые задачи по ходу работы.
Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.
Не нужно прорабатывать и продумывать полностью все функции сразу. Все «хотелки» и то, что появляется в процессе, добавляются в бэклог. Решайте, что делать сразу, а что стоит отложить на следующую версию.
Внедряйте спринты
Scrum создавался в первую очередь для гибкости и ускорения разработки. Для этого появилась механика спринтов — весь процесс делится на отрезки, обычно от одной до четырех недель.
Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.
Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».
Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.
Ключевая идея — до тех пор, пока команда не забрала задачи на спринт, их можно бесконечно видоизменять в бэклоге. В разработку уходит согласованная часть. Каждый спринт — это небольшой релиз, в конце которого команда показывает работающую функцию ПО.
Распределите роли в команде
В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.
Cвязующее звено между командой разработки и пользователями. Этот человек собирает общую концепцию продукта из мнений заказчиков и других заинтересованных в выпуске ПО людей. Он формирует задачи и расставляет приоритеты.
Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.
Люди, которые непосредственно создают и тестируют код.
К разработчикам есть несколько требований:
У такого принципа формирования команды есть минус — сложно заменить неожиданно выпавшего человека. Но скорость разработки на практике все равно выше, чем у других подходов.
Контролируйте процессы
Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.
Контролируйте работу команды с помощью двух scrum-показателей:
Организуйте работу команды
В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:
Задача руководителя — выяснить и устранить трудности, которые мешают разработчику добиться прогнозируемого результата. Для сотрудников это три-пять минут — ответили на вопросы, поставили оценки, разбежались работать дальше. Никаких решений или дискуссий.
В конце каждого спринта проводится ретроспектива. Команда встречается, озвучивает мнение, что в отрезке было хорошо, что плохо. Спросите у сотрудников идеи — что поможет им работать быстрее и эффективнее, что исправит проблемы. Запишите их в отдельный план — забирайте туда только те идеи, которые возможно сделать за следующий спринт.
Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.
На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.
Формируйте организацию процесса постепенно. Разбивайте день — например, шесть часов люди работают по спринтам, два часа остаются на срочные и случайные моменты. Если все пойдет без неожиданностей, ничего страшного, продолжайте спринт, сделайте больше тикетов.
Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.
Демонстрируйте проект
Не затягивайте с первой версией продукта. Демонстрацию лучше проводить после каждого спринта — пусть даже релиз не пойдет к пользователям. Не копите внутри команды много функций — покажите их заинтересованным лицам и получите обратную связь. После — сразу измените бэклог.
В этом основное преимущество Scrum — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.
Изучите инструменты для контроля
Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:
Чек-лист — как начать использовать Agile и Scrum на проекте
Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.
Делает из вебинаров статьи, пишет про все и даже немного больше.