14 лучших kanban инструментов в 2019 году

Содержание:

Определения

Скрам-процессы

Scrum

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Спринт

Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно скрам-стандарту компании Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец продукта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта.

Журнал пожеланий проекта

Журнал пожеланий проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items)

Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса.

Журнал пожеланий спринта

Журнал пожеланий спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объём работы, который нужно проделать для завершения спринта.

Диаграмма сгорания задач (Burndown chart)

Диаграмма отображает завершенный спринт. Показывает оставшиеся нерешённые задачи и трудозатраты, необходимые для их завершения в расчёте на 21 рабочий день.

Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта.

Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом. Данные должны быть доступны для всех членов проекта.

Существуют два вида диаграммы:

  • диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
  • диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

История

Термин «scrum» пришёл из регби, где он означает схватку. Здесь запечатлена схватка в регбийном матче клубов «Ньюпорт» и «Лондон Уэлш» 1904 года

Подход впервые описали и в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «регбийный подход».

В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведенный в статье Такэути и Нонакой. в начале 1990-х использовал подход, который привел SCRUM в его компанию. Впервые методология SCRUM была представлена на общее обозрение задокументированной, четко сформированной и описанной совместно Швабером и на OOPSLA’95 в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь свой опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как SCRUM. Швабер объединил усилия с в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».

С 2009 года публичный документ под названием The Scrum Guide официально определяет Scrum. Он был пересмотрен 5 раз, с текущей версией в ноябре 2017 года. В 2018 году Schwaber и сообщество Scrum.org вместе с лидерами сообщества Kanban опубликовали Руководство по Kanban для групп Scrum.

Scrum

В центре SCRUM находится команда, у каждого есть четкая роль. Условно, команда делится на 3 вида ролей:

1. Product Owner (владелец продукта) — человек, понимающий каким продукт должен получится на выходе. Он собирает и приоритезирует требования. Общается с клиентом или клиентами. Рассказывает о ним команде. Вот кстати интересный факт: Product owner это не всегда клиент. Это запросто может быть человек в команде разработки.

2. SCRUM Мастер — это “сердце команды”, задача этой роли в том, чтобы создать для команды максимально комфортные условия работы, мотивировать и помогать. Роли мастера и владельца продукта ни в коем случае не должны пересекаться.

3.  Непосредственно команда, которая выполняет проект: дизайнер, Front-end, Back-end.

“А кто головой отвечать будет??!” — восклицает Андрей.

В SCRUM нет распределяющей шляпы, которая говорит кто что делает и несет за это всю ответственность, как обычно принято. С точки зрения технологий Agile, команда является самоорганизующийся. Лидеры появляются в зависимости от той задачи, которую в данный момент решаем. А зависит это от итерации на которой находимся.

Андрею нужно изначально разбить время на отрезки, собрать команду, желательно до 7 человек на конкретный проект, все содержание проекта разделить на части, примерно равные по размеру. А что, как и когда делать, каждый решает для себя сам, при поддержке Scrum мастера и на условиях выдвинутых Владельцем продукта. 

Обязанности владельца продукта:

  • Анализ рынка
  • Улучшения продукта и техническое обслуживание
  • Определение требований
  • Вывод продукта на рынок
  • Обслуживание клиентов
  • Разработка стратегии продукта
  • Планирование, координация и реализация стратегических мер
  • Технико-экономические обоснование
  • Оценка ожидаемого объема продаж
  • Создание дорожной карты продукта
  • Формирование процессов внедрения и жизненного цикла продукта
  • Оптимизация возврата инвестиций (ROI)

Таким образом, владелец продукта сопровождает продукт на протяжении всего его жизненного цикла так же, как менеджер продукта. Это одна из причин, почему Scrum часто влечет за собой организационные изменения: жизненный цикл продукта не начинается и не заканчивается при разработке продукта, а затрагивает почти все части организации.

Владельцем продукта обычно является один человек, понимающий требования клиентов. Обычно это не технический эксперт, не старший разработчик или архитектор

Важно не устанавливать так называемого владельца продукта “по доверенности”. Этот термин описывает владельца продукта, который много работает с командой разработки, доступен для вопросов и выполняет многие утомительные задачи, такие как разъяснение требований

Тем не менее, этот человек не имеет полномочий принимать решения по этим самым требованиям. Такой владелец продукта может по-другому воспринимать какие-либо детали, чем тот, кто принимает решения. В свою очередь, команда разработчиков также по-разному интерпретирует эту информацию. В конце концов, это приводит к плачевным результатам. Кроме того, если владелец продукта увидит результаты (инкремент) только после окончания спринта, он, скорее всего, будет разочарован и получит запросы на изменение. Эта процедура неэффективна.

Основными навыками владельца продукта должны быть коммуникация и способность мотивировать других. Менеджер по продукту, берущий на себя роль владельца продукта, должен знать, что у него будет возможность и, возможно, обязанность регулярно выпускать и поставлять продукт. Для некоторых это ново, поскольку не все привыкли думать с точки зрения полной погруженности в свой продукт.

Он – единственный человек, который действительно владеет продуктом и говорит последнее слово. Он имеет решающее значение для успеха продукта.

Какой смысл набирать лучших разработчиков, если создаётся не тот продукт? Владелец продукта – это краеугольный камень, от которого зависит продукт.

В конечном счёте, команда разработки служит владельцу продукта, а Scrum мастер – команде разработки. Можно также сказать, что продакт оунер обслуживает клиента и других заинтересованных лиц.

Владелец продукта имеет полное право принимать все решения о продукте. Это отличает его от традиционного руководителя проекта, который отвечает только за рамки проекта, график и бюджет. Создаёт ли продукт ценность для пользователей и клиентов – не главная забота менеджера проекта. Это задача владельца продукта. Он максимизатор ценности продукта.

Эксперт в области и отношения с заинтересованными сторонами

Владельцу продукта необходимо понимать предметную область продукта, а также идентифицировать и тесно сотрудничать со всеми заинтересованными сторонами (клиенты, пользователи, руководители). Хороший владелец продукта – эксперт в области, который знает бизнес с разных сторон. Это позволяет владельцу продукта быстро принимать решения и корректировать стратегию по мере появления новой информации от заинтересованных сторон.

Эффективный владелец продукта должен иметь возможность усиливать других экспертов по предметным вопросам, чтобы помочь руководить продуктом. Владелец продукта может даже создать прямые линии связи между командами разработки и заинтересованными сторонами.

Владелец продукта и команда разработки

Помимо тесного сотрудничества со всеми заинтересованными сторонами, хороший продакт оунер также тесно сотрудничает с командой разработки. На самом деле, владелец продукта должен работать с командой разработки над бэклогом продукта, уточнением, критериями приёмки. Хотя ответственность за некоторые области лежит непосредственно на владельце продукта или на команде разработки, фреймворк Scrum предоставляет обеим сторонам множество возможностей для совместной работы и разделения ответственности.

Чем теснее команда разработки участвует в написании пользовательских историй, тем большую заинтересованность они будут показывать в проекте. Это означает, что владелец продукта, тратит меньше времени на определение требований и больше времени на то, чтобы рассказать команде о ценности продукта.

На чем стоит Scrum: роли, элементы и другое

Прежде чем приступить к разбору Скрама, неплохо было бы познакомиться с ценностями подхода. Они звучат ну прямо как гимн или установки из кабинета психолога. И еще раз доказывают, что все гениальное – просто и базируется на понятных вещах.

Основные ценности Скрама – это преданность, смелость, сфокусированность, открытость и уважение. Отсюда вытекают и главные принципы фреймворка – прозрачность, инспекция и адаптация. Все это ложится в основу всеобщего доверия. 

Итак, Scrum – относительно простой и гибкий подход к разработке. И у него есть своя четкая структура из несложных элементов и ролей. Поехали!

Роли в Scrum

В Scrum всего 3 роли:

  1. Скрам Мастер. Это бизнес-аналитик, руководитель проекта. Его задача – организовывать и проводить совещания и следить за тем, чтобы соблюдалась технология Scrum. Еще он снимает противоречия и направляет команду. 
  1. Product Owner. А это уже владелец проекта, его функциональный заказчик. Он отвечает за разработку продукта и ставит задачи команде. Это всегда один человек, а не группа лиц.
  2. Development Team. Команда из профильных специалистов – программистов, дизайнеров, аналитиков и т.д. Работает по принципам самоорганизации и самоуправления. Типичный размер команды – 7 человек (плюс/минус 2). За результат команда отвечает как единое целое. 

Артефакты (элементы) Scrum

В Скрам задействуется всего 4 артефакта.

Product Backlog

Это список требований, которые необходимо выполнить по проекту. Когда в нем не остается требований, проект считается завершенным. Принимать участие в дополнении этого списка могут все участники команды. 

Sprint Backlog

Список требований на ближайший спринт. Все требования обязательно делятся на задачи и получают оценку. Задачи обычно представляются команде на Kanban-доске.

Sprint Goal

Краткое описание цели, ради которой выполняется спринт. Целевое оформление спринта помогает команде в принятии обоснованных решений. Артефакт несет неоценимую помощь в пользу проекта, если команда находит альтернативные пути выполнения задачи и имеет право самостоятельно принимать подобные решения. Для осознанности таких решений и определяется цель спринта. 

Sprint Burndown Chart

Дословно название артефакта переводится как «диаграмма сгорания». В качестве «сгорающих» элементов рассматриваются человеко-часы. Диаграмму обновляют по завершению любой задачи. Незамысловатые диаграммы позволяют наглядно оценить, насколько быстро команда продвигается вперед. 

Ритуалы (процессы) в Скрам

Подход использует парочку процессов, которые здесь принято называть ритуалами. Каждый из них можно использовать строго по инструкции в соответствии с подходом. В реальной жизни ритуалы пытаются сделать адаптивными, но ключевые принципы остаются неизменными.

Sprint Planning Meeting

Это встреча по планированию спринта, на которой команда выбирает требования из Product Backlog и создает Sprint Backlog. На этой встрече Product Owner отвечает на вопросы участников команды.

Daily Meeting

Ежедневная встреча всей команды – она обязательно должна проходить каждый день, причем в одно и то же время. Интересный момент: на встрече все стоят (потому встречи еще зовут стендапами), потому длительность мероприятия не более четверти часа. В таком коротком временном промежутке каждый должен ответить на 3 вопроса:

  • Что я делал вчера?
  • Чем я занимаюсь сегодня?
  • Какие есть проблемы?

На этом митинге только делятся информацией, и не решают проблемы, а лишь выявляют их.

Sprint Review

Самый волнительный момент в завершении спринта – демонстрация результата. Ценность его в том, что любой результат, как отличный, так и очень плохой, все равно будет продемонстрирован. Если этого не происходит, то такое положение вещей дискредитирует все плюсы гибких процессов. 

Retrospective

Это ритуал по обмену опытом в коллективе команды и конструктивное улучшение процесса разработки. На встрече обязательно присутствие всей команды, вместе со Скрам Мастером, а вот Product Owner сам решает – приходить или воздержаться. На встрече озвучивают ответы на ряд вопросов:

  • Какие решения нужно принять, чтобы сделать процесс еще более предсказуемым?
  • Какие проблемы мешают выполнять обязательства, возложенные на команду?
  • Как еще лучше работать и взаимодействовать с Product Owner’ом?
  • Какие ошибки допускаются в команде и почему это происходит?

Что такое скрам-доска?

Методология скрам, изначально предназначенная для разработчиков программного обеспечения, основана на применении коротких рабочих периодов — спринтов, каждый из которых длится около двух недель. В течение такого периода владелец проекта обычно отвечает за организацию и проведение летучек или ежедневных совещаний для обсуждения хода работ. Скрам-мастер несет ответственность за сам проект. Он обязан убедиться, что все участники команды поддерживают ценности и лучшие методики скрам. И, наконец, участники команды непосредственно отвечают за выполнение спринтов.

Сотрудники канадского стартапа Procurify, занимающегося закупками программного обеспечения, обнаружили, что им удается сэкономить 70% времени, планируя спринты с помощью решения для совместной работы. Теперь участники команды знают, чем заняты остальные, и могут сотрудничать с коллегами из других команд. «С помощью единого инструмента для управления всем процессом, мы можем наблюдать за работой сотрудников и видеть, насколько это совпадает с целями компании», — прокомментировал Юджин Донг, сооснователь и технический директор Procurify. С историей успеха Procurify вы можете ознакомиться ниже:

За:

  • Возможность исправлять ошибки и избегать проблем, которые могут возникнуть.
  • Легкая адаптация к изменениям благодаря коротким спринтам и постоянной обратной связи.
  • Возможность вносить изменения в ход разработки на любом этапе, так как процесс становится более гибким.
  • Благодаря прозрачности клиенты могут отслеживать весь процесс и оценивать производительность отдельных исполнителей.
  • Методология скрам часто не требует лишних затрат благодаря простоте в использовании.

Против:

  • Это итеративная методология, и она требует постоянной обратной связи от участников команды для улучшения процесса.
  • Процесс требует высокого уровня доверия внутри команды. Слишком строгое управление может привести к срыву всего проекта.
  • Участнику команды может быть сложно уйти во время процесса.
  • Если нет жесткого срока, может произойти бесконтрольное расширение работ по проекту.
  • Отсутствие прогнозируемых временных рамок и оценки затрат может привести к тому, что понадобится несколько спринтов.
  • На участников команды оказывается сильное давление, и им приходится тратить много времени на разработку проекта.

Если душа просит подробностей

Scrum Master – помощник, а не хозяин

Если взять основное назначение такого понятия, как «чиновник», то оно приведёт нас к некоему человеку, который является слугой народа и занимается устранением любых проблем в отведенной ему области. Звучит утопично, не правда ли? Все мы прекрасно знаем, что происходит, когда некий чиновник перестает быть слугой народа, а то и вовсе не понимает главного смысла своей работы и начинает чувствовать себя просто управленцем, верхушкой треугольника, которому должен служить народ и выполнять все его поручения. Ничего хорошего, конечно, из этого не получается.

Scrum Master играет в кёрлинг

В качестве известного примера Scrum-методологии является игра кёрлинг. Нас она сейчас интересует со стороны Scrum Master.

Основные правила кёрлинга:

  1. Игра ведется на специальной площадке с дорожкой и «мишенью».
  2. Один игрок производит бросок камня, который катится в сторону мишени.
  3. Во время движения камня по льду происходит трение об лёд, и, по факту, камень может либо перекатиться через мишень, либо, наоборот, не докатиться. В данном случае в дело вступают игроки, которые занимаются так называемым «свипингом». Свипинг – это процесс натирания льда, который обеспечивает более быстрое скольжение камня по льду благодаря образующейся тонкой прослойке воды. Свипер (натирающий лёд), по сути, выполняет следующие функции:
  • не прикасается к движущемуся камню;
  • организует именно ту дорожку для камня, которая максимально точно приведет его к цели.

Можно ли сказать, что свипер двигает камень? Физически его толкает другой игрок и фактически свиперы не трогают камень. Однако именно благодаря свиперам камень движется именно так, как надо.

Как видно, свипер – это полный аналог Scrum Master. Scrum Master так же, не трогая работу самой команды, непосредственно влияет на её движение к заданной цели и никуда иначе. На примере кёрлинга очень хорошо видно, насколько важна работа Scrum Master.

Интересные Scrum-проекты

eduScrum

То, что скрам используется не только в IT сфере, демонстрирует проект  — инициатива учителя химии в школе нидерландского городка Алфен-ан-ден-Рейн. При поддержке делового сообщества в Голландии был создан фонд eduScrum, который обучает учителей использовать скрам на уроках. Школьники, работающие в скрам-командах, учатся лучше и с большим удовольствием, чем сверстники.

Проект «Страж» для ФБР

Внедрение скрам методологии спасло от краха многомиллионный проект американского правительства — единую базу данных «Страж» для ФБР. «Страж» был второй попыткой разработать единую информационную систему для ФБР. Первая провалилась, не проработав и дня.

«Страж» начал создаваться в 2005 г. по каскадной модели. На проект было выделено 4 года и 450 млн дол. В начале пятого года компания-подрядчик выполнила половину работ и израсходовала 95% бюджета. По оценкам экспертов ей бы потребовалось еще 350 млн. и 6-8 лет для завершения проекта.

Когда в начале 2010 г. каскадную модель сменила работа в скрам-командах, производительность разработчиков увеличилась втрое и 2 июля 2012 года «Стражем» пользовались сотрудники ФБР во всех штатах.

Собрания

Планирование спринта (Sprint Planning Meeting)

Происходит в начале новой итерации Спринта.

  • Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
  • На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах;
  • Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
  • Обсуждается и определяется, каким образом будет реализован этот объём работ;
  • Продолжительность совещания ограничена сверху 4—8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
    • (первая часть совещания) Участвует владелец продукта и скрам команда: выбирают задачи из бэклога продукта;
    • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта.

Ежедневное совещание (Daily Scrum meeting)

  • начинается точно вовремя;
  • все могут наблюдать, но только «свиньи» говорят;
  • длится не более 15 минут;
  • проводится в одном и том же месте в течение спринта.

В течение совещания каждый член команды отвечает на 3 вопроса:

  • Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
  • Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
  • Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Скрам над скрамом (Scrum of Scrums)

Проводится после ежедневного скрам-совещания.
Позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции.
Повестка та же, что и на ежедневном скрам-совещании плюс следующие вопросы:

  • Что каждая команда сделала с момента предыдущего ежедневного совещания?
  • Что каждая команда сделает к следующему ежедневному совещанию?
  • Есть ли проблемы, мешающие или замедляющие работу каждой команды?
  • Нужно ли другой команде сделать что-то из задач вашей команды?

Обзор итогов спринта (Sprint review meeting)

Проводится в конце спринта.

  • Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам.
  • Привлекается максимальное количество зрителей.
  • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
  • Нельзя демонстрировать незавершенную функциональность.
  • Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.

Ретроспективное совещание (Retrospective meeting)

Проводится в конце спринта.

  • Члены команды высказывают своё мнение о прошедшем спринте.
  • Отвечают на два основных вопроса:
    • Что было сделано хорошо в прошедшем спринте?
    • Что надо улучшить в следующем?
  • Выполняют улучшение процесса разработки (обсуждают варианты решения проблем, фиксируют удачные решения и вызвавшегося владельца решения).
  • Ограничена тремя часами для спринта любой длины.

Как сделать скрам-процесс успешным?

О чем следует помнить, когда только начинаете использовать эту методику?

1. Определите приоритеты в очереди задач

Первым делом нужно понять, какая задача является самой важной. Это значит, что владелец продукта должен составить список целей, которые нужно достичь, и задач, являющихся приоритетными

После этого скрам-мастер помогает команде обменяться идеями о том, что нужно сделать для достижения этих целей и сколько для этого требуется ресурсов (времени, труда, бюджета). Далее владелец продукта определяет, каким будет простейший работающий продукт — что необходимо сделать, а что нет. После чего команда решает, какую часть этих задач можно успеть сделать к концу спринта

Это значит, что владелец продукта должен составить список целей, которые нужно достичь, и задач, являющихся приоритетными. После этого скрам-мастер помогает команде обменяться идеями о том, что нужно сделать для достижения этих целей и сколько для этого требуется ресурсов (времени, труда, бюджета). Далее владелец продукта определяет, каким будет простейший работающий продукт — что необходимо сделать, а что нет. После чего команда решает, какую часть этих задач можно успеть сделать к концу спринта.

Сет Мессер, старший разработчик компании Vecteezy, объясняет, почему этот процесс так важен для определения пути к поставленной цели: «У разработчиков есть ограничение по времени (то есть мы должны сделать ту или иную задачу в поставленных временных рамках). Это означает, что мы знаем, что нам нужно сделать, и хотим, чтобы это было сделано к определенному моменту. К примеру, к февралю 2018 года нам нужна новая версия сайта. Начать работу — дело несложное, и мы знаем, что должны получить на выходе (например, новый сайт), но все, что лежит между этими двумя точками, покрыто мраком. Какую именно работу нужно выполнить и в какой момент?»

2. Летучки должны быть краткими и действенными

Ежедневные совещания-летучки — краеугольный камень скрам-процесса, так как они позволяют команде обсудить общие проблемы и совместными усилиями их устранить. Они должны занимать не больше 10-15 минут в зависимости от размеров команды. И хотя совещания — привычный элемент делового мира, к летучкам новая скрам-команда, возможно, привыкнет не сразу.

Гэвин Вудс, сертифицированный скрам-мастер из SCRUM Alliance, руководит проектами по цифровой трансформации для клиентов компании PITSS из различных отраслей. Он признает, что проводить летучки придется учиться. «Честно говоря, — говорит, он, — в некоторых компаниях внедрение скрама может очень сильно изменить привычные подходы к работе. Людям приходится больше рассказывать о том, что они делают и с какими трудностями сталкиваются, и решать проблемы сообща. Не каждому это дается легко».

«Когда вы только начинаете использовать скрам, скрам-мастеру приходится приучать сотрудников открыто, но коротко рассказывать о своей работе, — говорит Вудс. — Для этого мастерам необходимо действовать очень прямолинейно и иногда давить на людей, чтобы все участники команды поняли, что от них требуется».

Чтобы летучки были короткими, их проводят стоя, и это лишний раз мотивирует выступающих не лить воду. В конце каждый участник команды должен дать ответ на три вопроса:

  • Чего я добился?
  • Чем я занят в настоящий момент?
  • С чем я испытываю затруднения? / В чем мне нужна помощь?

Если какой-либо момент невозможно объяснить в двух словах, его следует перенести на следующее совещание. Если задача не касается остальных членов команды, ее можно упомянуть лишь вскользь.

Летучки помогают озвучить проблему, как только вы с ней столкнетесь

Поэтому крайне важно открыто говорить о том, что вам нужна помощь команды в том или ином деле. Чтобы сократить время летучек, по максимуму используйте систему управления проектами для обменя информацией по текущему статусу работы, оставляя для устного обсуждения лишь самые проблемные моменты

3. Записывайте сделанные выводы

Не забывайте проводить ретроспективу в конце каждого спринта. Обычно ретроспектива — это часовое совещание, на котором команда разбирает, какие успехи были достигнуты, какие уроки усвоены и что стоило бы улучшить для будущих спринтов.

Заносите сделанные выводы в базу знаний и обеспечьте свободный доступ к ним для всех членов команды. И не давайте негативным аспектам работы заслонить успехи вашей команды.

«Важно не нарушить баланс между тем, что не удалось, и тем, что прошло гладко, — говорит Вудс. — Позитивный настрой способствует творчеству»

OnAgile Academy

Онлайн обучение Agile, Scrum и продуктовому менеджменту

  • Вы сможете выявить ценность, которую хочет получить и/или удержать ваш потенциальный клиент, а также проблемы и препятствия, которые стоят перед потребителем
  • Вы ознакомитесь с понятем ценности, концепцией и моделью ценностного предложения, Jobs To Be Done, узнаете про уровни коммуникации ценности и освоите метод 4U
  • В результате вы сможете прямо на вебинаре усилить ценностное предложение, что позволит улучшить экономику вашего продукта или услуги

Тренинг Scrum Professional online

После прохождения обучения вы детально разберетесь в Scrum-фреймворке и принципах его работы. Сможете перевести свою команду на Scrum процесс и выступать в роли Scrum-мастера. Тренинг проводится практикующим Agile-коучем, экспертом в Agile и Scrum с международной сертификацией, и построен вокруг решения кейсов участников. На тренинге присутствуют участники из компаний различных сфер, что позволит вам узнать и разобрать особенности применения Agile и Scrum в реальных ситуациях.

Дополнительные совещания SCRUM

Эти совещания могут не входить в общий рабочий процесс SCRUM, но определенно имеют место быть в некоторых ситуациях.

SCRUM of SCRUMs

Если коллектив больше 11 человек, то команда больше рекомендуемого SCRUM размера. Для расширения SCRUM предложена методика SCRUM of SCRUMs.

Тогда коллектив разбивается на несколько SCRUM-команд. В каждой cвой менеджер-мастер и владелец продукта.

Команды проводят Daily SCRUM.

После ежедневного совещания SCRUM проводится митинг SCRUM of SCRUMs (SoS). Это значит следующее. От каждой команды выбирается по представителю. Представители разбиваются по 5-9 человек. Каждой группе назначается главный менеджер-мастер (Chief SCRUM Master) и главный владелец продукта (Chief SCRUM Product Owner) из числа менеджер-мастеров и владельцев продукта, участвующих в проекте. Команда представителей из разных SCRUM Team называется SCRUM of SCRUMs Team. В таком составе проводят 15-минутный стоячий митинг SCRUM of SCRUMs (SoS) или Meta SCRUM или Scaled Daily SCRUM(SDS).

Кен Швабер рекомендует проводить SCRUM of SCRUMs каждый день.

Однако некоторые команды SCRUM of SCRUMs проводят не каждый день, а 2—3 раза в неделю. Это нарушает базовые принципы SCRUM и является классическим примером SCRUMbut. Это не позволяет в полной мере использовать все преимущества SCRUM.

SCRUM of SCRUMs позволяет нескольким SCRUM Teams обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Главный менеджер-мастер задает всем членам SCRUM of SCRUMs-команды четыре вопроса, три первых вопроса повторяют вопросы Daily SCRUM:

  • Что каждая команда сделала с момента предыдущего совещания SCRUM of SCRUMs для достижения цели спринта?
  • Что каждая команда сделает к следующему ежедневному совещанию SCRUM of SCRUMs для достижения цели спринта?
  • Есть ли проблемы, мешающие команде достичь цели спринта?
  • Нужно ли другой команде сделать что-то из задач вашей команды для того чтобы помочь ей достичь цели спринта?

Если SCRUM of SCRUMs не охватывает весь коллектив, может быть проведен митинг SCRUM of SCRUM of SCRUMs (SCRUM-3, SoSoS), SCRUM of SCRUM of SCRUM of SCRUMs (SCRUM-4, SoSoSoS), и так далее. Последний MetaSCRUM называется Executive Meta SCRUM(EMS) или Executive Action Team(EAT). Такой подход позволяет всего за час организовать работу 4096 человек.

Порядок проведения SCRUM of SCRUMs такой же как у Daily SCRUM —

  • в одно и то же время, в одном и том же месте,
  • все могут наблюдать, но только «свиньи» говорят,
  • в митинге участвуют Chief SCRUM Master, Chief SCRUM Product Owner и SCRUM of SCRUMs Team,
  • длится ровно 15 минут,
  • все участники SCRUM of SCRUMs стоят (митинг в формате Daily Standup).

Груминг беклога (Grooming)

Беклог отправляется в парикмахерскую для того, чтобы команда разработки и владелец продукта могли:

  • Добавить, убрать или разбить элементы беклога продукта (PBI).
  • Уточнить или дать новые оценки.
  • Изменить порядок следования элементов беклога продукта.
  • Обсудить и прояснить требования.

Четвертый шаг. Делаем прототип

Чтобы не потратить кучу времени и сил на продукт, который никому не нужен, проверьте, все ли вы поняли правильно. Даже после общения с клиентом и выяснения требований могут остаться вопросы. Если вопросов нет, это еще не значит, что вы поняли, чего хочет клиент. Как это проверить? Покажите заказчику ваше видение проекта.

Готовим наглядную схему продукта: электронную версию или на бумаге

Не концентрируемся на дизайне, тут важна структура.

Акцентируем внимание на удобстве интерфейса будущего продукта для пользователя.

Показываем результат клиенту. Он добавляет комментарии.


Так выглядит прототип сайта с комментариями клиента. Источник.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector