Книга: Софт за 30 дней. Как Scrum делает невозможное возможным
Назад: 6. Scrum на уровне проекта
Дальше: 8. Scrum на уровне организации
7. Развитие возможностей Scrum
Шаг на следующую ступень в организации – переход Scrum с уровня проекта на уровень студии разработки программного обеспечения. Как только студия создана, у организации появляется постоянная база для быстрого запуска Scrum-проектов по разработке программного обеспечения.
Студия разработки программного обеспечения – это новая, обособленная организация внутри большой организации. Некоторые организации используют студии для разработки всех своих проектов. Другие – для разработки только сложных, больших и рискованных проектов. Как и Scrum-PRN, этап студии позволяет избежать трудностей и потенциального провала по внедрению на уровне всей организации.
Студию разработки программного обеспечения иногда также называют фабрикой разработки, хотя фабрика предполагает выполнение повторяющейся, стандартизированной, простой работы, в то время как разработка программного обеспечения отнюдь не такая работа.
Студия – научающаяся организация
Большинству организаций, которые адаптируют Scrum, требуется несколько лет, чтобы в полной мере начать пожинать плоды наиболее значительных его преимуществ. С самого начала их производительность увеличивается, а проекты становятся более управляемыми, чем до этого. Однако выгоды от улучшения качества, ценности и интеллектуального уровня достигаются позже. Организация нуждается в систематическом применении знаний, получаемых в предыдущих проектах. Студия – то место, где обретаются знания для быстрого накопления и создания устойчивого преимущества.
Вся работа в студии основывается на Scrum. Каждый разрабатываемый проект содействует накоплению знаний, квалификации, производительности и ценности всех последующих проектов. Чем больше проектов произведено в студии, тем больше накапливается опыта, знаний и технических средств. В результате каждый последующий проект становится более продуктивным и создает больше ценности.
Студия имеет собственную культуру, включающую изменения и поддержку, необходимую для разработки программного обеспечения и управления с использованием Scrum. Каждый, кто хочет использовать эту культуру для разработки систем или продуктов, может это сделать, однако он должен изучить эти культурные нормы и подчиниться им. Только люди, которые хотят применять Scrum, используют студию. Остальные продолжают делать работу старым способом.
Менеджер студии
Первый шаг – поиск сотрудника, который создаст студию по разработке программного обеспечения и будет ею управлять. Менеджер студии также и Scrum-мастер, в его функции входит поддержка работы студии с теми техническими средствами, которые есть в его распоряжении. Менеджер студии обязан:
• иметь за плечами несколько лет опыта работы Scrum-мастером, менеджером в Scrum-среде;
• понимать процесс разработки программного обеспечения;
• иметь квалификацию и опыт по внедрению изменений и упрощению процедур;
• обеспечивать обучение и инструктаж разработчиков в студии;
• быть уверенным, что Scrum-мастера, работающие над проектами, хорошо делают свою работу;
• помогать оптимизировать результаты проектов;
• постоянно совершенствовать технические средства студии, чтобы последующие проекты становились более экономичными и эффективными.
Менеджер студии изучает индустрию программного обеспечения для поиска лучших, наиболее экономически оправданных методов автоматизированных средств и программного обеспечения. Приложения и инструменты могут варьироваться от элементарных до сложных, в зависимости от того, как долго работает и улучшается студия.
Цель менеджера студии – обеспечить рабочую обстановку с максимально возможной стоимостью. Как минимум цель студии – сделать более легким запуск новых Scrum-проектов.
Обучение и условия использования
Обучение чему-то отличающемуся от привычного, такому как Scrum, может быть трудным. Люди должны иметь желание учиться новому подходу к управлению и разработке программного обеспечения. Обучение будет успешным только для тех, кто хочет и стремится изучить и потратить на это усилия. Если департамент планирует проводить все свои проекты в студии разработки, все, кто связан с этим, обязаны научиться работать по-другому.
Пользователи, столкнувшиеся со Scrum впервые, должны пройти двухдневный базовый курс обучения. Они обучаются Scrum и теории и принципам, лежащим в его основе. Они проходят через многочисленные симуляции различных ситуаций, пока не поймут ощущение и движение Scrum-проекта. Устанавливаются основные правила, расписание мероприятий, длина спринта и тому подобное.
Способы работы оформляются и объясняются. Новые техники могут потребоваться для следующего:
• увеличение вклада в работу команды по сравнению с личной производительностью;
• создание структуры отчетности и проверки производительности;
• разрешение конфликтов;
• урегулирование отношений с проблемными членами команды;
• преодоление препятствий и потребностей.
Также проводится обзор оборудования и технических средств студии, чтобы члены команды знали, какие имеются средства, как их использовать и как получить помощь.
Проводятся мероприятия по тимбилдингу, члены команды учатся работать друг с другом, занимаются упражнениями по совместному решению проблем и учатся преодолевать конфликты, которые нередко случаются в самоорганизованных командах, где различные идеи имеются в большом количестве.
Сотрудники, участвующие в Scrum-командах, подписывают соглашение об условиях использования технических средств студии. Соглашение обеспечивает их пониманием того, чего от них ждут. На рисунке 7.1 перечислены типичные условия использования Scrum.
Условия сотрудничества в рамках студии
1. Каждый проект должен быть основан на процессе Scrum и его принципах: эмпиризме, накоплении знаний и самоорганизации.2. Каждый проект будет реализован отдельной Scrum-командой, состоящей из владельца продукта, Scrum-мастера и не более чем девяти разработчиков.3. Scrum-мастер должен иметь опыт управления Scrum-проектами. Если его опыта недостаточно, он должен не стесняться принимать помощь и проходить обучение у старших Scrum-наставников.4. Владелец продукта будет активно сотрудничать со Scrum-командой по вопросам формулирования требований, оценке проделанной работы, оценке инкремента, а также будет оптимизировать ценность проекта на основе постоянных практических проверок и тестов.5. Scrum-команда (команда разработки) будет состоять из разработчиков программного обеспечения, обладающих всеми навыками, необходимыми для создания инкремента потенциально пригодной к использованию функциональности, основываясь на требованиях владельца продукта.6. На протяжении всего проекта внешние связи и подчиненность должны быть приостановлены.7. Каждый инкремент должен соответствовать определению «прозрачности» и «законченности».8. Scrum-команда будет использовать современные методы разработки и технические инструменты, предоставляемые студией, а также по необходимости проходить обучение по их использованию.9. Проект должен соответствовать всем политикам и стандартам студии.10. Члены Scrum-команды по возможности должны находиться на территории студии и работать над проектом полный рабочий день.11. Scrum-команда имеет право и возможность пользоваться всеми преимуществами и удобствами студии, помогающими в разработке.12. Члены Scrum-команды будут способствовать возрастанию общих знаний, основанных на опыте их работы над проектом, а также будут делиться этим знанием с другими командами.ФИО ______Дата ______Рис. 7.1. Условия сотрудничества в рамках студии
Когда новые команды разработки запрашивают использование студии, оцениваются их подготовка, опыт и квалификация. Их проекты также оцениваются, чтобы определить, насколько они подготовлены и способны производить ценность во временных рамках. На основании этой информации разрабатывается план поддержки, который балансирует ресурсы и поддержку в студии. Внешняя поддержка тоже предусматривается, но только в самых крайних случаях.
Технические средства студии
В самом начале студия более походит на остов, где больше учебы, чем чего-либо еще. Когда менеджер студии измеряет выгоды и отчитывается о них руководству, инвестиции могут быть вложены в технические средства, которые увеличивают полезность студии. Эти технические средства могут быть доступны для любого проекта, разрабатываемого в студии. Перечислим их.
1. Рабочее помещение. Scrum-команды преуспевают в открытых помещениях, которые поддерживают взаимодействие команды, то есть следует создать пространство, где члены Scrum-команды могут легко общаться, пока разрабатывают программное обеспечение. Должно быть достаточно пространства возле каждого человека, для двух или трех человек, чтобы они могли работать вместе. Кресла должны быть удобными, а рабочие столы – легко двигаться. Интернет, локальную сеть и серверы следует настроить и обеспечить инструменты для разработки, необходимые Scrum-команде. Оборудование также должно включать средства вывода, проекторы или большие телевизоры в местах проведения мероприятий, а также множество офисных мольбертов. Также должно быть предусмотрено место для посетителей или временных членов команды. Зачастую необходимо или желательно настроить пространство на основании стиля разработки или меняющихся потребностей.
2. Инструменты для разработки и методики. Scrum-команда должна иметь полностью автоматизированное оборудование для разработки и тестирования, чтобы, как только новое программное обеспечение будет разработано или изменено, его можно было бы протестировать и посмотреть, как оно работает. Тесты могут быть большими, например функциональными, или маленькими, например модульное тестирование кода. Критические тесты проводятся для проверки стабильности, производительности и безопасности. Должны использоваться техники бережливого качества, когда качество встроено, чем когда оно достигается путем тестирования, когда функционал уже закончен. Команда разработки характеризует продукт с точки зрения тестов или вещей, которые он должен делать, и того, как он их делает. Если какой-то тест не пройден, разработка останавливается, пока причина неудачи не будет исправлена. Незаконченная или дефектная продукция требует денег на исправление. Чем больше таких багов накапливается к концу разработки, тем выше будет стоимость или технические усилия по их исправлению. Это работа и стоимость уже не подчиняются линейному закону. Scrum-команда не только должна проводить тесты, чтобы удостовериться в том, что разработанное ими сейчас функционирует правильно, но также должна применить все предыдущие тесты, чтобы убедиться, что вся система не подорвана.
3. Планирование и отчетность. Полный набор стандартизированного планирования, контроля, управления рисками и процедуры отчетности должны быть доступны в студии, также должны быть предоставлены шаблоны, и Scrum-командам необходимо их использовать.
Изменения и дилемма
Как и единичный Scrum-проект, Scrum-студия осуществляет культурные изменения, требующиеся для эмпиризма и самоорганизации. Это не всегда легко, Scrum отличается от всех остальных методов. Scrum – дилемма для всех. Он бесспорно лучше предиктивного метода разработки, но привычки прошлого трудно преодолеть.
Только практика и способность проникнуть в суть преимуществ могут помочь осуществить переход от предиктивных процессов к эмпирическим. Для того чтобы помочь разрешить дилемму, мы разработали инструмент, показанный в табл. 7.1.
Таблица 7.1. Опросник
В первой части инструмента мы просим респондентов рассмотреть принципы, о которых они узнали при изучении Scrum, с точки зрения передового опыта, а иногда и просто с точки зрения здравого смысла. Мы просим их выбрать вариант ответа: полностью согласны, частично согласны, не знают, не согласны с утверждениями.
Если менеджер согласен с большинством этих утверждений, он, вероятно, сможет использовать Scrum. Это означает, что он не будет полагаться на традиционные методы, которые могут отвлечь команду, снизить ее креативность, инициативу и продуктивность. Он не станет от имени команды принимать обязательства относительно того, сколько они смогут сделать и к какой дате, а затем пытаться убедить команду, что эти обязательства достижимы. Менеджер не будет распределять задачи, рассказывая команде, как ей выполнять свою работу, или подталкивать членов команды работать так, чтобы исполнить обязательства, взятые на себя менеджером. Короче говоря, дилемма в том, что сейчас вы знаете одно, а должны действовать по-другому. Дилемма в том, чтобы меняться с помощью интеллектуального понимания своих действий день за днем.
Управление с помощью цифр
Все проекты в студии оцениваются с помощью измерений. Стандартный, комплексный набор показателей применяется к любым проектам, осуществляемых в студии. Scrum-команда использует эти показатели для отслеживания и улучшения производительности.
Эти показатели объединены на общей инструментальной панели студии, которая отслеживает историю проектов и отражает тенденции. Эти показатели используются и для оценки затрат и прибыли студии, и для оценки финансирования ее необходимого развития. Руководство организации может использовать совокупные показатели для определения общей рентабельности инвестиций (ROI) студии и решить, должно ли быть применение студии расширено или сжато. Рисунок 7.2 показывает первичные показатели на инструментальной панели студии. Каждый может иметь много подчиненных показателей.
Рис. 7.2. Инструментальная панель проекта
1. Продуктивность – это количество единиц бизнес-функционала, которое разработано на определенное количество денег (например, на 100 тысяч долларов инвестиций). Продуктивность также называют скоростью. Это показатель не ценности, а только количества произведенного функционала. Изначально произвольная единица функционала определяется и измеряется. Размер измеряется в функциональных точках, объективной и абстрактной системе измерений для программного обеспечения. Функциональные точки универсальны и могут быть применены везде в пределах системы, продукта или для любой другой системы. Весь другой функционал определяется относительно базовой единицы. Эта система измерений (измерение размера единицы функционала в функциональных точках) становится стандартным показателем студии. Базовая единица требует периодической калибровки, чтобы гарантировать ее соответствие.
2. Качество измеряется в дефектах по отношению к стандартному размеру единицы работы в студии. Scrum-команда разрабатывает инкременты функционала программного обеспечения. Когда владелец продукта хочет реализовать этот функционал, количество дефектов подсчитывается со дня, когда единица функционала передается владельцу продукта, до трех месяцев его использования.
3. Ценность – мера того, насколько ценен созданный функционал для организации. Это мера эффективности (в процентах) от каждого доллара, потраченного на разработку программного обеспечения, которая создает ценность для организации. Показатель ценности не включает рыночную ценность. Рыночная ценность отражает показатель ROI, о котором мы не станем говорить в рамках этой книги. В среднем в общем уровне затрат на создание ценности в организации на разработку программного обеспечения затрачивается меньше 10 % от каждого доллара. Значительный процент расходуется на поддержание и сохранение существующих систем. Также большое количество средств идет на разработку функционала, который используется не очень часто. Большая часть денег тратится на создание программного обеспечения, которое могло быть полезным где угодно, но не в пределах организации, которая за него платит.
Инструментальная панель студии отражает тенденции по повышению продуктивности и качества, как показано на рис. 7.3.
Рис. 7.3. Инструментальная панель качества и продуктивности
Следующая панель отражает тенденции в увеличении ценности и ROI, как показано на рис. 7.4.
Рис. 7.4. Инструментальная панель ценности и возврата инвестиций
Можно учитывать еще несколько показателей.
1. Стоимость владения. Программное обеспечение имеет три составляющие расходов для организации разработчика, которые определяют полную стоимость владения продуктом:
• разработка – средства, выделяемые на разработку продукта или системы;
• техническое обслуживание – затраты на поддержание, сохранение и развитие продукта;
• эксплуатационные затраты – средства, выделенные для запуска и управления продуктом, когда он доступен для использования по назначению.
2. Проекты. Количество проектов, чьи данные объединяются и отображаются.
3. ROI студии. Это показатель накопительного возвращения инвестиций, или общее значение прибыли, полученной от проектов, деленное на затраты на содержание студии. Это также показатель экономии, полученной в процессе улучшения производительности, в сравнении с затратами на поддержание и улучшении студии. Многие организации не знают показателей продуктивности своих подразделений, занятых разработкой программного обеспечения, особенно с точки зрения предоставляемого бизнес-функционала. Scrum-студии часто вынуждены создавать первые измерения производительности. Они используются в качестве исходных условий для всех последующих улучшений.
Таблица 7.2 показывает примеры показателей, которые могут быть сделаны в студии.
Таблица 7.2. Инструментальная панель тенденций
Решения, принятые в ходе разработки продукта, оказывают глубокое воздействие на стоимость владения системой.
Рассмотрим некоторые из этих воздействий.
• Функциональные возможности, которые редко используются, по-прежнему должны быть сохранены и увеличивают эксплуатационные расходы.
• Качество программного обеспечения, созданное в процессе разработки, определяет дальнейшие затраты на поддержку системы и затраты на дальнейшее улучшение. Программное обеспечение низкого качества труднее улучшить, чем высококачественное, оно оставляет наследство в виде увеличения затрат организации.
• Ремонтопригодность и устойчивость программного обеспечения могут быть сдерживающим фактором в жизненном цикле и полезности программного обеспечения. Многие организации не смогли стать конкурентоспособными, даже используя Scrum, поскольку изначальное программное обеспечение было в плохом состоянии, а разработчики, которые его делали, отсутствовали.
Вы, наверное, привыкли к гораздо большему количеству показателей, таких как «заработанная ценность». Эти показатели были для вас очень важными, потому что отсутствовал другой способ оценить прогресс и текущий риск разработки проекта. Scrum заменяет эти показатели на надежное материальное свидетельство в конце каждого спринта. У вас есть серьезный инкремент функционала, который может быть незамедлительно использован. Все показатели подчинены ценности и стоимости этого функционала.
Показатели зависят от прозрачности
Вы пришли к Scrum, потому что хотите знать, что происходит, и управлять работой для создания прибыли для вашей организации и ценности для ваших клиентов.
Scrum обеспечит вам следующие возможности.
1. Знание того, как много функционала программного обеспечения осталось создать. Даже после того, как вы внесли массу изменений, вы всегда сможете спрогнозировать, что осталось сделать.
2. Представление о том, какой функционал уже сделан. Функционал соответствует тому, сколько денег потрачено. Это прибыльно.
3. Понимание, сколько функционала было реализовано за несколько последних спринтов. Это позволит вам сделать прогноз относительно того, сколько времени займет создание оставшегося функционала. Помните, что это сложная работа и будущее может измениться, но что-то всегда лучше, чем ничего.
4. Возможность взять один или несколько инкрементов функционала, которые уже закончены, и начать ими пользоваться, изучая ценность на раннем этапе.
Все остальное, что предоставляет вам Scrum, – дополнение к этому. Вы можете создать продуктивность, качество, хорошее место для работы, привлечь пользователей и увеличить долю рынка. Но главное – вы должны знать, что делаете. Прозрачность инкремента и того, из чего он состоит, – основа.
Законченный инкремент функционала
В конце спринта у вас появится инкремент одного или нескольких требований, законченный и готовый к использованию. Испытайте его и убедитесь, что он не развалится, что он достаточно качественный для реального использования. Опробуйте этот инкремент в сочетании со всеми предыдущими. Выполненный, законченный инкремент – то, что вы можете использовать.
Если инкремент не функционирует, как надо, и не может быть сразу установлен и использован, не принимайте его. Просите команду пересмотреть порядок и включить в него все работы, необходимые, чтобы действительно закончить инкремент. Затем верните эти пункты в бэклог продукта.
Непрозрачность вместо прозрачности
У нас есть опыт работы с последствиями отсутствия прозрачности в крупной энергетической компании в 2002 году. Scrum был опробован в одном из отделов, менеджер которого, Дэвид, был в восторге от прозрачности, обеспечиваемой Scrum. К сожалению, он не убедился, что инкремент полностью доделан и годен к употреблению. Он даже не знал, что должен это делать. Вот его история.
Дэвиду нужно было автоматизировать получение его департаментом сведений об изменении собственности – они занимались обработкой и выплатой лицензионных платежей землевладельцам в начале каждого финансового года. Дэвид должен был быть уверен, что информация актуальная, поскольку отвечал за имущество на территории Соединенных Штатов и Канады.
Всю информацию его организация получала в форме распечатанных документов. Объем становился ошеломляющим, и Дэвид хотел автоматизировать этот процесс.
Он решил, что его разработчики для создания системы должны использовать Scrum. Не только потому, что законченный продукт мог позволить ему оставаться на вершине прогресса, но и потому, что таким образом он получал возможность использовать части функционала по мере их доступности.
К концу третьего спринта разработчики автоматизировали получение и интеграцию смены собственника для одной из провинций Канады. Они продемонстрировали это, используя SQL, технический язык запросов к базе данных. Дэвид был в восторге. Он решил, что его сотрудникам необходимо выучить SQL, потому что большинство их задолженностей было из этой провинции и автоматизация могла позволить быстро устранить отставание.
Команда разработки предупредила Дэвида, что он пока не может использовать инкременты функционала. Но Дэвид в это не поверил: команда должна была строить приращения программного обеспечения, которые он мог бы сразу запускать в работу. Он видел первый, второй и третий инкременты и хотел начать пользоваться ими для облегчения бизнес-процессов. Он хотел получить ранние выгоды, пока разработка продолжается.
Команда разработки сообщила Дэвиду, что инкременты были созданы для демонстрации, но не для использования, поскольку существовал целый ряд нерешенных вопросов – например, данные не были стабильными, и база данных иногда теряла информацию и становилась искаженной. Дэвид спросил, сколько еще предстоит сделать, чтобы он мог пользоваться первыми тремя инкрементами. Ему ответили, что потребуется еще два спринта, чтобы сделать инкременты стабильными.
После этого у Дэвида был еще один, более трудный, разговор с командой разработки. Он выразил разочарование по поводу того, что прогресс не был прозрачным. Дэвид был смущен: ему преподносили процесс как Scrum, но то, что он увидел, не было реальным и готовым к полноценному использованию. Он также сказал, что ему вдвойне неловко, потому что он отчитывался о проделанной работе перед владельцем продукта так, как будто знал, что происходит.
Что думали люди о том, что происходило
Перед началом проекта Дэвид и Scrum-команда разработали план для создания системы. Дэвид удостоверился, что все знают план и он представляет собой наилучший возможный прогноз. Он пообещал, что будет показывать реальный прогресс по отношению к плану в конце каждого месячного спринта. Рисунок 7.5 показывает планируемую диаграмму сгорания задач и отчетный прогресс для конца первых трех спринтов. Они были идентичны.
.
Рис. 7.5
Что произошло на самом деле
Разработчики Scrum-команды только начали использовать Scrum. Они поняли принцип итераций, инкрементов, спринтов, Scrum-митингов и все остальное. Однако они не поняли важность прозрачности и законченности инкрементов. До этого они использовали каскадный процесс, при котором программное обеспечение не должно собираться и интегрироваться для попыток использования до окончания проекта. Разработчики решили, что могут так делать и при использовании Scrum. Они создавали столько, сколько могли, в каждом спринте. Они рассчитывали, что, когда Дэвид захочет использовать программное обеспечение, у них будет дополнительное время на то, чтобы сделать это обеспечение рабочим.
Команда разработки планировала проект с Дэвидом, основываясь на текущем уровне своих способностей. Она была недостаточна квалифицирована, чтобы создавать законченные инкременты в конце каждого спринта, – ее члены только изучали новые методы, и требуемые инструменты для разработки были заказаны, но еще не использовались. Разработчики еще не были достаточно профессиональными, чтобы построить законченный инкремент в течение одного спринта, или создать инкременты, которые добавляются к созданным ранее, как показано на рис. 7.6.
Рис. 7.6. Инкрементальный прогресс в сторону готовой к использованию функциональности
В самом начале проекта они думали, что сделают все инкременты действительно готовыми к употреблению, когда все спринты будут закончены.
Дэвид уловил идею прозрачности и предсказуемости. Команда разработки – только общую идею Scrum. Они перенесли непредсказуемость разработки каскадного процесса внутрь Scrum.
Прозрачность инкрементов должна была позволить Дэвиду управлять рисками и добиваться предсказуемости. В начале проекта Дэвид со Scrum-командой определили план выпуска. После спринта № 1 он оценил динамику приближения к будущей цели путем оценки того, что, как он думал, было рабочим инкрементом, и принял решение о том, что необходимо сделать в спринте № 2 в рамках движения к цели. Если бы он знал, что прогресс был недостаточным, то мог бы отменить проект. Однако из-за того, что инкремент был непрозрачным, он не мог эффективно принять решение.
Когда команда разработки оценила объем работы, которая не была доделана в течение первых трех спринтов, это добавило еще 14 единиц работы. Расхождение между планом и реальным прогрессом в конце третьего месяца разработки отражает эти «скрытые» 14 единиц работы, как показано на рис. 7.7.
Рис. 7.7. Реальная и планируемая законченная работа
В конце третьего спринта Дэвид верил, что 30 % работы уже сделано, как показано на . Он думал, что может начать использовать эти 30 % готового продукта. К сожалению, инкремент не был законченным. Как показано на рис. 7.7, чтобы устранить расхождение между диаграммой сгорания задач, которую Дэвид считал правдивой, и реальной диаграммой, нужны два дополнительных спринта, чтобы сделать три предыдущих инкремента пригодными для использования в бизнесе.
Если вы, как Дэвид, когда-либо начнете принимать незаконченные инкременты, они вернутся и станут вас преследовать. Недоделанную работу гораздо труднее закончить, когда она перекрывается новыми задачами. Кроме того, незавершенная работа нарушает прозрачность, делая невозможным прогнозирование того, как далеко вы находитесь от достижения цели и каковы будут реальные затраты на проект. Вы окажетесь неспособны эффективно управлять своими инвестициями.
Когда проект «закончен», «завершен» или «финализирован», не должно быть недоделанной работы. Этот важный момент – одно из наиболее неявных, но фундаментальных требований Scrum-подхода.
Аналогия
В холодном климате, когда температура падает, всякий раз, когда вы включаете воду в кране или используете стиральную или посудомоечную машину – словом, когда система отопления включается, трубы начинают стучать друг о друга, об ограждение или стены. Иногда они звучат как отбойный молоток, особенно если это происходит посреди ночи. Они дребезжат, потому что плохо закреплены. Стучащие трубы трудно починить, точный источник стука сложно установить – стучать может не там, где труба расшаталась. Часто, чтобы обнаружить, где именно стучит, приходится делать большое отверстие в стене, удалять изоляцию, чтобы осмотреть трубы в поисках источника повреждения. Затем, при везении, вы сможете закрепить трубу должным образом. Стоимость правильного крепления труб при монтаже не сильно отличается от неправильного. Стоимость исправления креплений, когда здание уже построено, гораздо выше.
Каждый инкремент программного обеспечения должен быть таким же крепким, как и правильно закрепленная труба. Если мы надстроим на него больше инкрементов, то не захотим долго копать вглубь, чтобы починить то, что не работает должным образом. Починка после того, как строительство завершено, оказывается очень дорогой. Это называется техническим долгом.
Устранение технических долгов для получения готовых к использованию инкрементов
Множество Scrum-команд, с которыми мы сотрудничали, поначалу не были способны разработать готовые к использованию инкременты программного обеспечения к концу спринта. В прошлом от них не требовалось прозрачности, и они часто не имели достаточной технической квалификации или необходимых инструментов, чтобы быстро создать готовый для использования функционал.
Таблица 7.3 предоставляет в первой колонке типичную работу, которую проделывает команда девелоперов, чтобы превратить требования бэклога продукта в стабильный функционал. Вторая колонка, обозначенная «Обычно», содержит количество единиц работы, которую команды привыкли делать предварительно до конца предиктивного, традиционного, проекта для каждой задачи из первой колонки. К примеру, разработчики привыкли тратить 12 единиц работы на анализ требований. Они привыкли тратить 10 единиц работы, создавая компоненты архитектуры. Это относительные цифры, показывающие, что разработчики тратят на две единицы больше работы в первом пункте, или на 20 % больше работы, чем по второму пункту.
Таблица 7.3
Третья колонка, названная «Сделано», содержит единицы работы, которые им требуется выполнить, чтобы создать полностью законченные, прозрачные инкременты функционала по каждому пункту из первой колонки. Общая сумма работы для создания прозрачных инкрементов составляет 171 единицу. Большинство разработчиков привыкли заканчивать только 71 из этих единиц работы, когда они переходят на эмпирические Scrum-проекты, как это показано в колонке «Обычно». Они привыкли оставлять на потом 100 единиц работы в каждом фрагменте функционала, который они создают. спринт за спринтом, эта незаконченная работа накапливается по экспоненте до самого конца проекта.
Перед тем как вы начнете ваш первый спринт, попросите Scrum-мастера и команду разработки оценить табл. 7.3. Пусть они сделают новую таблицу в соответствии с тем типом программного обеспечения, которое вы создаете. Затем попросите их, до того как вы начнете первый спринт, обдумать, как они планируют закончить все работы. Чтобы увидеть, все ли они сделали, как надо, попросите у них один или несколько инкрементов для начала использования по назначению в конце любого спринта. Если они скажут, что это невозможно, или вы попробуете сами, но инкремент не работает как надо, значит, команде разработки требуется больше обучения или практики.
Компания Adobe и технический долг
Продукт Adobe Premiere Pro – ведущий в отрасли набор программного обеспечения для нелинейного видеомонтажа. Программы канала BBC и The Tonight Show («Сегодня вечером») создаются с его помощью. Вице-президент подразделения Стив Уорнер управлял Premiere Pro. Питер Грин был программным менеджером пакета Creative Suite в его составе. Развивающиеся стандарты и запросы на новые возможности требовали от них очень быстрого выпуска новых релизов.
Premiere Pro CS3 (Creative Suite, версия 3.0) был выпущен в июле 2007-го. Для его создания были использованы традиционные методы, и программное обеспечение поставлялось одним большим фрагментом после 18 месяцев разработки. Когда дата выпуска стала приближаться, разработчики начали собирать CS3 к релизу. Было очень много «стучащих труб» (то есть дефектов или ошибок). Разработчики не располагали достаточным количеством времени, чтобы их все исправить, поэтому собрали релиз так, как смогли в эти временные рамки, и выпустили его. Вот какие комментарии оставляли пользователи о CS3:
«Если вы хотите легкую в использовании, дружелюбную по отношению к пользователю программу для редактирования видео, это точно не она. Были вещи, которые я от нее ждал, а она их не делает. Или я не смог их запустить».
«…это программное обеспечение – заведомо плохой код с большим количеством утечек памяти. Если вы попробуете перекодировать большой видеофайл в mpeg2, Premiere, скорее всего, выдаст ошибку из-за плохого управления памятью. Единственное решение – просто перезапустить систему и молиться, чтобы это опять не случилось».
Следующий релиз, Premiere Pro CS4, должен был устранить дефекты CS3. CS4 должен был улучшить стабильность, скорость и легкость в использовании, а также остановить утечки памяти. Питер Грин услышал об этом и решил, что короткие циклы разработки позволят Adobe создать законченные инкременты общего продукта после каждого спринта. Затем инкременты будут складываться в нечто работающее, и это должно понравиться пользователям. Питер также хотел знать реальное положение дел в каждом спринте, поэтому поручил нескольким командам, работающим над CS4, попробовать Scrum.
У Adobe было более 100 девелоперов в 18 Scrum-командах, работающих над выпуском этого релиза. Все решили, что интегрирование всех инкрементов от всех 18 команд после каждого спринта будет слишком большой работой. Они решили подождать до даты, близкой к релизу, чтобы интегрировать все инкременты. Прямо перед выходом CS4 команды пытались соединить фрагменты своей индивидуальной работы в один объединенный продукт. Все противоречия и неразрешенные зависимости, которые препятствовали интеграции, выявились в виде ошибок, и фрагменты CS4 не работали вместе. Рисунок 7.8 показывает медленное увеличение в течение разработки до попытки интеграции и затем резкий скачок в количестве дефектов. Разработчики героически исправляли максимум возможного, но все-таки им пришлось выпустить продукт с заметными дефектами. Имена разработчиков, которые были госпитализированы по причине стресса и переработки в Adobe, стали легендой.
Рис. 7.8. Дефекты в Adobe CS4 и CS5
CS4 был выпущен в сентябре 2008 года и вызвал критические обзоры и негативные отзывы пользователей. Adobe использовал Scrum, чтобы стать более продуктивным, однако более продуктивной стала только каждая отдельная команда. Работа всех команд не была интегрирована и не стала прозрачной. Потенциальные проблемы интеграции были отложены для краткосрочной продуктивности. Качество продукта, отзывы критиков индустрии, своевременный выпуск новых возможностей, удовлетворенность клиентов, моральный дух и здоровье сотрудников в результате пострадали. Что-то надо было менять.
Стив и Питер решили в работе над CS5 использовать Scrum как можно шире, а также обучить методу всех разработчиков и программных менеджеров. Новой задачей Питера было обучать и инструктировать команды, чтобы они могли создать качественное программное обеспечение после каждого спринта. Все инкременты всех команд интегрировались и тестировались после каждого спринта. Каждый спринт естественным образом производил продукт уровня релиза CS5. Рисунок 7.8 показывает, что дефекты никогда не выходили из-под контроля в течение всего процесса. Более того, ко всеобщему удивлению, разработчики закончили работу быстрее, чем было запланировано. Неожиданные дефекты и ошибки от интеграции инкрементов больше не замедляли их прогресс. В дополнительное время перед выпуском разработчики исправили часть проблем, оставшихся от релиза CS4. CS5 был выпущен в апреле 2010-го, обзоры и отзывы пользователей были на этот раз одобрительными.
Питера попросили разработать показатели, которые могли быть использованы для управления Scrum-разработкой в Adobe. Он отметил три таких показателя. На первом месте было удовлетворение сотрудников Scrum процессом во время работы над CS5 и их вера в то, что Scrum улучшил их методы разработки программного обеспечения. Adobe предложил 200 разработчикам из 25 команд ответить на 50 вопросов. Результаты были проанализированы командами, и выявлены области, в которых требовались улучшения. Впечатляет, что 80 % разработчиков отметили, что продолжат использовать Scrum даже без распоряжения руководства. Среди наиболее производительных команд так ответили 100 % разработчиков. Уровень дефектов уменьшился значительно, и практически ни один продукт не был выпущен с «отложенными» дефектами. Удовлетворение пользователей заметно возросло.
Adobe опробовал Scrum, потому что испытывал проблемы, которые только усугублялись. Благодаря настойчивости, обучению и согласованности усилий многие проблемы были решены, и релизы программного обеспечения стали занимать меньше времени, а качество улучшилось.
Происхождение греха
Давайте рассмотрим типичный проект. Перед запуском проекта команда разработки сделала оценку, что бэклог продукта содержит 80 единиц работы над требованиями. Вы надеетесь выпустить это программное обеспечение после десяти спринтов длиной в один месяц. По привычке команда разработки делит 80 на 10 и сообщает, что будет выполнять по восемь единиц работы над требованиями за один спринт, причем станет выбирать восемь единиц работы для каждого месячного спринта, независимо от того, какое качество ожидается и сколько работы придется пропустить, чтобы все сделать вовремя.
В предиктивных проектах по разработке программного обеспечения организация оценивает требования и намечает дату выпуска и стоимость, затем следует обеспечить соответствие реальности планам. В Scrum-проектах команда разработки поставляет столько инкрементов функционала, сколько сможет, с учетом продуктовых приоритетов. И вы можете управлять этим процессом путем приоритезации потребностей, и каждый инкремент продукта будет работоспособен и будет соответствовать необходимому уровню качества.
Качество традиционно было переменной в сфере разработки программного обеспечения. Системы заканчивались с минимальной просрочкой срока выпуска, если качество понижалось. Однако ухудшение качества на самом деле снижает продуктивность, увеличивает стоимость и становится причиной еще больших просрочек. Команды отягощаются дополнительной работой по исправлению обнаруженных дефектов и ошибок, с той только разницей, что причина задержки и увеличение стоимости становятся невидимыми для вас. Сегодня качество перестает быть переменной.
Продолжаем наш пример. Вы ожидаете, что к концу десятого месяца сможете использовать весь функционал программного обеспечения. Однако в конце концов узнаете, что накопилось 48 единиц недоделанной работы, и вас это, конечно, не радует. Что делать? Просить разработчиков закончить недоделанные задачи, чтобы увеличить процент законченного для каждой строчки бэклога продукта как можно быстрее? Но мы ошибаемся, если требуем закончить работу как можно быстрее. Обычно на это уходит еще шесть месячных спринтов (48 единиц, деленные на предполагаемую скорость восемь единиц). Оставшаяся несделанная работа отражена на рис. 7.9 как пробел между работой, которая была заявлена как законченная, и аккумулированной незавершенной работой.
Рис. 7.9. Накопление технического долга по мере выполнения работы
В конечном счете команда разработки завершает часть недоделанных задач, и менеджмент признает, что продукт начинает работать. Однако вскоре пользователи принимаются жаловаться, что продукт не соответствует их ожиданиям. С этого момента незаконченная работа замораживается. Это технический долг, который ограничивает людей в эффективном использовании продукта. Начинаются звонков клиентов в службу поддержки и исправление ошибок, которое съедает наше внимание и прибыль. Хуже всего, что это может заставить пользователей искать лучшие альтернативы. Мы не получаем выгоды, которых ожидали. Технический долг прогрессивно уменьшает долговечность продукта, его предполагаемый жизненный цикл.
Предположим, команда разработки состоит из трех программистов и двух инженеров по качеству. Они применяют традиционные, предиктивные, методы. У них имеется контроль качества, чтобы посмотреть, все ли работает. Любые ошибки или дефекты обнаруживаются и возвращаются программистам на исправление. Пока это происходит, другие программисты могут написать много нового программного обеспечения поверх дефектного. Усилия по устранению изначальной проблемы теперь занимают больше времени, а усилия по исправлению сборок программного обеспечения еще больше увеличивают эти временные затраты. Очень важно обнаруживать и исправлять проблемы, как только они появляются. Затем разработчики могут продолжить без усложнения проблемы и отложенных проблем при сборке.
Технический долг затуманивает прозрачность и делает решения сомнительными. Мы измеряем наш прогресс путем сравнения законченных, готовых к использованию фрагментов функциональных возможностей программного обеспечения с оставшимися необходимыми фрагментами. Мы не берем в расчет незаконченную работу. Тем не менее очень много разработчиков программного обеспечения производят незаконченные инкременты. Обычно, когда членов команды спрашивают, почему они частично закончили некоторое количество требований бэклога продукта, вместо того чтобы выбрать меньшее количество и закончить полностью, они говорят: «У нас не было времени». Мы должны обратиться к нашему Scrum-мастеру, чтобы убедиться, что такого не произойдет.
Программное обеспечение за 30 дней обеспечивает предсказуемость, контроль рисков и оптимальную ценность. Краеугольный камень этих возможностей – постоянная прозрачность. Как минимум каждые 30 дней вы можете увидеть то, что покупаете. Многие разработчики борются со старыми привычками и недостаточными профессиональными навыками, чтобы создать эту прозрачность. Есть множество разработчиков, которые переступили эту пропасть. Вам следует выбирать разработчиков и инвестировать в них, пока они не смогут надежно создавать программный продукт, или найти других специалистов, которые смогут это сделать для вас.
Выводы
Scrum-студия разработки программного обеспечения – обособленная организация внутри вашей общей организации. Студия не делает попыток изменить существующий процесс разработки всей организации – скорее она организуется для того, чтобы каждый, кто хочет использовать Scrum для разработки программного обеспечения, мог туда пойти. Студия начинает с малого и растет, пока не подтвердит свою ценность, постепенно становясь местом, где разработка программного обеспечения продуктивна, отличается высоким качеством и ценностью. Риск находится под контролем, а проекты управляются предсказуемо. Тестирование и показатели используются для достижения результатов опытным путем, чтобы вдохновить постоянное совершенствование.
Scrum-студия – простой и быстрый путь для начала использования инкрементального, непрерывного улучшения в разработке программного обеспечения. Scrum и показатели студии помогают выявить проблемные области.
Назад: 6. Scrum на уровне проекта
Дальше: 8. Scrum на уровне организации
