Как известно, SCRUM и KANBAN – это методы управления проектом разработки определенных продуктов или услуг. Их относят к многочисленному семейству представителей методологии Agile-сообщества. Они весьма гибкие и итеративные, их возможностями могут пользоваться сотрудники из любой сферы, но больше всего они подходят для целей IT-сферы.
Зачастую применяется симбиоз этих методов. И, как правило, используют исключительно лучшие наработки KANBAN и/или SCRUM.
SCRUM и KANBAN весьма качественно объединяют в себе базовые принципы построения AGILE-манифеста:
- Группа людей превыше всего, выше любого процесса или комплекса инструментов. Люди, которые постоянно трудятся сообща над одной задачей, имеют значительный потенциал на конечный успех. Команда – это единое целое ядро, а значит, за положительный и негативный результат она отвечает исключительно сообща. Фундаментальный принцип – равное общение между коллегами и коллективное обсуждение возникающих задач и противоречий;
- Разрабатываемый веб продукт важнее любой подробной документации или спецификации. Как и в SCRUM, так и в KANBAN делается упор на существенном уменьшении документооборота и повышении коммуникации между коллегами внутри одной команды, а также постоянном обсуждении текущего проекта. Крайне важен процесс визуализации процесса разработки. Для подобных целей можно использовать простые доски с карточками, каждая из которых содержит определенное задание или поручение;
- Взаимодействие с клиентом превыше процесса согласования договора. Основа успеха – постоянное общение с заказчиком и пресловутая обратная связь. Подобная стратегия позволяет максимально исчерпывающее понять, что конкретно необходимо клиенту в конечном итоге;
- Постоянная готовность быстро реагировать на поступающие изменения, даже если они идут вразрез с ранее установленным планом. Этот принцип необходим для того, дабы быстро уметь реагировать на обратную связь и совершенствовать создаваемый продукт.
Хотя эти две методологии и имеют много общего, у них хватает различий, которые мы далее детально рассмотрим.
Состав команды
Проектная группа, работающая по технологии SCRUM, универсальна по своему набору.
В ее состав входит большое количество разноплановых специалистов, которые вполне могут решить любую задачу на конкретном проекте. Традиционно хватает 5-8 человек.
Если количество специалистов возрастёт, результат менее очевиден. Поэтому у сотрудников SCRUM-группы нет четко определенной компетенции, к примеру: QA может запросто помогать дизайнеру при составлении макета главной страницы, а маркетинговый аналитик – программисту или менеджеру проекта (ну и наоборот).
KANBAN же подразумевает балансировку разных специалистов внутри созданной команды.
Над решением поставленной задачи могут трудиться одновременно несколько узкопрофильных групп.
К примеру, сначала поставленные задачи решает отдел аналитики, затем – дизайнеры, и только потом к задаче допускаются разработчики. При всем этом, не возбраняется организовывать универсальные команды.
Отчерченные роли
SCRUM-команде необходимо большее количество разнообразных ресурсов, чем в KANBAN-команде. Для качественного управления всеми аспектами разработки необходимы дополнительно созданные роли: так называемый Scrum master и Product owner (собственник проекта).
Scrum master – это руководитель. Но он не выполняет управление, и тем более не раздает указания направо и налево.
В его задачи входит организация тематических собраний, устранение бытовых проблем, мотивация команды, слежение за статусом выполнения задач, проверка на соответствие всех внутри командных действий на предмет Scrum-подхода. Также, Scrum master выполняет такую же работу, как и другие члены команды.
Product owner имеет прямую связь с заказчиком, связывает волю клиента с возможностями команды, следит за развитием проекта, и при всем этом не является формальным начальником.
На него возлагаются обязанности по проставлению приоритетов внутри команды.
Он знакомится со всеми достигнутыми результатами работы.
Внутри Kanban-сообщества подобные ресурсы не актуальны, так как процесс разработки имеет линейное построение и весьма прост в конечном исполнении.
Проектной группе не требуется руководитель и собственник продукта. Группа –это единое целое.
Процесс планирования
И в Scrum, и в Kanban проект делится на 10, а то и 100 мелких подзадач разного характера.
Все будущие задачи на проекте, «складываются» в итоговый список – backlog. Каждая задача обладает своим приоритетом и актуальностью.
Отличие заключается в том, что все приоритеты в Scrum расставляются владельцем проекта, а в Kanban – исключительно проектной группой.
Временной промежуток
При использовании Scrum методологии время работы над проектом разбивается проектной группой на равноценные отрезки – спринты, длительность которых не превышает 4 недели, но чем короче спринт, тем проще вносить в него изменения и дополнения. При Scrum методологии сроки соблюдаются в обязательном порядке.
Любой спринт состоит из 4 взаимно дополняемых этапов:
- Процесс планирования. Проектная группа анализирует общее количество намеченных задач и выстраивает их в хронологическом порядке по приоритету выполнения. На спринт отбираются только те задачи, которые, по мнению команды, действительно будут выполнены;
- Выполнение. Все члены проектной группы трудятся одновременно: программист пишет код, тестировщик создает к нему набор тестов, а технический писатель – техническую документацию;
- Выпуск в продакшн. К моменту выпуска новой версии или сборки продукта, он должен быть максимально работоспособным, полезным для конечного пользователя и более совершенным, чем до момента создания спринта;
- Ретроспектива. Все участники проектной группы берут участие в обсуждении спринта. Они вместе анализируют возможные пути повышения качества работы, и что можно в будущем сделать быстрее и лучше.
Подход Scrum не такой гибкий, так как этот метод категорически запрещает добавлять новые задачи в уже начатый спринт. Даже самый срочная и важная обратная связь будет реализована исключительно в отдельном спринте, после завершения начатых ранее.
В конце этапа все недоделанные задачи возвращаются обратно в backlog. А на стадии планирования следующего спринта определяется необходимость и время для их завершения.
Также необходимо отметить, что при Scrum нужно выделять время на постоянные митинги, где планируются все будущие спринты и решаются возникающие организационные моменты.
При Kanban особо не нужно проводить постоянные встречи-обсуждения. Их периодичность может варьироваться от одной недели до месяца.
В Kanban любой проект делиться на особые этапы выполнения намеченных задач, к примеру: «Нужно выполнить», «Находиться в тестировании», «Завершено». Подобные этапы могут быть различной длины по временному отрезку.
Новые задачи или доработки можно вносить в любое время. Если перед командой поставлена задача что-то сделать в первую очередь, проектная группа не будет ждать наступления нового спринта, а срочно займется выполнением порученного задания.
Из этого всего можно предположить, что в Kanban сложнее контролировать временные рамки, необходимые для разработки веб продукта и делать прогнозы касательно завершения начатого модуля, чем при соблюдении Scrum методологии.
Доска
Чтобы максимально качественно визуализировать сущность этих двух методологий, зачастую используют физические либо же электронные доски, к примеру: Jira или Trello. С их помощью можно сделать рабочий процесс более открытым и понятным для всех членов проектной группы.
Ну и, конечно же, запланировать задачи и проставить текущие приоритеты.
Подобная доска делиться на несколько столбцов, которые отображают разные этапы завершения выполнения поставленных задач: «Test», «Done», «Review» либо же, «To do». Учитывая масштабы и задачи каждого конкретного проекта, количество столбцов может существенно варьироваться, но в целом, когда их немного, тем лучше.
Внутри каждой созданной карточки детально расписывается текущий приоритет, и проставляются сроки выполнения. По мере выполнения задач, карточки перемещаются по доске, что позволяет проектной группе воочию наблюдать за ходом выполнения задач и видеть, где возникают определенные трудности и неурядицы.
В данном случае отличие методов заключается в том, что при методологии Kanban, подобная доска постоянно находится в заполненном виде. При Scrum подходе, доску очищают тогда, когда наступает черёд выполнения новой итерации.
Показатели результативности
При соблюдении Scrum методологии измеряется суммарный вес всех проставленных задач, которые необходимо выполнить за один спринт.
Поделив общий вес текущих задач на потенциальную производительность за 1 спринт, проектная группа получает ориентировочный срок завершения проекта. Рост производительности – наиболее важный показатель проектной группы при соблюдении Scrum методологии.
При Kanban измеряется среднее время выполнения одной задачи на доске. Это время – самый доходчивый ориентир потенциальной эффективности проектной группы.
Участники команды не концентрируются на выполнении определенной задачи, но следят за тем, чтобы средний показатель выполнения был минимальным.
Особенности внедрения
Перейти на рельсы Agile очень просто именно через Kanban. А все потому, что у данной методологии очень мало ограничений, и не нужно формировать на проекте универсальные команды, а можно продолжать делиться на функциональные отделы.
Использовать Scrum можно тогда, когда есть уверенность, что в совершенстве владеешь всеми гибкостями методологии.
Как этого достичь?
- Отыщите настольную игру getkanban и попробуйте сыграть в нее со своими коллегами;
- Если игра пришлась по душе, возьмите любой текущий проект и разделите его задачи на мелкие составляющие. Очень удобно, когда все задачи занимают примерно одинаковое время для их выполнения. Проставьте приоритеты выполнения;
- Подумайте над стадиями, которые должны проходить эти задачи. К примеру, это может быть такая логика: План-Выполнение-Готово;
- Подумайте над ограничениями для статуса задач, как вам подсказывает логика;
- Проведите начальное совещание. Обсудите с коллегами, по какому принципу будете организовывать работу. Когда именно наступит время для релиза, и когда всех ждет следующее совещание;
- Перетащите пару задач с backlog в статус «План» и начинайте работать;
- Наблюдайте за тем, чтобы карточки «путешествовали» между колонками, когда сущность задачи перешла с одного статуса в другой;
- Следите за временем, затраченным на выполнения проставленных задач. Добавляя на доску новую карточку, напишите на ней время начала работы, а снимая с доски – время окончания;
- Проводите эксперименты с ограничениями по работе с карточками, чтобы показатель среднего времени на выполнение задачи неуклонно уменьшался;
- Проводите специализированные собрания, где каждый член проектной группы может высказать свое мнение касательно работы над текущим проектом: у него есть возможность сказать, что пошло по плану, а что в следующий раз можно было бы улучшить.
Опыт многих успешных на сегодняшний день веб компаний красноречиво говорит о том, что быстро внедрить Scrum или Kanban технологию очень трудно.
Если команда привыкла постоянно трудиться по каскадной структуре, перейти в плоскость гибкой методологии будет очень трудно. Но главное не опускать руки, и все получиться.
На самом деле, не важно, что выберете именно вы, ведь что для Scrum, что для Kanban любое взаимодействие внутри команды важнее продуктивной и востребованной практики.
Оставить комментарий