Scrum и xp заметки с передовой
 Скачать 3.07 Mb.
|
|
Тема письма: Спринт №15 у команды ”Джокер” начался Всем привет! Команда ”Джокер” только что стартовала спринт №15. Наша цель – продемонстрировать релиз, готовый к бета-тестированию, 24-го ноября. Страница информации о спринте доступна по адресу: http://wiki.mycompany.com/jackass/sprint15 Кроме этого у нас есть ”панель” в wiki, в которой содержаться ссылки на текущие спринты всех команд. Корпоративная панель Текущие спринты • Команда X, спринт №15 • Команда Y, спринт №12 • Команда Z, спринт № 1 В дополнение ко всему этому наш ScrumMaster распечатывает страницу информации о спринте и вывешивает её на стену в коридоре. Таким образом кто угодно, проходя мимо, может взглянуть на эту страницу и узнать, чем же занимается наша команда. Когда спринт подходит к концу, ScrumMaster напоминает всем про приближающуюся демонстрацию. Тема письма: Завтра в 13:00 команда ”Джокер” проводит демонстрацию в кафетерии Всем привет! Все приглашаются на демонстрацию спринта №15 команды ”Джокер” завтра в 13:00 в кафетерии. Будет продемонстрирован релиз, готовый к бета-тестированию. Страница информации о спринте доступна по адресу: http://wiki.mycompany.com/jackass/sprint15 Если всё это делать, то ни у кого не получится сказать, что он не мог узнать, чем занимается команда. Scrum и XP: заметки с передовой 37 6 Как мы создаём sprint backlog Уже добрались до этой главы? Отлично! Итак, мы только что закончили планирование и протрубили на весь мир про начало нашего новоиспечённого спринта. Теперь настал черёд ScrumMaster'а создать sprint backlog. Это необходимо сделать после планирования спринта, но до начала первого ежедневного Scrum'а. Формат sprint backlog'a Мы поэкспериментировали с разными форматами sprint backlog'а, включая Jira, Excel, не забыли попробовать и обычную настенную доску. Сперва в основном использовали Excel, в интернете можно найти довольно много Excel'евских шаблонов для sprint backlog'ов, с авто-генерацией burndown диаграмм и всякими другими примочками. Я мог бы долго рассказать про sprint backlog'и, созданные при помощи Excel, но я не буду. Даже не стану приводить примеров. Вместо этого я опишу во всех подробностях формат sprint backlog'а, который мы сочли наиболее эффективным – доску задач на стене. Найдите большую стену, на которой либо ничего нет, либо висит всякая ерунда вроде логотипа компании, старых диаграмм или ужасных картинок. Очистите её (если необходимо, спросите разрешения). Склейте скотчем большущее полотно бумаги (как минимум 2x2 или 3x2 метра для большой команды). А потом сделайте что-то вроде этого: Как вариант, можно использовать белую доску. Но такое её использование неэффективно. Если это возможно, сохраните белую доску для набросков будущего дизайна, а в качестве доски для задач используйте "бумажные стены". Примечание: если вы пользуетесь стикерами для задач, не забудьте прикрепить их скотчем, или же в один "прекрасный" день вы найдете их аккуратной кучкой на полу. Scrum и XP: заметки с передовой 38 Как работает доска задач Вы, конечно, можете добавить любые дополнительные поля. Например, "В ожидании интеграционного тестирования" или "Отменённые". Но прежде чем всё усложнять, хорошенько подумайте, действительно ли эти дополнения так уж необходимы? Я понял, что простота крайне ценна в такого рода вещах, поэтому я делаю усложнения только в случае, если цена неделания слишком велика. Пример 1 – после первого ежедневного Scrum'а После первого ежедневного Scrum'a доска задач может выглядеть примерно так: Scrum и XP: заметки с передовой 39 Как видно, три задачи находятся "в процессе", то есть команда будет заниматься ими сегодня. Иногда, в больших командах, задача зависает в состоянии "в процессе" потому, что никто не помнит, кто над ней работал. Если такое случается часто, команда обычно принимает меры. Например, отмечает на карточке задачи имя человека, который взялся над ней работать. Пример 2 – еще через пару дней Через пару дней доска задач может выглядеть примерно так: Как видно, мы закончили историю "Депозит" (т.е. она была зафиксирована в системе контроля версий, протестирована, отрефакторена и т.д.) "Автоматическое обновление" сделано частично, "Админка: вход" начат, а "Админка: управление пользователями" еще нет. У нас возникло 3 незапланированные задачи, как видно справа внизу. Об этом полезно будет вспомнить на ретроспективе. Вот пример настоящего sprint backlog'а ближе к концу спринта. Он, в самом деле, становится довольно беспорядочным по ходу спринта, но ничего страшного, так как это ненадолго. На каждый новый спринт мы начинаем sprint backlog с чистого листа. Scrum и XP: заметки с передовой 40 Как работает burndown-диаграмма Давайте присмотримся к burndown-диаграмме: Вот о чем она говорит: • В первый день спринта, 1-го августа, команда определила, что работы осталось примерно на 70 story point'ов. Это как раз и есть прогнозируемая производительность на этот спринт. • 16-го августа работы осталось примерно на 15 story point'ов. Пунктирная направляющая показывает, что они на верном пути, то есть в таком темпе они успеют закончить все задачи к концу спринта. Мы пропускаем выходные по оси X, так как в это время редко что-то делается. Раньше мы их включали, но burndown при этом выглядел странновато, так как он "выравнивался" на выходных, и это походило на повод для беспокойства. Тревожные сигналы на доске задач Беглый взгляд на доску задач должен дать возможность любому человеку понять, насколько успешно продвигается итерация. ScrumMaster несёт ответственность за то, чтобы команда принимала соответствующие меры при обнаружении первых тревожных симптомов: Scrum и XP: заметки с передовой 41 Эй, как насчет отслеживания изменений? Лучший вариант отслеживания изменений, который я могу предложить при данном подходе – это делать фотографию доски задач каждый день. Делайте так, если это необходимо. Я тоже иногда так делаю, хотя ещё никогда не возникало необходимости пересматривать эти фотографии позже. Если отслеживание изменений для вас очень важно, тогда возможно подход с доской задач вам вообще не подходит. И все-таки, я бы предложил вам сначала оценить значение детального отслеживания изменений в спринте. После того как спринт закончен и рабочий код вместе с документацией был отослан заказчику, будет ли кто-нибудь разбираться, сколько историй было закончено на 5й день спринта? Будет ли кто-нибудь волноваться о том, какова была реальная оценка для задачи "Написать приемочный тест для истории Депозит" после того, как история была закончена? Как мы оцениваем: в днях или часах? В большинстве книг и статей, посвящённых Scrum'у, для оценки времени выполнения задач используются часы, а не дни. И мы так раньше делали. Общая формула была такой: один эффективный человеко-день равен шести эффективным человеко-часам. Однако мы отказались от этой практики по следующим причинам: • Оценки в человеко-часах чересчур мелкие, что приводит к появлению большого количества крохотных задач по часу или два, и, как результат, к микроменеджменту (micromanagement). • Оказалось, что всё равно все оценивают в человеко-днях, а когда нужно получить оценку в человеко-часах, просто умножают дни на шесть. "Хм, эта задача займёт примерно день. Ага, я должен дать оценку в часах. Что ж, значит шесть часов". • Две разных единицы измерения вводят в заблуждение. "Это оценка в человеко-днях или человеко-часах?" Поэтому мы используем человеко-дни в качестве основной единицы при оценке времени (мы называем их story point'ами). Наше наименьшее значение – 0.5. Т.е. любые задачи, оцененные менее чем в 0.5, либо удаляются, либо комбинируются с другими, либо оценка остаётся 0.5 (ничего страшного в слегка завышенной оценке нет). Изящно и просто. Scrum и XP: заметки с передовой 42 7 Как мы обустроили комнату команды Уголок обсуждений Я заметил, что большинство интересных и полезных обсуждений возникают спонтанно, прямо перед доской задач. Поэтому мы пытаемся оформить это место как отдельный "уголок обсуждений" Стена проектирования (доска для маркеров) Стена с информ ацией п ро сп ринт (доск а задач ) Общий компьютер Несколько стульев И море свободного пространства, чтобы мы могли стоять и бродить, говорить и жестикулировать Это и в самом деле полезно. Нет лучшего способа посмотреть на систему в целом, чем стать в уголок обсуждений, посмотреть на обе стены, а потом сесть за компьютер и пощелкать последний билд системы (в случае, если вам повезло, и у вас внедрена практика "непрерывной интеграции" системы (см. стр. 62" Как мы сочетаем Scrum с XP") "Стена проектирования" – это просто большая доска, на которой развешены самые важные для разработки наброски и распечатки (блок-схемы, эскизы интерфейса, модели предметной области и т.п.) Scrum и XP: заметки с передовой 43 На фотографии: ежедневный Scrum в вышеупомянутом уголке. Хммммм... Эта burndown диаграмма выглядит подозрительно красивой и гладкой, правда? Но команда настаивает на том, что это правда :o) Усадите команду вместе Когда приходит время расставить столы и рассадить команду, есть одно правило, которое сложно переоценить. Усадите команду вместе! Чуть поясню, что я имею в виду: Усадите команду вместе! Людям не нравится переезжать. По крайней мере, в тех компаниях, в которых работал я. Они не хотят собирать все свои вещички, выдергивать шнуры из компьютера, переносить весь свой скарб на другой стол, и снова втыкать все шнуры. Чем меньше расстояние, тем больше недовольство. "Да ладно, шеф, НА КОЙ ЧЕРТ меня пересаживать всего на 5 метров вправо"? Но когда мы строим эффективную команду по Scrum'у, другого выхода нет. Просто соберите команду вместе. Даже если придется им угрожать, самому переносить все их имущество, и самому вытирать застарелые следы от чашек на столах. Если для команды нет места – найдите место. Где угодно. Даже если придется посадить команду в подвале. Передвиньте столы, подкупите офис-менеджера, делайте всё, что нужно. Но как бы то ни было, соберите команду вместе. Как только вы соберете всю команду вместе, результат появится незамедлительно. Уже после первого спринта команда согласится, что это была хорошая идея – собраться всем в одном месте (по моему опыту так и есть, хотя нет никаких гарантий, что команда не окажется слишком упрямой, чтобы это признать). Да, кстати, а что значит "вместе"? Как должны стоять столы? Ну, лично у меня нет однозначного мнения о наилучшем расположении столов. Но даже если бы и было, я думаю, у большинства команд нет такой роскоши – решать, как будут расставлены столы в их комнате. Всегда существуют физические ограничения – соседняя команда, дверь в туалет, здоровый автомат с батончиками и напитками посреди комнаты – да что угодно. "Вместе" значит: • В пределах слышимости: каждый в команде может поговорить с любым другим членом команды без крика и не вставая из-за своего стола. Scrum и XP: заметки с передовой 44 • В пределах видимости: каждый член команды может увидеть любого другого. Каждый может видеть доску задач. Не обязательно быть достаточно близко, чтобы читать, но, по крайней мере, видеть. • Автономно: если вдруг вся ваша команда поднимется и начнет внезапную и очень оживлённую дискуссию об архитектуре системы, никого из не-членов команды не окажется достаточно близко, чтобы ему это помешало. И наоборот. "Автономно" не значит, что команда должна быть полностью изолирована. В пространстве, разделённом на секции, вполне может хватить отдельной секции для команды, с достаточно высокими стенами, чтобы не пропускать большую часть шума извне. А как быть с распределённой командой? Ну, тогда вам не повезло. Чтобы уменьшить негативные последствия, используйте как можно больше технических средств: видеоконференции, вебкамеры, средства для совместного использования рабочего стола и т.п. Не подпускайте product owner'а слишком близко Product owner должен находиться настолько близко к команде, чтобы в случае возникновения вопросов, команда могла бы спросить его лично, и чтобы он имел возможность на своих двоих подойти к доске задач. Но он не должен сидеть в одной комнате с командой. Почему? Потому что есть вероятность, что он не сможет не вдаваться в подробности, а команда не сможет правильно сработаться (т.е. не достигнет состояния полной автономности, самомотивации и сверхпродуктивности). Если честно, то это всего лишь догадки: в действительности, я сам никогда не видел, чтобы product owner сидел рядом с командой, а, значит, у меня нет оснований говорить, что это плохая идея. Мне это просто подсказывает внутреннее чутьё и другие ScrumMaster'а. Не подпускайте менеджеров и тренеров слишком близко Эту главу мне писать немного тяжело, ведь я был как менеджером, так и тренером ... Тесная работа с командами входила в мои непосредственные обязанности. Я создавал команды, переходил из одной команды в другую, программировал с ними в парах, тренировал ScrumMaster'ов, организовывал планирования спринтов и т.д. Оглядываясь назад можно сказать, что я творил Хорошие Дела. И это всё благодаря моему опыту в гибкой разработке программного обеспечения. Но потом меня назначили (звучит тема Дарта Вейдера) руководителем отдела разработки. В общем, я стал менеджером. Это означало, что моё присутствие автоматически делало команду менее самоорганизующейся. "О! Шеф тут. У него, небось, есть куча идей о том, что надо сделать, и кто должен этим заняться. Давай-ка послушаем". Я придерживаюсь следующей точки зрения: Если вы Scrum-тренер (и возможно совмещаете эту роль с ролью менеджера), не бойтесь очень плотно работать с командой. Но только в течение определённого промежутка времени, а потом оставьте команду в покое и дайте ей возможность сработаться и самоорганизоваться. Время от времени контролируйте её (однако не очень часто). Это можно делать, посещая демо, изучая доску задач или принимая участие в ежедневном Scrum'е. Если вы увидите как можно улучшить процесс, отведите ScrumMaster'а в сторонку и дайте ему дельный совет. Не стоит поучать его на глазах у всей команды. Посещение ретроспективы (см. стр. 51 "Как мы проводим ретроспективы") тоже будет не лишним. Если степень доверия к вам со стороны команды невелика, то сделайте доброе дело, не ходите на ретроспективы, а то ваше присутствие заставит команду молчать о своих проблемах. Если Scrum-команда работает хорошо, обеспечьте её всем необходимым, а потом оставьте в покое (за исключением демо, разумеется). Scrum и XP: заметки с передовой 45 8 Как мы проводим ежедневный Scrum Наш ежедневный Scrum очень похож на то, как это описывают в книгах. Каждый день он начинается в одно и то же время, в одном и том же месте. Вначале, мы предпочитали проводить его в отдельной комнате (это были дни, когда мы использовали sprint backlog'и в электронном формате), однако сейчас мы проводим ежедневный Scrum у доски задач в комнате команды. Нет ничего лучше! Обычно мы проводим встречу стоя, поскольку это уменьшает вероятность того, что продолжительность нашей "планёрки" превысит 15 минут. Как мы обновляем доску задач Обычно мы обновляем доску задач во время ежедневного Scrum'а. По мере того, как каждый член команды рассказывает о том, что он сделал за вчерашний день и чем будет заниматься сегодня, он перемещает стикеры на доске задач. Как только рассказ касается какого-то незапланированного задания, то для него клеится новый стикер. При обновлении временных оценок, на стикере пишется новая оценка, а старая зачеркивается. Иногда стикерами занимается ScrumMaster, пока участники говорят. Приёмоч- ный тест 2д 3д Приёмоч- ный тест 2д 3д 1д Приёмоч- ный тест 2д В некоторых командах принято, что все члены команды обновляют доску задач перед каждой встречей. Это тоже хорошо работает. Просто решите, что вам ближе, и придерживайтесь этого. Независимо от того, какой формат sprint backlog'a вы используете, пытайтесь вовлечь всю команду в поддержание sprint backlog'a в актуальном состоянии. Мы пробовали проводить спринты, в которых только ScrumMaster занимался поддержкой sprint backlog'a. Он должен был каждый день обходить всех членов команды и спрашивать об оценках оставшегося до окончания времени. Недостатки этого подхода в том, что: • ScrumMaster тратит слишком много времени на "бумажную работу", вместо того, чтобы заниматься поддержкой команды и устранением преград. • Члены команды не в курсе состояния спринта, поскольку им не нужно заботиться о sprint backlog'e. Эта нехватка обратной связи уменьшает общую гибкость и сконцентрированность команды. Если sprint backlog имеет надлежащий вид, то любой член команды может легко его обновить. Сразу же после ежедневного Scrum'a, кто-то суммирует оценки всех задач на доске (конечно, кроме тех, которые находятся в колонке "Готово") и ставит новую точку на burndown-диаграмме. Как быть с опоздавшими Некоторые команды заводят специальную копилку. Если вы опоздали, даже на минуту, вы кидаете в копилку определённую сумму. Без вариантов. Даже если вы позвонили перед началом ежедневного Scrum'а и предупредили, заплатить всё равно придётся :o) Scrum и XP: заметки с передовой 46 Отвертеться можно лишь в исключительных случаях. Например, визит к врачу, собственная свадьба или что-то не менее важное. Деньги из копилки используются на общественные нужды. Например, на них можно заказать пиццу, когда мы решаем поиграть вечерком :o) Этот подход работает неплохо. Но пользоваться им нужно лишь в том случае, когда люди часто опаздывают. Некоторым командам это просто не нужно. Как мы поступаем с теми, кто не знает, чем себя занять Иногда кто-то говорит: "Вчера я делал то-то и то-то, а сегодня нет четкого представления у меня, чем занять себя". Наши действия? Допустим, Джо и Лиза не знают, чем сегодня заняться. Если я выступаю в роли ScrumMaster’а, я просто передаю слово следующему. При этом беру на карандаш тех, кто не знает, чем ему заняться. После того, как все высказались, я пробегаюсь вместе с командой по доске задач и проверяю, что данные на доске задач актуальные и что все понимают смысл каждой истории. Далее я предлагаю каждому участнику команды приклеить новые стикеры. После этого возвращаюсь к тем, кто не знал, чем себя занять, с вопросом "после того, как мы прошлись по доске, не появилось ли у вас представление о том, чем заняться?" Надеюсь, к тому времени оно уже появится. Если же нет, то я выясняю, есть ли возможность для парного программирования. Допустим, сегодня Никлас планирует реализовать интерфейс для админки. Вы можете предложить Джо или Лизе поработать в паре с Никласом над этой функциональностью. Обычно это работает. Если нет, то вот вам следующий приём. |