Качество программного обеспечения – это соответствие функциональным и не функциональным требованиям.
Функциональные требования (functional requirements, FR) описывают, что будет делать система, то есть это возможности системы (функции) без описания того, как они реализованы. В сложившихся практиках FR описываются элементами продуктового бэклога.
Нефункциональные требования (non-functional requirements, NFR) описывают, как будет работать система. Как правило, это перечень атрибутов и критериев их соответствия, в большинстве случаев говорят про атрибуты качества.
В сложившихся практиках NFR указываются в DoD и в исключительных случаях в критериях приемки.
В процессе работы команда может как увеличивать качество, так и занижать. Делать это можно запланировано или случайно. Рассмотрим все четыре случая.
3.3.1. Запланированное улучшение качества системы
Запланированное улучшение качества системы обычно происходит, когда продукт выходит из фазы пилотного проекта, и необходимо провести работы, чтобы подготовиться к увеличению нагрузки. Но лучше задуматься об атрибутах и критериях качества как можно раньше.
Владелец продукта предоставляет данные финансовой модели, по которым определяются атрибуты и критерии на горизонте 3–6 месяцев. Например:
➠ Количество активных пользователей в день – от 10 тыс. до 100 тыс. человек.
➠ Объем хранимых данных на пользователя – от 3 до 6 мб.
➠ Раздача видео потока на одного пользователя – до 100 мб/мес.
На ретроспективе в определение завершенности вносятся изменения, и команда уже со следующего спринта начинает планировать его с учетом новых критериев. Очевидно, что это может сказаться на объеме выработки за спринт.
Если в процессе требуется доработки функциональности системы, не ценные для конечных пользователей, то в бэклог добавляются энейблеры. Они могут быть сформулированы как пользовательская история, где в качестве пользователя выступают члены команды, например:
➠ «Как владелец продукта могу видеть данные о тестировании нагрузки, чтобы удостовериться, что система выдерживает единовременно 10 тыс. обращений».
➠ «Как разработчик могу настроить динамическое масштабирование приложения, чтобы выдерживать изменения нагрузки до 10 тыс. обращений».
Важно проверить на соответствие новым критериям ту функциональность, которая была реализована до этого. Если обнаружится, что какие-то уже реализованные истории не соответствуют новым критериям, то они добавляются в продуктовый бэклог в исходной формулировке, чтобы владелец продукта смог приоритизировать их в соответствии с новым DoD.
3.3.2. Незапланированное улучшение качества системы
Обычно незапланированное улучшение качества системы происходит, когда случился резкий рост продукта, но бывают и менее приятные ситуации, такие как хакерские атаки. В этом случае определяются атрибуты и критерии, например, устойчивость к DDoS-атакам до 300 Гб/с.
Если цель текущего спринта не может быть достигнута, то производится остановка спринта, например, в связи с атакой на сервер не может быть выполнен критерий «Из 100 единовременных обращений 80 % запросов не превышают одной секунды».
При необходимости добавляются сессии прояснения бэклога.
Далее ситуация переходит в разряд запланированных улучшений качества системы, и действия происходит в соответствии с шагами, описанными в предыдущем разделе.
3.3.3. Запланированное ухудшение качества системы
Запланированное ухудшение качества системы происходит, когда владелец продукта принимает на себя решение понизить качество системы, часто для увеличения скорости поставки.
Например, для демонстрации на мероприятии с фиксированной датой нужно занизить критерии, принятые в DoD. Для этого при оценке элемента бэклога на прояснении бэклога новые критерии заносятся в критерии приемки. Чтобы впоследствии не забыть исправить ухудшение, советую завести связанную пользовательскую историю с уже нормальными критериями.
Например, на прояснении бэклога команда оценила историю «Я как пользователь могу просмотреть видеофрагмент, чтобы принять решение о просмотре целиком». Разработчики оценили историю в 20, так как согласно DoD нужно всегда обеспечивать HD – качество видеопотока, что невозможно в сложившейся ситуации без существенных доработок. В этом случае владелец продукта разделяет историю на две (табл. 3.11).
Табл. 3.11. Пример планирования ухудшения качества в бэклоге
Первая история была реализована в необходимые сроки, вторая отложена для реализации в более удобное время. Такие отложенные доработки по восстановлению качества системы называются техническим долгом (technical debt, техдолг).
В данном случае техдолг был сформирован по инициативе владельца продукта, следовательно, он должен принять все присущие риски и ответственность по устранению.
Лучшие практики по работе с запланированным ухудшением качества
➠ Максимально стараться избегать образования и накопления техдолга.
➠ Если без этого невозможно, обязательно создавать связанную историю в бэклоге.
➠ Оперативно устранять известные запланированные ухудшения в системе.
➠ Вести учет техдолга, например, записывая в отдельный список или помечая его в бэклоге таким образом, чтобы его можно было увидеть при помощи инструментов фильтрации.
➠ Выделить в бэклоге спринта определенный буфер под работы по устранению техдолга.
3.3.4. Незапланированное ухудшение качества системы (дефекты)
Незапланированное ухудшение качества системы, обнаруженное во время спринта или уже после релиза, называется «дефект». Дефекты, обнаруженные в процессе разработки, по возможности исправляются разработчиками в процессе спринта, чтобы инкремент соответствовал DoD. Дефекты, обнаруженные после релиза, заносятся в бэклог продукта.
Например, если обнаружилось что в результате одной из поставок перестала работать история «Я как пользователь могу удалить элемент списка», то она добавляется в продуктовый бэклог в той же формулировке, оценивается исходя из актуального DoD и приоритизируется владельцем продукта.
Лучшие практики по работе с дефектами
➠ Разработчики исправляют небольшие дефекты сразу, если это не приносит ущерба цели спринта.
➠ Ведется учет дефектов, например, с помощью записи в отдельный список или отмечания его в бэклоге таким образом, чтобы его можно было увидеть при помощи инструментов фильтрации.
➠ В бэклоге спринта выделяется определенный буфер под работы по устранению дефектов.
3.3.5. Масштабирование гибких подходов
Компании разными путями приходят к масштабированию гибких подходов. Как правило, все начинается с небольшого эксперимента, когда одна команда начинает пробовать Scrum. При качественном старте результаты становятся очень заметными: осязаемый результат каждый спринт, быстрые реакции на изменения и внешние условия. Это обычно стимулирует повторить успех для всей организации.
Масштабирование гибких подходов происходит в двух случаях: масштабирование в процессе роста и масштабирование внутри уже существующей компании.
3.3.5.1. Масштабирование в процессе роста
В данном случае мы говорим о масштабировании из небольшого стартапа, который, как правило, создается вокруг одного продукта. Если перед компанией встает вопрос о необходимости масштабирования Agile, значит, для оперирования выбран какой-то фреймворк, скорее всего, Scrum. В этом случае в процессе роста важно сохранить гибкую культуру и выбрать правильный фреймворк масштабирования, который позволит быстро расти без избыточного найма. Один из таких фреймворков масштабирования для компаний, растущих с нуля, – LeSS, о котором поговорим в п. 3.4.5.3.
3.3.5.2. Масштабирование в уже существующей компании
Масштабирование гибких подходов в уже существующей компании часто называют Agile-трансформацией. Разумеется, нет двух одинаковых компаний, так что далее будем рассматривать некие гипертрофированные случаи для более наглядного описания процесса.
Рис. 3.23. Горизонтально интегрированная компания
Если в компании полностью отсутствует гибкая культура, то ее называют горизонтально интегрированной (рис. 3.23). В такой компании подразделения объединены вокруг функций. Например, юридический департамент, финансовый, проектный офис, департамент информационной безопасности, департамент информационных технологий и т. д. Каждый из них работает по принципу конвейера и имеет свой норматив прохождения артефактов, как правило, документов. Например, много лет назад в одном банке норматив времени на рассмотрение документов юристами составлял две недели, при этом не было точной уверенности, что после этого не придется отправлять документ на повторное рассмотрение. Функциональные департаменты не заинтересованы в бизнес-результате, а следовательно, сотрудники не хотят рисковать ради него репутацией. Люди скорее склонны творчески выявлять риски, чем их творчески устранять. В результате на каждом этаже происходит значительная задержка. Трансформация идеи в ценность для клиента может происходить так долго, что теряется актуальность, и выпущенный продукт на старте уже нуждается в значительной доработке. Стоит ли говорить, что доработка тоже может потерять актуальность, пройдя через этажи. Горизонтально интегрированные организации очень негибки к внезапным изменениям.
Если что-то нужно сделать срочно по сигналу с самого верха, то обычно в обход всех регламентов происходит спонтанная вертикальная интеграция. Собирается кросс-функциональная команда с разных этажей, которая быстро решает вопрос.
Один из самых лучших способов запустить Agile в горизонтально интегрированной компании – это выбрать отдельно взятый департамент (часто это департамент IT) или создать отдельную компанию с новыми процессами, что нередко называется «инновационной лабораторией» или «технологической компанией». В экспериментальном режиме создается частично вертикальная компания (рис. 3.24).
Сотрудники из разных функциональных подразделений объединяются в кросс-функциональные команды, способные ритмично увеличивать поток ценности для конечных клиентов.
Экспериментальное подразделение частично-вертикальной компании при правильном запуске начинает регулярно показывать ценный для клиентов и бизнеса результат. При этом часть подразделений остаются горизонтальными, но начинают верти-кализироваться. Сотрудники закрепляются за своими продуктовыми командами и впоследствии становятся частью продуктовой команды. Например, сотрудник отдела информационной безопасности становится частью продуктовой команды и берет на себя обязательства за достижение целей спринта. На этом этапе важно не терять времени и переходить к Agile-трансформации более высоких этажей. В ином случае может начаться отторжение: сотрудники верхних уровней, не участвующие в формировании потока ценности, могут начать саботировать процесс из страха, что не найдут себе место в новой структуре. Если компания успешно преодолела сопротивление, то она трансформируется в вертикально интегрированную компанию (рис. 3.25).
Рис. 3.24. Частично-вертикальная компания
В вертикально интегрированных компаниях подразделения сформированы вокруг потоков ценности и имеют обособленный бизнес-результат. При этом подразделения могут иметь несколько уровней вложенности, но принцип сохраняется – дочерние подразделения формируют дополнительную ценность для клиентов и бизнеса.
Например, бизнес-блок «Розничный бизнес» имеет в составе несколько трайбов – депозиты, кредиты и инвестиции. В трайбе депозитов есть команда, которая отвечает за раздел депозитов в мобильном банке.
Рис. 3.25. Вертикально интегрированная компания
Однако гибкие подходы не всегда просто перенести с уровня одной или нескольких команд на уровень всего продукта, портфеля или предприятия.
Для этого требуется масштабирование гибких подходов, которое представляет собой специальный набор методов и практик, направленных на расширение и координацию гибкости в организации.
Далее мы детально рассмотрим, что такое масштабирование гибких подходов, какие задачи и проблемы оно решает и какие фреймворки масштабирования существуют.
3.3.6. Понятие и цели масштабирования гибких подходов
Когда мы только запускали Ак Барс Цифровые Технологии, в компании было около 14 разработчиков, а когда я уходил, она насчитывала 350 человек. Мы организовали и запустили несколько Agile-команд, потом их количество увеличивалось, появились трайбы, с внедрением SAFe образовалась практика квартального планирования с привлечением руководителей бизнес-блоков. И вот из горизонтально-интегрированной компания пришла к высокой степени вертикальной интеграции. Если гибкий подход внедрен правильно, с соответствующей культурой и принятием на уровне ценностей всей компанией, то при наличии быстрых видимых побед процесс масштабирования гибких подходов будет проходить естественно и органично.
Масштабирование гибких подходов – это процесс расширения и координации применения гибких методов и практик на уровне всего продукта, портфеля или предприятия. Оно позволяет организациям достигать более высокой скорости, качества и ценности при разработке и поставке своих продуктов и услуг, а также адаптироваться к изменениям в рыночной среде, потребностях клиентов и технологическом прогрессе.
Цели масштабирования гибких подходов могут быть разными в зависимости от контекста и потребностей организации, но в общем случае они сводятся к следующим:
➠ Увеличить производительность и эффективность команд и организации в целом, сократить издержки и риски, повысить удовлетворенность и мотивацию сотрудников.
➠ Улучшить сотрудничество и коммуникацию между командами, стейкхолдерами и клиентами, создать единое видение и стратегию продукта, портфеля или предприятия, устранить дублирование и конфликты.
➠ Ускорить и оптимизировать процесс разработки и поставки продукта, сократить время выхода на рынок, повысить качество и надежность продукта, обеспечить непрерывную интеграцию и доставку
➠ Усилить ориентацию на клиента и ценность, лучше понимать и удовлетворять потребности и ожидания клиентов, получать и использовать обратную связь, проводить эксперименты и инновации.
3.3.7. Основные принципы и практики масштабирования гибких подходов
Масштабирование гибких подходов не означает просто увеличение числа команд, работающих по гибким методам, или копирование одних и тех же практик на разных уровнях организации. Масштабирование гибких подходов требует учета специфики контекста, целей и потребностей каждого проекта, продукта или предприятия, а также поиска оптимального баланса между автономией и согласованностью, стандартизацией и адаптацией, централизацией и децентрализацией. Для этого необходимо следовать некоторым общим принципам и практикам, которые помогают масштабировать гибкость в организации. Ниже мы перечислим и опишем некоторые из них:
➠ Продуктовое мышление и ориентация на ценность. Вся организация должна быть сфокусирована на создании и поставке продуктов, которые решают проблемы и удовлетворяют потребности клиентов, а также дают бизнес-ценность организации. Для этого необходимо определить продуктовое видение и стратегию, а также продуктовые цели и метрики, которые будут направлять и измерять работу всех команд и стейкхолдеров. Также необходимо организовать работу по принципу потока ценности, то есть по цепочке действий, которые преобразуют идею в готовый продукт, доставляемый клиенту.
➠ Кросс-функциональность и самоорганизация команд. Каждая команда должна состоять из специалистов разных областей и компетенций, которые могут совместно решать задачи и доставлять ценность клиентам. Команды должны иметь достаточную автономию и полномочия для принятия решений и управления своей работой, а также ответственность за свои результаты. Команды должны также постоянно совершенствовать свои процессы и практики, обучаться и делиться знаниями друг с другом.
➠ Инкрементальная и итеративная поставка. Вместо длительных и рискованных циклов разработки и поставки организация должна стремиться к частой и регулярной поставке небольших и работоспособных частей продукта, которые можно проверить и получить обратную связь от клиентов и стейкхолдеров. Для этого необходимо разбивать большие и сложные задачи на меньшие и более простые, а также использовать короткие и фиксированные временные интервалы (итерации или спринты), в течение которых команды планируют, разрабатывают, тестируют и доставляют инкремент продукта.
➠ Сотрудничество и обратная связь. Для успешного масштабирования гибких подходов необходимо обеспечить эффективную коммуникацию и координацию между всеми участниками процесса разработки и поставки продукта, включая команды, стейкхолдеров и клиентов. Для этого необходимо использовать различные формы и каналы общения, такие как ежедневные совещания, демонстрации, ретроспективы, обзоры, синхронизации и т. д. Также необходимо собирать и анализировать обратную связь от клиентов и стейкхолдеров и на ее основе внедрять улучшения.
➠ Адаптивность и экспериментирование. Организация должна быть готова к изменениям в рыночной среде, потребностях клиентов и технологическом прогрессе, а также способна быстро и гибко реагировать на них. Для этого необходимо поддерживать культуру обучения и инновации, а также проводить эксперименты и проверять гипотезы, прежде чем вкладывать ресурсы в разработку и поставку продукта. Кроме того, необходимо избегать излишней документации и бюрократии, а также минимизировать технический долг и зависимости.
3.3.8. Основные фреймворки и модели масштабирования гибких подходов
Существует множество фреймворков и моделей, которые предназначены для масштабирования гибких подходов в разных контекстах и ситуациях. Некоторые из них основаны на адаптации и расширении существующих гибких методов, таких как Scrum или Kanban, а другие представляют собой более комплексные и системные решения, которые включают в себя различные уровни, роли, артефакты и процессы. В этом подразделе мы кратко рассмотрим некоторые из наиболее популярных и известных фреймворков и моделей масштабирования гибких подходов, а также их особенности, преимущества и недостатки.
3.3.8.1. Модель Spotify
Модель Spotify – это гибкая модель организации работы, которая была разработана и применена в компании Spotify, известной своим музыкальным стриминговым сервисом (рис. 3.26). Модель Spotify не является формальным фреймворком, а скорее набором практик и принципов, которые можно использовать для создания гибкой и инновационной культуры в организации.
Без сомнения, модель Spotify – одна из самых часто упоминаемых в процессе масштабирования гибких подходов. Многие элементы, упомянутые в их обучающем видео Spotify Engineering Culture в 2014 году, входят в состав проприетарных Agile-фреймворков[50] крупнейших компаний.
Рис. 3.26. Модель Spotify
Модель Spotify основана на концепции сквадов (squads, часто говорят отряды) – маленьких кросс-функциональных и самоорганизованных команд, которые работают над одной функциональностью или частью продукта. Сквады объединяются в трайбы – большие группы, которые работают над одним доменом или областью продукта. Также в модели Spotify есть другие структуры, такие как:
➠ Отделение (chapter, часто говорят «чаптер») – это группа людей с одинаковым набором навыков или функций, например фронтенд-разработчики, тестировщики, дизайнеры и т. д. Отделение формируется внутри племени, которое представляет собой большую группу людей, работающих над одним продуктом или доменом. Цель отделения – развивать навыки его членов и поддерживать обмен информацией и последовательность. Отделение возглавляет лидер (также известный как чаптерлид), который является линейным руководителем членов отделения и поддерживает их в личностном росте и решении конкретных задач. Отделение регулярно собирается для обсуждения лучших практик, стандартов и общих проблем. Часто отделения называют центрами практик или центрами компетенции[51].
➠ Гильдия (guild) – более широкая и неформальная группа людей, которые разделяют общий интерес или страсть к какой-то теме или области знания. Гильдии могут включать в себя членов разных отрядов, трайбов и отделений, а также других сотрудников компании. Например, гильдия пользовательского интерфейса может включать дизайнеров и фронтенд-разработчиков. Гильдии организуют регулярные или спонтанные встречи, на которых обмениваются идеями, опытом и лучшими практиками, а также проводят обучения, ворк-шопы и хакатоны. Гильдии помогают распространять знания и инновации по всей компании, а также повышать мотивацию и вовлеченность сотрудников.
Еще один компонент, который нельзя не упомянуть, – это механизм поезда поставок (release train). Он позволяет нескольким командам работать над одним продуктом, чтобы при слиянии инкремент одной команды не ломал инкременты других. Производится ритмичное тестирование поставки релиз-кандидата по расписанию, по аналогии с поездом, который отходит в определенное время. Если инкремент не успевает на поезд, то не вливается в поставку, а если не проходит тестирование (ломает другие инкременты), то не вливается в поставку или вливается с отключенным feature-toggle (в отключенном состоянии при помощи механизма feature-toggling, описанном в 2.1.7).
3.3.8.2. Scaled Agile Framework
Scaled Agile Framework (SAFe)[52] – это гибкий фреймворк для разработки и поставки продуктов и решений, который позволяет масштабировать Agile-подходы на уровне предприятия. SAFe основан на принципах Lean и Agile, а также включает в себя четыре уровня: командный, программный, большого решения и портфельный. SAFe предлагает ряд ролей, артефактов и процессов, которые помогают координировать и синхронизировать работу множества команд, работающих над одним или несколькими продуктами или решениями. Он также поддерживает различные конфигурации в зависимости от размера и сложности организации и продукта.
SAFe тоже имеет в своем составе практику поездов поставок, для этого организуется синхронизация спринтов.
SAFe – самый популярный фреймворк для внедрения в уже существующих организациях. За счет большого комьюнити он постоянно актуализируется и включает множество нюансов организационных процессов, которые при этом органично складываются в целостную картину. Еще один его плюс – большое количество опытных экспертов по внедрению.
Представители классических Scrum-школ критикуют Scrum за то, что у него «тяжелая верхушка», намекая на то, что на каждом уровне присутствует большое количество непроизводящих ролей. Также есть шутка, что именно благодаря этому внедрение и не вызывает сопротивление: каждому непроизводящему сотруднику найдется место в новой структуре.
Large Scale Scrum (LeSS) – это гибкий фреймворк для масштабирования Scrum на уровне нескольких команд, работающих над одним продуктом. LeSS стремится сохранить простоту и эффективность Scrum, а также избегать излишней стандартизации и бюрократии. LeSS основан на том, что один продукт имеет один продуктовый бэклог, одного владельца продукта и одно определение завершенности. Он также предполагает, что команды координируют свою работу через совместное планирование, демонстрацию и ретроспективу, а также через общие роли, такие как Scrum-мастер и коуч. LeSS имеет две конфигурации: LeSS и LeSS Huge, которые зависят от числа команд.
LeSS хорошо себя показывает, когда продукт вырастает от одной до нескольких команд. Он позволяет на этом масштабе обходиться минимумом организаторских и управляющих ролей, делая упор на количество разработчиков в организации, что дает экономическую оптимальность и большую скорость.
Важно учесть, что с ростом числа команд возрастает потребность в ролях, обслуживающих такие процессы, как межкомандное взаимодействие, развитие компетенций внутри отделений, управление поездом поставок и т. д. В этом случае, обычно после размеренности 8-10 команд, возможностей LeSS может не хватать.
Многие считают SAFe противоположностью LeSS из-за фокуса второго на минимальность управляющих ролей.
3.3.8.3. Scrum@Scale
Scrum@Scale – фреймворк, первично разработанный Джефом Сазерлендом, а значит, он идеально работает со Scrum (рис. 3.27). Scrum@Scale, по мнению экспертов, обладает одним из лучших балансов в представленности непроизводящих ролей.
До определенного уровня новые роли не выделяются, и ответственность за вопросы масштаба ложится на Scrum-мастеров и владельцев продукта. Одна из идей – выстраивание организации по фрактальному принципу. Каждые пять команд объединяются в Scrum of Scrums (SoS), которые, в свою очередь, могут соединяться в SoSoS. В каждом SoS появляются свои события, например масштабированный дневной Scrum (scaled daily Scrum), на котором присутствуют представители команд для синхронизации.
Рис. 3.27. Модель Scrum@Scale
Согласно некоторым исследованиям, Scrum@Scale занимает пятое место в мире по популярности, но не очень распространен в России. Хотя практика Scrum of Scrums, согласно исследованиям, в России достаточно распространена.
Помимо перечисленных, существует много других популярных фреймворков, таких как Nexus и Disciplined Agile (DA), которые имеет смысл изучить, внедряя масштабирование гибких подходов в организации.