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

Ваня Звягин

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

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

Команда

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

На практике маленькие команды работают быстрее, чем большие. Джефф пишет, что идеальная команда — 7 человек.

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

Время

Время — важный ресурс, поэтому им нужно дорожить. Работу следует разбивать на равные отрезки времени. Промежуток времени может быть 1. 4 недели. Если вирус «Скрам» уже в вашей команде, называйте эти промежутки «спринтами».

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

Джефф говорит, что нужно выкинуть все визитки в компании. Назначенные должности — ярлыки статуса. Лучше гордитесь тем, что сделали. Как к вам будут обращаться — не важно.

Проводите ежедневные собрания по 15 минут, не больше. Каждому в команде нужно ответить на четыре вопроса:

  1. Что ты делал вчера, чтобы помочь команде?
  2. Что ты будешь делать сегодня?
  3. Что мешает работе?
  4. Успеваешь ли ты завершить работы до конца спринта?

Потери

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

Проекты Потр. время Потери
один 100% 0%
два 40% 20%
три 20% 40%
четыре 10% 60%
пять 5% 75%

Джефф рассказывает, что работать надо меньше. Выходные и отпуск никто не отменял. Работая много, мы устаём и продуктивность труда падает. Привет Коле Товеровскому →

Ставьте реальные цели, которые можно измерить. Недостижимые цели вызывают депрессию и рушат продуктивность команды.

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

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

Не стоит строить планы на 10 лет вперёд. Планируйте ровно на столько, чтобы команда была занята. Планировать нужно с помощью карт с числами Фибоначчи. Это одна из самых быстрых и надёжных оценок времени. Числа: 1, 2, 3, 5, 8, 13.

Работа — сценарий. Сценарий должен:

  • Быть завершённым, осуществимым на практике, не зависимым от обстоятельств.
  • Быть открыт для обсуждения.
  • Приносить пользу.
  • Быть удобен для оценки объёма работ.
  • Быть кратким и конкретным.
  • Пройти проверку на практике.

Каждая команда должна точно знать, сколько работы может сделать за один «спринт». А также, должна устранять всё, что тормозит её работу.

Счастье

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

  1. Оцените свою роль в компании по шкале 1. 5.
  2. Оцените компанию в целом по той же шкале.
  3. Почему вы так считаете.
  4. Назовите вещь, которая может сделать вас счастливее в следующем спринте.

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

Таблица «скрам-команды» должна состоять из пяти колонок: в очереди, приняты, в работе, на рассмотрении, сделано!

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

К чёрту тайны в команде! Все должны знать всё. Запутывание следов нужно только тем, кто ищет собственную выгоду.

Приоритеты

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

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

Расскажу немного про принцип «ООДА». Суть: вы должны видеть всю стратегическую картину, действовать тактически и быстро.

  • Наблюдать. Ясно видеть ситуацию по мере развития событий.
  • Ориентироваться. Это не только локация. Ещё это варианты развития ситуации.
  • Решать. На основе наблюдений.
  • Действовать. Говорит само за себя.

Выпускайте продукт вовремя. Намыливайте, смывайте, снова намыливайте. Всегда 20% функционала — 80% ценности продукта. Не упустите момент сдачи!

Внедрение

  1. Выберите владельца продукта внутри команды.
  2. Выберите команду 3. 9 человек.
  3. Создайте «бэклог». Его должен вести владелец продукта.
  4. Отдайте «бэклог» на уточнение и оценку команде. Команда использует числа Фибоначчи.
  5. Планируйте «спринты» в одну или две недели. Учитывайте количество баллов с прошлого «спринта». Наращивайте динамику производительности. Не добавляйте новые задания в действующий «спринт».
  6. Ведите доску задач.
  7. Проводите ежедневные собрания на ходу. Каждый в команде отвечает на три вопроса:
    • Что делал вчера?
    • Что будешь делать сегодня?
    • Какие препятствия встают на пути?
  8. Проводите обзоры спринта. Там команда показывает результаты.
  9. Проводите ретроспективные собрания. После сдачи спринта команда садится за стол и отвечает на вопросы:
    • Что прошло хорошо?
    • Что можно было сделать лучше?
    • Что можно сделать лучше в следующем спринте?
  10. Начинайте следующий спринт.

