scrum framework что это
Гибкая методология разработки Scrum, или как быть в потоке всем участникам проекта
Поток, что это? Это быть в моменте, здесь и сейчас, каждому участника проекта. Есть ты, рабочее пространство и 100% фокус. Рабочее пространство — это стены офиса или уголка в доме, если ты на удалёнке, твои коллеги очно, либо в мессенджерах, задачи, безумные идеи и яркие цели.
Мы в IT часто сталкиваемся или столкнёмся с тем, что надо запилить нечто такое, в короткие сроки, с учётом таких-то деталей и интеграции новшеств, не потеряв в скорости. В общем сделать так, чтобы всё было хорошо :). Вполне обычная задача, приступая к которой, засучиваешь рукава, хватаешь маркер, карандаши с ручками, собираешь или входишь в команду, проектируешь, визуализируешь, генерируешь идеи, варишь, варишь, варишь и идёшь стучать по клавишам, реализуя крутые вещи.
Scrum методология позволяет погрузить каждого, хоть немного ответственного, даже заинтересованного на малую долю участника, в процесс с головой. Каждый участник берёт на себя ответственность за задачу, невыполнение которой, подведёт в первую очередь всю команду и конечно самого себя. А это обидно, очень обидно.
Не будем сейчас расписывать мотивационную составляющую, в каждой компании свои методы, условия и плюшки. Мне больше импонирует человеческий фактор, прям от самой сути слова — человеческий. Это и компетенция, и опыт, и настроение, и желание, и общение и ещё десятки качеств, которые формируют человека, стоящего перед тобой.
В первую очередь, всегда говорил и говорю команде — мы делаем общее дело, все вместе. Так было 12 лет назад, когда занимался сопровождением продуктов, так было 9 лет назад, когда занимался системным и бизнес анализом и 7 лет назад, руководя производством, и вот уже на протяжении 4-х лет, руководя проектами. Лично для меня, нет должностных вертикалей, есть команда, которая на равных в своей компетенции, делает продукт. Такой подход стирает границы формальностей, бюрократии и самое главное, временных ожиданий. Любой участник имеет право голоса тогда, когда он считает нужным. И кстати, под словом команда, я имею в виду и заказчика, который является полноправным участником и входит в состав наших Scrum-команд.
Что такое гибкая методология разработки?
Гибкость в IT сейчас повсюду и философия Agile с набором ценностей, сформулированных в манифесте из 4-х ключевых идей и 12 принципов также, у всех на слуху, на виду и возможно в обойме вашего проекта, в котором вы участвуете. Мы полностью поддерживаем Agile в части взаимодействия людей внутри команд, топим за работающий продукт вместе с заказчиком, который как указал ранее, является частью команды и конечно же, мы 24/7 готовы к любым изменениям, абсолютно любым.
С философией определились, а за методологией или как правильно называют книги — фреймворком, далеко ходить не пришлось. Scrum почти идеально вписывался в наш проект. Почему почти, да потому что мы же говорим о гибкости и внедрять гибкую методологию, как оказалось, можно тоже гибко. Например, мы грешим взятием задач в уже запущенный спринт, да, ещё мы можем переносить не закрытые задачи в следующий спринт. Но это не мешает работать по Scrum методологии и успешно сдавать продукт.
Расскажу про адаптацию методологии в реалии разрабатываемого продукта. Да, возможно приверженцы и адепты Scrum до самых корней, будут немного удивлены описанному далее подходу, но ребят, мы же IT, а значит, нужно пробовать варианты, адаптировать под свои процессы и достигать успеха! Ведь конечная цель — это качественный и в срок, рабочий продукт! Что мы с командой и делаем.
Итак, Scrum методология/фреймворк, что мы взяли и как у нас есть
1. Product owner (PO) — Заказчик
В нашем случае это внешний заказчик, IT-технологи (в каждой команде 1-2 технолога), которые полностью участвуют в наших процессах разработки выставляя и транслируя требования/задачи своего бизнес-заказчика. Бизнес-заказчик, кстати, временами участвует в показах и грумингах команд, что очень полезно на стадии сбора первичных требований глобальных задач, фиксации промежуточных и конечных результатах.
2. Scrum master (SM) — Lead в команде + фасилитатор
3. Команда
Рекомендуемое методологией количество участников одной команды 5-9 человек. Состав наших команд от 6 до 12 человек. В сравнении с командой из 6 человек, проблем с увеличением времени митингов или каких-либо коммуникаций, в команде из 12 человек, не наблюдаем.
Команды делятся по функциональности продукта. В общей сложности у нас 7 команд, суммарной численностью 50+ человек в компетенциях: Аналитики, Разработчики разных направлений (Front, Back, Integration), Архитекторы, Тестировщики, Системные администраторы и Сопровожденцы.
Практически в каждой команде 100% автономность, покрывающая функциональность продукта. Но и тут есть адаптация Scrum методологии. Например, архитекторы участвуют во всех командах и точечно подключаются, когда зовут, для участия в митингах, грумингах и решении каких-либо задач. Точечное подключение касается команд администрирования и сопровождения. Также, участник команды в любой компетенции, может привлекаться к другим командам для решения задач, например, доработки модуля, который срочно нужно внедрить в предстоящий релиз. Такие привлечения согласовываются между SM команд, которые анализируют задачи спринтов и возможность отдачи компетенции, на срок, позволяющий максимально сохранить покрытие запланированного объёма задач, в рамках текущего спринта. Финальное решение переключения зависит от исполнителя компетенции, т. к. он берёт на себя ответственность, помимо закрытия задач своего спринта, закрыть дополнительно задачу спринта другой команды. Бывают ситуации, когда сами заказчики в командах, понимая важность рабочего модуля для проекта в целом, жертвуют компетенцией исполнителя/ей, перенося свои незавершённые задачи на следующий спринт. Но как показывает практика, все «жертвы» не напрасны. Мы получаем рабочий продукт в установленный релиз, клиенты довольны, мы довольны что клиенты довольны, ну, а взаимопомощь всегда хорошо, и кто знает, когда какой-то из функциональных команд, потребуется доп. помощь компетенции другой функциональной команды?
С ролями, надеюсь, всё понятно. Давайте рассмотрим предметно, что к чему.
Организация процесса
1. Boards — доски
Какое-то первичное понимание ведения досок у нас было. Мы знали, что можно брать стикеры, писать на них задачи и двигать бумажки по ячейкам, ровно так, как мы делали на Kanban доске. Kanban доска была классной, такой красивой, огромной и пробковой. У задач был свой жизненный цикл (ЖЦ) и до какого-то момента, стикеры помещались все. Но с наращиванием команды, оптимизации процессов разработки, прокачке компетенций, задач стали брать больше и больше. Как итог, десятки стикеров с задачами, которые попросту перестали умещаться на доске. И это глобальные задачи, детализация которых велась в Jira.
Scrum-методология тоже рекомендует стикеры, доску на которую их можно лепить, маркеры и стоящую вокруг доски, активно обсуждающую задачи, команду. Окай, сформировали пилотную команду и начали проводить данный обряд в митингах, грумингах и ретроспективах. Практически на каждом обряде очно присутствовал заказчик. Опыт неоценимый и очень результативный. Благодаря чему, команда сплотилась, выстроила чёткий вектор развития, прозрачно, объективно и с понятным (в Story Pointʼах) сроками.
ЖЦ скрам доски стандартный:
Параллельно физической доске, мы продолжали вести задачи в Jira, для удобства обмена информацией, историчности, оперативного поиска, обращения к вложениям и прочим благам цифровизации, а также заделом на будущее, для региональных и работающих удалённо участников будущих команд. Спустя какое-то время, стикеры, маркеры, флипчарты стали доставлять неудобства из-за объёма информации. Было принято решение, в той же Jira, сформировать Scrum доску. Это очень правильно решение, с него и надо начинать.
Позитивный и результативный успех пилотной команды, заложил фундамент на будущее. Разрабатываемый продукт у нас уже был разделён на функциональные блоки, которые вперемешку делали все участники команды в рамках своей компетенции и направлении задач.
Начали формировать команды, децентрализация по России сотрудников которых, составляет 45%. У каждой функциональной команды появилась своя доска в Jira, со своим SM, списком задач и сроками.
2. Коммуникации
Децентрализация команды, временами, ограничение возможности присутствия заказчика, а также необходимость в бизнес-заказчике, потребовало наладки VoIP коммуникации. Начали со Skype, но результат не отвечал нашим требованиям в части видеопотока, да и звука. Думаю, вы понимаете, о чём я, видя, как шевелят губами, роботом говорящие ребята. Это была проблема, т. к. большинство сотрудников заказчика, подключаются с мобильных устройств с плохим интернет-каналом.
В поисках решений, кто-то предложил Zoom клиент. Попробовали. Зашло. Аудио и видео потоки не прерывались, даже со слабым интернетом-каналом. Каждый участник команды, подключаясь на встречу, обязательно включает камеру, тем самым, частично компенсируя своё физическое отсутствие. Да и продуктивнее общаться online, видя собеседника и всю команду в целом.
SM команды, на каждом митинге шарит доску, вводя команду в единое инфополе.
Также, мы запустили Confluence, что позволило избавиться от тонны пересылаемых документов, с кучей разных версий, ожиданием пока кто-то почистит ящик, чтобы принять документ и прочими неудобствами. Confluence вывешен во вне и в моменте, все могут видеть единую версию документа, либо осуществлять правки в online, прям по ходу груминга например. Подключили плагин версионности публикуемых документов, с ним куда проще работать, особенно имея релизность продукта. Прям советую.
3. Backlog — список задач
Сформировать первичный бэклог труда нам не составило. После создания Scrum-доски в Jira, все незакрытые задачи публикуются в бэклоге. За несколько лет накопилось неплохое количество незакрытых задач, которые как ни кстати требовалось проштудировать и в целом понять, что актуально, что нет.
Оставив «жмых» из более чем сотни задач, стали распределять по командам, там-же, в бэклогe, путём создания новых спринтов с припиской «Backlog». Данные спринты никогда не берутся в работу, а служат только для хранения историй/задач для последующего взятия в спринт. Такой подход очень удобен тем, что все задачи на виду у всех участников множества команд. Бывают случаи, что кто-то цепляет взглядом какую-то интересную, по его мнению, задачу из другой команды, лезет чуть глубже и понимает, что она плотно коррелирует с тем, над чем он сейчас работает. Такие задачи переходят в команду интересующегося участника и как правило оперативно закрываются. Также, полная картинка бэклога мне даёт оперативный срез по объёмам производства и понимание динамики задач.
В основном задачи в бэклог добавляет SM, но каждый участник проекта может докидывать задачи в ходе рабочего процесса, уведомив SM. Например фичу надо допилить, для улучшения скорости загрузки, или не забыть поправить что-то не критичное, но мешающее внутреннему миру разработчика жить мягко и пушисто.
Как наполняется Backlog:
Выше упоминал о релизности продукта. Всю историю и будущее планирование выпуска релизов мы также, ведём в Jira. Количество и частота релизов с каждым годом увеличивается примерно в два раза. Все связи задач, историй, epicʼов и версий релизов, ведётся в бэклоге.
Релиз в Jirʼe декомпозируем следующим образом:
4. Оценка задач (подзадач)
Само собой, у всех нас была в голове одна оценка (ну ладно, две, вторая: сложно, не сложно) задач, в днях и в часах (для самых мелких задач). Тут снова приходит Agile и говорит, возьми не временную оценку, а оценку усилий, заложи туда всё, что может произойти с задачей и назови Story Point (SP). Было не просто уйти от привычного мерила, но шаг за шагом мы двигались, формировали в головах новые нейронные связи и пришли к градации 3, 6, 9, 12. Где 3 самая простая задача, 12 самая сложная. Кто-то использует шаг в 2 SP, кто-то ряды Фибоначчи или размеры одежды и даже размеры животных, мы же остановились на шаге в 3 SP, как самым оптимальным.
Для оценки задачи, субъективно, самой распространённой или скорее более точной техникой является Planning Poker. Тут вновь отходим от правильной методики оценки SP. В каждой нашей команде как минимум, есть 2 сотрудника одной компетенции, например аналитик. Да, они могут быть с разными скиллами, но это не мешает выходить на диалог при оценке задач. SM называет задачу, участник из команды, в рамках своей компетенции, откликается в качестве исполнителя, погружается (хотя в большинстве своём, команда предметно знает свои задачи бэклога из грумингов и рабочего процесса) детально в задачу и оглашает свою оценку в SP. Если SM или сотрудник в схожей компетенции, имеют вопросы или предположение своей оценки, отличной от озвученной, начинается дискуссия и раскладка задачи по полочкам, для более детальной и объективности оценки. Когда все вопросы дискуссии проработаны, фиксируется проговоренная между участниками команды SP задачи. Исполнитель финально подписывается под оценкой.
Задача = подзадача истории. Для удобства контроля выполнения подзадач и историй в целом, мы немного доработали Jira, включив суммарное отображение SP открытых подзадач в истории. Если подзадача закрывается, SP подзадачи вычисляется из общего SP истории. Оценки видны в бэклоге, что позволяет оперативно реагировать на «застрявшие» задачи. К примеру, если история взята в 2-х недельный спринт с оценкой 150 SP, то в соответствии с диаграммой погашения задач, в середине спринта, остаток открытых задач должен составлять примерно 75 SP ±. Видя сильное отклонение от цифры, на командном митинге, можно более детально углубиться в причины и скорректировать действия для успеха исполнения истории в текущий спринт.
Вся оценка историй и Epicʼов строится из оценки подзадач. Со временем, ты понимаешь продуктивность своей команды в SP. Даже при планировании спринта, накидывая историй с подзадачами, ориентируешься на средний показатель спринта. Продуктивность каждого участника команды также видно в SP. Это дополнительный инструмент SM, которым аккуратно можно балансировать нагрузку.
5. Sprint
Временной отрезок, включающий в себя полный цикл разработки продукта, с готовым функционалом на выходе. Спринт состоит из:
Временной отрезок, как правило, задаётся длинной в 1 — 2 недели или месяц. Этого более чем достаточно для потребностей большинства команд. Мы взяли 2-х недельный отрезок, как самый оптимальный и вот почему:
Как упоминал ранее, у нас 7 команд. Каждая команда использует компоненты спринта в удобные для себя дни и время. У кого-то спринт может стартовать/завершаться в середине недели, у кого-то со вторника. Время на груминги и ретроспективы, команда тоже определяет сама. Далее буду описывать работу на примере команды архитекторов.
Новый спринт у нас формируется каждый второй понедельник, после отчётного митинга за минувший рабочий день.
Отличие отчётного митинга от ежедневного митинга только в одном — участник команды не говорит о том, что будет делать сегодня.
В ежедневном митинге, каждый участник команды отвечает на 3 вопроса:
Ловить проблемы разного уровня, в ходе исполнения задач, это нормально. Если решение доступно в моменте, команда молниеносно прорабатывает варианты и принимает к исполнению (например композит выдаёт ошибку из-за некорректно указанной ссылки. Обновили ссылку, всё заработало). Если есть понимание, что требуется потратить приличное количество времени на решение проблемы, идём по сценариям:
Митинг проходит каждый рабочий день, в одно и то же время. У каждой команды своё время с разницей проведения в 30 минут. Это сделано для того, чтобы участники команд, при необходимости, могли подключаться с максимальным погружением к нескольким созвонам (например потребность в архитекторах может быть в нескольких командах сразу).
Груминг (Grooming) проводим каждую неделю, иногда чаще, в зависимости от потребности обсуждения/проработки задач. Стандартная встреча раз в неделю в запланированное время (например, каждый вторник в 16:00). На грумингах мы обсуждаем:
Продолжительность проведения груминга от 30 минут до нескольких часов.
Демонстрация функциональности (Demo/Показ) — проводится каждую вторую пятницу, в день завершения спринта. Demo это всегда волнующий и эмоциональный момент, ведь это двухнедельный результат работы всей команды и каждый участник с трепетом относится к своему детищу.
Demo зачастую проводит тестировщик, он как никто, знает, что показывать и как показывать. Знает, что работает, что нет, знает где есть костыль и как обойти багу. Шучу. Показ нацелен на результат команды, а вы помните, что заказчик является частью команды и прекрасно знает, если что где-то не так, знает, что не успели сделать и знает почему. Все успехи и неудачи делятся поровну, на всех участников команды. Методология скрама этим и хороша — все процессы настолько прозрачны, что в голове и мысли нет, чтобы тратить время на какие-то костыли и варианты демонстрации «красивой картинки». Мы оперируем фактами в текущем моменте, открыто принимаем ситуацию как есть и вместе ищем пути решения.
Ретроспектива спринта — проводится в день показа, ближе к концу рабочего дня. Ретроспектива помогает навести фокус на упущенные вещи, ввести корректировки в процессы команды, поставить новые цели и определить пути достижения. Каждый участник высказывается, делясь своим мнением и мыслями по ходу прошедшего спринта (что настораживает, что радует), озвучивает свои предложения, а также, предлагает идеи и способы реализации.
Поначалу, команде было не очень комфортно высказываться. Вроде всё нормально, спринт закрыли, всё показали, да и пятница, выходные уже вот-вот, что ты от меня хочешь? В какой-то степени это нормально, когда привык делать своё дело и делать его хорошо, да даже отлично. Но сейчас всё иначе. Сформировавшаяся сплочённость, персональная ответственность, открытость в процессах, меняет мышление. Это должно было произойти. Даже интроверты выходят за привычные им рамки и начинают «бомбить» идеями, предложениями, адресованными отзывами, проявляя открытость. Если вначале, мы могли слышать фразы — Вась, твой скрипт навернул мне процесс, что привело к нескольким часам поиска проблемы и как результат, я чуть не зафакапил свои задачи. И Вася начинает ещё больше напрягаться, ведь уже в ходе спринта всё проговорили, поправили, а сейчас опять тему поднимаем. То сейчас, мы говорим так — Вась, твой скрипт навернул мне процесс, мы с тобой потратили много времени на поиск и исправление, я тут прикинул, как в будущем уберечь нас от таких проблем, слушай.
В команде выстраивается открытый диалог, который нацелен на решение проблемы на уровне проекта, а не на уровне личных задач.
Пожалуй, это все процессы, которые мы ежедневно используем в рамках Agile философии и Scrum методологии. Возможно есть ещё какие-то вещи, но они кажутся настолько очевидными за 3 года применения и использования, что я попросту мог их не упомянуть выше.
Теоретическая применимость фреймворка ясна. В следующей статье рассмотрим практическое применение.
Автор: Константин Гусев
Руководитель проектов
Компания ОТР
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!