Scrum - методология управления проектом. Управление проектами: метод "Scrum"

Текущая страница: 1 (всего у книги 21 страниц) [доступный отрывок для чтения: 5 страниц]

Джефф Сазерленд

Scrum. Революционный метод управления проектами

Jeff Sutherland

The Art of Doing Twice the Work in Half the Time

Издано с разрешения Scrum, Inc. c/o The Ross Yoon Agency

Правовую поддержку издательства обеспечивает юридическая фирма «Вегас-Лекс»

* * *

Эту книгу хорошо дополняют:

Управление проектами

Вадим Богданов

Бизнес-процессы

Владимир Репин

Deadline

Том Демарко

Предисловие партнера к российскому изданию

Книга, которую вы держите в руках, написана одним из авторов Scrum. Он рассказывает о предпосылках создания методологии и основных ее аспектах.

Самое важное в данной методологии (на мой взгляд) – ориентация на клиента. Заказчик должен получить то, что хочет, вовремя и с минимальными затратами.

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

Основная характеристика Scrum – гибкость. Данный подход позволяет оперативно реагировать на изменения в требованиях заказчика и быстро адаптировать продукт к ним.

На сегодняшний день Scrum – хорошо проработанная методология. Ее популярность растет с каждым днем, в том числе в нашей стране. Однако при внедрении Scrum могут возникнуть трудности. Во-первых, предполагается активное участие заказчика в проекте, а во-вторых, требуется слаженная командная работа. По своему опыту могу сказать, что не всегда удается добиться присутствия заказчика на собраниях и адекватной обратной связи от него. Профессионализм, ответственность и умение работать в команде также нельзя назвать неотъемлемыми чертами нашей российской бизнес-действительности.

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

Книга написана очень живым языком и благодаря насыщенности фактическим материалом легко читается. Автор приводит множество примеров проектов, в которых использовалась Scrum: от таких крупных, как план модернизации системы управления информацией ФБР и одной из крупнейших фармацевтических компаний, до проекта ремонта дома. Также в ней даются ссылки на исследования, которые иллюстрируют психологические аспекты управления проектами.

Все это делает книгу «Scrum. Революционный метод управления проектами» интересной и полезной для всех, кто интересуется проектным управлением и хочет повысить свою эффективность в этой сфере. Думаю, после ее прочтения у всех возникнет желание использовать подходы и инструменты, которые дает автор, а также изучить этот метод глубже.

...

Ульяна Самолова,президент Samolov Group

Введение

Почему Scrum?

Все началось с того, что двадцать лет назад мы с Кеном Швабером создали свой подход к разработке программного обеспечения для технологических отраслей и назвали его Scrum. Наша методология была более быстрой, надежной и эффективной.

До того момента при управлении проектами по разработке программного обеспечения использовали каскадную модель – и так вплоть до 2005 года. Работа осуществлялась пошагово, постепенно продвигаясь к цели – получению конечного результата и передаче его пользователю. Процесс шел медленно, развивался непредсказуемо, зачастую так и не приводя к возникновению продукции, в которой нуждался заказчик или которую просто пожелали бы приобрести люди. Волокита, оборачивающаяся многими месяцами, а иногда и годами, – вот характерная черта каскадной модели. Предварительно составленные поэтапные планы, представленные на диаграммах Ганта, выглядели настолько подробными, что внушали руководству уверенность, будто процесс разработки находится у них под полным контролем, – и все-таки мы практически были обречены выпадать из графика и катастрофически выходить за рамки бюджета.

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

С момента своего возникновения концепция Scrum легла в основу проектирования новых программных продуктов для технологических отраслей. Однако, снискав признание и успех в Кремниевой долине среди руководителей проектов по созданию программного обеспечения и нового оборудования, в общей деловой практике Scrum остается еще малоизвестной методологией. Именно ради этого делового сообщества – людей, не связанных напрямую с миром высоких технологий, – я задумал написать книгу, в которой собираюсь раскрыть и разъяснить преимущества Scrum как системы управления в бизнесе. Я расскажу о первоистоках методологии Scrum: производственной системе компании Toyota и концепции, созданной для задач боевой авиации, – цикле OODA . Рассмотрю вопрос, почему организация проектов силами небольших команд является более эффективным способом работы. Остановлюсь на следующих моментах: как правильно расставлять приоритеты в работе над проектом; как организовывать спринты, то есть короткие этапы разработки проекта (от одной недели до одного месяца), – причем делать это таким образом, чтобы каждый член команды отвечал за свою часть работы, а результат последующего этапа вбирал в себя функции проекта, реализованные на предыдущих этапах; как проводить ежедневные короткие обсуждения задач проекта, чтобы быть не только в курсе сделанного, но и тех трудностей, с которыми неизбежно приходится сталкиваться. Кроме того, я объясню, как методология Scrum объединяет концепцию непрерывного совершенствования и концепцию реализации продукта с минимальным функционалом, что позволяет не ждать завершения всех работ, а оперативно удовлетворять требования заказчика на каждом этапе проекта. Вы узнаете, что мы применяли Scrum при проектировании абсолютно всего: от создания дешевых автомобилей с расходом топлива четыре литра на сто пятьдесят километров до разработки современных, на уровне XXI века, баз данных ФБР.

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

...

Джефф Сазерленд

Глава первая

Привычное мироустройство дает трещину

Джефф Джонсон был заранее уверен, что денек выдастся нелегким. Тогда, 3 марта 2010 года, Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией. Воплотив его, ФБР смогло бы предотвращать события, подобные 11 сентября. Однако разработка проекта потерпела фиаско – одно из самых грандиозных, которое знавала история развития программного обеспечения. В Бюро пытались обновить свою компьютерную систему уже более десяти лет, и похоже, их постигла катастрофа. Опять провал.

Но на сей раз – с детищем Джеффа Джонсона – все пойдет иначе.

Семь месяцев назад он появился в ФБР и заинтересовал своим предложением директора по информационному обеспечению Чеда Фулгэма – когда-то они вместе работали в банке Lehman Brothers. Джеффа назначили помощником начальника управления информационных разработок и дали офис на верхнем этаже здания имени Эдгара Гувера, то есть в штаб-квартире ФБР, расположенной в центре Вашингтона, округ Колумбия. Из его просторного кабинета открывался вид на монумент Вашингтона. Вряд ли Джефф предполагал, что ближайшие два года ему предстоит провести в бетонном подвале, в каморке без окон, где он будет пытаться исправить проект, который, по общему мнению, считался безнадежным.

Джефф Джонсон и его босс сочли правильным заявить о поражении и закрыть программу, работа над которой длилась без малого десять лет и обошлась ФБР в сотни миллионов долларов. Настал момент признать, что больший смысл имело бы забрать ее себе и трудиться над ней самостоятельно внутри отдела. «Решение далось нам нелегко, – сказал Джефф. – Но проект требовалось сделать, и сделать хорошо».

Столь долгожданная электронная система была призвана помочь ФБР вступить в новую эпоху – эпоху Facebook, Twitter, Amazon и Google. Шел 2010 год, а большинство документации хранилось в бумажном виде. Программная система, когда-то созданная для нужд Бюро, называлась «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и работала на гигантских ЭВМ – последнем слове техники далеких восьмидесятых. Многие спецагенты предпочитали ею не пользоваться. Слишком она была громоздкой и медленной для эпохи терактов и стремительно перемещающихся преступников.

