Привет, Хаброжители! Любой компании хочется добиться большей эффективности разработки ПО, ведь это напрямую влияет на прибыль. Большая часть литературы по Agile ориентирована на крупные компании с высокими темпами роста, но как быть, если ваша компания находится не на переднем фланге ИТ? Хорошая новость в том, что каждая организация может улучшить производительность, и эта книга поможет найти конкретные пути и решения, позволяющие извлечь максимальную выгоду от Agile-методов. «Я не евангелист Agile. Я сторонник того, что работает, и противник того, что много обещает, но не приносит результатов. В этой книге методология Agile представлена не как движение, которое требует повышенной сознательности, а как набор специальных управленческих и технических методов, эффект и взаимодействие которых доступны для понимания любому бизнесмену или айтишнику. Энтузиасты Agile могут раскритиковать эту книгу за то, что она не пропагандирует передовые методы Agile. Но в этом и смысл — акцент на практических методах, доказавших свою эффективность. История Agile полна идей, которые удалось успешно реализовать паре энтузиастов в некоторых организациях, но которыми невозможно пользоваться всем остальным», — говорит Стив Макконнелл. Новая книга Стива Макконнелла, автора легендарных книг Code Complete и Software Estimation, объединяет реальный опыт сотен компаний. Воспользуйтесь простым и понятным руководством по современным и самым эффективным методам Agile.

Ещё более эффективное выполнение проектов

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

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

Терминология значительно различается. Некоторые компании считают, что понятие «релиз» — это синоним слова «проект». Другие думают, что понятие «релиз» относится к последовательной разработке, поэтому прекратили его использовать. Третьи определяют понятие «функция» как объем работ, рассчитанный на 3–9 человек и 1–2 года. В этой главе под словом «проект» я буду иметь в виду любые из перечисленных видов работ, то есть работу некоторого количества сотрудников в течение длительного времени.

Ключевой принцип: небольшие размеры проектов

За последние 20 лет наиболее известны случаи успешного применения Agile в небольших проектах. Agile первые 10 лет своего существования уделял большое внимание тому, чтобы проекты были небольшими, то есть 5–10 человек в команде (например, 3–9 разработчиков, владелец продукта и скрам-мастер). Акцент на небольшом размере проектов очень важен, потому что с небольшими проектами успешно справиться легче, нежели с крупными, как показано на рис. 9.1.


Каперс Джонс уже 20 лет постулирует, что мелкие проекты чаще завершаются успешно, чем крупные [Джонс, 1991; 2012]. Я обобщил большинство исследований о зависимости успешности проектов от размера в своих книгах «Совершенный код» [Макконнелл, 2004; СПб.: Питер, 2007] и Software Estimation: Demystifying the Black Art [Макконнелл, 2006].

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

Следовательно, чем крупнее становится проект, тем больше допускается ошибок (рис. 9.2). Это говорит не просто о том, что общее количество ошибок растет, а о том, что в крупных проектах несоизмеримо больше ошибок!

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


Требуется также больше усилий для устранения ошибок. Следовательно, как показано на рис. 9.3, более мелкие проекты отличаются большей производительностью на человека, но чем больше размер проекта, тем сильнее падает производительность. Это явление известно как «издержки масштаба».


Эту обратную зависимость между размером и производительностью тщательно исследовали и проверяли на протяжении более 40 лет. Фред Брукс рассуждал на тему издержек масштаба при разработке ПО в первом издании своей книги «Мифический человеко-месяц» [Брукс, 1975; СПб.: Питер, 2021]. Работа Ларри Патнэма по оценке издержек при создании ПО подтвердила наблюдения Брукса [Патнэм, 1992]. Исследование модели издержек разработки (Cocomo) эмпирически подтвердило существование издержки масштаба дважды — в исследовании конца 1970-х годов и в обновленном исследовании конца 1990-х [Боэм, 1981; 2000].

Вывод таков: чтобы максимально увеличить вероятность успешного выполнения проекта по Agile, старайтесь сохранять небольшие масштабы проекта (и команды).

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

Ключевой принцип: короткие спринты

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

Короткие спринты снижают количество промежуточных требований и улучшают реагирование на новые требования

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

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


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


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

Короткие спринты обеспечивают большую оперативность при работе с клиентами и заинтересованными сторонами

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

Короткие спринты укрепляют доверие стейкхолдеров

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

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

Короткие спринты помогают сократить время на эксперименты

В контексте «Запутанные» по Cynefin проблемы нужно сначала исследовать, прежде чем получится понять весь объем работ. Такие исследования нужно характеризовать так: «Чтобы получить ответ на тот или иной вопрос, сделайте наименьшее необходимое количество работы». К сожалению, закон Паркинсона гласит, что работа занимает весь доступный объем времени. А до тех пор, пока у команды не разовьется железная дисциплина, решение вопроса, если на него выделен месяц, и займет ровно месяц. Но если есть всего две недели, то чаще всего и решение вопроса занимает две недели.

Короткие спринты позволяют вовремя обнаружить издержки и риски

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

Короткие спринты способствуют подотчетности команды

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

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

Короткие спринты способствуют подотчетности

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

Короткие спринты способствуют автоматизации

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

Короткие спринты чаще доставляют чувство удовлетворенности

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

Короткие спринты. Резюме

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

Планируйте в зависимости от скорости выполнения задач

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

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

Оценка размера бэклога продукта

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

Расчет скорости

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

Планирование спринта

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

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

Отслеживание релиза

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

Учет влияния изменений процесса, состава команды и других изменений

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

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

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

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

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

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


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

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

Вертикальные срезы обеспечивают более тесную обратную связь

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

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

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

Вертикальные срезы позволяют получить большую ценность для бизнеса

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

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

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

Что нужно команде для использования вертикальных срезов

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

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

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

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

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

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

Последствия технического долга

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


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

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


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


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

Погашение технического долга

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

Виды долга и как с ним справиться

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

• Намеренный долг (краткосрочный). Долг, полученный из тактических или стратегических соображений, например выпуск чувствительного ко времени релиза в срок.
• Намеренный долг (долгосрочный). Долг, полученный из стратегических соображений, например по причине изначальной поддержки единственной платформы вместо поддержки кросс-платформенности.
• Непреднамеренный долг (недобросовестность). Долг, который по воле случая возникает из-за низкокачественных методов разработки. Такой вид долга замедляет работу как в настоящем, так и в будущем, поэтому его нужно избегать.
• Непреднамеренный долг (добросовестность). Долг, который возникает случайно из-за естественных ошибок при разработке ПО («Наш подход к проектированию не так хорошо сработал, как мы планировали» или «Новая версия платформы показала серьезные недочеты проектирования»).
• Унаследованный долг. Долг, унаследованный новой командой от старой кодовой базы.

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


Польза обсуждения технического долга

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

Выстройте структуру работы во избежание выгорания

Пуристский взгляд на Agile предполагает одинаковую длительность спринтов (известную как «общая каденция»). Если команда хорошо переносит общую каденцию, нет смысла вносить изменения. Общие каденции позволяют упростить расчет скорости и других факторов при планировании спринта.

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

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

Одно из противоядий от усталости после спринтов — изменение по необходимости длительности спринтов. Системный способ его обеспечить — использовать шаблон 6 ? 2 ? 1, шесть спринтов по две недели плюс один спринт длительностью одну неделю, в сумме 13 недель, которые как раз составляют один квартал.

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

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

Прочие соображения

Внепроектная разработка ПО

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

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

Рекомендации
Изучайте:

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

Дополнительные ресурсы

• [Фред Брукс, 1975]. Мифический человеко-месяц. Несмотря на то что книга не нова, она содержит классическое обсуждение трудностей, возникающих на пути к успеху при выполнении крупных проектов.
• [Стив Макконнелл, 2019]. Understanding Software Projects Lecture Series. Серия Construx OnDemand. Сетевой ресурс (2019 год). ondemand.construx.com. В этих лекциях подробно обсуждается взаимосвязь размера проекта и динамики разработки ПО.
• [Кеннет Рубин, 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. В этом всеобъемлющем руководстве по Скраму дано объяснение, как на основе единиц сложности и скорости команды планировать спринты и релизы.
• [Филипп Крухтен и др., 2019]. Managing Technical Debt. Это во всех отношениях полноценное и продуманное рассуждение на тему технического долга.

» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — Agile

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.