Модель разработки ПО описывает стадии его жизненного цикла и все, что происходит на каждой из них. В книге рассматриваются только самые популярные и основные модели разработки.
Классические модели разработки
Эта модель самая простая, она часто применяется студентами в учебном процессе, например при написании лабораторных работ. Алгоритм этой модели состоит из следующих шагов.
1. Постановка задачи.
2. Создание программы.
3. Тестирование.
4. Анализ результатов тестирования и возможный переход к шагу 1.
Эта модель совсем не актуальна для профессиональной разработки ПО. По таким алгоритмам программисты работали 50–60 лет назад. Излишняя простота в этом случае не позволяет конкурировать с другими моделями.
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается строго после окончания предыдущей, и движение возможно только вперед. При правильном использовании «Водопад» считается наиболее быстрой и простой моделью. Она применяется уже почти полвека, с 1970-х годов.
В конце каждого этапа создается документация, которая служит входными данными для следующего этапа.
1. Сбор требований. Собираются требования к продукту, который надо разработать (определяем требования заказчика).
2. Анализ требований. Требования анализируются, детализируются, уточняются, обсуждаются, документируются (формируем требования к ПО).
3. Проектирование. Проектируются и согласовываются логика работы ПО и требования к дизайну; выбираются инструменты разработки. На выходе получаем документы, подробно описывающие для программистов способ и план реализации указанных требований.
4. Разработка. Реализация.
5. Тестирование. Проверка.
6. Внедрение, поддержка. Вывод в промышленную эксплуатацию и перевод на поддержку.
Когда можно использовать каскадную модель:
• для средних и больших проектов, в которых задействованы десятки программистов и несколько разных команд проекта;
• для проектов, в которых требования и границы прозрачны и точно известны в начале жизненного цикла проекта. То есть когда проект понятен и прост.
«Водопад» подходит для разработки проектов в медицинской и космической отраслях, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
Любая стройка – это пример использования «Водопада» (кейс – проект – стройка – приемка). Также в качестве примера подходит автомобильный конвейер.
При реальной работе в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, допущенных на ранних этапах.
Поэтому появились расширения модели: каскадная с обратной связью и каскадная с промежуточным контролем.
Расширяет стандартную модель, добавляя в нее циклы обратной связи для возврата на предыдущую стадию при изменении требований, для пересмотра отдельных вопросов или исправления ошибок.
Когда ошибки обнаруживаются на более позднем этапе, то пути обратной связи позволяют вернуться на тот этап, на котором была допущена ошибка, и исправить ее. А затем эти изменения отражаются на более поздних этапах.
Чтобы предусмотреть возможность возвращения к предыдущим этапам для внесения определенных изменений и пересмотра отдельных вопросов, в качестве одной из вариаций каскадной модели была создана каскадная модель с промежуточным контролем.
В этой модели увеличено время, отведенное на разработку, из-за проведения промежуточных корректировок между фазами жизненного цикла. Это позволяет снизить риски получения некачественного продукта на выходе и повысить надежность системы в целом.
Модель обладает следующими характеристиками взаимодействия этапов:
• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);
• каждый этап имеет обратную связь с предыдущими;
• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;
• этапы перекрываются во времени по причине наличия обратной связи: следующий этап не начинается, пока не завершится предыдущий. При первом проходе по модели вниз, как только обнаруживается ошибка, осуществляется возврат снизу вверх к предыдущим этапам, на которых была допущена эта ошибка. Таким образом, фактически этапы оказываются растянутыми во времени;
• результат появляется только в конце разработки, как и в модели «Водопад».
Эта модель разработки дает возможность создавать продукт по частям – инкрементам. Каждая часть – готовый фрагмент итогового продукта, который в идеале не требует значительных изменений.
В начале работы над проектом определяются все основные требования к системе, после чего выполняется ее разработка в виде последовательности версий. При этом каждая версия – законченный и работоспособный продукт. Процедура разработки по инкрементной модели предполагает на первом большом этапе выпуск продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых инкрементов. Процесс продолжается до тех пор, пока не будет создана полная система.
Мы получаем несколько циклов разработки – своеобразный «мультиводопад». Каждый цикл делится на модули, а каждый модуль – на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.
Когда можно использовать инкрементную модель:
• для проектов, в которых точное техническое задание прописано уже на старте, а продукт должен быстро выйти на рынок.
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техническое задание. То есть итеративная модель жизненного цикла не требует полной спецификации требований на старте.
В этом случае создание начинается с реализации части функционала и становится базой для определения дальнейших требований, иными словами, мы получаем так называемый минимально жизнеспособный продукт (Minimum Viable Product). Этот процесс повторяется снова и снова. Версия может быть неидеальной, главное, чтобы она работала. Понимая конечную цель, мы стремимся идти к ней так, чтобы каждый шаг был результативным, а каждая версия – работоспособной.
Когда можно использовать итеративную модель:
• когда важен анализ рисков и затрат;
• в крупных долгосрочных проектах с отсутствием четких требований или вероятностью их динамического изменения;
• при разработке новой линейки продуктов.
На рисунке показана итерационная «разработка» Моны Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй появляются цвета, в третьей добавляются детали и насыщенность, и процесс завершается. В инкрементной же модели функционал продукта наращивается по кусочкам, и продукт составляется из частей. В отличие от итерационной модели, здесь каждый кусочек – целостный элемент.
Еще она называется Verification and Validation model – модель верификации и валидации. Это усовершенствованная каскадная модель, в которой заказчик и команда программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. V-модель разработки унаследовала структуру «шаг за шагом» от каскадной модели.
В отличие от каскадной, V-model предполагает тщательную проверку и тестирование продукта уже на ранних стадиях разработки – оба процесса идут параллельно. Разработка каждого шага напрямую связана с этапом тестирования. Следующая фаза начинается только после завершения предыдущей, то есть каждое действие по разработке тестируется.
Ее начали использовать в 1988 году. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее включен анализ рисков и предусмотрена разработка проекта посредством прототипирования.
Спиральная модель состоит из четырех повторяющихся фаз, и в ходе процесса разработки проект проходит каждую по несколько раз.
Главные фазы:
1. определение целей, альтернатив, ограничений;
2. анализ, определение и разрешение рисков;
3. фаза разработки и тестирования;
4. планирование новой итерации.
В спиральной модели жизненный цикл разрабатываемого продукта изображается в виде спирали, каждый виток которой соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество, и планируются работы следующего витка спирали. Такая модель позволяет последовательно конкретизировать детали проекта и выбирать оптимальный вариант для реализации.
Таким образом, на выходе из очередного витка мы должны получить готовый протестированный прототип, который дополняет существующий. Прототип, удовлетворяющий всем требованиям, считается готовым к внедрению.
Главная особенность спиральной модели – концентрация на возможных рисках. Для их оценки даже выделена соответствующая стадия. Эта модель часто используется в исследовательских проектах и проектах с высокими рисками.
Это уже не модель, а методология разработки.
Модель разработки ПО описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: правила, техники и принципы, которые делают ее более эффективной. В этом случае мы имеем более практическое описание циклов разработки.
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от двух до шести недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций.
Цели каждой фазы:
• Inception (начальная стадия) – понимание того, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;
• Elaboration (Уточнение) – понимание того, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;
• Construction (конструирование) – создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);
• Transition (внедрение) – создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.
Это фазы управления развитием продукта – итерациями жизненного цикла. И в отличие от «водопада» каждая из фаз может повторяться по несколько раз, отражая изменение требований заказчика продукта.
Методология RUP основана на девяти основных потоках (workflow) – элементах итерации жизненного цикла ПО.
1. Business modeling (бизнес-анализ) – анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей.
2. Requirements (требования) – формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases, формально отображающих требования пользователя в UML. В результате мы получаем документы уровня менеджмента.
3. Analysis and design (анализ и моделирование) – перевод собранных требований в формализованную программную модель. Результат – описание системы на этапе реализации (технический проект); эти документы относятся к уровню разработчиков системы. Язык формализации – Unified Modelling Language (UML). В процессе итеративной разработки эволюционировать будет продукт именно этого потока – модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов.
4. Implementation (реализация, кодирование) – собственно написание кода.
5. Test (тестирование) – тестирование продукта на данной итерации.
6. Deployment (внедрение) – установка продукта на полигоне заказчика, подготовка персонала, запуск системы и приемо-сдаточные испытания, подготовка стандартов упаковки и распространения продукта, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта).
Особенности реализации RUP – временные акценты, а именно – на каких итерациях будут доминировать те или иные потоки, а также наличие универсального языка и набора утилит, позволяющего описывать процесс разработки.
На начальных этапах эволюции продукта основное внимание уделяется формализации проекта (анализ, моделирование), оно направлено на сокращение коммерческих рисков и снижение стоимости ошибок дизайна. Когда картина становится более или менее ясной, начинаются собственно разработка, тестирование и, наконец, внедрение продукта.
Также здесь есть элементы, касающиеся поддержки продукта, – core supporting workflows.
1. Management (управление проектом) – набор административных действий по управлению проектом согласно идеологии RUP. Использует средства управления проектом (см. ниже список продуктов Rational).
2. Configuration management (управление конфигурацией и изменениями) – мощный слой административных действий, направленных на управление версиями продукта. Предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, использование корпоративных стандартов разработки кода и документации, отслеживание изменений и ошибок (bug tracking). Тесно связан с тестированием и поддержкой пользователей (customers support).
3. Environment (окружение) – создание и поддержка средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).
В RUP весь процесс разработки программной системы рассматривается как процесс создания артефактов – начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т. п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть решает, когда и кто должен создать тот или иной артефакт.
Гибкие модели управления командой Agile и Kanban
С английского agile переводится как «подвижный, быстрый, проворный». В русской IT-лексике за этой группой методологий закрепилось определение «гибкие».
В Agile-подходе проект постоянно адаптируется к новым обстоятельствам и требованиям. Вспомним, как устроена разработка по методологии Waterfall.
1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.
Теоретически в Waterfall возможен возврат на предыдущие ступени – например, если оказывается, что ту или иную задачу невозможно выполнить по техническим причинам. В этом случае ТЗ пересматривают, но это скорее чрезвычайная ситуация. В норме конечный продукт должен идеально соответствовать требованиям, целям и задачам, которые были сформулированы до разработки.
Для Agile в приоритете не исходные установки, а актуальные потребности пользователя. Постоянно вносить изменения в ТЗ, даже в самый разгар разработки, для Agile нормально. В гибкой методологии не предусмотрен предварительный генеральный план – напротив, программный продукт пишется практически экспромтом.
Разработка проходит через ряд циклов – итераций. Каждая итерация – это фактически отдельный проект, в котором разрабатывают фрагмент программы, улучшают функциональность, добавляют новые возможности.
Agile – это не метод разработки программного обеспечения. Это принципы организации проектной деятельности, и применить их можно в любой области.
Гибкая методология – не единый подход к разработке, а набор идей и принципов, на которых основаны конкретные практические решения. Можно считать это особой философией, которая задает вектор, а не предписывает производить определенные действия. В Agile есть четыре центральные идеи.
1. Люди и взаимодействие между ними важнее, чем процессы и инструменты.
2. Работающее ПО важнее, чем исчерпывающая документация.
3. Сотрудничество с заказчиком важнее, чем согласование условий контракта.
4. Готовность к изменениям важнее, чем следование первоначальному плану.
В русском переводе идей Agile используется слово «важнее», но в оригинальном тексте вы увидите слово over – «над». При использовании слова «важнее» создается впечатление, что в фокусе находится только левая часть утверждения (все, что над линией over), а на правую часть можно не обращать внимания, если нет желания или не хватает ресурсов (времени и людей).
Это неверное понимание. Идеи Agile говорят нам, что в первую очередь мы должны фокусироваться на левой части утверждения, но при этом необходимо все равно уделить внимание правой части. Она тоже важна, просто чуть менее приоритетна.
Не отрицая важности правой части, мы больше ценим левую. Тогда идеи Agile можно сформулировать так:
• приоритет людей и общения над инструментами и процессами;
• приоритет работающего продукта над полной документацией;
• приоритет сотрудничества с заказчиком над утверждением контракта;
• приоритет готовности меняться над следованием первоначально созданному плану.
1. Наивысший приоритет для нас – удовлетворение потребностей клиента благодаря регулярной и ранней поставке ценного ПО.
То есть для команды, работающей над продуктом или системой, гораздо более приоритетно регулярно и как можно раньше удовлетворять потребности заказчика, предоставляя ему программное обеспечение, чем реализовывать все, что написано в ТЗ.
2. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
Чем чаще, тем лучше. Это позволит планировать и внедрять любые изменения.
3. Изменение требований приветствуется даже на поздних стадиях разработки.
Учитывается, что требования могут измениться на любом этапе разработки. Если изменения вносятся в проект быстро, заказчик может получить конкурентные преимущества.
4. Разработчики и представители бизнеса должны ежедневно работать вместе.
Можно оперативно задавать вопросы и получать ответы.
5. Над продуктом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте для них условия, обеспечьте поддержку и полностью доверьтесь им.
Разделение ответственности и понимание своего вклада в дело помогает работать лучше.
6. Личное общение – наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри нее.
Благодаря частому общению создается чувство единства, которое позволяет членам одной команды чаще и быстрее приходить к одному мнению. Это тоже важно: меньше времени уходит на споры и конфликты, больше времени остается для дела.
7. Работающий продукт – основной показатель прогресса.
Предоставляя работающие программные продукты по окончании каждой итерации и демонстрируя результаты работы команды, мы информируем всех участников о текущем состоянии проекта. В этом случае вероятность неправильно истолковать ситуацию стремится к нулю.
8. Инвесторы, разработчики и пользователи должны иметь возможность бесконечно поддерживать постоянный ритм.
Agile рекомендует использовать постоянный ритм работы и не перегружать людей. Постоянный темп работы позволяет заранее определить, сколько времени займет выполнение той или иной задачи, и дать правдивые обещания по срокам исполнения.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость.
Agile-разработчики приобретают много навыков, помогающих им создавать хорошо спроектированный код. Они постоянно ищут ошибки в коде и, найдя их, немедленно исправляют. Если во время работы над проектом уделять чуть больше внимания написанию качественного кода и исправлению ошибок, чтобы не было технического долга, можно создать надежную основу кода, которую будет легко поддерживать в дальнейшем.
10. Простота – это искусство не делать лишней работы.
Постоянная работа с клиентами и заказчиками, получение обратной связи – эффективный способ создания максимально полезного и ценного программного обеспечения. Во время такой работы можно выяснить, что какая-то функция не несет ценности, а значит, в долгосрочной перспективе для компании дешевле не создавать ее вовсе.
11. Лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Нужно стремиться к созданию самоорганизующейся команды: именно в ней рождаются наиболее эффективные и качественные решения.
Если разработчики могут принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и в соответствии с этим корректировать стиль своей работы.
Чтобы быть гибкой, команда должна совершенствовать способы создания программного обеспечения. Agile-команды постоянно занимаются контролем и адаптацией: они следят за тем, как работают их проекты, и используют эти знания для улучшения эффективности в будущем. Они делают это не только в конце: на ежедневных встречах члены команды ищут возможности для усовершенствования проекта и вносят изменения в текущую работу, если в этом есть необходимость.
Agile – это не методология, а набор привычек, убеждений и принципов, которыми вы руководствуетесь в работе, делах и жизни.
Что показывает эта картинка? Есть философия Agile, которая базируется на ценностях (на верхнем уровне) и принципах (более подробно), которые мы только что рассматривали. Далее на этих принципах строится много практик и моделей разработки и управления проектом. Один набор практик на рисунке – это Scrum, другой – XP (экстремальное программирование) и т. д.
На рисунке представлена матрица Стейси.
Эта матрица, похожая на модель Кеневин, была создана профессором менеджмента Ральфом Стейси. Она называется матрицей согласованности и определенности. Модель применяется для оценки проекта с точки зрения неопределенности. Так можно оценить применимость Agile к проекту.
Выделенные на рисунке области соответствуют доменам из теории запутанности, известной как Cynefin Framework. Эта теория делит все системы на четыре домена по степени неопределенности: простые, сложные (упорядоченные), комплексные (запутанные) и хаотичные.
• Простые задачи может решить любой человек, воспользовавшись инструкцией.
• Сложные системы можно описать, но в них слишком много переменных, поэтому для решения таких задач нужны профессионалы.
• Запутанные системы предполагают наличие большого количества факторов, но причинно-следственные связи между ними непонятны. Поэтому мы не можем сразу определить лучший способ решения таких задач. Нам необходимы гипотезы и эксперименты.
• Хаотичные системы – это запутанные в кубе. Количество факторов в них еще больше, причинно-следственные связи в основном неизвестны.
Модель имеет две оси, соответствующие степеням определенности в отношении технологий и в отношении требований.
• Горизонтальная ось демонстрирует уровень технической неопределенности проекта и показывает, насколько понятен способ достижения цели проекта (знаем ли мы, КАК делать?)
• Вертикальная ось показывает уровень неопределенности требований к проекту – степень согласия по поводу того, что должно быть сделано в результате проекта (знаем ли мы, ЧТО делать?)
Если эта степень определенности очень высокая, то есть вы способны четко описать задачу, точно знаете, как ее реализовать, и можете зафиксировать это в документах так, что исполнитель, следуя инструкциям, получит правильный результат, то вам подойдут любые методы, в том числе и водопадная модель. В остальных случаях лучше использовать Agile.
Систему канбан придумали японцы. Она сформировалась к 1950-м годам на производстве автомобилей «Тойота». Топ-менеджеры компании во главе с ее президентом Тайити Оно поставили цель: выпускать автомобили с максимальной скоростью, а складские запасы свести к минимуму.
Тайити Оно вместе с соратниками обратил внимание на работу американских супермаркетов, где покупатель сам выбирал необходимые товары. Роль «супермаркета» в корпорации Toyota выполнил склад.
Японцы взяли за основу принцип работы супермаркета и внедрили его на заводы. Детали для сборки начали поставлять в цеха небольшими партиями по мере необходимости, что разгрузило склады. Это касалось не только работы с поставщиками, но и взаимодействия между подразделениями.
На заводе «Тойота» установили правило: каждый цех по цепочке заказывает другому ровно столько деталей, сколько требуется для сборки на месяц вперед.
Суть подхода применительно к автопроизводству сводилась к тому, что любая запчасть автомобиля должна изготавливаться не раньше и не позже, чем в ней появится необходимость. Помимо прочего, это означало отказ от объемных складских запасов, что снижало текущие издержки на изготовление запчастей и содержание складов. По сравнению с американским автопромом, где склады с большими запасами деталей были нормой, такой подход стал новаторским.
Само слово «канбан» с японского переводится как «сигнальная карточка» / «бирка» / «знак».
Карточки (бирки) крепились к таре с деталями. На таких бирках указывалась информация о номере и количестве деталей, а также о том, какой отдел их отправляет и куда они должны прибыть.
Работник, непосредственно занимавшийся монтажом и сборкой машин, – нижний поток – забирал детали из тары, к которой был прикреплен «канбан» с запросом для склада. Карточка снималась и вместе с пустым ящиком передавалась транспортировщиком на склад. Там другой работник уже подготавливал новую тару с запчастями и крепил на нее производственный «канбан» – бирку с информацией о произведенных запчастях.
Производственный «канбан» заменялся на «канбан» с запросом для склада и отправлялся на производственную линию запчастей – верхний поток. В результате производилось именно то количество деталей, которое указывалось в карточке. Тара с новыми запчастями относилась транспортировщикам на монтажную линию и дальше по цепочке.
Система канбан, продолжая приносить пользу на производственных конвейерах, проникла и в сферу IT. Карточки стали использоваться иначе, но сохранился основной принцип фиксирования на них производственных задач – визуализация.
Канбан позволяет избежать перепроизводства и оптимизировать рабочие процессы так, чтобы производить столько продукции, сколько нужно, и в то время, когда нужно.
Результатом внедрения этой системы является ускорение работы, а также прозрачность того, какие процессы требуют большего вовлечения, а какие – нет.
Kanban – это метод улучшения процессов разработки путем визуализации и активной работы над незавершенными задачами, а также часть Agile-философии. То есть это не полноценная методология, а просто удобный инструмент, который можно использовать практически с любым подходом к разработке.
Kanban делает нагляднее работу над проектом, позволяет отслеживать выполнение отдельных задач и создание функциональных возможностей программного продукта. Кроме того, с этой системой легче контролировать нагрузку специалистов.
Kanban базируется на определенных ценностях.
1. Прозрачность. Это визуализация задач на доске, дающая понимание того, на каком этапе они находятся, и открытый обмен информацией между участниками команды. Прозрачность – это трамплин для создания безопасной среды и психологической безопасности.
2. Баланс. В основе Kanban лежит простая мысль: объем незавершенной работы необходимо ограничивать. Важно сохранять баланс в работе и не перегружать сотрудника задачами. Красота Kanban начинает сиять в полную силу, когда мы создаем сбалансированную систему работы. Когда количество запросов совпадает с производительностью, это позволяет нам установить устойчивый ритм, который приводит к упорядоченному режиму работы, дает возможность все проконтролировать и помогает избежать сюрпризов. Баланс между работой и личной жизнью – вот то, о чем мы говорим.
3. Сотрудничество. Совместная работа и ее совершенствование: члены команды сотрудничают друг с другом и с заказчиком.
4. Клиентоориентированность. На протяжении всего срока работы стремитесь вовремя завершать задачи и плавно наращивать ценность вашего труда для клиента.
5. Поток. Необходимо понимать, что работа – поток создания ценности. Поток в Kanban – это последовательность этапов, через которые проходит каждая задача. Важно сохранять эту последовательность и управлять потоком: находить и анализировать слабые места в процессе, исправлять их.
6. Лидерство. Нужно поощрять инициативу на всех уровнях организации: от каждого работника до высшего руководителя. Лидер должен вдохновлять окружающих своим примером. Хорошее лидерство помогает укрепить все прочие ценности, а плохое лидерство может быстро уничтожить их. Хорошее руководство создает хорошие системы работы (или ищет помощи в их создании) и сильную культуру.
7. Понимание. В Kanban эта ценность проявляется в понимании текущих ролей, процессов и того, почему все устроено таким образом.
8. Согласие. Люди должны уметь договариваться, даже если между ними возникают разногласия на пути к общей цели.
9. Уважение. Тут вроде все понятно: уважение к коллегам и совместной работе необходимо для комфортной и продуктивной деятельности.
Существует шесть основополагающих принципов Kanban, которые можно разделить на две группы:
• принципы управления изменениями;
• принципы предоставления сервисов.
Основная трудность заключается в сопротивлении команд новому. Kanban признает существование этого человеческого фактора и руководствуется тремя принципами управления изменениями.
1. Начните с того, что есть сейчас. Мы не начинаем резко менять структуру организации, процессы и роли. Kanban – это последовательные и плавные улучшения.
Когда мы визуализируем текущий рабочий процесс, мы не вводим никаких изменений. Мы просто делаем прозрачной работу команды, течение задач по потоку и перемещение из стадии в стадию от самого начала до завершения. Когда мы не вводим новые роли, люди не задаются вопросом, что будет с их текущими обязанностями. Мы стремимся избегать ситуаций, которые могут вызвать у сотрудников страх потери работы или опасения по поводу несоответствия новым ожиданиям.
Таким образом, у нас есть все шансы получить поддержку команды на старте изменений.
2. Договоритесь об эволюционном развитии. Команда должна прийти к единому мнению, что постоянные изменения – это способ улучшить процесс разработки. Глобальные перемены несут большой риск, поэтому Kanban поощряет небольшие эволюционные изменения.
Как работает эволюционный подход.
Мы последовательно улучшаем нашу работу (процессы) или продукт (критерии соответствия ожиданиям клиентов) через серию маленьких безопасных экспериментов (или итераций). Мы ищем ближайшую точку неудовлетворенности и устраняем ее. Если в результате наступают улучшения, мы закрепляем это новое состояние. Если становится хуже или ничего не меняется, делаем шаг назад.
Таким образом, мы эволюционно улучшаем наши процессы и продукт.
3. Поощряйте развитие лидерства на всех уровнях. Приветствуются проявления инициативы каждого члена команды разработки. Важно наличие примера лидерства и терпимость к ошибкам.
Каждая организация – это система взаимозависимых сервисов со своими правилами поведения. Мы все – один большой общий сервис для клиента. Иными словами, мы в команде предоставляем некий сервис или набор сервисов (если говорить о разработке продукта, то мы оказываем сервис – это разработка продукта).
Так вот, если рассматривать Kanban в сервисной парадигме, то есть с точки зрения того, что мы предоставляем какой-либо сервис Заказчику, то важно придерживаться следующих принципов предоставления сервисов.
1. Выясните потребности и ожидания заказчика. Постарайтесь понять потребности и ожидания клиентов и сосредоточьтесь на них
2. Управляйте работой, а не людьми, дайте возможность людям самим организоваться вокруг работы.
3. Развивайте правила, чтобы улучшить показатели и удовлетворенность заказчика сервисом. Регулярно пересматривайте систему и правила для улучшения результатов практик Kanban.
1. Визуализируйте.
2. Ограничивайте количество незавершенной работы.
3. Управляйте потоком работы.
4. Используйте явные правила работы.
5. Вводите циклы обратной связи (каденции).
6. Улучшайтесь и эволюционируйте.
Эти практические приемы мы используем для улучшения работы и повышения качества сервиса.
➤ Визуализация
Чтобы контролировать выполнение задач было проще, процесс работы визуализируют на Kanban-доске, разделенной на несколько секторов. Сами задачи записываются на карточках. На доске отображаюся статусы задач, что позволяет оценить, на каком этапе производственного процесса сейчас находится каждая из них. Это может быть как реальная доска или стена со стикерами, так и виртуальная доска в таск-трекере, например Jira.
В дополнение к этому удобно отслеживать время на каждом участке: мы всегда можем увидеть пробелы и скорректировать их. Визуализация хорошо показывает узкие места, очереди, отклонения и потери – все, что отрицательно влияет на продуктивность команды.
Kanban не дает указаний в отношении конструкции канбан-досок.
• Число столбцов выбирается исходя из ситуации и типа проекта. Важно наглядно отобразить основные этапы проекта и их статус. В самом простом варианте используют столбцы «В ожидании», «В работе» и «Выполнено», но можно добавлять дополнительные. Каждый столбец соответствует определенному этапу работы в потоке поставки ценности.
• На доске при необходимости можно выделить дорожки, каждая из которых соответствует задачам с определенным классом обслуживания.
➤ Работа с доской
1. Все задачи, которые поступают от заказчика, записываются на стикерах и размещаются в графе «В ожидании». На примере это графа «Сделать». Им можно назначать приоритет: более важные размещают выше и принимают в работу в первую очередь, а второстепенные выполняются после завершения приоритетных.
2. Как только команда приступает к работе над очередной задачей, соответствующий листок переносится в графу «В работе». На примере это графа «Выбрано».
3. Тут важно зафиксировать первую точку – точку принятия обязательств – когда заказчик подтвердил желание получить рабочий элемент, а команда подтвердила возможность выполнения задачи.
4. Вторая точка – точка поставки – принятие выполненного рабочего элемента (после колонки «Приемка»), когда заказчик принимает работу команды.
5. После выполнения задачи стикер отправляется в последнюю графу. В нашем примере – «Готово».
Очень важно постоянно обновлять статусы задач, чтобы любой человек, задействованный в работе над проектом, мог в любую секунду посмотреть эти статусы.
➤ Ограничение количества незавершенной работы
Еще одна значимая практика в Kanban – ограничение количества незавершенной работы. Незавершенная работа находится между двумя точками: «обязательство» и «поставка». На доске количество задач-листков, находящихся в работе на одной стадии, должно быть ограничено. Стабильно выполнять небольшое количество задач лучше, чем взяться за множество задач и толком не закончить ни одной. Для такого ограничения в Kanban вводится понятие work in progress (wip) – количество задач в работе. Точный максимум определяют, исходя из возможностей коллектива. Взяться за следующую задачу разработчик сможет не раньше, чем закончит работу с предыдущей.
Искусственное ограничение выглядит контрэффективным, но на практике оно вырабатывает совершенно иной подход и незавершенным делам. Благодаря Kanban-доске любая задержка или промедление в выполнении работы будет сразу заметна не только самому разработчику, но и всем коллегам. Это стимулирует не бросать начатое, столкнувшись со сложностями. Когда объем незавершенной работы не ограничен, можно позволить себе переключиться на более простые задачи, оставив сложную на потом. Это увеличивает риск того, что она навсегда останется в статусе отложенной.
Проблема разработчика – это проблема команды. Kanban стимулирует программистов активнее сотрудничать, обсуждать производственные вопросы и искать способы их решения.
Количество задач в работе можно уменьшать или увеличивать при необходимости. Это не постоянная величина, которая выбирается один раз, тут можно экспериментировать. Ограничение количества незавершенной работы позволяет контролировать нагрузку команды и получать результат точно в срок.
➤ Управление потоком работы
Цель – сделать поток работы равномерным и предсказуемым, сфокусироваться на результате, а не на утилизации ресурсов. Для того чтобы работа быстрее завершалась, нужно следить за ней, а не за людьми, которые ее делают.
Kanban помогает вам в этом с помощью kanban-досок. Когда мы выносим всю работу на видное место, нам становится проще понять, где именно возникают проблемы, а это позволяет оперативнее отреагировать и найти решение. Таким образом, работа быстрее движется к завершению.
Пожалуй, именно поэтому у данной практики есть более развернутая формулировка: «Управляйте потоком работы, а не людьми. Дайте людям самим организоваться вокруг нее».
➤ Используйте явные правила
Следующая практика говорит о важности использования явных правил в работе. Цель – сделать прозрачными договоренности, снизить зависимость от человеческого фактора. Другими словами, нужно определить правила игры.
Одно из правил – это подсчет wip. Самый частый пример явных правил – критерии готовности (definition of done) для вытягивания работы на следующий этап (то, что команда подразумевает под словом «готово» применительно к задаче). Например, сначала задача должна быть сформулирована в виде пользовательской истории с критериями приемки. И только после этого ее можно будет перенести в «ожидает разработки». Или реализованная задача должна пройти нагрузочное тестирование, чтобы ее можно было перенести в «приемка», и т. п.
➤ Используйте петли обратной связи
Практика больше известна как «встречи в Kanban». Цель – получить информацию о показателях системы и результатах совершенных ранее действий, спланировать следующие эксперименты и замкнуть петлю обратной связи.
➤ Улучшайтесь и эволюционируйте
Цель этой практики – научиться управлять изменениями команды или организации. Мы не рисуем большое красивое будущее в виде точки «Б» и не строим грандиозный план, как туда попасть.
Вместо этого мы здесь и сейчас ищем источники неудовлетворенности в работе, в наших результатах, в том, как мы обслуживанием клиентов, и формулируем гипотезы, как эти неудовлетворенности устранить. Из соображений безопасности эксперименты должны быть небольшими, но в то же время они должны иметь реальный эффект устранения неудовлетворенности.
Если после внедрения эксперимента неудовлетворенность исчезла, то мы закрепляем результат. Если ничего не изменилось или стало хуже, то делаем шаг назад. Более подробно об этом рассказано в разделе про принципы управления изменениями.
Kanban использует классы обслуживания (правила обработки задач), чтобы повысить приоритет определенных типов работ или нивелировать такое воздействие на бизнес, как стоимость задержки.
Стоимость задержки – это недополученная прибыль или понесенные издержки из-за не вовремя оказанных услуг. Рассмотрим влияние стоимости задержки и соответствующие классы обслуживания на примерах.
1. Ускоренный класс – неотложная скорая помощь, реанимация. Едет по выделенной полосе. Нет времени откладывать решение проблемы, необходимо все сделать как можно скорее. Пример: блокирующие дефекты.
2. Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода. Пример: проект в виде ФЗ с фиксированной датой начала действия. Не успеем вовремя – есть риск потерять лицензию.
3. Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, то и прибыль получаем сразу. Если делаем долго, то и прибыль получаем нескоро.
4. Нематериальный класс – делаем работу, но явной прибыли она не приносит, стоимость задержки растет медленно. Например, прибираться в доме можно нерегулярно, но через полгода придется делать генеральную уборку.
Каденция – термин из музыки и бега, обозначающий завершение музыкального акта или ритма. Каденциями называют регулярные встречи – петли обратной связи, приводящие к эволюционным изменениям и эффективному предоставлению сервисов/продуктов. Регулярность задает ритм, с которым течет поток работы.
Петли обратной связи – неотъемлемая составляющая любого контролируемого процесса, она необходима для эволюционных изменений. Цель – получить информацию о показателях системы и результатах совершенных ранее действий, спланировать следующие эксперименты и замкнуть петлю обратной связи.
Канбан предусматривает семь способов получения обратной связи. Выбор подходящей каденции зависит от обстоятельств и имеет большое значение для получения хороших результатов.
1. Канбан-митинг (ежедневная). Обсуждаем статус задач. Канбан-митинг чем-то напоминает стендап: сначала каждый делится проблемами и планами на день, а потом все вместе обсуждаем, как решить проблему. Уделяем внимание заблокированным задачам.
2. Встреча по наполнению очереди (обычно раз в одну-две недели). Берем на себя обязательства за то, что будет делать предоставляемый сервис, то есть планируем, какой продукт будем реализовывать.
3. Встреча по планированию поставки (согласно частоте поставки, обычно раз в две недели). Возвращаем выполненные обязательства и обсуждаем продукт, который будем внедрять.
4. Встреча по обзору сервиса поставки (обычно раз в две недели). Проводится для анализа и совершенствования эффективности сервиса. Обсуждаем качество сервиса и способы его улучшения, если в этом есть необходимость. На этих встречах осуществляется проверка эффективности команды в отношении выполнения обязательств, качества и своевременности реализации задач.
5. Операционная встреча (обычно раз в месяц). Обсуждаем качество взаимодействия связанных сервисов. Если мы взаимодействуем с кем-то еще, например с техподдержкой, то собираемся вместе и проводим обзор предоставляемых сервисов/продуктов для максимизации ценности сервиса для заказчика, то есть пересматриваем качество, ищем возможность улучшить результат.
6. Встреча по обзору рисков (обычно раз в месяц). Изучаем риски, обсуждаем попытки минимизировать их. Обсуждаем риски, связанные с блокировками выполнения задач и их влиянием на работу сервиса. К примеру, результатом встречи может быть изменение класса обслуживания/приоритета задачи.
7. Встреча по обзору стратегии (обычно раз в квартал). Используя метрики, обсуждаем изменения в стратегии/концепции разработки предоставляемого сервиса/продукта, а также анализируем внешние обстоятельства, возникающие при управлении сервисами.
Частоту встреч можно отрегулировать под себя. От некоторых допустимо вообще отказаться, если они не несут для вас никакой ценности. Например, 1–4 встречи – основные. А три последние вводятся на уровне организации и нескольких связанных сервисов. Но важно помнить, что обмен информацией между всеми уровнями управления принесет организации максимальную гибкость.
В Kanban выделяют три роли.
1. Менеджер сервиса запросов (Service Request Manager, менеджер продукта, владелец продукта) отвечает за изучение потребностей и ожиданий заказчиков, содействует выбору и приоритизации рабочих элементов на собраниях по пополнению очереди.
2. Менеджер сервиса поставки (Service Delivery Manager, менеджер потока, менеджер поставок) отвечает за поток работы, в ходе которого выбранные рабочие элементы поставляются заказчикам. Проводит Kanban-митинги и собрания планирования поставки.
3. Команда разработки.
Расшифровывается как System Thinking Approach for Introducing Kanban и переводится как «системный подход к внедрению Kanban». То есть вы проходите определенные шаги, оцениваете задачи, проблемы и ожидания. И из этих элементов получаете взгляд на систему в целом. Здесь будут видны все недостатки процессов и пути по их исправлению.
Восемь ключевых шагов – это те самые действия, которые нужно последовательно совершить для внедрения Kanban-метода.
1. Определить потребителей сервиса.
2. Выявить источники неудовлетворенности.
3. Проанализировать спрос.
4. Проанализировать возможности.
5. Построить модель рабочего процесса.
6. Определить классы сервиса.
7. Создать проект визуализации Kanban-системы.
8. Представить систему.
Пожалуй, один из самых важных разделов инструмента. Расскажите о вашем сервисе поставки и о том, кто является его менеджером.
Вспомогательные вопросы: какой сервис вы предоставляете? кто отвечает за то, что сервис будет предоставлен вовремя и в надлежащем качестве?
Здесь под словом «сервис» понимается ваша деятельность. Представьте себя и свою работу услугой, которую вы оказываете вашим клиентам (заказчикам).
В этом разделе нужно отразить внутренние и внешние (с точки зрения клиента) источники неудовлетворенности и изменчивости.
Внутренние источники неудовлетворенности – то, чем недовольна сама команда сервиса.
Примеры внутренних источников неудовлетворенности: перегрузки, переработки, частое переключение между задачами, частые простои, блокировки не по вине исполнителей, ссоры и конфликты с заказчиками.
Внешние источники неудовлетворенности – это то, чем недовольны заказчики сервиса или смежные сервисы.
Примеры внешних источников неудовлетворенности: слишком длительные сроки, нарушение обещаний по срокам, непрозрачность рабочих процессов, конфликты и ссоры с исполнителями.
Этот раздел содержит шаблон анализа запросов. Какие задачи вам поступают? Истории, собранные в этом разделе, часто содержат слова, которые раскрывают типы рабочих элементов, скрытую информацию о рисках, неудовлетворенные ожидания, внешние и специфичные зависимости (раздел «Отображение рабочих процессов»), неявные классы обслуживания.
Для каждого типа рабочего элемента соберите следующую информацию.
• Источник запроса – от кого приходят запросы на поставку типовых рабочих элементов. Пример: пользовательская история, проект, технический долг, договор, оформление сделки, инцидент, соискатель и так далее.
• Место назначения – куда поставляются результаты работы сервиса. Пример: они могут возвращаться заказчику или передаваться ниже по течению: в маркетинг, соседнему сервису, а могут оставаться в вашем сервисе.
• Частота возникновения – количество запросов на единицу времени. Плохой пример: «У нас 300 элементов в бэклоге». Если вам дадут такой ответ, спросите, откуда взялись эти элементы и как они попали в бэклог. Хороший пример: «Два раза в неделю».
• Характер (или природа) запроса – внимание к любым закономерностям. Пример: прибегает в последнюю минуту; ссылается на генерального директора; спокойный, можно договориться.
• Ожидания клиента – представления заказчика о времени поставки элемента. Могут быть необоснованными. Пример: через неделю, через два дня, сегодня, по готовности.
Нарисуйте рабочий процесс для нескольких типов рабочих элементов (3–4 шт.). Есть ли между ними сходства и различия? Осуществляется ли одновременная и неупорядоченная деятельность?
Рисовать можно любым удобным вам способом: например, изображать человечков, передающих работу с этапа на этап. Или отражать каждый из этапов на стикерах. Или использовать блок-схему.
Для каждого типа рабочего элемента укажите класс(ы) обслуживания, соответствующие им политики и ожидания поставки.
Всего существует четыре архетипа классов обслуживания. Они основаны на стоимости задержки. Задайте вопрос для каждого типового элемента из раздела 2: «Какую сумму денег мы потеряем, если не начнем делать эту работу прямо сейчас?» Варианты ответов:
1. Сразу потеряем очень много, необходимо начать в срочном порядке. Это ускоренный класс обслуживания.
2. Ничего не потеряем до тех пор, пока не наступит дедлайн. Нужно сделать работу к определенной дате. Это класс обслуживания для задач с дедлайном.
3. Будем терять постепенно, если не сделаем эту работу. Это стандартный класс обслуживания.
4. Очень долго ничего не будем терять, если не приступим к работе, но когда накопится критическая масса таких задач, бизнес может остановиться. Это нематериальные задачи, улучшайзеры – задачи, которые экономят нам время, автоматизируют типовые операции, сохраняют наши технические системы в актуальном состоянии. Это нематериальный класс обслуживания.
Укажите для каждого типа рабочего элемента входную и выходную каденцию – частоту наполнения и поставки типового элемента сервисом.
Здесь речь идет о том, что какие-то типовые элементы мы можем брать в работу раз в неделю, а какие-то не обязаны ждать общего пополнения, поэтому передаются в работу по мере поступления.
Так же и с планированием поставки. Здесь важно договориться о календарной дате и времени, когда вы будете это делать.
Сделайте набросок, прототип будущей канбан-доски, определите основные элементы. Они могут включать в себя отдельные дорожки, двухуровневую структуру, использование цвета для карточек и т. д. Не обязательно делать в этом разделе миниатюрную копию фактической доски: важен именно набросок.
Гибкие модели управления командой Scrum
Scrum – это процессный фреймворк для разработки, поставки и сопровождения сложных продуктов, который использует итеративно-инкрементальный подход и базируется на теории эмпирического управления.
Термин Scrum позаимствован из регби и переводится как «схватка». Это такой элемент игры, в котором от каждой команды участвуют по восемь игроков. Они обхватывают друг друга руками, выстроившись в три линии и сомкнувшись с соперниками, и в образовавшийся туннель вкидывают мяч, а игроки от команд пытаются завладеть мячом. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность действий каждого участника схватки и четкое понимание цели – то есть важна командная работа.
Создатели Scrum Джефф Сазерленд и Кен Швабер, наблюдая за игрой в регби, поняли, что как раз командной работы, слаженности не хватает и разработчикам ПО. Так появился Scrum.
Scrum-гайд – документ, описывающий набор ролей, событий и артефактов, которые должны присутствовать в ходе работы над продуктом по Scrum. Согласно гайду, никакие указанные в нем элементы не должны быть проигнорированы, иначе это будет уже не Scrum.
Эмпирическое управление – метод проб и ошибок. Руководитель действует опытным путем, получает некий результат, анализирует его и выстраивает свою дальнейшую работу, исходя из анализа.
Итеративный подход – повторение одной и той же последовательности действий из раза в раз. Это можно представить в виде замкнутого цикла, который повторяется многократно. Например, итерацией в Scrum являются спринты, длительность которых может быть от одной до четырех недель.
Инкрементальный подход – частичная реализация и медленное наращивание функциональности, дополнительных характеристик. Фактически это «приращение» чего-либо к чему-то уже имеющемуся. В данном контексте это означает, что с каждым витком итерации происходит «прирост» функциональности продукта.
В основе Scrum лежат три принципа: прозрачность, инспекция и адаптация.
➤ Прозрачность
Подразумевает, что между членами команды нет недомолвок, секретов и никто не скрывает важную для процесса информацию. Это относится в том числе и к отношениям между людьми. Принцип прозрачности очень важен для функционирования Scrum: там, где есть непрозрачность, закрытость и недомолвки, возникают ошибки и теряется возможность внести изменения, необходимые для усовершенствования процессов.
Когда мы не обладаем полной информацией, например нам не хватает данных, мы не можем делать выводы и вносить изменения для того, чтобы решать проблемы и задачи.
Прозрачность процессов в Scrum – не просто рекомендация, а именно принцип работы.
Примеры
1. Все участники процесса должны пользоваться его общей терминологией.
2. Те, кто выполняют работу и принимают рабочий продукт, должны иметь общие критерии готовности (definition of done).
➤ Инспекция
Принцип инспекции подразумевает, что мы оперативно отслеживаем все изменения в процессе работы, в ходе разработки продукта, а также изменения в самом продукте и окружающей среде (ситуация на рынке, новые инструменты разработки и т. д.).
Инспекция необходима для выявления нежелательных изменений или препятствий в процессе работы, которые влияют на результат. Инспекция – это своего рода детектор, отслеживающий ситуацию в продукте, команде, окружающей среде. За счет принципа инспекции в Scrum возможна оперативная адаптация.
Участники Scrum-процесса должны сами инспектировать его артефакты и прогресс на пути к цели спринта.
Пример
Ежедневные сборы для выявления блокеров и сообщения важной информации участникам команды.
➤ Адаптация
Адаптация – это изменения, которые происходят в системе при изменении условий внешней или внутренней среды. Обеспечить оперативную адаптацию позволяет принцип инспекции. Адаптация – это прямое действие, которое определяет гибкость команды и продукта. Мы не просто реализуем то, что должно быть реализовано. Мы находимся в контакте с реальностью и обеспечиваем нашей команде, нашим процессам и нашему продукту необходимую гибкость, чтобы достигать бизнес-ценностей максимально быстро и с минимальными рисками, связанными с затратами сил, времени и денег.
Принцип адаптации подразумевает, что мы оперативно вносим все изменения, адаптируемся с учетом ситуации здесь и сейчас и долгосрочного планирования. То есть после того, как мы выявили нежелательные изменения или препятствия, которые влияют на поставку результата, мы должны произвести перерегулирование так, чтобы минимизировать будущее отклонение от желаемых результатов.
Пример
В процессе ежедневных сборов выявляем блокеры и меняем планы, чтобы быстрее достигнуть необходимых результатов.
Три базовых принципа Scrum – это «три кита», которые позволяют Scrum как фреймворку максимально полно реализовывать гибкий подход к разработке.
Пять ценностей Scrum: смелость, сфокусированность, обязательство, уважение и открытость. На самом деле можно было бы выделить больше ценностей, но эти считаются основными.
➤ Сфокусированность (Focus)
Сфокусированность предполагает, что каждый участник Scrum-команды фокусируется на ограниченном количестве задач в одну единицу времени. Хотя Scrum-команда кросс-функциональна, это не значит, что она распыляется на множество задач. Такой подход приводит к утрате продуктивности и повышает вероятность того, что инкремент продукта не будет реализован к окончанию спринта, а вместо этого появится ряд наработок в нескольких продуктах или ряд решений для одного продукта.
Фокусирование помогает сконцентрировать все силы, внимание и креативность Scrum-команды для решения максимально актуальных и ценных пользовательских историй, а также достичь необходимой цели спринта – потенциально готового к выпуску инкремента продукта.
➤ Смелость (Courage)
Смелость необходима для того, чтобы открыто говорить о существующих сложностях и препятствиях в процессах, предлагать свои творческие идеи и решения. Смелость также заключается в том, чтобы признавать свои ошибки и открыто говорить о них, что дает возможность изменить процесс работы или инкремент продукта. Смелость – это признаться в том, что у тебя нет каких-то навыков, что тебе нужна помощь или дополнительные ресурсы.
➤ Открытость (Openness)
Открытость необходима Scrum-команде для того, чтобы достичь необходимой гибкости. Лучше вовремя исправить проблемные моменты в продукте или в процессе его разработки, чем упрямо создавать неправильный продукт или делать ценный продукт неправильным способом. Другими словами, сами члены команды могут открыто говорить о том, что важно. Открытость также подразумевает открытость к новым и креативным решениям, новым способам работы и взаимодействия. Это также открытость к новым задачам, которые могут возникать в процессе работы: негибко следовать первоначальному плану, когда бизнес-ситуация изменилась и возникли новые задачи. Нельзя игнорировать новую информацию. Открытость позволяет полноценно использовать Scrum как фреймворк гибкой разработки продукта.
➤ Обязательство (Commitment)
Вовлекаясь в процесс, каждый член Scrum-команды «подписывается» под целью Спринта, и под конкретными задачами беклога. Именно для этого на планировании Спринта присутствует вся Scrum-команда. Такой подход контрастирует с классическим менеджментом, когда дается указание свыше, и члены команды могут вообще не понимать, что они делают и зачем. В Scrum крайне важно, чтобы каждый член команды принимал сознательное решение и брал за него личную ответственность. Имея полный контроль над своими действиями, мы более склонны к успеху (committed to success).
➤ Уважение (Respect)
Уважение к членам команды, к продукту, к заказчику и конечному пользователю – необходимые условия рабочего процесса в Scrum. Если нет понимания ценности продукта, а также нет уважения к членам команды или к пользователю, то все остальные ценности можно поставить под сомнение.
Scrum – это командный процесс, который включает в себя три роли.
1. Владелец продукта (Scrum Product Owner).
2. Scrum-мастер.
3. Scrum-команда (команда разработки).
➤ Владелец продукта
Это выделенная роль. На самом базовом уровне владелец продукта – лидер, ответственный за максимизацию ценности продуктов, которые создает команда Scrum.
Однако для этого владелец продукта должен взять на себя несколько ролей, включая бизнес-стратега, дизайнера продукта, аналитика рынка, посредника, взаимодействующего с клиентами, и менеджера проекта.
1. Говоря о команде, мы упоминали такую роль, как владелец продукта (Product Owner). Это человек, который представляет продукт, управляет им и формирует его ви´дение. Анализируя рынок и целевую аудиторию, он определяет, как будет развиваться продукт и как максимально удовлетворить всех заинтересованных лиц.
Это означает, что владелец продукта знает целевую аудиторию, то есть понимает ее проблемы, потребности и желания. Он формулирует ценностное предложение для этой целевой аудитории – то, как именно наш продукт может решить ее проблемы. И только на основе этого понимания уже строит предположение о том, какие ценные функции должен содержать наш продукт.
2. Все идеи и пожелания владелец продукта складывает в Product Backlog. Бэклог продукта – это упорядоченный перечень всех пожеланий и идей, над которыми будет работать Scrum-команда. Владелец продукта единолично управляет этим бэклогом, описывает его задачи для команды, определяет приоритеты этих задач, обеспечивает прозрачность для всех участников процесса.
Поскольку продукт – это ценность, которую мы предоставляем заказчику, то именно владелец продукта определяет, какую ценность мы создадим в текущем спринте, а какую отложим на следующий. Он отвечает за максимизацию ценности для заказчика.
3. Владелец продукта вовлекает заказчиков и заинтересованных лиц в процесс разработки продукта. Это значит, что он приглашает заказчиков для участия в обзорах спринта (ретроспективах). У одного продукта может быть несколько заказчиков и заинтересованных лиц, например, относящихся к разным категориям пользователей нашего продукта. Владелец продукта приглашает их на мероприятия и помогает договориться друг с другом.
Владелец продукта также управляет ожиданиями стейкхолдеров. Один из самых прямых способов управления ожиданиями – регулярная поставка потенциально готового к релизу продукта. А стейкхолдеры могут взглянуть на него, оценить и дать свою обратную связь, которую мы учтем в следующей итерации. Обычно мы не посвящаем стейкхолдеров в рабочие процессы команды и тонкости реализации продукта, но обещаем показать рабочий продукт в течение определенного, относительно небольшого периода (спринт в Scrum длится от недели до месяца).
4. Владелец продукта формирует его ви´дение. Это означает, что он знает целевую аудиторию, понимает ее проблемы, потребности и желания. Владелец продукта постоянно взаимодействует с командой, выслушивает предложения и получает оценку задач.
Не всегда можно определить, какое решение должно быть первоочередным, поэтому общение с командой разработки и пользователями – неотъемлемая часть процесса. Владелец продукта помогает команде работать над по-настоящему нужными задачами, а также вовлекает заказчиков (пользователей) в процесс разработки, чтобы они ясно понимали, насколько важны для разработчиков.
➤ Scrum-мастер
Scrum-мастер – специалист, владеющий различными практиками и подходами, которые позволяют наладить процессы разработки ПО и привести их к соответствию Scrum-гайду и принципам Agile. Консультирует не только команду разработки, но и владельца продукта, а также владельцев бизнеса.
Scrum-мастер – это коуч и защитник Scrum-команды, который устраняет препятствия и контролирует рабочие процессы. Его задача – убедиться, что проект работает без сбоев, и у каждого члена команды есть инструменты для эффективного выполнения своей работы.
Scrum-мастер – это сложная роль, но столь же важная, как и владелец продукта. Scrum-мастер должен работать над бэклогом продукта в том порядке, который установил владелец продукта, и контролировать процессы, чтобы задачи выполнялись вовремя и в достаточно хорошем качестве. Помимо этого, Scrum-мастер принимает участие в командных обсуждениях (и конфликтах), поэтому он должен иметь хорошие коммуникативные навыки.
Scrum-мастер отвечает за мониторинг Scrum-процессов и встреч. Он повышает эффективность своей команды, мотивирует ее, коучит и фасилитирует, выступает за изменения, которые могут обеспечить качество и скорость работы.
Он не управляет командой, но наблюдает за исполнением основных принципов Scrum. Его задача – не давить, не делать всю работу самому и не распределять обязанности, но помогать, направлять и решать вопросы, которые тормозят процесс разработки.
1. Scrum-мастер помогает членам команды работать вместе и изучать фреймворк Scrum, а также защищает их от внутренних и внешних раздражителей. Scrum-мастер отвечает за то, чтобы Scrum понимали и применяли как внутри команды, так и за ее пределами.
2. Scrum-мастер может фасилитировать встречи. Он помогает Scrum-команде стать самоорганизующейся, не сбиться с пути, а также остаться продуктивной и нарастить свои возможности.
3. Scrum-мастер работает вместе с владельцем продукта, помогая ему понимать, создавать и поддерживать бэклог продукта.
4. Scrum-мастер помогает самой организации выстраивать Scrum, обучает людей, а также помогает Scrum-команде стать лучше, продуктивнее и ценнее.
5. Scrum-мастер помогает людям вне команды понять процесс и видит, какие взаимодействия с командой идут им на пользу, а какие нет.
➤ Scrum-команда
Сердце Scrum – Scrum-команда. Это небольшая группа людей, работающая над продуктом.
1. Команда разработки состоит из профессионалов, которые трудятся над созданием инкремента продукта. Они самоорганизуются для выполнения работ. Никто (даже Scrum-мастер) не может указывать команде, как создавать инкременты работающей функциональности из бэклога продукта.
2. Scrum требует, чтобы команда разработки была кросс-функциональной, то есть состояла из людей, обладающих всеми необходимыми знаниями и умениями для того, чтобы создать каждый инкремент продукта. При этом в Scrum-гайде нет никаких должностей, кроме разработчика. Главное, чтобы это не вызывало путаницу.
3. Члены команды разработки отвечают за то, чтобы самоорганизоваться для достижения цели спринта и создать каждый инкремент продукта согласно плану. Владелец продукта поддерживает упорядоченный список задач. Члены команды разработки прогнозируют, сколько они смогут выполнить в следующем спринте, и сами решают, как они будут это делать. Они также отвечают за качество своей работы.
4. В Scrum-команде обычно не так много людей – 7 ± 2 человека. Оптимальная по численности команда разработки достаточно мала для того, чтобы оставаться простой в управлении, и в то же время достаточно велика, чтобы выполнять значительный объем работы в течение спринта.
Scrum включает в себя пять видов активностей/мероприятий.
1. Спринт.
2. Планирование спринта.
3. Daily Scrum (ежедневный).
4. Обзор спринта.
5. Ретроспектива спринта.
Мероприятия используются в Scrum для поддержания принципов инспекции и адаптации, а также для создания регулярности.
➤ Спринт
Спринт – контейнер для всех событий Scrum, временной отрезок неизменной длины, за который команда разработки должна подготовить инкремент.
Обычно длительность спринта составляет месяц или менее. Лучше, когда длительность спринтов постоянна на протяжении всего периода разработки. Так легче спланировать работу и оценить производительность команд.
У спринта должна быть цель, чтобы команда разработки понимала, зачем создается инкремент и какие задачи нужно решить в первую очередь. Цель спринта дает некую гибкость: руководствуясь ею, можно корректировать содержимое спринта, например добавлять или заменять задачи.
Следующий спринт начинается сразу же по окончании предыдущего.
Спринты состоят из планирования, ежедневных Scrum (стендапов), разработки, обзора спринта (или демо), а также ретроспективы спринта.
➤ Планирование спринта
Это первое событие, которое происходит в рамках спринта. На этом этапе необходимо определить цели спринта и список задач, которые нужно выполнить. На встрече обсуждается способ реализации намеченных задач. В итоге должны быть определены цель спринта, список задач и способы их реализации.
В планировании участвует вся Scrum-команда и владелец продукта. Scrum-мастер отвечает за обязательное проведение мероприятия и помогает всем участникам понять его цель. Он учит Scrum-команду не превышать лимит времени, отведенный на мероприятие.
На встрече анализируют готовые разработки по продукту, список задач бэклога и выбирают те, которые можно и нужно выполнить далее. Количество задач определяет сама команда, исходя из своей производительности. Все участники команды должны прийти к единодушному мнению – это коллективное решение. Если они выполнят все задачи раньше окончания спринта, то возьмут еще. Если что-то не успеют, то вместе с владельцем продукта пересмотрят список задач.
Задачи, которые команда взяла в работу в спринт, называют бэклогом спринта.
Рекомендуемая длительность встречи – не более четырех часов для двухнедельного спринта.
➤ Ежедневный Scrum (стендап)
Это 15-минутные мероприятия для команды разработчиков, которые проводятся с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Такие встречи нужны для того, чтобы проинспектировать работу, проделанную с момента прошлого ежедневного Scrum, и спрогнозировать шаги, которые можно осуществить до следующего.
Эти встречи проводятся в одном и том же месте, в одно и то же время для уменьшения путаницы.
На встрече каждый из членов команды рассказывает о том, что сделал вчера, и планах на сегодня. Если у кого-то возникла проблема с задачей, то ее обсуждают совместно. Время жестко ограничено – не более 15 минут, поэтому на этой встрече команда только выявляет проблемы. Поиск решения выносится за рамки этой встречи.
Ежедневный Scrum помогает команде оценить прогресс в продвижении к цели спринта и выявить отклонения от планируемого объема работ бэклога спринта. Такой подход способствует повышению осознанности команды и ее самоорганизации. Также ежедневные Scrum помогают повысить эффективность общения внутри команды, определить и устранить препятствия на пути разработки, способствуют быстрому принятию решений и повышают уровень осведомленности команды разработки. Это ключевое мероприятие для инспекции и адаптации.
➤ Обзор спринта
Scrum-команда, владелец продукта и заинтересованные лица собираются в одной комнате. Команда и владелец продукта демонстрируют заинтересованным лицам результаты спринта, рассказывают, как прошел спринт, отвечают на вопросы. Далее обсуждают бэклог продукта, при необходимости вносят коррективы, обговаривают дальнейшие планы.
Это встреча проводится в конце спринта для инспекции инкремента и при необходимости адаптации бэклога продукта (то есть по результатам обратной связи возникает необходимость дополнить либо переработать бэклог, либо что-то убрать).
Результатом обзора спринта служит пересмотренный бэклог продукта, в котором выделены возможные его элементы для следующего спринта.
Для спринта длиной в месяц обзор – четырехчасовое мероприятие. На короткие спринты обычно тратят меньше времени.
➤ Ретроспектива спринта
Scrum подразумевает, что команда будет постоянно развиваться, совершенствоваться и повышать свою эффективность. Как раз для этого в конце каждого спринта проводится его ретроспектива. Scrum-команда обсуждает прошедший спринт: что получилось хорошо, какие возникли затруднения, что нового узнали в процессе работы. На этом этапе команда может обсуждать все аспекты: взаимоотношения между коллегами, внутренний процесс работы, используемые инструменты. Цель встречи – разработать план улучшений.
Ретроспектива спринта дает Scrum-команде возможность проинспектировать себя и создать план улучшений для следующего спринта. Ретроспектива спринта происходит после обзора спринта, перед планированием последующего спринта.
Цели ретроспективы спринта.
1. Оценить успешность спринта с точки зрения взаимодействия между людьми, процессов и инструментов.
2. Определить и упорядочить задачи – поговорить о том, что прошло успешно, а что нуждается в улучшении.
3. Разработать план по внедрению улучшений в процесс работы Scrum-команды, который и будет результатом встречи.
Scrum-мастер мотивирует команду пересмотреть процессы разработки в рамках фреймворка Scrum, чтобы сделать работу более эффективной и приятной в следующем спринте. Команда ищет пути улучшения качества разрабатываемого продукта.
Команда придумывает улучшения и внедряет их в следующем спринте – именно в этом заключается адаптация после инспектирования Scrum-команды. Хотя разработчики могут вносить изменения в любое время, ретроспектива предоставляет формальную возможность сфокусироваться на инспекции и адаптации.
Скрам включает в себя три важных артефакта: бэклог продукта, бэклог спринта и инкремент продукта.
➤ Бэклог продукта
Это список требований к продукту, упорядоченный по приоритету. В идеале он должен содержать требования такого размера, чтобы команда могла выполнить их за один спринт, и такой детализации, благодаря которой на планировании сразу будет понятно, что нужно делать. Более абстрактные требования тоже могут присутствовать в бэклоге, просто они обычно ниже по приоритету.
Любой участник команды может дополнять и изменять бэклог как на регулярных встречах, так и в течение спринта.
➤ Бэклог спринта
В бэклог спринта набираются задачи из бэклога продукта согласно цели спринта. Эти задачи позволят достичь цели спринта, разработать новую ценность, они понятны команде, и команда согласна с заданным объемом задач на спринт.
Бэклог спринта определяет объем работы, которую команда разработки должна выполнить, чтобы превратить бэклог продукта в готовый инкремент.
Задачи, взятые в спринт, могут быть декомпозированы на более мелкие. Как именно – не регламентируется.
В идеале бэклог спринта должен быть зафиксирован на спринт. Но бывает так, что либо сам владелец продукта, либо какое-то заинтересованное лицо или высокий начальник прибегает и просит включить задачу в текущий спринт, срочно-срочно. При том что спринт забит под завязку. В таких случаях команде нужно знать, как реагировать: разработчики, конечно, обсуждают ситуацию с владельцем продукта и пересматривают бэклог спринта, возможно, исключают какие-то задачи.
➤ Инкремент
Это сумма всех выполненных требований бэклога продукта, реализованных во время текущего спринта, и ценности всех предыдущих спринтов, то есть текущее состояние разработанного продукта. По окончании спринта новый инкремент должен быть «готовым», то есть пригодным к использованию и отвечающим определенным критериям готовности (об этом я расскажу далее).
У всей команды должно бы единое понимание того, что считать «готовым» продуктом (критерий прозрачности Scrum).
Критерий готовности (definition of done) – одно из соглашений, которое должна обсудить и принять вся команда. Участники команды определяют, что они подразумевают под словом «готово» применительно к задачам или элементам бэклога.
Критерии готовности задачи – критерии, которым должна удовлетворять задача, чтобы ее можно было внедрить и чтобы она превратилась в инкремент.
Критерии готовности к взятию в работу (definition of ready) – критерии, которым должна удовлетворять задача из бэклога продукта, чтобы ее можно было считать готовой к взятию в работу.
Это принцип освоения новой области знаний по этапам, следуя которому можно максимально быстро стать мастером в новой технике. Этот принцип изначально сформулирован в айкидо, но его можно использовать и в личной жизни, и в работе.
Название отражает три этапа освоения.
1. Следование правилам.
2. Небольшие эксперименты.
3. Следование интуиции.
h. Стадия Сю – «следуй правилу» / «соблюдай»
На этом этапе необходимо следовать тому, что показывает другой человек, который уже достиг мастерства. Изучаем и выполняем все в соответствии с правилами и инструкциями.
В айкидо ученику требуется много лет тренироваться, иначе у него не будет базы для перехода на следующую ступень. На этой стадии нарабатывается база, ученик постепенно привыкает к механике действий и через некоторое время становится готов перейти на следующую стадию.
h. Стадия Ха – «сломай правила» / «отделяйся»
На этом этапе следует отойти от правил и начать экспериментировать, пробовать новое, искать лучшие способы работать, анализировать и практиковать.
В айкидо это вторая ступень, на которой ученик обдумывает свои действия, изменяет правила, пробует их нарушать, строит новую систему собственных правил. Также он осваивает новые приемы у других учителей.
h. Стадия Ри – «отделение от правил» / «превосходи»
Суть правил освоена, они больше не нужны, можно действовать естественным образом. На этом этапе следует, оторвавшись от привычных правил и шаблонов, практиковать новое в своем стиле.
В айкидо это третья ступень, согласно которой нужно освободиться от правил: их больше нет, есть лишь естественный ход вещей (Дао). «Ри» означает подняться над всем, что изучалось раньше, создать более высокие и общие принципы. На этой ступени уже формируется органичное и естественное поведение на уровне привычек.
Так вот, принцип освоения Scrum похож на методику СюХаРи:
• скраму можно научиться лишь в процессе, при этом сначала нужно хорошо освоить все правила, а потом забыть о них;
• скрам основан на постоянном пополнении опыта, требует особой внимательности и приложения больших сил.