Когда агенту ФБР требовалось что-то сделать – а фактически все что угодно : заплатить осведомителю, выследить террориста, составить досье на банковского грабителя, – его работа мало чем отличалась от аналогичной тридцатилетней давности. Вот как описывает эту процедуру Джонсон: «Вы составляли в текстовом редакторе подробную записку и распечатывали ее в трех экземплярах. Одну копию посылали на утверждение, и она проходила всю санкционную цепочку до самого верха. Вторую отправляли в местный архив на случай, если первая потеряется. Ну а с третьей вы садились, брали красную ручку – да-да, я не шучу, красную ручку – и обводили ключевые слова для занесения в базу данных. Вы индексировали собственный отчет».

Итак, если ваш запрос одобряли, то первый экземпляр пронумеровывали и спускали вниз. Просто номер, проставленный на листе бумаги, – именно так в ФБР осуществлялось управление документами по расследуемым делам. Система была вопиюще архаичной и фантастически уязвимой. В том числе и из-за нее на Бюро возложили вину, что его подразделения не сумели связать все сведения воедино и обнаружить многочисленных активистов «Аль-Каиды», въехавших в страну за месяцы и даже считаные недели до 11 сентября. Один отдел следил за некой подозрительной личностью. Другой отдел занимался сомнительными иностранцами, почему-то одновременно в большом количестве проходящими летную подготовку. В третьем отделе занесли в список особого контроля кого-то неблагонадежного. Но между отделами не существовало никакого обмена информацией. Во всем ФБР никто так и не сложил вместе имеющиеся данные.

Комиссия 11 сентября – в попытках установить внутренние факторы, позволившие произойти тому, что произошло, – детально изучила все обстоятельства террористических атак. По мнению членов комиссии, аналитики не могли получить доступа к информации, которую должны были исследовать. «Плачевное состояние информационных систем ФБР, – гласит отчет, – привело к тому, что получение такого рода доступа в большей степени зависело от личных отношений аналитика с сотрудниками оперативных команд и подразделений, располагавших информацией».

До событий 11 сентября в ФБР никогда не выполняли экспертной оценки общей террористической угрозы Соединенным Штатам. На то было множество причин: от погони за карьерой до проблем с обменом информацией. Однако недостаток технологического развития указан комиссией как, пожалуй, основной фактор, из-за чего Бюро потерпело такое трагическое фиаско в дни, предшествовавшие 11 сентября. «Информационные системы катастрофически не соответствовали ситуации, – заключила комиссия в отчете, – в ФБР были лишены возможности охватить в полной мере ту информацию, которой оно обладало, поскольку не существовало эффективного механизма хранения и совместного использования накопленного объема знаний».

Когда сенаторы начали задавать ФБР некоторые неудобные вопросы, представители Бюро в основном отделывались фразой: «Не беспокойтесь, мы уже разрабатываем план модернизации». На этот проект под названием «Виртуальные следственные дела» (Virtual Case File, VCF) возлагали большие надежды. В желании извлечь максимальную выгоду из любого кризиса отвечавшие за разработку чиновники заявили о необходимости добавить всего лишь 70 миллионов долларов к имеющимся 100 миллионам, которые были предусмотрены в бюджете. Если вы почитаете публикации того времени, рассказывавшие о новом программном обеспечении для ФБР, то обнаружите, что никто не скупился на слова вроде революционный и преобразование .

Спустя три года проект закрыли. Программа была непригодна для работы. Ни на йоту. ФБР потратило 170 миллионов долларов из кармана налогоплательщиков на покупку компьютерной системы, которой никто никогда не будет пользоваться – ни единой строчкой кода, ни одним приложением, ни малейшим кликом мыши. Проект в целом оказался полностью провальным. И это нельзя считать простым недоразумением – неудачей IBM или Microsoft. Ведь на кону без преувеличения стоял вопрос о человеческих жизнях . На страницах Washington Post появилось признание Патрика Лехи, сенатора-демократа от штата Вермонт, председателя юридического комитета сената:

...

Мы располагали информацией, которая могла бы предотвратить 11 сентября. А они там сидели, и никто не принял никаких мер… Я до сих пор не вижу, что они устраняют проблему… Пока мы дойдем до технологии XXI века, уже наступит XXII столетие {1} .

Довольно показательно, что после провала программы «Виртуальные следственные дела» многие сотрудники ФБР перестали быть таковыми.

К следующему проекту, названному «Страж» (Sentinel), ФБР приступило сразу, в 2005 году. Программа обязательно начнет работать. В данном случае все будет иначе: в Бюро примут необходимые меры, проведут надлежащие бюджетные процедуры и организуют правильные средства контроля. Они как следует выучили урок. Цена вопроса? Сущий пустяк – 451 миллион долларов. И система «Страж» будет полностью работоспособной в 2009 году.

Что на этот раз могло пойти не так? Ответ появился в марте 2010 года и лежал на столе Джеффа Джонсона. Компания Lockheed Martin, подрядчик, которого наняли для разработки новой системы, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения программы, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, а налогоплательщикам пришлось бы раскошелиться дополнительно на 350 миллионов долларов минимум.

Разбираться с проблемой пришлось Джонсону.

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

Дело было в способе работы. В том, как работает большинство людей . В том, как, по нашему общему мнению, должна выполняться работа, потому что именно так нас учили ее делать.

Когда узнаёшь, как происходил процесс разработки, то на первых порах создается впечатление , будто все складывалось вполне разумно. Прежде чем участвовать в конкурсе за право работать над проектом, сотрудники Lockheed изучили потребности заказчика и продумали, как создать систему, отвечающую его требованиям. Тогда собралось много разумных людей, терпеливо работавших на протяжении нескольких месяцев, планируя, что именно следует сделать. Затем они потратили еще больше месяцев, выясняя, как это должно быть осуществлено. Они нарисовали замечательные графики, где были обозначены и все подробности, которые нужно выполнить, и время, которое потребуется на каждую задачу. Потом за счет точного подбора цветов они показали, как каждая фаза проекта последовательно переходит в другую – все это напоминало водный каскад.

Каскадная модель

Такие графики называют диаграммами Ганта, по имени их создателя Генри Ганта. С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы – и делать их по-настоящему комплексными – они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны – без исключения.

Генри Гант придумал свои знаменитые диаграммы в 1910 году. Впервые ими начал пользоваться генерал Уильям Крузер, начальник артиллерийско-технической службы вооруженных сил США в Первую мировую войну. Каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее «окопные» организационные идеи остаются популярными и по сей день.

На самом деле все выглядит невероятно заманчиво, когда работа, которую предстоит выполнить по крупному проекту, детально изображена графически и представлена на всеобщее обозрение. Посещая многие компании, я видел сотрудников, чьей единственной обязанностью было ежедневно обновлять диаграммы Ганта. Беда лишь в том, что как только этот превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.

Такая схема действия довольно неуместна и напоминает модель поведения Политбюро ЦК КПСС в конце 1980-х годов, якобы верившему отчетам, которые оно получало накануне крушения Советского Союза. Чистая видимость. Сегодня, как и в те годы, отчеты продолжают быть важнее действительности – а ведь они, судя по всему, призваны ее описывать, – но если вдруг всплывут несоответствия, то виновным назначают реальность, а не диаграмму.

