Scrum методология




Содержание страницы

Разница Между Scrum и Agile Методологии: Что Выбрать?

Scrum vs Agile являются гибкими методологиями, которые используются в управлении IT-проектами. Давайте же разберемся, какие понятия за каждым из.

Scrum vs Agile являются гибкими методологиями, которые используются в управлении IT-проектами. Давайте же разберемся, какие понятия за каждым из них закреплены, какая между нами разница. Английская вресия статьи what is the difference between scrum and agile methodology.

Agile

Agile — философия основанная на ценностях и принципах, которые описаны в манифесте. Эта методология отличается гибкостью и полностью являются противоположностью тяжеловесной Waterfall. Agile имеет всего 4 ценности, суть которых заключается в следующем:

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

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

Scrum

Давайте же теперь подробно рассмотрим что есть в методологии Scrum. Под каждый проект, который будет идти по Scrum подбирается набор специалистов из разных областей (7-9 человек), к которой добавляются еще две роли: владелец продукта (PO) и Scrum-мастер. PO звено между командой и клиентом и оперирует Product Backlog-м, в котором Stories, Bugs, Task, расположенные по приоритету (highest, high, medium, low) и в целом наблюдает за ходом развития проекта. Scrum-мастер призван помогать организовать сам процесс разработки: назначает и проводит митинги, решает ежедневные проблемы, мотивирует команду и следит за тем, чтобы принципы Scrum соблюдались.

Первым и основным пунктом в процессах можно назвать то, что весь процесс делиться на равные промежутки времени – спринты, длительностью в среднем от 1 до 3 недель. Продолжительность итерации зависит от команды и сложности спринта. Перед началом спринта выносятся задачи на предстоящий спринт (Sprint Planning Meeting) на котором формируется backlog спринта, а по завершению спринта – анализируются результаты (Sprint Review). Спринты часто сравнивают между собой, с целью повышения эффективности работы (Retrospective).

Также во время спринта происходит еще один процесс — Daily Meeting, на котором команда обсуждает что сделала, что планирует делать и какие помехи могут их ожидать. Эффективность в Scrum измеряется временем за которое карточка из To do перешла в Done. Чем меньше тем лучше, если больше — то необходимо реагировать и принимать действия по оптимизации работы. Scrum хорошо подходит для управления самоорганизующейся команды разработчиков. Используя данную методологию воспитывается самостоятельность, ответственность. У каждого есть своя роль и свой пул работы.

Visual board

Для наглядности в гибких методологиях (Agile-фреймоврках) большую роль играют доски: настенные и онлайн. Оба типа дают возможность легко воспринимать информацию всем членам команды в целом, что крайне важно при отсутствии менеджера проекта который и вовсе не предусмотрен в данной философии). Существует несколько фреймворков, относящихся к классу Agile, которые помогают применить философию/теорию на практике. Фреймворк — набор правил, следование которым поможет настроить работу над проектом по принципам и ценностям Agile:

Они бывают разной степени детальности. Ранее мы писали разницу между Kanban vs Scrum. Если говорить про Kanban, у него есть всего 6 правил, а в Scrum описаны роли, процессы и артефакты. А вот что общего у них всех – это метрика, а именно рабочий продукт. Также все фреймворки подразумевают под собой итеративный процесс веб разработки, где завершение каждой итерации это обновление требований от Заказчика и их реализацию посредством самоорганизующейся команды, в состав которой входят back-end и front-end разработчики, тестировщики, дизайнеры, верстальщики и другие.

Agile vs Scrum

Как видите Agile и Scrum это два разных понятия которые объединяются одной целью, повышения продуктивности управления процессами. Agile — это набор ценностей. В методологию Scrum можно добавить больше гибкости используя Agile. Например, наша компания Merehead, в разработке использует методологию Kanban и Scrum/Agile. Мы видим большие преимущества Scrum методологии только с Agile принципами.

Scrum

Макар че подходът на Scrum е първоначално предложен за управление на проектите за разработване на продукти, той се фокусира с времето върху управлението на софтуерни проекти и може да бъде използван за да задвижва екипи за софтуерна поддръжка или като общ подход за проектов / програмен мениджмънт. Тази методология е променила възприятията за типичното управление на проекти, като ясно показва предимствата на гъвкавите пред „waterfall“ или неитеративните, негъвкави методологии.

