Апокриф SCRUM

Предисловие: святотатство над Scrum

И эти люди запрещают мне ковыряться пальцем в носу?

Из одного старого анекдота

Не так давно я решил приобщиться к опыту, изложенному в книге Мери и Тома Попендрик «Бережливое производство программного обеспечения». В этой книге авторы постарались провести анализ лучших практик наиболее передовых организаций-разработчиков программного обеспечения и сформировали прикладные рекомендации по внедрению принципов бережливости в программные проекты. Полезность книги подтверждали предисловия-рекомендации двух апостолов основоположников Agile – Кента Бека (ХP, TDD ) и Джеффа Сазерленда (Scrum). «Помимо моей компании,PatientKeeper, – отметил Джефф Сазерленд, – я использовал процедуры и процессы, описанные в этой книге для обучения специалистов-практиков по всему миру ».

Методика Story Points , призванная убирать противоречия в восприятии оценки разработчиком и менеджером, в моей голове породила больше вопросов, чем ответов. Несмотря на многочисленные доказательства успешного успеха StoryPoints, топ-менеджеры которые попадаются на моих проектах не хотят видеть прогнозы о предполагаемой трудоемкости в собако-единицах. В итоге совещания с представителями топ-менеджмента сводятся к попыткам ответа на два вопроса: сколько надо еще денег (или сотрудников определенной квалификации) и в какие сроки работа будет завершена.

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

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

По мотивам

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

Будущее Scrum: параллельная конвейеризация спринтов в сложных проектах

Аннотация

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

· Метод MetaScrum для координации релизов.

· Спринты переменной продолжительности.

· Перекрывающиеся спринты для одной команды.

· Предварительная подготовка бэклога продукта.

· Ежедневные встречи Scrum of Scrums , а также автоматизация управления и интеграцией продукта.

· Формирование журнала отставания и журнала спринта с отчетами в масштабе реального времени.

· Менее 60 секунд на одного разработчика и менее 10 минут для ScrumMaster – ограничение на ежедневные трудозатраты сотрудников для формирования отчетности по текущему состоянию производственного процесса в условиях, когда проектная команда обеспечивает несколько десятков выпусков корпоративных продуктов в год.

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

1. Эволюция Scrum

Эволюция рождается как естественный ответ на вызовы окружающей среды. На 2005 год в Scrum-сообществе насчитывается более 2000 сертифицированных Scrum-мастеров и десятки тысяч завершенных проектов. Это позволяет провести комплексный анализ результатов применения Scrum, который может помочь в совершенствовании дальнейшей деятельности. В частности анализ, что именно из того, что вы сделали вчера, сработало (оценка опыта Scrum), что имеет смысл делать завтра (эволюция Scrum) и что блокирует развитие (уточнение ограничений Scrum). Одним из факторов, повлиявших на создание процесса разработки Scrum как одного из направлений Agile, стала статья Хиротака Такеучи и Икудзиро Нонака о разработке новых продуктов в Японии в журнале Harvard Business Review [21]. Ключевым компонентом их публикации была диаграмма, показывающая разработку продукта, разделенную на отдельные этапы (Тип A), слегка перекрывающиеся фазы (Тип B) и совмещающую все фазы разработки (Тип C). Авторы рассматривали разработку продукта типа А, реализованную в NASA, как устаревший процесс. Fuji-Xerox отказалась от подхода NASA в пользу процесса организованного по типу B, который они назвали Sashimi, в котором реализация задач беклога совмещалась с проектированием задач на следующий этап. Процесс разработки по типу C был реализован в Canon и Honda. Авторы статьи рассматривали типы B и C как подход, при котором несколько этапов разработки продукта выполняются одновременно. Они рассматривали производственный процесс по принципу «все и сразу» (all-at-once) как аналог командной работы при игре в регби, когда мяч может пасоваться не только вперед, но и назад.

После обсуждения отличительных признаков различных типов Scrum с сертифицированными Scrum-мастерами на семинарах Scrum Alliance и с командами разработчиков Microsoft, Yahoo, Ariba, Adobe, GE Healthcare и других компаний, выяснилось, что диаграмма на рисунке 1 может быть применена к более высокому уровню понимания трех типов Scrum. Уровню, выходящему за рамки, обозначенные Такеучи и Нонака.

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

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

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

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

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

2. Эволюция Scrum на практике

Эволюция Scrum в пяти компаниях в период с 1993 по 2001 год была описана ранее [16, 17]. Здесь мы сосредоточимся на продолжающейся эволюции Scrum на основе опыта, накопленного в компании PatientKeeper, Inc. В 2000 году в этой компании мы впервые автоматизировали решение для Scrum типа B.

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

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

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

Ежедневные встречи Scrum of Scrum стали нормой. К 2003 году мы организовали еженедельные встречи MetaScrum со всеми заинтересованными стейкходлдерами для оценки качества запланированных релизов. Результатом стали поставки кода в промышленную эксплуатацию для нескольких корпоративных клиентов в рамках каждого спринта. Выпуски обновлений с решением инцидентов стали еженедельными. Выпуски версий с уточненными функциональными возможностями обеспечивались ежемесячно. Выпуски версий с новыми функциями – ежеквартально. В 2004 году было завершено, установлено и запущено на объектах клиентов более 45 корпоративных версий производственного программного обеспечения PatientKeeper. Многие из клиентов PatientKeeper — это крупные больничные комплексы, например, Partners (Massachusetts General и Brigham and Women’s Hospital) в Бостоне, Johns Hopkins в Балтиморе и Duke University Health System в Северной Каролине.

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

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

3. Scrum: тип A

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

В Easel Corporation в 1993 году мы первоначально применили Scrum типа А к командам разработчиков программного обеспечения, когда создали первый инструмент объектно-ориентированного проектирования и анализа (OOAD), который включал в себя комплексную поддержку разработки от проектирования до кодирования (в т.ч. при необходимости и реинжениринг ) в среде разработки Smalltalk [18]. Для выпуска первого работоспособного варианта продукта было проведено шесть спринтов, и перерыв между спринтами занимал как минимум неделю, а иногда и две недели. В результате мы могли проводить только 9 спринтов в год, теряя 25% нашей производительности по сравнению с потенциально возможными 12 спринтами в год. Эта потеря времени была реальной проблемой, поскольку выживание компании зависело от поставок инновационного продукта на рынок как можно раньше.

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

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

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

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

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

Преимущества Scrum типа А

• Концентрация внимания к только на задачах спринта.

• Простота внедрения.

• Уточнение и понимание темпов (скорости) разработки команды.

• Четко определенные результаты для каждой итерации.

Недостатки Scrum типа А

• Потеря времени на выход на рынок.

• Нарушение темпов разработки из-за непонимания разработчиками особенностей предметной области автоматизации.

• Потеря производительности (и доли рынка) из-за возникающих задержек.

4. Scrum: тип B

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

Необходимость начинать разработку с адекватными функциональными спецификациями была отмечена Аланом Маккормаком [12], когда он провел оценку эффективности применяемых методов разработки на основе 29 программных проектов компании Hewlett Packard.

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

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

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

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

Функциональная спецификация, которая достаточно полна для начала работы в рамках спринта, позволяет разработчикам начать работу без фальстартов, улучшает поставку функций в рамках спринтов и повышает пропускную способность команды. Хотя фаза внедрения составляет небольшую часть общей трудоемкости программного проекта, наиболее узким местом ресурсов в программном проекте обычно является нехватка опытных разработчиков, чьи компетенции сложно делегировать. Анализ ограничений математически показывает, что самое узкое место должно быть устранено в первую очередь [7] (как при настройке компьютерной системы), а ранняя поставка функциональной спецификации для одного инкремента помогает устранить «бутылочное горлышко» в использовании ресурсов разработки.

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

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

• Автономия команды (team autonomy) — команда Scrum несет (и чувствует) полную ответственность за свой продукт, и никакое внешнее руководство не влияет на план работы команды внутри спринта. Владелец продукта является частью команды Scrum и помогает с решением возникающих вопросов проектирования продукта и его реализацией в рамках спринта.