Есть у кого опыт внедрения «Скрам» в дизайн-команды?
Напишите в комментариях своё мнение, буду очень благодарен!

Почти все да, кроме нескольких моментов:

«Проводите ежедневные собрания по 15 минут, не больше. Каждому в команде нужно ответить на три вопроса:»
Тут, по опыту, я бы добавил четвертый вопрос «успеваю ли я завершить свои работы до конца спринта?». Если рабочего времени с спринте осталось на 15 часов, а работы на 40, очевидно, что что-то не будет сделано. Об этом надо говорить как можно раньше владельцу продукта (PO) и scrum master для того чтоб: изменить спринт, распределить задачи на других членов команды, у которых загрузка меньше.

«Если заметили ошибку, исправляйте её сразу, отложив все дела. Если править её позже, времени на это уйдёт намного больше.»
Категорически нет. Перед этим нужно это приоритизировать. Критическая ошибка или нет? Блокирует функционал или нет? Есть ли потеря данных? Как часто воспроизводится? Есть ли workaround? Баги часто сложно оценить и если команда займется фиксом бага (неоцененного), который в свою очередь не является критическим, но запорит весь спринт, то value (ценность) результата спринта будет минимальной.

«К чёрту тайны в команде! Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственную выгоду.»
Чем меньше тайн — тем лучше (иногда), но финансовые данные никто не обязан обсуждать/ рассказывать команде, если это частная компания. Если рассказать за сколько мы продаем работу разработчика и сколько ему платим по факту в месяц, где-то может начаться бунт 🙂 Нанятый работник это нанятый работник и кое-что знать ему не нужно, поэтому без фанатизма тут)

Ну а остальные вопросы мы обсудили в пятницу 😉 Главное понимать, что нужно не команду/ продукт под скрам подстраивать и наоборот. Главные моменты: планировать учитывая риски всей командой, работать короткими спринтами и давать полезный результат, держать руку на пульсе в течении спринта, стараться ускорять частотность релизов, анализировать сделанную работу и улучшать процесс

Джефф Сазерленд — Scrum. Революционный метод управления проектами

Джефф Сазерленд — Scrum. Революционный метод управления проектами краткое содержание

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

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

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

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

Deadline

SCRUM

The Art of Doing Twice the Work in Half the Time

SCRUM

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

Манн, Иванов и Фербер

Информация

от издательства

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

На русском языке публикуется впервые

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

Scrum. Революционный метод управления проектами / Джефф Сазерленд ; пер. с англ. М. Гескиной — М.: Манн, Иванов и Фербер, 2016.

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

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

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

© Jeff Sutherland and Scrum, Inc., 2014

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2016

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

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

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

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

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

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

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

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

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

президент Samolov Group

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

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

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

Книгу «Scrum. Революционный метод управления проектами» (Scrum: The Art of Doing Twice the Work in Half the Time) стоит почитать всем, кто хоть чем-то управляет и что-то организует. Обычно все думают, что скрам — это про разработку софта. На примерах из жизни Джефф Сазерленд (Jeff Sutherland) объясняет философию подхода и рассказывает, как применять его для самых разных задач — от ремонта в доме и организации свадьбы до обучения и ведения бизнеса.

О книге

Методология Scrum появилась 20 лет назад и со временем стала популярным подходом к производству софта. Мануал для работы по скрам несложно найти в Сети — казалось бы, зачем писать новую книгу? Сначала она кажется рекламной, потом пропагандистской (Сазерленд описывает много ситуаций, связанных с военной и политической активностью США, работой ФБР и т. д.). Потом может возникнуть ощущение, что книга начинает расползаться на разные темы, которые непонятно как относятся к скрам. Имеет смысл абстрагироваться от этих ощущений и читать дальше: чуть позже все это соберется в единую картину, и станет ясно, что почти 300 страниц историй и рассуждений нанизаны на нить методологии. Таким образом Сазерленд объясняет, что Scrum — это не искусственное построение: к появлению методологии вело много научных экспериментов и наблюдений, накопление опыта и тестирование производственных и управленческих ноу-хау.

