Бережливость Scrum

David Starr. Дэвид Старр является главным специалистом по программному обеспечению для сайта Scrum.org, где он направляет свои усилия на улучшение профессии разработчика программного обеспечения. Он также основал сетевое техническое сообщество ElegantCode.com.

Июль 2012

Проверьте рациональность платформы Scrum, а также рассмотрите различные способы помочь Scrum-командам повысить рациональность.

Применение

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

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

Общие сведения

Методология Scrum чрезвычайно популярна; из команд, заявляющих о применении гибких методов разработки, 92% говорят, что используют именно Scrum[1]. После достижения успеха, что позволяет сделать Scrum, многие команды стремятся усовершенствовать свои методики за пределы базовой платформы Scrum. Данная статья исследует расширение платформы Scrum с помощью техник бережливого производства и канбан, с использованием общего подхода Кайдзен, или непрерывное улучшение.

Scrum

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

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

Методология Scrum описана в справочнике по Scrum, где документированы роли, артефакты и события, существующие в Scrum. Руководство по Scrum обеспечивается авторами Scrum и доступно онлайн на Scrum.org.

Бережливо

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

При применении к разработке программного обеспечения, бережливый подход представлен следующими семью принципами, впервые опубликованными в книге, Lean Software Development: An Agile Toolkit[2].

1. Устранить отход

2. Ускорьте обучение

3. Решить как можно позднее

4. Доставить как можно скорее

5. Наделение команды полномочиями

6. Встроить целостность в

7. Видеть целое

Применение этих принципов к работе по доставке продукта программного обеспечения не является конечной целью. Человеку не говорят "работай бережливо"; вместо этого человек использует бережливые принципы для принятия решений и выбора методик, которые позволят улучшить систему в целом. Например, методика TDD (разработка на основе тестов) обеспечивает целостность программного обеспечения путем его проверки в точке создания, таким образом поддерживая рациональный принцип обеспечения целостности в процессе создания.

Канбан

Одной из методик, берущих начало в бережливом мышлении, является канбан[3], которая предполагает использование бережливого мышления в виде формального метода, направленного на сокращение непроизводительных затрат, поставку "точно в срок" и недопущение слишком большой нагрузки на тех, кто выполняет работу. В отличие от Scrum, канбан – не итеративный и добавочный метод; канбан отталкивается не от итераций, а от 5 основных действий.

1. Визуализация рабочего процесса

2. Ограничить Выполняемую работу НЗП

3. Управление потоком

4. Сделайте явными политики процесса

5. Улучшать совместными усилиями

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

Scrum и кайдзен

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

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

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

Взгляд на Scrum через призму бережливости

Платформа Scrum состоит из следующих ролей, артефактов и событий. Если вы не знакомы с базовой платформой Scrum, сначала прочтите руководство по Scrum.

Роли	Артефакты	События
Владелец продукта Координатор Scrum Команда разработки	Отставание продукта Отставание спринта Increment	Спринт Планирование спринта Ежедневное использование Scrum Разбор спринта Ретроспектива спринта

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

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

События

За исключением спринта, который является контейнером для всех остальных событий, события Scrum по сути просто собрания. Бережливый подход обычно рассматривает совещания как лишний элемент, который надо быть исключенным.

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

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

Событие	Проверено	Принято
Учет невыполненной работы	Отставание продукта	Отставание продукта
Планирование спринта	Отставание продукта Предыдущие приращения	Цель спринта Отставание спринта
Ежедневное использование Scrum	Отставание спринта Движение к цели спринта	Отставание спринта Ежедневный план
Разбор спринта	Последнее приращение Последний спринт Отставание продукта	Отставание продукта Другие долгосрочные планы
Ретроспектива спринта	Последнее приращение Последний спринт Сама Scrum-команда Технические методики	Поведение Scrum-команды Технические методики Практики управления работой, используемые в пределах Scrum

Артефакты

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

Отставание продукта

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

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

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

Отставание спринта

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

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

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

Increment

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

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

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

Роли

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

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

Уникально в Scrum— роль Координатор Scrum, которая описывается в руководстве по Scrum следующим образом:

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

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

К более бережливому Scrum

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

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

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

Устранение отхода

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

1. Неиспользуемый код или функции

2. Дефекты, которые ведут к переработке

3. Задержки или время, затраченное на ожидание чего-либо

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

5. Очень подробно описанные требования

6. Недостаточные требования

7. Медленный или слабый обмен информацией

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

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

Сценарий

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

Бережливый подход

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

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

Рассмотреть вопрос немедленно

Отходы невыполненной работа

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

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

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

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

Ограничение выполняемой работы

Сценарий

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

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

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

День 1	День 4
День 9	День 14
День 17	День 20

Координатор Scrum поделился этими фото с группой разработки. Некоторые моменты были очевидны, например:

• Обычно количество выполняемых задач превышает число членов в команде разработки.

• На второй день разработчик перетянул все все задачи по компоненту С в состояние "Выполняется" и оставил их там на время спринта.

• Функция B не принималась в работу до завершения спринта и не была закончена.

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

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

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

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

Бережливый подход

Во время следующих ретроспективных собраний по спринту команды координатор Scrum объяснил идею ограничения НЗП по команде разработки, которая решила использовать этот метод. Команда разработчиков решила реализовать три новых правила для уменьшения НЗП в следующем спринте:

1. Функции в списке невыполненных работ спринта реализуются в порядке сверху вниз.

2. Одновременно может выполняться не более 3 элементов. Если четвертый элемент введен в выполнение, команда приостановится, чтобы определить, почему в системе возникает узкое место.

Координатор Scrum сфотографировал еще раз в ходе следующего спринта. Некоторые фотографий представлены ниже.

День 2	День 8
День 12	День 20

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

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

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

3. Сложность одновременной координации изменений в множестве различных областей кода снизилась значительно. До такой степени, что производительность команды разработчиков действительно заметно повысилась.

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

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

Сокращение времени ожидания

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

• Разрешение сделать что-либо

• Долгий процесс для завершения

• Передача от другой рабочей группы или лица

• Тесты для запуска или проверка, которую требуется выполнить

• Доступ к необходимому ресурсу

• Сотрудничество с человеком, не являющимся членом команды

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

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

Сценарий

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

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

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

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

На следующем рисунке показано типичное управление конфигурацией во время спринта. Команды разработки создают свои собственные ветви разработки в начале каждого спринта. Они объединяют их код в конце недели 2. В течение недели 3 группы разработки обслуживают запросы команды интеграции согласно необходимости.

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

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

Бережливый подход

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

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

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

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

1. Каждая команда разработки ограничивает НЗП до одной функции на определенный момент времени.

2. Функция остается незавершенной, пока она не интегрирована в основную строку кода.

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

Результирующая работа показана на следующем графике.

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

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

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

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

Откладывание обязательства

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

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

Сценарий

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

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

Бережливый подход

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

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

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

Визуализация рабочего процесса

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

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

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

На Эту обычную форму визуализации рабочего процесса сильно влияет рекомендация Scrum использовать кроссфункциональные группы разработки. Фокус на универсальных командах разработки является определяющей характеристикой платформы Scrum. Универсальная команда содержит все компетенции для обеспечения полного приращения работающего программного обеспечения в каждом спринте. Члены команды выполняют много действий по разработке ПО одновременно.

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

Сценарий

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

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

Бережливый подход

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

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

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

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

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

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

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

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

Построение целостности в

Многие методы построения ПО фокусируются на целостности в процессе создания. Шаблоны разработки программного обеспечения, разработка на основе тестирования, рефакторинг и парное программирование — все они направлены на повышение качества ПО во время его создания. Использование методов, которые повышают качество в начале процесса создания гарантирует, что команды не полагаются проверку качества после завершения, чтобы "проверить качество потом".

Сценарий

Группа разработки экспериментировала с методами разработки на основе тестирования и успешно использует выражение Given/When/Then условий приемки в модульных тестах, созданных разработчиками во время разработки.

Формат критериев принятия "с учетом/если/тогда"
С учетом <некоторого начального контекста> Когда <какое-то действие происходит> Затем <получается>

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

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

Бережливый подход

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

1. Специалисты по тестированию создают условия приемки не как документы Microsoft Word, но как автоматические тесты с негативным результатом, которые не имеют внутреннюю реализацию.

2. Новые автоматические тесты будут выполняться ежедневно в 5:00 и 15:00, формируя отчет оп пройденным и непройденным тестам. Вновь созданные тесты всегда завершаются с ошибкой.

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

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

5. Функция остается невыполненной, пока тест не будет пройден.

6. Все тесты должны проводиться в конце спринта.

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

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

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

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

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

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

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

Ссылки

1. West, D. (2011). XXXXX. Исследование Forrester

2. Poppendieck, M. P. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.

3. Anderson, D. (2010). Канбан. Успешное постепенное изменение для вашей технической компании. Blue Hole Press.