Гибкая методология разработки “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)
Заранее благодарю за указанные ошибки и неточности!
Почему метод разработки agile очень нужен для создания мобильных приложений?
Студия по разработке мобильных приложений RussianGeeks, решила поделиться с вами методами разработки и планирования мобильных приложения. Интересно то, что многие люди думают лишь о том, чтобы приложение было готово, как финальный этап разработки, но не думают о том, что само приложение включает в себя неимоверное количество этапов и интеграции, тестов и релизов, которые должны быть выполнены в срок и надлежащим качеством. В этой статье Мы решили поделиться с вами о том, как метод Agile может значительно упростить и ускорить выпуск приложения.
Прежде чем понять, что такое метод разработки Agile мобильных приложений, необходимо понять процесс разработки мобильных приложений. Любое приложение, установленное на смартфоне, игре или приложении социальной сети, требует наличия многих факторов для его правильного функционирования. Факторы, которые необходимо учитывать:
- Идею приложения
- Дизайн
- Разработка
- Исполнение и публикацию
- И тестирование
Если любой из этих факторов нарушается, возникают проблемы, такие как: нарушение сроков, потеря финансов, отток сотрудников и другие трудности на этапе реализации.
Разработка мобильных приложений — это результат большой работы, проделанной специалистами из разных областей, и, самое главное, постоянных переговоров между клиентом и компанией, занимающейся разработкой мобильных приложений. Любое программное обеспечение, в том числе мобильные приложения, можно рассматривать как результат правильного и качественного взаимодействия..
Разработка методом Agile мобильных приложений — один из наиболее эффективных подходов ко всем бизнесам по разработке программного обеспечения, он обеспечивает надлежащий канал связи, который помогает как клиентам, так и разработчикам приложений выполнять желаемое мобильное приложение или фактически любое программное обеспечение.
Точное значение Agile — это быстрое внедрение правок и изменений к движущемуся вперёд проекту. То же самое относится и к методологии Agile. Относительно метода управления проектами, который я охарактеризовал как разделение задач на короткие фазы работы и частую переоценку и адаптацию планов.
Характеристики Agile упрощают разработку мобильных приложений, так что результаты мобильного приложения могут быть адаптированы после его публикации.
Поговорим больше об Agile, посмотрим какие принципы разработки программного обеспечения используются. Их всего 12.
- Удовлетворенность клиентов за счет своевременной и непрерывной поставки программного обеспечения
- Приветствуются меняющиеся требования даже на поздней стадии разработки, то есть какие-то правки
- Работающее программное обеспечение доставляется часто, то есть этапы интегрируются и выпускаются регулярно
- Тесное, ежедневное сотрудничество заказчика и разработчика
- Проекты строятся вокруг мотивированных людей, которым доверяют
- Разговор лицом к лицу — лучшая форма общения (последнее время все менее актуально, но все же. )
- Работающее программное обеспечение — главный показатель прогресса
- Устойчивое развитие, способное поддерживать постоянный темп
- Постоянное внимание к техническому совершенству и хорошему дизайну
- Простота — очень важное искусство максимизировать объем незавершенной работы
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
- Команда регулярно размышляет о том, как стать более эффективными, и соответствующим образом корректировать свои действия.
Со всеми этими задачами Agile идеально справляется.Но теперь возникает вопрос насколько она лучше по сравнению с методологией Waterfall.
Как вы думаете, какой из них лучше подходит для разработки мобильных приложений?
Давайте вкратце разберемся, а затем сравним их бок о бок.