Scrum Эта методология предназначена для гибкой разработки программного обеспечения с акцентом на качественном контроле процесса разработки. Ее фундамент заключается в существовании нескольких команд, создающих финальный продукт по четко определенным этапам. То есть финальный продукт готовят не одним махом, а небольшими частями, качественно проработанными и готовыми к выпуску.
Структура скрама состоит из следующих частей:
Роли. События. Правила. Артефакти. Сами роли со своей стороны делятся на две категории. Первая часть полностью вовлечена в работу, вторая — лишь частно заинтересована и задействована, но не имеет прямого отношения к процессу.
В первой категории представлены следующие роли:
Владелец продукта — лицо, понимающее его стоимость для бизнеса. Он представляет интересы всех заинтересованных сторон и доносит все пожелания заказчика. В то же время владелец не вовлечен в технический аспект процесса. Разработчики — ответственные за реализацию технических задач. Их команда состоит из специалистов разных отраслей, обеспечивающих выполнение нужных функций. Также они создают беклог, контролируют качество, адаптируют план к целям спринта. Скрам-мастер или руководитель — ответственный за групповую коммуникацию. Помогает владельцу продукта и разработчикам выполнять свои задачи без препятствий и отвлекающих факторов. Вся коммуникация лиц, не связанных с командой по разработке, происходит исключительно через скрам-мастера. Для этой методологии характерны пять видов событий:
Спринт — центр всего процесса в скраме. В нем происходят самые главные активности: планирование спринта, дейли-скрам, обзор и ретроспектива скрама. Планировка спринта, в котором участвует вся команда. При планировании проводятся презентации продукта и каждый участник может высказать свои предложения или замечания. На этом этапе создается беклог, определяются способы выполнения задач. Дейли-скрам — короткие рабочие встречи до 15 минут. На них планируется расписание рабочего дня разработчиков и анализ трудностей и непонятных вопросов. Присутствие всех разработчиков не обязательно. Члены команды отчитываются, что сделали с момента прошедшего совещания, что будет сделано до следующего, что мешает выполнению поставленных целей. Обзор спринта — демонстрация продукта, созданного при спринте. Происходит в конце спринта с целью показать достижение команды стейкхолдерам. Ретроспектива спринта — полное и подробное обсуждение командной работы на протяжении всего спринта и поиск методов повышения эффективности работы в будущем. Артефакты — методы и инструменты, которые используются в скраме:
Беклог продукта — совокупность действий, направленных на техническую и пользовательскую сторону проекта. Беклог спринта — совокупность задач, которые обязаны быть выполнены во время спринта, создаются на базе беклога продукта. Инкремент — элементы беклога продукта, исполненные во время спринта. Agile Представляет собой достаточно гибкую систему управления. Ее характерными признаками является выдача готового и рабочего продукта на каждом этапе работы и использование небольших команд, у каждой из которых есть своя четкая функция. Их работу обеспечивает комбинированное управление.
Примечательно, что набор инструментов у аджайла такой же, как у скрамы — спринты, беклоги. Временные расходы по выполнению проекта намечают непосредственно под спринтом.
По этой методологии этапы могут не идти один за другим, а проходить параллельно или в разном порядке. Но после каждого этапа продукт должен соответствовать требованиям и работать на определенном уровне.
Основные принципы метода заключаются в следующем:
Активные действия всех вовлеченных в проект участников. Команда имеет возможность принимать общие решения. Требования должны быть прописаны наилучшим образом, их нужно облегчать и показывать наглядно. Шаги (итерации) должны быть краткими и постепенными. Фокус — только на постоянном предоставлении результатов. К следующему шагу переходят только после завершения предыдущего. Полученные результаты нужно тестировать в течение всей работы, а не под конец. Совместная работа как участников, так и заинтересованных сторон. Преимущества аджайла состоят в обеспечении качественного взаимодействия между всеми участниками проекта и гибкости. Метод подходит для компаний, работающих в условиях быстрых и непредсказуемых изменений, в сфере высоких технологий или для работы с клиентом, постоянно меняющим требования.
Среди недостатков следует выделить, что постоянная адаптация к изменениям может привести к тому, что финальный продукт так и не увидит свет.
Kanban Ключевыми признаками этой методологии является наглядность и баланс задач. Каждый участник процесса может отследить все действия — от постановки задачи до результатов ее выполнения. У Канбана нет четких ролей или этапов прогресса. Это часто подходит для различных поточных производств, особенно тех, где финальный продукт нематериален. Выходит что-то вроде эстафеты — каждый отдел, выполнив свою функцию в задаче, передает ее в следующий отдел и т.д. Это помогает увидеть ошибки, сделанные на предыдущем этапе, и своевременно их исправить.
В общем, канбан базируется на четырех принципах:
Визуализация задачи — все поставленные задачи должны отображаться в плане, их статус обновляется по мере прохождения этапов. Группировка — это делается на базе статуса задач, иногда хватает обычного «Нужно сделать», «Выполняется», «Выполнено», «Проверка», «Одобрено». Внимание к незавершенным задачам — если выполнение какой-то задачи затормозило на определенном этапе, то следует разобраться в причинах этого и при необходимости выделить дополнительные ресурсы или предоставить необходимую помощь для завершения работы. Постоянное усовершенствование — контроль за сроками выполнения и перемещением задач помогает находить слабые места в процессах. Из этого делаются соответствующие выводы: где нужно больше ресурсов, где меньше, а где следует корректировать нагрузку. Хорошей иллюстрацией этого метода служит то, как создавалась эта статья:
В специальном задачнике редактор поставила задание «Написать статью на тему методологий проектов» ⟶ журналист прорабатывает источники, пишет статью и переводит ее на редактора ⟶ редактор вычитывает статью и, если все хорошо, переводит ее на корректора ⟶ корректор вычитывает статью на наличие ошибок, вносит правки и передает ее для публикации контент-менеджеру ⟶ он подбирает иллюстрации, публикует статью на нашем сайте и переводит задания обратно на журналиста ⟶ он пересматривает публикацию и закрывает задание, если все правильно.
Все эти этапы имеют специальные статусы в задачнике: «Новая задача», «В работе», «Готово к принятию», «Готово к закрытию», «Закрыто». В случае возникновения проблем на определенных этапах есть статусы «Обратная связь» и «Отклонены».
Waterfall «Водопад» традиционная и распространенная методология. Ее суть состоит в последовательном прохождении процесса, который разделен на определенные этапы или стадии. Этот способ управления используется в проектах, которые могут быть разделены на логические и последовательные части.
Задача руководителя такой модели — следить за выполнением плана и избегать просрочки задач.
Плюсом этого метода есть простота и понятность логики работы, небольшие затраты на обслуживание такой модели управления, четкая оценка стоимости и сроки выполнения. Недостатки очевидны — отсутствие гибкости и невозможность внесения изменений на определенных этапах для получения лучших результатов из-за жесткой основы для работы. Кроме того, с помощью Водопада продукт тестируют только в конце, а не во время каждого этапа и их взаимодействия.