12
1.2. Методология Scrum
1.2.1. Что такое Scrum?
Scrum – это подмножество Agile и одна из самых популярных
платформ для реализации Agile. Это итеративная модель разработки
программного обеспечения, используемая для управления сложным
программным обеспечением и разработкой продукта. В ней определяется
набор ролей, обязанностей и встреч, которые никогда не меняются.
Итерации с фиксированной длиной, называемые спринтами, позволяют
команде выпускать программное обеспечение по готовности.
1.2.2. Преимущества Scrum
Scrum – структура с очень строгим подходом к определению ролей и
регулярных мероприятий. Хотя это может быть чересчур много для
органичного внедрения, эти правила имеют много преимуществ. Из
недостатков можно отметить такие моменты, как необходимость высокого
уровня опыта и приверженности команды и проектов, а также может быть
подвержен риску отставания от сроков.
Таблица 1.2 Таблица преимуществ и недостатков технологии Scrum
Преимущества
Недостатки
Прозрачность и наглядность
проекта: с ежедневными стоячими
встречами вся команда знает, кто что
делает, что позволяет исключить
множество недоразумений и путаницы.
Проблемы определяются заранее,
позволяя команде разрешать их, прежде
чем они выйдут из-под контроля.
Риск замедления разработки:
некоторые проекты Scrum могут
испытывать сбой в продуктивности из-за
отсутствия конкретной даты окончания.
Без даты завершения у заинтересованных
сторон может возникнуть соблазн
продолжать запрашивать дополнительную
функциональность.
Повышенная ответственность
команды: нет менеджера проекта,
сообщающего команде Scrum, что делать
и когда. Вместо этого команда
коллективно решает, какую работу они
Команда требует опыта и
приверженности: с определенными
ролями и обязанностями команда должна
быть хорошо знакома с принципами
Scrum, чтобы добиться успеха. Поскольку
13
могут выполнить в каждом спринте. Все
они работают вместе и помогают друг
другу, улучшая сотрудничество и
позволяя каждому члену команды быть
независимыми.
в команде Scrum нет определенных ролей
(все делают всё), для этого требуются
члены команды с большим техническим
опытом. Команда также должна совершать
ежедневные встречи Scrum и оставаться в
команде на протяжении всего проекта.
Легко вносить изменения: с
короткими спринтами и постоянной
обратной связью легче справляться с
изменениями и вносить изменения.
Например, если команда обнаруживает
новую историю пользователя во время
одного спринта, они могут легко добавить
эту функцию к следующему спринту во
время собрания для обработки оставшихся
задач.
Неправильный мастер Scrum может
испортить всё: мастер Scrum очень
отличается от менеджера проекта. Мастер
Scrum не имеет полномочий над
командой; ему нужно доверять команде,
которой они управляют, и никогда не
указывать им, что делать. Если мастер
Scrum пытается контролировать команду,
проект потерпит неудачу.
Повышенная экономия затрат:
постоянная связь обеспечивает
информирование команды обо всех
проблемах и изменениях, как только они
возникают, что помогает снизить расходы
и повысить качество. Посредством
создания и тестирования функций в
небольших кусках существует постоянная
обратная связь, и ошибки могут быть
исправлены на ранней стадии, прежде чем
они станут слишком дорогими для
исправления.
Плохо определенные задачи могут
привести к неточностям: затраты и сроки
проекта не будут точными, если задачи не
будут четко определены. Если
первоначальные цели неясны,
планирование становится
затруднительным, и спринт может занять
больше времени, чем первоначально
предполагалось.
1.2.3. Роли в Scrum
Владелец продукта должен иметь понимание того, что он хочет
построить, и передает это видение команде. Он не является
менеджером проекта: вместо того, чтобы управлять прогрессом, он
должен мотивировать команду целью и видением.
Мастер Scrum часто считается тренером команды. Это означает
организацию встреч, рассмотрение препятствий и вызовов, а также
работу с владельцем продукта для обеспечения готовности продукта
к следующему спринту. Он не имеет полномочий над членами
команды, но имеет полномочия в отношении этого процесса.
14
Команда Scrum состоит из трёх-семи человек. Все в проекте
работают вместе. Команда Scrum владеет планом для каждого
спринта, они прогнозируют, сколько работы они могут выполнить на
каждой итерации.
1.2.4. Шаги в процессе Scrum
Планирование продукта: владелец продукта и команда Scrum
собираются для определения приоритетов элементов в журнале
продуктов и наполняют ими бэклог продукта.
Планирование спринта: перед каждым спринтом владелец
продукта представляет верхние позиции из бэклога на совещании по
планированию спринта. Затем команда выбирает, какую работу они
могут выполнить во время спринта, и перемещает работу из бэклога
продукта в бэклог спринта.
Уточнение или уход за бэклогом: в конце одного спринта команда
и владелец продукта встречаются, чтобы убедиться, что бэклог готов
к следующему спринту. Цель в том, чтобы отставание содержало
только те элементы, которые являются релевантными и подробными,
и которые отвечают целям проекта.
Ежедневные Scrum-встречи: 15-минутные общие встречи, в
которых каждый член команды рассказывает о своих целях и любых
проблемах, которые возникли. Ежедневный Scrum происходит
каждый день во время спринта и помогает держать команду в курсе.
Презентация: на этой встрече должна присутствовать живая
демонстрация, а не отчет или презентация PowerPoint.
Ретроспектива: в конце каждого спринта команда отражает то,
насколько хорошо Scrum работает на них и рассказывает о любых
изменениях, которые необходимо внести в следующем спринте.
15
Рис. 1.2 Схема последовательных этапов разработки по технологии Scrum
На изображении мы видим, как из бэклога проекта выбирается
несколько историй, далее планируется спринт и формируется бэклог
спринта, после чего в течение 2-4 недель разрабатывается готовый к
использованию участок проекта.
1.2.6. Инструменты и методы в Scrum
Помимо ролей и церемоний, проекты Scrum также включают в себя
определенные инструменты и методы.
Scrum-доска может иметь разные формы, но традиционно включает
в себя картотеки, заметки Post-It или доску. Обычно разделенеа на
три категории: что нужно сделать, что находится в работе и что
сделано. Команда Scrum должна обновлять доску на протяжении
всего спринта. Например, если кто-то придумает новую задачу, он
создаст новую карточку и поместит ее в соответствующую колонку.
Истории пользователей описывают функцию программного
обеспечения с точки зрения клиента. Он включает в себя тип
пользователя, что он хочет сделать и какую цель преследует.
Команда разработчиков использует эти истории для создания кода,
который будет отвечать требованиям истории.
График сжигания (рис. 1.3) представляет собой всю проделанную и
оставшуюся работу. График сжигания может показывать команде,
если что-то не идет по плану и помогает в принятии решений.
16
Timebox – это заданный период времени. Вместо того, чтобы
команда работала до достижения цели, подход к временному окну
прекращает работу.
Рис. 1.3 Представление инструмента «графика сжигания»
На рисунке отмечена оранжевая линия «идеального сжигания», то
есть равномерного выполнения задач по отношению ко времени. Такого
результата добиться практически невозможно, и мы видим отображение
реального положения дел, на котором зелёной кривой отображаются
затрачиваемые усилия, серой – остаток задач.
1.3. Методология водопада
1.3.1. Что такое водопад
Методология водопада придерживается последовательного,
линейного процесса. Иногда она используется совместно с диаграммой
Ганта, которая показывает даты начала и окончания каждой задачи. Как
только один из восьми этапов будет завершен, команда разработчиков
перейдет на следующий шаг. Команда не может вернуться на предыдущий
этап без начала всего процесса с самого начала.
17
1.3.2. Преимущества водопада
Водопад лучше всего использовать для простых, неизменных
проектов. Его линейный, жесткий характер позволяет легко использовать и
позволяет выполнять углубленную документацию. Но поскольку Waterfall
является линейной последовательной моделью, вы не можете прыгать
между фазами, даже если происходят неожиданные изменения.
Таблица 1.3 Таблица преимуществ и недостатков технологии Waterfall
Преимущества
Недостатки
Простота использования и управления:
поскольку модель Waterfall соответствует
одному и тому же последовательному
шаблону для каждого проекта, ее легко
использовать и понимать. Каждая фаза
имеет конкретные результаты и обзор,
поэтому ее легко управлять и
контролировать.
Изменения не могут быть органично
внедрены в проект: как только команда
завершит определенный этап, к нему
нельзя уже будет вернуться. Если они
достигают фазы тестирования и
понимают, что функция отсутствовала на
этапе требований, будет очень сложно и
дорого вернуться и исправить ее.
Дисциплина: каждый этап в Водопаде
имеет начальную и конечную точку.
Сосредоточив внимание на требованиях и
дизайне до написания кода, команда
может снизить риск пропущенного срока.
Программное обеспечение не
демонстрируется до конца работы: в
проекте должно быть завершено две-
четыре фазы до начала программирования.
Требуется хорошо документированный
подход: Водопад требует документации
для каждой фазы, что позволяет лучше
понять логику кода и тестов. Он также
оставляет бумажный след для любых
будущих проектов или если
заинтересованным сторонам необходимо
увидеть более подробную информацию об
определенном этапе.
Сбор точных требований может быть
сложным: одним из первых этапов проекта
«Водопад» является общение с клиентами
и заинтересованными сторонами и
определение их требований. Тем не менее,
может быть трудно точно определить, что
они хотят в начале проекта.
1.3.3. Этапы водопада
В Водопаде есть восемь этапов, и все они должны происходить в
последовательном порядке.
Концепция: эта фаза начинается с идеи. Этап концепции
предполагает грубую оценку проекта, почему он полезен и
рассматривает любые первоначальные сметы расходов.
18
Инициирование: как только идея сформирована, вам нужно нанять
команду и определить цели, сферу действия и конечные результаты.
Анализ требований: требования собираются и анализируются,
чтобы убедиться, что проект действительно осуществим.
Дизайн: Конструктивные спецификации, созданные на этом этапе,
используются на этапе написания кода.
Реализация: начинается фактическое кодирование программного
обеспечения. Любые блок-схемы или алгоритмы, созданные на этапе
проектирования, переводятся на язык программирования.
Тестирование: как только код будет завершен, программное
обеспечение должно быть проверено на наличие ошибок.
Обслуживание: после того, как клиенты используют программное
обеспечение в реальном мире, они могут найти новые проблемы.
Рис. 1.4 Схема работы по методологии водопада
Методология водопада – наиболее простая для понимания и наиболее
сложная для реализации. Работа по каждому этапу должна быть выполнена
максимально кропотливо, так, чтобы не осталось ни одной, даже самой
маленькой ошибки. Такой подход используется крайне редко.
19
1.4. Kanban
1.4.1. Что такое Канбан?
Канбан - японский символ для «визуального знака» или «карты». Это
визуальная среда, используемая для реализации Agile, которая показывает,
что производить, когда производить и сколько производить. Будь то
физическая или онлайн-система, она состоит из разных колонок.
Простейшие таблицы имеют три столбца: что нужно сделать, что делается
и что нужно делать. Столбцы для проекта разработки программного
обеспечения могут состоять из бэклога, поставленных задач, в разработке,
на тестировании, утвержденных и выполненных столбцов.
Рис. 1.5 Наглядное представление реальной доски Канбан
Карточки Kanban представляют задачу, и каждая карта помещается
на доске в полосе, которая представляет статус этой задачи. Эти карточки
показывают состояние работы с первого взгляда.
1.4.3. Преимущества Канбан
Наглядная природа Канбана дает уникальное преимущество при
внедрении Agile. Доску Kanban легко внедрить и использовать, она
улучшает поток работы и минимизирует время цикла. А недостатки
Канбан, связаны в основном с неправильным использованием или
неправильной обработкой правления Канбана.
20
Таблица 1.4 Таблица преимуществ и недостатков технологии Kanban
Преимущества
Недостатки
Увеличивает гибкость: Kanban -
развивающаяся, мягкая модель. Нет
заданных фаз, а приоритеты
переоцениваются по мере поступления
новой информации.
Устаревшая, давно не
обновлявшаяся доска может привести к
возникновению проблем: команда должна
быть уверена в том, что доска Kanban
отражает реальное положение дел, иначе
они будут отрабатывать неточную
информацию.
Сокращение отходов: Kanban
вращается вокруг сокращения отходов,
гарантируя, что команды не тратят время
на работу, которая не нужна, или что кто-
то делает работу неправильно.
Команды могут скомпрометировать
совет: Совет Канбана должен оставаться
ясным и легким для чтения, однако
некоторые члены команды могут изучить
«новые трюки», которые они могут
применить к своей доске. Добавление
таких нововведений на доску Канбана
просто зарывает важную информацию, и
работать с доской становится неудобно.
Легко в понимании: визуальный
характер Канбана помогает сделать его
невероятно интуитивным и легким в
освоении. Команде не нужно изучать
совершенно новую методологию, и
Kanban можно легко реализовать поверх
других систем.
Недостаток времени: частая жалоба
на Канбан заключается в том, что вы не
знаете, когда все будет сделано. Столбцы
на панели Kanban отмечены только фазой
(для выполнения, в процессе, полной), нет
никаких временных рамок, связанных с
каждой фазой, поэтому вы действительно
не знаете, как долго может длиться фаза.
Улучшает поток доставки: команды
Kanban оптимизируют поток работы для
клиентов.
Минимизирует время цикла, то есть
количество времени, которое требуется
для того, чтобы работа переходила через
полный рабочий процесс команды.
1.4.4. Основные практики и принципы Канбан
Каждый проект Канбана должен следовать основным принципам:
Визуализация рабочего процесса: визуальное представление
работы позволяет понять общую картину, как продвигается работа.
Предельная незавершенная работа: определяется минимальный и
максимальный объем работы для каждого столбца.
21
Управление потоком: необходимо контролировать и улучшать
поток работы. Нужен быстрый, плавный поток, который показывает,
что команда быстро создает ценность.
Явные политики процессов: для того, чтобы совместные
изменения произошли в системе Канбана, процессы должны быть
явными.
Постоянное улучшение: метод Канбана поощряет небольшие
постоянные изменения, которые сохраняются. В процессе работы
команда может выявить проблемы и предложить улучшения.
1.5. Выводы первой главы
Рассмотрев наиболее распространенные инструменты управления
разработкой программного обеспечения, мы можем увидеть, что уже
существует достаточное количество методов и способов сделать работу IT-
подразделения любого размера прогнозируемой, эффективной и
результативной, т.е. отвечающей всем требованиям, которые руководство
компании и заказчики предъявляют этой области деятельности.
При этом все участники процесса могут прикладывать больше
усилий для того, чтобы реализовывать проект более эффективно. Но если
для этого достаточного интереса, нужно стимулировать его новыми
методами, мотивировать работников и заказчиков к тому, чтобы их
взаимодействие происходило эффективнее, а сама работа проходила
быстрее и чётче. Для этих целей мы предлагаем воспользоваться методами
набирающей популярность во всех областях человеческой деятельности –
от развлекательной до производственной – геймификации, суть, истоки и
примеры внедрения которой мы рассмотрим во второй главе.