Что это? Scrum – это методология гибкой разработки, относящаяся к семейству Agile. В отличие от классического каскадного (последовательного) метода предлагает совершенно иную и более эффективную структуру работы над продуктом.
Как внедрить? Для начала необходимо понять, насколько это нужно именно вашей компании. Выбрать цели, собрать и обучить команду, разработать спринты. Очень важно подойти к вопросу не формально.
- Суть Scrum
- Отличия Scrum от Kanban и Agile
- Плюсы и минусы Scrum
- Обязательные принципы Scrum
- Артефакты методологии Scrum
- Роли в Scrum
- Как и зачем проводятся совещания в Scrum
- Пошаговое внедрение Scrum
- 4 ошибки, из-за которых Scrum не работает
- 5 лучших книг про Scrum для лучшего понимания
-
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.Бесплатно от Geekbrains
Суть Scrum
Scrum не сразу зародился как метод отладки бизнес-процессов. В 80-90-х годах 20 века происходило становление различных методологий ведения бизнеса. Однако, первыми особенности технологии Scrum описали вовсе не предприниматели, а программисты Джефф Сазерленд и Кен Швабер. Они заметили, что при разработке программного обеспечения прекрасно работает принцип командного решения задач по частям.
Как «схватка» в регби – после каждой остановки или ошибки возникает новая расстановка сил. Именно отсюда и был взят термин Scrum.
Впоследствии особенности Scrum-процессов успешно стали применяться в сфере организации бизнеса. Предпринимателей привлекает в Scrum то, что можно не делать акцент на узкой специализации сотрудников. Главное, правильно распределить роли в группе на разных этапах работы.
Упор делается на следование манифесту Agile. «Гибкий» подход к организации и управлению деятельностью позволяет достигать конечного результата с минимальными энергозатратами, но максимальной эффективностью.
Одним из основных принципов Scrum является ценность командной работы. Причем, ставка делается не только на действия работников компании. Клиент, в интересах которого решаются все поставленные задачи, принимает активное участие на всех этапах процесса. Понимание того, насколько каждый следующий шаг удовлетворяет заказчика, дает возможность сотрудникам компании добиться более точного результата при создании продукта.
Коммуникация между исполнителями и заказчиком дает возможность прийти к более точному результату, удовлетворяющему обе стороны. Ведь возможность создать качественный продукт основывается на правильном понимании целей и задач, поставленных заказчиком. А умение разработчиков корректировать план с каждой новой «схваткой» – одна из основных особенностей методологии Scrum.
Отличия Scrum от Kanban и Agile
Часто отмечается, что Agile это базовая платформа методики Scrum. Некоторые даже путают данные понятия. Но все становится на свои места, если представить, что Agile – это философия ведения бизнеса, а Scrum – конкретные методы, позволяющие постоянно совершенствовать способы разработки для улучшения качества конечного продукта.
Теперь рассмотрим, чем же отличаются, похожие на первый взгляд, методологии Scrum и Kanban? Обе берут начало из принципов «гибкой» системы управления бизнесом, но организация процессов строится по-разному. Kanban не терпит перераспределения задач сотрудников: нагрузка делится пропорционально-равномерно среди всех членов команды. Scrum делает ставку на четкий план каждого из этапов с возможным перераспределением ролей в целях эффективного решения задач.
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Скачивайте и используйте уже сегодня:
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка
Только проверенные нейросети с доступом из России и свободным использованием
ТОП-100 площадок для поиска работы от GeekBrains
Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽
Структурированный поэтапный подход методологии Scrum строится на спринтах – нескольких циклах в рамках одной бизнес-задачи, когда каждый следующий период планируется с учетом итогов предыдущего. Спринты ограничены по времени, в конце каждого цикла идет согласование результатов с заказчиком.
В ходе работы на основе Kanban-методологии новые задания сотрудникам могут даваться в любой момент в течение дня. Члены команды отмечают статус решения задач на досках, которые отражают движение процесса от постановки задачи к ее выполнению.
Плюсы и минусы Scrum
Почему так привлекателен Scrum? В первую очередь, его ценность состоит в вовлечении клиента в процесс создания продукта. На каждом этапе заказчик может внести любые коррективы и даже, осознав необходимость изменения продукта, озвучить новые требования к результату.
Scrum привлекателен не только для заказчиков. Владельцы малого бизнеса или руководители небольших организаций, благодаря принципам работы спринтов, могут не тратиться на привлечение в команду узких специалистов под каждую задачу.
Несмотря на всю простоту и привлекательность методологии Scrum, она обладает и рядом минусов. Правила скрам достаточно четкие и даже жесткие. Есть временные промежутки циклов, которые не должны нарушаться в процессе разработки продукта. Есть ориентир на самоорганизацию группы в процессе каждого нового этапа.
И если команда не «сыгранная», не умеющая грамотно перераспределять роли в зависимости от итогов предыдущего цикла, может произойти недопонимание ценности спринта в достижении бэклога продукта, особенно если он подвергается корректировкам со стороны клиента. Поэтому зачастую руководитель вынужден вложить дополнительные средства в обучение персонала методам Scrum прежде, чем начать эффективно их внедрять.
Можно сказать, что метод Scrum не слишком хорош для четко поставленных задач с конкретным видением конечного результата, когда можно выработать пошаговый план достижения цели и продумать возможность возникновения рисков, а значит и способы реагирования на них.
В Scrum-процессе каждый спринт, это своего рода риск, когда в итоге может сформироваться новое видение задачи. Поэтому заказчик формально не может ожидать поэтапной реализации его идеи, а значит и доказать, что на каком-то шаге работы компании произошло отклонение от плана.
Обязательные принципы Scrum
Главная задача любой работы как личной, так и командной – своевременное достижение поставленной цели. И Scrum – не исключение. Для того чтобы результат действий команды оказался продуктивным, качественным и удовлетворяющим клиента, методологи скрам разработали несколько важных принципов.
- Работа короткими циклами (спринтами)
Важно не загадывать наперед, а планировать действия в рамках одного спринта. В конце каждого цикла рождается готовый продукт.
Скачать файл- Гибкость. «Проверять и адаптироваться»
Итог каждого спринта доступен для опробования заказчиком. По итогам теста клиент может высказать пожелания по изменению конечного продукта. Команда же, в свою очередь, корректирует план следующего цикла, опираясь на видение бэклога продукта заказчиком.
- Участие заказчика и пользователей в создании продукта
Плотный коннект с владельцем продукта дает возможность чуткого и четкого реагирования на результаты тестирования. Ведь после каждого спринта пусть еще «сырой», но уже пригодный для применения продукт доступен для проверки пользователями и заказчиком. Результаты тестирования дают более точное представление о необходимых поправках в плане реализации задач, поставленных клиентом.
- Взаимодействие команды
Слаженная и «сыгранная» команда – это залог успеха методологии Scrum. Несколько сотрудников, объединяясь для решения общих задач, должны уметь грамотно планировать действия всех и каждого. Сравнить Scrum-команду можно с единым организмом, где функционал каждого органа продуман во благо качественной жизнедеятельности и быстрой адаптации к изменениям внешних обстоятельств.
Артефакты методологии Scrum
Артефакт в общем понимании – уникальный продукт, сгенерированный в процессе деятельности человека или группы людей. По сути, любые действия по разработке нового продукта в итоге должны увенчаться появлением очередного артефакта. Так в Scrum можно отметить три уникальных результата: backlog-продукта, sprint-backlog и инкремент, основанный на пожеланиях клиента.
- Бэклог-продукта — список пожеланий к конечному результату, который формирует заказчик на начальной стадии работы
В процессе реализации задач по разработке продукта в перечень требований можно и должно вносить коррективы, который будут учитываться при составлении плана спринта. Клиент привносит свое видение в любой из пунктов бэклога продуктов, а команда постоянно опирается на список задач и, учитывая изменения, находит новые способы решения для улучшения качества итогового продукта.
Читайте также!
- Бэклог-спринта — план спринта, отвечающий на основные вопросы: зачем, что и как делать в рамках данного цикла задач для реализации бэклога-продукта
В начале каждого спринта проводится собрание, где проводится планирование действий команды на данном временном отрезке. После собрания у каждого должно возникнуть четкое понимание действий для достижения бэклога-продукта в рамках текущего спринта. Иногда Sprint backlog может претерпевать изменения, которые способствуют лучшему достижению целей.
- Инкремент (или цель спринта) — итог деятельности всей команды – продукт, готовый для тестирования
В конце каждого спринта должен появиться хотя бы один инкремент, приближающий команду и владельца продукта к итоговому видению результатов. Однако, команда может по окончанию спринта предъявить и неполную версию инкремента, если задание объемное и требует для разработки более длительного времени, чем отведено на спринт.
В таком случае для полного понимания качества продукта необходимо закончить работу над большей частью продукта. Каждый следующий инкремент является продолжением и улучшенной версией предыдущего. И, как было упомянуто выше, требует разного времени на реализацию до стадии готовности. Следует все же отметить, что затягивать со временем при разработке ПО не следует, так как это уменьшает его шансы на успех.
Способность команды постоянно улучшать приемы видения способов создания артефактов и методов их реализации в жизнь является одним из важных навыков работы процессов Scrum. Поэтому руководителю следует обратить внимание на отработку слаженности действий команды и воспитание скорости ее отклика на возможные изменения критериев.
Роли в Scrum
По практике, команда Scrum должна состоять из 7 (плюс-минус 2) человек. Меньший состав вряд ли справится с грамотным распределением ролей в условиях каждого спринта. А большее количество разработчиков усложнит взаимодействие внутри команды.
Организация бизнес-процесса по Scrum-методу предусматривает обязательное наличие трех ролей:
Владелец продукта
Владелец — человек, который формирует список требований к конечной версии продукта. Это может быть как сам заказчик, так и его официальный представитель. Объем его полномочий гораздо больше, чем у обычного менеджера проекта и он является непосредственной частью команды.
на курсы от GeekBrains до 01 декабря
Владелец обязан предоставить план, отражающий экономическую эффективность бэклога-продукта. Перечень задач составляется им на основе оценки их приоритетности и веса. Также в его обязанности входит контроль за отслеживанием окупаемости вложений и организация продуктивного взаимодействия команды с заказчиком.
Приблизительный функционал владельца:
- разработка журнала продукта;
- оценка соответствия бэклога-продукта ожиданиям заказчика;
- расстановка приоритетов и оценка функциональности задач в рамках каждого спринта;
- формирование четкого списка требований, согласованных с заказчиком;
- ответственность за эффективность конечного продукта;
- управление тестированием инкремента и грамотная оценка его итогов.
Скрам-мастер
Скрам-мастер – это координатор действий членов команды. Оценивает состояние участников группы, точность фокусировки на задачах и степень достижения цели спринта на разных этапах. Этот специалист не просто наблюдает за деятельностью коллектива со стороны и раздает инструкции к действию, он является полноценным активным членом команды. Одновременно контролирует процесс взаимодействия членов группы и принимает непосредственное участие в разработке продукта.
Scrum-мастер помогает команде обратить внимание на приоритетные задачи реализации фреймворка: наблюдает за уровнем удовлетворенности всех членов группы, использует мотиваторы работоспособности и следит за сроками выполнения графика спринта.
Приблизительный функционал скрам-мастера:
- создание благоприятной обстановки;
- отлаживание продуктивного взаимодействия членов группы;
- разрешение возможных противоречий и устранение преград;
- помощь команде в преодолении отвлекающих факторов;
- отслеживание соблюдения принципов Scrum.
Разработчики
Все члены команды являются разработчиками и отвечают за качество конечного продукта. Самоорганизующаяся группа разработчиков вправе перераспределять функции ее членов с целью реализации задач проекта. В начале каждого спринта намечается список целей и время их выполнения.
Приблизительный функционал команды разработчиков:
- первоначальное планирование задач спринтов, согласно списку требований заказчика;
- работа над соответствием конечного результата бэклогу продукта;
- самостоятельная организация своих действий ради достижения целей спринта;
- демонстрация итогов работы заказчику.
Как и зачем проводятся совещания в Scrum
Следует помнить, что Scrum строится на чередовании последовательных мероприятий, которые помогают правильно организовать работу группы на протяжении всего проекта. Оттачивать слаженность действий членов команды помогают совещания (митинги). Существуют стандартные типы совещаний команды Scrum. Однако, точное следование регламенту митингов рекомендуется только на начальном этапе отладки взаимодействия в новой команде.
В процессе нескольких первых спринтов проводятся все собрания согласно рекомендуемому времени и структуре собрания. Далее, команда вырабатывает свое видение ежедневных коммуникаций, придерживаясь принципов скрам.
Проведем краткий анализ видов собраний команды Scrum.
Организация бэклога
Это командная встреча с владельцем продукта, на которой он доводит до сведения участников список приоритетных задач по реализации проекта. Первоначальная презентация бэклога=продукта, согласованного с пожеланиями заказчика, может преображаться от спринта к спринту из-за изменений на рынке либо в следствие корректив после тестирования продукта пользователем. За поддержание приоритетов требований и актуальность списка задач отвечает владелец продукта.
Для этого он постоянно держит руку на пульсе и чутко реагирует на изменения пожеланий заказчика, своевременно осведомляя о них команду Scrum.
Планирование спринта
Sprint Planning Meeting – самое длительное собрание команды Scrum, на котором присутствуют все разработчики, скрам-мастер и владелец продукта.
Целью этого собрания является разработка стратегии спринта. Идет обсуждение с владельцем, какие пункты бэклога-продукта будут реализовываться в текущем спринте, разработчики, согласно уровню своей производительности, объективно оценивают возможность выполнения поставленных в плане задач, команда определяет критерии тестирования и возможную скорость изготовления артефакта, а скрам-мастер помогает распределить функционал между участниками проекта.
По итогу собрания вырабатывается четкая стратегия на спринт с учетом пожеланий заказчика, расстановки приоритетов от владельца продукта и согласованности действий разработчиков. Все это способствует реализации основной задачи Scrum-проекта – повышению ценности продукта в рамках текущего цикла.
Спринт
Спринт – это непрерывная коммуникация членов команды в течение определенного срока. По практике средняя оптимальная длительность спринта – две недели. В это время каждый участник вносит свой вклад в общее дело, поэтому, если при планировании структуры спринта команда считает нужным сократить или увеличить время, то это не возбраняется.
Но у каждой команды есть право распределять время самостоятельно, на то она и самоуправляемая. Чтобы у скрам-команды выработался опыт определения оптимальной длительности спринта под ту или иную задачу, необходимо разработать от начала до конца несколько продуктов. Тогда можно будет проанализировать ошибки и взять на вооружение достоинства предыдущих проектов в части эффективного определения времени спринта.
Ежедневное Scrum-совещание
Такое собрание команда может запланировать на любое время дня, главное, чтоб оно проводилось каждый день в одном и том же месте и длилось не слишком долго. Достаточно 15 минут, поэтому собрание проводится стоя. У каждого участника к моменту собрания готов небольшой отчет по итогам проделанной за вчерашний день работы и сформулированы задачи на сегодня. Это краткие ответы на основные вопросы:
- Чего я добился вчера?
- Чего планирую добиться сегодня?
- Что мне мешает?
Выслушав друг друга, члены команды сообща могут определить степень готовности продукта на данном этапе и способы достижения наилучших результатов. Важно не превратить Daily-митинг в нудное зачитывание вчерашнего распорядка дня из блокнотов участников. Выступление одного члена команды должно длиться не более 2-х минут.
Обмен информацией об итогах прошедшего дня и планами на сегодня проводится для осведомления группы об актуальном состоянии процесса разработки. Получив заряд мотивации, команда приступает к текущим делам.
Обзор итогов спринта
По окончании срока спринта Scrum-команда предъявляет владельцу продукта демоверсию конечного продукта – инкремент. Для более точной и всеобъемлющей оценки итогов работы цикла можно пригласить на собрание разработчиков из других команд, руководителя проектов и конечных пользователей продукта.
Отзывы всех участников обзора помогают подытожить, были ли решены задачи спринта в полном объеме, надо ли что-то изменить в бэклоге и получилось ли выпустить полноценный тестируемый продукт на данном этапе. Эта обратная связь дает возможность более точно определить, что именно нужно потребителю.
Обзор итогов спринта – это не мероприятие строгой отчетности, а конструктивная встреча участников проекта. Длится такое собрание не более 4-х часов для месячного спринта. В итоге владелец проекта не просто принимает работу команды, но и получает более точное представление о формировании следующего бэклога.
Ретроспектива спринта
После обзора итогов спринта назначается очередной митинг – ретроспектива спринта. Это встреча команды, на которой обсуждается эффективность предыдущего этапа работы. Анализируются все минусы и плюсы продукта, выявленные на обзоре. Каждый может высказаться, почему не получилось в прошлый раз и предложить свои методы преодоления трудностей разработки.
Пошаговое внедрение Scrum
Сегодня способ организации процесса Scrum является достаточно популярным и действенным. Эффективность методов скрам высоко оценивается специалистами по организации бизнес-процессов. Остается один вопрос: как внедрить эту методологию в компанию правильно.
Разберем по шагам путь перехода на командную разработку продуктов.
Шаг 1: Собрать команду
Главный и достаточно сложный этап – сбор эффективной команды, которая быстро «сыграется» и в итоге выработает свою рабочую схему взаимодействий при разработке новых продуктов.
Шаг 2: Назначить владельца продукта
Найти того, кто станет связующим звеном команды с конечными пользователями тоже не так-то просто. Главное, чтобы владелец продукта мог чутко реагировать на необходимость исправить бэклог-продукта и своевременно вносил нужные изменения, не прерывая, а лишь поправляя ход процессов.
Шаг 3: Выбрать Scrum-мастера
Грамотный скрам-мастер – залог половины успеха разработки качественного продукта. Функции тренера играющей команды можно доверить лишь специалисту, знающему методологию Scrum не на словах, а на деле. Опытному мастеру, который видел методы скрам в работе, легче создавать благоприятную и продуктивную атмосферу в команде.
Шаг 4: Создать список требований к продукту
Зная и понимая цели и требования клиента, легче добиться заданного результата. На этом этапе необходимо выяснить все особенности конечного продукта и составить ТЗ, на которое можно будет опираться при его разработке.
Шаг 5: Спланировать спринт
Все техническое задание владельца продукта не подвергается планированию в полном объеме. Работа делится на циклы и каждый последующий спринт планируется, опираясь на результаты предыдущего.
Шаг 6: Постоянно анализировать и оценивать результат
В Scrum важно уметь подводить итоги и гибко реагировать на необходимость изменения бэклога-продукта. Только полностью готовый продукт или часть продукта (в зависимости от плана) можно считать положительно завершенным спринтом и переходить к планированию следующего цикла.
Эти шесть простых шагов помогут компании перейти на Scrum и повысить продуктивность действий команды с меньшими временными и энергетическими затратами. Неужели при внедрении данной методологии не возникает никаких сложностей? Ответ очевиден: как и в любом процессе, ошибки могут присутствовать и здесь. Чтобы избежать нежелательных последствий и выпустить качественный продукт методами скрам, необходимо опираться на опыт реальных разработчиков.
4 ошибки, из-за которых Scrum не работает
Почему такой популярный Agile-фреймворк может дать осечку? Причин может быть несколько.
- Методы Scrum истолковываются неверно или применяются не в полном объеме
Разработчики Scrum отмечали, что при попытке следовать методам Scrum, важно опираться на эмпирический опыт. Существует гайд по внедрению Scrum, в котором подробно расписываются принципы самоорганизации команды. Необходимо не просто проводить по графику митинг за митингом, а сделать ставку на отработку слаженности в команде при отсутствии в ней номинального руководителя.
- Неверная или неполноценная мотивация команды
Не каждый человек способен на самостоятельную мотивацию и самоорганизацию труда. Таких людей не более 20% от всех работающих. Однако, это не обозначает, что команду Scrum без них не собрать. Многое зависит и от условий, которые будут предложены группе, работающей по принципам Scrum. Если превратить процесс разработки в своего рода игру, вовлеченность в работу может повыситься, особенно при наличии положительных результатов в виде обратной связи.
Эффективность действий сподвигает команду к переходу на более продуктивный темп для получения лучших результатов. Так же важно «сбивать» команду из сотрудников, способных к смене ролей в ходе процесса, предупреждая выгорание члена самоорганизованной группы от наскучившего повторяющегося раз от раза функционала.
- Неверный выбор продукта для применения Scrum
Существуют продукты, которые делаются по определенному шаблону с заранее известным планом от «А» до «Я». Здесь принцип работы над разработкой продукта лучше не менять и оставить «водопадным». Также не соответствуют принципам Scrum проект с фиксированными сроками и фиксированными ценами, ведь согласно философии Agil в любой момент в процесс работы могут быть внесены правки, поэтому весь путь создания продукта никогда не расписывается по шагам.
Зачастую первоначальное видение продукта разительно отличается от конечного результата. Не работает Scrum и в ситуациях, когда заказчик не желает активно участвовать в разработке продукта.
В случаях, когда методология Scrum не применима, можно обратиться к другим способам организации бизнес-проектов.
- Неграмотное распределение зон ответственности
Рассмотрим примеры:
- Бывает, что разработку продукта Scrum команде заказал не один заказчик, а несколько. Представления о конечном результате в процессе разработки могут не совпадать и группа «единомышленников» превращается в несогласованную хаотичную силу. Они начинают по очереди высказывать каждый свои требования и мешают команде сосредоточиться на результате. О чем свидетельствует такая картина? Можно с уверенностью сказать, что в данном случае в команде некомпетентный владелец продукта, который не способен скоординировать действия заказчиков, приведя их к единому знаменателю, и довести до команды Scrum четко сформулированные условия, основанные на общих пожеланиях клиентов.
- Другой пример относится к ошибкам Scrum-мастера. Этот специалист должен быть ответственным за медиацию команды, призван налаживать внутреннюю коммуникацию в группе разработчиков, грамотно направляя каждого к созидательной миссии. А он всего лишь сосредотачивается на формальном выполнении своих обязанностей: ведет собрания и контролирует действия разработчиков. Иногда, не умея смотивировать членов команды, сам выполняет их функции, идя по пути наименьшего сопротивления. Ни о каком эффективном построении процесса в данном случае речь не идет.
- Иногда проблемы возникают и с разработчиками. По сути, если в команде уже есть владелец продукта и Scrum-мастер, все остальные члены группы – это равноправные разработчики, от чьей слаженной работы зависит результат проекта. Еще разработчика можно назвать developer, что в более распространенном вольном переводе обозначает: «тот, чьей работой является создание новых идей и продуктов». Так вот, если разработчики теряют равноправие, разбиваясь на меньшие команды в составе группы, то команда перестает быть эффективной и функциональной. Такая ошибка так же понимается, как неверное распределение ролей в Scrum-группе.
5 лучших книг про Scrum для лучшего понимания
- Джефф Сазерленд. «Scrum. революционный метод управления проектами»
Автор методологии Scrum сформировал и изложил на 280-ти страницах свое описание принципов работы Scrum. Вышла книга в далеком 1995 году и с тех пор была неоднократно переиздана на разных языках. Это издание будет полезно для начинающих знакомство с методами скрам.
- Кеннет С. Рубин. «Основы Scrum»
Тем, кто уже специализируется на работе по методологии Scrum и применяет ее именно для разработки программного обеспечения, советуем обратить внимание на руководство данного автора. Исторически методология Scrum зародилась на ниве работы с продуктами ПО. Эта книга даст более углубленное понимание технологии Scrum применительно к данной сфере разработок.
Автор собрал словарь терминов, а для лучшего понимания материала текст издания подкреплен примерами и иллюстрациями. Привлекательно, что все примеры учебника обоснованы личным опытом автора, поэтому советы так легко применить на практике.
- Кен Швабер. «Скрам»
Еще один из основателей методологии Scrum поделился своим практическим и теоретическим видением плюсов и минусов работы технологии Scrum. В книге он рассказывает:
- как наладить обратную связь с заказчиком и помочь ему конкретнее и четче формулировать требования к продукту.
- как упростить руководство проектом, опираясь на принципы самоорганизации в команде;
- как реализовывать сложные проекты в условиях частого изменения требований.
- Хенрик Книберг. «Scrum и XP: заметки с передовой»
Автор имел возможность экспериментировать с различными Agile-практиками, о чем и рассказывает в своей книге, используя понятные наглядные примеры. Однажды, желая написать лишь ряд небольших заметок о своем опыте применения Scrum-методологии, он продолжил изложение знаний и в конце концов издал полноценное практическое пособие по разработке ПО.
Читайте также!
- Майк Кон. «Scrum: гибкая разработка ПО»
Эта книга не будет лишней для тех, кто решил в сравнении познать опыт разных экспертов Agile-технологий по разработке продуктов программного обеспечения. Авторское понимание процессов Scrum подкреплено результатами собственных экспериментов. Знания и опыт, описанные автором книги, можно также применить для внедрения гибкого метода Scrum в работу любой организации.