В бытность свою кадетом Военной академии США, более известной как Вест-Пойнт, я спал в бывшей комнате Эйзенхауэра. По ночам уличные огни, отражаясь в висевшей над камином золотой табличке, иногда будили меня. Табличка гласила: «Здесь спал Дуайт Эйзенхауэр». Я вспомнил об этом президенте, поскольку он однажды заметил, что планировать сражение очень важно, но стоит прогреметь выстрелам – и твоя схема действий развеивается вместе с первым дымом. По крайней мере, Эйзенхауэру хватило здравого смысла не использовать диаграммы Ганта.

Итак, Lockheed представила ФБР множество соблазнительных графиков, и Бюро подписало договор. На этот раз, по общему мнению, задание было детально продумано, поэтому ничто не могло пойти наперекосяк: «Взгляните, вот план работы над проектом – с цветной маркировкой, шкалой времени и гистограммами».

Однако весной 2010 года Джефф и его босс, директор по информационному обеспечению Чед Фулгэм, в очередной раз просматривая план, поняли, какой полной профанацией являются, по сути, все подобные диаграммы. Эти двое начали изучать реальное положение дел, знакомиться с фактическими результатами и осознали, что решить проблему невозможно. Новые дефекты обнаруживались у программы быстрее, чем удавалось устранить уже выявленные.

Чед доложил генеральному инспектору Министерства юстиции , что завершить систему «Страж» Бюро сможет только в том случае, если возьмет на себя управление проектом: они сократят количество разработчиков, выполнят наиболее трудную часть плана в пять раз быстрее и истратят менее одной десятой бюджетных денег. В докладах генерального инспектора Конгрессу, обычно сухих и официальных, явственно звучали скептические нотки.

Представители финансового контроля, регулярно проводившие по распоряжению генерального инспектора проверку хода работ над проектом, в октябре 2010 года представили очередной отчет, в котором выразили серьезную озабоченность по поводу предложения ФБР; свои основные соображения они изложили в девяти пунктах, после чего следовало их заключение:

...

В общем и целом у нас есть существенные опасения в отношении предложенного нового подхода; остается немало вопросов по поводу способности исполнителей обеспечить завершение проекта «Страж» без дополнительных расходов, без нарушения сроков и при сохранении в новой системе функциональности старой системы управления следственными делами… {2}

Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах - о том, как организовать слаженную командную работу.
Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

Революционный ли это метод, как указано в названии? Не знаем. Но, возможно, те, кто не читал книгу и не знаком с методикой, почерпнут для себя ряд полезных идей из нашего саммари (краткого изложения). Итак…

Что такое Scrum. Суть методики

«Порвите свои визитки. Избавьтесь от званий и титулов, от руководителей и иерархических структур. Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят ».

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

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

Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

Для начала необходимо выбрать «Владельца продукта» - человека, обладающего видением того, что вы собираетесь создать или достигнуть.
Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
Нужно выбрать «Скрам-мастера» - того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт - определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель - постоянно превосходить свои собственные результаты - «наращивать динамику производительности».
Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста - ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
По завершении спринта команда делает его обзор - проводит встречу, на которой участники рассказывают, что сделано за спринт.
После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

Недостатки традиционного подхода к управлению проектами

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

Каскадная модель предполагает использование диаграмм Ганта - графиков, на которых обозначаются этапы работы и время на их выполнение. Ход проекта детально размечается и отражается каждый шаг работы. Предполагается, что каждая фаза проекта последовательно переходит в другую, - это и есть принцип каскада.

Изображение с сайта www.quickiwiki.com

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

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, «каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день».

В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое «верило» отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.

«Сегодня, как и в те годы, отчеты продолжают быть важнее действительности - а ведь они, судя по всему, призваны ее описывать, - но если вдруг всплывут несоответствия, то виновным назначают реальность, а не диаграмму ».

Планы рассыпаются в прах. Альтернатива - это Scrum

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

Слово scrum («схватка») автор позаимствовал из игры в регби. Оно «обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. „Схватка“ представляет собой идеальную модель полного взаимодействия игроков ». И это именно то, что требуется для успешной командной работы.

Изображение с сайта brendanmarsh.com

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

«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.
На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот - недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости ».

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

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

Как отмечает Джефф Сазерленд, благодаря использованию Scrum, группы учатся добиваться «сверхэффективности», поднимая свою производительность на триста или четыреста процентов.

Философия scrum

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

Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда «ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) - это одновременно и концепция боевых искусств, и показатель уровня мастерства».

Суть командной работы в Scrum

Scrum - это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:

непрекращающийся поиск совершенства;
автономность - способность к самоорганизации;
многофункциональность. Наличие разных специалистов и культура взаимодействия и взаимопомощи.

На многофункциональности стоит заострить внимание особо. Автор приводит пример многофункциональной команды из спецназа - группу «Альфа» (команда «А»). Каждая такая «команда „А“ сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий „обычных“ армейских сил, заключается в том, что „зеленые береты“ самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому - ведь именно в таких „швах“ таится слабое место, из-за которого возникают ошибки ».

Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы - около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.

Кроме того автор напоминает о «законе Брукса»:

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

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

Нет мультизадачности

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

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

Никаких переработок

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

«Этот феномен окрестили „истощение эго“. Идея заключается в том, что принятие любого решения требует от вас энергетических затрат. Это странный вид истощения - вы не чувствуете физического утомления, но ваша способность принимать взвешенные решения снижается. Что на самом деле меняется, так это наш самоконтроль - наша способность быть дисциплинированными, вдумчивыми и просчитывать последствия ».

Вывод: в нерабочее время отдыхайте, полностью отдалитесь от работы, заряжайтесь приятными впечатлениями.

«Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколько кто-то потратил времени на то, чтобы что-то сделать? Единственное, что имеет значение, - как быстро и качественно это было сделано ».

Суть работы - поток

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

Как его достичь? За состоянием потока стоит внутренняя дисциплина.

«Не должно быть ни одного движения впустую ».

Скрам и счастье

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

В конце каждого спринта участники устраивают ретроспективное собрание, на котором рассказывают о своих работах и перемещают рассмотренные задачи в колонку «Сделано», а потом обсуждают, что хорошо, а что можно улучшить. Они находят основную помеху и думают, как ее устранить в следующем спринте. Это и есть решение проблемы непрерывного совершенствования.

«Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее ».

Элементы скрам

Спринты

Как уже отмечалось выше, в начале спринта и для обеспечения открытости и наглядности, нужно завести специальную доску и поделить ее на три колонки: «Бэклог»; «В работе»; «Сделано». Перед каждым спринтом члены команды наклеивают в колонку «Бэклог» стикеры с задачами, которые, по их мнению, они могут выполнить за спринт. В течение спринта, любой член команды, взявшись за задачу, переклеивает стикер из раздела «Бэклог» в колонку «В работе». После выполнения задачи - в колонку «Сделано». Таким образом, каждый видит, над чем сейчас работают другие участники.

Изображение с сайта nyaski.ru

Однако есть важное замечание - «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».

«Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „блокируются“. Никто не имеет права их менять или вносить добавления ».

Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.