Scrum процесът се състои от отделни итерации, наречени спринтове. Спринтовете могат да имат продължителност от една седмица до четири седмици. В края на всеки спринт, екипът разполага с работеща версия на продукта, която включва всички готови задачи от backlog-а.

SCRUM е разработен за тези компании, чиято верига на стойността (изобразяваща процеса от началото до края на продукта и всяка стъпка, на която се добавя стойност) прави дългосрочното планиране на продукта доста трудно. За разлика от типичния мениджмънт чрез контрол и командване, тук се набляга на обратната връзка и се дава повече власт в ръцете на хората, които извършват операциите по процесите.

Съдържание

Подходът е създаден през 1987 и името му произлиза от scrum, scrummage – „спорна топка“ в английски и по-точно идеята за играта ръгби в случая, и един холистичен подход, по идеята за рестартирането на играта след кратки прекъсвания за нарушения.

1. Ключови роли или самият SCRUM екип.

Product Owner / Собственик на продукта Собственикът на продукта е отговорното лице за това организацията да добавя стойност (към продукти и услуги) за клиентите. Той е гласът на клиента и прави всякакви неща свързани с него. Той общува с клиента, задава приоритети на задачите и вписва всичко в „product backlog”- а. В SCRUM екипа такава роля трябва да има само един човек. Ролята на продуктния собственик не се препоръчва да се смесва с тази на SCRUM ръководителя. От друга страна той може да бъде човек от екипа за разработка. Scrum Master / Scrum ръководител Ръководителя е отговорен да бъдат премахвани пречките при изпълнението на договорените в спринта задачи и да постигне желаните за спринта цели. Той не е лидер на екипа, а нещо като служещ на екипа лидер. Следи за изпълнение на правилата и за това нещата да се случват по концепциите на SCRUM. Ръководителят се грижи за това екипът да не бъде разсейван със странични фактори и за това всичко да е подчинено на целите на спринта. Development Team / Екип разработка Екипът, който създава продукта, върши „черната работа“ – анализира, прави архитектурата, пише код, тества го, извършва работа по техническа комуникация, документира и т.н. Състои се от 3 до 9 души, които имат различни и сходни умения по множеството работа. Той има задачата да доставя увеличен брой или подобрени парчета софтуер на края на всеки спринт. Тези парчета трябва да са по някакъв начин подходящи за изпращане или продажба. Така във всеки един момент проектът може да бъде спрян и продаден. Екипът за разработка се самоорганизира, дори и това да налага сътрудничество с отдел/организация за управление на проекти.

Product Owner, Scrum Master и Team образуват заедно т.нар. Scrum Team.

а) Stakeholders / Клиенти или Вендори

б) Managers /Мениджъри

Матрицата помага да се планират всички заинтересовани лица от проекта. По-конкретно се планира какви да бъдат те по време на всяка от фазите (при по-детайлния план – на всяка от дейностите) на проекта: Responsible, Accountable, Consultant, Informed и Facilitate.

Преди всеки спринт има среща за планиране на спринта. На нея се поставят измеримите цели за спринта и се идентифицират задачите, които ще бъдат свършени в неговите рамки. По време на всеки спринт екипът създава завършени парчета от даден продукт. Дейностите за всеки спринт се описват и взимат от „продуктовата опора“ или на английски „product backlog” (пример на фиг. 3). Често тези дейности са описани като характеристики, които продукта трябва да има и да бъдат постигнати за спринта. Т.е. product backlog е приоритизиран списък на изискванията. Какво от списъка да влезе в даден спринт се решава на планиращата среща преди спринта. Продуктовият собственик уведомява екипа кои части от списъка с изисквания иска да бъдат свършени на предстоящия спринт. Развойният екип преглежда, обсъжда, решава и записва в Sprint Backlog кои от тези изисквания и цели ще успее да изпълни на предстоящия спринт. Sprint Backlog е собственост на развойния екип. Целите, вписани в този документ, не трябва да бъдат променяни по време на спринта. За разработването се определя фиксирана продължителност, такава, че спринтът да свърши навреме. Изискванията, които не бъдат удовлетворени за спринта се изключват и връщат към product backlog. След като спринтът е изпълнен, екипът демонстрира как се използва софтуерът.

SCRUM позволява организирането на самоорганизиращи се екипи като стимулира всички членове на екипа да се намират на едно и също място и да си комуникират на живо.

Ключов принцип на SCRUM е това, че се приема още в самото начало на проекта, че изискванията няма как да са пълни и напълно разбрани. Т.е. очакват се нововъведения от клиента – промяна на желанията му. SCRUM се фокусира върху способността на екипа да доставя бързо и да е готов да отговори бързо на неочакваните промени. Това е положителна черта за SCRUM, защото резките промени не могат да бъдат добре оборени с традиционните отгатващ или планиращ методи.

Както в другите гъвкави методологии за управление на проекти, SCRUM може да се имплементира чрез различни видове инструменти. Най-много се използват спредшийтове (екселски таблици или еквивалента им в Google Docs). В тях се правят така наречените SCRUM „артефакти“ като sprint backlog-а. Други организации прилагат SCRUM с помощта на бели дъски, лепящи се листчета и хартиени документи.

Product Backlog Както е упоменато по-горе, това е приоритетно подреден списък с изисквания, редактируем от всеки, но отговорност на продуктния собственик. При приоритизирането последния взема предвид рискове, добавена стойност, разходи, зависимости, дата на предаване на клиента и т.н. Характеристиките се добавят в този документ следвайки форматът на история: „As a I want to so that “. Sprint Backlog Списък с работата, която развойният екип (собственик на документа) трябва да свърши. В нея по време на ежедневните SCRUM срещи се вписват идентифицирани задачи. Те обаче не се задават на никого конкретно. Програмистите сами си избират задачи от там спрямо приоритети. Често се използва дъска / таблица, в която се вписва статусът на задачите – „да бъде свършено“, „в процес на работа“, „свършено“.

Задачите се идентифицират като развойният екип си избира истории от product backlog-a. После той разбива тези истории. Пита се „можем ли да направим и това?“ и така докато екипът почувства, че е взел достатъчно работа за спринта.

Story Point Абстрактна величина, използвана за оценка на времето, необходимо за изпълнение на дадена задача. Scrum Poker Използва се за по-точна оценка на времето, което отнема реализирането на дадена задача. Всеки член на тима получава комплект карти с различни числа (използват се числата на Фибоначи, обикновени числа, степени на числото 2 и др.). Всяка конкретна задача се предлага за обсъждане в тима и след приключването на това обсъждане, всеки участник показва една карта с броя на Story Points, необходими според него за цялостното завършване на задачата. Ако всички са единодушни, това число се записва в backlog-а. При разногласия, участникът дал най-голямо число и участникът с най-малко излагат аргументите за своите решения пред тима и се пристъпва към ново гласуване. Процедурата се повтаря докато има различия. Increment Това е сумата от всички задачи свършени на спринтовете до даден момент. Накрая на спринта инкрементът трябва да е готов във форма годна за някаква употреба. Burndown chart Отразява текущия напредък по време на спринта. Графичен еквивалент на Scrum backlog-а и е достъпен за Product Owner-а. Актуализира се ежедневно, непосредствено след приключване на Daily Scrum. Backlog изчистване време за истории (Backlog grooming: storytime):

По време на спринта, екипът трябва да прекара време за доизясняване на sprint backlog-а. Преценява се съществуващият backlog, доизясняват се критериите за приемане за отделните клиентски задания, разбиват се големите истории на по-малки. — Срещите не трябва да са по-дълги от час. — Не се включва разбиване на заданията на отделни задачи. — Екипът има свободата да реши колко срещи са нужни за една седмица.

Най-често използваният метод е покер планиране.

