Формирование организации процесса

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

Такой метод позволяет грамотно собирать все необходимые данные,

Зачастую отсутствие слаженности и непонимание конечной цели разработки, как правило, приводят к нарушениям планов и графиков работ, увеличению бюджета, а также созданию нездорового внутреннего микроклимата в коллективе.

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

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

Чем больше людей тем больше разговоров и меньше дела.

Теряем время когда переключаемся между разными делами.

1 проект – 0% потерянного времени.

2 проекта – 20% потерянного времени.

3 проекта – 40% потерянного времени.

4 проекта – 60% потерянного времени.

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

Product owner (владелец продукта): специалист, отвечающий за связь всей команды с заинтересованными сторонами (stakeholders), такими как руководство и сотрудники компании, заказчик, потребители, клиенты и др. Его можно назвать куратором проекта.

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

Scrum-team (скрам-команда) проекта: все остальные участники команды равноправны в команде и работают над задачами определенными на этапе планирования.

В Scrum-методологии стартовым документом является так называемый product backlog – это список пожеланий к результатам, ранжированный по важности и, иногда, по сложности.

На этапе формирования команды топ-менеджмент назначил владельца продукта (product owner).
Владелец продукта приступил к сбору информации и формированию списка пожеланий к результатам product backlog на основе данных рынка, опроса топ-менеджеров «Вандекс» и фокус-групп с потенциальными клиентами.
Нанятая команда (scrum-team) совместно с владельцем проекта провела установочную встречу, на которой определила размер спринта в две недели, приняла и расставила приоритеты для «пользовательских историй» из списка задач (product backlog). Затем уже без владельца продукта, команда, под контролем и управляющим воздействием скрам-мастера, распределила задачи по спринтам, сформировала спринт-бэклог предстоящего спринта; каждый участник команды взял себе в работу задачи из списка бэклога. Не используя специфическую терминологию все действия этого этапа сводятся к следующему: определяется длительность каждой итерации работы команды до очередной встречи с куратором, формируется и согласовывается окончательный список требований и спецификаций для начала работы, затем из него членами команды выбираются задачи для первой итерации, остальные распределяются по будущим и команда приступает к разработке.
Идет первый спринт: в течение, которого каждый день команда собирается на 15 минутные скрам-летучки (scrum-meeting). На этих встречах участники команды посвящают коллег в статус выполнениями ими выбранных задач, делятся планами на день, возникающими сложностями, что позволяет всем участникам команды быть в курсе текущего статуса проекта. Например, у одного из членов команды ответственного за дизайн «слетел софт» и у него нарушается привычный ритм работ и возможно он не уложится в срок, надо будет переносить задачу, но не факт. Другой член команды ответственный за разработку, нашел в сети готовый блок кода и поэтому освободится раньше. Так как оба специалиста кросс-функциональны и вся команда отвечает за продукт, второй предложил помощь первому и скорее всего в срок они уложатся. Удобно для такой встречи использовать визуализацию в виде доски или специального программного обеспечения, в котором отмечены задачи текущего спринта и все product backlog (все задачи из списка спецификаций) каждая с учетом ее статуса: «к выполнению», «в работе», «на тестировании», «выполнено». Доска соответственно разделена на соответствующие столбцы, и участники команды переносят свои задачи из одного столбца в другой, иллюстрируя статус своих задач и вводя в курс дела своих коллег.
По завершению спринта, команда демонстрирует выполненную работу владельцу продукта, который в свою очередь дает обратную связь в ответ. Без владельца продукта команда обсуждает итоги проведенного спринта и полученные новые вводные от владельца продукта, планирует следующий спринт. Например, команда демонстрирует работающий прототип программы: интерфейс пользователя, водителя и администратора сервиса такси.
Цикл спринтов повторяется до тех пор, пока не будет готов продукт, проведено его тестирование и он не будет принят владельцем продукта и заказчиком. Но в ходе работ может быть создан первый релиз, который будет предложен потребителю для проверки в условиях реального рынка сформированных перед реализацией проекта гипотез, получения новых вводных, новой информации в отношении потребностей конечного пользователя. Современное производство программного обеспечения подразумевая априори регулярный выпуск обновлений на основе выявленных недостатков и проблем, а также новых запросов потребителя.
По завершению проекта скрам-команда проведет ретроспективное совещание, на котором проанализирует все сложности и вызовы при реализации проекта, запротоколирует сам ход реализации, характеристики продукта и как они менялись по ходу разработки и т.п. Чтобы сохранить полученные знания в ходе реализации проекта для своих будущих проектов и для отчета перед заказчиком.

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

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

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

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

Инкремент — Инкремент представляет собой сумму всех элементов Бэклога Продукта, выполненных во время спринта, и ценность инкрементов всех предыдущих Спринтов. В конце спринта новый Инкремент должен быть «Готов», что означает его работоспособность и соответствие определению «Критериев Готовности» СКРАМ команды.

Элемент Бэклога Продукта — элемент Бэклога Продукта, который нужно выполнить за итерацию спринта. Обычно разбивается на несколько меньших подзадач.
Цель Спринта — то, что нужно сделать, чтобы выполнить элемент Бэклога Продукта.
Берн-даун чат Спринта — работа, которая остается до полного выполнения задач спринта. Берн-даун чат может быть восходящим или нисходящим в зависимости от того, с чем команда сталкивается при выполнении задачи. Он служит не отчетом о продвижении команды, а методом преодоления трудностей и поддержания активности.
Релиз Продукта/Берн-даун чат Продукта — его в конце каждого спринта обновляет СКРАМ-мастер. Горизонтальная ось соответствует спринтам, вертикальная — показывает, сколько работы (в начале каждого спринта) осталось до завершения проекта.

Правила скрам-фреймворка

Роли, встречи и артефакты — основные правила SCRUM, но есть и другие, которые также добавляют процессу эффективности:

СКРАМ команда состоит только из Владельца Продукта, SCRUM-мастера и Команды разработки.
Все спринты должны быть одинаковыми по длине.
Когда завершается один спринт, следующий начинается немедленно.
Каждый спринт начинается с Планирования Спринта. Команда разработки каждое утро проводит Ежедневный SCRUM.
В каждом спринте проводят Обзор Спринта, чтобы стейкхолдеры могли предоставить обратную связь.
Дополнять Бэклог Спринта во время спринта — не лучшая практика.

Больше сведений по терминологии SCRUM вы сможете получить из глоссария SCRUM-терминологии (см. scrum.org).

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

Разумеется, продолжаться так больше не может — и именно для того, чтобы разорвать этот порочный круг, была создана методика управления проектами Scrum. Джефф Сазерленд, автор методики, описал ее основные положения в своем труде «Scrum. Революционный метод управления проектами».

Выкиньте свои визитки. Должности и звания — это лишь ярлычки вашего статуса. Пусть вас знают за то, что вы делаете, а как к вам будут обращаться — не суть важно.

Сделать половину — не сделать ничего.

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

Если для выполнения работы вам нужен герой — у вас проблема. Героическое усилие следует рассматривать как признак ошибки при планировании.

Планируйте реальность, а не пустую мечту.

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

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

Commitment — понимание необходимости брать обязательство перед собой, перед командой, перед организацией за выполнение поставленных целей и задач на короткий период работы (1-4 недели); понимание командой, что им необходимо делать всё, что в их силах, чтобы выполнить то, что они сами (!) пообещали реализовать; понимание своих реальных возможностей и, соответственно, взятие на себя реалистичных обязательств. Как говорит Джефф Сазерленд, это одна из основ непрерывного улучшения. Это действия, направленные на то, чтобы быть лучшими людьми, лучшими командами, лучшими компаниями.

Focus — это сосредоточенность на ближайшей цели команды, на выполнении того обещания, которое было дано владельцу продукта, клиенту. Распыление не дает возможности брать на себя обязательства перед кем-либо. Сосредоточенность — даёт такую возможность.

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

Openness — открытость в отношениях внутри команды и с клиентом, когда проблемы не прячутся «под ковер», и когда каждый член команды имеет право голоса. Только так можно реалистично прогнозировать, что может быть поставлено заказчику в установленный срок, и действительно выполнить обещанное. Только когда все согласились с достижимостью поставленных целей, с направлением движения, с выбранными путями достижения целей, только тогда можно взять на себя обязательство за их выполнение.

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

Внедряем Scrum ценности

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

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

Начать можно с общей встречи и открытого разговора со всей командой (включая Product Owner), желательно в начале проекта. Если это сделано не было, начать никогда не поздно. На встрече перечисляем и выписываем на доску Scrum ценности.
Просим каждого члена команды на цветных карточках/стикерах написать, что именно для него значит каждая ценность, как бы он хотел, чтобы она проявлялась в их команде. Каждой ценности дать 3-5 характеристик. Получаем 3-5 карточек от каждого члена команды.
Складываем все карточки и получаем набор определений к каждой ценности.
Вместе делаем первичную группировку карточек. Все одинаковые и подобные карточки собираем и даем им единое название под соответствующей ценностью.
Получаем набор примерно по 10-15 определений для каждой ценности.
Проводим несколько итераций по разделению наших карточек на 2 группы — «важно», «менее важно». Здесь можно голосовать, обсуждать. Но обязательно получить 2 равные группы. Чем-то придется жертвовать. Каждый раз то, что находится в разделе «важно» делим еще раз на «важно» и «менее важно».
Останавливаемся, когда каждая ценность имеет по 3 определения в финальной группе «важно».

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

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

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

Удачи всем в непрерывном развитии 🙂