Ежедневные собрания

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

Делайте до конца

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

«Израсходованы ресурсы, силы, время, деньги, но полностью функционирующий продукт не получен ».

Планирование в Scrum

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

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема - такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, «Такса - единица; дог - тринадцать; лабрадор стал пятеркой, а бульдог - тройкой ».

Автор также предлагает использовать интересную методику покер планирования. Ее суть - каждому участнику процесса планирования дается колода карт с числами Фибоначчи - 1, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».

Требования - это истории

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

«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“.

Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин:

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

Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание ».

Пользовательская история должна быть завершенной, независимой от разных обстоятельств, реализуемой на практике. Эти критерии говорят о готовности истории. Также важно, чтобы историю можно было оценить на предмет ее выполнимости.

Как планировать спринт

В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется - «планирование спринта».

«Все собираются вместе, просматривают список пользовательских историй, которые уже стоят в очереди на выполнение; выясняют, какое количество задач может взять на себя каждый участник группы; тщательно взвешивают, смогут ли они за этот спринт довести до полной готовности отобранные задания; смогут ли продемонстрировать заказчику сделанные единицы работ и показать ему готовые функции продукта; смогут ли сами себе в конце спринта сказать, что они со всем справились ».

После этого команда дружно произносит: «Вперед!» - и принимается за работу

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа - это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику - сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише ».

Открытость во всем

Скрам предполагает прозрачность всех действий и процессов.

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

«Секретность - яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды ».

Расстановка приоритетов

Эту диаграмму нужно иметь в виду каждому предпринимателю. Суть работы заключается в поиске золотой середины - сбалансированной концепции между тремя крайностями:

Вы выдвигаете на первый план то, что вы можете предложить. Тогда возникает риск сделать никому ненужный продукт;
Вы ориентируетесь на рынок. Тогда вас могут опередить или уничтожить конкуренты;
Ваше главное стремление - большие продажи. Тогда вы рискуете выпустить на рынок посредственный продукт.

Бэклог

Как уже отмечалось, бэклог в скраме - это список требований и функций продукта, упорядоченный по степени важности задач. Он может содержать и сотни заданий или несколько.

«Смысл составления бэклога представляет создание максимально полного перечисления требований, предъявляемых к функциям продукта. На самом деле никто и не собирается выполнять подряд каждый пункт, но такой документ, содержащий все, что в принципе могло бы быть включено в концепцию проекта, всегда должен находиться под рукой. Некоторые требования отбираются в первую очередь ».

Как правильно расставить приоритеты?

«Для этого нужно выяснить, какие пункты списка:

имеют самое большое значение для хода работ над проектом;
важнее всего для заказчика или будущего потребителя;
принесут максимальный доход;
проще всего осуществить».

Джефф Сазерленд отмечает, что важно помнить в списке всегда есть задачи, которыми вы никогда не сможете заняться. Вам необходимо выбрать те, которые приносят максимальную пользу при минимальном риске.

Владелец продукта

В скраме предполагается три роли: скрам-команда - исполнители конкретных проектов; скрам-мастер - это тот, кто следит за ходом проекта и помогает команде решать проблемы, и владелец продукта - тот, кто решает вопросы концепции продукта и составляет бэклог.

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

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

Минимизация рисков в скраме

Так как в скраме предусмотрена пошаговая сдача проекта, то это способствует минимизации рисков. Это помогает быстрее показывать клиенту продукт и получать от него обратную связь.

«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное? »

Вам не нужно тратить огромные средства перед тем, как понять, что-то не работает.

Как внедрить Scrum прямо сейчас

Джефф Сазерленд советует начать со сбора команды и составления бэклога. Нужно составить концепцию своего продукта и начать дробить его на задания. Не обязательно все требования сразу вносить в бэклог - можно выделить на это неделю. «Пока члены вашей команды проводят ежедневные собрания на ходу и первые спринты, вы сможете за это время составить довольно объемный бэклог, чтобы было чем занять команду на несколько спринтов вперед. Не забывайте почаще в него заглядывать, потому что команда начнет ускорять темп и будет выполнять больший объем работ, чем вы планировали в самом начале ».

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

О нас

Мы рассказываем о ключевых идеях из лучших книг жанра нон-фикшн. В нашей

Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

« Порвите свои визитки. Избавьтесь от званий и титулов, от руководителей и иерархических структур. Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят » .

Что такое Scrum. Суть методики

Для начала необходимо выбрать « Владельца продукта» - человека, обладающего видением того, что вы собираетесь создать или достигнуть.
Затем нужно собрать « Команду» , в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
Нужно выбрать « Скрам-мастера» - того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название « Бэклог продукта» . Он может развиваться и изменяться на протяжении всего срока реализации проекта.
Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание , на котором они запланируют спринт - определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель - постоянно превосходить свои собственные результаты - « наращивать динамику производительности» .
Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: « Нужно сделать, или бэклог» ; « В работе» ; « Сделано» . На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки « Бэклог» в колонку « в работе» , а затем в « сделано» .
Ежедневно проводится скрам-собрание . По выражению Джеффа Сазерленда « это пульс всего процесса Scrum» . Суть его проста - ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: « Что ты делал вчера, чтобы помочь команде завершить спринт?» , « Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?» , « Какие препятствия встают на пути команды?» .
По завершении спринта команда делает его обзор - проводит встречу, на которой участники рассказывают, что сделано за спринт.
После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

Недостатки традиционного подхода к управлению проектами

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

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, « каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „ окопные“ организационные идеи остаются популярными и по сей день» .

В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое « верило» отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.

« Сегодня, как и в те годы, отчеты продолжают быть важнее действительности - а ведь они, судя по всему, призваны ее описывать, - но если вдруг всплывут несоответствия, то виновным назначают реальность, а не диаграмму » .

Планы рассыпаются в прах. Альтернатива - это Scrum

Слово scrum (« схватка» ) автор позаимствовал из игры в регби. Оно « обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. „ Схватка“ представляет собой идеальную модель полного взаимодействия игроков » . И это именно то, что требуется для успешной командной работы.

Изображение с сайта brendanmarsh.com

« Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт» .На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот - недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости » .

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

Как отмечает Джефф Сазерленд, благодаря использованию Scrum, группы учатся добиваться « сверхэффективности» , поднимая свою производительность на триста или четыреста процентов.

Философия scrum

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

Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда « ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) - это одновременно и концепция боевых искусств, и показатель уровня мастерства » .

Суть командной работы в Scrum

Scrum - это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:

непрекращающийся поиск совершенства;
автономность - способность к самоорганизации;
многофункциональность. Наличие разных специалистов и культура взаимодействия и взаимопомощи.

На многофункциональности стоит заострить внимание особо. Автор приводит пример многофункциональной команды из спецназа - группу « Альфа» (команда « А» ). Каждая такая « команда „ А“ сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий„ обычных“ армейских сил, заключается в том, что „ зеленые береты“ самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому - ведь именно в таких „ швах“ таится слабое место, из-за которого возникают ошибки » .

Кроме того автор напоминает о «законе Брукса»:

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

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

Нет мультизадачности

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

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

Никаких переработок

« Этот феномен окрестили „ истощение эго“ . Идея заключается в том, что принятие любого решения требует от вас энергетических затрат. Это странный вид истощения - вы не чувствуете физического утомления, но ваша способность принимать взвешенные решения снижается. Что на самом деле меняется, так это наш самоконтроль - наша способность быть дисциплинированными, вдумчивыми и просчитывать последствия» .

Вывод: в нерабочее время отдыхайте, полностью отдалитесь от работы, заряжайтесь приятными впечатлениями.

« Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколько кто-то потратил времени на то, чтобычто-то сделать? Единственное, что имеет значение, - как быстро и качественно это было сделано» .

Суть работы - поток

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

Как его достичь? За состоянием потока стоит внутренняя дисциплина,

« Не должно быть ни одного движения впустую» .

Скрам и счастье

В конце каждого спринта участники устраивают ретроспективное собрание, на котором рассказывают о своих работах и перемещают рассмотренные задачи в колонку « Сделано» , а потом обсуждают, что хорошо, а что можно улучшить. Они находят основную помеху и думают, как ее устранить в следующем спринте. Это и есть решение проблемы непрерывного совершенствования.

« Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее» .

Элементы скрам

Спринты

Как уже отмечалось выше, в начале спринта и для обеспечения открытости и наглядности, нужно завести специальную доску и поделить ее на три колонки: « Бэклог» ; « В работе» ; « Сделано» . Перед каждым спринтом члены команды наклеивают в колонку « Бэклог» стикеры с задачами, которые, по их мнению, они могут выполнить за спринт. В течение спринта, любой член команды, взявшись за задачу, переклеивает стикер из раздела « Бэклог» в колонку« В работе» . После выполнения задачи - в колонку « Сделано» . Таким образом, каждый видит, над чем сейчас работают другие участники.

Изображение с сайта nyaski.ru

Однако есть важное замечание - « ничто не переносится в колонку „ Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом» .

« Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „ блокируются“ . Никто не имеет права их менять или вносить добавления » . Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.

Ежедневные собрания

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

Делайте до конца

« Израсходованы ресурсы, силы, время, деньги, но полностью функционирующий продукт не получен» .

Планирование в Scrum

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи « в собаках» . Эта проблема - такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, « Такса - единица; дог - тринадцать; лабрадор стал пятеркой, а бульдог - тройкой » .

Автор также предлагает использовать интересную методику покер планирования. Ее суть - каждому участнику процесса планирования дается колода карт с числами Фибоначчи - 1, 2, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. « Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными » .

Требования - это истории

« Представьте, что вы составляете „ пожелание пользователя Amazon.com“ . Пробный вариант выглядит так: „ Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“ .Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин : Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать. Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину. Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать. Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание » .

Как планировать спринт

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

После этого команда дружно произносит: « Вперед!» - и принимается за работу

« Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише» .

Открытость во всем

Скрам предполагает прозрачность всех действий и процессов.

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

« Секретность - яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды» .

Расстановка приоритетов

Вы выдвигаете на первый план то, что вы можете предложить. Тогда возникает риск сделать никому ненужный продукт;
Вы ориентируетесь на рынок. Тогда вас могут опередить или уничтожить конкуренты;
Ваше главное стремление - большие продажи. Тогда вы рискуете выпустить на рынок посредственный продукт.

Бэклог

« Смысл составления бэклога представляет создание максимально полного перечисления требований, предъявляемых к функциям продукта. На самом деле никто и не собирается выполнять подряд каждый пункт, но такой документ, содержащий все, что в принципе могло бы быть включено в концепцию проекта, всегда должен находиться под рукой. Некоторые требования отбираются в первую очередь» .

Как правильно расставить приоритеты? « Для этого нужно выяснить, какие пункты списка:

имеют самое большое значение для хода работ над проектом;
важнее всего для заказчика или будущего потребителя;
принесут максимальный доход;
проще всего осуществить » .

Владелец продукта

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

Минимизация рисков в скраме

« Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное? »

Вам не нужно тратить огромные средства перед тем, как понять, что-то не работает.

Как внедрить Scrum прямо сейчас

Джефф Сазерленд советует начать со сбора команды и составления бэклога. Нужно составить концепцию своего продукта и начать дробить его на задания. Не обязательно все требования сразу вносить в бэклог - можно выделить на это неделю. « Пока члены вашей команды проводят ежедневные собрания на ходу и первые спринты, вы сможете за это время составить довольно объемный бэклог, чтобы было чем занять команду на несколько спринтов вперед. Не забывайте почаще в него заглядывать, потому что команда начнет ускорять темп и будет выполнять больший объем работ, чем вы планировали в самом начале» .

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

О нас

Мы рассказываем о ключевых идеях из лучших книг жанра нон-фикшн. В нашей библиотеке более сотни бестселлеров, в том числе и тех, которые еще не изданы на русском.

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

«Цинизм является ответной реакцией нашего сознания на чувство отчаяния ».
Джефф Сазерленд

Насколько сильна альтернатива PM?

Действуя как топ-менеджер и проект-менеджер, я столкнулся с понятием Scrum как некой экзотической альтернативой классическому project management. Захотелось разобраться, в чем идеологические и технологические особенности данного подхода, и в чем, собственно, революция метода? Прочел несколько монографий. Честно скажу, после первого знакомства особой глубины не разглядел. Методология Скрам показалась несколько ангажированной и неконкретной.

При втором, более обстоятельном, рассмотрении метода Скрам, стали осознаваться черты, которые, на мой взгляд, все-таки заслуживают пристального внимания деловым сообществом. Представляется даже, что метод этот интересен не только для коммерческо-производственной сферы, но и для иных институтов нашего общества. Метод применим при проектировании моделей образования, НИОКР, государственного и муниципального строительства. Однако, как для любого нового, важно:

исключить абсолютизацию и рецептурную безупречность рассматриваемой технологии;
осознавать, что метод Скрам идеологически сырой и может просто «не лечь на нашу почву» с ее укладами и традициями;
видеть конфликтогенные точки, которые несет в себе данный метод;
понимать, что метод Скрам требует прозрачной идеологии государства и бизнеса относительно «правил игры» с персоналом, участвующим в развитии.

Являются ли современная парадигма управления проектами, международные и национальные стандарты (ANSI PMbok Guide, PM ICB IPMA, НТК) продуктом, который используют потребители: государство, его институты, бизнес? Да, конечно. Какие проблемные зоны существуют в современной проектной практике, основанной на рабочей методологии? Их несколько, но основных две: невыполнение проектных сроков и превышение бюджета проекта.

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

Данное свойство проектов особенно остро проявляется в областях, требующих инновационного подхода. Метод Скрам (Scrum) способен существенно смягчить названные проблемы. В начале 2000-х годов он явился результатом труда двух новаторов Д. Сазерленда и К. Швабера (США). В своей разработке авторы метода использовали элементы теории Х. Такеучи и И. Нонака, а также идеи системы компании Тoyota (Тайити Оно). И как революционный метод управления проектами модель Скрам уже получила признание в западных странах, причем на сегодняшний день практика его применения не ограничена только бизнесом.

Терминология метода

Авторы метода небезосновательно подвергли критике классическую модель календарного планирования проектов, применяемую уже около 100 лет на основе подхода Г. Гантта. Действительно, ничего нельзя противопоставить утверждению, что наглядная диаграмма Ганта, по существу является одноразовой в использовании. Мало того, что работа над ней занимает массу времени, практически сразу после начала проектных работ каскадная модель в большинстве случаев оказывается бесполезной.

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

Владелец продукта. Эта фигура несет ответственность за то, чтобы командная работа дала результат, который приносит компании прибыль (выгоды). Он должен прекрасно разбираться в сути продукта, в возможностях команды и в приоритетах рынка.
Скрам-мастер. Метафорически это очень интересная роль. «Лидер-слуга», «капитан команды», «тренер-коуч». Его главная задача – вести команду по пути непрерывного совершенствования, устраняя препятствия и причины помех.
Доска Скрам. Обычная офисная доска, разделенная на части: «бэклог», «в работу», «в работе», «на рассмотрение», «сделано!». По ней перемещаются наклеиваемые стикеры с заданиями.
Собрание Скрам. Итоговое собрание по завершении спринта.
Спринт. Временной промежуток от 1 до 4 недель, устанавливающий рабочий ритм деятельности команды Скрам по созданию новой функциональности.
Совещания на ходу или ежедневный Scrum. Короткие собрания команды проекта для ответа на вопросы скрам-мастера о результатах, планах на день и текущих препятствиях.
Бэклог (баклог). Список текущих требований-заданий к созданию функциональности продукта проекта.
Диаграмма выгорания задач. Диаграмма, показывающая количество сделанной и оставшейся работы в рамках поставленной задачи.
Последовательность Фибоначчи. Математическая закономерность, свойственная природе нашей Вселенной, при которой действует особый порядок чисел. Настоящая последовательность хорошо применима для альтернативной оценки продолжительности выполнения работ проекта, благодаря использованию так называемого «покера планирования». Ниже представлена визуальная модель числовой последовательности.
Сюхари (Shu Ha Ri). Сюхари – одна из концепций японских боевых практик (например, айкидо), которая вошла в число принципов метода Скрам как метафора возможности поэтапного (итерационного) достижения совершенства команды проекта.
OODA. Принцип метода Скрам по циклической реализации: наблюдать, ориентироваться, решать, действовать.

Модель последовательности Фибоначчи

Базовая модель метода Скрам. Источник: Асхат Уразбаев. Краткий обзор методологии Скрам

Краткое описание процесса

Методология Скрам как бы погружает ткань реализации проектной задачи в достаточно жесткий ритм циклических спринтов. В отличие от стандартной проектной деятельности, в методике исходным посылом для планирования являются не задания (хотя задача проекта не отменяется), а истории и факты, которые помогают понять ценности и потребности пользователя, клиента проектного продукта. Необходимо понять побудительные мотивы, которые вызывают его потребность в продукте.

В классике проектной деятельности подобная работа выполняется на этапе разработки устава проекта, но там она значительно более формальна. Здесь же формируются некие пользовательские истории, лаконичные и удобные для последующей фрагментации. Обратите внимание, при традиционной декомпозиции проектных задач происходит их предельное закрепощение в форму сухого языка однозначности. В методе Скрам, напротив, происходит раскрепощение – для того чтобы истории создали ценностный образ проектного продукта.

Проектная реализация с использованием процессов Scrum состоит из четырех крупных блоков.

Заполнение ролей команды Скрам.
Формирование артефактов Скрам.
Реализация активности.
Воспроизводство цикла Скрам.

Визуальная модель процесса метода Скрам

Состав ролей в методе Скрам прост: владелец продукта, скрам-мастер и команда. В этом же порядке и производится выбор людей на указанные роли. Наиболее близок к классической роли проект-менеджера владелец продукта, он отвечает за формирование и регулярное изменение бэклога продукта. После формирования бэклога команда проекта приступает к планированию предстоящего спринта. При этом активно используется «покер планирования» как инструмент более объективный и взвешенный, основанный на дельфийском методе и последовательности Фибоначчи. Таким образом формируется локальный бэклог на предстоящий цикл нового спринта.

Под артефактами Scrum в методе понимаются: бэклоги продукта и спринта, продукт проекта с новой функциональностью. Каждый спринт своей целью имеет создание новой функциональности продукта, пусть незначительного продвижения, но которое станет очевидным и может быть предъявлено заказчику проекта и другим заинтересованным сторонам. Во внутренней среде цикла спринта команда действует автономно, сопровождаемая «совещаниями на бегу» и перемещениями стикеров на доске Скрам. Пример внешнего вида доски показан ниже.

Пример доски Скрам

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

Комментарии по заполнению ролей

Одной из монографий, с которыми мне удалось познакомиться, явилась книга Д. Сазерленда, в которой Скрам презентуется не иначе как революционный метод управления проектами. Труд изобилует массой примеров из личного опыта автора, успешных проектных решений и громких имен. Эмоциональная окраска аргументации действует впечатляюще. В целом, традиционный для северо-американской методологической школы подход. Несмотря на немного запутанную логику, разобраться в методе проектирования нетрудно. Хорошее подспорье имеется в Приложении. Первые три шага технологии вполне резонно посвящены ролям в команде Scrum.

Шаг 1 алгоритма методологии Скрам

При ближайшем рассмотрении выводы-метафоры, приводимые к каждому разделу методики, оказались весьма действенными. Далее мои комментарии к разделам алгоритма будут построены по принципу поиска положительных моментов, выгодно отличающих Scrum от традиционной проектной методологии. Затем я намерен сформулировать вопросы, которые вызывают у меня сомнение или требуют разрешения для российских условий проектной практики. Среди положительных моментов на первом шаге метода я усмотрел:

семантически грамотное трансформирование роли проект-менеджера во владельца продукта, с позиции NLP точно программирующее лидера на результат проектной задачи;
ранжирование списка заданий (бэклога) проекта по ценностям (для клиента) и рискам;
гибкость в принятии изменения ценности продукта для заказчика проекта;
балльная оценка заданий и возможность замены проектных задач в ходе перераспределения приоритетов и остановки спринта.

Шаг 2 алгоритма методологии Скрам

Наиболее ценный методологический посыл шага 2, на мой взгляд, – «обвинять глупо». «Золотой стандарт» численности команды Скрам также принимается без возражений. Для определенного типа культуры команды проекта, например, адхократической или, в другой классификации, партиципативной, я вполне согласен с принципом автономности команды Скрам. Все остальные тезисы шага 2 универсальны и идентичны классическому проектному подходу.

Шаг 3 алгоритма методологии Скрам

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

Если «лидер – не босс», а скрам-мастер – «играющий тренер», тогда кто управляет командой Скрам? Самоуправление, на мой взгляд, не укладывается в концепцию проектного управления.
Возникает вопрос мотивации владельца продукта проекта, скрам-мастера и команды Скрам. В методике описан принцип открытости информации, включая доступа к финансовым данным проекта. Идея неплохая, но, учитывая Макиавеллевскую позицию, присутствующую во многих российских компаниях, у такой возможности среди руководителей, наверное, окажется много противников.

Вопрос формирования артефактов

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

Главная из них состоит в том, что данный список требований Скрам не рассматривается как что-то разово найденное и незыблемое. Бэклог продукта подвергается динамическому переосмыслению каждый раз после окончания спринта. И это весьма ценно, на мой взгляд. Могу сказать из собственной практики, что такого механизма не хватает в классической модели проектного управления.

Шаг 4 алгоритма методологии Скрам

Пятый шаг алгоритма Scrum не менее интересен. Совершенно не хочется погружаться в мистические аспекты чисел. Но у нас с вами есть рядовая прагматическая задача: наилучшим образом составить прогноз продолжительности выполнения работ проекта, используя самую объективную экспертную оценку. К сожалению, «гадание на кофейной гуще» по проставлению часов в MS Project – нет ничего более тоскливого и изнурительного даже с привлечением знающих экспертов. Могу с уверенностью заявить, что лучшего метода, чем «покер планирования» я в проектной практике не встречал. Метод широко известен, поэтому заострять на нем внимание не будем. Замечу лишь, что сочетание метода Дельфи и последовательности Фибоначчи дает поразительные результаты.

Пример пасьянса метода «Покера планирования»

Причин для того, чтобы рассматривать метод Скрам не как тюнинг современной доктрины PM, а как поистине революционный метод управления проектами несколько. Одна из них – это отношение к описанию работы по выполнению проектного задания с позиции историй, что противоположно процессуальному подходу Д. Чампи и М. Хаммера. Люди действительно мыслят образами. С одной стороны, трудно согласиться с тем, что можно не бояться потерять однозначность трактовки результата работы. С другой стороны, если отвлечься от задачного давления и взглянуть на вопрос с позиции подлинной ориентации на клиента проекта, «мягкие» истории могут дать больше для получения нужных результатов заданий.

Шаг 5 алгоритма методологии Скрам

Рассматривая шаги 5 и 6, механизмы расчета динамики производительности, бэклога спринта, сроков окончания проекта и возможности ускорения, не вызывают сомнений. Все достаточно очевидно. Затруднения в понимании возникают относительно одного вопроса: как по окончании каждого спринта добиваться наглядного приращения функциональности продукта? Касаемо проектов разработки программных продуктов такое вполне возможно. А как быть, например, при реализации проекта внедрения системы бюджетирования по методу Скрам, где много этапов подготовительной работы, на которых видимого прироста функциональности не происходит? Представляется, что в данную часть метода требуется дополнительное погружение.

Шаг 6 алгоритма методологии Скрам

Вопросы активных действий в ходе процесса

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

Шаг 7 алгоритма методологии Скрам

Одной из явных находок метода Скрам я считаю технику ежедневных совещаний на ходу. Весьма лаконичное и действенное средство взаимодействия и мотивации команды проекта внутри спринта. Великий спортсмен XX века Мохаммед Али придавал огромное значение регулярному ритуалу для успеха в любом деле. Ежедневное совещание Скрам призвано быть тем мощным регулярным ритуалом, которое подпитывает консолидацию команды на короткий рывок. Коучинговая поддержка, единое территориальное пространство, отсутствие деления по «чинам и званиям» – все это работает на то, чтобы команда Скрам действовала с ускорением проектной реализации.

Шаг 8 алгоритма методологии Скрам

На шаге 9 алгоритма метода Скрам проявляется то, что беспокоит и снова возвращает к формулировке заданий на спринт. Долгие годы мне приходилось воспитывать в себе убежденность в том, что задачный контекст проектного управления предполагает однозначность формулировки результата в понимании «достигнуто – не достигнуто». При этом не имеет значения, какой результат рассматривается: задачи верхнего уровня или декомпозированной. В любом случае постановщик проектной задачи и ответственный ресурс должны быть лишены возможности манипулировать неконкретностью формулировки.

Шаг 9 алгоритма методологии Скрам

Цикл спринта завершается десятым шагом, на котором производится коллегиальный ретроспективный анализ законченного спринта. Вновь включается коучинговый режим взаимодействия с командой Скрам в ходе оценки хода работы над заданиями, поиска улучшений. Для российской ментальности всегда присущи оценочные суждения с негативным окрасом неудачных результатов и срывов. При этом всегда должен быть обозначен «стрелочник» – член команды проекта, по чьей вине возникли потери. Тем ценнее представляются принципы примата системной ошибки над действиями участников процесса Скрам как субъектов проектной активности и отказа от персонификации вины.

Шаг 10 алгоритма методологии Скрам

Скрам как код антицинизма

Мне импонирует представленная в подзаголовке метафора. Она принадлежит Джеффу Сазерленду, и в ней чувствуется глубокое переживание цинизма как значительного порока современного бизнеса. В целом позиция автора метода Скрам, безусловно, искренняя. Это подкупает. И, в принципе, совсем неплохо, что Сазерленд вводит в управленческий контекст компонент счастья. Подобное делается так по-американски. Вместе с тем, хотелось бы разобраться, почему слово «счастье», и все, что с ним связано в рассматриваемой революционной проектной доктрине, вызывает внутренний дискомфорт. Только ли это субъективно-личностное восприятие, или это некоторый общий культурологический взгляд на предлагаемый подход?

Мы с вами, скорее всего, помним, что происходило в России в конце 90-х – начале 2000-х годов. В страну буквально хлынули «новоявленные нуворишы» со всех уголков мира, и в основном из США, вещающие «правду» о личной и корпоративной успешности. Надо честно сказать, что подобные «откровения» не прошли бесследно, многие бизнесмены взяли на вооружение ключевые аспекты привезенных с Запада теорий управления. Я специально не называю тренинговые курсы, авторские теории и именитые школы. Кто с ними сталкивался, поймут.

70 лет Советской власти сильно изменили внутреннюю культуру людей, но генетический код российского человека не был утрачен окончательно, поскольку формировался столетиями. Тем не менее, когда открылись широчайшие возможности коммуникаций и деловых отношений, у бизнесменов и управленцев естественные фильтры оказались сорваны. И многие идеи оказались принятыми как аксиомы, при этом принципы элементарной мудрости применены не были. Это издержки междувременья, которое сейчас завершается.

Происходит быстрое отрезвление и на уровне государства, и на уровне деловых людей. И они начинают понимать, что некоторые привносимые решения, способы ведения бизнеса, построения отношений с персоналом не просто полезны, они служили враждебным и разрушающим целям, приводящим к ломке нашей национальной культуры, в том числе культуре хозяйствования. Я приведу один единственный пример противопоставления двух идеологем: «Разделяй и властвуй!» и «Купеческое слово дороже договора!».

Вот это отрезвление и является причиной очень острожного отношения к навязыванию ресурса счастья как средства управления. В российской традиции с его многовековой общинностью, православными и исламскими корнями «счастье» относится к высокодуховным, добродетельным категориям. Оно не может не рассматриваться комплексно с позиции морально-нравственного аспекта, с точки зрения психологического состояния, с ракурсов интеллектуального осмысления, физического и душевного подъема.

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

Самая известная книга, посвящённая теме, в русском переводе известна под названием «Scrum. Революционный метод управления проектами», что содержит определение, которое нередко вызывает критику. В оригинале подзаголовок другой: «Искусство делать в два раза больше работы в два раза быстрее». Здесь Scrum не называется методом, и речь не идёт об управлении проектами. Однако и такой вариант трактовки в более широком контексте тоже оправдан. Особенно если рассматривается не узкая сфера разработки программного обеспечения (ПО), а подход, лежащий в основе фреймворка, который легко распространяется почти на любой вид коллективной деятельности.

