Софт за 30 дней. Как Scrum делает невозможное возможным

Таблица 6.1. Стоимость коротких спринтов

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

Не пытайтесь делать спринты такой длины

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

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

1. Заинтересованные лица теряют внимание и забывают о проекте.

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

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

В пределах проекта применяйте спринты одной длины

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

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

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

Примеры проектов Scrum-PRN

В Fidelity Investments применили Scrum в 1997 году, чтобы предоставлять интернет-услуги для своих пользователей. Чарльз Шваб и клиенты E-Trade уже управляли своим капиталом онлайн, а пользователи Fidelity – еще нет. В то время Fidelity представляла собой жесткую каскадную организацию. Многочисленные попытки по предоставлению интернет-услуг заканчивались неудачей. В отчаянии компания обратилась к Scrum. За несколько месяцев первый вариант сайта Fidelity.com был разработан и запущен, и в течение 18 месяцев инвесторы были счастливы работать с Fidelity.com, который стал не хуже решений конкурентов. Успех был достигнут, и Scrum выведен из оборота компании. Следующие семь раз, когда Fidelity критически нуждалась в разработке программного обеспечения, она создавала Scrum-проекты. Однако компания не воспользовалась всеми преимуществами, которые могла бы получить, приняв во внимание предыдущий опыт. Каждый Scrum-проект мог быть более эффективным, чем предыдущий. Тем не менее Fidelity сделала выбор – использовать Scrum только в чрезвычайных ситуациях, PRN.

7. Развитие возможностей Scrum

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

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

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

Студия – научающаяся организация

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

Вся работа в студии основывается на 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 тысяч долларов инвестиций). Продуктивность также называют скоростью. Это показатель не ценности, а только количества произведенного функционала. Изначально произвольная единица функционала определяется и измеряется. Размер измеряется в функциональных точках, объективной и абстрактной системе измерений для программного обеспечения[8]. Функциональные точки универсальны и могут быть применены везде в пределах системы, продукта или для любой другой системы. Весь другой функционал определяется относительно базовой единицы. Эта система измерений (измерение размера единицы функционала в функциональных точках) становится стандартным показателем студии. Базовая единица требует периодической калибровки, чтобы гарантировать ее соответствие.

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

3. Ценность – мера того, насколько ценен созданный функционал для организации. Это мера эффективности (в процентах) от каждого доллара, потраченного на разработку программного обеспечения, которая создает ценность для организации. Показатель ценности не включает рыночную ценность. Рыночная ценность отражает показатель ROI, о котором мы не станем говорить в рамках этой книги. В среднем в общем уровне затрат на создание ценности в организации на разработку программного обеспечения затрачивается меньше 10 % от каждого доллара. Значительный процент расходуется на поддержание и сохранение существующих систем. Также большое количество средств идет на разработку функционала, который используется не очень часто. Большая часть денег тратится на создание программного обеспечения, которое могло быть полезным где угодно, но не в пределах организации, которая за него платит.

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

Рис. 7.3. Инструментальная панель качества и продуктивности

Следующая панель отражает тенденции в увеличении ценности и ROI, как показано на рис. 7.4.

Рис. 7.4. Инструментальная панель ценности и возврата инвестиций

Можно учитывать еще несколько показателей.

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

• разработка – средства, выделяемые на разработку продукта или системы;

• техническое обслуживание – затраты на поддержание, сохранение и развитие продукта;

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

2. Проекты. Количество проектов, чьи данные объединяются и отображаются.

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

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