Как появился Scrum

scrum-rugby

Многие слышали о том, что термин Scrum пришел к нам из Регби. Когда-то мы даже публиковали интересное видео на тему аналогий в Скрам методологии и игре в Регби.

Лично я часто задавался вопросом, что вдохновило отцов-основателей Скрам методологии Джеффа Сазерленда и Кена Швабера, чтобы объединить минимальный набор правил, которые по сути есть здравый смысл, в единую методологию.

Scrum позволяет организовать работу команд разного уровня зрелости и делать проекты разного уровня сложности — от простых до комплексных с высокой степенью неопределенности. Всего, дается 9 основных правил, которые включают три предписанные роли, четыре типа встреч и парочку артефактов — вот и все, что нужно для успешного запуска проекта!

Как известно, многие инновации базируются на существующих идеях и, только будучи объединенными вместе, дают что-то принципиально новое. (далее…)

Как объяснить команде Scrum или упражнение “Построй свой Скрам”

build-scrum

У многих, кто читает этот блог, я уверен, были случаи, когда было необходим рассказать про Scrum методологию своей команде или группе людей. И неважно, было это только чтобы познакомиться с фреймворком, освежить знания или чтобы разобраться с деталями и начать практиковать – вы так или иначе показывали картинку, где расставлены роли, артефакты и встречи.

Думаю, в моей работе тренера и коуча Agile команд, мне приходится делать это еще чаще чем вам :-). И основной совет – это рисовать картинку от руки, а не использовать слайды или распечатки. В этом случае люди лучше запоминают основные части и именно этот принцип я использовал в видео курсе «Agile своими силами», когда рассказывал про Scrum фреймворк.

Нередко так бывает, что группа людей? с которой я общаюсь, уже что-то слышала или читала про Scrum, но знания на разном уровне и общей картины у всех нет.  В этом случае рассказывать с нуля, может быть немного скучным и утомительным, так как люди про это вроде бы слышали.

С другой стороны, мне необходимо быстро выявить пробелы в знаниях и явное непонимание терминов, плюс все-таки нарисовать картинку, чтобы была перед глазами, плюс привести всех к общему пониманию. Для этого я использую упражнение, которое можно назвать “построй свой Скрам”, и вот как я это делаю.
(далее…)

Числа, Имена, Даты или что вы используете для имени Спринта?

Порадовал Майк Кон своим недавним постом «Числа, Имена, Даты или пропойте свой Спринт», где он говорит о том, как некоторые команды называют свои Спринты.

Некоторые команды нумеруют свои Спринты: Sprint 1, Sprint 2…, а некоторые даже обозначают их как Sprint 1.1., Sprint 1.2, чтобы показать принадлежность Спринта к определенной версии релиза.

Мне приходилось видеть такие названия не раз, и они удобны, когда у вас проект и есть определенный план. Есть в таких именах нечто логичное, структурированное и в то же время чуточку бюрократичное :-).

Многие команды, с которыми я работал, используют (далее…)

Как расставлять приоритеты при совмещении роли ScrumMaster в команде

scrummaster

Интересный вопрос, который я неоднократно встречаю с самых первых дней практики и «евангелизации» Scrum подхода. Действительно, для маленьких команд от 5 до 9 человек (как предписывается), да еще и в аутсорсинге (как бывает) нанять отдельного выделенного ScrumMaster может быть проблемой. Бывает, что роль не до конца понятна команде и заказчику/менеджменту. А бывает, что банально не хватает денег на хорошего опытного ScrumMaster’а, который «разгонит» и оптимизирует команду —  поможет ей достигнуть небывалых высот.

В любом случае, многие приходят к казалось бы логичной идее совместить эту роль с технической ролью в команде. Тем самым получить продуктивного игрока, который лишь половину времени уделяет ScrumMaster’ству, а остальное время приносит пользу делает что-то в другой роли (разработчик, тестировщик, бизнес-аналитик и т.п.).

Давайте рассмотрим примеры такого совмещения, какие бывают плюсы и минусы и как можно расставлять приоритеты. (далее…)

Онлайн курс "Agile своими силами" теперь доступен каждому!

За прошедший год мне удалось реализовать настоящий полноценный продукт, который называется «Agile своими силами». Очень много времени ушло на то, чтобы составить такой курс, после просмотра которого было бы все ясно и понятно, чтобы действительно можно было начать внедрять все, что касается Agile в целом, и Scrum в частности.

Я уверен, что этот курс дает полную картину и поможет всем, кто хочет что-то поменять в существующем устое, кто хочет разобраться, что представляют собой Agile подходы к разработке программного обеспечения, кто хочет начать делать что-то самостоятельно, кто уже много чего знает про Agile, Scrum и связанные темы, но еще ни разу не пробовал применить свои знания, кто уже попробовал внедрять какую-то из Agile методологий или просто отдельные практики, и не очень получилось, кто уже практикует Scrum или другую Agile методологию,  но нужен свежий взгляд на текущую ситуацию, и конечно же тем, кто еще не пробовал и не изучал, даже если и слышал про Agile.

В этом курсе я делюсь своим опытом, именно опытом того, через что я прошел сам,  а не теориями из книжек. Именно поэтому считаю этот курс уникальным 🙂 Здесь в основном практические аспекты, хотя без теории тоже никуда, но она здесь только для общего понимания и ее по сути — минимум.

Итак, Agile своими силами — это онлайн-курс самостоятельного изучения различных аспектов Agile в виде серии коротких видеороликов. Программа представляет серию из 13 видеороликов, продолжительностью до 30 минут, каждый из которых рассказывает об отдельной теме. Всего более 6 часов видеоматериала! (далее…)

Мифическая роль Владельца Продукта (Product Owner)

Несомненно, роль Владельца Продукта является ключевой при использовании любой Agile методологии. В тоже время, ожидания и определение этой роли размыты еще больше, чем роль Скрам Мастера и Scrum команды.

Если говорить метафорами, то Scrum команда — это мощный (или не очень 🙂 ) автомобиль, и то, как быстро он едет, напрямую зависит от опыта водителя — Владельца Продукта.

Как мы знаем, водить многие учатся, где попало и как попало, поэтому так и ездят управляют проектами. Работая со своими клиентами, я видел много примеров того, как исполняется роль Product Owner, и постоянно обдумываю, как объяснить эту роль, когда готовлюсь к своим тренингам по Agile управлению проектами. Что интересно, многие мысли все больше и больше подтверждаются практикой. (далее…)

Почему недельная длина Спринта хуже, чем двухнедельная

В 90-х Джеф Сазерленд и Кен Швабер экспериментировали со своими командами и вырабатывали подходы, которые потом и назвали Scrum методологией. Они говорили о коротком цикле разработки длиной в один месяц. На фоне долгосрочных многолетних проектов – это была уже сама по себе революция, которая обеспечивала быструю обратную связь и гибкость всего проекта. Сегодня две недели стали уже де-факто стандартом длины итерации (спринта). Более того, некоторым компаниям две недели оказываются слишком долгими, и они требуют от своих команд коротких недельных итераций.

«Почему недельная  длина спринта хуже?», — этот вопрос мне часто задают команды, с которыми я работаю, во время моих тренингов и просто в общении со знакомыми Скрам мастерами. Попробую обобщить свои мысли на эту тему. (далее…)

"Раскрась свой Бэклог!" или о чем я рассказывал на Agile Eastern Europe

На прошедшей недавно конференции Agile Eastern Europe, я решил поддержать рускоязычную сцену и выступил с докладом «Раскрась свой Бэклог! или о том, как принимать решения на основе разных типов элементов бэклога».

Ниже под катом находится слайдкаст моего выступления — те, кто не смог присутствовать, могут и посмотреть и послушать.

Сама идея того, что в Бэклоге Продукта могут быть разные типы элементов, очень быстро приходит к тем, кто начинает практиковать Scrum или другую Agile методологию. Ведь Бэклог — это и инструмент взаимодействия с внешним миром, и инструмент планирования на разных уровнях. Достаточно быстро становится очевидным, что туда должно попадать все, на что нужно инвестировать время команды, чтобы получить в результате рабочий продукт.

Что же вы положите в Бэклог и, на что это повлияет?
(далее…)

Какую проблему решает буфер времени при планировании итерации

В прошлой статье я рассказывал об одной технике, которая применяется при планировании итерации. Судя по комментариям, которые на мой взгляд отходят от темы, я понял, что в прошлой статье не раскрыл главный вопрос — зачем и когда применять эту технику 🙂

Действительно, любой здравомыслящий человек, прежде чем применять новый подход, должен задаваться вопросом: «Какую проблему я решаю?».

Итак, какую проблему мы решаем с помощью буфера времени? Моя статья была навеяна проблемой планирования итерации, которую я обсуждал со своими клиентами. Вы наверное видели ниспадающие (burndown) графики в Cпринте, вроде этого:

График команды "опоздали"

или этого:

График хорошей команды

Они говорят о том, что команда планирует больше, чем реально может сделать. Это может происходить из-за того, (далее…)

Когда подстилать соломку или планирование Спринта с учетом вашей реальности

Когда-то, я писал о Разноцветном Бэклоге, т.е. о применении идеи цветовых маркировок для разных типов элементов Бэклога. Да-да, не удивляйтесь, Бэклог Продукта может содержать элементы разного типа — это иногда оказывается «новостью» для тех, кто только начинает практиковать Scrum и прочел только несколько статей или короткую книжку 😉 Одна только работа с Бэклогом содержит много нюансов, о которых я рассказывал во время онлайн курса или уже неоднократно писал. Так что если вы хотите больше узнать, то почитайте мои статьи на эту тему.

Другой вопрос, который я получаю сразу после того, как читатели, или слушатели тренинга, разобрались с идеей разных элементов Бэклога: «Как их учитывать при планировании Спринтов или целых выпусков?». Иногда просто так и спрашивают: «Как оптимально планировать итерацию?». Ответ прост, как и все из того, что применяется в Agile методах и о чем я рассказываю в этом блоге.  (далее…)