Нельзя сказать, что Scrum — полностью изобретение Швабера и Сазерленда: они опирались на публикацию 1986 года ‘The New Product Development Game’ в «Гарвардском деловом обзоре». Хиротака Такэути и Икудзиро Нонака рассказали в ней о своих наблюдениях: лучшие результаты показывают небольшие команды разнопрофильных специалистов, которые руководствуются принципами игры в регби (там есть понятие Scrum, «схватка»). Но именно Швабер и Сазерленд взялись тестировать идею на практике, формировать подход и документировать процесс. Благодаря этому и появилась непосредственно методология, по которой сейчас могут работать все, а работают преимущественно программисты. Ну как так?

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

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

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

Почему вам обязательно нужно узнать, что такое Scrum

Scrum — это гибкое управление проектами, предсказуемые процессы создания продуктов, эффективная работа команд и коллективов. Не знать о Scrum становится неприличным сегодня и невозможным в будущем.

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

Scrum («скрам») — практическое воплощение Agile-принципов. Это подход, позволяющий, по словам его создателя Джеффа Сазерленда (Jeff Sutherland), делать в два раза больше за вдвое меньшее время.

Вы, вероятно, хотели бы знать больше об Agile и Scrum, чтобы быть в теме. Мир IT уже невозможно представить без Agile, и эта «зараза» стремительно распространяется на традиционные офлайновые бизнесы.

Чтобы быть в курсе, вы можете прочитать новую книгу Джеффа Сазерленда «Scrum. Революционный метод управления проектами». Это займёт несколько дней. Альтернативный способ быстрого чтения умных американских бизнес-книг — прочитать краткую выжимку, пересказ, саммари от нашего партнёра — компании Smart Reading. Это займёт полчаса, и вы обязательно усвоите все ключевые идеи без воды.

Scrum появился около 20 лет назад как эффективный метод увеличения продуктивности при разработке программного обеспечения. Завоевав популярность в Кремниевой долине, Scrum быстро получил признание в других отраслях бизнеса. Его создатели Кен Швабер (Ken Schwaber) и Джефф Сазерленд изучили передовой мировой опыт успешных компаний и пришли к выводу, что «водопадная» модель, по которой прежде строилась работа над IT-проектами, безнадёжно устарела. Она не отвечала ожиданиям клиентов, поскольку работа продвигалась медленно, в строгом соответствии с долгосрочным планом, и часто на выходе получался не тот продукт, который на самом деле был нужен.

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

Познакомьтесь с ключевыми принципами Scrum, и, возможно, тема заинтересует вас настолько, что не прочитать книжку Сазерленда вы уже не сможете.

Люди важнее процессов

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

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

Продукт важнее документации

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

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

Сотрудничество с клиентом важнее идеально составленного контракта

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

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

Способность меняться важнее следования планам

Говорят, самое страшное — всю жизнь делать продукт, которым в итоге никто не воспользовался. Представьте, вы три года разрабатывали что-то, что потом не полетело, так как оказалось невостребованным на рынке. Виной тому грандиозные планы, составленные на старте, и точное следование им. Что, если план на три года был ошибочен? Вы потратите кучу денег и останетесь у разбитого корыта.

Как же быть? По Scrum, вы должны иметь большую цель, но идти к ней итеративно, не пытаясь предугадать каждый свой шаг в далёком будущем. Небольшими итерациями по 2–4 недели двигайтесь к цели, оборачивайтесь назад, делайте ретроспективу, оценивайте сделанное, отказывайтесь от результата последней итерации, если он не приближает вас к цели. Таким образом можно избежать глупых больших провалов. Итеративность — это научный подход. Надежды на правильность больших планов — это, скорее, похоже на религию.

Должности и титулы не важны — важно то, что вы делаете

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

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

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

Итак, узнать досконально всё о Scrum можно из книги его создателя Джеффа Сазерленда. В качестве альтернативы можно за 20–30 минут прочитать саммари этой книги в электронной библиотеке Smart Reading.

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

Подводные камни Scrum-проектов

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

Что такое Scrum?

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

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

Как это делается?

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

Разобравшись с Product Backlog`ом, можно приступать к планированию деятельности. Для того чтобы сделать процесс работы гибким, его планируют не полностью, а по частям, то есть разбивают на спринты – этапы работы продолжительностью в одну или несколько недель. При этом команда выбирает для одного спринта наиболее актуальные задачи из Product Backlog`а, оценивая, сколько из них она успеет выполнить за отведенный промежуток времени.

Каждый рабочий день в течение спринта начинается с короткой, в идеале 15-минутной, планерки (ежедневный Scrum). Участники команды рассказывают, что они сделали вчера, что планируют выполнить сегодня, какие сложности встают у них на пути. Таким образом, исполнители постоянно отслеживают и оценивают прогресс реализации задач спринта и попутно решают возникающие проблемы. В этом, если брать классический Scrum, им помогает Sprint Backlog – доска задач, наглядно показывающая процесс выполнения спринта.

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

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

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

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

«На самом деле в проекте по разработке заказного программного обеспечения не бывает ситуаций с нефиксированным бюджетом, – добавляет генеральный директор First Line Software Александр Поздняков. – Возможно, исполнитель не знает точно, какой бюджет клиент заложил на проект, но заказчик – знает всегда. Что касается договоров, то с моей точки зрения, нет особой сложности в том, чтобы описать юридическим языком работу между контрагентами по Scrum. Компании, работающие в ИТ-сервисной сфере, давно разработали вариант контракта, который это предусматривает».

Scrum не работает

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

«Действительно, при внедрении новой методологии могут возникнуть сложности. Это нормально, и здесь важно просто продолжать действовать, – считает Александр Поздняков. – Дело в том, что Scrum – это не просто методология. Это ещё и определённый образ мышления, который надо привить команде. Довольно часто происходит путаница: есть компании или группы людей, которые используют только часть практик и называют это Scrum. На самом деле это не Scrum – это просто часть практик. А когда у них не получается достичь ожидаемых результатов, разочарование зачастую «прилипает» к Scrum незаслуженно. Еще раз повторю: нельзя быть «немножко Scrum», нужно использовать эту методологию в целом».

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

Не получается создать команду

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

«Профессионалов всегда сложно найти, — говорит Александр Горник. – Проблема компетентной Scrum-команды решается только одним образом: необходимо параллельно внедрению современных процессов делать компанию более привлекательной для сотрудников и, соответственно, нанимать более сильный персонал. В методике Scrum для ИТ есть такая роль – scrum-мастер или agile-coach, ведущий разработчик. Хорошо, когда именно этот человек просматривает отклики по вакансии разработчиков и собеседует людей вместе с другими участниками команды. Решение о найме должно принимается коллегиально. Так происходит у нас в Mindbox и это помогает избежать трудностей адаптации к нашей системе работы. Вообще, при работе по Scrum у сотрудников появляется больше ответственности, больше автономии. Весь смысл внедрения таких методов сводится к отказу от начальников. Мы не хотим иметь в компании начальников, которые раздают задачи, решают, кто с кем должен работать и прочее. Мы отдаем полномочия как можно ниже, туда, где людям наиболее видна суть задачи».

«Люди иногда уходят в отпуск, иногда болеют. Команда должна быть готова к таким сложностям, – добавляет Александр Поздняков. – Именно в этом и есть главное отличие Scrum от других методик: команда мобилизуется для решения проблемы как единое целое и как единое целое несет ответственность за результат. К примеру, есть три вопроса, на которые каждый участник команды отвечает на ежедневном стендапе: «Что я сделал?», «Что я сделаю?», «Какие у меня проблемы?» Здесь часто забывают об одной маленькой, но важной детали – эти вопросы должны задаваться с позиции команды: «А что я сделал, чтобы у команды всё получилось?», «Какие, с моей точки зрения, проблемы у команды?», «И как я могу помочь их решить?». Это просто критически всё меняет. В Scrum думать нужно не о себе, а о команде – тогда все пойдет на лад».

Кстати, Scrum – это не аббревиатура. Сам термин обозначает горячую схватку вокруг мяча в регби. Более того, технология использует методы из самых разных, порой неожиданных, областей знаний, например, из айкидо или военных интеллектуальных разработок. Почитать об этом подробнее можно в книге создателя методики Джеффа Сазерленда «Scrum. Революционный метод управления проектами». А если вы собираетесь внедрить или повысить эффективность Scrum в своей компании, то рекомендуем своего рода инструкцию по применению «Scrum и XP: заметки с передовой» от шведского agile-консультанта Хенрика Книберга. Удачи!

Методология Scrum для управления проектами

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

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

За 20 лет существования Scrum помогла не только большинству разработчиков программного обеспечения, но и ФБР, автопроизводителям, фармацевтам и простым людям, планирующим свои дела.

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

Как работает Scrum

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

Выберите владельца продукта

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

Выберите команду

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

Выберите скрам-мастера

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

Создайте бэклог продукта

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

Уточните и оцените бэклог продукта

Крайне важно, чтобы участники группы, которые будут выполнять задания из бэклога, оценили, сколько усилий это потребует. Команда должна взглянуть на каждую задачу и определить, выполнима ли она в принципе. Достаточно ли информации, чтобы выполнить задачу? Достаточно ли она обозрима, чтобы ее можно было оценить? Есть ли общее понимание, каким стандартам и критериям она должна соответствовать, чтобы быть выполненной? Создается ли при этом действительная стоимость? Должна быть обеспечена возможность продемонстрировать результат выполнения каждой задачи. Не оценивайте задания бэклога в часах, поскольку люди плохо с этим справляются. Оценивайте в относительных размерах: «малый», «средний», «большой». Лучше использовать последовательность Фибоначчи и присваивать каждой задаче количество баллов: 1, 2, 3, 5, 8, 13, 21.

Планирование спринта

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

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

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

Работа должна быть видимой

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

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

Ежедневное собрание на ходу, или ежедневный Scrum

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

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

  • Что ты делал вчера, чтобы помочь команде завершить спринт?
  • Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
  • Какие препятствия встают на пути команды?

Обзор спринта

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

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

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

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

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

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

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

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

Подведем итоги

Сомнение смерти подобно

Наблюдать, ориентироваться, решать, действовать. Определите, где вы находитесь, осознайте имеющиеся варианты, сделайте выбор и действуйте!

Искать ответы вокруг себя

Сложные адаптивные системы следуют нескольким простым правилам, ориентируясь на окружающую среду.

Великие коллективы

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

Не гадать

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

Сюхари

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

Scrum — современный метод управления проектами

Современные способы управления безнадежно устарели, а линейная модель и традиционное планирование просто не работают. В книге «Scrum — революционный метод управления проектами» Джефф Сазерленд рассказывает об идеях, которые помогли наладить рабочий процесс в Microsoft, Morning Star, Google, Amazon и ФБР.

Командная работа

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

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

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

Пакет «MUSTHAVE-2020» для digital-агентств и веб-студий

RUWARD анонсировал главный коммерческий пакет MUSTHAVE-2020 для digital-агентств и веб-студий на весь 2020 год.

В пакет включено сразу 7 различных крутых опций, сервисов и рекламных форматов в рейтингах Руварда на следующий год.

Команда моей мечты

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

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

Оптимальный размер рабочей группы

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

С чем это связано? Американский психолог Джордж Миллер уверял, что краткосрочная память среднестатистического человека может удерживать одновременно не более семи объектов. Позже исследование Нельсона Коуэна доказало: Миллер заблуждался. Число объектов, которые человек может удерживать в краткосрочной памяти, не семь, а четыре. Количество коммуникационных каналов существенно увеличивается с количеством людей, и наш мозг просто не в состоянии справиться с этим.

Инструменты Scrum

Спринты и собрания на ходу — два важнейших инструмента методики Scrum.

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

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

Как Scrum меняет мир

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

  • В 2008 году экономический кризис ударил по Исландии. В результате революции правительство, виновное в финансовом провале, было свергнуто. Новая власть создала новую конституцию за считанные месяцы, используя методику Scrum.
  • Фонд «Грамин» успешно пользуется этой методикой, чтобы помогать населению Уганды. В результате урожаи фермеров увеличиваются вдвое.
  • Учитель химии из маленького городка Алфен-ан-ден-Рейн рискнул пойти наперекор традиционному методу преподавания и применить в обучении методику Scrum. За один год успеваемость его учеников повысилась на 10 процентов.
  • С помощью Scrum ФБР удалось создать систему управления базами данных за 18 месяцев, не превышая бюджета. До этого было несколько попыток модернизировать управление информацией, на проекты тратилось огромное количество денег, но каждый из них проваливался раз за разом.
Ссылка на основную публикацию