Как мы проводим Scrum-of-Scrums
Scrum-of-scrums - это регулярные встречи, цель которых - обсуждение различных вопросов между Scrum-мастерами.
Как-то мы работали над четырьмя продуктами. Над тремя из них работало по одной Scrum-команде, а над четвёртым - 25 человек, которые были разделены на несколько Scrum-команд. Это выглядело следующим образом:
У нас было два уровня Scrum-of-Scrums: «уровня продукта», который проводился с участием команд продукта Д, и «уровня компании» для участников всех команд.
Scrum-of-Scrums уровня продукта
Эта встреча была очень важной. Мы проводили её не реже одного раза в неделю. Мы обсуждали проблемы интеграции, балансировки команд, подготовку к следующему планированию спринта и т.д. Мы выделяли на это 30 минут, но часто нам их не хватало. В качестве альтернативы можно было бы проводить ежедневный Scrum-of-Scrums, однако, мы так и не собрались опробовать его.
Наша повестка дня имела следующий вид:
1. Каждый по очереди рассказывал, что его команда сделала на прошлой неделе, что планирует закончить на этой недели, и с какими трудностями они столкнулись.
2. Любые другие проблемы, относящиеся к компетенции нескольких команд одновременно, которые нужно обсудить. Например, вопросы интеграции.
На самом деле повестка дня Scrum-of-Scrums не так уж и важна - важнее, чтобы эта встреча проводилась регулярно.
Из книги Scrum и XP: заметки с передовой автора Книберг Хенрик Из книги Прибыльный блог: создай, раскрути и заработай автора Литвин Евгений Из книги автора Из книги автора Из книги автораКак мы проводим демо Демонстрация спринта - очень важная часть Scrum’а, которую многие все же недооценивают. «Ой, а нам что, обязательно делать демо? Мы все равно ничего интересного не покажем!» «У нас нет времени на подготовку разных &%$# демо!» «У меня куча работы, не
Из книги автора Из книги автораКак мы проводим ретроспективы Хотя основной формат немного варьируется, но в основном мы делаем так: Выделяем 1-3 часа, в зависимости от того насколько долгая ожидается дискуссия. Участвуют: product owner, вся команда и я собственной персоной. Располагаемся либо в отдельной
Из книги автораКак мы сочетаем Scrum с XP То, что Scrum и XP (eXtreme Programming) могут быть эффективно объединены, не вызывает сомнений. Большинство рассуждений в интернете поддерживают это предположение, и я не хочу тратить время на дополнительные обоснования.Тем не менее, одну вещь я всё-таки должен
Из книги автораПовышайте качество, включив тестировщиков в Scrum-команду О, я уже слышу эти возражения:«Но это же очевидно! Scrum-команды должны быть кросс-функциональными!»«В Scrum-команде не должно быть выделенных ролей! У нас не может быть человека, занимающегося только тестированием!»Я быПроводим интернет-семинары и обучающие курсы Этот вид заработка подходит для самых амбициозных и компетентных блогеров, профессионалов, гуру, экспертов в своей теме. Или для тех блогеров, которые незаметно для себя таковыми стали.Блогер может заработать деньги на
К сожалению, на благодарности нам выделили всего лишь страничку. Поэтому я постараюсь представить всех наших активистов в фактах.
Максим Харченко умудрялся переводить даже на море. Спасибо Гипер. NET
Дима Данильченко - директор и по совместительству (да и такое бывает ☺) один из самых активных переводчиков в нашем проекте.
Если по ходу книги вам очень понравился перевод, и вы заулыбались, то, скорее всего, эту главу переводил Артём Сердюк.
Боря Лебеда автоматизировал конвертацию оригинала из word’а в wiki формат. Я и понятия не имел, что это можно сделать так легко.
Ярослав Гнатюк знает Хенрика лично.
Антон Марюхненко - самый молодой и перспективный.
Сергей Петров - самый старший и опытный.
Марина Кадочникова - наша единственная девушка-переводчица.
Серёжа Мовчан, конечно же, я про тебя не забыл ☺. Просто хотел сказать тебе отдельное спасибо. Ты был тем вторым локомотивом, благодаря которому нам удалось дотянуть до победного конца. Ведь как говорится в одной японской поговорке: «Начинать легко, продолжать сложно».
Спасибо Марине Зубрицкой и Лёше Мамчию за финальную вычитку и редактуру. Им удалось найти свыше ста ошибок, в уже, казалось бы, вылизанном тексте. Нет предела совершенству.
Не забудем мы и про тех, у кого было желание, но, как часто это бывает, не было времени: Сергей Евтушенко, Артём Марченко, Алексей Тигарев, Тим Евграшин, Александр Кулик.
Лёша Солнцев,
инициатор и координатор первого украинского краудсорсингого проекта, Certified Scrum Master
P.S. Оригинал книги вы можете скачать по адресу http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Предисловие Джефа Сазерленда
Командам необходимо знать основы Scrum’а. Как создать и оценить product backlog? Как получить из него sprint backlog? Как работать с burndown-диаграммой и вычислять производительность(velocity) своей команды? Книга Хенрика - это базовое руководство для начинающих, которое поможет командам перейти из состояния «мы пробуем Scrum» в состояние «мы успешно работаем по Scrum’у».
Хорошая реализация Scrum"а становится всё важнее и важнее для команд, которые хотят получить инвестиции. Я выступаю в качестве тренера по гибким методологиям для группы компаний с венчурными инвестициями, помогая им в стремлении вкладывать деньги только в настоящие Agile-компании. Глава группы инвесторов требует от компаний, составляющих инвестиционный портфель, ответа на вопрос, знают ли они производительность своих команд. Многих этот вопрос ставит в тупик. Будущие инвестиции требуют от команд знания собственной производительности разработки программного обеспечения.
Почему это так важно? Если команда не знает собственной производительности, следовательно product owner не может разработать стратегический план развития продукта с достоверными датами релизов. Без такого плана компанию может постичь неудача, в результате чего инвесторы потеряют свои деньги.
С этой проблемой сталкиваются разнообразные компании: большие и маленькие, старые и новые, с финансированием и без. Во время недавнего обсуждения реализации Scrum"а компанией Google на лондонской конференции я решил узнать у аудитории, состоящей из 135 человек, кто из них использует Scrum? Я получил утвердительный ответ лишь от тридцати человек. Затем я поинтересовался, соответствует ли их процесс Nokia-стандарту итеративной разработки. Итеративная разработка - это ключевое положение Agile Manifest’а: «Постарайтесь предоставлять версии работающего программного обеспечения как можно чаще и раньше». В результате проведения ретроспектив с сотнями Scrum-команд в течение нескольких лет, Nokia выработала некоторые базовые требования к итеративной разработке:
Итерации должны иметь фиксированную длину и не превышать шести недель.
К концу каждой итерации код должен быть протестирован отделом качества (QA) и работать как следует.
Из тридцати человек, которые сказали, что работают по Scrum’y лишь половина подтвердила, что их команды придерживаются первого принципа Agile Manifest’а и соответствую Nokia-стандарту.
Затем я спросил их, придерживаются ли они Scrum-стандарта, разработанного Nokia:
У Scrum-команды должен быть один product owner и команда должна знать, кто это.
У Product owner’а должен быть один product backlog с историями и их оценками, выполненными командой.
У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.
На протяжении спринта никто не должен вмешиваться в работу команды.
Из тридцати команд, внедряющих Scrum, только у трёх процесс разработки соответствовал стандартам Nokia. Я думаю, что только эти три команды получат дальнейшие инвестиции от венчурных капиталистов.
Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog’а, и burndown-диаграмма. Вы также будете знать производительность вашей команды и сможете использовать все наиболее важные практики высокоэффективных Scrum-команд. Вы пройдёте Nokia Scrum-тест, за что инвесторы оценят вас по достоинству. Если вы - начинающая компания, то, возможно, вы получите такие жизненно важные для вашего проекта финансовые вливания. Возможно вы - будущее разработки программного обеспечения, вы - создатель нового поколения программ, которые станут лидерами рынка.
Предисловие Майка Кона
И Scrum, и ХР (экстремальное программирование) требуют от команд завершения вполне осязаемого куска работы, который можно предоставить пользователю в конце каждой итерации. Эти итерации планируются таким образом, чтобы быть короткими и фиксированными по времени. Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и ХР нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода, который сойдёт на все случаи жизни. Вместо этого Scrum и ХР команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки - это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта.
Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих. То, что Хенрик разделяет эти взгляды, видно с самых первых страниц книги. Он не предлагает нам длинное описание того, что такое Scrum; вместо этого он просто ссылается на необходимые веб-ресурсы. Первым делом Хенрик начинает с описания того, как его команда работает со своим product backlog"ом. Затем он проходит по всем элементам и практикам правильно поставленного agile-проекта. Без теоретизирования. Без справочных данных. Ничего этого не нужно: книга Хенрика - не философское объяснение, почему Scrum работает или почему мы должны делать так, а не иначе. Это описание того, как работает одна успешная agile-команда.
Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и ХР на передовой.
Предисловие - Эй! А Scrum-то работает!
Scrum работает! По крайней мере, нам он подошёл (я имею в виду проект моего клиента из Стокгольма, чьё имя я не хотел бы называть). Надеюсь, вам он тоже подойдёт! И, возможно, именно эта книга поможет вам на пути освоения Scrum"а.
Очень понравилась «Scrum и XP: заметки с передовой» Хенрика Книберга в переводе Agile Ukraine . В ней Хенрик делится личным опытом ScrumMaster`ства в софтверных конторах. Никакой «воды», никаких лирических отступлений, только факты как работали они, как ещё можно работать, и как работать не нужно. Повествование от первого лица и встречающийся иногда юмор делают эту книгу интересным и лёгким чтивом.
Далее небольшой конспект перевода книги. Анонс перевода есть на Хабрахабре . Русский перевод книги можно взять на scrum.org.ua , а оригинал на infoq.com .
Product backlog – это основа Scrum’а. С него все начинается. По существу, product backlog является списком требований, историй, функциональности, которые упорядочены по степени важности. При этом все требования описаны на понятном для заказчика языке. Может хранится в екселе с публичным доступом.
Каждая история состоит из:
Дополнительные поля истории в помощь product owner`у:
Истории не должны отражать технических деталей (создать индексы), но должны описывать зачем это делается (ускорить поиск), и опционально в комментарии можно добавить совет про индексы. Так достигается ориентированность историй на бизнес.
У системы с высоким внутренним качеством иногда может быть довольно низкое внешнее. Но наоборот бывает крайне редко. Сложно построить что-то хорошее на прогнившем фундаменте. Внутреннее качество не может быть предметом дискуссии. Команда постоянно должна следить за качеством системы, поэтому оно попросту не обсуждается.
Product owner говорит «… по-быстрому “залатать” проблему». Он пытается использовать внутреннее качество как переменную, хочет, чтобы мы уменьшили оценку задач, не уменьшив при этом объём работ. Слово “заплатка” должно вызывать у вас тревогу.
Жертвовать внутренним качеством – это практически всегда очень плохая идея. Сэкономленное время ничтожно мало по сравнению с той ценой, которую вам придётся заплатить как в ближайшем будущем, так и в перспективе. Как только качество вашего кода ухудшится, восстановить его будет очень тяжело.
Для ускорения разработки нужно уменьшать объём работ, выбрасывая менее важные user story и упрощая более важные до минимально рабочего уровня.
Истории, написанные на стикерах наклеиваются на доску по убыванию приоритета. В ходе обсуждения порядок меняется. История дробится на задачи, стикеры с задачами клеятся под стикером соответствующей истории. Мы не добавляем задачи в product backlog в Excel’е потому, что:
Оптимальный объём истории — от двух до восьми человеко-дней. При средней производительности команды в 40 – 60 человеко-дней позволяет включать в спринт примерно по 10 историй. Иногда 5, а иногда 15.
Истории — это нечто, что можно продемонстрировать, что представляет ценность для product owner’а
Задачи — либо нельзя продемонстрировать, либо они не представляют ценности для product owner’a.
Техника “вчерашней погоды”. Определения.
Производительность является мерой “количества выполненной работы”. Рассчитывается как сумма первоначальных оценок всех историй, которые были реализованы в течение спринта.
Доступные человеко-дни — сумма всех человеко-часов (полной и частичной занятости) с учётом отгулов и больничных каждого члена команды на протяжении спринта, делённое на продолжительность рабочего дня.
Фокус-фактор – это коэффициент того, насколько команда сфокусирована на своих основных задачах. При низком фокус-факторе команда ожидает неоднократного вмешательства в свою работу или предполагает, что оценки слишком оптимистичны. Фокус-фактор берётся из последнего спринта либо среднее значение за несколько последних спринтов
Реальная производительность — сумма первоначальных оценок завершённых за последний спринт историй. Единица измерения — story-point.
Расчёт производительности.
Фокус-фактор
= Реальная_производительность
/ Доступные_человеко-дни
Прогнозируемая_производительность = Доступные_человеко-дни * Фокус-фактор
Product owner и команда совместными усилиями определяют критерий готовности. Например
Истории очень отличаются друг от друга. Таким образом невозможно определить общий критерий готовности. Поэтому здравый смысл часто лучше, чем формальный контрольный лист. Если вы часто путаетесь с определением критерия готовности, то вам, наверное, стоит ввести поле “критерий готовности” для каждой истории.
Критерий готовности можно определить:
Простое описание часто позволяют обнаружить разное понимание объёма работ для историй. Хорошо ведь узнать об этом заранее, не так ли?
ТИ — это всё, что должно быть сделано, но невидимо для заказчика, не относится ни к одной user story, и не даёт прямой выгоды product owner’у. Для него приоритезировать ТИ в product backlog’е было всё равно, что сравнить тёплое с мягким. Поэтому они получают самый низкий приоритет. В некоторых случаях product owner действительно прав, но чаще — нет. Product owner не всегда компетентен, чтобы идти на компромисс по приотретизации ТИ. Что можно с этим сделать:
Основополагающий принцип Scrum`а — прозрачность. Поэтому желательно информировать product owner`а о необходимых ТИ, а не просто ставить перед фактом определённого (заниженного ради ТИ) фокус-фактора. При этом product owner должен быть сообразительным и компетентным.
Варианты работы с БТ:
Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или – что ещё хуже – придумывать всякие ужасы про вас. Для этого можно использовать “страницу с информацией о спринте”:
Эта страница помещается в вики (и список всех команд и спринтов), уходит рассылкой по почте, вывешивается в печатном виде в коридоре, при приближении демо уходит рассылка с напоминанием (это всё делает scrum master).
Доска (канбан) состоит из 4х колонок (в планах в процессе, готово, доп.инфо). Каждая строка — отдельная user-story с задачами в порядке убывания приоритета (сверху вниз). По мере выполения задачи продвигаются из «в планах» через «в процессе» в «готово». В информационной части фиксируется цель спринта, burndown-chart, незапланированные, но необходимые к выполнению задачи, не вошедшие в изначальный sprint-backlog и дополнительные user-story, которые желательно выполнить, если запланированные user-story будут закончены до окончания спринта.
Простота доски необходима. Усложнять незачем. Так же на карточке задачи можно фиксировать имя исполнителя и/или идентификатор в баг-трекере.
По оси X отмечаются только рабочие дни до окончания спринта. По оси Y — прогнозируемый объём оставшейся работы (в story-point`ах). Изменения оставшейся работы фиксируются ежедневно. ScrumMaster несёт ответственность за то, чтобы команда принимала соответствующие меры при обнаружении первых тревожных симптомов (сильном отклонения кривой story-pointt`ов от линии нормального хода спринта).
В большинстве источниках, посвящённых Scrum’у, время выполнения задач оценивается в часах, а не днях (например один эффективный человеко-день равен шести эффективным человеко-часам). Но так лучше не делать потому, что:
Поэтому лучше использовать человеко-дни в качестве основной единицы при оценке времени (называть их story point’ами). При этом выбрать наименьшим значением 0.5. Т.е. любые задачи, оцененные менее чем в 0.5, либо удаляются, либо комбинируются с другими, либо оценка остаётся 0.5 (ничего страшного в слегка завышенной оценке нет). Изящно и просто.
Проводится для поддержания sprint backlog’a в актуальном состоянии. Лучше, чтоб этим занималась вся команда.
Лучше проводить встречу стоя (уменьшает вероятность затягивания «планёрки» более чем на 15 минут)
По мере рассказа каждого члена команды о сделанном за вчера и чем будет заниматься сегодня, он перемещает стикеры на доске задач.
Либо все члены команды обновляют доску задач перед каждой встречей.
Как только рассказ касается какого-то незапланированного задания — для него клеится новый стикер.
При обновлении временных оценок, на стикере пишется новая оценка, а старая зачеркивается. Иногда стикерами занимается ScrumMaster, пока участники говорят.
Можно завести специальную копилку. Если вы опоздали, даже на минуту, вы кидаете в копилку определённую сумму. Даже если вы позвонили перед началом ежедневного Scrum’а и предупредили. Этот подход работает неплохо. Но пользоваться им нужно лишь в том случае, когда люди часто опаздывают.
Демо необходимо:
Подготовка и проведение демо:
«Недемонстрируемые» вещи, такие как оптимизация кода для увеличения производительности, можно продемонстрировать либо графиками, либо диаграммами, либо таблицами.
Ретроспектива — второе по важности действие в Scrum`е (после планирования). Ретроспектива важна, т.к. это самое подходящее время для начала улучшений. Без ретроспектив вы обнаружите, что команда наступает на одни и те же грабли снова и снова.
Ретроспективы могут и не иметь чёткого плана проведения, но главная тема – всегда одна и та же: «Что мы можем улучшить в следующем спринте». В основном ретроспективу можно проводить так:
Доска ретроспективы делится на 3 колонки:
После окончания мозгового штурма по поводу всех этих стикеров, провести «точечное голосование» для определения улучшений, которым следует уделить особое внимание в ходе следующего спринта. У каждого члена команды имеется три магнитика, которыми он может воспользоваться для голосования. Каждый член команды может лепить магнитики как ему вздумается, хоть все три сразу на одну задачу. Основываясь на этом голосовании выбрать 5 улучшений, которые попытаться внедрить в следующем спринте, а на следующей ретроспективе проверить, что вышло.
Важно учиться на ошибках. Возможные способы решения проблем, найденных командой на ретроспективе, могут оказаться
полезными для остальных. Роль связующего звена тут может выполнять ScrumMaster. Можно писать отчёт, но их никто не читает. Сотрудник в роли связующего звена должен:
Иногда достаточно всего лишь четко определить проблему, и она часто решается сама собой в следующем спринте. Для этого на стене в рабочей комнате повесить записи по ретроспективе. Однако каждое изменение имеет свою цену. Если в ответ на каждую жалобу пытаться что-то делать, народ с неохотой будет рассказывать про свои даже самые мелкие проблемы, которые могут быть ужасными.
В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой. То же справедливо для Scrum’а и для разработке программного обеспечения в целом. Спринты очень изматывают. Мало кто может похвастаться: «Я потратил большую часть дня, положив ноги на стол, просматривая блоги и попивая капучино».
Ещё аргумент — после демо и ретроспективы команда и product owner будут переполнены информацией и всевозможными идеями, которые им следовало бы обмозговать. Если же они немедленно займутся планированием следующего спринта, то они не смогут упорядочить всё полученную информацию или сделать надлежащие выводы. К тому же у product owner’а не хватит времени для корректировки его приоритетов после проведённого демо.
Нужно постараться добиться того, чтобы ретроспектива спринта и следующее планирование спринта не проходили в один и тот же день. Перед началом нового спринта каждый должен хорошенько выспаться, не думая при этом о спринтах.
Один из вариантов — инженерные дни. Это когда разработчикам разрешается делать по сути все, что они хотят. (читать о последних средствах разработки и API, готовиться к сертификации, обсуждать компьютерные занудства с коллегами, заниматься своим личным проектом, поддерживать актуальность своих знаний). Хорошо, если удастся проводить инженерный день для всех команд сразу (будут воспринимать более серьёзно). Может быть фиксированный (первая пятница каждого месяца), либо плавающий (в конце каждого спринта).
Оставшуюся часть книги законспектирую чуть позже.
Хенрик Книберг
Scrum и XP: заметки с передовой
К сожалению, на благодарности нам выделили всего лишь страничку. Поэтому я постараюсь представить всех наших активистов в фактах.
Максим Харченко умудрялся переводить даже на море. Спасибо Гипер. NET
Дима Данильченко - директор и по совместительству (да и такое бывает ☺) один из самых активных переводчиков в нашем проекте.
Если по ходу книги вам очень понравился перевод, и вы заулыбались, то, скорее всего, эту главу переводил Артём Сердюк.
Боря Лебеда автоматизировал конвертацию оригинала из word’а в wiki формат. Я и понятия не имел, что это можно сделать так легко.
Ярослав Гнатюк знает Хенрика лично.
Антон Марюхненко - самый молодой и перспективный.
Сергей Петров - самый старший и опытный.
Марина Кадочникова - наша единственная девушка-переводчица.
Серёжа Мовчан, конечно же, я про тебя не забыл ☺. Просто хотел сказать тебе отдельное спасибо. Ты был тем вторым локомотивом, благодаря которому нам удалось дотянуть до победного конца. Ведь как говорится в одной японской поговорке: «Начинать легко, продолжать сложно».
Спасибо Марине Зубрицкой и Лёше Мамчию за финальную вычитку и редактуру. Им удалось найти свыше ста ошибок, в уже, казалось бы, вылизанном тексте. Нет предела совершенству.
Не забудем мы и про тех, у кого было желание, но, как часто это бывает, не было времени: Сергей Евтушенко, Артём Марченко, Алексей Тигарев, Тим Евграшин, Александр Кулик.
Лёша Солнцев,
инициатор и координатор первого украинского краудсорсингого проекта, Certified Scrum Master
P.S. Оригинал книги вы можете скачать по адресу http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Предисловие Джефа Сазерленда
Командам необходимо знать основы Scrum’а. Как создать и оценить product backlog? Как получить из него sprint backlog? Как работать с burndown-диаграммой и вычислять производительность(velocity) своей команды? Книга Хенрика - это базовое руководство для начинающих, которое поможет командам перейти из состояния «мы пробуем Scrum» в состояние «мы успешно работаем по Scrum’у».
Хорошая реализация Scrum"а становится всё важнее и важнее для команд, которые хотят получить инвестиции. Я выступаю в качестве тренера по гибким методологиям для группы компаний с венчурными инвестициями, помогая им в стремлении вкладывать деньги только в настоящие Agile-компании. Глава группы инвесторов требует от компаний, составляющих инвестиционный портфель, ответа на вопрос, знают ли они производительность своих команд. Многих этот вопрос ставит в тупик. Будущие инвестиции требуют от команд знания собственной производительности разработки программного обеспечения.
Почему это так важно? Если команда не знает собственной производительности, следовательно product owner не может разработать стратегический план развития продукта с достоверными датами релизов. Без такого плана компанию может постичь неудача, в результате чего инвесторы потеряют свои деньги.
С этой проблемой сталкиваются разнообразные компании: большие и маленькие, старые и новые, с финансированием и без. Во время недавнего обсуждения реализации Scrum"а компанией Google на лондонской конференции я решил узнать у аудитории, состоящей из 135 человек, кто из них использует Scrum? Я получил утвердительный ответ лишь от тридцати человек. Затем я поинтересовался, соответствует ли их процесс Nokia-стандарту итеративной разработки. Итеративная разработка - это ключевое положение Agile Manifest’а: «Постарайтесь предоставлять версии работающего программного обеспечения как можно чаще и раньше». В результате проведения ретроспектив с сотнями Scrum-команд в течение нескольких лет, Nokia выработала некоторые базовые требования к итеративной разработке:
Итерации должны иметь фиксированную длину и не превышать шести недель.
К концу каждой итерации код должен быть протестирован отделом качества (QA) и работать как следует.
Из тридцати человек, которые сказали, что работают по Scrum’y лишь половина подтвердила, что их команды придерживаются первого принципа Agile Manifest’а и соответствую Nokia-стандарту.
Затем я спросил их, придерживаются ли они Scrum-стандарта, разработанного Nokia:
У Scrum-команды должен быть один product owner и команда должна знать, кто это.
У Product owner’а должен быть один product backlog с историями и их оценками, выполненными командой.
У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.
На протяжении спринта никто не должен вмешиваться в работу команды.
Из тридцати команд, внедряющих Scrum, только у трёх процесс разработки соответствовал стандартам Nokia. Я думаю, что только эти три команды получат дальнейшие инвестиции от венчурных капиталистов.
Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog’а, и burndown-диаграмма. Вы также будете знать производительность вашей команды и сможете использовать все наиболее важные практики высокоэффективных Scrum-команд. Вы пройдёте Nokia Scrum-тест, за что инвесторы оценят вас по достоинству. Если вы - начинающая компания, то, возможно, вы получите такие жизненно важные для вашего проекта финансовые вливания. Возможно вы - будущее разработки программного обеспечения, вы - создатель нового поколения программ, которые станут лидерами рынка.
Предисловие Майка Кона
И Scrum, и ХР (экстремальное программирование) требуют от команд завершения вполне осязаемого куска работы, который можно предоставить пользователю в конце каждой итерации. Эти итерации планируются таким образом, чтобы быть короткими и фиксированными по времени. Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и ХР нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода, который сойдёт на все случаи жизни. Вместо этого Scrum и ХР команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки - это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта.
Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих. То, что Хенрик разделяет эти взгляды, видно с самых первых страниц книги. Он не предлагает нам длинное описание того, что такое Scrum; вместо этого он просто ссылается на необходимые веб-ресурсы. Первым делом Хенрик начинает с описания того, как его команда работает со своим product backlog"ом. Затем он проходит по всем элементам и практикам правильно поставленного agile-проекта. Без теоретизирования. Без справочных данных. Ничего этого не нужно: книга Хенрика - не философское объяснение, почему Scrum работает или почему мы должны делать так, а не иначе. Это описание того, как работает одна успешная agile-команда.
Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и ХР на передовой.
Предисловие - Эй! А Scrum-то работает!
Scrum работает! По крайней мере, нам он подошёл (я имею в виду проект моего клиента из Стокгольма, чьё имя я не хотел бы называть). Надеюсь, вам он тоже подойдёт! И, возможно, именно эта книга поможет вам на пути освоения Scrum"а.
Это был первый случай в моей жизни, когда я увидел как методология (ну да, Кен , - фреймворк) работает «прямо из коробки». Просто подключи и работай. И при этом все счастливы: и разработчики, и тестеры, и менеджеры. Вопреки всем передрягам на рынке и сокращению штата сотрудников, Scrum помог нам выбраться из сложнейшей ситуации, позволил сконцентрироваться на наших целях и не потерять свой темп.
Не хочеться говорить, что я удивлён, но… так и есть. После беглого знакомства с парой книг по теме, Scrum произвёл на меня хорошее впечатление, даже слишком хорошее, чтобы быть похожим на правду. Так что неудивительно, что я был настроен слегка скептически. Однако после года использования Scrum"а, я настолько впечатлён (и большинство людей в моих командах тоже), что, скорее всего, буду использовать Scrum во всех новых проектах, ну, разве что кроме случаев, когда есть веская причина не делать этого.