Кен Швабер - Скрам

• Название: Скрам
• Автор: Кен Швабер
• Жанр: Отраслевые издания
• Год: 2019
• ISBN: 978-5-9614-2860-5

Эта книга несет в себе дух скрама, раскрывая его ценности и основные принципы. Кен Швабер, один из создателей скрама, соавтор «Руководства по скраму» и основатель Scrum.org, собрал лучшие кейсы из своей практики, демонстрирующие примеры успехов и неудач применения скрама в реальных проектах. Они помогут вам понять, как использовать скрам для решения комплексных проблем и достижения результатов. Автор рассказывает, как эффективно управлять сложными, громоздкими проектами и изменяющимися требованиями к продукту; упрощать организационную структуру с помощью самоуправляемых команд разработки; получать более четкие описания требований и внятную обратную связь от клиентов и заказчиков. Вы узнаете, как эффективнее планировать работу над проектом, научитесь избегать ошибочных действий, используя регулярную инспекцию, а также увеличивать отдачу от инвестиций.

---

Эмпирический процесс управления

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

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

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

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

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

Бабатунде Огуннайке и Хармон Рэй. Динамика, моделирование и управление процессами (Process Dynamics, Modeling, and Control)[5]

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

Любое внедрение управления эмпирическим процессом основывается на трех китах: прозрачность, инспекция и адаптация. Прозрачность означает, что характеристики процесса, влияющие на результат, должны быть видны и известны тем, кто этот процесс контролирует. Одинаково важно и то, чтобы эти характеристики были видны, и то, чтобы они были правдивы. При управлении эмпирическим процессом нет места обману. Например, если кто-то говорит, что конкретная функциональность отмечена как «готовая», что имеется в виду? В сфере разработки ПО утверждение о готовности функциональности может подразумевать выполнение всех следующих условий: аккуратно написан программный код, произведен рефакторинг, протестированы отдельные компоненты, собран дистрибутив для установки, произведена приемка пользователями. При этом кто-то другой может подразумевать, что программный код был только написан, протестирован и собран в дистрибутив. Если нет единого понимания того, что означает слово «готово», то и от наличия информации о «готовности» конкретной функциональности пользы мало.

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

Третий кит управления эмпирическим процессом – адаптация. Если в ходе проверки инспектор выявляет, что одна или несколько характеристик процесса выходят за допустимые пределы значений и полученный продукт будет неприемлемым, то инспектор корректирует процесс или используемое сырье. Корректировка должна быть произведена как можно быстрее, чтобы свести к минимуму дальнейшее отклонение.

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

Разработка комплексного программного обеспечения

Разрабатывая программное обеспечение, я создаю набор логически взаимосвязанных инструкций, которые посылают сигналы, управляющие аппаратурой и ее взаимодействием с другими аппаратами, людьми или окружающей средой. Уровень точности, необходимый для успешного функционирования ПО, варьируется от невероятного до по-настоящему пугающего. Любой из этих объектов может оказаться комплексным. А когда эти комплексные объекты вступают во взаимодействие, уровень сложности зашкаливает. Рассматривая далее комплексную природу разработки программного обеспечения, давайте ограничимся тремя наиболее важными измерениями: требованиями, технологиями и людьми.

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

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

На рис. 1.1 вертикальная ось показывает комплексность требований, а горизонтальная – комплексность технологии. Пересечение этих двух видов комплексности определяет общий уровень комплексности проекта. Почти все проекты разработки программного обеспечения сегодня – комплексные. А некоторые даже хаотичны, но в них невозможно работать, пока часть сложностей не будет устранена.