Scrum: трудности перевода

Scrum (по-русски произносится «скрам») – термин, который в регби означает фигуру, создаваемую игроками в процессе игры, а в бизнесе придумывался авторами Джеффом Сазерлендом (Jeff Sutherland) и Кеном Швабером (Ken Schwaber) как каркас эффективного процесса разработки ПО. В официальном описании Scrum нет указаний к действию в любой ситуации, и некоторые вопросы остаются без ответов (например, здесь указывается необходимость оценки отводимого на процесс рабочего времени, но не определяется вид оценки). Поэтому говорить о Scrum как об исчерпывающей методологии в классическом понимании слова нужно с осторожностью.

Сами разработчики ПО чаще называют Scrum фреймворком, имея в виду одновременно и платформу, которая определяет структуру какой-либо программной системы, и своего рода организационную форму, позволяющую структурировать содержание процесса. Вот в этом втором значении «формы-модели для структурирования содержания коллективной деятельности» Scrum стал применяться в других отраслях коммерческого и некоммерческого типов. Там же, наполнившись своим содержанием, структура управления получила звание методологии.

Универсальная схема Scrum

Управление продуктом в Scrum складывается из нескольких универсальных для каждого контекста шагов.

Выбирается «Владелец продукта» – человек, который становится связующим звеном между рынком (заказчиком продукта или конечным потребителем) и командой исполнителей. Этот человек отвечает за увеличение ценности продукта и со старта видит общий замысел.
Собирается команда исполнителей, компетентность которой должна сочетаться с умением согласованно работать.
Определяется Scrum-мастер. Здесь мастер – это администратор, следящий за ходом работы в команде, но не командующий, а помогающий в обучении, обеспечивающий плановое проведение собраний и т. д.
Создаётся список требований к цели и продукту с расстановкой пунктов по приоритету. Этот список меняется по ходу развития проекта.
Участники команды оценивают каждый пункт списка, решая сколько временных и материальных ресурсов потребуется для реализации задачи.
Владелец продукта, мастер и участники команды проводят собрание, где в совместном обсуждении планируется спринт – короткий (не больше месяца в практике разработчиков ПО) этап, на который планируется решение определённой части задач. В некоторых контекстах такой этап называют итерацией. Предполагается, что в течение каждого спринта-итерации команда нарабатывает определённое количество баллов, которое в следующем спринте желательно увеличить, чтобы продемонстрировать рост производительности.
Для информирования всех участников процесса создаётся информационная доска, заполняемая стикерами, с разделением на то, что нужно сделать, что находится в работе, и что сделано. По мере выполнения задач, стикера перемещаются из одной колонки в другую.
Короткие общие собрания проводятся ежедневно. На них озвучиваются препятствия на пути, определяется уже сделанное для пользы проекта и запланированное.
Каждый спринт заканчивается детальным обзором результатов работы и, что не менее важно, обсуждением характеристик процесса в прошедшем спринте. Если можно что-то улучшить, то обговариваются направленные на оптимизацию нововведения, которые будут внедрены в следующем спринте.

Для того чтобы такая схема была жизнеспособной, методология управления Scrum должна складываться из ряда составляющих:

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

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

Философская основа Scrum

Управление продуктом в Scrum на идеологическом уровне – это следование определённому образу жизни и образу деятельности. Автор книги о методе Scrum увлекался японскими боевыми искусствами и это увлечение отразилось на отношении к своей работе, которая перестала быть просто зарабатыванием денег. Работа в стиле Scrum (как и айкидо) – это способ постоянного совершенствования через практику стремящихся к единству тела и разума.

Идеологические основы Scrum позднее были более чётко выражены в манифесте Agile. В нём были перечислены 4 ценности и 12 принципов, которым призывали следовать авторы манифеста. На первое место в системе ценностей ставились:

люди и их взаимодействие,
работающий продукт,
живое сотрудничество с заказчиком,
готовность менять и меняться.

Эти ценности были не противопоставлены, но определены как более важные по отношению к формальному соблюдению процессуального шаблона и выбору инструментов, соблюдению бюрократической процедуры, следованию первоначальному плану.

Предполагалось, что если практика на каждом этапе вносит свои коррективы, и это делает продукт лучше и ценнее, а потребителей – счастливее, то эта практика лучше жёсткого планирования. Подход Agile объединил в одно семейство модели, в основе которых лежали сформулированные ценности. Частью такого семейства моделей был и остаётся Scrum.

Роли в Scrum

Scrum подход предполагает распределение трёх ролей между участниками проекта.

Product owner . Этого человека называют «владельцем продукта» поскольку он становится единственным, кто принимает окончательное решение (поэтому эта роль, как правило, не перепоручается группе лиц). Он же ведёт проект в целом и занимается увеличением ценности продукта для рынка (заказчика), которого представляет. Исполнитель этой роли должен поставить задачи команде на спринт, но не ставит задачи конкретному исполнителю. То есть, Product owner – руководит продуктом, а не командой.
Scrum Master . Роль мастера тоже не предполагает возможность постановки задач конкретному исполнителю, поскольку команда, следуя принципам подхода, должна проявлять себя как самоорганизующийся и самоуправляемый организм. Его роль в работе ближе к роли администратора:
Team . Scrum команда в такой модели кроссфункциональна и самоуправляема. Нет специального человека, который бы организовывал её работу. Применительно к сфере разработки ПО, команды, как правило, складываются из 5-9 человек (в среднем – семи) специалистов разного профиля (аналитиков, разработчиков, тестировщиков). Несмотря на разнообразие специалистов внутри команды, Team действует как единой целое, и результаты её деятельности тоже оцениваются как результат общей работы.

В других сферах бизнес-деятельности, перенявших модель Скрам, стараются сохранить этот количественных стандарт, поскольку большему коллективу сложно самоорганизоваться и функционировать эффективно. Недаром в знаменитой игре Что? Где? Когда? её автор, В. Ворошилов, придумывая правила, остановился на шестёрке знатоков, как на самой эффективной функциональной коллективной единице.

В случае масштабирования при решении очень трудоёмких многоплановых задач, число людей в команде Скрам всё равно стараются не увеличивать, а для работы организовывают систему из нескольких команд. Помимо прочего, это объясняется и «законом Брукса», согласно которому, если коллектив не успевает вовремя закончить проект, то добавление числа исполнителей задерживает проект ещё больше.

Характеристика этапов работы

Работа над проектом и распределение времени предполагает фазы планирования, спринтов и подведения итогов спринта.

В модели Скрам процессы и действия предполагают прозрачность. Чтобы все всё видели в режиме реального времени внедряется специфический инструментарий – доска с колонками, на которой перестановкой стикеров иллюстрируется процесс. В продвинутой версии список информационных панелей расширяется.

Список скрам-артефактов включает 4 инструмента:

Все этапы, процессы (ритуалы) и технология применения инструментов важны для жизнеспособности модели. Управление проектами Scrum даёт максимальный эффект при комплексном и системном внедрении всех составляющих.

мастер работает над созданием атмосферы доверия в коллективе, пока остальные решают свои задачи,
устраняет препятствия,
поднимает, формулирует и выносит на обсуждение скрытые противоречия,
становится связующим звеном между менеджером проекта и командой.

Возможно, будет полезно почитать: