Бережливое производство (Lean)

Бережливое производство (lean manufacturing) — концепция управления производственным предприятием (Toyota), которая основана на постоянном стремлении предприятия к устранению всех видов потерь.

Lean в разработке ПО пришел из бережливого производства (Lean Manufacturing), он имеет набор принципов, относящихся к качеству, скорости и клиентоориентированности.

Основные принципы:

• Исключение потерь. Потерями считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

• Предельно быстрая доставка заказчику. Короткие итерации.

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

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать быстро, ошибаться мало; учиться стремительно».

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

Lean также делает очень сильный акцент на то, что называется “системой”, т.е. что команда работает как единое целое. Мы всегда должны смотреть на нашу работу “с высоты”, чтобы быть уверенным, что мы улучшаемся в целом. Например, много менеджеров хотят “занять” работой каждого разработчика на 100%, но в большинстве случаев это, на самом деле, контрпродуктивно. Давайте не будем заставлять людей кодировать то, что не нужно (или полностью не определено), только ради того, чтобы они кодировали, потому что в будущем для нас это создает еще больше работы.

Подводя черту, Lean говорит: уважайте людей. Это означает давать людям ту работу, которую они лучше всего знают как надо делать. Дайте им то, что им необходимо, чтобы быть эффективными и затем доверьте им сделать это. Суть программной разработки в постоянном обучении; поэтому строить работу нужно так, чтобы убеждаться, что мы постоянно учимся. И поэтому нужно откладывать принятие решения до последнего момента (ведь мы будем на тот момент знать больше). В итоге разработка идет путем создания качественного продукта, потому что нет другого способа, обеспечивающего постоянную быструю поставку, если нужно возвращаться и убирать наш беспорядок.

“Организации, которые по-настоящему следуют Lean, имеют сильное конкурентное преимущество, потому что они очень быстро и в высшей степени дисциплинированно реагируют на рыночный спрос, а не пытаются предсказывать будущее”, – Мэри Поппендик.

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

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

Agile

Agile опирается на совокупность ценностей и принципов, изложенных в манифесте Agile.

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

Ценности Agile:

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условия контракта.

• Реагирование на изменение важнее следования первоначальному плану.

Принципы Agile:

• Наивысший приоритет — удовлетворение пользователей.

• Изменение требований приветствуется.

• Работающий продукт следует выпускать как можно чаще.

• Представители бизнеса и разработки должны работать вместе ежедневно.

• Над проектом должны работать мотивированные профессионалы.

• Непосредственное общение является наиболее практичным и эффективным.

• Работающий продукт — основной показатель прогресса.

• Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.

• Постоянное внимание техническому совершенствованию и качеству проектирования повышает гибкость проекта.

• Простота — искусство минимизации лишней работы — крайне необходима.

• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

• Команда должна систематически анализировать возможные способы повышение эффективности и соответственно корректировать стиль своей работы.

Kanban

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

Доска Kanban

Работа kanban-команд строится вокруг kanban-доски, которая используется для визуализации и оптимизации рабочего процесса.

Доски нужны, чтобы визуализировать работу команды, стандартизировать процесс, а также найти и устранить блокеры и зависимости. На стандартной Kanban-доске процесс состоит из трех шагов: «Запланировано», «В работе» и «Сделано». Однако доску можно настроить в соответствии с процессом, принятым в той или иной команде, в зависимости от ее размеров, структуры и целей.

Методология Kanban основана на полной прозрачности работы и обмене информацией по ресурсам в режиме реального времени. Таким образом, Kanban-доска должна стать единственным достоверным источником информации о работе команды.

Преимущества Kanban

Гибкость планирования

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

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

Сокращение времени цикла

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

Если теми или иными навыками обладает несколько человек, продолжительность цикла сокращается, если же только один — в процессе появляется узкое место. Именно поэтому команды стремятся делиться знаниями и внедряют такие практики, как проверка кода и менторинг. Благодаря обмену знаниями члены команды могут выполнять разнообразные задачи, что еще больше оптимизирует продолжительность цикла. Это также означает, что в случае скопления работы вся команда сможет взяться за нее и восстановить нормальное течение процесса. К примеру, тестирование не всегда выполняют только инженеры по тестированию. Разработчики тоже могут поучаствовать.

В методологии Kanban все члены команды отвечают за то, чтобы рабочие процессы протекали без задержек.

Меньше узких мест

Многозадачность убивает эффективность. Чем больше незавершенных задач, тем чаще приходится переключаться между ними, а это сказывается на сроках их завершения. Поэтому ключевой принцип Kanban состоит в ограничении объема незавершенной работы (WIP). Лимиты незавершенной работы позволяют быстро находить в работе команды узкие и проблемные места, вызванные нехваткой внимания, людей или навыков.

К примеру, типичная команда разработчиков ПО может использовать четыре состояния процесса разработки: «Запланировано», «В работе», «Проверка кода» и «Сделано». Для состояния проверки кода можно установить лимит WIP, равный 2. Число может показаться маленьким, но на все есть свои причины: разработчики предпочитают писать собственный код, а не проверять чужой. Низкий лимит стимулирует команду уделять особое внимание задачам в состоянии проверки, а также проверять чужую работу, прежде чем создавать свои задачи на проверку кода. В конечном итоге это сокращает общее время цикла.

Наглядность

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

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

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

Непрерывная поставка

Непрерывная поставка (CD) предполагает частую поставку релизов продукта клиентам. Непрерывная интеграция (CI) — это практика инкрементной автоматизированной сборки и тестирования кода в течение дня. Вместе они образуют конвейер CI/CD, без которого сложно обойтись командам разработчиков, если они хотят быстрее выпускать качественное ПО.

Kanban и CD идеально дополняют друг друга, поскольку обе методики основаны на своевременной (и последовательной) поставке ценности. Чем быстрее команда сможет выпустить инновационное решение на рынок, тем более конкурентоспособным будет ее продукт. Kanban-команды сконцентрированы именно на оптимизации процесса поставки продуктов клиентам.

Лимит WIP

Лимиты незавершенной работы (WIP) применяются в процессе agile-разработки, чтобы ограничить максимальное количество задач на каждом этапе рабочего процесса. Лимитируя объем незавершенной работы, вы можете обнаружить слабые места в рабочем процессе команды. Благодаря этому вы без труда выявите проблемы в потоке поставки продукта до того, как ситуация усложнится.

Плохие практики при использовании лимитов WIP (не надо так делать):

• Ограничения незавершенной работы можно при необходимости увеличить, чтобы команды в них не упирались («потолок долга»).
  Не стоит!

• У всех есть большое «фоновое задание», чтобы скрыть время, которое в противном случае считалось бы простоем без работы.
  Не должно быть!

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

• Выделение большего количества человеко-часов на решение проблемных моментов является более предпочтительным, чем совершенствование методов разработки или командных процессов.
  Надо постоянно улучшать процессы!

Цели для agile-команд, использующих лимиты WIP:

Цель 1. Научиться делить работу на отдельные задачи примерно равного объема. Разбивая на части требования и пользовательские истории, важно следить, чтобы на выполнение отдельной задачи уходило не более 16 часов. В итоге команда будет увереннее подходить к оценке сложности работы, и проблемных мест станет меньше. Ничто так не замедляет работу команды и не приближает ее к ограничениям WIP, как большая задача, препятствующая работе конвейера.

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

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

Цель 3. Сократить простои. Если у какого-либо участника команды появилось свободное время, посоветуйте ему помочь коллегам на других этапах работы. Общая продуктивность команды повысится, а заодно и сотрудник чему-нибудь научится!

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

SCRUM

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

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

Артефакты Scrum

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

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

Инкремент (или цель спринта) — это готовый к использованию конечный продукт по итогам спринта. Принято представлять инкремент на демонстрации в конце спринта, на которой команда показывает, что она сделала за спринт. Слово «инкремент» не так уж широко встречается в повседневной жизни. Его часто определяют как принятые в команде критерии готовности продукта, контрольную точку, цель спринта или даже полную версию или поставленный эпик. Все зависит от того, какими критериями готовности руководствуется ваша команда и как выбираются цели спринта.

Церемонии Scrum

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

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

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

Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует планировать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой. Не стесняйтесь менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.

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

Ежедневное Scrum-совещание, или стендап. Это очень короткое ежедневное собрание, которое для удобства проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание также называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное Scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от цели и получал план работы на ближайшие 24 часа.

Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

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

• «Что мне удалось сделать вчера?»

• «Что я планирую сделать сегодня?»

• «Может ли мне что-то помешать?»

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

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

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

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

Роли в Scrum

Владелец продукта Scrum

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

Об эффективных владельцах продукта можно сказать следующее:

• Они составляют бэклог продукта и управляют им.

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

• Они дают команде понятные указания, чтобы ее участники знали, какие возможности поставить следующими.

• Они решают, когда поставить продукт, стремясь делать это как можно чаще.

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

Scrum-мастер

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

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

Команда разработчиков Scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников.

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

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

Оценка задач в SCRUM

Многие agile команды предпочитают оценку сложности в Story Points.

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

Размер в SP = Объем работы  + Сложность + Неуверенность (Неизвестность) 

Обычно для оценки используются числа Фибоначчи

Оценки: | 0 | 0,5 | 1 | 2 | 3 | 5 | 8 | 13 | 21 | 

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

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

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

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

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

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

Рекомендации:

• Стори поинты не надо сводить только к сложности, неопределенности или объему работы. 

• Стори поинты не надо переводить в часы  — это создаст дополнительные разногласия в оценках. 

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

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

• Не забывайте оценивать баги — конечно, если у команды нету фиксированного процента времени на устранение багов. 

• Не присваивайте стори поинты очень мелким задачам (например, двухчасовому исследованию) — можно поставить 0. 

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

• Если в новом спринте остается работа с прошлого спринта, не оценивайте ее повторно: во-первых, вы уже знаете ее продолжительность в часах, во-вторых, эа работа потом отразится в скорости (velocity) команды. 

• Не подстраивайте оценку в стори поинтах под отдельного разработчика. 

• Если меняется состав команды, нужно настроить оценки заново. 

• Не подстраивайтесь под оценку самого опытного специалиста на совещании. 

• Не забывайте обсудить неадекватные оценки на ретроспективе. 

Покер планирование

Это одна из самых популярных техник оценки. Участники процесса используют специально пронумерованные карты (подобные игральным), чтобы голосовать с их помощью за оценку user story. Обычно для «покера» используются карты с числами Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89), но возможны и другие варианты.

Процесс оценки выглядит следующим образом:

• Каждый участник получает колоду карт с числовыми значениями для оценки, изображением «?» (запрос уточнения задачи) и «чашки кофе» (требование перерыва).

• Product Owner делает краткий анонс очередной пользовательской истории и отвечает на вопросы команды по данной задаче.

• Участники «покера» выбирают карту с подходящей по их мнению оценкой и кладут их рубашкой вверх (чтобы не влиять на выбор друг друга).

• После того, как все члены команды выбрали свои оценки карты одновременно переворачиваются.

• Участникам с самыми низкими и высокими оценками делают краткие комментарии объясняя свой выбор оценки.

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

Planning Poker одна из самых точных техник оценки, но подходит для сравнительно небольшого количества задач. В течение часовой сессии таким способом можно оценить 4-10 историй.

T-Shirt планирование

В качестве единицы измерения в этой технике используется размер футболки: XS, S, M, L, XL. Команда принимает решение о размере той или иной пользовательской истории в ходе совместной открытой дискуссии. В случае неопределенности, возможно применение голосования. При желании можно договориться о соотношении «размеров», например, S это до 2 XS, M это до 2 S и так далее.

Как правило первые несколько задач оцениваются предварительно. Далее начинает вырисовываться картина о степени декомпозиции историй. В итоге мы находим самые мелкие относительно остальных задачи и они принимаются за XS . После этого остальные задачи оцениваются с точки зрения насколько они больше XS. В зависимости от этого им присваивается определенный размер S, M, L или XL.

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

Данная техника является довольно быстрой и ее можно использовать для оценки большого количеством user story за одну сессию. С ее помощью вполне реально за час оценить 15-20 историй.

Bucket планирование

В этой методике используется принцип похожий на Planning Poker - задачи оцениваются и помещаются с ведерки с соответствующим размером. Для указания размера также можно использовать числа Фибоначчи. Однако у этих методов есть принципиальное различие – в Bucket System после начального масштабирования задач, задачи разделяются между участниками для оценки.

Процесс оценки выглядит так:

• Все истории, которые требуется оценить, выписываются на карточки.

• На столе или доске выстраивается последовательность из «ведерок» для задач различного размера.

• Команда выбирает по очереди 3-5 произвольные карточки с задачами и оценивает их в ходе открытого обсуждения сравнивая и выстраивая их друг относительно друга.

• Задачи помещаются в соответствующие «ведра» задавая общий масштаб и ориентиры для последующих оценок.

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

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

Данный метод (в отличие от Покера планирования) может использоваться для быстрой оценки очень большого числа задач (от 50) и с большим количеством участников.

Kanban vs SCRUM

Nexus

Nexus — это фреймворк Кена Швабера, являющийся эволюционным расширением классического скрама для крупных проектов с многокомандной разработкой. Он базируется на тех же привычных scrum-основах: ролях, артефактах и ивентах, дополняя их аналогичными ивентами и артефактами для выявления и управления зависимостями, своевременного обмена информацией и доменными знаниями между командами и удержания фокуса на конечном продукте, а не индивидуальных инкрементах.

Артефакты Nexus

Чтобы видеть целостную картину по продукту, Product Backlog всегда сохраняется в единственном числе, как и инкремент. В Nexus нет командных Sprint Review, и результатом спринта является сумма всего, сделанного командами — Integrated Increment по продукту. Помимо Sprint Backlog, добавляется новый артефакт — Nexus Sprint Backlog, который является набором фич для всех команд с указанными между ними зависимостями — своеобразным общим планом спринта, — и используется для отслеживания прогресса и ежедневного перепланирования по общему инкременту.

Definition of Done формируется NIT (Nexus Integration Team), пересматривается и поддерживается в актуальном состоянии после каждой ретроспективы. Команды могут дополнительно создавать свои DoD, но правила должны быть строже, чем у общего.

Церемонии Nexus

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

Событие проходит в несколько этапов: 

• Cперва NIT (Nexus Integration Team) разбивает содержимое бэклога на мелкие и независимые части до уровня, когда одна команда может закончить фичу за один спринт.

• Затем выявляются и визуализируются все зависимости между фичами и командами. На этом этапе NIT определяет своеобразную «дорожную карту» фич и зависимостей: что и какой командой будет сделано, в каком спринте.

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

Планирование в Nexus также проходит этапами:

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

• Дальше команды продолжают планирование в индивидуальном порядке, и результаты планирования по всем командам вносятся в Nexus Sprint Backlog.

Помимо Daily Scrum для каждой команды, добавляется Daily Scrum для NIT — для ежедневного перепланирования оставшейся работы по общему инкременту.

Классические три вопроса скрама для интеграционной команды трансформируются в:

• Что было успешно интегрировано до сегодняшнего Daily Scrum?

• Какие новые зависимости обнаружили?

• Какую информацию нужно распространить среди команд сегодня?

Информация, полученная в ходе Nexus Daily Scrum, используется для обсуждения на командных Daily Scrum.

Nexus Retrospective состоит из трёх частей:

• NIT определяет проблемы, затронувшие более одной команды, и передает их как дополнительную входную информацию для командной ретроспективы.

• Командная ретроспектива, на которой обязательно принимаются во внимание общие проблемы, определённые на первом этапе

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

Стоит отметить, что длина спринтов у команд в Nexus может отличаться, но должна быть кратной (например, 1, 2 и 4 недели или 1 и 3 недели), чтобы пересекаться на общем планировании, спринт ревью и ретроспективе.

Роли в Nexus

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

Эта группа участников состоит из выбранных представителей команд, которые озвучивают интересы команды. Если рабочее время участников делится между NIT и командой разработчиков, то более приоритетна работа в Nexus Integration Team.

Состав интеграционной команды может меняться по необходимости.

Масштабирование

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

Nexus предполагает работу над одним продуктом 3-9 команд. Существует еще Nexus+, представляющий собой следующий уровень надстройки над фреймворком (Nexus для Nexus-а), но стоит трижды подумать, прежде чем его применять. В какой-то момент количество времени, уходящее на менеджмент зависимостей, перевешивает пользу от добавления новых команд.

Product Owner отвечает за верхнеуровневое видение продукта, за стратегию, приоритезацию и определение ценности. В независимости от масштаба проекта, существует только один бэклог и один PO на продукт. Он или она может иметь помощников по ежедневными задачами: описывать критерии истории, разъяснять командам детали, обращаться за помощью к экспертам в какой-то доменной области. Но финальное слово по приоритезации остаётся за Product Owner.