По време на спринта, всеки ден се провеждат т.нар. правостоящи срещи (stand-up meetings). Тези срещи продължават от 5 до 15 минути и се провеждат ежедневно в определен час. На срещата всеки от екипа абсолютно неформално разказва за три неща:

  • какво е работил предишния ден,
  • какво планира за предстоящия ден
  • какви проблеми е срещнал, които му пречат да работи.

Главни атрибути на срещата са:

  • Срещата започва точно навреме.
  • Мястото и часът са едни и същи всеки ден.
  • Срещата трябва да се вмести точно в 15 минути.
  • Може всички, но главно говорят основните роли в екипа.

На срещата се обновява и backlog-ът като се отбелязва свършената работа.

Ако се идентифицират някакви проблеми, те се решават колективно. Важно е да се отбележи, че това не са срещи за отчет пред ръководството, а за синхронизация (самоорганизация) на екипа и разкриване на потенциални пречки в работата.

  • Ежедневни правостоящи срещи (Stand-up meetings)
  • Backlog: списък със задачите за текущия спринт и тяхното състояние
  • Самоорганизиращ се екип: екипът не следва предварително раздадени задачи, а всеки негов член се стреми да допринася за постигне целите на спринта – всеки ден всеки си взима задачи, за които отговаря
  • Работни срещи и обсъждания с клиента и с екипа след всеки спринт

Преглежда се и работата, която е била свършена, и тази която не е.

  • Представя се свършената работа на клиентите (показва се демо).
  • Несвършената работа няма как да бъде представена, но се описва.
  • Срещата трябва да се вмести в 4 часа.

Спринт Ретроспекция

  • Всички членове на екипа си припомнят и обсъждат миналия спринт.
  • Правят се продължителни подобрения по процесите.
  • Задават се 2 основни въпроса:
  • Какво мина добре по време на спринта?
  • Какво може да бъде подобрено за следващия спринт?
  • Срещата трябва да се вмести в 3 часа.

Все что нужно знать про Scrum

Что такое Scrum методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?

Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.

Методология Scrum является самой популярной среди всего гибкого в разработке и не только. Мне стало интересно разобраться, что это такое и в чем практическое применение этого инструмента. Представляю обзор на ваш суд.

Что такое Scrum

Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.

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

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

Как Scrum устроен на самом деле смотрите ниже.

Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

  • Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
  • Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

Скрам митинг – ежедневная планерка, летучка, где разбирается ход работы спринта. Что сделали, есть ли проблемы, что планируется сделать. Не более 15 минут на собрание. Все участники команды должны высказаться. Скрам-мастер следит за таймингом и выступлением каждого.

  • Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

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

Процессы

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

Почта, это прошлый век, подписывайтесь на наш telegram канал!

Пример Scrum

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

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

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

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

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

Стена работает тоже хорошо, так как на этапе создания вся команда увлечена и чувствует свой вклад в общее дело. Но после ее нужно перенести в подходящий инструмент.

Вернемся к уборке двора. Вот мы выбрали спринты с задачами и преступили к работе. Команда каждый день выполняет объем работ, а скрам-мастер организует 15 минутные планерки (скрам митинги), где обновляет статус задач спринта и выясняет трудности в работе, если они возникли.

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

После 2-х недельного спринта скрам-мастер и команда проводит демонстрацию функционала. В нашем примере, мы успели сделать форму регистрации и показываем ее владельцу продукта. Он смотрит и вносит корректировки, если требуется. После принятия работы переходим к следующему спринту.

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

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

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

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

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

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

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

Оценка историй пользователей внутри беклога

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

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами” стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

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

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

Далее с учетом приоритетов задачи набираются в спринты и начинается работа. По итогам завершенных спринтов становится понятно, сколько story point-ов приблизительно может выполнить команда. А в процессе разбора (ретроспективы) после могут найтись точки роста.

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

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

Завершим

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

Великолепный ролик от Николая Дроздова и Huawei. Обязательно смотреть!

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

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

Суть agile-подхода изложена в «манифесте», но для заказчика ее можно коротко сформулировать так:

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

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum — это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг «Scrum для проектных команд«. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog — это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

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

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

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