• Самопреодоление (self-transcendence) — сотрудники выходят за рамки своей зоны комфорта, если этого требуют интересы повышения производительности команды.

• Перекрестное обучение (cross-fertilization) — на регулярной основе организован обмен опытом между работниками проектной команды, поэтому ни один из сотрудников не является «бутылочным горлышком».

Полная загрузка разработчиков, с точки зрения Scrum без определения устойчивого темпа (предсказуемой производительности) разработки, неизбежно отрицательно скажется на моральном духе. Нужно учитывать, что в сложных проектах по разработке новому сотруднику может потребоваться несколько месяцев, чтобы достичь максимальной производительности . Абдель-Хамид [3] показывает с помощью моделирования процессов разработки программного обеспечения, что недостаточное обеспечение ресурсами увеличивает общую стоимость проекта примерно на 25%. Если текучесть кадров составляет 20%, вы фактически недоукомплектованы ресурсами на 20%. Экстраполируя данные Абдель-Хамида, производительность вашей команды разработчиков может снизиться на 15% только из-за этого. Текучка кадров может привести к задержке задач разработки, поскольку для их выполнения необходимо перераспределить специализированные ресурсы, что еще больше снизит производительность. В таких условиях, подавленное состояние сотрудников еще больше снижает темп разработки. Вы можете сократить производительность вдвое из-за «динамических факторов мотивации» Абдель-Хамида.

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

4.1. Подготовка функциональных спецификаций для спринта типа B

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

В PatientKeeper спецификация продукта требует макетов пользовательского интерфейса, требований к данным, описания рабочего процесса от экрана к экрану и описания бизнес-логики, которая должна быть автоматизирована. Это важно, поскольку все новые функции должны быть проверены представителями заказчика перед внедрением. Состав минимально необходимой документация был хорошо представлен в публикации Ивара Якобсена [10], которая может служить отличным руководством. В практике PatientKeeper часто встречаются опытные представители заказчика, которые выступают в качестве владельцев продукта. Хотя некоторые из них не имеют образования в области разработки программного обеспечения, они быстро учатся разрабатывать сценарии использования таким образом, чтобы определять пользовательские требования к программным продуктам PatientKeeper. Кроме того, эти сотрудники являются ориентированными на результат опытными пользователями и устойчивы к аналитическому параличу. Они избегают траты времени на лишнюю документацию, что делает их превосходными Agile Product Owners по своей природе.

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

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

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

4.2. Владелец продукта – это сотрудник Scrum-команды

Первоначальный японский взгляд на разработку продукта Scrum создал кросс-функциональную команду, которая полностью отвечала за продукт [21]. В некоторых компаниях, таких как Individual, владелец продукта присутствовал на каждом собрании Scrum. В других, таких как Easel Corporation, владелец продукта был разъездах большую часть недели, однако всегда присутствовал на пятничных собраниях Scrum [16, 17].

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

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

4.3. Scrum типа B позволяет создавать сверхпродуктивные команды

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

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

Scrum был разработан для достижения гиперпродуктивного состояния сотрудников, чтобы заставить обычных разработчиков функционировать как команда чемпионов. Это происходит только с 10% Scrum и начинает происходить только тогда, когда организация переходит на Scrum типа B. Удвоение производительности команды, которая и так очень продуктивна, приводит к организационному прорыву.

5. Эволюция к типу C

Scrum — это организационная модель [4], разработанная для управления деятельностью, которая крайне непредсказуема. Эта модель полезна в любом контексте, где деятельность требует постоянного изменения направления, непредвиденного взаимодействия со многими участниками и необходимости добавлять новые задачи по мере выполнения работы. Влияние этих факторов усилились в PatientKeeper, когда в 2000 году она получила раунд венчурного финансирования в размере 50 млн долларов.

Было принято решение стать компанией-разработчиком платформы и прикладных приложений, создав программный фреймворк и открытые интерфейсы прикладного программирования (API), которые позволят интегрироваться со многими партнерами по разработке как на бэкенде, так и на фронтенде. Для решения этой задачи была выбрана сервисно-ориентированная архитектура на основе использования веб-сервисов.

В дополнение к архитектуре сервера, которая была основана на Java/XML, был реализован кросс-платформенный программный фреймворк на языке C/C++ для использования на карманных устройствах Palm и Pocket PC. Этот фреймворк предоставлял открытые API и комплект для разработки программного обеспечения, что позволяло сторонним поставщикам и конечным пользователям тесно интегрировать свои мобильные приложения с другими программами, уже доступными на карманном устройстве.

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

5.1. Особенности предметной области

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

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

• первичные данные хранятся в клиническом репозитории данных, зачастую в сторонней системе;

• некоторые или все данные могут кэшироваться в клиническом репозитории PatientKeeper;

• для повышения производительности необходимо было обеспечить массовую многопоточность запросов данных к репозиториям с широким использованием кеширования;

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

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

Команда разработчиков, работающая над этим продуктом, была разделена на команду интеграции бэкенда, команду клинического репозитория, команду сервера промежуточного программного обеспечения, две команды КПК (Palm и Pocket PC) и веб-команду. Тесное взаимодействие этих команд на ежедневном собрании Scrum гарантировало, что все программное обеспечение совместимо между собой.

5.2. Проблемы рынка

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

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

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

5.3. Проблемы планирования ресурсов

Ограничения ресурсов заставили каждого разработчика сосредоточиться на 100% на создании системы. Scrum-мастера и руководители групп совмещали работу как на проектированием, так и на кодированием системы. Администраторов, которые бы занимались только организационными вопросами, на проекте не предусматривалось.

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

Это в свою очередь порождало ряд ключевых вопросов, требующих решения.

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

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

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

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

• Еженедельные и ежемесячные релизы должны гарантировать прирост ценности в интересах решения проблем заказчиков. В году 12 месяцев – это 52 недели. При таких требованиях необходимо обеспечить внедрение в промышленную эксплуатацию 64 релизов в год. Как это сделать возможным?

5.4. Решение – Scrum типа C

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

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

• Ежедневный митап стал основным собранием Scrum.

• Был реорганизован контроль качества

• Процесс сборки стал выполняться чаще и стал более надежным и простым в настройке.

• Значительно улучшилась автоматизация регрессионного тестирования.

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

• Корпоративные процессы стали полностью прозрачными. Все данные были доступны в любое время дня и ночи всем в масштабе реального времени.

Далее в статье описана инфраструктура компании, необходимая для успешного запуска Scrum типа C. Многие детали инструментария и методов в команде разработчиков выходят за рамки этой статьи и описаны в другой публикации [19].

5.4.1. MetaScrum

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

[Перекрывающиеся спринты, выполняемые одной командой разработки]

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

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

Ежеквартальные релизы предназначены для поставки основных функций и могут быть обеспечены только тогда, когда еженедельные и ежемесячные релизы идут по графику. Приоритеты могут меняться в течение квартала из-за изменений на рынке или новых предпочтений клиентов. Крупный партнер, такой как Cerner или GE Healthcare, может предъявить новые требования, запросить увеличение скорости работы или ускорения выпуска релиза.

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

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

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

5.4.2. Организация проектных команд

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

• Что каждая из шести интегрированных команд выполнила за последние 24 часа? Лидер Scrum of Scrums регистрирует, какие задачи были выполнены, и отправляет электронное письмо в компанию сразу после собрания.

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

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

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

Каждый спринт в Scrum типа C приводит к выпуску кода, который добавляет ценность продукта. Поэтому все спринты требуют пристального контроля качества, поскольку программное обеспечение внедряется в непосредственно в промышленную эксплуатацию и удовлетворяет реальные потребности клиентов. Быстрый темп поставки релизов изначально создал узкое место в обеспечении качества (QA). Решением было назначить небольшую команду QA для каждого релиза. Служба контроля качества была расширена до четырех небольших команд по 2-4 человека. Это позволило им работать с командой разработчиков непрерывно над регрессионным тестированием и поставкой четырех наиболее приоритетных релизов, которые являются функционально завершенными, одновременно проводя раннее тестирование кода разработчиков для релизов, находящихся в производстве. Группы QA является частью Scrum-команды и ежедневно отчитываются о текущем состоянии тестирования.

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

5.4.3. Сбор данных о состоянии проекта

Для оценки процесса сбора данных о состоянии задач публикации было проведено исследование работы группы пользователей и фокус-групп, результаты которого были опубликованы [16]. Данных, которые будут использоваться для автоматизации построения стандартных диаграмм сгорания Scrum. Результаты пятнадцатилетних исследований показали, что сотрудники в различных компаниях использовали широкий спектр инструментов отслеживания состояния проекта и ни один из этих инструментов не считался адекватным. Требование 60 секунд для ввода данных подразумевало, что использование приложения по учету будет уже невозможным, если простой запуск этого приложения может потребовать 60 секунд.

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

• Какова первоначальная оценка для этой задачи, если это новая задача?

• Сколько времени вы потратили на эту задачу на данный момент?

• Какой процент выполнения этой задачи на данный момент ?

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

5.4.4. Инструменты для сбора данных и составления отчетов о состоянии проекта

PatientKeeper использует систему отслеживания ошибок GNATS с открытым исходным кодом [14]. Поскольку разработчикам необходимо было использовать систему отслеживания ошибок ежедневно, не было дополнительных временных затрат на внедрение приложения для ввода данных о задачах.

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

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

• первоначальная оценка (initial estimate);

• дни работы;

• % завершения.

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

• оставшиеся дни;

• фактическое время до завершения.

Например, если первоначальная оценка составляет 2 дня и работы не начаты, то оставшиеся время составляют 2 дня. Если разработчик потратил на работу над задачей 1 день и заявляет, что эта задача выполнена на 25%, GNATS рассчитал оставшееся время как 3 дня. Первоначальные оценки автоматически уточнялись в реальном времени в процессе работы над задачей.

Сведения о совокупном объеме оставшейся работы для выпуска релиза мог получить любой человек в компании, имеющий доступ к GNATS. В PatientKeeper это все сотрудники компании. Оставшиеся дни для всех задач, назначенных для релиза, суммируются для расчета совокупной трудоемкости незавершенных задач бэклога - итогового числа, отображаемого на диаграмме выгорания Scrum. Поскольку в системе есть тысячи задач, и любая затронутая задача обновляется, применение статистической регрессии к среднему значению делает сводные данные по совокупному времени до релиза очень точными. Он достигает Святого Грааля бухгалтерии программного обеспечения, микрорасчета каждой деятельности в компании [13], не посвящая в это разработчиков, за исключением демонстрации очень точной диаграммы сгорания.

Этот подход можно обобщить для отслеживания задач разработки в любой системе отслеживания ошибок. В идеале система отслеживания интегрируется с системой контроля версий. Такие инструменты, как Trac [2], интегрируются с системой управления версиями кода Subversion [1] и поддерживают комплексную интеграцию разработки, отслеживания ошибок и управления кодом. Это текущие кандидаты на обновление системы GNATS.

5.5. Scrum типа C: отличительные черты

Как отмечено в нашей публикации Pattern Languages ​​of Program Design [4], «[планируемые трудозатраты] очень легко переоценить или недооценить, что приводит либо к простою разработчиков, либо к задержкам в завершении задания. Поэтому лучше в ходе процесса работы чаще контролировать выполнение небольших заданий». Процессы с высокой степенью непредсказуемости не могут использовать традиционные методы планирования проектов (диаграммы Ганта или PERT), поскольку скорость изменения того, что анализируется, выполняется или создается, слишком высока. Вместо этого постоянная переоценка задач предлагает адаптивный механизм, который обеспечивает выборку системных знаний за короткие периоды времени. Scrum-встречи также помогают в создании «предвосхищающей» культуры [22], поскольку они поощряют «продуктивные ценности»:

• повышают чувство коллективной ответственности за выпуск релиза в заданный срок;

• способствуют обмену знаниями;

• поощряют плотную коммуникацию;

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

В Scrum типа C культура срочности, обмена, коммуникации и честности распространяется на всю компанию. «С точки зрения теории сложности [9, 8], Scrum позволяет объединяться сотрудникам, вовлекая их в более тесное сотрудничество, тем самым ускоряя процесс самоорганизации, поскольку он в общих интересах перераспределяет ресурсы через ежедневные встречи Scrum». [4] При распространении Scrum на всю компанию, вся компания самоорганизуется на еженедельной основе. Нижеперечисленные модели поведения становятся обычным явлением.

• Никогда не бывает неожиданного срыва срока выпуска релиза, поскольку проблемы видны задолго до этого срока. Компания самоорганизуется вокруг вопросов, поднятых на совещаниях MetaScrum.

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

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

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

5.6. Scrum типа С: результаты применения

Переход на Scrum типа C для повышения производительности разработки имел далеко идущие последствия для компании, сделав ее более гибкой, более решительной, более адаптивной и более привлекательной для сотрудников. Те же эффекты, которые обычно наблюдаются в командах Scrum, нашли воплощение в работе всей компании. Управление проектами было полностью автоматизировано. Результатом стало управление проектами, основанное на безбумажной отчетности, формируемой в значительной степени без человеческого вмешательства. Выполнение Scrum стало исключительно эффективным, а автоматизированная система отслеживания текущего состояния работ стала критически важной для достижения стратегических целей компании. Диаграммы выработки были преобразованы так, чтобы отразить текущее состояние проекта в целом на одной диаграмме. Для тех, кто знаком с данными, диаграмма, представленная на рис. 4, с первого взгляда дает представление о текущем состоянии проекта для версии 320. Поскольку все задачи вводятся с дискретностью не более 16 часов, а учет факта исправления ошибок обычно занимают менее дня, можно отслеживать совокупную трудоемкость задач, а скорость снижения является высокопредсказуемой относительно даты поставки.

Информация на диаграмме представлена ​​следующим образом.

1. Ромб (синий) — текущая трудоемкость открытых задач — совокупная оставшаяся работа.

2. Треугольник (желтый) — трудоемкость закрытых задач в день — элементы, закрываемые QA каждый день.

3. Звезда (фиолетовый) — общая трудоемкость закрытых задач — совокупное закрытое (по шкале справа).

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

5. X — трудоемкость потока поступления новых задач.

Совокупная трудоемкость закрытых задач, измеряемая на правой шкале, намного выше, чем начальное число измеряемое по левой шкале. Причина этого в том, что QA находит ошибки, часто генерируя несколько задач, которые можно закрыть одним исправлением разработчика. Увеличение количества задач происходит также из-за жалоб клиентов на разные релизы (заявленные дефекты могут относится к более ранним поставкам ПО). Кроме того, разработчики формируют новые задачи по мере того, как они конкретизируют требования технического проекта. Совокупное количество решенных задач является индикатором «протечек» в проекте. Именно поэтому Ф. Брукс в своей публикации [5] отметил, что разработка всегда занимает в три раза больше времени, чем первоначальные оценки.

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

PatientKeeper удалось быстро выйти на рынок и достичь лидерства на рынке дистанционных медицинских услуг [11], выпустив более 45 производственных релизов PatientKeeper Platform в 2005 году для таких крупных предприятий, как Partners Healthcare в Бостоне, Johns Hopkins в Балтиморе и Duke University Health System в Дареме. Gartner Group поставила PatientKeeper на лидирующие позиции в своем «магическом квадранте» для отраслевого сегмента. Ключевую роль в этом успехе сыграло применение в компании Scrum по типу C.

6. Scrum типа С: выводы

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

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

7. Ссылки

[1] Subversion Version Control System. 2005, Tigris.org: Open Source Software Engineering Tools.

[2] Trac Integrated SCM and Project Management. 2005, Edgewall Software Services.

[3] Abdel-Hamid, T.K., The Slippery Path to Productivity Improvement. IEEE Software, 1996. 13(4): p. 43-52.

[4] Beedle, M., et al., SCRUM: A Pattern Language for Hyperproductive Software Development, in Pattern Languages of Program Design, N. Harrison, Editor. 1999, Addison-Wesley. p. 637-651.

[5] Brooks, F.P., The Mythical Man Month: Essays on Software Engineering. 1995: Addison-Wesley.

[6] Cohn, M., Diagram of Simultaneous Overlapping Sprints, J. Sutherland, Editor. 2005, Mountain Goat Software.

[7] Goldratt, E.M. and J. Cox, The goal: a process of ongoing improvement. 2nd rev. ed. 1994, Great Barrington, MA: North River Press. 351 p.

[8] Holland, J.H., Emergence: from chaos to order. 1998, Reading, Mass.: Addison-Wesley. xiii, 258 p.

[9] Holland, J.H., Hidden order: how adaptation builds complexity. 1995, Reading, Mass.: Addison-Wesley. xxi, 185.

[10] Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach. 1992: Addison-Wesley .

[11] Kleinberg, K. and T. Berg, Mobile Healthcare: Applications, Vendors and Adoption, in Strategic Analysis Report, R-17-7369, Editor. 2002, Gartner Group. p. 1-44.

[12] MacCormack, A., et al., Exploring Tradeoffs Between Productivity and Quality in the Selection of Software Development Practices. IEEE Software, 2003(Sep/Oct): p. 78-85 .

[13] McCarthy, W.E., The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review, 1982. LVII(3): p. 554-578 .

[14] Osier, J.M., B. Kehoe, and Y. Svendsen, Keeping Track: Managing Messages with GNATS, The GNU Problem Report Managment System Version 4.0. 2002, Free Software Foundation .

[15] Salitsky, B., Scrum Burndown Chart, Release 3.20. 2005, PatientKeeper, Inc.: Brighton, MA.

[16] Schwaber, K. and M. Beedle, Agile software development with scrum. Series in agile software development. 2002, Upper Saddle River, NJ: Prentice Hall. xvi, 158 p.

[17] Sutherland, J., Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies. Cutter IT Journal, 2001. 14(12): p. 5-11.

[18] Sutherland, J., Agile Development: Lessons Learned from the First Scrum. Cutter Agile Project Management Advisory Service: Executive Update, 2004. 5(20): p. 1- 4.

[19] Sutherland, J., Future of Scrum: Pipelining of Sprints in Complex Projects with Details on Scrum Type C Tools and Techniques. 2005, PatientKeeper, Inc.: Brighton, MA. p. 1-27.

[20] Takeuchi, H. and I. Nonaka, Hitotsubashi on Knowledge Management. 2004, Singapore: John Wiley & Sons (Asia) .

[21] Takeuchi, H. and I. Nonaka, The New New Product Development Game. Harvard Business Review, 1986(January-February) .

[22] Weinberg, G., Quality Software Management Vol. 4: Anticipating Change. 1997: Dorset House .

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

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

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

По всей видимости, спонсоров проекта перестает удовлетворять прогнозирование трудозатрат и velocity в StoryPoints. Когда вам поручили проект на 50 M$, заказчик хочет понимать, каким образом эти деньги тратятся и к каким срокам будут получены результаты. Как говорил один классик (см. эпиграф к послесловию), учет расхода основного ресурса (рабочего времени) и контроль текущих результатов работы становятся ключевыми факторами успешного успеха.

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

Так, например, в то время, когда писалась статья (2005 год), учет трудозатрат в компании PatientKeeper проводился с дискретностью в 1 день. С другой стороны, мой личный опыт говорит о том что выбранная единица измерения для учета трудозатрат несколько крупновата. И это не только мое мнение.

Источник

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

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

Основной вывод, который я сделал для себя после прочтения статьи, это то, что с ростом размеров проекта принципы Agile волшебным образом все больше становятся похожими на принципы, изложенные в ГОСТ 34-й серии. Или, может, если наш советский ГОСТ перевести на английский язык он станет похож на SAFe или LeSS Huge ?

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

А вы что об этой ереси этом думаете? Или сразу на костер?

По мотивам