Роль Product Owner

  • формулирует требования
  • приоритезирует требования
  • корректирует приоритеты на каждом спринте
  • несет персональную ответственность за ценность требований для рынка/пользователей
  • отвечает за взаимодействие с рынком
  • только один человек

Product Owner — это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них «главного», который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

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

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет «администратор». Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи — это делает сама команда;
  • Мастер не заставляет людей делать работу — это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать — это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

  • кросс-функциональная
  • взаимозаменяемая
  • самоорганизующаяся
  • с фиксированным составом (в ходе спринта)
  • 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

  • какие требования являются приоритетными — это делает Product Owner.

На снимке ниже команда проекта проводит обязательный «ритуал» — Daily Meeting (см. ниже).

Команда проводит «ритуал» Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

  • выполняется всей командой перед началом спринта
  • команда выбирает требования из Product Backlog и формирует Sprint Backlog
  • если требуется учесть взаимосвязи между операциями, то это делается здесь
  • команда декомпозирует требования на задачи (tasks)
  • каждая задача проходит оценку в трудозатратах или универсальных единицах
  • во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

  • представление и пояснение Product Owner’ом списка требований
  • вопросы со стороны команды
  • /рекомендуется перерыв/
  • декомпозиция требований на задачи (tasks)
  • оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

  • проходит ежедневно и только в одно и то же время;
  • встреча проходит только стоя;
  • поэтому длительность встречи не более 15 минут;
  • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review — сдача спринта Product Owner

По завершению каждого спринта команда обязана провести демонстрацию полученного результат. Ценность этого ритуала я поясню отдельно.

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

  • команда зачитывает требования из Sprint Backlog
  • по каждому критерию приемки происходит демонстрация полученных результатов
  • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
  • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

  • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
  • какие проблемы мешают команде выполнять взятые на себя обязательства?
  • как улучшить взаимодействие с Product Owner’ом?
  • какие ошибки совершает команда и почему.

Решения должны быть записаны на отдельной доске. После всеобщего голосования решения принимаются к исполнению со следующего спринта. Scrum Master контролирует ход встречи и следит за её регламентом.
Ознакомьтесь со списком наших курсов по управлению проектами.

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

  1. Заказчик не может сформировать четкие требования к ПО;
  2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
  3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

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

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

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

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы — управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile — владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile — это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

Гибкая методология Scrum

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

Гибкие методологии

Начать стоит с самого происхождения Agile-методологий. Начало им положил «Манифест гибкой методологии разработки программного обеспечения» в 2001-м году. Agile — в переводе с английского «гибкий». Вот основные принципы Манифеста:

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

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

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

  • DSDM с начала 90-х,
  • FDD с 97-го,
  • Kanban ещё с 60-х годов, однако эта методология использовала лишь часть приёмов от гибких методик.

Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Впервые слово «Скрам» не в контексте регби (там этот термин обозначает позицию игроков, борющихся за мяч в плотном скоплении), а в контексте разработки использовали Хиротака Такеучи и Нонака Икуджир в статье в 1986-м году. Там учёные описывали новый гибкий геймификационный подход к разработке коммерческого продукта, позволяющий выполнять работу в быстрые сроки. Команда разработчиков сравнивалась с командой в регби: действует во время «Скрама», как единый организм, для достижения общей цели.

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

В этом же году создаётся Scrum Alliance. Его миссия: направлять лидеров, компании и людей в целом на создание правильной организации рабочего процесса — «Transform the World of Work». Альянс существует и сегодня и занимается внедрением методологии Scrum.

На чём базируется Scrum

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.

  • Работа над проектом состоит из спринтов (итераций), длина которых две–четыре недели. В течение спринта необходимо выполнить заданный заранее объём работ. Обычно это либо новая функциональность продукта, либо готовый продукт в целом, который в ходе следующих спринтов улучшается. Нельзя менять задачи в ходе спринта, спринт можно остановить только в исключительных ситуациях.
  • Численность команды: четыре–десять человек. Такое ограничение обеспечивает максимальную производительность и сводит к минимуму отвлечения от работы и разговоры. Команда должна содержать всех необходимых для создания продукта специалистов.
  • Задачи спринта излагаются в Product Backlog. Product Backlog составляется из пожеланий пользователей (user stories) — то, что заказчик или потребитель желает видеть в проекте.
  • Каждый спринт начинается с планирования — на нём обсуждается, какие задачи нужно будет выполнить, завершается ретроспективой — оценка эффективности команды. Каждый день проходят 15-минутные собрания — члены команды, обязательно стоя, обсуждают: что удалось сделать вчера, что нужно сделать сегодня и что может этому препятствовать.
  • Отсутствие многозадачности. Единовременно команда работает только над одной задачей.
  • Помимо команды разработчиков обязательно присутствуют ещё две роли. Scrum-мастер, который следит за соблюдением принципов Scrum и убирает препятствия для эффективной работы, и Product Owner. Он взаимодействует с заказчиком и передаёт его требования команде.
Доска и Диаграмма сгорания задач

Отдельно стоит поговорить о методах визуализации работы, используемых в Scrum и некоторых других Agile-методиках. Две главных из них: Burndown Chart и Desk.

Burndown Chart — Диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом. По ней легко отследить, насколько команда приблизилась к выполнению задачи. По горизонтали откладывается время: остаток дней до конца стрима. По вертикали — количество подзадач, человеко-часов или Story Points — единиц измерения работы. График Диаграммы сгорания стремится вниз, от первого дня к последнему, от максимального количества подзадач/человеко-часов к их отсутствию. Отдельным цветом изображается идеальный график — прямая: когда за каждый день выполняется одинаковый объём работы, что в итоге приводит к равномерной нагрузке и выполнению цели в срок. Плохим результатом на Диаграмме сгорания будет не только возвышение реального графика над идеальным. Если команда выполнила весь объём работ на несколько дней раньше, значит неправильно был определён размер итерации либо поставлена слишком маленькая или простая задача.

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

Два этих способа визуализации обязательны в Scrum. Burndown chart и Desk — статистика и мотивация для команды. Однако применять такие инструменты можно и без перехода к гибким методикам: они отлично покажут эффективность любого рабочего коллектива.

Ещё один популярный инструмент: метрика Velocity. На диаграмме за несколько спринтов сравниваются столбцы запланированных подзадач/Story points за стрим со столбцами выполненных. На основе этого определяется эффективность. Метод весьма спорный, так как слишком обобщает результаты, но может использоваться дополнительно.

Где применяется Scrum

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

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

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

Scrum и крупные компании

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

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

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

Оценка Scrum

Scrum существует уже достаточно долго и за это время приобрела много сторонников и немало противников.

Преимущества
  • Быстрое удовлетворение большинства требований заказчика или клиентов.
  • Высокая конкурентоспособность продукта за счёт его постоянной оптимизации.
  • Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками.
  • Готовый продукт производится в быстрые сроки.
  • Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика.
Недостатки
  • Не все проекты можно выполнять по такой методологии. Для госзаказов, к примеру, Scrum многие специалисты считают неприменимой.
  • Отсутствие фиксированных бюджета и срока (имеется ввиду не спринт, а в целом время, нужное для получения готового продукта) на выполнение также осложняет заключение юридических договоров.
  • Немотивированная или низкоквалифицированная команда не сможет работать эффективно. А далеко не все сотрудники отличаются самоорганизованностью. Это же может повысить затраты на подбор и отбор кадров.
  • С некомпетентностью можно столкнуться и при подборе специалистов на роль Scrum-мастера. Сейчас очень много людей, имеющих на руках сертификат о том, что они прошли обучение. При этом далеко не всегда эти люди действительно являются профессионалами и могут организовывать деятельность команды.

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

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

Обучение Scrum

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

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

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

2. «Софт за 30 дней» Джеффа Сазерленда.

Эта книга также написана Джеффом Сазерлендом совместно с Кеном Швабером — другим создателем Scrum. В книге описывается процесс быстрой разработки программного обеспечения на основе методики, а дополнение Scrum Guide описывает все роли, артефакты, процессы.

3. «Scrum и XP: заметки с передовой», Хенрик Книберг.

Автор делает выводы из использования методологий на практике. Поможет быстро войти в тему.

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

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

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