Искусство Agile-разработки. Теория и практика гибкой разработки ПО [2 ed.] 9785446123865

Table of contents :
Отзывы
Предисловие
Введение
Для прагматиков
Что нового во втором издании
Для кого предназначена книга
О приглашенных авторах
Гитте Клитгаард
Диана Ларсен
Шейн Уорден
Условные обозначения
Использование примеров кода
Благодарности
От издательства
Часть I. Улучшая гибкость
Глава 1. Что есть Agile
Происхождение Agile
Рожденный из кризиса
Манифест Agile
Суть Agile
Адаптивность вместо предиктивности
Ориентированность на людей, а не на процессы
Почему Agile победил
Почему Agile работает
Почему Agile терпит неудачу
Глава 2. Как быть Agile
Практика Agile
Как достичь мастерства
С чего начать?
Присоединение к действующей команде Agile
Введение Agile
Совершенствование действующих Agile-команд
Применение отдельных практик Agile
Глава 3. Выберите свою гибкость
Модель Agile Fluency
Уровень фокусировки (Focusing)
Уровень поставки (Delivering)
Уровень оптимизации (Optimizing)
Уровень укрепления (Strengthening)
Выберите свои уровни
Глава 4. Инвестируйте в гибкость
Найдите время на обучение
Если нет времени на обучение…
Если нет средств на финансовую помощь…
Отберите или создайте Agile-команды
Если вы не можете закрепить людей за определенной командой…
Если члены команды не ладят друг с другом…
Если вы не можете создать долгосрочную команду…
Если вы не можете получить необходимых экспертов со знанием бизнеса, клиентов или пользователей…
Если вы не можете получить необходимые вам навыки разработчиков…
Выберите Agile-коучей
Если вы не можете нанять на работу нужных вам коучей…
Делегируйте полномочия и ответственность команде
Если работу нужно поручить отдельным людям…
Если корпоративные инструменты не поддерживают командную работу…
Если команды должны использовать корпоративный инструмент отслеживания…
Если у команды нет доступа к стейкхолдерам…
Если команда поставки не управляет своим процессом релиза…
Если команда оптимизации не управляет своими планами создания продукта и расходами…
Измените стиль управления командой
Если менеджеры не могут отпустить ситуацию…
Организуйте рабочие помещения
Если команда удаленная…
Если вы не можете организовать физическое помещение для офисной команды…
Выберите команде подходящую для обучения задачу
Если есть важный дедлайн…
Если нет значимой работы с нуля…
Смените водопадные подходы в управлении
Если требуется водопадная модель управления…
Измените вредные HR-политики
Если HR-политики не подлежат изменению…
Решите проблемы, связанные с безопасностью
Если требования безопасности не допускают гибкости…
Если вам требуется дополнительный этап ревью кода…
Глава 5. Инвестируйте в изменения
Осознание изменений
Масштабные изменения
Процессы изменений
Заручитесь поддержкой руководства
1. Начните с разговора
2. Получите одобрение экономичного покупателя
3. Сделайте официальное предложение
Если это выглядит слишком трудозатратным…
Если руководство считает, что они уже Agile…
Если руководство не поддерживает…
Заинтересуйте команду
Если команда настроена скептически…
Если несколько членов команды против…
Если большинство членов команды против…
Если люди обманывают насчет своего согласия…
Заручитесь поддержкой стейкхолдеров
Если нужны конкретные обязательства…
Если стейкхолдеры не спешат поддержать…
Литература для дополнительного чтения
Глава 6. Масштабирование гибкости
Масштабирование свободного владения навыками
Организационный потенциал
Коучинговый потенциал
Потенциал команды
Масштабирование продуктов и портфелей
Вертикальное масштабирование
Горизонтальное масштабирование
Вертикальное и горизонтальное масштабирование
Моя рекомендация
Часть II. Фокус на ценность
Добро пожаловать на уровень фокусировки
Достижение свободного владения навыками на уровне фокусировки
Глава 7. Командная работа
Вся команда
Навыки в сфере деятельности заказчика
Навыки разработки
Навыки коучинга
Специалисты широкого профиля
Комплектование команды
Размер команды
Команда единомышленников
Еще раз о провальной команде
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Командная комната
Секреты сотрудничества
Физические командные комнаты
Виртуальные командные комнаты
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Безопасность
Понятие психологической безопасности
Как создать атмосферу безопасности
Роль лидера
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Цель
Начните с ви́дения
Идентифицируйте цель
Задокументируйте цель
Внесите цель в свой устав
Продвигайте цель
Обновляйте цель
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Контекст
Запишите контекст в устав
Обновляйте контекст
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Согласование
Запишите договоренности в устав
Обновляйте соглашения
Придерживайтесь договоренностей
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Энергичная работа
Как быть энергичным
Поддерживайте энергичную работу
Делайте перерывы
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Глава 8. Планирование
Истории
Как написать историю
Ценность для заказчика
Разделение и объединение историй
Специальные истории
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Адаптивное планирование
Ценные инкременты
Фокус на один инкремент за раз
Разделите инкременты
Делайте частые релизы и как можно раньше
Ваш первый инкремент
Адаптируйте свои планы
Как создать план
Баланс адаптивности и предсказуемости
Адаптивное планирование и организационная культура
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Визуальное планирование
Кто планирует?
Картирование кластеров
Дальнейшая разбивка инкрементов
Карты влияния
Перспективный анализ
Составление карты историй
Обновление визуального плана
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Игра в планирование
Как играть
Держите открытым окно возможностей
Как выиграть в игре в планирование
Приоритизация решений по разработке
Лицом к лицу с реальностью
Повторение игры в планирование
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Вовлечение реального заказчика
Разработка для собственных нужд
Разработка платформ
Внутренняя разработка на заказ
Аутсорсинг разработки
Программное обеспечение для вертикального рынка
Программное обеспечение для горизонтального рынка
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Инкрементные требования
Изменяемый документ с требованиями
Когда эксперты не являются частью команды
Работайте инкрементно
Документация
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Глава 9. Владение
Планирование задач
Рабочий ритм
Создание задач
Визуальное отслеживание
Кросс-командные зависимости
Принятие и выполнение обязательств по итерации
Незаконченные истории
Срочные запросы
Ваша первая неделя
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Потенциал
Вчерашняя погода
Потенциал и временные рамки итерации
Стабилизация потенциала
Оценка историй
Когда оценить трудно
Защита оценки
Ваш начальный потенциал
Как улучшить потенциал
Потенциал — это не производительность
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Резерв времени
Сколько резерва нужно
Как использовать резерв
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Стендап-митинги
Как проводить ежедневные стендапы
Будьте краткими
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Информативное рабочее пространство
Тонкие сигналы
Большие наглядные диаграммы
Диаграммы улучшений
Игры
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Примеры заказчика
Описать
Продемонстрировать
Разработать
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Сделано Сделано
Как быть в статусе «Сделано Сделано»
Находить время
Организационные ограничения
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Глава 10. Ответственность
Доверие стейкхолдеров
Добавьте немного суеты
Проявите эмпатию
Выполняйте обязательства
Управляйте проблемами
Уважайте цели заказчика
Сделайте так, чтобы стейкхолдеры выглядели хорошо
Будьте честны
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Демо для стейкхолдеров
Петли обратной связи
Частота демо
Как проводить демо для стейкхолдеров
Подготовьтесь
Когда дела идут плохо
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Прогнозирование
Неопределенность и риск
Запланированные даты релизов
Прогнозы осуществимости
Прогнозы сроков и объема работы
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Дорожные карты
Agile-руководство
Вариант 1. Только факты
Вариант 2. Общее направление
Вариант 3. Дата и примерный объем работы
Вариант 4. Детальные планы и прогнозы
Корпоративные системы отслеживания
Когда дорожная карта недостаточно хороша
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Менеджмент
Теория X и теория Y
Роль руководителя в Agile
Дисфункция измерений
Почему дисфункция измерений неизбежна
Делегируемое управление
Когда показатели необходимы
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Глава 11. Совершенствование
Ретроспективы
Виды ретроспектив
Как проводить пульсирующие ретроспективы
Шаг 1. Первая директива (5 минут)
Шаг 2. Мозговой штурм (20 минут)
Шаг 3. Безмолвное сопоставление (15 минут)
Шаг 4. Генерация идей (инсайтов) (10–30 минут)
Шаг 5. Цель ретроспективы (10–20 минут)
Довести дело до конца
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Динамики команды
Что формирует команду
Развитие команды
Коммуникация, сотрудничество и взаимодействие
Совместное лидерство
Токсичное поведение
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Устранение препятствий
Выявление препятствий
Круги и суп
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Часть III. Надежная поставка
Добро пожаловать на уровень поставки
Достижение свободного владения навыками на уровне поставки
Глава 12. Сотрудничество
Коллективное владение кодом
Как заставить коллективное владение работать
Программирование без эго
Сотрудничество без конфликтов
Работа с незнакомым кодом
Преимущества для программистов
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Парное программирование
Почему парное?
Рабочие станции для парного программирования
Как работать в паре
Эффективная навигация
Обучение при работе в паре
Трудности
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Групповое программирование
Как работать в групповом программировании
Почему групповое программирование работает
Рабочая станция для группового программирования
Как заставить режим группового программирования работать
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Единый язык
Дилемма экспертных знаний в предметной области
Говорить на одном языке
Как создать единый язык
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Глава 13. Разработка
Нулевое трение
Обратная связь за секунду
Знайте свой редактор
Воспроизводимые сборки
Пятиминутная интеграция
Контролировать сложность
Автоматизировать все
Автоматизируйте инкрементно
Автоматизация устаревшего кода
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Непрерывная интеграция
Непрерывная интеграция — это практика, а не инструмент
Множество разновидностей непрерывной интеграции
Танец непрерывной интеграции
Непрерывная интеграция без CI-сервера
Синхронная или асинхронная интеграция
Многоступенчатые интеграционные сборки
Запросы на слияние кодов (пул-реквесты) и ревью кода
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Разработка через тестирование
Почему TDD работает
Как использовать TDD
Ешьте луковицу с середины
Пример TDD
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Быстрые надежные тесты
Использование узких модульных тестов
Тестирование внешних взаимодействий с помощью узких интеграционных тестов
Моделирование нелокальных зависимостей
Контроль глобального состояния
Написание коммуникативных тестов
Разделение инфраструктуры и логики
Применение широких тестов только в качестве страховочной сетки
Добавление тестов к существующему коду
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Рефакторинг
Как делать рефакторинг
Рефакторинг в действии
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Спайк-решения
Простые вопросы
Сторонние зависимости
Дизайн-эксперименты
Найдите время для спайков
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Глава 14. Дизайн
Инкрементный дизайн
Никогда не останавливайте работу над дизайном
Как работает инкрементный дизайн
Уровни дизайна
Архитектура на основе рисков
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Простой дизайн
Вам это не понадобится (YAGNI: You Aren’t Gonna Need It)
Однажды и только однажды
Связанность и сплоченность
Сторонние компоненты
Быстрое завершение с ошибкой
Самодокументируемый код
Опубликованные интерфейсы
Оптимизация производительности
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Рефлексивный дизайн
Как работает рефлексивный дизайн
Рефлексивный дизайн на практике
Реверс-инжиниринг дизайна
Определение улучшений
Проблемный код
Выполняйте рефакторинг инкрементно
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Глава 15. DevOps
Сборка для эксплуатации
Моделирование угроз
Конфигурация
Секреты
Параноидальная телеметрия
Ведение журнала событий
Показатели и пригодность к наблюдению
Мониторинг и оповещения
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Флаги функций
Замковый камень
Флаги функций
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Непрерывное развертывание
Как использовать непрерывное развертывание
Обнаружение сбоев развертывания
Устранение сбоев развертывания
Инкрементные релизы
Миграция данных
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Эволюционная системная архитектура
Вам действительно это понадобится?
Нацеленность на простоту
Контроль сложности
Рефакторинг системной архитектуры
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Глава 16. Качество
Без багов
Не ищите виноватого в багах
Как встроить качество
Исправляйте баги незамедлительно
Роль тестировщика
Правильное мироощущение
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Обнаружение слепых зон
Подтвержденное знание
Исследовательское тестирование
Хаос-инжиниринг
Тестирование на проникновение и оценка уязвимостей
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Анализ инцидентов
Природа сбоя
Проведение анализа
Обучение организации
Ответственность за инциденты
Вопросы
Предварительные требования
Показатели
Альтернативы и эксперименты
Литература для дополнительного чтения
Часть IV. Оптимизация результатов
Добро пожаловать в область оптимизации
Достижение навыков на уровне оптимизации
Глава 17. Автономность
Экспертные знания в области заказчика
Бизнес-решения
Ответственность и надзор
Финансирование
Эксперименты и литература для дополнительного чтения
Глава 18. Открытия
Подтвержденное знание
Способность к адаптации
Эксперименты и литература для дополнительного чтения
Глава 19. Взгляд в будущее
Библиография
Об авторе

Citation preview

Искусство Agile-разработки ВТОРОЕ ИЗДАНИЕ

Джеймс Шор Диана Ларсен, Гитте Клитгаард, Шэйн Уорден

2024

ББК 32.973-018 УДК 004.4:005.8 Ш79



Шор Джеймс, Уорден Шэйн

Ш79 Искусство Agile-разработки. Теория и практика гибкой разработки ПО. — СПб.: Питер, 2024. — 624 с.: ил. — (Серия «Бестселлеры O’Reilly»).

ISBN 978-5-4461-2386-5 Большинство компаний, разрабатывающих ПО, якобы используют Agile, но на самом деле не понимают, что это такое. Хотите повысить гибкость своей команды? В книге вы найдете четкие, конкретные и подробные рекомендации о том, что, как и почему следует делать, а когда стоит пойти на компромиссы. Джеймс Шор предлагает реальные решения по освоению, планированию, разработке и управлению, основанные на более чем двадцатилетнем опыте Agile. Он объединяет актуальные идеи экстремального программирования, Scrum, Lean, DevOps и многих других в единое целое. Узнайте, как успешно внедрить гибкую разработку в вашей команде и организации, или разберитесь, почему Agile вам не подходит.

16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)

ББК 32.973-018 УДК 004.4:005.8

Права на издание получены по соглашению с O’Reilly. Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав. Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги. В книге возможны упоминания организаций, деятельность которых запрещена на территории Российской Федерации, таких как Meta Platforms Inc., Facebook, Instagram и др. Издательство не несет ответственности за доступность материалов, ссылки на которые вы можете найти в этой книге. На момент подготовки книги к изданию все ссылки на интернет-ресурсы были действующими.

ISBN 978-1492080695 англ. ISBN 978-5-4461-2386-5

Authorized Russian translation of the English edition of The Art of Agile Development 2E, ISBN 9781492080695 © 2022 James Shore and Big Blue Marble LLC. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. © Перевод на русский язык ООО «Прогресс книга», 2023 © Издание на русском языке, оформление ООО «Прогресс книга», 2023 © Серия «Бестселлеры O’Reilly», 2023

Оглавление

Отзывы.........................................................................................................................................................................21 Предисловие.............................................................................................................................................................24 Введение.....................................................................................................................................................................26 Для прагматиков..............................................................................................................................................27 Что нового во втором издании..................................................................................................................27 Для кого предназначена книга..................................................................................................................28 О приглашенных авторах.............................................................................................................................29 Гитте Клитгаард..........................................................................................................................................29 Диана Ларсен..............................................................................................................................................30 Шейн Уорден...............................................................................................................................................30 Условные обозначения.................................................................................................................................30 Использование примеров кода................................................................................................................31 Благодарности...................................................................................................................................................31 От издательства................................................................................................................................................32

ЧАСТЬ I. УЛУЧШАЯ ГИБКОСТЬ Глава 1. Что есть Agile..........................................................................................................................................34 Происхождение Agile.....................................................................................................................................34 Рожденный из кризиса..................................................................................................................................35 Манифест Agile..................................................................................................................................................35 Суть Agile..............................................................................................................................................................37 Адаптивность вместо предиктивности..........................................................................................37 Ориентированность на людей, а не на процессы.....................................................................38 Почему Agile победил....................................................................................................................................39 Почему Agile работает...................................................................................................................................40 Почему Agile терпит неудачу......................................................................................................................42 Глава 2. Как быть Agile.........................................................................................................................................44 Практика Agile...................................................................................................................................................44 Как достичь мастерства................................................................................................................................45 С чего начать?....................................................................................................................................................46 Присоединение к действующей команде Agile..........................................................................46 Введение Agile............................................................................................................................................46 Совершенствование действующих Agile-команд......................................................................47 Применение отдельных практик Agile............................................................................................48

6  Оглавление Глава 3. Выберите свою гибкость...................................................................................................................49 Модель Agile Fluency......................................................................................................................................49 Уровень фокусировки (Focusing).......................................................................................................51 Уровень поставки (Delivering).............................................................................................................52 Уровень оптимизации (Optimizing)..................................................................................................53 Уровень укрепления (Strengthening)..............................................................................................53 Выберите свои уровни..................................................................................................................................54 Глава 4. Инвестируйте в гибкость...................................................................................................................56 Найдите время на обучение.......................................................................................................................58 Если нет времени на обучение…......................................................................................................60 Если нет средств на финансовую помощь…................................................................................60 Отберите или создайте Agile-команды..................................................................................................60 Если вы не можете закрепить людей за определенной командой…...............................62 Если члены команды не ладят друг с другом…..........................................................................62 Если вы не можете создать долгосрочную команду…............................................................62 Если вы не можете получить необходимых экспертов со знанием бизнеса, клиентов или пользователей….........................................................................................................62 Если вы не можете получить необходимые вам навыки разработчиков…..................62 Выберите Agile-коучей..................................................................................................................................63 Если вы не можете нанять на работу нужных вам коучей…................................................63 Делегируйте полномочия и ответственность команде..................................................................63 Если работу нужно поручить отдельным людям…...................................................................64 Если корпоративные инструменты не поддерживают командную работу…...............64 Если команды должны использовать корпоративный инструмент отслеживания…........................................................................................................................................65 Если у команды нет доступа к стейкхолдерам….......................................................................65 Если команда поставки не управляет своим процессом релиза…...................................65 Если команда оптимизации не управляет своими планами создания продукта и расходами…............................................................................................................................................65 Измените стиль управления командой.................................................................................................66 Если менеджеры не могут отпустить ситуацию….....................................................................66 Организуйте рабочие помещения...........................................................................................................66 Если команда удаленная…...................................................................................................................67 Если вы не можете организовать физическое помещение для офисной команды….......................................................................................................................67 Выберите команде подходящую для обучения задачу..................................................................67 Если есть важный дедлайн…..............................................................................................................68 Если нет значимой работы с нуля….................................................................................................68 Смените водопадные подходы в управлении....................................................................................68 Если требуется водопадная модель управления…..................................................................68 Измените вредные HR-политики .............................................................................................................69 Если HR-политики не подлежат изменению…............................................................................70

Оглавление  7

Решите проблемы, связанные с безопасностью...............................................................................70 Если требования безопасности не допускают гибкости…...................................................71 Если вам требуется дополнительный этап ревью кода…......................................................71 Глава 5. Инвестируйте в изменения..............................................................................................................75 Осознание изменений...................................................................................................................................75 Масштабные изменения...............................................................................................................................77 Процессы изменений.....................................................................................................................................78 Заручитесь поддержкой руководства....................................................................................................79 1. Начните с разговора...........................................................................................................................79 2. Получите одобрение экономичного покупателя..................................................................80 3. Сделайте официальное предложение.......................................................................................81 Если это выглядит слишком трудозатратным….........................................................................82 Если руководство считает, что они уже Agile…..........................................................................83 Если руководство не поддерживает…...........................................................................................83 Заинтересуйте команду................................................................................................................................85 Если команда настроена скептически…........................................................................................86 Если несколько членов команды против…..................................................................................86 Если большинство членов команды против…...........................................................................86 Если люди обманывают насчет своего согласия…...................................................................87 Заручитесь поддержкой стейкхолдеров..............................................................................................87 Если нужны конкретные обязательства…....................................................................................88 Если стейкхолдеры не спешат поддержать….............................................................................88 Литература для дополнительного чтения............................................................................................89 Глава 6. Масштабирование гибкости............................................................................................................90 Масштабирование свободного владения навыками......................................................................90 Организационный потенциал.............................................................................................................90 Коучинговый потенциал........................................................................................................................91 Потенциал команды.................................................................................................................................92 Масштабирование продуктов и портфелей........................................................................................93 Вертикальное масштабирование......................................................................................................93 Горизонтальное масштабирование..................................................................................................98 Вертикальное и горизонтальное масштабирование............................................................ 100 Моя рекомендация............................................................................................................................... 101

ЧАСТЬ II. ФОКУС НА ЦЕННОСТЬ Добро пожаловать на уровень фокусировки.................................................................................. 105 Достижение свободного владения навыками на уровне фокусировки.............................. 107 Глава 7. Командная работа............................................................................................................................. 108 Вся команда..................................................................................................................................................... 109 Навыки в сфере деятельности заказчика................................................................................... 111 Навыки разработки............................................................................................................................... 114

8  Оглавление Навыки коучинга.................................................................................................................................... 115 Специалисты широкого профиля.................................................................................................. 117 Комплектование команды................................................................................................................. 118 Размер команды..................................................................................................................................... 120 Команда единомышленников.......................................................................................................... 122 Еще раз о провальной команде...................................................................................................... 123 Вопросы..................................................................................................................................................... 124 Предварительные требования........................................................................................................ 124 Показатели................................................................................................................................................ 125 Альтернативы и эксперименты....................................................................................................... 125 Литература для дополнительного чтения.................................................................................. 125 Командная комната...................................................................................................................................... 126 Секреты сотрудничества.................................................................................................................... 128 Физические командные комнаты................................................................................................... 132 Виртуальные командные комнаты................................................................................................ 138 Вопросы..................................................................................................................................................... 141 Предварительные требования........................................................................................................ 141 Показатели................................................................................................................................................ 142 Альтернативы и эксперименты....................................................................................................... 142 Литература для дополнительного чтения.................................................................................. 143 Безопасность.................................................................................................................................................. 143 Понятие психологической безопасности................................................................................... 144 Как создать атмосферу безопасности.......................................................................................... 144 Роль лидера.............................................................................................................................................. 148 Вопросы..................................................................................................................................................... 150 Предварительные требования........................................................................................................ 151 Показатели................................................................................................................................................ 151 Альтернативы и эксперименты....................................................................................................... 151 Литература для дополнительного чтения.................................................................................. 152 Цель..................................................................................................................................................................... 152 Начните с ви́дения................................................................................................................................. 153 Идентифицируйте цель....................................................................................................................... 153 Задокументируйте цель...................................................................................................................... 155 Внесите цель в свой устав.................................................................................................................. 157 Продвигайте цель.................................................................................................................................. 160 Обновляйте цель.................................................................................................................................... 161 Вопросы..................................................................................................................................................... 161 Предварительные требования........................................................................................................ 162 Показатели................................................................................................................................................ 162 Альтернативы и эксперименты....................................................................................................... 162 Литература для дополнительного чтения.................................................................................. 163

Оглавление  9

Контекст............................................................................................................................................................. 163 Запишите контекст в устав................................................................................................................. 163 Обновляйте контекст........................................................................................................................... 168 Вопросы..................................................................................................................................................... 168 Предварительные требования........................................................................................................ 168 Показатели................................................................................................................................................ 168 Альтернативы и эксперименты....................................................................................................... 169 Согласование.................................................................................................................................................. 169 Запишите договоренности в устав................................................................................................ 170 Обновляйте соглашения..................................................................................................................... 174 Придерживайтесь договоренностей............................................................................................ 175 Вопросы..................................................................................................................................................... 177 Предварительные требования........................................................................................................ 177 Показатели................................................................................................................................................ 177 Альтернативы и эксперименты....................................................................................................... 178 Энергичная работа....................................................................................................................................... 178 Как быть энергичным........................................................................................................................... 179 Поддерживайте энергичную работу............................................................................................. 179 Делайте перерывы................................................................................................................................ 181 Вопросы..................................................................................................................................................... 181 Предварительные требования........................................................................................................ 182 Показатели................................................................................................................................................ 182 Альтернативы и эксперименты....................................................................................................... 182 Литература для дополнительного чтения.................................................................................. 183 Глава 8. Планирование..................................................................................................................................... 184 Истории............................................................................................................................................................. 185 Как написать историю......................................................................................................................... 186 Ценность для заказчика...................................................................................................................... 187 Разделение и объединение историй............................................................................................ 188 Специальные истории......................................................................................................................... 190 Вопросы..................................................................................................................................................... 193 Предварительные требования........................................................................................................ 194 Показатели................................................................................................................................................ 194 Альтернативы и эксперименты....................................................................................................... 195 Адаптивное планирование...................................................................................................................... 196 Ценные инкременты............................................................................................................................. 196 Фокус на один инкремент за раз.................................................................................................... 198 Разделите инкременты........................................................................................................................ 200 Делайте частые релизы и как можно раньше.......................................................................... 201 Ваш первый инкремент....................................................................................................................... 203 Адаптируйте свои планы.................................................................................................................... 204

10  Оглавление Как создать план..................................................................................................................................... 206 Баланс адаптивности и предсказуемости.................................................................................. 209 Адаптивное планирование и организационная культура.................................................. 211 Вопросы..................................................................................................................................................... 212 Предварительные требования........................................................................................................ 212 Показатели................................................................................................................................................ 213 Альтернативы и эксперименты....................................................................................................... 213 Литература для дополнительного чтения.................................................................................. 214 Визуальное планирование....................................................................................................................... 214 Кто планирует?........................................................................................................................................ 214 Картирование кластеров................................................................................................................... 215 Дальнейшая разбивка инкрементов............................................................................................ 217 Карты влияния........................................................................................................................................ 219 Перспективный анализ....................................................................................................................... 222 Составление карты историй............................................................................................................. 224 Обновление визуального плана..................................................................................................... 227 Вопросы..................................................................................................................................................... 228 Предварительные требования........................................................................................................ 228 Показатели................................................................................................................................................ 229 Альтернативы и эксперименты....................................................................................................... 229 Литература для дополнительного чтения.................................................................................. 230 Игра в планирование.................................................................................................................................. 230 Как играть.................................................................................................................................................. 231 Держите открытым окно возможностей..................................................................................... 234 Как выиграть в игре в планирование........................................................................................... 235 Приоритизация решений по разработке................................................................................... 236 Лицом к лицу с реальностью............................................................................................................ 237 Повторение игры в планирование................................................................................................ 237 Вопросы..................................................................................................................................................... 238 Предварительные требования........................................................................................................ 238 Показатели................................................................................................................................................ 239 Альтернативы и эксперименты....................................................................................................... 239 Вовлечение реального заказчика......................................................................................................... 239 Разработка для собственных нужд................................................................................................ 240 Разработка платформ.......................................................................................................................... 241 Внутренняя разработка на заказ.................................................................................................... 241 Аутсорсинг разработки....................................................................................................................... 242 Программное обеспечение для вертикального рынка....................................................... 243 Программное обеспечение для горизонтального рынка.................................................. 244 Вопросы..................................................................................................................................................... 244 Предварительные требования........................................................................................................ 244

Оглавление  11

Показатели................................................................................................................................................ 245 Альтернативы и эксперименты....................................................................................................... 245 Инкрементные требования...................................................................................................................... 246 Изменяемый документ с требованиями..................................................................................... 246 Когда эксперты не являются частью команды......................................................................... 247 Работайте инкрементно...................................................................................................................... 247 Документация.......................................................................................................................................... 249 Вопросы..................................................................................................................................................... 251 Предварительные требования........................................................................................................ 252 Показатели................................................................................................................................................ 252 Альтернативы и эксперименты....................................................................................................... 253 Литература для дополнительного чтения.................................................................................. 253 Глава 9. Владение................................................................................................................................................ 254 Планирование задач................................................................................................................................... 256 Рабочий ритм .......................................................................................................................................... 256 Создание задач....................................................................................................................................... 259 Визуальное отслеживание................................................................................................................. 261 Кросс-командные зависимости...................................................................................................... 264 Принятие и выполнение обязательств по итерации............................................................ 265 Незаконченные истории.................................................................................................................... 266 Срочные запросы.................................................................................................................................. 266 Ваша первая неделя............................................................................................................................. 267 Вопросы..................................................................................................................................................... 269 Предварительные требования........................................................................................................ 270 Показатели................................................................................................................................................ 271 Альтернативы и эксперименты....................................................................................................... 271 Литература для дополнительного чтения.................................................................................. 272 Потенциал......................................................................................................................................................... 272 Вчерашняя погода................................................................................................................................. 273 Потенциал и временные рамки итерации................................................................................. 274 Стабилизация потенциала................................................................................................................. 274 Оценка историй...................................................................................................................................... 277 Когда оценить трудно.......................................................................................................................... 281 Защита оценки........................................................................................................................................ 282 Ваш начальный потенциал................................................................................................................ 284 Как улучшить потенциал.................................................................................................................... 284 Потенциал — это не производительность................................................................................ 286 Вопросы..................................................................................................................................................... 288 Предварительные требования........................................................................................................ 289 Показатели................................................................................................................................................ 290 Альтернативы и эксперименты....................................................................................................... 290

12  Оглавление Резерв времени............................................................................................................................................. 291 Сколько резерва нужно...................................................................................................................... 291 Как использовать резерв................................................................................................................... 292 Вопросы..................................................................................................................................................... 295 Предварительные требования........................................................................................................ 296 Показатели................................................................................................................................................ 296 Альтернативы и эксперименты....................................................................................................... 297 Литература для дополнительного чтения.................................................................................. 297 Стендап-митинги........................................................................................................................................... 297 Как проводить ежедневные стендапы......................................................................................... 298 Будьте краткими..................................................................................................................................... 301 Вопросы..................................................................................................................................................... 302 Предварительные требования........................................................................................................ 302 Показатели................................................................................................................................................ 303 Альтернативы и эксперименты....................................................................................................... 303 Литература для дополнительного чтения.................................................................................. 303 Информативное рабочее пространство............................................................................................ 303 Тонкие сигналы....................................................................................................................................... 304 Большие наглядные диаграммы..................................................................................................... 305 Диаграммы улучшений....................................................................................................................... 306 Игры............................................................................................................................................................. 307 Вопросы..................................................................................................................................................... 308 Предварительные требования........................................................................................................ 308 Показатели................................................................................................................................................ 308 Альтернативы и эксперименты....................................................................................................... 309 Литература для дополнительного чтения.................................................................................. 309 Примеры заказчика..................................................................................................................................... 309 Описать....................................................................................................................................................... 310 Продемонстрировать.......................................................................................................................... 311 Разработать.............................................................................................................................................. 313 Вопросы..................................................................................................................................................... 314 Предварительные требования........................................................................................................ 314 Показатели................................................................................................................................................ 314 Альтернативы и эксперименты....................................................................................................... 314 Литература для дополнительного чтения.................................................................................. 315 Сделано Сделано.......................................................................................................................................... 315 Как быть в статусе «Сделано Сделано»........................................................................................ 317 Находить время...................................................................................................................................... 319 Организационные ограничения..................................................................................................... 319 Вопросы..................................................................................................................................................... 320 Предварительные требования........................................................................................................ 321 Показатели................................................................................................................................................ 321 Альтернативы и эксперименты....................................................................................................... 321

Оглавление  13

Глава 10. Ответственность.............................................................................................................................. 322 Доверие стейкхолдеров............................................................................................................................ 323 Добавьте немного суеты..................................................................................................................... 324 Проявите эмпатию................................................................................................................................. 325 Выполняйте обязательства............................................................................................................... 325 Управляйте проблемами.................................................................................................................... 326 Уважайте цели заказчика................................................................................................................... 328 Сделайте так, чтобы стейкхолдеры выглядели хорошо...................................................... 329 Будьте честны.......................................................................................................................................... 329 Вопросы..................................................................................................................................................... 330 Предварительные требования........................................................................................................ 330 Показатели................................................................................................................................................ 330 Альтернативы и эксперименты....................................................................................................... 330 Литература для дополнительного чтения.................................................................................. 331 Демо для стейкхолдеров........................................................................................................................... 331 Петли обратной связи.......................................................................................................................... 331 Частота демо............................................................................................................................................ 332 Как проводить демо для стейкхолдеров.................................................................................... 333 Подготовьтесь......................................................................................................................................... 335 Когда дела идут плохо......................................................................................................................... 336 Вопросы..................................................................................................................................................... 337 Предварительные требования........................................................................................................ 338 Показатели................................................................................................................................................ 338 Альтернативы и эксперименты....................................................................................................... 339 Прогнозирование......................................................................................................................................... 339 Неопределенность и риск................................................................................................................. 340 Запланированные даты релизов.................................................................................................... 341 Прогнозы осуществимости............................................................................................................... 342 Прогнозы сроков и объема работы.............................................................................................. 343 Вопросы..................................................................................................................................................... 348 Предварительные требования........................................................................................................ 348 Показатели................................................................................................................................................ 349 Альтернативы и эксперименты....................................................................................................... 349 Литература для дополнительного чтения.................................................................................. 349 Дорожные карты........................................................................................................................................... 350 Agile-руководство................................................................................................................................. 350 Вариант 1. Только факты .................................................................................................................... 351 Вариант 2. Общее направление...................................................................................................... 352 Вариант 3. Дата и примерный объем работы........................................................................... 352 Вариант 4. Детальные планы и прогнозы................................................................................... 353 Корпоративные системы отслеживания..................................................................................... 354 Когда дорожная карта недостаточно хороша ......................................................................... 355 Вопросы..................................................................................................................................................... 357

14  Оглавление Предварительные требования........................................................................................................ 357 Показатели................................................................................................................................................ 357 Альтернативы и эксперименты....................................................................................................... 357 Литература для дополнительного чтения.................................................................................. 358 Менеджмент.................................................................................................................................................... 358 Теория X и теория Y.............................................................................................................................. 359 Роль руководителя в Agile................................................................................................................. 360 Дисфункция измерений...................................................................................................................... 361 Почему дисфункция измерений неизбежна............................................................................. 362 Делегируемое управление................................................................................................................ 364 Когда показатели необходимы........................................................................................................ 366 Вопросы..................................................................................................................................................... 367 Предварительные требования........................................................................................................ 367 Показатели................................................................................................................................................ 368 Альтернативы и эксперименты....................................................................................................... 368 Литература для дополнительного чтения.................................................................................. 369 Глава 11. Совершенствование...................................................................................................................... 370 Ретроспективы............................................................................................................................................... 371 Виды ретроспектив............................................................................................................................... 372 Как проводить пульсирующие ретроспективы....................................................................... 372 Шаг 1. Первая директива (5 минут)................................................................................................ 373 Шаг 2. Мозговой штурм (20 минут)................................................................................................ 374 Шаг 3. Безмолвное сопоставление (15 минут).......................................................................... 374 Шаг 4. Генерация идей (инсайтов) (10–30 минут).................................................................... 375 Шаг 5. Цель ретроспективы (10–20 минут)................................................................................. 375 Довести дело до конца........................................................................................................................ 376 Вопросы..................................................................................................................................................... 376 Предварительные требования........................................................................................................ 378 Показатели................................................................................................................................................ 378 Альтернативы и эксперименты....................................................................................................... 378 Литература для дополнительного чтения.................................................................................. 379 Динамики команды...................................................................................................................................... 379 Что формирует команду..................................................................................................................... 379 Развитие команды................................................................................................................................. 380 Коммуникация, сотрудничество и взаимодействие.............................................................. 386 Совместное лидерство ....................................................................................................................... 388 Токсичное поведение.......................................................................................................................... 391 Вопросы..................................................................................................................................................... 392 Предварительные требования........................................................................................................ 393 Показатели................................................................................................................................................ 393 Альтернативы и эксперименты....................................................................................................... 393 Литература для дополнительного чтения.................................................................................. 394

Оглавление  15

Устранение препятствий........................................................................................................................... 394 Выявление препятствий..................................................................................................................... 395 Круги и суп................................................................................................................................................ 395 Вопросы..................................................................................................................................................... 399 Предварительные требования........................................................................................................ 399 Показатели................................................................................................................................................ 400 Альтернативы и эксперименты....................................................................................................... 400 Литература для дополнительного чтения.................................................................................. 400

ЧАСТЬ III. НАДЕЖНАЯ ПОСТАВКА Добро пожаловать на уровень поставки........................................................................................... 402 Достижение свободного владения навыками на уровне поставки...................................... 404 Глава 12. Сотрудничество .............................................................................................................................. 406 Коллективное владение кодом.............................................................................................................. 407 Как заставить коллективное владение работать.................................................................... 407 Программирование без эго.............................................................................................................. 408 Сотрудничество без конфликтов.................................................................................................... 409 Работа с незнакомым кодом ............................................................................................................ 410 Преимущества для программистов.............................................................................................. 411 Вопросы..................................................................................................................................................... 412 Предварительные требования........................................................................................................ 412 Показатели................................................................................................................................................ 413 Альтернативы и эксперименты....................................................................................................... 414 Парное программирование..................................................................................................................... 414 Почему парное? ..................................................................................................................................... 415 Рабочие станции для парного программирования .............................................................. 415 Как работать в паре.............................................................................................................................. 416 Эффективная навигация..................................................................................................................... 418 Обучение при работе в паре............................................................................................................ 419 Трудности.................................................................................................................................................. 419 Вопросы..................................................................................................................................................... 421 Предварительные требования........................................................................................................ 423 Показатели................................................................................................................................................ 423 Альтернативы и эксперименты....................................................................................................... 424 Литература для дополнительного чтения.................................................................................. 425 Групповое программирование............................................................................................................... 425 Как работать в групповом программировании....................................................................... 426 Почему групповое программирование работает.................................................................. 427 Рабочая станция для группового программирования......................................................... 427 Как заставить режим группового программирования работать..................................... 427 Вопросы..................................................................................................................................................... 430 Предварительные требования........................................................................................................ 430

16  Оглавление Показатели................................................................................................................................................ 430 Альтернативы и эксперименты....................................................................................................... 430 Литература для дополнительного чтения.................................................................................. 431 Единый язык.................................................................................................................................................... 431 Дилемма экспертных знаний в предметной области........................................................... 431 Говорить на одном языке................................................................................................................... 432 Как создать единый язык................................................................................................................... 432 Вопросы..................................................................................................................................................... 435 Предварительные требования........................................................................................................ 435 Показатели................................................................................................................................................ 436 Альтернативы и эксперименты....................................................................................................... 436 Литература для дополнительного чтения.................................................................................. 436 Глава 13. Разработка.......................................................................................................................................... 437 Нулевое трение.............................................................................................................................................. 438 Обратная связь за секунду................................................................................................................ 439 Знайте свой редактор ......................................................................................................................... 441 Воспроизводимые сборки................................................................................................................. 441 Пятиминутная интеграция................................................................................................................. 443 Контролировать сложность.............................................................................................................. 444 Автоматизировать все......................................................................................................................... 444 Автоматизируйте инкрементно...................................................................................................... 445 Автоматизация устаревшего кода................................................................................................. 446 Вопросы..................................................................................................................................................... 447 Предварительные требования........................................................................................................ 448 Показатели................................................................................................................................................ 448 Альтернативы и эксперименты....................................................................................................... 449 Непрерывная интеграция......................................................................................................................... 449 Непрерывная интеграция — это практика, а не инструмент............................................ 450 Множество разновидностей непрерывной интеграции..................................................... 452 Танец непрерывной интеграции.................................................................................................... 453 Непрерывная интеграция без CI-сервера.................................................................................. 454 Синхронная или асинхронная интеграция................................................................................ 455 Многоступенчатые интеграционные сборки........................................................................... 456 Запросы на слияние кодов (пул-реквесты) и ревью кода................................................... 457 Вопросы..................................................................................................................................................... 458 Предварительные требования........................................................................................................ 459 Показатели................................................................................................................................................ 460 Альтернативы и эксперименты....................................................................................................... 460 Литература для дополнительного чтения.................................................................................. 460 Разработка через тестирование............................................................................................................ 461 Почему TDD работает........................................................................................................................... 461 Как использовать TDD......................................................................................................................... 463

Оглавление  17

Ешьте луковицу с середины.............................................................................................................. 466 Пример TDD.............................................................................................................................................. 467 Вопросы..................................................................................................................................................... 474 Предварительные требования........................................................................................................ 475 Показатели................................................................................................................................................ 476 Альтернативы и эксперименты....................................................................................................... 476 Литература для дополнительного чтения.................................................................................. 477 Быстрые надежные тесты.......................................................................................................................... 477 Использование узких модульных тестов.................................................................................... 478 Тестирование внешних взаимодействий с помощью узких интеграционных тестов...................................................................................................................... 479 Моделирование нелокальных зависимостей.......................................................................... 479 Контроль глобального состояния.................................................................................................. 480 Написание коммуникативных тестов........................................................................................... 480 Разделение инфраструктуры и логики........................................................................................ 482 Применение широких тестов только в качестве страховочной сетки ........................ 482 Добавление тестов к существующему коду............................................................................... 483 Предварительные требования........................................................................................................ 484 Показатели................................................................................................................................................ 484 Альтернативы и эксперименты....................................................................................................... 484 Литература для дополнительного чтения.................................................................................. 484 Рефакторинг ................................................................................................................................................... 485 Как делать рефакторинг..................................................................................................................... 485 Рефакторинг в действии..................................................................................................................... 486 Вопросы .................................................................................................................................................... 494 Предварительные требования........................................................................................................ 495 Показатели................................................................................................................................................ 496 Альтернативы и эксперименты....................................................................................................... 496 Литература для дополнительного чтения.................................................................................. 496 Спайк-решения ............................................................................................................................................. 497 Простые вопросы.................................................................................................................................. 497 Сторонние зависимости..................................................................................................................... 498 Дизайн-эксперименты......................................................................................................................... 498 Найдите время для спайков.............................................................................................................. 499 Вопросы..................................................................................................................................................... 499 Предварительные требования........................................................................................................ 500 Показатели................................................................................................................................................ 500 Альтернативы и эксперименты....................................................................................................... 500 Глава 14. Дизайн.................................................................................................................................................. 502 Инкрементный дизайн............................................................................................................................... 505 Никогда не останавливайте работу над дизайном................................................................ 505 Как работает инкрементный дизайн............................................................................................ 506

18  Оглавление Уровни дизайна...................................................................................................................................... 507 Архитектура на основе рисков........................................................................................................ 511 Вопросы..................................................................................................................................................... 513 Предварительные требования........................................................................................................ 514 Показатели................................................................................................................................................ 515 Альтернативы и эксперименты....................................................................................................... 515 Литература для дополнительного чтения.................................................................................. 515 Простой дизайн............................................................................................................................................. 516 Вам это не понадобится (YAGNI: You Aren’t Gonna Need It)................................................. 517 Однажды и только однажды............................................................................................................. 517 Связанность и сплоченность........................................................................................................... 519 Сторонние компоненты...................................................................................................................... 519 Быстрое завершение с ошибкой.................................................................................................... 520 Самодокументируемый код.............................................................................................................. 521 Опубликованные интерфейсы ........................................................................................................ 522 Оптимизация производительности ............................................................................................. 523 Вопросы..................................................................................................................................................... 523 Предварительные требования........................................................................................................ 524 Показатели................................................................................................................................................ 524 Альтернативы и эксперименты....................................................................................................... 524 Литература для дополнительного чтения.................................................................................. 525 Рефлексивный дизайн................................................................................................................................ 525 Как работает рефлексивный дизайн............................................................................................. 526 Рефлексивный дизайн на практике............................................................................................... 526 Реверс-инжиниринг дизайна........................................................................................................... 529 Определение улучшений................................................................................................................... 530 Проблемный код.................................................................................................................................... 531 Выполняйте рефакторинг инкрементно..................................................................................... 533 Вопросы..................................................................................................................................................... 534 Предварительные требования........................................................................................................ 534 Показатели................................................................................................................................................ 535 Альтернативы и эксперименты....................................................................................................... 535 Литература для дополнительного чтения.................................................................................. 535 Глава 15. DevOps.................................................................................................................................................. 536 Сборка для эксплуатации.......................................................................................................................... 537 Моделирование угроз......................................................................................................................... 538 Конфигурация......................................................................................................................................... 539 Секреты...................................................................................................................................................... 540 Параноидальная телеметрия........................................................................................................... 540 Ведение журнала событий ............................................................................................................... 541 Показатели и пригодность к наблюдению................................................................................. 543 Мониторинг и оповещения............................................................................................................... 544

Оглавление  19

Вопросы..................................................................................................................................................... 547 Предварительные требования........................................................................................................ 547 Показатели................................................................................................................................................ 548 Альтернативы и эксперименты....................................................................................................... 548 Литература для дополнительного чтения.................................................................................. 548 Флаги функций............................................................................................................................................... 549 Замковый камень .................................................................................................................................. 549 Флаги функций........................................................................................................................................ 550 Предварительные требования........................................................................................................ 552 Показатели................................................................................................................................................ 553 Альтернативы и эксперименты....................................................................................................... 553 Литература для дополнительного чтения.................................................................................. 553 Непрерывное развертывание................................................................................................................ 554 Как использовать непрерывное развертывание.................................................................... 554 Обнаружение сбоев развертывания............................................................................................ 555 Устранение сбоев развертывания................................................................................................. 555 Инкрементные релизы........................................................................................................................ 557 Миграция данных ................................................................................................................................. 558 Предварительные требования........................................................................................................ 559 Показатели................................................................................................................................................ 559 Альтернативы и эксперименты....................................................................................................... 559 Литература для дополнительного чтения.................................................................................. 560 Эволюционная системная архитектура.............................................................................................. 560 Вам действительно это понадобится? ......................................................................................... 561 Нацеленность на простоту................................................................................................................ 562 Контроль сложности ........................................................................................................................... 563 Рефакторинг системной архитектуры ........................................................................................ 565 Предварительные требования........................................................................................................ 568 Показатели................................................................................................................................................ 569 Альтернативы и эксперименты....................................................................................................... 569 Литература для дополнительного чтения.................................................................................. 569 Глава 16. Качество.............................................................................................................................................. 570 Без багов........................................................................................................................................................... 571 Не ищите виноватого в багах........................................................................................................... 572 Как встроить качество......................................................................................................................... 573 Исправляйте баги незамедлительно............................................................................................ 576 Роль тестировщика............................................................................................................................... 577 Правильное мироощущение............................................................................................................ 577 Вопросы..................................................................................................................................................... 578 Предварительные требования........................................................................................................ 579 Показатели................................................................................................................................................ 579 Альтернативы и эксперименты....................................................................................................... 580

20  Оглавление Обнаружение слепых зон......................................................................................................................... 580 Подтвержденное знание.................................................................................................................... 580 Исследовательское тестирование................................................................................................. 582 Хаос-инжиниринг.................................................................................................................................. 583 Тестирование на проникновение и оценка уязвимостей................................................... 584 Вопросы..................................................................................................................................................... 585 Предварительные требования........................................................................................................ 586 Показатели................................................................................................................................................ 586 Альтернативы и эксперименты....................................................................................................... 586 Анализ инцидентов...................................................................................................................................... 587 Природа сбоя.......................................................................................................................................... 588 Проведение анализа............................................................................................................................ 590 Обучение организации....................................................................................................................... 597 Ответственность за инциденты....................................................................................................... 598 Вопросы..................................................................................................................................................... 598 Предварительные требования........................................................................................................ 599 Показатели................................................................................................................................................ 599 Альтернативы и эксперименты....................................................................................................... 599 Литература для дополнительного чтения.................................................................................. 600

ЧАСТЬ IV. ОПТИМИЗАЦИЯ РЕЗУЛЬТАТОВ Добро пожаловать в область оптимизации..................................................................................... 602 Достижение навыков на уровне оптимизации............................................................................... 604 Глава 17. Автономность................................................................................................................................... 605 Экспертные знания в области заказчика........................................................................................... 605 Бизнес-решения............................................................................................................................................ 606 Ответственность и надзор ....................................................................................................................... 607 Финансирование........................................................................................................................................... 607 Эксперименты и литература для дополнительного чтения...................................................... 608 Глава 18. Открытия............................................................................................................................................. 609 Подтвержденное знание........................................................................................................................... 610 Способность к адаптации.......................................................................................................................... 610 Эксперименты и литература для дополнительного чтения...................................................... 612 Глава 19. Взгляд в будущее ............................................................................................................................ 613 Библиография........................................................................................................................................................ 615 Об авторе................................................................................................................................................................. 623

Отзывы

Автор «Искусства Agile-разработки» смог совершить, казалось бы, невозможное, собрав все материалы по обширнейшей теме разработки современного программного обес­печения в понятную и увлекательную книгу. Новички, лишь начинающие изучать итеративные процессы, найдут в ней отличный обзор популярных практик. Людям, заблудившимся в дебрях мудреных процессов «масштабизации Agile», она предлагает хорошие идеи выхода из этого ада. Первое издание оказало огромное влияние на мою карьеру два десятилетия назад, и, уверен, второе издание аналогичным образом поможет миллионам разработчиков улучшить свои методы поставки ПО. Гойко Аджич, автор книг Running Serverless, Impact Mapping и Specification by Example В этой книге есть все: от кода до поставки готового продукта. Заработанные десятилетиями тяжелого труда знания превратились в легкочитаемый и доступный для восприятия материал — обязательный к прочтению для всех, кто работает с командой разработчиков программного обеспечения или в ней. Ави Кесснер, инженер, Forter Эта книга получит свое постоянное место на моей книжной полке. Кришна Кумар, основатель и CEO, Exathink Research Первое издание этой книги заворожило меня до такой степени, что до сих пор стоит на моей книжной полке в качестве справочника. Второе издание сохраняет шарм своего предшественника и содержит еще больше знаний, накопленных за последнее десятилетие. Бенджамин Мускалла, старший инженер-программист, GitHub Одна из самых полных книг по Agile-разработке программного обеспечения, которые я когда-либо читала. Очень прагматичная, с яркими примерами, легко применимыми к любому проекту разработки ПО независимо от технологического стека, размера команды или предметной области отрасли. Определенно жемчужина, стоящая того, чтобы держать ее под рукой. Луиза Нуньес, менеджер программ, Thoughtworks

22  Отзывы Это моя любимая книга об Agile. Она охватывает технические и управленческие темы. Я использую ее на своих занятиях и всегда рекомендую своим клиентам. Николас Паес, инженер-программист и преподаватель, Университет Буэнос-Айреса Джеймс подробнейшим образом описывает собственный опыт в Agile-разработке ПО. Простыми словами, связывая теорию с практикой. Кен Пью, главный консультант, автор книги Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability Тысячи книг об Agile. Какую из них прочитать? Я советую вам эту. Джеймс работает с Agile с первых дней его появления и знает свое дело. Книга разбирает весь бессмысленный мусор в нашей отрасли, окружающий это понятие, и предлагает тщательно выверенный, целостный подход. Этот подход не будет быстрым и легким, но он того стоит. Мне понравилась книга «Искусство Agile-разработки». Это книга с характером! Бас Водде, соавтор LeSS Джеймс Шор полностью обновил «Искусство Agile-разработки», дополнив книгу новыми инструментами, методами и уроками прошедшего десятилетия. Эта жемчужина среди книг поможет вам превратить ваш стиль работы в действительно эффективный Agile-подход. Билл Уэйк, XP123, LLC

Моей семье

Предисловие

Когда мы писали Манифест Agile для разработки программного обеспечения, нашими сторонниками было незначительное меньшинство людей, пытавшихся изменить отрасль. Сейчас, 20 лет спустя, «agile» — это мейнстрим. Я пишу «agile» в кавычках намеренно: множество людей говорят, что они занимаются разработкой программного обеспечения по Agile, в самом деле искренне в это веря, однако их действия мало напоминают то ви́дение, которым мы поделились со всеми два десятилетия назад. Правда в том, что для работы по Agile требуется целая сеть взаимосвязанных практик, охватывающая как управление, так и техническую работу по созданию ПО. Многие из этих практик, особенно технические, далеко не всем хорошо понятны или не изучаются широко. Следовательно, слишком многие люди имеют искаженное представление о том, что могло бы быть очень эффективным способом создания программных продуктов. Джеймс Шор был одним из пионеров, вставших на тропу экстремального программирования (Extreme Programming, XP), центрального элемента движения Agile. Первое издание этой книги было отличным руководством для команд, показывавшим им, что нужно знать для правильного выполнения Agile-процессов. Позже Джеймс вместе с Дианой Ларсен продолжили работу над созданием модели Agile Fluency™, которая объединила в себе их опыт развития навыков в использовании подходов Agile. Модель показывает, что простое применение техник проектного управления, часто именуемых базовым подходом Scrum, дает некую ценность, фокусируя внимание на потребностях клиентов, но не учитывает технических навыков, необходимых для того, чтобы полностью раскрыть преимущества высокой производительности и надежности, которых добиваются многие команды. Эта позиция непосредственно определяет структуру книги, значительная часть которой посвящена тому, как сфокусироваться на создании реальной ценности и как надежно поставить ее потребителю продукта. «Сфокусироваться на ценности» означает понимать потенциал командной работы, развивать навыки адаптивного планирования и тесно сотрудничать с заказчиками и конечными пользователями готового ПО. В понятие «надежно поставить ценность» входят основные технические практики тестирования, рефакторинга, дизайна и коллективной разработки. Оно также учитывает парадоксальное наблюдение, что создание программного обеспечения, обладающего высоким внутренним качеством, снижает затраты и увеличивает скорость поставки продукта. Сочетание культуры DevOps и непрерывной поставки (continuous delivery) дает возможность быстро вводить в эксплуатацию множество функций, а это, в свою очередь, позволяет командам понять, что является ценным в программном обеспечении, наблюдая, как оно используется на практике.

Предисловие  25

Двадцать лет назад мне повезло найти свое место в компании Thoughtworks, где наши команды используют такие навыки, чтобы создавать для наших клиентов новые программные продукты и заменять ими устаревшие. Как и Джеймс, мы обнаружили, что техники экстремального программирования служили надежной основой для нашей работы, и мы весьма успешно применяли их в течение последних двух десятилетий. Поэтому я очень рад, что Джеймс переписал свою книгу, добавив в нее опыт еще одного десятилетия своей работы в роли коуча. В результате получился прочный фундамент для изучения тех навыков, которые нам так помогли. Как и все действительно стоящее, обучение займет время, и на вашем пути будут разочарования. Но этот путеводитель может вам помочь — избавив от безрезультативных церемоний и приведя к источнику силы, которую мы с Джеймсом почувствовали, впервые применив эти методы много лет назад. Мартин Фаулер, Chief Scientist, Thoughtworks

Введение

Вопрос: Что нужно делать, чтобы выступить в Карнеги-холле? Ответ: Практиковаться, практиковаться и еще раз практиковаться. Я хочу помочь вам овладеть мастерством Agile-разработки. Agile, как и любой командный подход к разработке программного обеспечения, — в своей основе человеческое искусство, зависящее от капризов людей и их взаимодействия. Чтобы мастерски овладеть Agile-разработкой, вам нужно научиться ежеминутно оценивать множество возможностей и интуитивно выбирать лучшее направление действий. Как можно научиться такому сложному искусству? Практикуясь! Во-первых, эта книга — руководство. Она содержит подробное описание одного из способов практического применения Agile. Книга основана на экстремальном программировании, но также берет идеи и практики из Scrum, Kanban, DevOps, Lean Software Development, Lean Startup и др. В конечном счете это практическое пособие, которое позволит вам успешно внедрить Agile-разработку в вашу команду и организацию или поможет обнаружить, что Agile не подходит в вашей ситуации. Во-вторых, эта книга призвана помочь вам овладеть мастерством Agile-разработки. Освоить Agile означает выйти за рамки книги рецептов. Разработка программного обеспечения — слишком чувствительный к контексту процесс, чтобы какой-то один подход подошел вам полностью, и слишком богатый нюансами, чтобы какая-то книга могла научить вас, как его освоить. Мастерство приходит изнутри — благодаря опыту и интуитивному пониманию природы волн, вызванных брошенным в воду камнем вашего выбора. Я не могу спрогнозировать, какую волну поднимет ваш выбор в вашей организации. Я и не пытаюсь. Вы должны сами определить нюансы и достичь понимания. Это единственный способ овладеть искусством. Следуйте практикам. Смотрите, что происходит. Думайте, почему они сработали… или не сработали. Потом повторяйте. Что было таким же? Что получилось по-другому? Почему? Потом делайте это снова. И снова. Поначалу вам может быть трудно понять, как использовать каждую из практик. Они могут выглядеть простыми на бумаге, но сложными в реальном применении. Продолжайте практиковаться, пока не станет легче. По мере того как применять Agile станет проще, вы обнаружите, что некоторые мои советы для вас не работают. Поначалу вы не сможете различить, в чем проблема: в инструкциях, которые я дал, или в том, как вы их выполняете. Продолжайте практиковаться, пока не почувствуете уверенность. Как только это произойдет, нарушьте правила. Измените мои инструкции так, чтобы они работали лучше в вашей

Введение  27

конкретной ситуации. В каждой практике есть подраздел «Альтернативы и эксперименты», содержащий идеи для исследований. Однажды правила перестанут вас интересовать. В конце концов, Agile не о том, чтобы следовать правилам. Тогда вы подумаете: «Речь о простоте и обратной связи, общении и доверии. О поставке ценности и смелости делать правильные вещи в нужное время». Вы станете мгновенно оценивать множество возможностей и интуитивно выбирать лучшее направление действий. Когда этот момент настанет, отдайте книгу (пусть и с загнутыми уголками страниц и, возможно, слегка потрепанную) кому-нибудь еще, чтобы эти люди тоже смогли овладеть искусством разработки Agile.

ДЛЯ ПРАГМАТИКОВ А что, если вы не хотите овладевать так называемым «искусством»? Что, если вы хотите просто разрабатывать хорошее ПО? Не волнуйтесь. Эта книга и для вас тоже. На основе моего многолетнего опыта Agile-разработки я создал единый, четко определенный, комплексный подход. Это позволяет мне использовать простой язык. Я даю много практических советов. Я честно пишу, когда мой подход не будет работать и какие альтернативы можно рассмотреть в таком случае. Глава 2 поможет вам начать. Есть и обратная сторона обсуждения только одного подхода: ни один подход не применим ко всем случаям. Мой совет может быть непригоден для вашей команды или организации. Прочтите главы 4 и 5, чтобы понять, на каких общих условиях возможен успех, и изучите подраздел «Предварительные требования» каждой практики. Не стоит сразу думать, что какая-либо конкретная практика вам не подходит. Некоторые практики, описанные в этой книге, противоречат здравому смыслу или просто не кажутся интересными. Большинство из них лучше всего работают в сочетании с другими. Если можете, то попробуйте применять практики, как написано, в течение нескольких месяцев, получите реальный опыт их работы в ваших условиях и потом измените их. Я применяю эти идеи в реальной работе уже более 20 лет. В правильной среде они действительно работают. Agile оказывается более увлекательным и успешным, чем любой другой подход к разработке программного обеспечения, который я пробовал. Присоединяйтесь.

ЧТО НОВОГО ВО ВТОРОМ ИЗДАНИИ Первое издание было полностью переработано. Во втором издании сохранен приземленный, практический подход, свойственный первому изданию, как и большинство приводившихся в нем практик. Но почти все они были переписаны с учетом 14 лет прогресса Agile, не говоря уже о моем собственном 14-летнем опыте.

28  Введение Я полностью переработал книгу, чтобы она позволяла обеспечить постепенное внедрение Agile и лучше отражала реальное использование командами. Принципы и настройки, обсуждавшиеся в части III первого издания, были распределены между практиками, чтобы сделать их более заметными и понятными, и я внес в каждую практику предложения по экспериментам. Среди наиболее заметных дополнений: zz

подробное руководство по внедрению Agile и адаптации этого внедрения к потребностям вашей компании, основанное на модели Agile FluencyТМ1, которую я создал вместе с Дианой Ларсен;

zz

новая глава о масштабировании Agile, основанная на моем опыте помощи большим и маленьким компаниям;

zz

новая глава о DevOps, содержащая новый материал о работе в сфере эксплуатации и безопасности, а также вдохновленные темой DevOps обновления по остальной части книги;

zz

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

ДЛЯ КОГО ПРЕДНАЗНАЧЕНА КНИГА Эта книга для каждого, кто уже работает с командой Agile или надеется работать в будущем. Сюда входят, конечно же, программисты, а также менеджеры, руководители высшего звена, эксперты в предметных областях, тестировщики, продакт-менеджеры, руководители проектов, архитекторы, сотрудники отделов эксплуатации и отделов безопасности, дизайнеры и бизнес-аналитики. Команды Agile кросс-функциональны; книга отражает этот факт. Книга представляет собой краткий справочник, но ее также можно читать и подряд, от корки до корки. Каждая практика в частях II–IV предназначена для самостоятельного чтения. Блоки «См. также» и ссылки на источники помогут вам сопоставить информацию. Вдобавок печатное издание можно открыть в любом месте и быстро просмотреть интересующую информацию. Можете пролистать книгу и остановиться, чтобы прочитать какую-то врезку более внимательно, если она привлечет ваше внимание. Если вы менеджер или руководитель высшего звена, который хочет понять, как Agile может или должен работать в вашей компании, то прочитайте часть I. Если вы руководитель командного уровня, то прочтите еще и раздел «Менеджмент» главы 10 и, возможно, другие практики, рассматриваемые в той же главе. Если вы член команды или менеджер, заинтересованный в том, чтобы внедрить Agile в свою компанию или улучшить уже работающую в ней практику Agile, то прочитайте всю книгу целиком. Часть I поможет вам понять, как представить идеи Agile Fluency — зарегистрированный товарный знак Agile Fluency Project LLC.

1

Введение  29

Agile коллегам. Остальной материал книги поможет разобраться, как воплотить Agile в жизнь. Если вы часть Agile-команды и просто хотите получить знания, которые позволят выполнять вашу работу, то можете сосредоточиться на практиках, изложенных в частях II и III. Начните с главы 1, чтобы получить общую картину, затем перейдите к тем практикам, которые использует ваша команда. Если вы не являетесь частью Agile-команды, но работаете с одной из них, то посоветуйтесь с ними, что почитать. Продакт-менеджеры, владельцы продукта, дизайнеры могут начать с главы 8 и раздела «Цель» главы 7. Сотрудникам отделов безопасности и отделов эксплуатации рекомендую разделы «Сборка для эксплуа­ тации» главы 15, «Обнаружение слепых зон» и «Анализ инцидентов» главы 16. Тестировщики, ознакомьтесь с главой 16. Если вам просто любопытно узнать об Agile, то начните с главы 1. После этого ознакомьтесь с частями II–IV. Начните с наиболее интересных для вас практик. Можете читать их в любом порядке.

О ПРИГЛАШЕННЫХ АВТОРАХ Эта книга создана в соавторстве с несколькими выдающимися людьми. Гитте Клитгаард написала раздел «Безопасность» главы 7, профессионально осветив тему психологической безопасности. Диана Ларсен написала разделы «Динамики команды» и «Устранение препятствий» главы 11, поделившись своим многолетним опытом организационного и командного развития. Шейн Уорден, мой соавтор первого издания, не смог написать новый материал для второго, но остался надежным и ценным советчиком, и наша работа над первым изданием легла в основу этой книги.

Гитте Клитгаард Гитте Клитгаард — Agile-коуч, инструктор и наставник, специализирующаяся на помощи организациям в формировании психологической безопасности и ответственности. Гитте сразу переходит к сути дела и помогает людям стать самими собой и таким образом достичь успеха. Ее вклад в сообщество включает организацию встреч для тренеров и выступления на конференциях, где она поднимает темы психического здоровья и психологической безопасности и делает их доступными для общего понимания. Гитте создает безопасную и уважительную атмосферу на работе и за ее пределами. Она умеет слушать и вовлекать в обсуждение более тихие голоса и малые сообщества. В свободное время Гитте собирает LEGO, коллекционирует фигурки Йоды и поддерживает связь с друзьями со всего земного шара, многих из которых она считает своей второй семьей. Гитте является владельцем Native Wired и руководила преобразованиями в таких компаниях, как LEGO, Spotify и Mentimeter.

30  Введение

Диана Ларсен Более 20 лет Диана Ларсен вносила свой вклад в формирование основ и расширение идей Agile, а также в практику создания и развития квалифицированных команд. Диана — соавтор книг Agile Retrospectives1, Liftoff, 2nd ed., Five Rules for Accelerated Learning и электронной книги The Agile Fluency Model: A Brief Guide to Success with Agile; кроме того, сейчас пишет две новые книги. Будучи главным коучем, консультантом, координатором, спикером и наставником, она продолжает вносить свой вклад и соответствует своему званию в проекте Agile Fluency — «Главное связующее звено» (Chief Connector). Живет в Портленде, на верхнем левом побережье США.

Шейн Уорден Шейн Уорден — руководитель инженерно-технической службы и писатель, в частности, соавтор первого издания этой книги, а также книги Masterminds of Programming2. В свободное от работы время он помогает находить животным хорошие дома.

УСЛОВНЫЕ ОБОЗНАЧЕНИЯ В книге используются следующие условные обозначения. Курсив Курсивом выделены новые термины и важные понятия.

Аудитория В этих блоках указывается целевая аудитория каждой практики Agile.

Шрифт одной ширины

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

Показывает добавленный код в работающих примерах кода.

В блоках-выносках выделены важные концепции.

См. также В этих блоках приводятся связанные практики.

Перечеркнутый шрифт одной ширины

Показывает удаленный код в работающих примерах кода. Шрифт без засечек

Используется для обозначения URL, адресов электронной почты, названий кнопок, каталогов. Дерби Э., Ларсен Д. Agile ретроспектива. Как превратить хорошую команду в великую.

1

Бьянкуцци Ф., Уорден Ш. Пионеры программирования: диалоги с создателями наиболее популярных языков программирования.

2

Введение  31

ИСПОЛЬЗОВАНИЕ ПРИМЕРОВ КОДА Дополнительные материалы доступны для скачивания по ссылке https://www.james­ shore.com/v2/books/aoad2. Пожалуйста, напишите по адресу электронной почты [email protected], если у вас технический вопрос или проблема с использованием материалов. Эта книга призвана помочь в решении ваших задач. В общем случае все примеры кода из книги вы можете использовать в своих программах и в документации. Вам не нужно обращаться в издательство за разрешением, если вы не собираетесь воспроизводить существенные части кода, или если вы разрабатываете программу и используете в ней несколько фрагментов кода из книги, или если будете цитировать эту книгу либо примеры из нее, отвечая на вопросы. Вам потребуется разрешение от издательства O’Reilly, если вы хотите продавать или распространять примеры из книги либо хотите включить существенные объемы программного кода из книги в документацию вашего продукта. Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN. Получить разрешение на использование значительных объемов программного кода примеров из этой книги можно по адресу [email protected].

БЛАГОДАРНОСТИ Эта книга вдохновлена бессчетным количеством источников. На протяжении всей книги я поблагодарил скольких мог, но наверняка забыл кого-то. (Пожалуйста, примите мои извинения.) Я хочу выразить особую признательность Кенту Беку, Рону Джеффрису и Уорду Каннингему за то, что они создали экстремальное программирование, с которого я начал мое Agile-путешествие. Алистер Коберн и его круглый стол по программному обеспечению, как и бурные споры и обсуждения Вики-страниц C2 Уорда Каннингема, помогли определить направление в начале этого пути. Благодарю также Диану Ларсен, с которой я работаю много лет — ее точка зрения так хорошо уравновешивает мою. И конечно, Мартина Фаулера, чей вдумчивый стиль письма много лет вдохновляет меня. Поддержка этого издания со стороны O’Reilly была просто исключительной. Я выражаю огромную благодарность Гэри О’Брайену, моему редактору, обеспечивавшему постоянную обратную связь и поддержку. Благодарю также Мелиссу Даффилд, которая помогла сделать так, чтобы книга пользовалась успехом; Райана Шоу, убедившего меня в том, что пришло время для второго издания; Дебору Бейкер, подготовившую издание ранних выпусков книги; Сюзанну Хьюстон, которая позаботилась о том, чтобы люди узнали о книге; Ника Адамса и команду Tools издательства O’Reilly, которые выстроили производственный процесс и успешно разобрались с моими запутанными и придирчивыми требованиями к оформлению; Кристофера Фоучера, который руководил превращением «сырой рукописи» в «законченную книгу»; Тонью Трибулу и Стефани Инглиш, исправивших мои грамматические чудачества; Кейт Дулли, превратившую мои наброски от руки в понятные рисунки.

32  Введение Что касается обратной связи, особую признательность выражаю моим рецензентам. Рецензирование было открытым, и мы получили более 700 электронных писем от десятков людей. Практически каждое было содержательным и полезным и в результате улучшило книгу. Кроме того, благодарю тех людей, которые ответили на мои прямые запросы на рецензию. Спасибо всем: Адриану Саттону, Энтони Уильямсу, Ави Кесснер, Басу Водде, Бенджамину Мускалла, Биллу Уэйку, Брэду Эпплтону, Си Кейту Рэйю, Си Джею Джеймсону, Кристиану Дювану, Дэйвиду Пулу, Диане Ларсен, Диего Фонтдевиле, Эмили Бач, Эрику Петерсону, «Эвану M.», Францу Амадору, Джорджу Динвидди, Гойко Аджичу, Джейсону Йипу, Джеффу Григгу, Джеффу Паттону, Джеффри Палермо, Йохану Алуддену, Кену Пью, Кришне Кумару, Лиз Кеог, Луизе Нуньес, Марсело Лопесу, Маркусу Гертнеру, Мартину Фаулеру, Михалу Свободе, Николасу Паесу, Полу Стивенсону, Петеру Гравесу, Реувену Ягелю, Рикардо Майерхоферу, Рону Джеффрису, Рону Квартелу, Саре Хоран Ван Треесе, Стиву Бементу, Томасу Джей Оуэнсу, Тодду Литтлу и Уорду Каннингему. Особая благодарность тем рецензентам, которые пошли еще дальше, прочитав и прокомментировав почти каждую из частей книги: Басу Водде, Биллу Уэйку, Кену Пью, Мартину Фаулеру и Томасу Джей Оуэнсу. Процесс открытого рецензирования пошел на пользу и первому изданию, и все его преимущества, в свою очередь, отразились и на этой книге. Спасибо Адриану Ховарду, Адриану Саттону, Энн Баркомб, Энди Лестеру, Энтони Уильямсу, Басу Водде, Биллу Капуто, Бобу Коррику, Брэду Эпплтону, Крису Уилеру, Кларку Чингу, Дади Ингольфссону, Диане Ларсен, Эрику Петерсену, Джорджу Динвидди, Илье Прейсу, Джейсону Йипу, Джеффу Олферту, Джеффри Палермо, Джонатану Кларке, Кейт Рэй, Кевину Рутерфорду, Ким Грэсман, Лизе Криспин, Марку Уайтэ, Николасу Эвансу, Филиппе Антрасу, Рэнди Коулмэн, Роберту Шмитту, Рону Джеффрису, Шейну Доуну, Тиму Хоутону и Тони Бирну за их множественные комментарии и Брайану Марику, Кену Пью и Марку Стрейбеку за их замечания по готовому черновику. И наконец, еще раз спасибо моей жене Ниру. В этот раз ты знала, на что шла, и все же без колебаний поддерживала меня. Без тебя я бы не смог это сделать.

ОТ ИЗДАТЕЛЬСТВА Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение! На сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

I УЛУЧШАЯ ГИБКОСТЬ

ГЛАВА 1

Что есть Agile

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

ПРОИСХОЖДЕНИЕ AGILE В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и называлось: «Кризис программного обеспечения». Проекты разработки выходили за рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто цитируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть их была полностью отменена [Standish1994]. Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом. Чтобы взять под контроль разработку ПО, большие организации придумали ­высокодетализированный процесс, точно определявший, как ПО должно создаваться. Все жестко контролировалось, чтобы исключить возможность ошибки. (Во всяком случае, в теории.) Сначала бизнес-аналитики должны были опрашивать стейкхолдеров (stakeholders, заинтересованные стороны) и документировать системные требования. Далее архитекторы программного обеспечения должны были изучить документы с требованиями и создать подробную проектную документацию, определяющую каждый компонент системы и их взаимосвязь друг с другом. Затем программисты должны были конвертировать проектную документацию в код. В некоторых организациях такое выполнение механического перевода считалось низкоквалифицированной работой. Тем временем руководители тестирования должны были создавать планы тестирования, используя те же документы, и когда кодирование завершалось, бесчисленные специалисты по обеспечению качества должны были вручную выполнять эти планы, фиксируя отклонения как дефекты. По завершении каждой фазы все должно было быть задокументировано, проверено и подписано.

Глава 1.  Что есть Agile  35

Подход, основанный на фазах, получил название водопадной (waterfall develop­ ment) или каскадной разработки (phase-gate development)1. Если вам это кажется похожим на нелепое пугало — считайте, что вам повезло. Не все команды применяли в 1990-х перегруженный документацией каскадный процесс, но он широко признавался как логичный и разумный метод работы. Конечно, нужно было определить требования, разработать проект, затем выполнить реализацию и следом — тестирование. Конечно, нужно было документировать каждую фазу. Это была дисциплина. Это была инженерия. Как еще можно было добиться успеха?

РОЖДЕННЫЙ ИЗ КРИЗИСА Крупные компании расписывали свои процессы в мельчайших деталях. Роли, ответственности, шаблоны документов, языки моделирования, советы по контролю за изменениями… каждый аспект разработки строго регламентировался и контролировался. Если проект заканчивался провалом (а согласно CHAOS Report, менее одной шестой доли проектов были успешны), причиной считалась недостаточная детализация процесса: нужно больше документов, больше согласований. Это порождало огромное количество документации. Мартин Фаулер описывал это в своей статье The Almighty Thud [Fowler1997]. Этот стиль работы был далеко не лучшим. Он был бюрократическим и бесчеловечным. Казалось, знания и навыки не так важны, как соблюдение процессов. Программисты чувствовали себя легко заменимыми винтиками бездушной машины. И даже она работала не очень хорошо. И тогда несколько человек создали более простые, изящные и менее директивные методы разработки программного обеспечения. Они назывались легковесными в отличие от тяжеловесных, использовавшихся большими компаниями. Эти методы носили такие названия, как адаптивная разработка программного обеспечения (Adaptive Software Development), Crystal, разработка на основе функциональности (FeatureDriven Development, FDD), метод разработки динамических систем (Dynamic Systems Development Method, DSDM), экстремальное программирование (ХР) и Scrum. К концу 1990-х эти методы стали привлекать серьезное внимание. Экстремальное программирование, в частности, вызвало вспышку массового интереса среди программистов. В 2001 году 17 сторонников легковесной методологии встретились на горнолыжном курорте в штате Юта, чтобы обсудить объединение усилий.

МАНИФЕСТ AGILE «Лично я не ожидал, что эта конкретная группа [людей] сможет договориться о чемлибо по существу», — позже говорил Алистер Кокберн. И действительно, за два дня они смогли договориться только о двух вещах: названии Agile и заявлении о четырех ценностях новой методологии (рис. 1.1). В течение Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса, написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для описания того, что люди уже давно делали [Bossavit2013, chapt. 7].

1

36  Часть I.  Улучшая гибкость следующих нескольких месяцев, переписываясь по электронной почте, эти люди сформулировали 12 сопутствующих принципов (рис. 1.2) [Beck2001].

Рис. 1.1. Ценности Agile

Рис. 1.2. Принципы Agile

Глава 1.  Что есть Agile  37

Это стало Манифестом Agile, который изменил мир. «Таким образом, — продолжил Алистер, — они в конце концов все же смогли договориться о чем-то по существу»1. Однако единого метода Agile не было. Его никогда не было и никогда не будет. Agile Если ваши команды воплощают подразумевает три составляющие: название, философию Agile, то вы — Agile. Если не воплощают — то нет. ценности и принципы. И все. Это не что-то, что можно делать. Это философия. Это способ мышления, посвященный разработке программного обеспечения. Невозможно «использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть. Если ваши команды воплощают философию Agile, то вы — Agile. Если не воплощают — то нет.

СУТЬ AGILE Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании в тщательно продуманные, беспристрастно точные объяснения. Его определение «Суть разработки программного обеспечения по Agile» — одно из лучших: Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы2. Мартин Фаулер

Адаптивность вместо предиктивности Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в области программного обеспечения успешна? В отчете успешность определена очень специфическим образом: zz

успешный — проект выполнен вовремя и в рамках бюджета, все характеристики и функциональности соответствуют изначально запланированным;

zz

сомнительный — проект завершен, результаты переданы в эксплуатацию, но количество характеристик и функциональностей меньше, чем было заявлено изначально. Запланированные бюджет и сроки проекта превышены;

zz

неуспешный — проект отменен в какой-либо момент в течение цикла разработки.

1

Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожидал… что эта конкретная группа приверженцев различных гибких методик сможет договориться о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Манифеста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой. Таким образом, мы все же смогли договориться о чем-то по существу».

2

Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно найти в статье [Fowler2000].

38  Часть I.  Улучшая гибкость Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они все говорят о соответствии запланированному. Если вы сделали то, что собирались сделать, то вы успешны. А если нет, то неуспешны! Все просто. На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]: Как обнаружилось, проекты, отвечающие всем традиционным критериям успешности — время, бюджет и технические спецификации, — могут по завершении все же быть провальными, поскольку оказываются неактуальными для пользователей, которым предназначались, или потому, что в итоге не приносят особых выгод бизнесу… С другой стороны, проекты, считающиеся не­успешными согласно традиционным метрикам информационных технологий, могут оказаться успешными, поскольку, несмотря на проблемы с бюджетом, графиком или техническими характеристиками, получившаяся система нравится конечным пользователям или имеет какую-либо непредвиденную ценность.

Команды Agile определяют успех как поКоманды Agile определяют успех ставку ценности, а не соответствие плану. как поставку ценности, а не Фактически команды, действительно достигсоответствие плану. нувшие Agile, активно ищут возможности повысить ценность продукта, изменив планы. Взгляните еще раз на Манифест (см. рис. 1.1 и 1.2). Найдите пару минут, чтобы вдумчиво изучить ценности и принципы Agile. Сколько из них относятся к поставкам ценного программного обеспечения и адаптации к полученной обратной связи?

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

Глава 1.  Что есть Agile  39

Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы имеют отношение к концепции «люди на первом месте»?

ПОЧЕМУ AGILE ПОБЕДИЛ В течение первых десяти лет после появления Манифеста Agile столкнулся с небывалой критикой. Его называли «недисциплинированным». Говорили, что он никогда не будет работать. Следующие десять лет критики молчали. Agile был уже везде, по крайней мере это название. Тяжеловесные водопадные методы практически умерли. Молодые программисты вообще не верили в то, что кто-то когда-то мог работать таким образом. Не то чтобы основанные на фазах процессы неполноценны по сути. У них, безус­ ловно, есть свои недостатки, но если ограничивать их объем, при этом действуя в хорошо изученной предметной области, то методы водопадного стиля тоже могут работать. Проблема была в самом тяжеловесном процессе, который применяли крупные компании. Словно по иронии судьбы, процессы, предназначенные для того, чтобы избегать проблем, на самом деле сами вызывали большинство проблем, с которыми сталкивались компании. Трудно представить, как будет работать Получение информации и реакция программа, до того, как вы начнете ее исна изменения лежат в основе всего пользовать на практике, и еще тяжелее протого, что называется Agile. думать абсолютно все, что она должна будет делать. И это вдвойне сложнее для людей, которые не вовлечены в разработку программного обеспечения. В результате критически важно как можно скорее предоставить людям работающую программу. Вам просто необходимо получить от них обратную связь о том, что не работает и чего не хватает, и затем скорректировать ваши планы в зависимости от полученной информации. Как говорится в Манифесте, «работающее программное обеспечение — основной показатель прогресса». Получение информации и реакция на изменения лежат в основе всего того, что называется Agile. В случае тяжеловесных процессов придавалось настолько большое значение контролю над процессами и согласованию документации, что порождались значительные задержки и расходы. На то, чтобы получить работающее ПО, уходили годы, и заказчику не показывали ничего конкретного почти до самого конца проекта. Вместо того чтобы приветствовать изменения, в этих процессах делалось все, чтобы их избежать. Была даже отдельная составная часть процессов «Совет по контролю за изменениями» (Change Control Board), чьей основной задачей было сказать «нет» запросам на изменения. (Точнее, «да, но за это понадобится доплатить».) Все это наслаивалось друг на друга в проектах, где люди годами вели разработку, прежде чем могли что-то показать клиенту. И когда они это делали, было уже слишком поздно и дорого что-то менять. В конечном итоге они выдавали программное обеспечение, которое не делало то, чего хотел заказчик.

40  Часть I.  Улучшая гибкость

Типичный провал тяжеловесного процесса Третьего февраля 2005 года Роберт С. Мюллер III, директор Федерального бюро расследований, предстал перед подкомитетом Сената США, чтобы объяснить, как ФБР умудрилось потратить впустую 104,5 миллиона долларов1. Это явно было не комфортно для компании. В июне 2001-го ФБР запустило проект VCF с целью заменить программное обеспечение для управления делами. Через четыре года он был отменен. Общие затраты составили 170 миллионов долларов; 104,5 миллиона из них были полностью невозвратными. Сроки и последовательность событий проекта могут рассказать нам хорошо знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноябре 2002-го, были определены «четкие требования». Программное обеспечение было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило некоторое количество недостатков в VCF, которые делали его непригодным для использования». Подрядчик, разрабатывавший программу, согласился исправить недостатки, но только за дополнительную плату в размере 56 миллионов долларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять недочеты, фактически перечеркнув годы работы.

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

ПОЧЕМУ AGILE РАБОТАЕТ Первым прорывным успехом Agile стало экстремальное программирование, метод со слоганом «Примите изменения». В нем смешались здоровая доза философских размышлений о разработке программ и прагматичное стремление изменить ситуацию Источники: Mueller’s February 3, 2005, testimony to Congress (https://oreil.ly/GlQSa) и Inspector General Glenn Fine’s May 2, 2005, testimony to Congress (https://oig.justice.gov/node/672).

1

Глава 1.  Что есть Agile  41

к лучшему. В предисловии к первой книге по экстремальному программированию было сказано: «Если коротко, то экстремальное программирование обещает снизить риски проекта, улучшить отклик на потребности бизнеса и повысить продуктивность в течение всего срока жизни системы, сделать приятным создание ПО в команде — и все это одновременно. Это правда. Прекратите смеяться» [Beck2000a]. Extreme Programming Explained, первое издание

Одни действительно смеялись. А другие попробовали и обнаружили, что (вопреки всеобщему мнению о том, как должна вестись разработка ПО) экстремальное программирование реально выполняло все, что обещало. Так, несмотря на смех, оно пользовалось спросом, а вместе с ним Agile. Экстремальное программирование было живым примером Agile, заложившим основу идей и терминологии, которые используются до сих пор. Однако сила сообщества Agile в том, что оно всегда было широкой коалицией. Agile не ограничивается каким-то одним методом. Он постоянно расширяется, включая в себя новых людей и свежие идеи. «Бережливая разработка программного обеспечения» (Lean software development), Scrum, Kanban, «Бережливый стартап» (Lean Startup), DevOps и многие-многие другие подходы внесли свой вклад в то, что сейчас известно под общим названием Agile. Если взять все эти идеи и сгруппировать по категориям, то получится пять центральных концепций. zz

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

zz

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

zz

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

zz

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

zz

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

42  Часть I.  Улучшая гибкость Agile определяется Манифестом, но сам Манифест — лишь начальная точка. Agile работает потому, что люди заставляют его работать. Они берут идеи Agile, адаптируют их к своим ситуациям и не перестают совершенствоваться.

Agile работает потому, что люди заставляют его работать.

ПОЧЕМУ AGILE ТЕРПИТ НЕУДАЧУ Agile начинался как общественное движение. Первоначально он был успешным в значительной степени благодаря программистам, стремящимся к лучшим результатам и лучшему качеству жизни. По мере роста этого успеха акцент сместился с основополагающих идей в сторону ажиотажа. Вместо того чтобы сказать: «Давайте добьемся лучших результатов, адаптируя наши планы и ставя интересы людей превыше всего», — лидеры компаний стали говорить: «Все обсуждают Agile. Дайте мне этот Agile». Дело в том, что нет такого Agile, который можно было бы где-то взять. Это просто набор идей. Существуют специфические подходы Agile, такие как экстремальное программирование и Scrum, которые могут вам объяснить, как быть Agile, но вам все же придется принять лежащую в его основе философию. А для многих организаций эта основополагающая философия (адаптировать планы и ставить интересы людей превыше всего) на самом деле реально чуждая.

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

Впервые я прочел эту историю в трудах Ричарда Фейнмана, где в числе прочего была представлена его речь на церемонии вручения дипломов в Калтехе в 1974 году [Feynman1974]. История основана на реальных ритуалах, практиковавшихся в  Меланезии после Второй мировой войны.

1

Глава 1.  Что есть Agile  43

Трагедия карго-культа — в его приверженности к поверхностным, внешним проявлениям какой-либо идеи в сочетании с полным непониманием того, как эта идея работает на самом деле. В той истории островитяне воссоздали все элементы по отдельности: взлетно-посадочную полосу, башню, наушники, — но не знали обо всей инфраструктуре, благодаря которой прибывали самолеты. Такая же трагедия случается с Agile. Люди хотят Agile-карго: лучшие результаты, больше наглядности происходящего процесса, меньше неудач бизнеса. Но они не понимают лежащую в основе всего этого философию и зачастую не согласились бы с ней, даже если бы поняли. Они хотят купить Agile, но идею нельзя купить. Что можно купить, так это внешние символы Agile. Стендап-митинги! Истории! Инструменты! Сертификации! Есть множество вещей с маркировкой Agile и достаточно людей, жаждущих вам их продать. Их часто продают как элементы «корпоративного уровня», что является способом сказать: «Не беспокойтесь, вам не придется ничего менять». Неудобные идеи, вроде «адаптивного планирования» или «ориентированности на людей», игнорируются. Так и получается карго-культ. Много действий, ноль результата. Относящаяся к Agile составляющая отсутствует. «В моей предыдущей компании огромное количество человеко-часов тратилось на совещания». «Из-за этого [Agile] целая команда (30+ человек) лишилась работы, поскольку они не произвели почти ничего в результате почти года работы». «Все это [Agile] означает, что разработчиков просто обманули, когда проект изменился... за день до поставки». Реальные комментарии об Agile из сети

Слово Agile — повсюду. Идеи Agile — нет. Это вечный самообман для многих: единственный Agile, который они знают, — это каргокульт Agile. Настало время это исправить. В этой книге я расскажу вам, как применять идеи Agile по-настоящему. Будьте начеку, чтобы не поддаться поборникам карго-культа Agile, которых вы встретите в книге. Они покажут вам, как делать не надо. Готовы? Поехали.

ГЛАВА 2

Как быть Agile

Как перейти от нагромождения Agile-идей к реальным, действующим Agileкомандам? Нужна практика. Очень много практики.

ПРАКТИКА AGILE У каждой команды есть свой подход к работе — процессы, или методы, которым она следует, зачастую формально не задокументированы. Эти методы отра­ жают лежащую в их основе философию разработки программного обеспечения, хотя она не всегда бывает четко сформулирована и не обязательно последовательна. Чтобы быть Agile, вам нужно изменить Чтобы быть Agile, вам нужно свои методы так, чтобы они стали отражать изменить свои методы так, чтобы они философию Agile. Это одновременно и простали отражать философию Agile. ще, и сложнее, чем кажется. Это просто, поскольку в большинстве случаев вы можете начать с одного из готовых Agile-методов, например, представленного в этой книге. И это сложно, так как вам понадобится перестроить свой стиль работы, а это подразумевает изменение многих привычек. Сообщество Agile называет эти привычки практиками. Им посвящена значительная часть данной книги. Под практиками подразумеваются сессии планирования, автоматизированные сборки и демо для стейкхолдеров. Большинство этих практик существует десятилетиями. В методах Agile они скомбинированы уникальным образом — выделяются компоненты, поддерживающие философию Agile, отбрасываются остальные и добавляется ряд новых идей. В результате получается экономичный, эффективный, взаимоусиливающий комплект. Практики Agile часто имеют двойное и тройное назначение, решая одновременно множество проблем и поддерживая друг друга разумными и неожиданными способами. Вам не удастся по-настоящему понять, как работает метод Agile, до тех пор, пока вы некоторое время не понаблюдаете за ним в действии. Таким образом, несмотря на соблазн сразу настроить метод Agile под себя, лучше все же начать со стандартного, «книжного» подхода. Идея удалить наименее знакомые

Глава 2.  Как быть Agile  45

практики выглядит заманчиво, но именно они и будут вам нужны больше всего, если вы действительно собираетесь перейти на Agile. Именно с этими практиками связаны главные изменения в философии.

КАК ДОСТИЧЬ МАСТЕРСТВА Овладение искусством разработки по Agile требует реального опыта использования конкретного, четко определенного метода Agile. Начните со стандартного, «книжного» подхода. Примените его на практике — полностью — и потратьте несколько месяцев, совершенствуя практику и досконально разбираясь, почему она работает. Потом настройте под себя. Выберите один из нюансов, разберитесь с последовавшими переменами и повторите. Данная книга посвящена этой цели. В ней представлен тщательно подготовленный набор практик Agile, проверенных в реальном мире. Чтобы совершенствоваться в искусстве Agile или просто достичь бо́льшего успеха с помощью практик Agile, выполняйте следующие шаги. 1. Выберите для освоения подгруппу идей Agile. Глава 3 поможет вам определиться. 2. Применяйте как можно больше соответствующих практик. Они описаны в частях II–IV. Практики Agile усиливают друг друга, поэтому работают наилучшим образом, если использовать их все вместе. 3. Применяйте практики строго и последовательно. Если практика не работает, то попробуйте следовать методу еще точнее. Команды-новички в Agile часто недостаточно тщательно следуют практикам. Будьте готовы к тому, что вам потребуются два-три месяца на то, чтобы почувствовать себя комфортно, работая с новыми практиками, и еще от двух до шести месяцев на то, чтобы довести их использование до автоматизма. 4. По мере того как вы почувствуете уверенность в том, что применяете практики правильно (повторимся, отведите на это несколько месяцев), начните экспериментировать, внося изменения. Описание каждой из практик в этой книге дополнено рассуждениями о том, почему она работает и что в ней можно изменить. Каждый раз, меняя что-либо, наблюдайте за результатами и затем вносите дальнейшие улучшения. 5. Последнего шага нет. Разработка программного обеспечения по Agile — это непрерывный процесс обучения и совершенствования. Не прекращайте практиковаться, экспериментировать и развиваться. На рис. 2.1 показан этот процесс. Сначала следуйте правилам, потом нарушайте их и в конце концов будьте выше правил1. 1

Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари (Shu-Ha-Ri).

46  Часть I.  Улучшая гибкость

Рис. 2.1. Как достичь мастерства

С ЧЕГО НАЧАТЬ? Ваши первые шаги зависят от того, чего вы хотите. Вы присоединяетесь к действующей команде Agile, внедряете Agile в работу одной или нескольких команд или стремитесь улучшить свою команду Agile?

Присоединение к действующей команде Agile Если вы планируете присоединиться к действующей Agile-команде или просто хотите дополнить свои знания о том, как Agile работает на практике, то можете перейти к частям II–IV. Каждая часть начинается с истории в стиле «один день из жизни», описывающей, как может выглядеть Agile. Команды, работающие по Agile, отличаются друг от друга, поэтому и ваша не будет абсолютно такой же. Но эти истории дадут вам представление, чего можно ожидать. Прочитав истории, переходите к интересующим вас практикам. Каждая написана как отдельный справочный материал.

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

Глава 2.  Как быть Agile  47

Сначала убедитесь, что Agile подходит вашей компании: zz

выберите подход Agile, который ваша организация сможет поддерживать (см. главу 3);

zz

определите, что ей нужно сделать, чтобы успешно внедрить Agile (см. главу 4);

zz

получите согласие на эксперимент с Agile (см. главу 5);

zz

если у вас несколько команд, то решите, как вы будете их масштабировать (см. главу 6). За несколько недель до начала:

zz

определитесь, кто будет коучем (или коучами) команды, и выберите по меньшей мере одного человека, который будет продакт-менеджером (см. раздел «Вся коман­да» главы 7);

zz

организуйте встречу продакт-менеджера с исполнительным спонсором команды и ключевыми стейкхолдерами, чтобы разработать замысел проекта (см. раздел «Цель» главы 7);

zz

обеспечьте команде физическое или виртуальное помещение (см. раздел «Командная комната» главы 7);

zz

запланируйте и проведите сессию подготовки устава команды (см. врезку «Планирование сессии подготовки устава» в главе 7);

zz

попросите команду ознакомиться с новым методом. Раздайте людям копии этой книги, чтобы они могли ее изучить самостоятельно, предложите применить некоторые практики в их текущей работе и рассмотрите возможность проведения тренинга по тем практикам, которые вызывают трудности (практики представлены в частях II–IV). Когда команда будет готова начать, сделайте глубокий вдох и:

zz

поручите членам команды спланировать первую рабочую неделю (см. подраздел «Ваша первая неделя» главы 9).

Совершенствование действующих Agile-команд Если у вас уже есть действующие Agile-команды и вы хотите улучшить их работу, то ваш подход будет зависеть от того, какие именно улучшения вам нужны. Если вы заинтересованы в небольшой регулировке уже работающих процессов вашей команды, то перейдите к частям II–IV и прочитайте об интересующих вас практиках. Если вы хотите более масштабных улучшений, то процесс будет таким же, как и при внедрении Agile в команду, за исключением того, что вам понадобится сосредочиться на конкретных элементах, требующих изменений. В качестве руководства используйте чек-листы из предыдущего подраздела «Внедрение Agile» данной главы. Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Руководство по устранению неполадок» в главе 4.

48  Часть I.  Улучшая гибкость

Применение отдельных практик Agile Agile работает наилучшим образом, когда вы идете ва-банк, но если это не ваш вариант, то вы можете добавить немного Agile в действующие процессы. Вот подходящие практики, c которых можно начать. zz Ежедневное планирование. Если вы боретесь с частыми прерываниями (inter­ ruptions), то попробуйте использовать однодневные итерации (см. раздел «Планирование задач» главы 9). Возьмите за основу игру в планирование (см. раздел «Игра в планирование» главы 8) и измеряемый потенциал (capacity) по работе вашей команды на спринте (см. раздел «Потенциал» главы 9) и проводите совместные сессии планирования в начале каждого дня, откладывая все прерывания на сессию планирования следующего дня. Обеспечьте условия, чтобы люди сами оценивали свои задачи. zz Итерации. Если частые прерывания для вас не проблема, но вы все же хотели бы улучшить свое планирование, то попробуйте использовать недельные итерации (см. раздел «Планирование задач» главы 9). В этом случае вы также можете практиковать ежедневные рабочие стендап-митинги (см. раздел «Стендап-митинги» главы 9) и регулярные демо для стейкхолдеров (см. раздел «Демо для стейкхолдеров» главы 10). Со временем рассмотрите возможность использования индексных карточек для планирования и больших диаграмм, показывающих предстоящую работу, как описано в разделе «Визуальное планирование» главы 8. zz Ретроспективы. Частое проведение ретроспектив (см. раздел «Ретроспективы» главы 11) — отличный способ адаптировать и улучшить рабочие процессы команды. Могут быть полезны и другие практики, перечисленные в главе 11. zz Быстрая обратная связь. Быстрая автоматизированная сборка значительно улучшит вашу жизнь, а также откроет возможности для других усовершенствований (см. раздел «Нулевое трение» главы 13). zz Непрерывная интеграция. Непрерывная интеграция (практика, а не инструмент) не только уменьшает проблемы интеграции, но и способствует повышению качества сборок и тестов. Более подробную информацию см. в разделе «Непрерывная интеграция» главы 13. zz Разработка через тестирование. Хотя эту практику не так легко принять, как другие, она весьма эффективна. Разработка через тестирование (см. соответствующий раздел главы 13) позволяет снизить частоту появления программных ошибок (багов), повысить скорость разработки, улучшить вашу способность к переработке кода (рефакторингу) и сократить технический долг. На ее освоение может уйти некоторое время, так что запаситесь терпением. Другие практики, описанные в частях II–IV, также могут оказаться полезными. Agile-практики объединены множеством зависимостей друг от друга, поэтому обязательно обратите внимание на блоки «См. также» и подраздел «Предварительные требования» каждой практики. Не расстраивайтесь, если возникнут проблемы с применением отдельных практик. Быстрее и проще выбрать соответствующую группу практик и применить ее полностью, от начала и до конца. Это мы и рассмотрим далее.

ГЛАВА 3

Выберите свою гибкость

Нет смысла использовать Agile ради него самого. Задайте себе два вопроса. 1. Поможет ли нам Agile стать более успешными? 2. Чего нам будет стоить достижение этого успеха? Ответив на эти вопросы, вы поймете, нужен ли вам Agile.

Что ценно для организаций? Успех определяется не только доходами. Вот только несколько составляющих успеха: zz zz zz zz zz zz

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

МОДЕЛЬ AGILE FLUENCY В 2014 году я сотрудничал с Дианой Ларсен, чтобы проанализировать, почему компании видят разные результаты от их Agile-команд. Мы оба работали с командами с самого начала. С годами мы заметили, что команды начинали склоняться к кардинально разным типам результатов и эти результаты имели тенденцию группироваться в разных «зонах».

50  Часть I.  Улучшая гибкость Мы обобщили эти наблюдения в модели Agile Fluency™. Ее упрощенный вариант показан на рис. 3.1 [Shore2018b].

Рис. 3.1. Упрощенная модель Agile Fluency™

Каждый уровень связан с набором преимуществ. Чтобы обрести их, команде необходимо свободно (уверенно) владеть навыками, относящимися к этому уровню. Считается, что команда свободно владеет навыками, если способна применять все навыки этого уровня, не прикладывая сознательных усилий. ПРИМЕЧАНИЕ Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к другому, в реальности все более беспорядочно. Команды могут достигать уверенного владения навыками на любом уровне, в любом порядке, хотя продвижение, показанное на рис. 3.1, типично.

Навыки, необходимые для свободного применения, перечислены в предисловиях к частям II–IV. Но уверенное владение навыками не достигается само по себе. Ваша организация тоже должна инвестировать в эти навыки своих команд. Это гораздо больше, чем поддерживать идеи Agile на словах. Организация должна произвести реальные, значительные изменения, которые занимают время, стоят денег и требуют вложения политического капитала. Результат, который вы получаете от команд, зависит от того, насколько ваша организация вкладывается в идеи Agile. Компании не удается добиться результатов, которых она хочет от Agile, обычно потому, что она не сделала необходимые инвестиции. Часто организации даже не осознают, что это было нужно.

Глава 3.  Выберите свою гибкость  51

Инвестирование в Agile должно стать осознанным Инвестирование выбором. Тщательно изучите каждый из уровней. Кажв Agile должно стать дый требует затрат, и каждый имеет свои преимущества. осознанным выбором. Выберите те уровни, которые имеют наилучшее соотношение затрат и выгоды для вашей ситуации. Вероятнее всего, вам не удастся убедить вашу компанию инвестировать в каждый уровень. Это нормально. В отличие от моделей зрелости (maturity models), таких как интегрированная модель зрелости возможностей компании при разработке ПО (Capability Maturity Model Integration, CMMI), модель Agile Fluency™ не показывает продвижения от слабых навыков к сильным. Вместо этого она демонстрирует множество вариантов соотношения инвестиций/выгоды. Хотя диаграмма показывает наиболее распространенный вариант продвижения, каждый уровень можно выбрать независимо. Каждый имеет ценность сам по себе.

Уровень владения навыками и степени зрелости Свободное владение навыками — это свойство, присущее команде, а не одному индивидууму. Свободное владение навыками не означает, что каждый член команды обладает каждым навыком, связанным с данным уровнем. Вместо этого им нужна способность, будучи командой, привлекать к работе правильных людей в правильное время. Каждый уровень имеет несколько степеней зрелости. 1. Обучение — команда изучает нужные навыки. 2. Профессионализм — команда может продемонстрировать нужные навыки, когда она концентрируется на них. 3. Свободное владение — команда демонстрирует нужные навыки автоматически, не прикладывая осознанных усилий, при условии, что в команде есть коуч. 4. Самостоятельное свободное владение — команда демонстрирует нужные навыки автоматически, не нуждаясь в присутствии в команде коуча.

Уровень фокусировки (Focusing) Уровень фокусировки — это самые основы Agile: сфокусированность на бизнесрезультатах; командная работа; принятие на себя ответственности. Команды, которые свободно владеют навыками на этом уровне, фокусируют процесс разработки на основной цели команды, сначала выпускают наиболее ценные функциональности и меняют направление в ответ на меняющиеся потребности бизнеса. Они постоянно фокусируются на наиболее значимых приоритетах своей организации. В большинстве команд и организаций для этого требуется изменить образ мышления о командах. Организации, находящиеся в состоянии «до Agile», составляют планы заранее, запрашивают смету у команды и требуют отчетов о соответствии хода работ этой смете. Команды зоны фокусировки часто корректируют свои планы (по меньшей мере ежемесячно) и демонстрируют прогресс, показывая выполненную работу.

52  Часть I.  Улучшая гибкость Организации в состоянии «до Agile» разбивают свои планы на задачи, назначают членов команды ответственными за них и оценивают людей, основываясь на том, насколько хорошо те выполняют свои задачи. Команды уровня фокусировки самостоя­ тельно делают разбивку задач, сами решают, кто над чем будет работать, и ожидают, что их будут оценивать по их способности создавать ценный продукт как команда. Чтобы команды вашей организации достигали успеха, понадобится поддерживать перемены конкретными инвестициями в форме изменения командной структуры, системы управления и рабочей среды. (Я подробно расскажу об этом в следующей главе.) Это ситуация в стиле «хорошие новости и плохие новости»: плохие новости в том, что когда доходит до дела, у многих организаций пропадает желание инвестировать. А хорошие новости таковы: если они отказываются, то вы понимаете сразу, на начальном этапе, что на самом деле они не готовы к погружению в философию Agile. Вы просто избавили себя от долгих лет разочарований и душевной боли, которые пришлось бы испытать, следуя за карго-культом Agile. Если же вам удастся получить поддержку, то владение навыками на уровне фокусировки может быть достигнуто каждой командой примерно за 2–6 месяцев целенаправленных усилий. При должной поддержке они превзойдут свой предыдущий уровень производительности даже в течение 1–4 месяцев1. В части II приведены практики, которые могут им понадобиться.

Уровень поставки (Delivering) Agile-команды могут менять свои планы в любое время. Для большинства команд это несколько снижает качество их кода. Они постепенно теряют свою способность вносить изменения, эффективные с точки зрения затрат. В итоге команды могут сказать, что нужно выбросить ПО и переписать его заново, а это дорогое и невыгодное решение. Команды уровня поставки предотвращают эту проблему через свое техническое превосходство. Они сразу закладывают в дизайн своих программ готовность к частым изменениям. Команды поддерживают высокое качество кода, поэтому не тратят время на поиски багов. Они совершенствуют цикл своего производства так, чтобы релизы ПО становились безболезненными, а эксплуатация — управляемой. Они способны поставить надежное программное обеспечение с низким уровнем дефектов в любой момент, когда это наиболее целесообразно для бизнеса. Достижение таких результатов требует существенных инвестиций в навыки членов команды по разработке, а также структурных изменений, которые позволят интегрировать людей, компетентных в тестировании и эксплуатации, в каждую команду. Если ваша компания сделает эти инвестиции, то на достижение владения навыками на уровне поставки у ваших команд уйдет от 3 до 24 месяцев, и повышение производительности вы сможете увидеть в течение 2–6 месяцев. Точное количество времени, которое понадобится каждой команде, зависит от текущего качества ее кода и от того, сколько у нее будет коучей. Часть III содержит нужные практики. Временные рамки, приведенные в этой главе, приблизительны и основаны на моем опыте. Ваш опыт может быть другим.

1

Глава 3.  Выберите свою гибкость  53

Уровень оптимизации (Optimizing) Большинство компаний были бы довольны лишь уровнями фокусировки и поставки. Но Agile способен на большее. Agile во всем своем великолепии — это мир, в котором команды рады изменениям рыночных условий. Они экспериментируют и учатся, развивают новые рынки, обыгрывают конкурентов. Команды уровня оптимизации достигают этой степени гибкости. Они понимают, чего хочет рынок, каковы требования бизнеса и как можно соединить одно с другим. Или, как в обстановке стартапа, они понимают, чему им надо научиться и как к этому приступить. Они постоянно оптимизируют свои планы создания продукта, чтобы те достигли максимально возможного уровня. Здесь необходимы изменения в организационной структуре. Создание оптимальных планов требует постоянного внимания людей, обладающих глубокими знаниями в области бизнеса и продуктов, и, следовательно, эксперты по рынку и по продукту должны постоянно взаимодействовать с командой разработки. Это также означает, что на эти команды будет возложена полная ответственность за их планы создания продукта и бюджеты. Такие структурные изменения требуют одобрения на высоком уровне, которое может быть трудно получить. Команды обычно тратят по меньшей мере год на укрепление доверия с помощью уверенного владения навыками на уровне поставки, прежде чем получают разрешение на такие инвестиции. Как только это происходит, свободное владение навыками в оптимизации занимает следующие 3–9 месяцев, хотя увидеть некоторые улучшения можно уже в течение 1–3 месяцев. Но даже в этом случае оптимизация остается бесконечным процессом экспериментирования, обучения и открытий. В части IV мы поговорим о том, как начать.

Уровень укрепления (Strengthening) Есть еще один последний уровень в модели Agile Fluency™. Он во многом теоретичен: это возможное будущее Agile. Кроме того, он подходит только для организаций, находящихся на переднем крае теории и практики управления. Это обстоя­ тельство выводит данный уровень за рамки темы этой книги. Вкратце, уровень укрепления предполагает переработку коллективных идей команд и направление их в организационные улучшения. Если вы хотите узнать об этом больше, то прочтите главу 19.

Уровни свободного владения навыками Agile, резюме Фокусировка zz zz zz

Основные преимущества: фокус на бизнес-приоритеты, наглядность работы команды, способность менять направление. Инвестиции: структура команд, управление, рабочая среда. Примерные сроки: падение производительности на 1–4 месяца, достижение владения наыками в течение 2–6 месяцев.

54  Часть I.  Улучшая гибкость

Поставка zz zz zz

Основные преимущества: мало дефектов и высокая производительность, техническая долговечность. Инвестиции: навыки разработки, слияние тестирования и эксплуатации. Примерные сроки: падение производительности на 2–6 месяцев, достижение владения навыками в течение 3–24 месяцев.

Оптимизация zz zz zz

Основные преимущества: повышение уровня ценности релизов и улучшенные продуктовые решения. Инвестиции: встроенное управление продуктом, команда несет ответственность за бюджет и планы. Примерные сроки: падение производительности на 1–3 месяца, достижение владения навыками в течение 3–9 месяцев.

ВЫБЕРИТЕ СВОИ УРОВНИ К каким уровням свободного владения навыками должна стремиться ваша команда? Это зависит от того, на каких из них вас может поддержать ваша организация. В идеале все вместе: фокусировка, поставка и оптимизация — наилучший вариант. Комбинация трех уровней обеспечивает наилучшие результаты и чистейшую реализацию идей Agile. Но выбор всех трех уровней одновременно требует и максимальных инвестиций. Если вы не можете обосновать их, то у вас наверняка будут сложности с получением необходимой поддержки. А при недостаточных инвестициях вашим командам будет тяжело достичь уверенного владения навыками. Вы понесете расходы на обучение и не получите преимуществ. Вы даже можете увидеть худшие результаты по сравнению с тем, что есть сейчас. Другими словами, выбирайте те уровни, которые нужны вашей компании и за которые она хочет платить. Какие же уровни вам все-таки выбрать? zz Каждая команда нуждается в свободном владении навыками на уровне фокусировки. Это базовое свойство. Если ваша компания не может инвестировать по меньшей мере в навыки в фокусировке, то, вероятно, Agile вам не подходит, хотя, возможно, у вас получится постепенно продвигаться в этом направлении, если вы начнете со свободного владения навыками на уровне поставки. zz Свободное владение навыками на уровне поставки снижает затраты и повышает скорость разработки. Без нее ваш код в конечном итоге скатится к техническому долгу. Это делает уровень поставки очевидной целью для большинства команд. Тем не менее многие организации не готовы к большим инвестициям в обучение и качество кода, требующимся для уровня поставки. Тогда имеет смысл начать со свободного владения навыками на уровне фокусировки, продемонстрировать

Глава 3.  Выберите свою гибкость  55

успех и использовать его как положительный пример для обоснования дальнейших инвестиций. zz Свободное владение навыками на уровне оптимизации — это то, где Agile проявляет себя наиболее ярко. Но хотеть этого сразу, возможно, чересчур. Для большинства организаций лучше сначала выстроить доверительные отношения, продемонстрировав навыки на уровнях фокусировки и поставки, а затем постепенно брать на себя больше ответственности. Но если в вашей организации уже принято делегировать полномочия по принятию решений кросс-функциональным командам, как это часто бывает в стартапах, то благодаря свободному владению навыками на уровне оптимизации вы получите великолепные результаты. Больше информации о каждом уровне и его преимуществах вы можете найти в предисловиях к частям II–IV. Подробная информация о необходимых инвестициях представлена во врезке «Список необходимых инвестиций» в главе 4. Если вы не можете определиться, какой из уровней выбрать, то начните с фокусировки и поставки. Какие бы уровни вы ни выбрали, инвестируйте в изучение всех относящихся к ним практик одновременно. Практики из более поздних уровней улучшают работу более ранних, поэтому вам лучше осваивать их все вместе, а не по отдельности. Но если вы не можете инвестировать в каждый из желаемых уровней, то это нормально. Процесс будет длиться дольше, но со временем вы сможете добраться и до других уровней. Определившись с желаемыми уровнями, переходите к более подробному рассмотрению инвестиций, требуемых от вашей организации. Мы будем изучать их в следующей главе.

ГЛАВА 4

Инвестируйте в гибкость

Как мы видим из предыдущей главы, для того чтобы команды получили все преимущества Agile, ваша организация должна приобщиться к его основополагающей философии. Не просто тратить деньги (это сравнительно легко), а выполнять реальные, осмысленные изменения в организационных структурах, системах и рабочих привычках... Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели эти инвестиции действительно настолько важны? Да, действительно настолько. Инвестировать в Agile важно, поскольку По большей части команды вы инвестируете в изменение границ, косдерживают не процессы, которым торые вас сдерживают. По большей части они следуют, а ограничения, команды сдерживают не процессы, которым в которых они находятся. они следуют, а ограничения, в которых они находятся. Попробуйте делать эти инвестиции и не следовать практикам, и ваши команды, вероятно, все же покажут улучшение результатов. А если, наоборот, следовать практикам и игнорировать инвестиции? Тогда командам придется тяжело. Как сказал Мартин Фаулер1, «я вижу поразительную параллель между ДХХ (Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель экстремального программирования). Любой из них, получив в подарок ограниченный мир, посмотрит на его ограничения, которые мы принимаем как должное, сочтет их несущественными и создаст новый мир без них… они просто подложат под них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они могут создавать такие вещи, как экстремальное программирование и Rails, которые встряхивают всю индустрию». Делайте инвестиции — в них секрет успеха Agile. В следующих разделах рассказывается об инвестициях, которые нужны вашим командам от вашей организации. Возможно, вы не сможете получить их все, поэтому я предлагаю вам альтернативы. При этом альтернативы возможны ценой снижения эффективности, поэтому лучше приложите все усилия, чтобы добиться как можно больше инвестиций. Я включил в список только те, которые важны. 1

Отрывок из статьи Мартина Фаулера Enterprise Rails (http://martinfowler.com/bliki/Enter­ priseRails.html).

Глава 4.  Инвестируйте в гибкость  57

Список необходимых инвестиций Все команды Agile zz zz

zz

zz

zz

zz zz

zz zz

Получите поддержку руководства, команд и ключевых стейкхолдеров, как описано в главе 5. Создайте долговечные кросс-функциональные команды и все время назначайте людей только в эти команды (см. раздел «Выберите или создайте Agile-команды» текущей главы). Предоставьте каждой команде коуча, который поможет ей научиться быть эффективной слаженной командой (см. раздел «Выберите Agile-коучей» текущей главы). Поручайте работу командам, а не отдельным людям. Ожидайте от команд самостоятельного выбора подхода к ежедневному планированию и распределению задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы). Направьте усилия руководителей командного уровня на управление общей системой работы вместо управления отдельными людьми и задачами (см. раздел «Измените стиль управления командой» текущей главы). Организуйте физические или виртуальные рабочие помещения для каждой команды (см. раздел «Организуйте рабочие помещения» текущей главы). Для получения первого опыта работы в Agile выберите командам значимую, но несрочную задачу (см. раздел «Выберите команде подходящую для обуче­ ния задачу» текущей главы). Замените водопадные политики управления на политики управления Agile (см. раздел «Смените водопадные подходы в управлении» текущей главы). Удалите, пересмотрите или научитесь обходить политики отдела кадров, препятствующие эффективной командной работе (см. раздел « Измените вредные кадровые политики» текущей главы).

Команды фокусировки zz zz

zz

zz zz

Рассчитывайте на 1–4 месяца пониженной производительности каждой коман­ ды (см. раздел «Найдите время на обучение» текущей главы). Включите в команду людей, имеющих навыки в сфере деятельности пользователей и заказчиков (см. раздел «Выберите или создайте Agile-команды» текущей главы). Убедитесь, что в каждой команде есть тот, кто принимает решение, над чем команда будет работать, или команда имеет к нему свободный доступ (см. раздел «Выберите или создайте Agile-команды» текущей главы). Предоставьте каждой команде коуча, который сможет научить ее практикам фокусировки (см. раздел «Выберите Agile-коучей» текущей главы). Обеспечьте каждой команде доступ к стейкхолдерам или их представителям (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

Команды поставки zz

Рассчитывайте на 2–6 месяцев пониженной производительности каждой коман­ ды (см. раздел «Найдите время на обучение» текущей главы).

58  Часть I.  Улучшая гибкость

zz

zz zz

zz

zz

Объедините в каждой команде все нужные навыки разработки, такие как тестирование и эксплуатация (см. раздел «Выберите или создайте Agile-команды» текущей главы). Предоставьте каждой команде коуча, который сможет научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы). Доверьте каждой команде контроль над ее процессами разработки, сборки, тестирования и релиза (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы). Для получения первого опыта работы в Agile выберите задачу, предполагающую написание кода с нуля (green-field codebase), если коуч не сочтет, что в этом нет необходимости (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы). Разберитесь с вопросами безопасности, которые мешают коллективной разработке (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

Команды оптимизации Рассчитывайте на 1–3 месяца пониженной производительности каждой коман­ ды (см. раздел «Найдите время на обучение» текущей главы). zz Включите в команду экспертов в области бизнеса, рынка и продукта (см. раздел «Выберите или создайте Agile-команды» текущей главы). zz Предоставьте каждой команде коуча, который сможет научить ее практикам оптимизации (см. раздел «Выберите Agile-коучей» текущей главы). zz Передайте каждой команде ответственность за ее бюджет, планы и результаты (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы). zz

НАЙДИТЕ ВРЕМЯ НА ОБУЧЕНИЕ Изменения даются непросто, и нужно время, чтобы научиться чему-то новому. Освоение Agile поначалу замедлит работу ваших команд. Насколько они замедлятся? Объективных критериев продуктивности в разработке программного обеспечения нет [Fowler2003], но, исходя из моего опыта, я бы предположил снижение на 10–20 % на первых порах. По мере освоения знаний и навыков Agile производительность команд будет расти. Она будет увеличиваться, пока команды не достигнут уверенного владения навыками, и тогда рост постепенно начнет выравниваться (рис. 4.1). Это называется J-кривой, и она характерна для всех значительных изменений. В главе 5 мы более подробно рассмотрим эти изменения. Временны́ е затраты обычно окупаются уже в первый год. Длительность изначального спада зависит от уровней свободного владения навыками, которые осваивает каждая команда, как объяснялось в предыдущей главе. Напомню: zz фокусировка — 1–4 месяца; zz поставка — 2–6 месяцев; zz оптимизация — 1–3 месяца.

Глава 4.  Инвестируйте в гибкость  59

Рис. 4.1. Изменение производительности в Agile с течением времени

Эти периоды пересекаются, поэтому команда, обучающаяся навыкам фокусировки и поставки одновременно, будет менее продуктивна в течение 2–6 месяцев. Для сравнения: команда, которая сначала изучает фокусировку и позже переходит к обучению поставке, продемонстрирует два спада: 1–4 месяца — при обучении фокусировке и затем 2–6 месяцев — при обучении поставке. Производительность команд Agile меняется и с других сторон. Команды Agile фокусируются на том, чтобы полностью завершить разработку одной функциональности, прежде чем переходить к следующей. Это особенно верно в отношении команд поставки, которые предпочитают создавать качественный продукт с самого начала, а не исправлять баги в конце. Это улучшает продуктивность и производительность, но (как ни странно) выглядит как замедление работы для людей, которые привыкли видеть одновременно несколько функциональностей в разработке. В результате стейкхолдеры могут быть разочарованы темпом Agile-разработки, особенно в течение первого года, когда им приходится справляться сразу с тремя ударами: с реальными задержками из-за обучения команд, с ощущением задержки, вызванной необходимостью последовательно фокусироваться на завершении задач, и с затратами на завершение работ, которые велись до эксперимента с Agile и были объявлены «выполненными», на самом деле не являясь таковыми. Это может приводить к тому, что команды будут отвлекаться от изучения Agile и фокусироваться только на поставке программного обеспечения, не закончив обуче­ ние. Такая ситуация контрпродуктивна для всех: команды будут измучены и расстроены, а организация потеряет свои инвестиции. Перед тем как команды начнут внедрять Agile, убедитесь, что руководители и все стейкхолдеры отдают себе отчет в том, что в первый год производительность снизится. У вашей организации есть возможность купить время за деньги, наняв людей, которые помогут командам. Это не устранит полностью спад производительности, но сделает его менее значительным. Варианты такой помощи весьма разнообразны: периодическое наставничество, тренинги, помощь в разработке и имплементации

60  Часть I.  Улучшая гибкость процессов, каждодневный коучинг. Эффективнее всего нанять опытных специалистов-практиков, которые будут на постоянной основе тренировать каждую команду. Решая, кого нанять, лучше игнорируйте бесчисленные схемы сертификации Agile. Многие из них — пустая трата денег. Большинство просто в течение нескольких дней переливают из пустого в порожнее, читая лекции «капитана Очевидность». Другие если даже и считаются отличными обучающими программами, то лишь благодаря конкретному преподавателю, а не самой сертификации. Поэтому оценивайте курсы независимо от сертификации, которую они рекламируют. Это относится и к найму консультантов и коучей. Попросите свою сеть контактов предоставить рекомендации, просмотрите общедоступные материалы, изучите отзывы. Начав применять практики из этой книги, вы, вероятно, столкнетесь со специфическими проблемами и задачами. Найдите наставника, к которому сможете обратиться с вопросами. Эта услуга не обязательно должна быть платной: уважаемый коллега из компании, проходившей через подобное, местное сообщество пользователей, интернет-форум — все это будет подходящими вариантами.

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

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

ОТБЕРИТЕ ИЛИ СОЗДАЙТЕ AGILE-КОМАНДЫ Невозможно преувеличить важность команды в Agile-организации. Большинство организаций рассматривают людей как основной производственный ресурс. В Agile ресурсом являются команды. Вашей организации нужно инвестировать в команды, которые будут: zz кросс-функциональными — члены команды в совокупности обладают всеми знаниями, которые нужны ей для достижения цели; zz полностью вовлеченными — внешние специалисты могут время от времени приходить в команду, чтобы помочь, но основные члены команды должны посвящать все свое время только своей команде;

Глава 4.  Инвестируйте в гибкость  61

сплоченными — отношения между членами команды дружеские, конструктивные, позволяющие сотрудничать; zz долгосрочными — у команд могут уходить месяцы на то, чтобы понять, как наиболее эффективно работать вместе, поэтому сохраняйте состав команд как можно дольше. Размер и состав каждой команды зависят от того, какие уровни свободного владения навыками вы выбрали. В разделе «Вся команда» главы 7 представлены все подробности. Краткое описание команд выглядит следующим образом. zz Команды фокусировки концентрируются на достижении бизнес-результатов. Им нужны люди, способные поставить себя на место пользователей и заказчиков, чтобы точно понять, что должно делать программное обеспечение. Если команда работает над задачей, ориентированной на пользователя, необходимы специалисты, имеющие навыки UI/UX (UI — User Interface — «пользовательский интерфейс», UX — User Experience — «опыт пользователя»). Команды также должны иметь способ определять, чем заниматься дальше. Лучше всего, если в команде есть люди с навыками и полномочиями, позволяющими делать это самостоятельно, однако члены команды могут работать и с кем-то извне. zz Команды поставки берут на себя ответственность за полный цикл поставки своего программного обеспечения. Им требуются все навыки, необходимые для сборки и развертывания программного продукта. Команда поставки должна брать на себя те виды ответственности, которые раньше передавались другим командам. Сюда входят управление сборкой, архитектура и администрирование данных, тестирование и эксплуатация. zz Команды оптимизации ответственны за успех своего продукта в бизнесе в широком смысле. Они также берут на себя ответственность за координацию со стейкхолдерами и принимают решения о продуктовых приоритетах. Им нужны эксперты в сфере бизнеса, рынка и продукта. Возможно, у вас уже есть команды, которые отвечают всем требованиям. Если вы собираете новые Agile-команды, то можете выполнить шаги, описанные ниже. В любом случае вам понадобится вовлечь команду в процесс, как описано в разделе «Заинтересуйте команду» главы 5. 1. Определите цель каждой команды (см. раздел «Цель» главы 7). 2. Решите, сколько человек будет в каждой команде, основываясь на значимости цели команды и в зависимости от ограничений, описанных в разделе «Вся команда» главы 7. 3. Определите, какие навыки нужны в каждой команде. 4. Выберите людей с соответствующими навыками, которые наверняка смогут сотрудничать и хотят попробовать работу в Agile. Если вы создаете или реорганизуете множество команд, то позвольте командам провести самостоятельный отбор. Этот способ удивительно эффективен в создании высокопродуктивных команд, которые будут в восторге от совместной работы. В книге Creating Great Teams: How Self-Selection Lets People Excel [Mamoli2015] рассказывается, как это работает. zz

62  Часть I.  Улучшая гибкость

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

Если члены команды не ладят друг с другом… Для новой команды нормально проходить через трудный период, когда люди учатся работать друг с другом, поэтому не волнуйтесь, если первое время в команде происходит борьба. Коуч и менеджер команды могут помочь в урегулировании конфликтов. В разделе «Динамики команды» главы 11 эта тема разбирается более подробно.

Если вы не можете создать долгосрочную команду… Разбивать отлично работающую команду — расточительно, но это не помешает вашим командам быть Agile.

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

Если вы не можете получить необходимые вам навыки разработчиков… Скорее всего, вы не сможете достичь навыков в поставке, но практики поставки вам все же стоит изучать и использовать в работе.

Глава 4.  Инвестируйте в гибкость  63

ВЫБЕРИТЕ AGILE-КОУЧЕЙ Каждой команде нужен коуч, который поможет ей научиться быть эффективной Agile-командой. В подразделе «Навыки коучинга» главы 7 содержатся подробности. Краткое описание коуча представлено ниже. zz Каждой команде необходим тот, кто может помочь ей научиться быть эффективной и сплоченной. zz Командам фокусировки нужен тот, кто может научить практикам планирования, описанным в части II. zz Командам поставки нужен тот, кто может научить техническим практикам, изложенным в части III. zz Командам оптимизации нужен тот, кто сможет научить практикам развития бизнеса, описанным в части IV. Некоторые коучи могут охватить сразу несколько категорий. Каждый коуч может работать с одной или двумя командами.

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

ДЕЛЕГИРУЙТЕ ПОЛНОМОЧИЯ И ОТВЕТСТВЕННОСТЬ КОМАНДЕ Уважение к человеческим способностям лежит в центре философии Agile, и нигде это не очевидно настолько, как в подходе Agile к полномочиям и ответственности.

Уважение к человеческим способностям лежит в центре философии Agile.

Секрет первоклассного выполнения работы заключается в правильном понимании деталей, а никто не понимает их лучше, чем непосредственные исполнители этой работы… Имея необходимую квалификацию и направляемые лидером, они будут принимать наилучшие технические решения и воплощать их лучше, чем кто-либо другой смог бы сделать за них [Poppendieck2003]. Мэри и Toм Поппендик

zz

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

64  Часть I.  Улучшая гибкость

zz

zz

zz

zz

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

Если работу нужно поручить отдельным людям… Если вашу организацию не устраивает то, что команды самостоятельно принимают решения по распределению своих задач, значит, в ней дефицит доверия, а доверие — требование Agile. Вы могли бы попытаться убедить людей изменить их мнение, попробовав командную работу с пилотной Agile-командой, но делайте это осторожно. Стиль управления «командуй и контролируй» обычно несовместим с Agile. Если эта проблема не слишком широко распространена и дело лишь в нескольких менеджерах, которые не могут отпустить ситуацию, то прочитайте раздел «Измените стиль управления командой» текущей главы.

Если корпоративные инструменты не поддерживают командную работу… Если в вашей компании используется система распределения задач, которую невозможно заменить, то одним из вариантов краткосрочного решения проблемы может стать создание для каждой команды «фантомного» человека, чтобы он принимал командные задачи. Другой вариант — члены команды могут рассматривать получаемые индивидуальные задания как командные. В долгосрочной перспективе лучше все же исправить корпоративную программу.

Глава 4.  Инвестируйте в гибкость  65

Если команды должны использовать корпоративный инструмент отслеживания… Одна из главных причин эффективности Agile-команд — способность улучшать и упорядочивать свои рабочие процессы. Корпоративные системы отслеживания, включая так называемые инструменты управления жизненным циклом Agile (Agile Lifecycle Management), ограничивают возможности команд. Как и множество продуктов, борющихся за место в вагоне локомотива Agile, эти инструменты имеют тенденцию настолько упускать смысл самого подхода, что начинают снижать гибкость команд. Принуждение Agile-команд к использованию корпоративных инструментов отПринуждение Agile-команд слеживания в их повседневной деятельнок использованию корпоративных инструментов отслеживания в их сти снижает их производительность. Если повседневной деятельности снижает у вас нет выбора в этом вопросе, то можно их производительность. применять две отдельные системы отслеживания: одну для легковесного подхода Agile и основную корпоративную систему. Более подробная информация доступна в подразделе «Корпоративные системы отслеживания» главы 10.

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

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

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

66  Часть I.  Улучшая гибкость

ИЗМЕНИТЕ СТИЛЬ УПРАВЛЕНИЯ КОМАНДОЙ Когда команды сами определяют свои процессы, назначают себе задачи и координируют работу со стейкхолдерами, менеджеры командного уровня могут подумать, что им нет места в Agile. Но это далеко не так. Работа руководителя группы в Agile различается, но она не менее важна, чем в команде периода «до Agile». Больше информации об этом можно найти в разделе «Менеджмент» главы 10. Поговорите с менеджерами об их новой роли и предложите им тренинг, если необходимо. Убедитесь, что их ожидания тоже соответственно изменились.

Если менеджеры не могут отпустить ситуацию… Микроменеджмент раздражает, но в краткосрочной перспективе он не будет камнем преткновения. Однако он препятствует обучению, отбирая у команд возможность самостоятельно принимать решения. Микроменеджеры удлиняют сроки и повышают затраты, необходимые для достижения уровня свободного владения навыками1. Руководители часто занимаются микроменеджментом, когда не знают, чем еще им заниматься, или когда боятся, что им не найдется места в среде Agile. Заверьте их, что у них есть роль, показав, как она выглядит. Тренинг или хороший Agile-коуч могут в этом помочь.

ОРГАНИЗУЙТЕ РАБОЧИЕ ПОМЕЩЕНИЯ Команды Agile активно сотрудничают и постоянно общаются друг с другом. Чтобы это общение было эффективным, потребуется помещение, приспособленное под потребности команды. Оно может быть как физическим, так и виртуальным. В разделе «Командная комната» главы 7 содержится более подробная информация. Для команд, работающих в режиме личного общения, организация физического помещения может стать вашей самой дорогостоящей инвестицией. Вдобавок она является и наиболее ценной. Как обсуждается в разделе «Командная комната» главы 7, физические командные комнаты играют роль мультипликаторов производительности. Однако, когда ваша команда только наКоманды-новички в Agile обычно чинает работу, вы можете не знать, какого недооценивают то, насколько им рода помещение ей нужно и даже прижипонравится совместная работа. вется ли вообще Agile на долгий срок. Ваши команды, вероятно, тоже этого не знают. Команды-новички в Agile обычно недооценивают то, насколько им понравится совместная работа, и переоценивают свою тягу к приватности. Спасибо Джорджу Динвидди за это замечание.

1

Глава 4.  Инвестируйте в гибкость  67

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

Если команда удаленная… Вы можете создать виртуальную командную комнату. В подразделе «Виртуальные командные помещения» главы 7 рассказывается, как это сделать.

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

ВЫБЕРИТЕ КОМАНДЕ ПОДХОДЯЩУЮ ДЛЯ ОБУЧЕНИЯ ЗАДАЧУ У любой команды есть цель: ее место в общей стратегии организации. (См. раздел «Цель» главы 7.) Когда команда только начинает учиться Agile, важно выбрать цель, которая поможет в учебе. В практическом смысле это означает три вещи. zz

Цель, имеющая ценность, но не срочная. Если команда будет сильно ограничена во времени, то ей будет трудно учиться. Члены команды по умолчанию вернутся к тому, что у них хорошо получалось в прошлом, чем будут тратить время на воплощение новых идей.

zz

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

zz

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

68  Часть I.  Улучшая гибкость

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

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

СМЕНИТЕ ВОДОПАДНЫЕ ПОДХОДЫ В УПРАВЛЕНИИ Руководство (Governance) — это процесс Чтобы Agile заработал, необходимо того, как работа согласовывается, отслежиизменить водопадные политики вается и управляется на высоком уровне. руководства. В большинстве организаций политики такого руководства предполагают водопадный подход в разработке. Часто это требует подготовки предварительной документации или четких переходов от фазы к фазе (phase gates). Все это означает предиктивный подход к планированию. Для достижения лучших результатов нужно изменить политики руководства так, чтобы они стали соответствовать подходу Agile. Это значит удалить точки фазовых переходов и использовать адаптивный подход к планированию. Подробная информация доступна в подразделе «Agile-руководство» главы 10.

Если требуется водопадная модель управления… Это расточительно и лишит команды части их гибкости, но при необходимости вы можете соблюдать водопадные политики руководства. Это возможно для нескольких пилотных команд, но будет лучше переключиться на Agile-руководство, прежде чем распространять Agile дальше. Чаще всего руководство требует составления четких предварительных планов и бюджета. Простейший способ удовлетворить это требование — использовать сначала любой доступный вам подход, а затем, после того как вы пройдете через согласование проекта, начать Agile-часть процесса. В качестве альтернативы для команд, свободно владеющих навыками на уровне как фокусировки, так и поставки, вы можете заложить 4–8 недель на планирование, начать нормально работать и создать качественную дорожную карту (Roadmap). (См. раздел «Дорожные карты» главы 10.)

Глава 4.  Инвестируйте в гибкость  69

Как добиться успеха, используя водопадную модель Agile подходит далеко не для каждой компании. И это нормально! Можно добиться успеха, используя водопадную модель. Если вы в компании, которой нужны предварительные планы или культура которой — «командуй и контролируй», то водопадная модель может быть более уместной. Наиболее безопасно использовать итеративный водопад. Вместо того чтобы реализовывать один большой водопадный проект, что довольно рискованно, начните серию небольших водопадных проектов. Каждый должен длиться не больше 3–6 месяцев и завершаться работающим программным обеспечением, действительно пригодным для выхода на рынок. Каждый проект должен содержать стандартные фазы водопада: анализ требований, архитектура и дизайн, реализация, тестирование — или тот вариант фаз, который предпочитает ваша компания. Водопадная модель работает наилучшим образом в хорошо изученных предметных областях при наличии небольшой неопределенности. Постарайтесь взять на работу людей, весьма опытных в создании именно того типа программного обеспечения, который вы собираетесь реализовывать.

Другую предварительную документацию, такую как анализ требований или проектная документция, также можно подготовить с помощью действующих подходов до начала выполнения Agile-части вашей работы. Оставшуюся часть работы, которую необходимо выполнять для того, чтобы ваш рабочий процесс соответствовал водопадному подходу, можно распределить параллельно Agile-работе вместе с пользовательскими историями (см. раздел «Истории» главы 8), как и любые другие запросы. Водопадный стиль управления несовместим со свободным владением навыками на уровне оптимизации, который основан на адаптивном планировании. Если от вас требуется соответствие водопадным политикам управления, ограничьтесь уровнями фокусировки и поставки.

ИЗМЕНИТЕ ВРЕДНЫЕ HR-ПОЛИТИКИ Agile — это командный спорт, и несмотря на то, что на словах командная работа поддерживается, многие компании имеют политики, непреднамеренно сдерживающие ее. Любая политика, поощряющая людей конкурировать друг с другом, затруднит работу по Agile. Особенно деструктивный пример — таблицы ранжирования, где члены команды оцениваются методом сравнения друг с другом. Люди, оказывающиеся на верхушке таблицы, получают повышение, а тех, кто «на дне», увольняют независимо от их реальной производительности. Похожий случай — руководители, которые ценят только материальный результат. В Agile-команде есть много способов внести свой вклад в успех. Примером может служить человек, который непосредственно не пишет код, но проводит много времени, воспроизводя баги, или человек, который работает «за сценой» над улучшением коммуникации.

70  Часть I.  Улучшая гибкость Во многих организациях также развита культура вины, при которой на ошибки реагируют путем наказания виновных. В мировоззрении Agile, напротив, ошибки рассматриваются как возможность обучения. Например, не-Agile-организация может уволить программиста за непреднамеренное удаление критически важной оперативной базы данных. Agile-организация вместо этого спросит: «Какие методы сдержек и противовесов мы можем внедрить, чтобы предотвратить случайное удаление баз данных, и как мы можем упростить восстановление после подобных ошибок?» Такие особенности корпоративной культуры часто отражены в HR-политиках (Human Resources, HR) в части продвижения и поощрения. Если карьера людей зависит от внешней причины, независимо от их реального влияния на производительность команды, то у ваших команд, вероятно, будут трудности в совместной работе по Agile. Вам не удастся изменить культуру вашей организации за одну ночь, но вы можете начать работать над изменением HR-политик, а руководители могут изменить способ своего обращения с командами. Это занимает много времени, так что начните как можно раньше. Вам наверняка понадобится поддержка высшего руководства. Часто лучше найти креативные способы применения существующих политик, чем отменить все политики сразу, что вдобавок может оказаться значительно сложнее. Кроме того, помните, что иногда руководство может применять какие-то практики по собственному усмотрению, поэтому если вы слышите, что что-либо «невозможно сделать», то это может быть из-за менеджера, которого вы уговариваете, а не из-за отдела кадров.

Если HR-политики не подлежат изменению… Если изменить плохие HR-политики невозможно, то руководителям придется ограждать от них свои команды. Сделайте так, чтобы они и освоили Agile, и могли хорошо ориентироваться в корпоративной бюрократии. Если у вас много команд, то ограничьте пилотный Agile командами, имеющими опытных руководителей. Используйте их опыт, чтобы запустить необходимые вам изменения политик.

РЕШИТЕ ПРОБЛЕМЫ, СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ Эти инвестиции обычно не проблема, но если они вдруг становятся проблемой, то могут затормозить вас намертво. Так что уделите им внимание, особенно если вы работаете в индустрии, имеющей повышенную чувствительность к безопасности. Проблема в том, что работающие очно команды, которые используют такие практики, как парное программирование и групповое програмирование (мобпрограммирование) (см. соответствующие разделы главы 12), работают вместе за одним компьютером. Это может беспокоить с точки зрения безопасности, поскольку человек, который вошел в систему, не всегда тот же, кто сейчас сидит за клавиатурой. Фактически человек, который авторизовался в системе, может ненадолго отойти, чтобы поговорить с кем-то или посетить уборную. Набирая код, люди часто меняются

Глава 4.  Инвестируйте в гибкость  71

(буквально каждые несколько минут), поэтому выходить из системы каждый раз, когда вводить код должен другой человек, и затем снова входить нереально. Если ваши команды будут использовать эти практики, то привлеките людей из службы безопасности вашей компании и поработайте с ними над решением беспокоящих их вопросов. Обычно можно найти креативный способ поддерживать работу по Agile и одновременно соблюдать правила безопасности. Один общий подход — создать закрытую общую учетную запись для отдела разработки. Некоторые компании совмещают ее с отдельными рабочими станциями, выделенными специально отделу разработки, или виртуальными машинами на базе общих серверов. Использовать электронную почту и выполнять другие индивидуальные задачи можно на других ноутбуках, выданных индивидуально. С этим связана проблема возможности отслеживания. Некоторые компании требуют, чтобы каждое внесенное изменение (commit) можно было отследить до его автора. Это требование можно выполнить, добавив инициалы или адрес электронной почты в коммит-комментарий команды. У Git есть соглашение о том, чтобы добавлять строку Co-authored-by в конце каждого коммит-сообщения1. Некоторые компании требуют, чтобы весь код перед релизом просмотрел еще один человек, помимо автора. В парном и групповом программировании это требование выполняется, но, скорее всего, вам понадобится модифицировать свой инструментарий, чтобы он позволил осуществить релиз кода, минуя дополнительную фазу проверки. Если полная отмена этого требования — не подходящий вариант, то вам, возможно, понадобится модифицировать инструменты так, чтобы пропускать проверку изменений, выполненных в соавторстве.

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

Если вам требуется дополнительный этап ревью кода… Код, написанный в результате парного или группового программирования, уже может считаться прошедшим дополнительное ревью, поэтому команды могут начать не глядя штамповать отзывы об этом коде. Однако это тоже вызывает сложности, так что лучше убрать данное требование до того, как начинать широкое распространение Agile. 1

Спасибо Джею Базузи за то, что обратил мое внимание на эти соглашения о commit-сообщениях (https://oreil.ly/7vSmz).

72  Часть I.  Улучшая гибкость

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

Команда не заинтересовалась Agile (см. «Заинтересуйте команду» главы 5); или В команде нет коуча, который может научить ее практикам (см. раздел «Выберите Agile-коучей» текущей главы); или На команду слишком давят, чтобы она давала результат (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы). Внутри команды слишком много конфликтов

Команды слишком часто переформируются (см. раздел «Выберите или создайте Agile-команды» текущей главы); или Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или Менеджеру команды приходится постоянно помогать улаживать конфликты (см. раздел «Измените стиль управления командой» текущей главы); или Политики отдела кадров поощряют конкуренцию (см. раздел «Измените вредные кадровые политики» текущей главы). Члены команды не сотрудничают друг с другом

Команда не заинтересовалась Agile (см. раздел «Заинтересуйте команду» главы 5); или Члены команды не имеют возможности посвятить все свое время команде или не ладят друг с другом (см. раздел «Выберите или создайте Agileкоманды» текущей главы); или В команде нет коуча, который может научить ее сотрудничеству (см. раздел «Выберите Agile-коучей» текущей главы); или Распределение или отслеживание задач требует индивидуальной работы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или Рабочее пространство не подходит команде (см. раздел «Организуйте рабочие помещения» текущей главы); или Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или Менеджер команды раздает индивидуальные задания (см. раздел «Измените стиль управления командой» текущей главы); или HR-политики поощряют индивидуальную работу (см. раздел «Измените вредные кадровые политики» текущей главы).

Глава 4.  Инвестируйте в гибкость  73

Команда тратит слишком много времени на предварительную оценку, планирование и отслеживание работ

Команда вынуждена использовать корпоративную систему отслеживания задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или От команды требуют составления предварительных планов и детальных прогнозов (см. раздел «Смените водопадные подходы в управлении» текущей главы); или Команде нужно развивать свободное владение навыками на уровне фокусировки (см. часть II). Программное обеспечение, созданное командой, не делает то, что нужно стейкхолдерам

У команды нет доступа к нужному представителю бизнеса, или ей нужны люди с большим опытом в сфере деятельности заказчика и пользователей (см. раздел «Выберите или создайте Agile-команды» текущей главы); или В команде нет коуча, который может научить ее работе со стейкхолдерами (см. раздел «Выберите Agile-коучей» текущей главы); или У команды нет доступа к стейкхолдерам (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы). Команде тяжело привлекать внимание стейкхолдеров

Стейкхолдеры не поддержали инициативу с Agile (см. раздел «Заручитесь поддержкой стейкхолдеров» главы 5); или У команды отсутствуют необходимые навыки в сфере деятельности заказчика (см. раздел «Выберите или создайте Agile-команды» текущей главы); или Стейкхолдеры не считают работу команды актуальной или значимой (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы). Программное обеспечение, созданное командой, делает то, что хотят заказчики и пользователи, но не имеет коммерческого успеха

У команды нет доступа к нужному представителю бизнеса или опыта в бизнесе (см. раздел «Выберите или создайте Agile-команды» текущей главы); или Команде нужна более подходящая цель (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или Команде нужно развивать свободное владение навыками на уровне оптимизации (см. часть IV); или Команда свободно владеет навыками в оптимизации, но не может контролировать свои планы и расходы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

74  Часть I.  Улучшая гибкость

Программное обеспечение, разрабатываемое командой, имеет очень долгие циклы выпуска версий, много багов или эксплуатационные проблемы

В команде нет людей, уверенно владеющих навыками на уровне поставки (см. раздел «Выберите или создайте Agile-команды» текущей главы); или В команде нет коуча, который может научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы); или Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или Команда свободно владеет навыками на уровне поставки, но не может полностью контролировать свою разработку, выпуск версий и эксплуатацию (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или Команда учится работать с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы). Разработка идет медленнее, чем ожидалось

Команда завершает предыдущие задачи, которые были до Agile, или все еще учится (см. раздел «Найдите время на обучение» текущей главы); или Команде нужно больше коучинга (см. раздел «Выберите Agile-коучей» текущей главы); или Рабочее пространство не подходит командам (см. раздел «Организуйте рабочие помещения» текущей главы); или Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или Команда не может полностью контролировать свой процесс разработки (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или Команда работает с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или Команда ограничена требованиями руководства, отданными на высоком уровне (см. раздел «Смените водопадные подходы в управлении» текущей главы); или Команда ограничена требованиями безопасности (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

ГЛАВА 5

Инвестируйте в изменения

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

ОСОЗНАНИЕ ИЗМЕНЕНИЙ Изменения разрушительны, и внедрение Agile — Изменения разрушительны, не исключение. Степень разрушительности зависит и внедрение Agile — от того, скольких команд они коснулись и наскольне исключение. ко успешно вы управляете этими изменениями. Если у вас одна команда, жаждущая попробовать Agile при полной поддержке со стороны организации, то это не должно быть большой проблемой. Если вы пытаетесь изменить 50 команд в организации, не знакомой с идеями Agile… что ж, это очень большая проблема. Понять, как люди реагируют на изменения, можно с помощью модели изменений Вирджинии Сатир (рис. 5.1)1. Согласно рисунку, существует пять ступеней перемен. Они применимы к Agile следующим образом. 1. Имеющийся статус-кво. Это стиль работы, который был до Agile. Он удобен и всем хорошо знаком. Все знают, чего от них ждут и как делать свою работу. Некоторые, тем не менее, не очень довольны и считают, что Agile должен помочь. Они хотят перемен. 2. Сопротивление. Люди, желающие перемен, начинают получать поддержку, и какие-то изменения в направлении Agile становятся возможными. Это называется внешним элементом изменения. Люди начинают по-разному реагировать на возможность перемен. Многие противостоят им. Они говорят, что в Agile нет необходимости, что вряд ли его внедрение будет успешным или что это пустая трата времени. Некоторые злятся. Чем больше людей касаются изменения, тем больше сопротивления вы встречаете. 3. Хаос. Проект изменений одобрен, и команды начинают использовать практики Agile. Старые методы работы и привычные ожидания больше не действуют. У Стивена Смита есть хорошая статья об этой модели (https://oreil.ly/1KQ38), включающая советы о том, как помочь команде на каждом этапе.

1

76  Часть I.  Улучшая гибкость Люди растеряны, находятся в замешательстве, и настроения в коллективе переменчивы. В какие-то дни все хорошо, в другие — все плохо. Люди периодически демонстрируют ребяческое поведение. Производительность и моральный климат ухудшаются. 4. Интеграция. С течением временем, практикуясь, люди начинают осваивать новые методы работы. Они открывают для себя тот аспект Agile (его называют трансформирующей идеей), который особенно убедителен для них (для каждого человека он свой). Люди начинают осознавать возможности, которые дает им Agile, и прикладывают реальные усилия, чтобы Agile заработал. Ощущение хаоса снижается, моральный климат улучшается, производительность растет. 5. Новый статус-кво. Коллектив прошел через изменения. Новые методы работы по Agile уже комфортны и знакомы, и люди достаточно уверены в себе, чтобы продолжать добавлять небольшие изменения. Производительность стабилизировалась на более высоком уровне, чем была до перемен, и продолжает постепенно расти по мере того, как люди экспериментируют с внедрением небольших новшеств.

Рис. 5.1. Модель изменений Вирджинии Сатир (The Satir Change Model)

Такие реакции на изменения неизбежны. ПоПопытки ускорить процесс пытки ускорить процесс только ухудшают ситуа­ только ухудшат ситуацию. цию. Вот почему организациям следует отвести время на обучение (см. раздел «Найдите время на обучение» главы 4). Обратите внимание на параллели между моделью Сатир, представленной на рис. 5.1, и J-кривой, показанной на рис. 4.1 (см. выше). Каждый участник проходит через эти ступени в своем темпе. Длительность периода изменений и глубина хаоса зависят от того, в какой степени затронута повседневная жизнь человека. Участник, действующий на периферии процесса, реагирует легче, чем тот, кто непосредственно является частью новой Agile-команды. Индивидуальные

Глава 5.  Инвестируйте в изменения  77

особенности личности также имеют значение; одним людям нравится пробовать все новое, в то время как другие хотят стабильности и предсказуемости. Вы можете снизить (но не полностью устранить!) хаос, применив технику, которой я научился у Дианы Ларсен: поддержка, информация и структура (Support, Information, Structure — SIS)1. zz Поддержка. Помогите людям разобраться, как выполнять работу в изменившейся окружающей среде. Организуйте обучение, коучинг или найдите любые другие способы оказать помощь людям, не внушая им мысль, что их оценивают. Сделайте необходимые инвестиции, описанные в главе 4. Убедитесь, что у каждого есть кто-то, с кем он может поговорить на работе или в частной жизни, когда чувствует себя перегруженным. zz Информация. Обеспечьте прозрачность информации в отношении того, что происходит, что известно и с чем еще предстоит определиться. Не оставляйте без внимания озабоченность людей карьерными вопросами. Если вы можете сделать это честно, то дайте твердое обещание, что никто не будет уволен в результате изменений. Сообщайте даже больше, чем считаете нужным2. zz Структура. Людям нужна твердая почва под ногами, поэтому предоставьте им дорожную карту грядущих изменений. Если вы используете эту книгу в качестве основы для ваших изменений, то раздайте всем ее копии и расскажите, какие части в данный момент используете. Когда что-то неясно, объясните, что нужно сделать, чтобы внести определенность, и когда, по вашим ожиданиям, это произойдет. Если нужен промежуточный шаг, например временные команды, то дайте ясно понять, что это временно, и объясните, что будет дальше.

МАСШТАБНЫЕ ИЗМЕНЕНИЯ Изменения, затрагивающие множество людей, гораздо более разрушительны, чем те, которые касаются лишь нескольких команд. Это разрушение имеет тенденцию усиливаться. Появляются слухи, люди начинают беспокоиться о своих рабочих местах, и грядущие перемены становятся предметом ежедневного обсуждения. Большие перемены (непосредственно затрагивающие 30–70 и более человек) требуют профессионального управления изменениями. В зависимости от размеров вашей организации ваш отдел кадров может иметь в своем составе специалистов по изменениям, которые могут вам помочь. Если вы нанимаете внешних консультантов Agile на этот проект, то поинтересуйтесь их опытом и подходом в области управления изменениями. Руководители организаций часто недооценивают важность управления измене­ Не стоит недооценивать важность управления изменениями. ниями. Это большая ошибка! Используя терминологию модели Сатир, к тому времени, Спасибо Диане Ларсен за помощь в составлении этого списка.

1

Диана говорит: «Коммуницируйте, пока вас не затошнит. И даже потом продолжайте».

2

78  Часть I.  Улучшая гибкость как вся остальная организация узнает об изменениях, руководство организации уже восприняло «трансформирующую идею», которая избавила их от ощущений неприя­ тия и хаоса. Для руководства изменения уже кажутся очевидными и необходимыми. Так почему кто-то может быть не согласен? И тогда они запускают процесс изменений и сталкиваются с огромным сопротивлением и противодействием со стороны людей, которые только начали проходить сквозь собственные ступени неприятия и хаоса. И это способно загубить на корню весь проект изменений. Правильный процесс управления изменениями не может предотвратить все разрушения, но может их минимизировать. Не скупитесь. Если вы не готовы потратиться на экспертную помощь, то ограничьте масштабы вашего проекта изменений в направлении Agile всего несколькими командами за раз.

ПРОЦЕССЫ ИЗМЕНЕНИЙ Кайдзен — общий термин в сообществе Agile. Это японское слово, означающее «совершенствование». В Agile-сообществе этот термин означает непрерывное постепенное совершенствование1. Непрерывное совершенствование — неотъемлемая часть Agile, так не нужен ли кайдзен в первую очередь для того, чтобы направить ваши усилия к Agile? Парадоксально… но, наверное, нет. Кайдзен предназначен для улучшения существующих методов работы. Если в вашей компании особое значение имеют документы, то кайдзен поможет вам рационализировать документооборот. Если культура вашей организации основана на обвинениях, то кайдзен поможет вам точнее устанавливать вину. Но он не поможет вам перейти с любой культуры на Agile. Чтобы перейти с одного стиля работы на другой, вам понадобится другое японское слово — кайкаку. Оно означает «трансформационное изменение». Вместо того чтобы постепенно улучшать существующие процессы работы, как это делает кайдзен, кайкаку фундаментально меняет основополагающий подход. Все лучшие команды Agile, которые я знаю, начинали с кайкаку. Они разобрались, что им нужно от Agile, как они собираются инвестировать в достижение этого результата, и пошли ва-банк. Я вижу команды Agile, которые работают посредственно, значительно чаще, чем те, которые функционируют прекрасно. Первых объединяет то, что их компании в свое время не пошли ва-банк. Они пытались проложить свой путь к Agile через кайдзен. Поначалу кажется, что это работает, но потом все неизбежно останавливается. Люди выгорают из-за несовпадения идей Agile и ценностей компании. Они устают впитывать новые идеи. Изменения вызывают переутомление, прогресс начинает тормозиться и после многолетних усилий полностью останавливается. По иронии Термин «кайдзен» был импортирован в Agile из концепции бережливого производства (lean manufacturing), которая, в свою очередь, основывается на революционной производственной системе компании Toyota, — отсюда и японский термин. Рифмуется с английским I win — «я выигрываю».

1

Глава 5.  Инвестируйте в изменения  79

судьбы, разрушения при таком способе продвижения к Agile значительно более длительные, чем при кайкаку. Если ваша компания — новичок в идеях Agile (даже если вы уже используете это слово), то вам нужен кайкаку. Определите зоны применения, выделите необходимые средства, и пусть каждая команда начнет использовать все соответствующие практики сразу. Возможно, это звучит пугающе, однако на самом деле это быстрее и безопаснее, чем осваивать практики постепенно. Если у вас много команд, то, вероятно, безопаснее действовать постепенно, но даже тогда кайкаку — лучший вариант для вас. Вместо того чтобы в соответствии с кайдзен постепенно внедрять Agile во многих командах, примените кайкаку, чтобы полностью внедрить Agile в подгруппе команд. Если нужно двигаться еще более мелкими шагами, то начните всего с одной команды и, возможно, только с одного уровня фокусировки. Затем добавьте уровень поставки. Далее добавьте еще одну команду, возможно, вместе с уровнями фокусировки и поставки. По мере накопления опыта увеличьте размер шага изменений. Команды, уже работающие по Agile, могут использовать кайдзен для достижения лучших результатов в рамках их нынешних областей компетентности. Более подробная информация доступна в главе 11. Чтобы добавить новые области (например, если команда компетентна на уровне фокусировки и хочет стать таковой на уровнях поставки и оптимизации), лучше всего выбрать кайкаку. Новые уровни требуют новых инвестиций и серьезных изменений, и лучше делать все сразу. Успешный кайкаку требует дисциплины и заботы. Рассмотрим, с чего все начинается.

ЗАРУЧИТЕСЬ ПОДДЕРЖКОЙ РУКОВОДСТВА Agile требует поддержки руководства. Без нее несоответствие между Agile-практиками вашей команды и никак не связанной с Agile культурой вашей организации будет вызывать постоянные трения. Если вы сами руководитель, постарайтесь сделать так, чтобы ваш непосредственный руководитель был на вашей стороне, и будет совсем хорошо, если коллеги тоже вас поддержат.

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

80  Часть I.  Улучшая гибкость вашу аудиторию. Вкратце обрисуйте преимущества свободного владения навыками на каждом соответствующем уровне и поинтересуйтесь, какие уровни важны по мнению собеседников. Спросите почему. Слушайте больше, чем говорите. Прежде всего фокусируйтесь больше на том, что они могут получить и к каким потерям может привести бездействие, чем на продвижении Agile ради него самого. На самом деле, учитывая степень всеобщего недопонимания, что такое Agile, вам может быть лучше вообще не упоминать этот термин.

2. Получите одобрение экономичного покупателя Ваша конечная цель — поговорить с человеком, обладающим полномочиями распоряжаться инвестициями, которые понадобятся вашей команде. В продажах этот человек называется экономичным покупателем (economic buyer). Экономичные покупатели часто бывают окружены своего рода привратниками, работа которых — беречь время экономичного покупателя. Они предложат вам передать всю информацию им, чтобы они могли презентовать ее покупателю. Они не пытаются украсть вашу идею; они пытаются помочь экономичному покупателю сберечь его время. Иногда они пытаются убедить вас, что покупатель на самом деле — это они, даже если у них в действительности нет необходимых полномочий. Не дайте себя обмануть. Заручиться поддержкой привратников полезно и часто даже необходимо, однако этого недостаточно. Они не смогут одобрить нужные вам инвестиции. Вам нужно разговаривать с реальным экономичным покупателем. До этого разговора фокусируйте ваше общение на выгодах Agile: что на кону. Вопрос инвестиций, скорее всего, будет отвлекать или даже вызывать беспокойство, поскольку люди, с которыми вы будете разговаривать, не имеют полномочий управлять инвестициями. Когда разговор с экономичным покупателем наконец состоится, вашей целью будет получить его принципиальное согласие инвестировать в Agile. Вероятнее всего, ваше время будет ограниченным, так что удерживайте фокус на общей картине. Кроме того, часто лучше провести эту встречу в формате диалога, а не презентации со слайдами, хотя в вашей конкретной ситуации, скорее всего, ваши союзники смогут предложить вам наилучший подход. Во время встречи с экономичными покупателями говорите о том, чего они хотят от их организации и как Agile может в этом помочь. Это может сработать еще лучше, если кто-то из руководителей, кому они доверяют, будет говорить от вашего имени. Заполучив в команду союзников экономичного покупателя, начните говорить об инвестициях. Если вы предложите Не перегружайте собеседников излишними поднесколько вариантов, это робностями; кратко перечислите несколько клюпонизит шансы отказа. чевых инвестиций, необходимых каждому уровню (врезка «Список необходимых инвестиций» в главе 4 поможет вам подготовиться), а также то, как эти уровни соотносятся с пожеланиями покупателя. Спросите его, какой компромисс между размером инвестиций и выгодой он считает приемлемым. Если вы предложите несколько вариантов, а не потребуете ответа «да или нет», это понизит шансы категорического отказа.

Глава 5.  Инвестируйте в изменения  81

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

3. Сделайте официальное предложение Если вы добрались до этого этапа, то поздравляю! Вы преодолели самое важное препятствие. Сейчас вам нужно пройти через официальное предложение. Степень формальности предложения зависит от вашей организации. Ваш спонсор и ваши союзники помогут вам разобраться, как лучше оформить предложение, помогут доработать его, правильно преподнести экономичному покупателю. Действуйте оперативно, вежливо и настойчиво. В вашем предложении опишите преимущества, которые может получить ваша организация, и инвестиции, которые ей необходимо сделать. Будьте конкретны. В главе 3 описываются преимущества в целом, а в предисловиях к частям II–IV дана более подробная информация. Перенесите эти преимущества на вашу конкретную ситуацию, на инвестиции, которые экономичный покупатель готов сделать, и объясните, что в реальности это означает для вашей организации. При подготовке инвестиционного аспекта вашего предложения прочитайте главу 4 и переведите каждый шаг в конкретный запрос. В каких-то инвестициях вам, вероятно, придется пойти на компромисс. В главе объясняется, как это сделать. Но постарайтесь избежать слишком больших компромиссов. В конечном счете именно инвестиции делают возможными преимущества Agile.

Выход на экономичного покупателя Приведу пример того, как вовлеченность руководства работает в сложной ситуации; он взят из моего собственного опыта в роли консультанта. Это не было обычным проектом по переходу организации к Agile, поэтому у вас все будет иначе, но этапы обсуждения в организации наверняка будут похожими. Изначально ко мне обратился менеджер по проектированию компании, насчитывающей несколько сотен инженеров и порядка 45 команд разработчиков программного обеспечения. Этот руководитель искал кого-нибудь, кто возглавил бы маленькую команду. Мы поговорили, и я узнал, что у них были сложности с взаи­ модействием команд. Я предложил свою помощь в решении этой проблемы. Этот руководитель нашел мои идеи касательно масштабирования довольно содержательными и представил меня своему вице-президенту по проектированию.

82  Часть I.  Улучшая гибкость

Мы поговорили спустя две недели. Ему понравилось то, что я сказал, и еще через полторы недели мы обедали с его боссом — директором по продукту. Он и был экономичным покупателем. Во время того обеда директор по продукту высказал ряд опасений, касающихся его организации. Мы обсудили несколько способов, как я могу помочь, и в качестве продолжения запланировали встречу между мной и их директором по управлению продуктами, который также присутствовал на том обеде. Я встретился с директором через неделю. Он не являлся покупателем, поэтому моей целью было не убедить его, а узнать больше информации о компании. Я также хотел убедиться, что мы правильно понимаем друг друга, поскольку нам предстоя­ ло тесно сотрудничать. К счастью, мы были на одной волне, и мой собеседник запланировал еще одну встречу с участием нас двоих и директора по продукту. Эта встреча состоялась на следующей неделе. Наша предыдущая встреча за обедом была нашим шансом познакомиться друг с другом, тогда как эта встреча была моим шансом заручиться поддержкой директора по продукту. Я не пытался развернуть рекламную кампанию. Я никогда не считал полезным говорить людям, что они должны хотеть. Вместо этого я задавал вопросы. У меня была реальная цель: я хотел понять потребности директора по продукту и проинформировать его о тех моментах, которые чреваты трудностями или даже проблемами. Я спросил его, как он представляет себе успех, как он поймет, что успех достигнут, и как, по его ожиданиям, в итоге это повлияет на бизнес. К концу встречи, которая заняла час, я узнал достаточно, чтобы обрисовать примерный подход и ценовой диапазон. Я спросил, правильно ли я все понял, и мой собеседник ответил утвердительно. Мы ударили по рукам, и я обещал к концу следующего рабочего дня представить детальное предложение, что и сделал. Его рассмотрели в течение недели (директор держал меня в курсе того, что происходило в компании) и одобрили на следующей неделе, внеся небольшие поправки. Окончательное одобрение заняло еще некоторое время, которое ушло на то, чтобы пробиться сквозь корпоративную бюрократию, однако на тот момент это был уже решенный вопрос. От первой встречи до первого одобрения прошло пять встреч и семь недель. Это довольно быстрый результат для организации такого размера, но они были очень мотивированы. У них была серьезная проблема, которая блокировала прогресс, и они верили, что я могу помочь им решить ее. Вот те ингредиенты, которые понадобятся и вам: мотивирующая проблема и вера в то, что вы можете ее решить.

Если это выглядит слишком трудозатратным… Этот осторожный процесс привлечения сторонников предназначен для случаев, когда поддержка под вопросом: если вы работаете со множеством команд, запрашиваете большие инвестиции или работаете в бюрократической организации, для которой идеи Agile не комфортны (даже если люди активно используют это название). Но иногда все это не так сложно. Иногда вы просто помогаете одной маленькой команде стать более Agile. Если вы и ваш руководитель уже имеете все полномочия, чтобы выделить необходимые вам инвестиции, то просто сделайте это!

Глава 5.  Инвестируйте в изменения  83

Если руководство считает, что они уже Agile… Некоторые организации (а в наши дни таких много) думают, что они уже Agile. Одна организация говорила мне: «Мы пост-Agile!» Или вы можете услышать: «Мы agile с маленькой буквы “а”, а не Agile с большой буквы “A”!» Но сравнив философию, описанную в главе 1, с тем, как действует организация, вы поймете, что это далеко не так. Спорить о терминологии бесполезно. Если Фокусируйтесь на текущей организация хочет сказать, что она Agile, или ситуации: проблемах, пост-Agile, или экстра-супер-пупер-Agile, то преимуществах, инвестициях. пусть говорит. Вместо того чтобы спорить, фокусируйтесь на текущей ситуации: проблемах, с которыми сталкиваются ваши команды, преимуществах, которые организация может получить, и на том, какие инвестиции потребуются для этого.

Если руководство не поддерживает… Если поначалу вы не можете найти понимание и поддержку у руководства, то не отчаивайтесь. Попробуйте поставить себя на их место. Как Agile может помочь им получить то, что им нужно? Если ответ «не может», то, вероятно, он им и не нужен. Выберите другой подход к разработке программного обеспечения, такой, который лучше впишется в культуру вашей организации. Один из вариантов можно найти во врезке «Как добиться успеха, используя водопадную модель» в главе 4. Если у вас есть руководитель, которому вы доверяете, то обратитесь к нему за помощью и советом. Если его нет, то попробуйте провести информационное интервью: поговорите с руководителем из другой компании, проходившей через это недавно. (Они могут попытаться нанять вас на работу. Взаимовыгодный вариант, win/win!) Во врезке «Смените организацию» далее в этой главе рассматривается ряд идей на этот случай. На заре развития Agile, когда это было еще стихийным общественным движением, множество команд приняли экстремальное программирование самостоятельно, при слабой поддержке или согласии руководства, а то и вообще без них. Вы тоже могли бы попробовать это сделать. Но я не рекомендую. Опыт команд, которые попытались это сделать, показал, что кому-то (чаще всего руководителю проекта) в конце концов приходилось все время преодолевать разрыв между корпоративной культурой и философией Agile. Это неблагодарная работа, которая привела к выгоранию команды. Некоторые используют метод Kanban, чтобы мотивировать организационные изменения1. Kanban представляет существующие методы работы таким образом, чтобы подчеркнуть узкие места в исполняемой работе и показать стоимость задержек. Его достаточно легко внедрить, и он может мотивировать переход организации к Agile. Kanban является кайдзен-подходом к изменениям, он медленный и работает только до определенного предела, но очень эффективен и может привести к появлению разрешения на кайкаку. Более подробную информацию вы можете найти в книге [Anderson2010]. Обратите внимание, что метод Kanban — это значительно более широкое понятие, чем доска Kanban, применяемая некоторыми командами для визуализации планирования.

1

84  Часть I.  Улучшая гибкость Если ничего из того, что вы делаете, не меняет ситуацию, то задумайтесь, а что нужно вам. Представьте, что статус-кво не изменится, поскольку этого, вероятно, и не случится. И тогда или вас это устраивает, или (а часто это как раз такой случай) пришло время перейти в другую, более подходящую вам компанию.

Изменить организацию Вы можете изменить свою организацию или сменить ее. Мартин Фаулер Изменить организацию изнутри непросто, но возможно. Это отнимает много сил и времени, и не всегда оказывается, что оно того стоило. Поэтому более простой способ изменить организацию — сменив работу — может оказаться более разумным выбором. Для тех, кто все же хотел бы попытаться, ниже приведены 13 советов, почерпнутых из моего собственного опыта изменения организации изнутри. 1. Задумывайтесь о своих мотивах. Отвечает ли Agile в наивысшей степени интересам организации или он нужен вам по личным причинам? Есть ли у вас время, энергия и энтузиазм, чтобы проповедовать эти изменения? Есть ли у вас стратегия поиска выхода из проблем, которые могут возникнуть вследствие ваших усилий? Если ответ на любой из этих вопросов — «нет», то смена работы может оказаться лучшим выходом. 2. Организуйте надежную сеть поддержки. Изменения в направлении снизу вверх — неблагодарная работа, часто ведущая к разочарованию. Полагайтесь на семью и друзей, уходите домой вовремя и не живите рабочими проблемами в нерабочее время. 3. Находите для себя маленькие удовольствия. Без поддержки сверху организационные изменения в значительной мере находятся вне вашего контроля. Находите небольшие ежедневные рабочие задачи, благодаря выполнению которых вы будете чувствовать удовлетворение. 4. Не сдавайтесь. Небольшие изменения накапливаются. Поначалу эффект от ваших усилий будет незаметным, но они будут постепенно менять стиль мышления людей в сфере решения проблем. В конце концов, по достижении некоего порога все внезапно начнет меняться. 5. Уважение — ваша валюта. Чем больше люди уважают вас, тем больше ваш авторитет. Завоевывайте авторитет своими действиями и уважительно относитесь к другим, даже в мыслях. 6. Оставайтесь внутри сферы своего влияния. Изменения снизу требуют постоянного повторения. Пытайтесь вносить изменения только в тех отделах организации, с которыми вы находитесь в постоянном контакте. 7. Пополняйте ряды сторонников. Найдите хотя бы одного человека, который уважает вас и ваши идеи и имеет большее влияние, чем вы. Привлеките его к распространению ваших идей. 8. Находите пробелы. Люди должны хотеть изменений, но они будут их хотеть, только если это дает им что-то, что они не могут получить другим способом, или если это убережет их от потери чего-то ценного для них. Фокусируйтесь на этих моментах.

Глава 5.  Инвестируйте в изменения  85

9. Вникайте в причины. Всегда есть причины, почему что-то делается именно так, а не иначе, и вы можете сделать свое вмешательство более эффективным, если разберетесь, что это за причины. 10. Повторяйте. Продвигайте свою идею изменений снова и снова, разными способами и разным людям. Но старайтесь не быть назойливым. 11. Не критикуйте все подряд. Выберите что-то одно и работайте с этим. Если вы будете находить проблемы во всем, то люди просто перестанут вас слушать. 12. Не ищите признания. Если вы успешны, то люди начнут повторять ваши идеи, как если бы они были их собственными. Это не плагиат. Ваши усилия на самом деле могут изменить мышление людей, при этом они даже не будут это осознавать. Пусть они так думают. Они будут более усердно трудиться ради собственных идей. 13. Будьте осторожны в своих желаниях. Если ваш проект изменений будет успешен, то готовы ли вы взять на себя ответственность за то, что будет дальше? Если вы захотите прочесть историю изменений, вдохновившую автора на эти советы, то можете найти ее онлайн на веб-странице [Shore2006]. Подробное руководство по изменениям изнутри содержится в книге More Fearless Change: Strategies for Making Your Ideas Happen [Manns2015].

ЗАИНТЕРЕСУЙТЕ КОМАНДУ Agile ставит интересы людей на первое место, поэтому для вас не должно стать сюрпризом, что нужно получить согласие вашей будущей Agile-команды на то, чтобы попробовать новый подход. Можно заставить людей согласно кивнуть, стиснув зубы, но (и я говорю это, основываясь на моем нелегком опыте) это обычно приводит к потере кадров. Когда меня просят помочь компаниям с внедрением Agile, я всегда разговариваю с каждой командой отдельно от ее руководителей. Нужно дать членам команды возможность высказаться в комфортных для них условиях, не опасаясь возмездия. Пригласите на встречу и коуча команды, и если вы сами руководитель, то начните разговор с того, что поддержите решение команды, каким бы оно ни было. Затем дайте людям поговорить с коучем без вас. Вы или коуч можете сказать команде, что ее выбрали возможным кандидатом на тестирование Agile. Я обычно объясняю, почему руководство заинтересовано в Agile, какие выгоды он принесет организации и как это повлияет на членов команды лично. Я также объясняю, что изменение рабочих привычек — это стресс и команде следует ожидать хаоса (обычно на период до трех месяцев), пока каждый разберется, как сработаться с Agile. Еще я часто рисую набросок и поясняю модель изменений Вирджинии Сатир (см. рис. 5.1). Я говорю: «Если вы согласитесь, то я предложу вам попробовать стандартный вариант Agile в течение трех месяцев. После этого мы оценим, что работает, что нет,

86  Часть I.  Улучшая гибкость и попробуем что-то улучшить1. Спустя шесть месяцев у вас будет возможность принять решение — продолжаем мы работать с Agile или остаемся с тем, что есть сейчас». Затем я даю всем возможность задать вопросы. У команд обычно множество вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс отказаться сейчас и конкретную возможность передумать позже, вы позволяете им в безопасном режиме попробовать что-то новое. Выделите достаточно времени на то, чтобы ответить на все вопросы. Встреча обычно занимает около часа, но иногда может затянуться. Ответив на все вопросы, напомните, что не будет никаких последствий для проголосовавших против. Еще раз подчеркните это. И затем приступите к голосованию.

Если команда настроена скептически… Скептический настрой — нормальное явление, его следует ожидать. Будьте честны с вашим коллективом: изменения разрушительны, но результаты себя оправдывают. Поясните практики, которые, по вашему мнению, люди поначалу могут счесть странными или даже раздражающими, например парное программирование. Это поможет снизить градус скептицизма и в будущем облегчит процесс внедрения этих практик. Может быть полезно подчеркнуть, что это эксперимент и за командой будет последнее слово в вопросе, придерживаться Agile или нет.

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

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

1

Глава 5.  Инвестируйте в изменения  87

Если люди обманывают насчет своего согласия… Иногда люди голосуют за Agile, при этом внутренне выступая против. С этим вы ничего не можете сделать, кроме как приложить все усилия, чтобы люди не чувствовали себя принуждаемыми. Пытаться угадывать чужие мысли непродуктивно. Даже если никто не обманывает сейчас, природа изменений такова, что время от времени всех Природа изменений такова, будут посещать сомнения. Вам придется работать что время от времени всех с этими сомнениями по мере их появления. И будет будут посещать сомнения. полезно иметь возможность напомнить людям, что они согласились принять участие в эксперименте длиной в шесть месяцев, что есть точная дата его окончания и если все не заработает к этой дате, то они смогут отказаться. Отнеситесь к ним с сочувствием и уважением; изменение привычек требует времени, и люди могут чувствовать, что устои, на которые они привыкли опираться, полностью утрачены. По моему опыту, к окончанию шестимесячного периода изначальный хаос изменений будет уже в прошлом и люди будут вполне довольны своим новым стилем работы по Agile. Так было с каждой командой, с которой я работал.

ЗАРУЧИТЕСЬ ПОДДЕРЖКОЙ СТЕЙКХОЛДЕРОВ Стейкхолдерами вашей команды являются все, кого касается ваша работа или кто может влиять на нее. Применительно к вашим усилиям по Agile-улучшениям к стейкхолдерам также нужно отнести всех тех, кто влияет на эти изменения. Мы уже разбирались с вопросом поддержки со стороны членов команды и руководителя. Вам не нужно, чтобы все остальные стейкхолдеры поддерживали ваш замысел, но вам точно нужно заручиться поддержкой тех, кто имеет значительное политическое влияние. В противном случае они могут тихо саботировать ваши усилия или каким-нибудь неожиданным образом выбить почву у вас из-под ног через полгода-год, если (особенно если) внедрение Agile будет успешным1. С наибольшей вероятностью вы встретите сопротивление со стороны бизнеспартнеров вашей команды: менеджеров по продукту, маркетингу и продажам. Agile ведет к серьезным сдвигам в системе взаимодействия с этими группами. Они привыкли к прогнозируемому подходу, ориентированному на строгие обязательства и сроки. Взаимодействие этих людей с командой разработки, как правило, основано на документации, отчетах о проделанной работе и согласованиях. Команды, работающие по Agile, фокусируются на обратной связи, частой поставке ценного продукта и постоянной адаптации своих планов. Они регулярно просят у стейкхолдеров обратную связь, а затем корректируют свои планы в соответствии с полученной информацией. Так как планы Agile-команд постоянно меняются, они не берут на себя четких обязательств по срокам релизов. Некоторые команды Алистер Кокберн называет этот феномен организационными антителами. Чем более успешна инициатива по изменениям, тем больше люди беспокоятся о ее влиянии на них и тем сильнее сопротивляются изменениям.

1

88  Часть I.  Улучшая гибкость могут давать какие-то прогнозы, но они не являются обязательствами и тоже часто меняются. Одним стейкхолдерам это нравится. Наконец-то они знают, что происходит на самом деле, и имеют возможность влиять на результат. Другие же, особенно те, кто уже когда-то пострадал из-за срывов сроков или обязательств, видят в Agile политический маневр: изощренный способ не давать обещаний. Они сражаются с Agile изо всех сил. Поговорите с ключевыми стейкхолдерами вашей команды об Agile. Чаще всего это лучше делать один на один. Тема может быть политически чувствительной, поэтому спланируйте стратегию вместе с вашими союзниками в руководстве. Кроме того, возможно, будет лучше, если этот разговор проведете не вы, а руководитель или человек, которому доверяет данное заинтересованное лицо. Во время таких разговоров относитесь к вашим стейкхолдерам как к доверенным Относитесь к вашим стейкхолдерам партнерам. Вы хотите, чтобы они достигли как к доверенным партнерам. успеха. Вам необходимо соблюдать баланс Вы хотите, чтобы они достигли успеха. множества интересов, и вы обеспечиваете прозрачность и контроль, а не предсказуемость. Но помогать им — существенная часть вашей работы. Вы будете делать все от вас зависящее, чтобы облегчить их работу и привести к успеху.

Если нужны конкретные обязательства… В Agile используется адаптивное планирование, которое подразумевает динамичное изменение планов в целях достижения наилучших результатов. Вы можете установить конкретную дату и придерживаться ее, как описано в подразделе «Запланированные даты релизов» главы 10, но не сможете точно предсказать, какие функции будут готовы к этой дате. Если этого недостаточно, то можно применить подход, описанный в подразделе «Если требуется водопадная модель управления…» главы 4, то есть подготовить планы с фиксированными сроками и объемом работ. Нет гарантии, что эти планы будут правильными, но это лучшее, что вы можете предложить на данный момент. Если и этого недостаточно, то, видимо, Agile вам не подходит.

Если стейкхолдеры не спешат поддержать… Иногда у команд разработчиков складываются непростые отношения с некоторыми стейкхолдерами, особенно с продакт-менеджерами или отделом продаж. Эти отношения могут быть довольно напряженными. В некоторых случаях неприязнь и отсутствие доверия даже могут привести к тому, что эти люди будут категорически против Agile. Они могут также возражать против замедления работы, вызванного необходимостью обучения Agile в начале процесса внедрения (см. раздел «Найдите время на обучение» главы 4). Если возражают всего несколько человек, то попробуйте выбрать команды, в работе которых они не участвуют. Если среди стейкхолдеров много возражающих или

Глава 5.  Инвестируйте в изменения  89

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

ЛИТЕРАТУРА ДЛЯ ДОПОЛНИТЕЛЬНОГО ЧТЕНИЯ Книгу 7 Rules for Positive, Productive Change1 [Derby2019] должен прочитать каждый, кто занимается организационными изменениями. Если хотите понять, как повлиять на изменения в вашей организации, то начните с прекрасной книги More Fearless Change: Strategies for Making Your Ideas Happen [Manns2015].

Дерби Э. Психология управления изменениями. Семь главных правил.

1

ГЛАВА 6

Масштабирование гибкости

В идеальном мире каждая Agile-команда была бы полностью независима и единолично владела бы своим продуктом или портфелем продуктов. Но в реальном мире необходимость координации взаимодействия множества команд является источником задержек и разнообразных ошибок. Если бы каждая команда работала изолированно, то этих проблем просто не было бы. Но это совершенно нереалистично. Типичная Agile-команда состоит из 4–10 чело­ век. Как правило, этого недостаточно. Как же вам тогда расширяться? Эта книга посвящена в основном индивидуальным Agile-командам, однако этот вопрос достаточно важен, чтобы заслуживать отдельной главы.

МАСШТАБИРОВАНИЕ СВОБОДНОГО ВЛАДЕНИЯ НАВЫКАМИ Организации довольно часто пытаются масОрганизации довольно часто штабировать Agile, при этом не ставя на первое пытаются масштабировать Agile, место способность быть Agile. Они инвестипри этом не инвестируя руют много времени и денег в некое грандиозни в команды, ни в потенциал ное «фирменное блюдо» под названием Agile, самой организации. не инвестируя ни в свободное владение командами навыками, ни в потенциал самой организации. И это никогда не работает. Чтобы масштабировать Agile, вам понадобится масштабировать и способность вашей организации быть Agile. В эту задачу входят работы по трем направлениям: организацонному потенциалу, коучинговому потенциалу и потенциалу команд.

Организационный потенциал Одна из самых больших ошибок, которую совершают организации при попытке внедрить Agile, — отказ от инвестиций, описанных в главе 4. Но даже если ваша организация серьезно относится к этим инвестициям, могут обнаружиться другие скрытые проблемные места.

Глава 6.  Масштабирование гибкости  91

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

Коучинговый потенциал Вам понадобится коуч или коучи, которые помогут разобраться с общей картиной масштабирования Agile: кросс-командной координацией, потенциальными возможностями организации, управлением продуктом/портфолио и управлением изменениями. С помощью книг и тренингов вы можете сами взрастить этих коучей внутри организации, однако лучше все же нанять кого-то со стороны. Вам также понадобятся опытные коучи командного уровня, и это, вероятно, будет главным ограничением при масштабировании. Это люди, которые помогают команде достичь уровня уверенного владения навыками, и они ей жизненно необходимы. Каждой команде понадобится по меньшей мере один коуч, как обсуждается в подразделе «Навыки коучинга» главы 7. Кроме того, вы можете как нанять опытных коучей командного уровня, так и воспитать собственных внутри организации. Если вы выбираете второй вариант, то учтите, что каждому будущему коучу понадобятся обучающие ресурсы, такие как, например, эта книга. Вы можете расширяться быстрее, поощряя опытных коучей командного уровня переходить в другую команду, как только их текущая команда начнет приближаться к уровню свободного владения навыками. (Чек-листы в начале частей II–IV помогут вам оценить прогресс.) К этому моменту некоторые члены команды, возможно, уже сами будут обладать квалификацией, достаточной для того, чтобы выступать в качестве коучей командного уровня, и смогут развивать свои новые навыки в более опытных командах. Убедитесь, что такие горизонтальные перемещения улучшают карьеру ваших коучей, а не вредят ей, иначе их поток может иссякнуть1. Спасибо Эндрю Стельману за то, что в Twitter-посте указал на опасность горизонтального перемещения (https://oreil.ly/E0EaB).

1

92  Часть I.  Улучшая гибкость Навыки коучинга отличаются от навыков разработки. Даже лучшим членам вашей команды может быть трудно стать хорошими коучами. Быстрее расширить возможности коучинга командного уровня можно, наняв коучей для обучения коучей. Опытные коучи командного уровня могут работать с двумя командами одновременно, хотя это и не всегда хорошая идея для команд, добивающихся свободного владения навыками на уровне поставки. Менее опытные коучи должны быть прикреплены только к одной команде.

Потенциал команды Коучи помогут вашим командам достичь свободного владения навыками. Чем больше опыта у коучей, тем быстрее пойдут дела, но все же это займет некоторое время. В разделе «Найдите время на обучение» главы 4 представлены примерные цифры. Вы можете форсировать события, наняв крупную консалтинговую компанию, чтобы укомплектовать ваши команды опытными Agile-разработчиками в соотношении 50 % и более. Достаточно высокое соотношение позволяет достичь уровня компетентности почти мгновенно при условии, что вы уже приложили достаточно усилий для мобилизации потенциала вашей организации. Однако применяйте этот подход с осторожностью. Стратегия разумная, хотя и дорогостоящая, но ее реализация имеет тенденцию давать сбои. Люди, которыми вы дополняете ваши команды, оказывают огромное влияние на успех этого подхода, и есть вполне реальный риск нанять неправильную фирму. Все говорят, что их сотрудники имеют Agile-навыки, но даже в случае компаний с широко известными именами тут больше бравады, чем реальных возможностей. За несколькими исключениями, если добавленный персонал и имеет какие-то знания в Agile, то обычно они ограничиваются уровнем фокусировки. Еще один риск усиления штата с помощью внешнего персонала связан с навыками коучинга. Даже если добавленные сотрудники и будут иметь навыки, необходимые для мгновенного перехода на уровень свободного владения навыками (в чем далеко не всегда можно быть уверенным), маловероятно, что они также будут владеть и навыками коучинга. Изменения в направлении Agile могут не состояться, если консалтинг не даст результата. Подход с добавлением внешнего персонала может сработать, если вы наймете подходящую фирму. Выбрав этот вариант, постарайтесь воспитывать при этом собственных коучей. Не ждите, что компания, добавляющая вам персонал, сделает это за вас; тут нужен совершенно другой набор навыков. Обратитесь в небольшие фирмы и к независимым консультантам, которые специализируются на Agileтрансформациях и услугах обучения коучей. Люди, которых вы нанимаете, имеют большее значение, чем вендор, особенно в случае этих конкретных навыков, и маленькие консалтинговые компании делают эту работу лучше.

Глава 6.  Масштабирование гибкости  93

Синдром второго ребенка Я заметил удивительный тренд среди компаний, внедряющих Agile: пилотные команды часто очень успешны и вдохновляют организацию на дальнейшее распространение Agile, но вторая волна команд начинает испытывать трудности. Я называю это синдромом второго ребенка. Моя теория заключается в том, что пилотные команды получают всю необходимую поддержку: целеустремленных участников, терпеливую организацию, помощь извне и задачи, хорошо подходящие для обучения. А затем, думая, что все ее сотрудники уже хорошо знакомы с Agile, организация оказывает второй волне команд гораздо меньшую поддержку. Agile навязывается людям, которые его совсем не хотят; кроме того, руководители не предоставляют помощь извне и оказывают большее давление по срокам выполнения задач. Чтобы избежать синдрома второго ребенка, помните, что успех одной команды не гарантирует автоматически успех другой. Каждой команде требуются понимание и поддержка, когда она впервые пытается быть Agile-командой.

МАСШТАБИРОВАНИЕ ПРОДУКТОВ И ПОРТФЕЛЕЙ Свободное владение навыками — основа Успешное масштабирование Agile — успешного масштабирования Agile, но самоэто вопрос правильного управления го по себе этого недостаточно. Вам понадовзаимозависимостями. бится способ координации работы команд, если только они не работают совершенно независимо. Это труднее, чем кажется, поскольку команды обычно зависят друг от друга, что вызывает появление узких мест в рабочем процессе, задержек, проблем и ошибок коммуникации. Успешное масштабирование Agile — это вопрос правильного управления взаимозависимостями. Есть две базовые стратегии масштабирования Agile: вертикальное, нацеленное на увеличение количества команд, способных работать друг с другом, не образуя узких мест, и горизонтальное, которое пытается ликвидировать узкие места путем изоляции зон ответственности команд. Обе стратегии можно использовать вместе.

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

94  Часть I.  Улучшая гибкость Я рассмотрю два подхода к тому, как это сделать: LeSS и FAST. Для ясности буду использовать терминологию из этой книги вместо терминов, которые применяются в каждом из подходов, но приведу их в скобках.

LeSS LeSS, который расшифровывается как Large-Scale Scrum, — один из оригинальных подходов в Agile-масштабировании. Он был создан Крейгом Ларманом и Басом Водде в 2005 году1. Базовый LeSS применим для 2–8 команд, численностью до восьми человек каждая. Все команды работают по одному визуальному плану (который в LeSS называется бэклогом продукта) и совместно являются владельцами всего общего кода. Кроме того, существует LeSS Huge, который применяется при значительно большем количестве команд. Это мы обсудим позже. Группу команд LeSS возглавляет продакт-менеджер (LeSS называет их владельцами продукта), отвечающий за принятие решений о направлении развития продукта. Команды работают итерациями фиксированной длительности, обычно составляющими две недели. В начале каждой итерации команды собираются, чтобы вместе посмотреть на визуальный план и решить, над какими историями заказчика (пунктами из бэклога, или функциональностями) будет работать каждая из них. Команды работают только над историями, имеющими самый высокий приоритет. Время от времени команды собираются на игру в планирование (пересмотреть бэклог — рефайнмент). Обычно это происходит в середине каждой итерации. Команды могут добавлять истории к визуальному плану и предлагать приоритеты продакт-менеджеру. Каждая команда LeSS — это команда функциональности; то есть команда работает над историей целиком, от начала до конца, независимо от того, какой код потребуется для ее реализации. Как только команда берет ответственность за историю, она становится ее владельцем. Ожидается, что она будет работать с заказчиком и другими стейкхолдерами, чтобы прояснить детали, а также будет изменять и улучшать любые части кодовой базы, которые потребуются для завершения каждой истории. В LeSS нет концепции владения кодом на командном уровне. В какой-то момент может оказаться, что нескольким командам требуется внести поправки в один и тот же код, поэтому ожидается, что они сами будут договариваться между собой, чтобы избежать проблем. Эта координация обычно происходит спонтанно, при необходимости и напрямую между задействованными участниками. Члены команды знают, когда им будет нужно договориться, поскольку они обсуждали это, работая вместе при выборе историй. Коллективное владение кодом возможно благодаря использованию непрерывной интеграции (Continuous Integration, CI), которая предполагает слияние последнего кода, написанного каждым программистом, с общей основной ветвью каждые несколько часов. LeSS также включает в себя разнообразные механизмы координации, наставничества и обучения. Большое спасибо Басу Водде за отзывы по теме LeSS.

1

Глава 6.  Масштабирование гибкости  95

Внедрение LeSS Материалы этой книги полностью соответствуют LeSS, за исключением того, что в большинстве упоминаний командного владения чем-либо подразумевается, что LeSS-команды владеют этим все вместе, а не какая-либо одна из них. Это особенно верно в отношении менеджмента продукта и владения кодом. Вдобавок некоторые термины LeSS отличаются от тех, которые используются в этой книге. Непрерывная интеграция особенно важна для LeSS, и коммит (фиксация) сборки должен быть быстрым. Возможно, вам необходимо использовать многоступенчатые сборки (см. подраздел «Многоступенчатые интеграционные сборки» главы 13) более интенсивно, чем рекомендует книга. В частности, вам может понадобиться перенести некоторые, а возможно, даже все тесты на вторичную сборку, несмотря на возрастающий риск ее поломки. Если вы ищете устоявшийся, хорошо проСм. также веренный подход к масштабированию Agile, то начните с LeSS. Вам понадобится развить Коллективное владение кодом свободное владение навыками на уровнях фо(глава 12) кусировки и поставки. Уровень фокусировки — Разработка через тестирование это фундамент, а уровень поставки необходим, (глава 13) чтобы команды могли совместно владеть обНепрерывная интеграция щим кодом. Как минимум вам понадобятся (глава 13) практики коллективного владения кодом, разработки через тестирование и непрерывной интеграции. Больше информации о LeSS доступно на сайте less.work или в книге о LeSS LargeScale Scrum: More with LeSS [Larman2015].

FAST FAST расшифровывается как Fluid FAST — один из самых многообещающих Sca­ling Technology. Это детище Рона подходов к масштабированию, который Куартела и один из наиболее многообея когда-либо видел. щающих подходов к масштабированию, который я когда-либо видел. К сожалению, на момент написания этой книги и наименее проверенный. Я включил его в книгу, поскольку думаю, что он заслуживает вашего внимания1. Рон Куартел создал FAST в одной из страховых компаний в Вашингтоне. На пике подхода у него было 65 человек, которые работали как одна команда. Он начал с экстремального программирования в качестве основы, затем наложил его на технологию открытого пространства (Open Space Technology, OST), помогающую большим группам людей самоорганизовываться вокруг какой-либо цели или задачи. По сравнению с LeSS подход FAST гораздо более, так сказать, подвижный. LeSS основывается на итерациях и долгосрочных командах, владеющих определенными Большое спасибо Рону Куартелу за отзывы по теме FAST.

1

96  Часть I.  Улучшая гибкость историями. FAST использует непрерывный поток работы и формирует новые команды каждые несколько дней. В FAST отсутствует владение на командном уровне. FAST-группа называется трайбом (tribe — «племя»). Каждый трайб состоит из разработчиков и одного или нескольких продакт-менеджеров (которых FAST называет директорами по продукту), ответственных за определение направления. В теории трайб может насчитывать до 150 человек, но такое количество не тестировалось на момент написания этой книги. Каждые два дня (этот срок может меняться) трайб собирается на FAST-митинг, на котором решает, над чем работать. Это короткая и быстрая встреча. Продакт-менеджеры объясняют свои приоритеты, и затем люди вызываются добровольцами, чтобы вести работу команды над какой-либо задачей. Таких людей называют стюардами команды. Любой может вызваться добровольцем в стюарды. Это временная роль, которая длится только до следующего FAST-митинга. Приоритеты продакт-менеджеров — это скорее ориентир, а не директива. Стюарды команды могут выбрать для работы задачу, которая им нравится, хотя и ожидается, что они будут действовать добросовестно. Иногда это может под­разумевать работу над чем-то, что продакт-менеджеры не просили напрямую, например исправлением некорректного кода или уменьшением трудностей, возникающих при разработке. Как только добровольцы-стюарды найдены и они объявили, над чем будет работать их команда, оставшаяся часть трайба самостоятельно распределяется по командам в зависимости от того, кто с кем и над чем хочет работать. Вместо того чтобы разбивать истории на детализированные списки задач, команды FAST создают дерево открытий (discovery tree) для каждого ценного инкремента1. (Ценный инкремент представляет собой то, что может быть выпущено само по себе (см. подраздел «Ценные инкременты» главы 8).) Дерево открытий — это иерархическая текущая декомпозиция работы, необходимой для релиза такого инкремента. Его изображают с помощью бумажных стикеров, наклеенных на стене, или виртуальных стикеров на виртуальной доске. Команды работают в течение двух дней или в том темпе, который выбрал трайб. От них не ожидают, что они выпустят что-либо определенное за этот период времени. Вместо этого они просто делают столько, сколько могут. Деревья открытий нужны, чтобы обеспечить непрерывность процесса и помочь людям увидеть прогресс. Кто-то также может выступить добровольцем в роли «стюарда функциональности» определенного дерева открытий, если это необходимо для усиления поддержки непрерывности процесса. Вся остальная кросс-командная координация происходит спонтанно при необходимости и напрямую между задействованными участниками, так же как и в LeSS. По завершении двух дней трайб собирается на следующий FAST-митинг. Команда быстро оценивает свой прогресс, и весь цикл повторяется. Это быстрый, подвижный и неформальный процесс.

1

Буквально «приращение», «добавка». Часть (или версия) создаваемого продукта, потенциально готовая к использованию и увеличивающая ценность для конечных пользователей/потребителей. Инкремент необходимо показывать конечным потребителям для получения от них обратной связи (отзывов, замечаний и предложений).

Глава 6.  Масштабирование гибкости  97

Внедрение FAST FAST не настолько точно совпадает с техниками, представленными в этой книге, как LeSS. Например, многие практики из уровня фокусировки не будут применимы. В частности: zz все места в книге, где упоминается термин См. также «команда», относятся к FAST-трайбу в целом; zz у вас будут дополнительные требования к коКомандная комната (глава 7) мандной комнате, хотя настоящее руководСогласование (глава 7) ство остается в силе, особенно для удаленных команд; Ретроспективы (глава 11) zz согласование и ретроспективы должны быть Визуальное планирование настроены для работы с более крупными груп(глава 8) пами людей, и им, вероятно, понадобится более Игра в планирование (глава 8) опытный фасилитатор, особенно для удаленПланирование задач (глава 9) ных команд; Потенциал (глава 9) zz визуальное планирование применимо в том виде, в котором описывается здесь, но в него Резерв времени (глава 9) больше не включается ничего мельче, чем один Стендап-митинги (глава 9) ценный инкремент (Valuable Increment); Прогнозирование (глава 10) zz игра в планирование, планирование задач и поДинамики команды (глава 11) тенциал больше не нужны; zz резерв времени должен внедряться по-другому; zz стендап-митинги заменяются FAST-митингами; zz прогнозирование — совершенно другое (и значительно проще, хотя его точность не оценивалась); zz динамики команд осложнены, поскольку отсутствуют постоянные составы команд. В то же время одинаково хорошо соответствуют FAST практики уровней поставки и оптимизации. Как и в LeSS, вам нужно быть более требовательным к скорости непрерывной интеграции. Хотя FAST и не проверялся до такой степени подробно, как LeSS, я считаю его очень перспективным. Если у вас есть опыт в Agile и вам ничего не мешает протестировать его с пилотной командой, состоящей из 10–30 человек, то рекомендую вам сделать это. Для тестирования FAST вам нужны опытные коучи. В теории FAST требует свободного владения навыками только на уровне фокусировки. Однако Рон Куартел включил в свой пилотный проект с FAST коучей, имеющих опыт в экстремальном программировании, и я подозреваю, что отчасти именно их знание практик уровней поставки и фокусировки заставило FAST работать. Если вы решитесь попробовать его, то я советую вам сделать то же самое. Вы можете найти больше информации о FAST на сайте fastagile.io. Поищите там раздел FAST Guide. Руководство короткое и легко читается. У меня на сайте также есть интервью с Роном Куартелом о FAST [Shore2021].

98  Часть I.  Улучшая гибкость

Проблемы и преимущества вертикального масштабирования Ахиллесова пята вертикального масштабироваСм. также ния также является и его сильной стороной: это совместное владение. Вертикально масштабиКоллективное владение кодом рованная группа команд совместно отвечает за (глава 12) всю базу кодов. Для этого нужно, чтобы люди были знакомы с большим разнообразием кодов. На практике, по крайней мере в LeSS и FAST, люди обычно имеют специализацию и стремятся работать в тех областях, которые уже знают, но при этом еще могут совершенствоваться. Однако это не самая большая проблема. Настоящая сложность в том, что коллективное владение кодом может легко превратиться в отсутствие владения. Как вы понимаете, коллективное владение не только дает возможность изменять код, но и налагает на вас ответственность улучшать код, когда вы видите такую возможность. В больших группах легко предполагать, что это сделает кто-то другой. В маленьких командах это тоже может быть проблемой, но в больших группах эффект возрастает. Людям потребуется больше коучинга, чтобы помочь им свыкнуться с этой ответственностью. Вместе с тем вертикальное масштабирование решает одну из главных проблем масштабирования Agile: создание кросс-функциональных команд. Agile-командам нужны люди со специальными навыками, такими как UX-дизайн, эксплуатация и безопасность. Если в каждой из ваших команд только шесть или семь человек, то вам будет трудно оправдать включение людей с этими навыками в каждую команду. Но если этого не сделать, то вы столкнетесь с трудностями при распределении задач. Как убедиться в том, что у команды есть все, кто ей необходим, в нужное время? А для вертикально масштабированных групп это не проблема. Если у вас 30 человек и достаточно работы только для двух UX-специалистов, это не проблема: вы можете взять всего двух UX-специалистов. В FAST они сами включат себя в те команды, в которых нужны их навыки. В LeSS они присоединятся к определенной команде или двум, и эти команды вызовутся добровольцами на задачу, требующую квалификации в UX.

Горизонтальное масштабирование Применительно к крупномасштабному Agile я предпочитаю вертикальное масштабирование. Но многие организации вместо этого обращаются к горизонтальному. В нем основное внимание уделяется тому, чтобы позволить командам работать изолированно. Вместо того чтобы коллективно владеть продуктом или портфелем, как это происходит в вертикальном масштабировании, горизонтальное разделяет продукт или портфель на индивидуальные зоны ответственности, которыми владеют отдельные команды. Задача горизонтального масштабирования состоит в определении зон ответственности команды таким образом, чтобы они оставались максимально изолированными.

Глава 6.  Масштабирование гибкости  99

Это очень трудно сделать правильно и затрудняет адаптацию к изменениям в приоритетах продукта. В теории каждая команда должна владеть долей продукта, полностью ориентированного на заказчика, от начала до конца. На практике горизонтально масштабированные команды настолько малы, что им сложно владеть целой долей. В итоге вы приходите к тому, что двум командам необходим доступ к одному и тому же коду. Но в горизонтально масштабированной модели команды не должны делиться кодом с другими командами. В результате, хотя в идеале каждая команда владела бы долей продукта, вам почти всегда придется вводить в работу и менее идеальные типы команд. В книге Team Topologies [Skelton2019] они разделены на четыре категории. zz

Поточно-ориентированные команды. Это идеальный вариант. Они сфокусированы на определенном продукте, его доле, обращенной к заказчику или группе заказчиков.

zz

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

zz

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

zz

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

Секрет успеха горизонтального планирования — в правильном распределении ответственности среди команд. Чем меньше перекрестных зависимостей между командами, тем лучше. Это фундаментальный вопрос архитектуры, поскольку зоны ответственности ваших команд должны имитировать желаемую системную архитектуру. (Это также называется обратным маневром Конвея (Inverse Conway Maneuver).) Горизонтальное масштабирование работает наилучшим образом, когда у вас всего несколько команд. Когда их количество невелико, легко понять, как все они сочетаются друг с другом, и координировать их работу. Если есть проблема, то представители команд могут собраться вместе и все урегулировать. Такой принцип координации по необходимости (ad-hoc coordination) перестает работать при наличии примерно 5–10 команд. Начинают формироваться узкие места,

100  Часть I.  Улучшая гибкость одни команды почти останавливают работу, а другие оказываются перегружены ею. Чтобы сохранять команды как можно более независимыми друг от друга, вам нужно уделять особое внимание их структуре. Каждая команда, особенно те, которые не относятся к типу поточно-ориентированных команд, должна рассматривать автономию тех, кто от нее зависит, как свой высочайший приоритет. А продакт-менеджеры должны тщательно координировать действия всех участников, обеспечивая общую согласованность работы. Когда вы достигаете уровня 30–100 команд, даже этот подход начинает сбоить. Чаще происходят различные изменения, и зоны ответственности команд нужно корректировать, чтобы не отставать от изменений в бизнес-приоритетах. Вам уже требуется многоуровневая система координации и управления. Люди перестают понимать, как работает система в целом. Хотя горизонтальное масштабирование может продолжаться до бесконечности, на практике по мере роста количества команд управлять им становится все труднее. Вертикальное масштабирование является более гибким, но не может масштабироваться до такой степени. К счастью, можно получать преимущества обоих вариантов, комбинируя два подхода.

Вертикальное и горизонтальное масштабирование Я работал со стартапом, в котором участниками команд стали 300 человек и который застопорился на этом. (Вся организация насчитывала более 1000 человек, а в коман­ дах разработки продукта состояло около 300 человек.) Все команды работали над разными аспектами одного и того же продукта, и кросс-командные зависимости просто блокировали их деятельность. Я подошел к задаче со стороны горизонтального масштабирования и помог им реструктурировать зоны ответственности команд так, чтобы минимизировать зависимости и максимизировать изоляцию. В итоге они достигли уровня 40 команд (почти то же, что и раньше), но были гораздо более независимыми. Это разблокировало их попытки развития, и они продолжили рост. Они выросли до 80 команд, прежде чем столкнулись с новым препятствием. Все были довольны результатом. Однако если бы я мог сделать это еще раз, то внедрил бы и вертикальное масштабирование. Вместо 40 команд они могли бы сформировать шесть групп по 50 человек в каждой. Координировать шесть вертикально масштабированных групп значительно легче, чем 40 маленьких команд, и у них не было бы проблем при дальнейшем масштабировании. Даже когда они бы начали сталкиваться с проблемами координации, техники горизонтального масштабирования помогли бы им вырасти на порядок. Так как вертикально масштабированные группы большие, еще лучше было бы, будь все они согласованными по потоку. Созданная нами структура содержала вспомогательные команды и команды платформ, и некоторые из них изо всех сил пытались понять свою роль. Поточно-ориентированные команды гораздо проще. Используя вертикально масштабированные группы, они получали бы все, что им было нужно, кроме операционной платформы.

Глава 6.  Масштабирование гибкости  101

Отчасти причина того, что в работе начались сбои, когда этот стартап разросся до 80 команд, — в том, что организация не поддерживала в актуальном состоянии зоны ответственности команд. Мы спроектировали механизм пересмотра и обновления обязанностей команд (это была работа команды архитекторов), но, как это часто случается, о нем забыли на фоне выполнения других обязанностей. А вертикально масштабированные группы не нуждаются в таком же объеме сопровождения. Они могут намного легче адаптироваться к меняющимся условиям бизнеса. Другими словами, вы можете комбинировать вертикальное и горизонтальное масштабирование, представляя себе свои вертикально масштабированные группы как одну «команду» с точки зрения горизонтального масштабирования. При этом почти каждая может быть поточно-ориентированной, возможно, за исключением группы, занятой вашей операционной платформой.

Моя рекомендация Резюмируем: как вам масштабировать вашу Agile-организацию? Начните с формирования компетентной команды. Наиболее частая ошибка, которую допускают организации, — это начать широко распространять Agile, не добившись свободного владения навыками у команд. В большинстве случаев хороНачните с формирования у команды шее масштабирование потребует от ваших свободного владения навыками. команд развития компетентности на уровнях фокусировки и поставки. Делайте вертикальное масштабирование прежде, чем горизонтальное. В большинстве случаев лучшим выбором является LeSS. Если у вас есть опыт и вы хотите экспериментировать, то попробуйте FAST. Если вы достигли пределов вертикального масштабирования (вероятно, около 60–70 человек, хотя FAST, возможно, способен и на дальнейшее масштабирование), то разделитесь на множество вертикально масштабированных групп. Каждая должна быть поточно-ориентированной. Вам вряд ли понадобится команда сложных подсистем или вспомогательная команда, поскольку ваши группы будут достаточно велики, чтобы иметь все необходимые знания. В некоторых случаях вы можете захотеть сформировать отдельную группу платформ, чтобы заботиться об общей инфраструктуре — обычно о платформе эксплуатации или развертывания. Если вы используете LeSS, то LeSS Huge описывает этот тип разделения при горизонтальном масштабировании, хотя и с небольшими различиями. Он сохраняет присущий LeSS акцент на коллективном владении кодом, даже двумя группами (которые LeSS называет «областями»). Однако в действительности группы склоняются к специализации. Но помните: успех масштабирования зависит от свободного владения навыками команд. Этому посвящена вся оставшаяся часть книги. Мы начнем со свободного владения навыками на уровне фокусировки.

102  Часть I.  Улучшая гибкость

Несколько слов о SAFe SAFe (Scaled Agile Framework), масштабированный гибкий фреймворк, представляет собой популярный подход к Agile-масштабированию. К сожалению, я пока еще не видел его хорошо работающим. Как правило, компании принимают его с большой помпой, но через несколько лет тихо избавляются от него. Я не знаю точно, почему это так. Критики SAFe заявляют, что это не совсем Agile и что ему свойствен характерный оттенок преобладания «процессов над людьми» и «предиктивности над адаптивностью». Я подозреваю, что настоящих причин неудач SAFe две. Во-первых, SAFe подчеркивает, что «он дружествен для предприятий», что в организациях, которые я видел, приводит к недостаточным инвестициям в идеи Agile. Организации склонны придерживаться привычного предиктивного мышления в стиле управления сверху вниз и «командуй-и-контролируй». Во-вторых, SAFe мало что предлагает для координации команд — самой сложной и критически важной проблемы масштабирования. До SAFe 5 он предлагал делить команды по функциональностям (то же, что и LeSS), но это было крайне невыгодно и не включало элементы, с помощью которых LeSS обеспечивает работу команд1. SAFe 5, появившийся в феврале 2021 года, заменил функциональные команды дискуссией о топологиях команд, которая хотя бы содержит больше деталей. Но это подход горизонтального масштабирования, что является шагом назад. Он требует обращать пристальное внимание на структуру обязанностей команд, которую SAFe опять-таки даже не упоминает, не говоря о том, чтобы помочь с этим разобраться. Небольшим вкладом SAFe в координацию команд может считаться сессия планирования инкремента программы (Program Increment (PI) Planning) каждые несколько месяцев, также известная как «планирование в большой комнате». Эта сессия предиктивная, не адаптивная; чрезвычайно трудоемкая и изнурительная; плохо работающая с удаленными командами. Хотя некоторые команды и ценят ее за возможность привести команды к общему пониманию, по моему опыту, это первое, от чего избавляются компании. К сожалению, в SAFe больше нет ничего особенного, и как только из него исчезает PI Planning, вы остаетесь с группой команд и ограниченными возможностями их координации. В общем и целом SAFe на словах поддерживает идеи Agile, однако не понимает их по-настоящему. Я его не рекомендую.

См. https://www.scaledagileframework.com/features-and-components по состоянию на 30 июня 2021 года.

1

II ФОКУС НА ЦЕННОСТЬ

Вы приходите на работу прохладным октябрьским утром. Ваша предыдущая команда работала полностью удаленно, но нынешняя предпочитает работать в офисе. Стили общения — абсолютно разные, размышляете вы, но Agile — тот же самый. Ваша команда свободно владееет навыками на уровне фокусировки. Как команда, вы очень хорошо понимаете потребности заказчика, выступаете с хорошими идеями и фокусируете свою работу на наиболее ценном из того, что можете сделать. Вам есть что улучшить, в частности, в сфере дефектов и развертывания, и люди говорят об инвестировании в свободное владение навыками и на уровне поставки, что позволит решить эти проблемы, но в целом руководство очень довольно вашей работой. Некоторые выступают с идеей, чтобы ваша команда взяла на себя полную ответственность как команда оптимизации, но в данный момент ваши приоритеты определяет Ханна, продакт-менеджер из отдела маркетинга. Она очень занята, и ее босс не хочет назначать ее в вашу команду на полный рабочий день. Кстати, о направлении развития продукта. Сегодня демодень. Каждую неделю ваша команда выпускает новую версию своего ПО, затем составляет план на следующую неделю разработки. Раз в месяц вы встречаетесь с вашими основными стейкхолдерами, показываете, что сделали, и получаете от них обратную связь. Раньше вы делали это чаще, но представителей стейкхолдеров нельзя беспокоить слишком частыми встречами. Так что ваши демо стали реже и короче, и обычно все участники встреч предвкушают что-то новое. Когда нужна более быстрая обратная связь, вы проводите частные демонстрации для отдельных заинтересованных лиц. Как обычно, демо ведет Ханна. Сначала она хотела, чтобы его вели члены команды, но вы обнаружили, что Ханна уделяет больше внимания тому, что вы создаете, если сама отвечает за демо. Это улучшает результаты и обратную связь от заказчиков. Вдобавок она лучше умеет находить общий язык со стейкхолдерами.

104  Часть II.  Фокус на ценность Стейкхолдеры, кажется, довольны вашим прогрессом за этот месяц. Большой интерес вызвала функциональность для немарочного продукта (whitelabel), над которой вы сейчас работаете, и, как обычно, поступило несколько предложений. Ханна принимает их к сведению. После демо приходит время вашей еженедельной командной ретроспективы. Она позволяет вашей команде обсудить практики, динамику и имеющиеся организационные препятствия на пути к экспериментам, а также возможные улучшения. Периодичность ваших демо — как раз результат одного из таких экспериментов. Каждую неделю вы меняете ведущего ретроспективы. На этой неделе очередь Шайны. Вы ждете с нетерпением. Шайна всегда придумывает творческие занятия, чтобы оживить ретроспективу, и ей очень хорошо удается увлечь команду разными экспериментами. У вашей команды перерыв после ретроспективы, затем Ханна начинает еженедельную сессию планирования. Она достает доску для визуального планирования. Это большая белая доска с пачкой индексных карточек, прилепленных к ней магнитами. Карточки образуют кластеры, и у каждого из них есть название, например, «реселлеры», «актуарии», «бухгалтеры». Кластеры представляют собой группы ваших заказчиков. Есть и другая большая группа карточек, помеченная словом whitelabel. «У нас были хорошие идеи во время демо, — говорит Ханна, — но я хочу, чтобы мы продолжили фокусироваться на функциональности для немарочного продукта для реселлеров». Все кивают. Вы работаете над этим уже несколько недель, так что это для вас не является сюрпризом. «Мы близки к завершению самой сути немарочного продукта, поэтому следующий этап — экраны администратора. Перед этим я хотела бы организовать пробный прогон с одним из наших главных реселлеров. Я пришлю подробную информацию по электронной почте». Ханна делает знак Колтону, UX-дизайнеру команды, и он вступает в разговор. «Мы с Ханной собираемся заняться пробным прогоном и администрированием whitelabel чуть позже сегодня. Приглашаем всех поучаствовать. После этого я хотел бы составить карту историй и провести игру в планирование, чтобы конкретизировать истории. Это не должно быть слишком сложным. Я сообщу вам, когда мы это запланируем». Ханна берет несколько голубых карточек с историями из раздела доски, подписанного whitelabel. «У нас еще достаточно историй на эту неделю. Наш потенциал все еще составляет 12 пойнтов (point), верно?» Все кивают. «Отлично. Вот 3… 6… 8, 11, 12. Это должно приблизить нас к пробному прогону с реальными заказчиками». Она поднимает первую карточку, на которой написано «цветовая схема whitelabel». «Окей, для этого нам нужна возможность изменить цветовую схему сайта, чтобы она соответствовала фирменным цветам каждого реселлера». Вдобавок Ханна кратко поясняет содержимое остальных карточек. Ей задают несколько уточняющих вопросов, но вообще-то вы все уже видели это раньше, поэтому процесс идет быстро. «Вот такой план! — заканчивает Ханна. — Колтон сможет ответить на любые вопросы, касающиеся деталей. Сейчас мне нужно заняться электронными письмами, но я буду здесь, — она показывает на угол, — до тех пор, пока вы не закончите планирование. Дайте знать, если от меня понадобятся какие-либо пояснения».

Часть II.  Фокус на ценность  105

Ханна садится, и Шайна берет инициативу в свои руки. Некоторое время назад вы решили (это был другой эксперимент с ретроспективами), что тот, кто ведет ретроспективу, будет фасилитировать все собрания команды в течение недели. Вы не слышали, чтобы какие-либо другие команды работали подобным образом, но наличие заранее назначенного фасилитатора помогает вам придерживаться выбранного направления, тем более сейчас, когда ваш коуч перешел в другую команду. Шайна переворачивает планировочную доску. На обратной стороне ваш план на неделю. «Окей, вы знаете упражнение, — говорит она, указывая на пять карточек с историями, выбранными Ханной. — Разложите их, и начнем мозговой штурм. Нужно выписать задачи на желтые карточки. Я приготовлю доску». Члены команды собираются вокруг стола и начинают записывать задачи на желтых карточках. В процессе этого они высказывают свои соображения, что, в свою очередь, вдохновляет всех на дополнительные идеи. «Обновить схему DB так, чтобы она содержала цветовую схему». «Вынести переменные CSS». «Сделать для каждого реселлера отдельный файл CSS». «Добавить CSS-файл реселлера к шаблону верхнего уровня». Вскоре появляется упорядоченная сеть карточек, показывающая все, что команде нужно сделать за эту неделю. Шайна помогает перенести все на белую доску. Вы слышали, что другие команды визуализируют свои планы по-другому, но вам нравится именно этот подход. «Давайте соберемся на стендап», — говорит Шайна. Вы собираетесь вокруг белой доски и сначала кратко обсуждаете, над чем будете работать, а затем каждый участник снимает с доски карточку с задачей. На каждую задачу уходит всего несколько часов, поэтому, как только она завершена, вы помечаете ее как выполненную и берете с белой доски новую. Каждый день вы проводите новый стендап-митинг вокруг доски, чтобы оценить ваш прогресс и убедиться, что неделя идет должным образом. «Думаю, на этом все», — говорит Шайна. Стендап занял всего несколько минут, а вся сессия планирования продолжалась менее часа. Учитывая ретроспективу и демо, время приближается к полудню. «Кто на обед?»

ДОБРО ПОЖАЛОВАТЬ НА УРОВЕНЬ ФОКУСИРОВКИ Свободное владение навыками на уровне Область фокусировки — фокусировки — для тех команд, которые для тех команд, которые хотят хотят сконцентрироваться на том, что их сконцентрироваться на том, что их компания ценит больше всего. Они тесно сокомпания ценит больше всего. трудничают со своими бизнес-партнерами, чтобы понимать приоритеты, обеспечивать наглядность и реагировать на обратную связь. В частности, команды, которые свободно владеют навыками на уровне фокусировки1: zz планируют свою работу с точки зрения бизнес-ценности, а не технических задач и согласовывают работу с бизнес-приоритетами компании; Эти списки взяты из [Shore2018b].

1

106  Часть II.  Фокус на ценность zz

демонстрируют прогресс по меньшей мере ежемесячно и делают это с точки зрения бизнес-ценности, а не технических задач;

zz

меняют свое направление, чтобы следовать за изменениями в  приоритетах бизнеса;

zz

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

zz

регулярно улучшают свои рабочие привычки, снижая затраты и повышая эффективность;

zz

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

Чтобы добиться всех этих преимуществ, командам необходимо развить соответствующие навыки. Это требует инвестиций, описанных в главе 4. Команда отвечает на потребности бизнеса: zz

работает с представителем бизнеса, который обеспечивает ее организационными перспективами и ожиданиями;

zz

стейкхолдеры от бизнеса могут быть уверены, что команда будет работать над тем, что ее бизнес-представитель называет своим самым важным приоритетом;

zz

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

zz

бизнес-представитель команды видит и может изменить направление работы команды по меньшей мере раз в месяц;

zz

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

zz

составляет свои ежедневные задачи и план, основываясь на приоритетах ее бизнес-представителя;

zz

участники считают план командной работой, а не индивидуальной;

zz

члены команды разделяют ответственность за выполнение плана;

zz

руководство считает план командной работой, а не назначает ответственными отдельных исполнителей. Команда стремится к командным достижениям:

zz

принимает и постоянно улучшает общий подход к своей работе;

zz

понимает, как внутрикомандные отношения влияют на ее способность достигать успеха, и своевременно пытается их улучшить;

zz

понимает, как рабочая атмосфера влияет на способность команды выполнять работу, и своевременно пытается ее улучшить.

Часть II.  Фокус на ценность  107

ДОСТИЖЕНИЕ СВОБОДНОГО ВЛАДЕНИЯ НАВЫКАМИ НА УРОВНЕ ФОКУСИРОВКИ Главы этой части помогут вашей команде достичь свободного владения навыками на уровне фокусировки. Здесь содержатся практики, которые научат вас работать как команда, планировать ценные релизы, управлять своей работой и нести за нее ответственность, а также неуклонно совершенствоваться. zz

В главе 7 рассматривается эффективная работа в команде.

zz

В главе 8 описывается, как планировать и приоритизировать работу в соответствии с бизнес-ценностью.

zz

В главе 9 рассказывается о том, как взять на себя ответственность за повседневный процесс и планы.

zz

В главе 10 описывается, как обеспечить наглядность рабочего процесса и завоевать доверие стейкхолдеров.

zz

В главе 11 представлена информация о том, как улучшать рабочие привычки, отношения и атмосферу в команде.

ГЛАВА 7

Командная работа

Лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Манифест Agile для разработки программного обеспечения

Кросс-функциональные самоорганизующиеся команды — основной ресурс любой Agile-организации. Но кто должен быть частью Agile-команды? Как они узнают, над чем работать? Что помогает им продуктивно работать вместе? В этой главе содержатся практики, позволяющие создать отличную команду Agile. zz

С помощью практики «Вся команда» вы можете создать кросс-функциональную команду, имеющую все необходимые навыки.

zz

Практика «Командная комната» позволит создать пространство, физическое или виртуальное, в котором команда может эффективно сотрудничать.

zz

С помощью практики «Безопасность» вы можете создать рабочую среду, в которой члены команды могут делиться опытом и знаниями.

zz

Практика «Цель» помогает командам понять, как их работа поддерживает глобальные планы компании.

zz

В практике «Контекст» рассматриваются вопросы о стейкхолдерах команды и выделенных ресурсах.

zz

Практика «Согласование» дает возможность устанавливать нормы и правила, позволяющие членам команды эффективно сотрудничать.

zz

В практике «Энергичная работа» рассказывается о том, как работать таким способом, который ваша команда может поддерживать неограниченно долго.

Глава 7.  Командная работа  109

Источники командной работы Идея кросс-функциональных самоорганизующихся команд была частью Agile с самого начала. В экстремальном программировании эта идея называется «вся команда», данный термин я использую в этой книге. В Scrum это явление называется Scrum-командой. Командная комната — тоже устоявшийся термин, в экстремальном программировании это называется «сидеть вместе», а в оригинальной книге о Scrum [Schwaber2002] говорилось о важности рабочей среды для команды. Безопасность также была частью обсуждения в Agile в течение многих лет. [Beck2004] рассуждает об этом в своей дискуссии о команде. Джошуа Кериевски называет принцип «безопасность — предварительное условие» руководящим принципом современного Agile. Обсуждение этой темы было включено в данную книгу благодаря приглашенному автору Гитте Клитгаард, которая имеет огромный опыт помощи командам и организациям в создании психологической безопасности. Практики «Цель», «Контекст» и «Согласование» основаны на великолепной книге Дианы Ларсен и Эйнсли Нис Liftoff: Start and Sustain Successful Agile Teams [Larsen2016]. Вместе они являют собой пример подготовки устава (chartering), который я впервые увидел, в контексте Agile, в методе Джошуа Кериевски Industrial XP (IXP) [Kerievsky2005]. Подготовку устава внес в IXP неподражаемый III1, который также оказал большое влияние на работу Нис и Ларсен. Практика «Энергичная работа» — еще одна давняя идея Agile. Термин пришел из XP: в первом издании книги по XP эта концепция носила название «40-часовая неделя», но оно было пересмотрено, превратившись во втором издании в название «Энергичная работа», менее ориентированное на США.

ВСЯ КОМАНДА У нас есть все навыки, необходимые для достижения отличных результатов.

Аудитория

Коучи Современная разработка ПО требует множества навыков. Речь идет не только о навыках программирования, но и о навыках общения с людьми. Художественных навыках. Технических навыках. И когда команда не имеет этих навыков, производительность падает. Вместо того чтобы сконцентрироваться на функциональности и завершить ее, члены команды должны жонглировать множеством задач, отправляя электронные письма, ожидая ответы и улаживая недоразумения. Чтобы избегать подобных проблем, Agile-команды создаются как кросс-функциональные команды. Они соСм. также стоят из людей, имеющих разные навыки и опыт, коллективно обладающих всеми данными, позволяющими Цель (глава 7) людям выполнять свое предназначение. В широком III — его полное имя. Произносится как «три».

1

110  Часть II.  Фокус на ценность смысле эти навыки могут быть сгруппированы в навыки в сфере деятельности заказчика, навыки разработки и навыки коучинга. Обратите внимание, что Agile-командам нужны Agile-командам нужны навыки, а не роли. Иногда из старших программистов, навыки, а не роли. давно работающих в компании, получаются лучшие продакт-менеджеры. Иногда руководители проектов обладают великолепными навыками в тестировании. И вдобавок Agile-команды учатся и растут. Каждый работает над расширением своих навыков, особенно в отношении сферы деятельности заказчика. В тексте этой книги, когда я пишу «продакт-менеджер» или «разработчик», я имею в виду кого-то в команде, кто имеет такие навыки, а не того, чья должность в команде носит буквально такое название. Agile-команды работают наилучшим образом, когда люди вносят вклад в соответствии с их навыками и опытом, а не позицией в организационной структуре. К А Р ГО - К УЛ ЬТ

Провальная команда «Окей, теперь вы Agile», — говорит ваш руководитель и немедленно исчезает за дверью офиса. Вы вчетвером нервно смотрите друг на друга. Вы — команда фронтенд-программистов и не совсем понимаете, что вам делать. До вас доходили слухи о новой инициативе и о том, что ваша команда будет участвовать в ней… как? На следующий день вбегает Клодин. «Привет! Я ваш Scrum-мастер, — говорит она. — Извините, вчера меня не было. У меня еще четыре команды, и я только что узнала, что буду работать еще и с вами. Рамонита будет вашим владельцем продукта, но она сегодня не сможет присутствовать. Я назначила встречу через неделю». Клодин вводит вас в курс дела касательно продукта, над которым вы будете работать. Ваша команда создает пользовательский интерфейс, а несколько других команд делают микросервисы бэкенда. Тестирование будет проводиться отделом контроля качества, как обычно, и когда вы будете готовы к развертыванию, то отправите заявку в отдел эксплуатации, который будет отвечать за мониторинг и бесперебойную работу. «Вот макет интерфейса, подготовленный отделом дизайна, — говорит Клодин, — и Рамонита добавит в трекер задач истории со всеми требованиями. Я буду встречаться с вами каждый день на стендап-митинге. Просто сообщайте мне, что вы сделали, и я буду обновлять трекер задач». Клодин выбегает, и ее голос, затихая, доносится из глубины коридора. «Дайте мне знать, если вам что-то понадобится!» Вы смотрите друг на друга, пожимаете плечами и открываете трекер задач. Истории не совсем понятные, поэтому вы отправляете несколько электронных писем с вопросами. И начинаете разработку.

Глава 7.  Командная работа  111

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

Навыки в сфере деятельности заказчика Люди, представляющие интересы заказСм. также чика, пользователей или бизнеса, называются локальными заказчиками команды, Вовлечение реального заказчика (глава 8) или просто заказчиками. Они отвечают за понимание, что создавать. В зависимости от вида ПО, которое вы создаете, ваши заказчики в команде могут являться реальными заказчиками или могут быть людьми, представляющими реальных заказчиков. Один из наиболее трудных моментов при создании Agile-команды — найти Чтобы использоваться по-настоящему людей с навыками в сфере деятельноуспешно, ваше ПО должно также сти заказчика. Не пренебрегайте этими приносить пользу реальному заказчику, пользователям и вашей организации. навыками. Они необходимы для повышения ценности продукта, который вы поставляете. Отличная команда может создавать технически совершенное программное обеспечение и без локального заказчика, но чтобы использоваться по-настоящему успешно, ваше ПО должно также приносить пользу реальному заказчику, пользователям и вашей организации. А это требует навыков в сфере деятельности заказчика. Они бывают нескольких категорий.

Управление продуктом (оно же владение продуктом — ownership) Agile-команды фокусируются на ценности, но как они узнают, что ценно? Здесь и начинается управление продуктом. Члены команды, имеющие навыки управления продуктом, находятся в постоянном контакте со стейкхолдерами, чтобы понять, над чем надо работать, почему это важно и чьи интересы нужно удовлетворить; они проводят демо и запрашивают обратную связь; они также продвигают работу команды

112  Часть II.  Фокус на ценность внутри организации. Как правило, это работа См. также на полный рабочий день. Продакт-менеджеры должны иметь полноЦель (глава 7) мочия принимать сложные компромиссные решения о том, что войдет в продукт, а что Контекст (глава 7) останется за рамками. Этим людям требуются Адаптивное планирование (глава 8) навыки дипломатии, которые позволят соглаВизуальное планирование (глава 8) совывать разнообразные интересы множества стейкхолдеров, консолидировать их, превраДемо для стейкхолдеров (глава 10) щая в цель команды, а также эффективно отДоверие стейкхолдеров (глава 10) вечать «нет» на запросы, которые невозможно выполнить. Люди, имеющие навыки и влияние такого масштаба, обычно очень востребованы и заняты. Вам может быть трудно привлечь их внимание. Настаивайте. Продакт-менеджер — один из важнейших членов команды. От его участия зависит, чем закончится проект: успехом или провалом. Если ваше ПО недостаточно ценно, чтобы отнимать время такого специалиста, то, возможно, не стоит и начинать разработку. Во многих компаниях довольно мало продакт-менеджеров. Для команд, работающих медленно и имеющих предсказуемые задачи, это, возможно, не проблема. Но чаще всего это приводит к тому, что команды тратят время впустую, создавая не то, что требуется. [Rooney2006] столкнулся с этой проблемой, приведшей к печальным результатам: Мы не знали, какие у нас приоритеты. Мы не были полностью уверены, над чем работать дальше. Мы вытаскивали истории из общего списка, а заказчик [продакт-менеджер] давал очень мало информации о том, над чем нам работать. Так продолжалось несколько месяцев. Потом мы обнаружили, что золотой владелец [исполнительный спонсор] был очень рассержен — просто в бешенстве. По его мнению, мы работали совсем не над тем, над чем должны были.

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

Экспертные знания в предметной области (Domain expertise, Subject Matter Expertise) Чаще всего программное обеспечение работает в определенной индустрии, например финансовой, имеющей собственные правила ведения бизнеса. Чтобы успешно ис-

Глава 7.  Командная работа  113

пользоваться в этой индустрии, ПО должно добросовестно реализовывать эти правила. Они называются правилами предметной области, а знание этих правил подразумевает знание самой предметной области. В команде нужны эксперты, разбирающиеся в предметной области, которые будут отвечать за выяснение всех деталей, разрешение противоречий и давать немедленные ответы на любые вопросы. Это должны быть люди с огромным опытом. Одна Agile-команда, с которой я работал, разрабатывала ПО для химического анализа, и в ней был химик-аналитик со степенью магистра. Другая создавала программу для управления межбанковским залоговым обеспечением, и в ней были два финансовых эксперта. Третья создавала ПО для страхования жизни, и ее эксперт в предметной области был актуарием. Даже если в вашем ПО нет сложных правил См. также предметной области, вам все равно понадобятся люди, которые смогут детально разобраться Поэтапные требования (глава 8) в том, что именно оно должно делать. В некоторых командах таким человеком может быть Примеры заказчика (глава 9) продакт-менеджер, дизайнер пользовательскоЕдиный язык (глава 12) го интерфейса (User Experience; UX-дизайнер) или бизнес-аналитик. В отличие от продакт-менеджера, который должен много времени общаться со стейкхолдерами, эксперт в предметной области проводит основное время с коман­дой. Бо́льшая часть этого времени уходит на прояснение деталей предстоящей работы, создание примеров сложных правил и ответы на различные вопросы по данной предметной области.

Дизайн пользовательского интерфейса (UX-дизайн) (он же дизайн взаимодействий) Пользовательский интерфейс вашего ПО — лицо вашего продукта. Для многих пользователей интерфейс и есть продукт. Они судят о продукте, основываясь только на том, какое впечатление у них вызвал его пользовательский интерфейс. Люди, имеющие UX-навыки, определяют пользовательский интерфейс. Эти навыки заключаются в понимании пользователей, их потребностей и того, как они взаимодействуют с продуктом. В их работу входит проведение интервью и обсуждение прототипов с пользователями, создание пользовательских образов, наблюдение за использованием реального ПО и объединение этой информации в подробные макеты и изображения. Быстрая, итеративная и ориентированная на обратную связь природа Agileразработки приводит к формированию среды, отличной от той, к которой, возможно, привыкли UX-дизайнеры. Вместо того чтобы включать UX-дизайн в предварительные исследования пользователей, его выполняют итеративно, одновременно с такой же итеративной доработкой самого ПО. Agile-команды выпускают ПО каждую неделю или две, что дает дизайнерам возможность дать его реальным пользователям, понаблюдать за паттернами его использования и руководить дальнейшими планами команды, основываясь на полученной обратной связи.

114  Часть II.  Фокус на ценность

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

Программирование, дизайн и архитектура Любой команде, разрабатывающей ПО, См. также конечно, необходим навык программирования. Кроме того, в команде поставки Разработка через тестирование каждый, кто пишет код, также делает (глава 13) дизайн и архитектуру, и наоборот. Такая Простой дизайн (глава 14) команда использует метод разработки через тестирование, чтобы объединить Инкрементный дизайн (глава 14) архитектуру, дизайн, тесты и кодироваРефлексивный дизайн (глава 14) ние в непрерывную деятельность. Эволюционная системная архитектура Но все же эксперты в дизайне и архи(глава 15) тектуре необходимы. Их роль — возглавИгра в планирование (глава 8) лять работы по дизайну и архитектуре, Без багов (глава 16) помогая членам команды найти способы упрощения сложного дизайна. Эксперты Сборка для эксплуатации (глава 15) действуют на равных, скорее направляя, чем командуя. Навыки программирования позволяют осуществлять планирование, предотвращать дефекты и упрощать развертывание ПО и управление им в производственной среде.

Тестирование Люди, имеющие навыки тестирования, помогают команде поставки создавать качественные результаты с самого начала. Благодаря их критическому мышлению заказчики при представлении будущего продукта могут рассматривать все возможности. Эти люди также выступают в роли технических экспертов команды,

См. также Поэтапные требования (глава 8) Примеры заказчика (глава 9) Обнаружение слепых зон (глава 16) Без багов (глава 16)

Глава 7.  Командная работа  115

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

Эксплуатация (Operations) В командах поставки нужны люди, имеющие навыки эксплуатации ПО. Они помогают разСм. также вертывать, контролировать, управлять ПО Непрерывное развертывание и обеспечивать его безопасность в производ(глава 15) стве. В небольших организациях эти люди также могут отвечать за обеспечение и управление Сборка для эксплуатации (глава 15) аппаратными средствами (hardware). В более крупных организациях они могут быть заняты Анализ инцидентов (глава 16) координацией с центральной эксплуатационной группой. В навыки эксплуатации также входит помощь команде в поддержании рабочих реалий: планирование потребностей отдела эксплуатации, таких как безопасность, производительность, масштабирование, контроль и управление; справедливое распределение смен дежурств на линии поддержки (при необходимости); помощь в анализе и предотвращении инцидентов.

Навыки коучинга Командам — новичкам в Agile надо научиться многому: им нужно понять, как применять практики Agile, вдобавок им следует научиться работать всем вместе как эффективные самоорганизующиеся команды. Их организациям также надо научиться способам поддержки своих команд. Большую часть этой поддержки они дают в виде инвестиций, описанных в главе 4, но всегда необходимы дополнительные изменения. И хотя лучше, если организации делают нужные командам инвестиции заранее, командам часто приходится добиваться необходимых инвестиций уже после того, как работа началась. Люди, имеющие навыки коучинга, помогают командам учиться быть эффективными Agile-командами. Они обучают практикам, помогают в дискуссиях, направляют самоорганизацию и развитие и показывают, как работать с руководителями и другими бизнес-стейкхолдерами, чтобы получить нужные инвестиции. Команды — новички в Agile обычно имеют в своем составе одного, иногда двух человек, однозначно опреРабота коуча — деляемых как коучи команды. Работа этих людей — помогать команде помогать команде стать независимо компетентной, стать независимо чтобы все ее члены могли выполнять свои задачи компетентной. без участия коуча. Это не значит, что коуч уходит из

116  Часть II.  Фокус на ценность команды, но это значит, что он мог бы, и если остается, то постепенно становится постоянным членом команды. ПРИМЕЧАНИЕ Даже после того как команда станет независимо владеть навыками, будет полезно присоединять к ней опытного коуча (скажем, раз в год или около того), чтобы помочь ей вспомнить забытые практики и попробовать новые.

Командам нужен коучинг в четырех категориях в зависимости от того, какие уровни свободного владения навыками их интересуют. zz

Развитие команды, самоорганизация и посредничество (все команды).

zz

Практики планирования и командной работы на уровне фокусировки.

zz

Практики разработки на уровне поставки.

zz

Практики развития бизнеса на уровне оптимизации.

Для этого может потребоваться несколько коучей. Часть работы коуча — научить команду быть самодостаточной. Ее участники должСм. также ны быть способны сами помогать себе вести дискуссии, улучшать динамику и практики Ретроспективы (глава 11) своих команд, понимать, какие инвестиции Динамики команды (глава 11) сделают их более эффективными, и работать Устранение препятствий (глава 11) со стейкхолдерами так, чтобы получить эти инвестиции. Как и со всеми командными навыками, нет необходимости, чтобы это мог делать каждый в команде, но чем больше участников могут, тем более устойчивой она будет. Некоторые коучи попадают в своеобразную ловушку и начинают делать все это за команду, вместо того чтобы научить ее, как делать это самостоятельно. Убедитесь, что это не ваш случай.

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

Коучи-игроки Один из вариантов коуча-практика — это коуч-игрок (играющий тренер, playercoach), который имеет опыт в практиках Agile и некие навыки коучинга, но больше сфокусирован на поставке, чем на помощи командам в обучении. В эту категорию

Глава 7.  Командная работа  117

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

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

Специалисты широкого профиля Команды Agile работают наилучшим образом, когда состоят из специалистов широкого профиля, также называемых людьми с профилем компетенций T, или T-людьми (T-shaped people). Специалист широкого профиля обладает глубокими знаниями и опытом сразу в нескольких областях, что символизирует вертикальная линия буквы Т, но полезен и в некоторых других областях, необходимых команде. Это символизирует горизонтальная черта. (Иногда используют термин «М-люди» (M-shaped people), чтобы подчеркнуть, что такие специалисты могут развить у себя экспертные навыки во многих областях.) Agile-командам нужны такие специалисты, чтобы предотвращать образование узких мест в рабочем процессе. Организации, не использующие Agile, следуют Название Scrum-мастер пришло из популярного метода Scrum. Оно вводит в заблуждение: предполагает кого-то, кто достиг мастерства в понимании Scrum, а не того, кто имеет власть или контроль над командой.

1

118  Часть II.  Фокус на ценность сложным процедурам формирования ресурсов, чтобы обеспечить каждую команду необходимыми специалистами в нужное время. Эти процедуры никогда толком не работают, поскольку работа по созданию ПО не может быть предсказана настолько точно, насколько они требуют. Поэтому командам в итоге приходится ждать нужных людей, задерживающихся на других проектах, или торопливо находить какие-то задачи для тех специалистов, которые освободились раньше, чем вся команда готова к началу работы. Получается, что люди страдают из-за множества краткосрочных разрозненных назначений, в то время как руководители борются за то, чтобы выровнять назначение в команде. Это ведет к разнообразным потерям. В Agile-организации ресурс — это команды, а не индивидуумы, поэтому процесс формирования ресурсов значительно более простой: все или ничего. Команда или берется за разработку функциональности, или нет. Или нужного человека назначают в команду, или она не приступает к работе. Но вы можете столкнуться с узкими местами и внутри команды. Представьте команду с двумя фронтенд- и двумя бэкенд-разработчиками. Иногда бывает больше работы по фронтенду, и тогда разработчики бэкенда бездельничают. (Или они работают на опережение, что в конечном итоге приводит к постоянным дорогостоящим переделкам, что мы будем обсуждать во врезке «Минимизируйте объем незавершенной работы» в главе 8.) В другое время ситуация в такой команде может быть противоположной. Команды, в составе которых есть специалисты широкого профиля, избегают этого. Когда много работы по фронтенду, соответствующие специалисты берут инициативу в свои руки, а бэкенд-разработчики им помогают. Когда много работы по бэкенду, все наоборот. И речь идет не только о программировании. Какие бы узкие места ни встретились команде, ее члены должны хотеть и быть способны вмешаться и помочь решить проблему. Вам не нужно, чтобы члены команды были специалистами широкого профиля, когда вы впервые ее формируете. Это больше про их отношение к данному вопросу, чем возможности. Любой специалист при желании может научиться работать в областях, близких к его основной специализации. При подборе людей в команду убедитесь, что у них есть такое желание.

Комплектование команды Точные названия должностей и ролей в вашей команде неважны, пока в ней представлены все необходимые навыки. Должности больше имеют отношение к традициям в вашей компании, чем к чему-либо еще. ПРИМЕЧАНИЕ В недавно сформированных Agile-командах полезно четко обозначить продактменеджера и коуча. Для опытных команд четкие роли могут только мешать, но новичкам в Agile будет полезно точно знать, к кому обращаться в случае вопросов.

Глава 7.  Командная работа  119

У вас может не получиться найти в команду Внештатные владельцы продукта человека, имеющего навыки продакт-менедне могут поддерживать команду жера или экспертные знания в предметной в долгосрочной перспективе. области. Во многих компаниях такого человека назначают на неполный рабочий день координировать команду в качестве владельца продукта. Рассматривайте это как знак того, что члены команды должны сами развить у себя навыки менеджмента продукта и экспертные знания в предметной области. Такой внештатный владелец продукта может помочь им начать, однако не сможет поддерживать их в долгосрочной перспективе. Лучшие Agile-команды прекрасно разбираются в сфере деятельности заказчиков. Это хорошо сформулировал Бас Водде1: Я вижу, что большинство команд, с которыми работаю, находятся на пути трансформации от «программистов» к «разработчикам продукта». Это означает, что команда (вся команда!) глубоко понимает заказчика и его предметную область, а не зависит от кого-то, кто выяснит все для них и передаст им результаты. Да, мне нравится, когда в команде есть люди, которые хорошо знают заказчика, но в основном имеют цель помочь всей команде совершенствоваться.

Даже в случае высокопрофессиональной команды некоторые решения будут приниматься людьми, не входящими в вашу команду. Например, если она работает над компонентом большого продукта, решения о системной архитектуре могут оказаться вне вашей компетенции. Хорошо, если эти решения — только часть каких-то процессов, происходящих на заднем плане. Но если вы постоянно ждете, пока люди, не входящие в вашу команду, примут решение или сделают что-то для вас, — значит, ваша команда неполная. Члены вашей команды должны иметь требуемые навыки и ответственность, или же данный компонент продукта нужно отдать куда-то вне команды. Больше информации о кросс-командной координации доступно в главе 6.

Постоянные члены команды Каждый постоянный член команды должен быть полностью приписан только к одной команде. Дробные назначения (когда человек назначается одновременно в несколько команд) дают ужасные результаты. Частично занятые работники не связаны со своей командой, часто не присутствуют при обсуждениях и не слышат ответы на вопросы, к тому же должны постоянно переключаться между задачами, что влечет за собой множество скрытых потерь. «Минимальные потери — 15 процентов. Работники с частичной занятостью могут выглядеть загруженными, но их загруженность — по большей части бестолковая суета» [DeMarco2002] (гл. 3). Скорее всего, некоторые навыки нужны вашей команде лишь изредка. Вы можете приглашать людей, имеющих эти навыки, временно присоединиться к вашей команде. Например, если она создает сложный продукт на серверной стороне, имеющий очень маленький пользовательский интерфейс, то вы можете пригласить UX-дизайнера присоединиться к вашей команде лишь на те несколько недель, в течение которых вы работаете над интерфейсом. В личном общении.

1

120  Часть II.  Фокус на ценность Даже если кто-то временно является частью вашей команды, договоритесь, чтобы эти люди были полностью приписаны к вам на этот период. Лучше иметь кого-то, назначенного в команду на полный рабочий день на одну неделю, а потом — к другой команде на другую неделю, чем того же человека, назначенного в обе команды одновременно на две недели.

Стабильные команды Команде может потребоваться несколько меСм. также сяцев на то, чтобы научиться эффективно работать вместе. В некоторых организациях Динамики команды (глава 11) команды создаются и расформировываются для каждого нового проекта. Однако сохранять состав команды — менее расточительный вариант. Даже если цель команды достигнута или жизненный цикл продукта завершен, не распускайте команду. Вместо этого дайте ей новую цель или продукт. То же самое применимо и к изменению состава. Если вы добавляете человека в существующую команду, то он встраивается в ее культуру и нормы. А если вы добавляете нескольких, то команда практически начинает все с нуля. Мое правило — добавлять или удалять не больше одного человека в месяц.

Размер команды Рекомендации в этой книге предназначены для команд численностью 3–20 человек. Для новых команд хорошей отправной точкой будет численность 4–8 человек. Превысив количество в 12 человек, вы начнете замечать проблемы в общении, так что будьте осторожны при создании больших команд. И наоборот, если у вас очень маленькие команды, то подумайте о том, чтобы объединить их. Это уменьшит расходы, и вы будете менее чувствительны к текучести персонала. Для большинства команд программирование поначалу будет узким местом. Поэтому, См. также планируя размер команды, начните с того, чтобы подумать, сколько времени уходит Парное программирование на программирование. Для удобства я буду (глава 12) называть человека, на 100 % занятого проГрупповое программирование граммированием, «один программист», но это (глава 12) не значит, что в вашей команде должны быть строго обозначенные роли. zz Команды, которые не используют парное или групповое программирование, должны состоять из 3–5 программистов. По мере увеличения команды у них начинаются проблемы с координацией. zz Команды с парным программированием должны состоять из 4–10 программистов. Оптимальное количество — шесть. Команды — новички в практиках поставки не должны насчитывать больше 6–7 программистов, пока не приобретут достаточного опыта.

Глава 7.  Командная работа  121

Команды с групповым программированием должны состоять из 3–5 программистов. Можно работать и с более многочисленными группами (это хорошая обучающая техника), но в какой-то момент вы достигнете точки падения эффективности. Обычно оставшуюся часть команды комплектуют пропорционально объемам выполняемого программирования. Соотношение должно быть примерно эквивалентно количеству работы, которую надо сделать так, чтобы не образовывались узкие места, а наличие специалистов широкого профиля должно позволять справляться с неравномерностью загрузки. В целом нужно планировать: zz навыки в сфере деятельности заказчика — один-два локальных заказчика на каждые три программиста. От четверти до половины их времени будет уходить на менедж­мент продукта. Оставшееся будет тратиться на сочетание экспертных знаний в предметной области и UX- и UI-дизайна в зависимости от вида вашего ПО; zz навыки тестирования — один тестировщик на каждые 2–4 программиста, если команда не имеет свободного владения навыками на уровне поставки, или один тестировщик на каждые 4–8 программистов, если имеет; zz навыки эксплуатации — от нуля до двух специалистов эксплуатации в зависимости от типа продукта; zz навыки коучинга — один или два коуча, которые могут делить свое время с другими командами. Повторюсь: речь идет не о наличии четких ролей в команде. Например, вы можете иметь команду из шести программистов, включая коуча-игрока, которая затрачивает примерно половину своего времени на программирование, одну шестую — на работу с заказчиком, одну шестую — на тестирование и еще одну шестую — на эксплуатацию. zz

Почему так много заказчиков Два заказчика на каждых трех программистов — это очень много, не правда ли? Я начинал с гораздо меньшего соотношения, но часто видел, что заказчики держатся наравне с программистами. В итоге я пришел к соотношению «два к трем» после экспериментов с разными соотношениями в различных успешных командах. Все эти команды свободно владели навыками на уровне поставки, что подразумевало наличие в команде менеджмента продукта. Большинство работали в сложных предметных областях. Если у вас простое ПО и вы не стремитесь к свободному владению навыками на уровне поставки или у вас в команде отсутствует менедж­ мент продукта, то, вероятно, сможете обойтись меньшим количеством заказчиков. Но имейте в виду, что у заказчиков очень много работы. Им необходимо понять, что представляет наибольшую ценность, установить правильные приоритеты в работе, определить все детали, о которых будут спрашивать разработчики, и вовремя реагировать на отзывы и примеры от клиента. Заказчики должны все это делать, на один шаг опережая программистов, которые (особенно в командах поставки) неумолимо следуют за ними, словно товарный поезд, который невозможно остановить. Это очень большая работа. Не стоит ее недооценивать.

122  Часть II.  Фокус на ценность

Команда единомышленников Никто в команде не отвечает за других. Далеко не каждое решение подлежит обсуждению; но люди имеют решающий голос в своей экспертной области. Например, программисты не могут не учитывать мнение заказчиков о приоритетах продукта, а заказчики не могут не принимать во внимание мнение программистов о технических необходимостях. Вдобавок у вас есть старшие члены команды, которые берут на себя принятие важных решений. Но внутри нее нет иерархии подчиненности. Даже люди с впечатляющими должностями, наподобие «продакт-менеджер», не управляют командой. Это понимание важно для самоорганизующейся команды. Она сама решает, кто возьмет на себя инициативу в любой задаче. И это нельзя считать трудным решением; в командах, которые хорошо знают друг друга, это обычно происходит автоматически. Таким человеком будет тот, кто лучше всех знаком с задачей, или тот, кто больше всех заинтересовался получением дополнительной информации, или следующий в очереди, или кто-нибудь еще. При этом трудно передать, насколько весело и с удовольствием проводят время высокопродуктивные Agile-команды. Брайан Марик, один из авторов Манифеста Agile, говорил, что радостный настрой (Joy) — еще одна ценность Agile1. И он прав. Отличные Agile-команды ее ощущают. Они оптимисты, энтузиасты своего дела и получают истинное удовольствие от совместной работы. Есть чувство превосходства, но они не воспринимают его слишком серьезно. Например, когда есть задача, за которую никто не хочет браться, разговор о том, кто ее будет делать, может вестись в игривой и веселой манере. И он протекает быстро. Эффективные Agile-команды легко принимают решения. Такая эффективность требует значительСм. также ного времени и работы над собой. В практике «Динамики команды» показано, как Динамики команды (глава 11) это сделать. КЛЮЧЕВАЯ ИДЕЯ

Самоорганизующиеся команды Agile-команды самостоятельно решают, над чем работать, кто будет это делать и как. Это основная идея Agile: люди, которые выполняют работу, достаточно квалифицированны, чтобы решать, как ее делать. Поэтому в данной книге так много практик в областях планирования, взаимодействия и работы со стейкхолдерами. За все это отвечают команды, а не менеджеры. От команд ожидается, что они коллективно возьмут на себя ответственность и будут совместно работать для достижения своей цели. Это не значит, что руководителям нечем заняться. Фактически, делегируя детали своим командам, руководители освобождают свое время, чтобы иметь Марик определял четыре ценности, которые он видел в ранних Agile-командах: навык, [само]дис­циплина, легкость, радостный настрой [Marick2007a].

1

Глава 7.  Командная работа  123

возможность сконцентрироваться на более значимой деятельности. Их работа — настраивать команды на успех, управляя более широкой системой, в которую встроены их команды. Более подробная информация представлена в разделе «Менеджмент» главы 10.

Еще раз о провальной команде Давайте еще раз взглянем на историю провальной команды (см. врезку «Провальная команда» ранее в текущей главе). Что пошло не так? zz Руководитель удивил команду и сразу ее покинул, вместо того чтобы настроить ее на успех. zz Коуч Клодин не помогала команде учиться. zz У Рамониты, продакт-менеджера, совсем не было времени на команду. zz В команде не было никого, кто разбирался бы в сфере деятельности заказчика. zz У команды не было возможности самостоятельно выпускать продукт. Им требовалось координироваться с внешними командами: отделом контроля качества, эксплуатации и бэкенда. А вот как все это должно было произойти. «Окей, сегодня день Agile», — говорит ваш руководитель. Вы согласились на этот эксперимент несколько недель назад, так что никто не удивлен. «Как мы обсуждали, мы формируем новую команду для работы над этим продуктом. Почему бы вам всем не представиться и не рассказать о себе заново?» Все присутствующие поочередно представляются. У вас три фронтенд-программиста (один имеет опыт работы с полным стеком (full stack experience)), один бэкенд-программист, тестировщик и один UX-дизайнер. Вы уже познакомились со своим коучем Клодин. Она представляет вам Рамониту, вашего продакт-менеджера. Входит Клодин. «Я знаю, что вам всем не терпится узнать, как работает Agile, поэтому сразу перейду к делу. Мы начнем с активности, называемой подготовкой устава. Рамонита работает со стейкхолдерами нашего проекта, чтобы понять, что мы будем создавать, почему и как это на всех повлияет. Мы тоже с ними встретимся через пару минут. Кроме того, мы уделим некоторое время тому, чтобы понять, как нам взаимодействовать наилучшим образом». В течение следующих нескольких дней вы думаете, как выполнить эту работу, и начинаете подбирать для нее технологии, имеющиеся в вашем распоряжении. Рамонита не входит в состав команды, но Микки, ваш UX-дизайнер, будет плотно работать с ней, чтобы конкретизировать ваши планы. Проходят недели. Рамонита появляется часто, и Микки учится заменять ее, когда она отсутствует. Благодаря тому, что ответственные за фронтенд, бэкенд, тестирование и эксплуатацию становятся одной командой, вам удается продвигаться быстро. Через неделю вы проводите первое демо для стейкхолдеров, и их реакция заряжает вас новой энергией. Вы — хорошая команда. И вам не терпится увидеть, что будет дальше.

124  Часть II.  Фокус на ценность

Вопросы А что, если не хватает людей, чтобы обеспечить каждую команду всеми необходимыми ей навыками, или определенный навык нужен команде не постоянно? Для начала проверьте, не нанимает ли ваша компания слишком много программистов по сравнению с остальными экспертами, нужными командам разработки ПО. Это распространенная ошибка. Если это так, то попробуйте изменить приоритеты найма. Если у вас несколько команд, работающих над одним продуктом, то рассмотрите возможность использования вертикального масштабирования, что позволит разумно объединить их усилия, как описано в подразделе «Вертикальное масштабирование» главы 6. Если эти варианты не сработают, то ваша компания может сформировать вспомогательную команду, ответственную за инструкции, стандарты и тренинг для других команд, как описано в подразделе «Горизонтальное масштабирование» главы 6. Например, какая-либо UX-команда может создать руководство по стилям и научить людей, как его использовать применительно к программному обеспечению, разрабатываемому их командами. Это позволяет командам решать собственные проблемы, не нуждаясь в полноценном опыте. Когда требуется больше навыков, вы можете запросить, чтобы соответствующего специалиста назначили в вашу команду временно. За этот период он сможет обучить членов команды. Отложите любую работу, требующую определенных навыков, до тех пор пока они не появятся. Таким образом вы не останетесь с наполовину выполненной работой, что ведет к потерям, как обсуждается во врезке «Минимизируйте объем незавершенной работы» в главе 8. Младшие члены команды наравне с остальными? Члены команды необязательно наравне (у всех разная квалификация и опыт), но они коллеги. Для младших членов команды будет разумным обращаться за советом и наставничеством к более опытным коллегам. А для тех, в свою очередь, разумным будет обращаться ко всем с уважением, создавать товарищеские отношения и помогать младшим коллегам расти, иногда делая шаг назад и позволяя им взять инициативу в свои руки. Как члены команды могут развить определенные навыки, не работая в команде, специализирующейся на этом навыке? Многие Agile-организации формируют сообщества практик вокруг функциональных специализаций. Их может вести руководитель, централизованная команда поддержки или просто те, кому это интересно. Обычно эти люди проводят множество тренингов, встреч и предлагают другие возможности для развития навыков.

Предварительные требования Создание кросс-функциональной команды требует вовлеченности и поддержки от руководства, а также согласия команды работать вместе как Agile-команда. В главе 5 можно найти больше подробностей о формировании такой вовлеченности.

Глава 7.  Командная работа  125

Показатели Когда ваша команда кросс-функциональна: zz

она способна решать проблемы и выполнять свою задачу, не дожидаясь внешних специалистов;

zz

люди в команде работают, выходя за рамки своей специализации, чтобы предотвратить появление узких мест и замедление работы;

zz

команда способна принимать решения легко и эффективно;

zz

люди в команде плавно перенимают роли лидерства от задачи к задаче.

Альтернативы и эксперименты Теория, лежащая в основе этой практики, очень простая. Чтобы избежать задержек и проблем в общении, следует: 1) найти всех, кто нужен для достижения ваших целей; 2) собрать их всех в одну команду; 3) организовать согласованную работу команды так, чтобы она достигла этих целей. Это основная идея Agile, и на самом деле нет никаких альтернатив, соответ­ ствующих философии Agile. Но есть много возможностей для оптимизации де­ талей. Накопив опыт использования этой практики, несколько месяцев применяя ее буквально, как написано в этой книге, попробуйте немного поэкспериментировать. Например, как ваша команда может экспериментировать с изменением способов принятия решений? Улучшается ли процесс, если назначить специального человека для фасилитации дискуссий? Или пусть дискуссии текут свободно? Следует ли возлагать некоторые решения на конкретных людей? Или ответственность руководства должна быть более гибкой? Простых ответов на эти вопросы не существует. Сделайте предположение. Проверьте его, посмотрите, как все работает, и сделайте другое предположение. Проверьте и его. Никогда не переставайте экспериментировать. Только так можно достичь мастерства.

Литература для дополнительного чтения The Wisdom of Teams: Creating the High Performance Organization1 [Katzenback2015] — классическое издание о высокоэффективных командах. Agile Conversations [Squirrel2020] — отличный ресурс для коучей, которые помогают командам и организациям развить культуру Agile. Катценбах Дж., Смит Д. Командный подход: Создание высокоэффективной организации.

1

126  Часть II.  Фокус на ценность

КОМАНДНАЯ КОМНАТА Мы взаимодействуем быстро и эффективно.

Аудитория Вся команда, коучи

К А Р ГО - К УЛ ЬТ

Окончание истории Вы — программист, работающий в команде над какой-то историей, и вам нужны пояснения по одному из требований. Вы отправляете электронное письмо вашему эксперту в предметной области, Линн, и делаете перерыв, чтобы размять ноги и выпить кофе. Когда вы возвращаетесь, ответа от Линн все еще нет, поэтому вы заглядываете в пару блогов по теме разработки, которые собирались почитать. Через полчаса вы получаете ответ Линн. Эх, кажется, она не поняла ваше сообщение и ответила не на тот вопрос. Вы отправляете другое письмо, но дальше ждать уже не можете. Вы предполагаете, каким мог бы быть ее ответ, и возвращаетесь к работе. Днем позже, обменявшись еще несколькими письмами, вы вместе с Линн нащупываете правильный ответ. Он не совсем такой, как вы предполагали, но довольно близок к этому. Вы возвращаетесь к тому месту в коде и корректируете его. В этот момент вы вдруг понимаете, что есть еще один связанный случай, которым еще никто не занимался. Конечно, вы можете еще раз спросить Линн, но это очень странный случай. Скорее всего, в реальной жизни он никогда не произойдет. Кроме того, Линн очень занята, а вы обещали закончить с этой историей еще вчера. (Фактически все и было готово вчера, кроме этих мелких придирок.) Вы снова делаете предположение и продолжаете работу, не зная, что ваше предположение было неверным.

Когда люди не могут общаться напрямую, эффективность общения падает, как обсуждается во врезке «Личное общение» далее в текущей главе. Возникают недопонимание и задержки. Люди начинают строить догадки, чтобы избежать долгого ожидания ответов. Случаются ошибки. Начинает формироваться подход, в котором есть противостояние группировок «мы» и «они». Чтобы справиться с этой проблемой, многие команды пытаются снизить необходимость прямого общения. Это спорный способ. Если вопросы порождают задержки и ошибки, снизьте необходимость задавать вопросы! Люди тратят больше времени на предварительное выяснение требований и  документирование каждой потребности. Согласно этой теории, впоследствии программистам не нужно будет общаться с экспертами; они могут просто посмотреть ответы в документе. Звучит разумно, но на практике не работает. Трудно заранее предсказать каждый То, что написано, очень легко понять вопрос, и  то, что написано, очень легко неправильно.

Глава 7.  Командная работа  127

понять неправильно. К тому же это удлиняет процесс разработки: прежде чем приступить к работе, людям нужно потратить много времени на написание, передачу и чтение документов. Поэтому Agile-команды используют общую командную комнату, чтобы разговаривать напрямую. Это место, См. также физическое или виртуальное, в котором команда рабоВся команда (глава 7) тает и взаимодействует друг с другом. Вместо того чтобы назначать кого-то для общения с экспертами в предметной области и готовить документы, которые потом будут читать программисты, Agile-команды включают в свой состав экспертов в предметной области и других локальных заказчиков. Когда программистам надо понять, что делать, они разговаривают с локальными заказчиками напрямую. Совместная работа в одной комнате дает огромные См. также преимущества. В полевых исследованиях шести совмещенных рабочих команд [Teasley2002] было обПоэтапные требования наружено, что работа в одном помещении удваивала (глава 8) продуктивность и ускоряла выход на рынок почти до трети от базового расчетного уровня компании. Это сто́ит того, чтобы повторить еще раз: команды поставляли ПО за треть обычного времени. После пилотного исследования еще 11 команд достигли того же результата. КЛЮЧЕВАЯ ИДЕЯ

Личное общение Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее. Манифест Agile для разработки программного обеспечения Несмотря на успехи технологий, непосредственное, личное общение остается самым эффективным способом общения. Перефразируя [Cockburn2006] (гл. 3), существует несколько осей эффективности общения. Удаление каждой из них делает его менее эффективным. zz

zz

zz

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

128  Часть II.  Фокус на ценность

zz

zz

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

Уберите все это — и получите написанный документ. Нет нюансов, интерактивности, но есть максимум возможностей для неверного понимания.

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

Всегда просите помощи, всегда помогайте Если вы зациклились на проблеме, а кто-то в команде знает ответ, попросите его помочь. Нет смысла биться головой о стену. Многие команды заключают рабочее соглашение: «Мы всегда помогаем, когда член команды просит помощи». Некоторые, услышав это правило, беспокоятся, что не будут продуктивными. И в некоторой степени Agile фокусируется они правы. Если вы будете проводить много времени, на продуктивности отвечая на вопросы, то вы, возможно, будете не столь команды, а не отдельных продуктивны. Но Agile — это команда. Даже если вам лиц. в конечном итоге придется тратить больше времени, команда в целом будет более продуктивной. А как насчет программирования и другой работы, требующей глубокой сосредоточенности? Согласно [DeMarco2013], у программиста уходит 15 минут и больше на то, чтобы погрузиться в работу после прерывания. Не может ли культура, в которой все время просят о помощи, повредить общей продуктивности программирования? Может. Но в то же время быстрое решение проблем программирования с помощью просьб о помощи — одна из прекрасных возможностей улучшить продуктивность

Глава 7.  Командная работа  129

команды в целом. Поэтому вместо того, чтобы избегать прерываний, ищите способы, как сделать так, чтобы они не отвлекали. Лучший способ избежать длительного отСм. также влечения в случае прерываний — использовать парное или групповое программирование. В слуПарное программирование чае парного программирования, пока один че(глава 12) ловек отвечает на вопросы, второй может проГрупповое программирование должать размышлять над текущей задачей. (глава 12) По завершении прерывания вопрос «На чем мы остановились?» вернет процесс в прежнее русло. В случае группового программирования прерывание становится еще меньшей проблемой; как правило, оно имеет тенденцию вовсе не происходить, поскольку все работают вместе. А когда происходит, тот, кого отвлекли, просто отходит в сторону, а остальные продолжают работать. Если парное и групповое программирование См. также для вас не вариант, то вашей команде понадобится заключить рабочие соглашения относительно Согласование (глава 7) прерываний работы, требующей глубокой сосредоточенности. Один из вариантов — выбрать какой-либо показатель (например, наушники при личном общении или специальный статус в программе при виртуальном), который будет означать «пожалуйста, не отвлекайте». Но все же не забывайте, цель — повысить продуктивность команды, а не отдельных лиц.

Легко входите в дискуссии и выходите из них Общая командная комната позволяет вам тратить меньше времени на встречи. Когда вам нужно обсудить проблему с другими людьми в команде, не организуйте собрание, просто скажите на всю комнату, что вы хотите обсудить. Или встаньте и скажите чтолибо (если все находятся в одной комнате), или отправьте сообщение в групповой чат (при виртуальном общении). Затем просто начните разговаривать друг с другом. В каждое обсуждение должны вовлекаться только те, кого непосредственно касается этот вопрос, и его надо завершать сразу, когда проблема решена. Если оказывается, что в обсуждении нужен кто-то еще из команды, то попросите его присоединиться. Когда кто-то начинает разговор, вам не обязательно сразу в нем участвовать. Подслушайте, о чем речь, и решите, нужно ли что-либо от вас. Так, если оказывается, что дискуссия не имеет к вам отношения, то не нужно в ней участвовать. Вы можете вернуться к работе. Это называется «закон мобильности», или «закон двух ног» (Law of Mobility, или Law of Two Feet): «В любой момент времени, если вы не учитесь чему-то важному и не вносите какой-либо вклад в общее дело, переместитесь в то место, где вы будете это делать»1. И наоборот! Если оказывается, что обсуждение имеет к вам отношение, то присоединитесь к нему. 1

Закон мобильности, или закон двух ног, пришел из «Технологий открытого пространства» Харрисона Оуэна — прекрасного подхода к организации продуктивных дискуссий в больших группах.

130  Часть II.  Фокус на ценность В физическом помещении вежливость предписывает общаться в стороне от того места, где работают люди, которым нужна концентрация. Большинство командных комнат имеют специально отведенную отдельную зону для общения. Она находится достаточно близко к остальной команде, чтобы люди могли слышать разговор и при желании вступить в него, и при этом достаточно отделена, чтобы шум не отвлекал других участников. Виртуальные команды имеют противоположную проблему: трудно услышать разговоры других людей. Как только разговор начинается, обычно более эффективно вывести его из группового чата в формат видеоконференции. Но тогда никто не сможет услышать, о чем разговор. Поэтому рассмотрите возможность время от времени размещать обновления по текущему обсуждению в групповом чате, чтобы люди могли решить, нужно ли им вступить в него.

Создавайте визуализации В момент общения каждый его участник держит в голове собственную модель окружающего мира. И если ментальные модели слишком сильно различаются, происходит недопонимание. Чтобы это предотвратить, превратите вашу внутреннюю модель во внешнюю. Создайте визуализацию, которую каждый сможет увидеть, сравнить с собственной моделью и изменить. Подойдут рисунки на белой доске, но еще лучше — модели, которые способствуют сотрудничеству. Отлично работают индексные карточки и стикеры или их виртуальные эквиваленты. Записывайте ваши идеи на карточках и передвигайте их, чтобы наглядно представить взаимосвязи. Вы будете встречать примеры таких визуализаСм. также ций в этой книге, например визуальное планирование или практики планирования задач. Не ограничиВизуальное планирование вайтесь визуализациями, описанными здесь. Всякий (глава 8) раз, когда у вас возникает дискуссия, особенно если Планирование задач люди никак не могут понять друг друга или прийти (глава 9) к согласию, создавайте модель, которой участники смогут управлять.

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

Глава 7.  Командная работа  131

Этот вид одновременной совместной работы невероятно эффективен. Все, что нужно, — это чтобы человек, который обычно сидит за клавиатурой, отпустил контроль. И как только это происходит, обсуждения значительно ускоряются. В командах, находящихся в одном помещении, люди естественным образом разделятся на маленькие группы, чтобы обсуждать темы по интересам. Вы сделаете в два-три раза больше работы за то же время. Виртуальные группы не увидят столько же преимуществ, поскольку для них сложнее организовать обсуждение в маленьких группах. Но они все же будут эффективными. Один из моих любимых способов одновременной работы — одновременный мозговой штурм (brainstorming). Кто-то предлагает группе высказывать идеи по обсуждаемой теме, совсем как при обычном мозговом штурме. Когда кому-то приходит на ум идея, он говорит ее вслух, записывает на индексную карточку и помещает ее туда, где каждый сможет ее видеть. (Одна идея на одной карточке, чтобы облегчить последующую сортировку.) Высказывание вслух вдохновляет остальных участников на идеи, а самостоятельная запись идеи на карточку предотвращает задержки, которые неминуемы, если все записывает один человек. ПРИМЕЧАНИЕ Помните, что критиковать идеи во время мозгового штурма не нужно. И он лучше всего работает, когда состоит из двух частей: первая — генерация идей в свободной форме, где годится все; вторая — уточнение и фильтрация идей.

Иногда я провожу одновременный мозговой штурм, используя сопоставление, или картирование сходства (affinity mapping). Чтобы сделать карту сходства, возьмите все карточки, заполненные командой во время мозгового штурма, и разложите их произвольно на столе или белой доске. Затем переместите их так, чтобы наиболее похожие идеи оказались рядом друг с другом, а наименее похожие — в отдалении. Все участники работают одновременно, передвигая карточки, как только видят нужное направление. В конце концов карточки должны сформировать кластеры, которым можно дать названия. Вариантом картирования сходства является молчаливое сопоставление (mute mapping), которое представляет собой тот же процесс, но никому не разрешается разговаривать, пока перемещаются карточки. Это помогает предотвратить споры о том, куда поместить ту или иную карточку, а также приводит к забавным мимическим взаимодействиям. Еще один способ фильтрации ваших идей после мозгового штурма — точечное голосование (dot voting). Каждый имеет определенное количество голосов. (Я умножаю количество вариантов на три, а затем делю на количество участников.) Все голосуют одновременно, ставя точку на вариант, который они предпочитают. Можно голосовать за один вариант несколько раз. Например, если у вас четыре голоса, то вы можете поставить по одной точке на четыре разных варианта, четыре точки на один вариант или сделать что-то среднее. Побеждают варианты, получившие наибольшее количество голосов.

132  Часть II.  Фокус на ценность

Стремитесь к согласию Как вы поступаете, когда люди не согласны? Единоличные решения заставляют людей отстраняться. Правило большинства приводит к разочарованию тех, кто в меньшинстве. А поиск консенсуса очень долог и может зайти в тупик. Вместо всего этого используйте голосование согласием (consent vote). При таком способе голосования кто-то высказывает предложение, и затем все голосуют одним из следующих способов: «Я согласен» (большой палец вверх при личном общении, «+1» — в групповом чате), «Я вместе с группой» (большой палец в сторону или «+0») или «Я не согласен и хочу объяснить почему» (большой палец вниз или «–1»). Чтобы избежать случайного давления друг на друга, вы можете договориться, что каждый раскрывает свой вариант голосования на счет три. Если никто не выбирает вариант «Я согласен», предложение не принимается изза отсутствия интереса. И наоборот, если отсутствуют несогласные, оно проходит. Если все же кто-то не согласен, то объясняет свои возражения, и группа корректирует предложение, чтобы устранить их. Предложение не проходит, пока не устранены все возражения. Голосование согласием работает по двум причинам. Во-первых, оно дает людям возможность воздержаться от поддержки, не блокируя предложение полностью. Во-вторых, если кто-то чувствует себя достаточно сильным, чтобы наложить вето на предложение, то должен объяснить причины, что позволяет группе разрешить их сомнения.

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

Физические командные комнаты Командные комнаты могут быть физическими или виртуальными. Если есть такая возможность, то организуйте физическую комнату. Она обойдется дороже, чем виртуальная, но, несмотря на успехи технологий, личное общение все же остается наиболее эффективным способом взаимодействия команд. Бьорн Фриман-Бенсон, технологический лидер, имеющий многолетний опыт управления распределенными группами, сказал: «Наши виртуальные команды были гораздо менее креативными. Нам приходилось комплектовать команды с большей численностью персонала, чтобы получать тот же уровень креативности… Ключевой

Глава 7.  Командная работа  133

момент любого бизнеса, в котором я был, — это творческий потенциал, в удаленных командах его меньше из-за разногласий. Вы можете даже получить больше единиц работы, но тикеты Jira не оплачивают счета» [Shore2019].

Эффект коктейльной вечеринки Отчасти причина того, что физические командные комнаты более эффективны, заключается в эффекте коктейльной вечеринки, который [Cockburn2006] называет осмотической коммуникацией. Случалось ли вам разговаривать с кем-либо, стоя посреди переполненной людьми комнаты, и внезапно услышать свое имя? Даже если вы были сконцентрированы на вашей беседе, ваш мозг прислушивался ко всем остальным разговорам. Услышав ваше имя, он воспроизвел эти звуки в вашем сознании. Вы слышите не только ваше имя, но и отрывок обсуждения, в котором оно прозвучало. Представьте себе команду поставки, которая сидит вместе. Члены команды работают в парах и ведут тихие разговоры. Потом один из программистов упоминает что-то насчет управления соединением с базой данных, и другой оживляется: «О, мы с Кейли на прошлой неделе сделали рефакторинг соединений с базой данных. Больше не нужно управлять соединениями вручную». Когда членам команды удобно разговаривать таким образом, то это происходит часто (по меньшей мере раз в день) и всякий раз экономит время и деньги.

Дизайн вашей командной комнаты Сделайте такой дизайн комнаты для вашей команды, который будет способствовать взаимодействию. Поставьте прямые столы, позволяющие двум членам команды сидеть рядом и вместе работать, вместо угловых столов в форме буквы L с монитором в углу. Поставьте много белых досок и сделайте так, чтобы на стенах можно было рисовать наброски идей и размещать плакаты с диаграммами. Организуйте зону для общения с большим столом, который команда сможет использовать для раскладывания карточек и построения визуализаций, и добавьте проектор или большой монитор, если возможно, для групповых дискуссий, в которых требуется компьютер. Группируйте людей в соответствии с темами, к обсуждению которых им будет нужно прислушиваться. Обычно разработчики (программисты, тестировщики, эксплуатация и т. д.) должны сидеть рядом. Заказчикам в команде не обязательно находиться рядом, но они должны быть поблизости, чтобы при необходимости отвечать на вопросы. Кроме того, организуйте ваше рабочее пространство таким образом, чтобы минимизировать отвлекающий шум. Зона общения команды должна быть удалена от рабочих столов. Рассмотрите возможность организовать отдельную закрытую комнату, предназначенную для телефонных разговоров, особенно если в команде есть люди, которые много общаются по телефону или на видеоконференциях. И наконец, уделите внимание человеческому фактору. Людям комфортнее, когда их рабочее место освещается Уделите внимание естественным образом, там есть растения и цвета. Оставьте человеческому пространство для индивидуальности. Если у людей нет фактору. своих постоянных мест, как это обычно бывает при парном

134  Часть II.  Фокус на ценность и групповом программировании, предоставьте им место для хранения личных вещей. Добавьте книги (например, эту), чтобы их можно было просто полистать или сверить какую-либо информацию. Сделайте так, чтобы всю мебель можно было передвинуть, вместо того чтобы прикручивать ее к полу. Тогда члены команды смогут настроить свое рабочее место под свои потребности.

Множество команд Из комнат, где сидят Agile-команды, обычно доносится ровный гул голосов, перио­ дически перекрываемый возгласами торжества. Это вряд ли будет мешать членам вашей команды, но может беспокоить ваших соседей. Убедитесь, что командная комната хорошо шумоизолирована. Если командам необходимо часто сотрудничать, то разместите их рядом и дайте возможность слышать друг друга. Команды, которым взаимодействие не требуется, можно разделить, используя расстояние или шумозащитные экраны.

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

1

Глава 7.  Командная работа  135

стикеры разного цвета, размера и формы; zz карандаши, ручки и маркеры на водной основе для рисования на карточках и стикерах. Избегайте перманентных маркеров; они сильно пахнут, и к тому же кто-нибудь неизбежно испачкает ими белую доску1; zz маркеры сухого стирания для белой доски, маркеры на водной основе для флипчарта и маркеры влажного стирания для полуперманентных надписей на белой доске, а также вечный календарь. Избегайте сильно пахнущих маркеров; zz магнитные кнопки для прикрепления карточек и документов к доске; zz экземпляр этой книги и другие полезные справочные материалы. Командам, работающим в парном программировании в режиме личного общения, также понадобятся специальные рабочие станции (см. раздел «Парное программирование» главы 12): zz широкие столы, подходящие для работы бок о бок. Некоторые команды предпочитают иметь или оба варианта столов (столы для работы сидя и стоя), или столы с изменяемой высотой; zz один компьютер уровня разработки для каждой рабочей станции; zz две клавиатуры и мыши на каждой станции. Некоторые предпочитают использовать свои клавиатуры и мыши; в этом случае удостоверьтесь, что USB-порты легкодоступны, поскольку каждый компьютер будут перемещать между станциями несколько раз в день; zz не менее двух мониторов на каждой станции. Командам, работающим в групповом программировании в режиме личного общения, тоже понадобятся специальные рабочие станции (см. раздел «Групповое программирование» главы 12): zz столы, за которыми поместятся каждый член команды и несколько гостей, и пространство, достаточное для того, чтобы люди могли меняться местами; zz кресло «водителя» — с удобным доступом, мышью, клавиатурой и компьютером уровня разработки; zz кресло «штурмана» — за тем же столом, что и кресло «водителя», или достаточно близко, чтобы «водитель» и «штурман» могли беспрепятственно общаться; zz не менее одного монитора, обычно с диагональю от 60 дюймов, достаточно большого, чтобы его было видно со всех мест. Телевизоры с разрешением 4K тоже вполне пригодны для этой цели. Убедитесь, что всех все устраивает с учетом разницы в зрении. Не покупайте программное обеспечение для управления жизненным циклом Agile или другие Не покупайте программное системы отслеживания, если команда не прообеспечение для управления жизненным циклом Agile. сит именно его, и даже если просит, подождите, пока члены команды сначала наберутся опыта, zz

1

Профессиональный совет: следы от перманентного маркера на белой доске можно удалять, рисуя поверх него маркером для белой доски и немедленно стирая.

136  Часть II.  Фокус на ценность несколько месяцев работая с практиками планирования, представленными в этой книге. Больше информации можно найти в подразделе «Корпоративные системы отслеживания» главы 10.

Примеры командных помещений Схема рабочего пространства, представленная на рис. 7.1, основана на командных помещениях, которые я видел в штаб-квартире Spotify в 2015 году. Каждое помещение имело рабочую зону со множеством белых досок, зону для общения и комнату для частных разговоров, вмещающую от трех до пяти человек. За пределами помещения был широкий коридор с уютными диванами и креслами и вешалка для верхней одежды.

Рис. 7.1. План командного помещения, вдохновленный Spotify

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

Глава 7.  Командная работа  137

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

Рис. 7.2. План бюджетного командного помещения

Это было отличное пространство с одним серьезным недостатком: перегородкой между программистами и продакт-менеджером. (На рисунке я ее удалил.) В результате продакт-менеджер сидел снаружи комнаты и не мог слышать членов команды и участвовать в общих дискуссиях. Команда не получала своевременных ответов на вопросы и часто имела проблемы с требованиями по продукту.

Адаптация к физической командной комнате Многие люди могут сопротивляться переезду в общую командную комнату. Они обычно опасаются потерять индивидуальность и приватность, предполагаемого понижения статуса из-за потери собственного кабинета и того, что руководители не будут замечать индивидуального вклада. По моему опыту, большинство людей начинает получать удовольствие от преимуществ, которые дает совместная работа в одном помещении, однако на это может уйти несколько месяцев. Некоторые команды, с которыми я работал, зарезервировали для себя много индивидуального свободного места в командных комнатах, но, в конце концов, так его и не использовали. Тематическое исследование Тизли продемонстрировало похожие результаты: члены команды сначала предпочитали офисы-кабинки с перегородками, но в конце эксперимента им уже больше нравилось открытое рабочее пространство. Однако заставлять людей сидеть вместе в надежде, что им это когда-нибудь понравится, — плохая идея. Вместо этого поговорите с командой об их опасениях и компромиссах переезда в общее помещение. Обсудите, как работа членов команды будет оцениваться в среде Agile (это должно улучшить вклад команды, см. врезку «Коллективное владение» в главе 9) и как обеспечить приватность.

138  Часть II.  Фокус на ценность Один менеджер, с которым я разговаривал, организовал командную комнату, оборудовав ее рабочими станциями для парного программирования, но не требовал, чтобы члены команды использовали его. Несколько человек захотели попробовать парное программирование и перебрались в ту комнату. Со временем все больше и больше людей переходили в нее, чтобы работать с коллегами, которые уже были там. В конце концов вся команда перешла на парное программирование, без какоголибо принуждения перебравшись в общую комнату.

Виртуальные командные комнаты Если ваша команда работает удаленно, то вы можете организовать виртуальную комнату с помощью онлайн-инструментов. Это возможно и в случае гибридных и частично удаленных команд1, но будьте осторожны: люди, работающие удаленно, не смогут принять участие в личном общении. Тем, кто работает в офисе, тоже нужна виртуальная командная комната, чтобы взаимодействовать с коллегами, работающими удаленно. Решение использовать виртуальное рабочее пространство эквивалентно решению действовать так, будто все работают удаленно.

Оборудование и инструменты для удаленной работы Удаленным командам нужна электронная версия командного рабочего пространства: zz ПО для видеоконференций, такое как Zoom, для общения в реальном времени; zz ПО для обмена сообщениями (мессенджер), например Slack; zz виртуальная белая доска, например Miro или Mural, для простого взаимодействия в свободной форме; zz инструменты для конкретных задач, где это возможно, в версиях для совместного использования, такие как Figma для UX- и UI-дизайна; zz хранилище для документации, например DropBox, Google Drive или Вики; zz недорогие планшеты для использования в качестве доски, на которой можно совместно рисовать наброски; zz дополнительный монитор или планшет для видеоконференций, чтобы люди могли видеть друг друга и одновременно работать; zz для команд поставки инструменты для совместного программирования, например Tuple или Visual Studio Live Share, с поддержкой парного или группового программирования (более подробную информацию см. в разделах «Парное программирование» и «Групповое программирование» главы 12). Как и в случае офисного рабочего пространства, не покупайте ПО для управления жизненным циклом Agile или другие системы отслеживания. 1

Гибридно-удаленная команда в  одни дни работает в режиме личного общения, а в другие — в удаленном режиме. В частично удаленной команде часть людей работает в офисе, а часть — удаленно.

Глава 7.  Командная работа  139

Организация удаленного взаимодействия Взаимодействие не вызывает трудностей, когда См. также люди сидят все вместе. Достижение такого же уровня взаимодействия при удаленной работе Согласование (глава 7) требует тщательной проработки. Когда ваша команда устанавливает свои рабочие соглашения в ходе начального согласования, обязательно обсудите, как вы будете сотрудничать. Помните, что цель — максимизировать продуктивность команды, а не отдельного человека. В процессе работы не забывайте чаще оценивать и совершенствовать ваши методы общения. Я просил людей, имеющих опыт работы с офисными и удаленными командами, поделиться приемами удаленного взаимодействия1. Вот несколько отличных советов. zz Находите время для личных контактов. Команды, общающиеся лично, формируют дружеские связи и взаимное уважение, и это позволяет им принимать решения быстро и эффективно. Виртуальным командам будет полезно выделять время на общение и интересоваться жизнью друг друга. Примеры — виртуальные перерывы на кофе, которые помогают снизить напряженность в общении; отдельные чаты и каналы для приветствий по приходе и выходе из офиса и личных сообщений; а также 30-минутные ежедневные звонки для неформального общения или игр. Одна из команд выработала привычку выделять первые 5–10 минут каждой встречи на неформальное общение; люди могли либо приходить пораньше и общаться, либо приходить позже, непосредственно к деловой части встречи, по настроению. Другая команда специально выделяла время для празднования успехов. zz Обеспечьте безопасность. В командах, общающихся лично, люди могут шутить и быть самими собой, не опасаясь, что кто-то когда-либо припомнит им это. В виртуальной среде все может быть записано. Установите четкие рекомендации о том, когда можно записывать разговор и распространять запись. Еще один способ создать атмосферу безопасности — открыть приватный канал в вашем групповом чате, доступный только команде. zz Сделайте неявное явным. При личном общении многие социальные сигналы подаются с помощью малозаметных изменений выражения лица и языка тела. При виртуальном общении эти сигналы обычно не видны. Поэтому сделайте их явными. Например, один человек сделал индексные карточки, которые он держал во время видеозвонков. На них было написано «+1», «Обеспокоен», «+1 000 000» и «Да-а-а-а! Сделаем это!» (Пусть это будет весело!) Кроме того, демонстрируйте, что вы доступны для общения. Ставьте в групповом чате статус, оповещающий о том, где вы, что делаете и открыты ли для разговора. zz Обновите вашу среду общения. Низкоскоростная связь (например, текстовый чат) пригодна для коротких обменов информацией, но может приводить к длинным и долгим перепискам, когда надо обсудить значимые вопросы. Если вы заметили, Спасибо Дэйву Пулу, Габриель Хокнесс, Александру Берду, Крису Фентону, Брайану Шефу и Дэйву Руни за то, что поделились своими приемами в Twitter (https://oreil.ly/vwWli). Кроме того, спасибо Бренту Миллеру, Дэннису Макмиллану, Сету Маккарти, Джеффу Олферту, Матту Плавкану за их советы.

1

140  Часть II.  Фокус на ценность

zz

zz

zz

zz

что это происходит, переключитесь на более скоростные варианты связи. Например, одна команда установила стандарт, предусматривающий переход на видео, если тему в групповом чате команды обсуждали больше двух человек. Используйте функции одновременного общения в параллельных группах. Когда группы одновременно работают над визуализацией, они часто разделяются на дискуссионные группы численностью два-три человека. Придумайте, как организовать нечто подобное с помощью ваших программных инструментов. В ПО для видеоконференций можно открывать комнаты отдыха, а приложения для групповых чатов поддерживают создание отдельных каналов и чатов. Создайте «стену». В офисе информация, которую необходимо узнать или помнить, вывешивается на стене. Для виртуальных команд можно создать небольшое количество общих документов, в которых будет храниться та же информация. Купите планшеты. Стоят они не очень дорого, а рисовать диаграммы на планшете гораздо удобнее, чем с помощью мыши или сенсорной панели. Раздайте планшеты всем членам вашей команды и держите их подключенными к вашей виртуальной белой доске. Когда вам понадобится зарисовать что-то во время обсуждения, планшеты будут наготове. Учитывайте разницу в доступе к Интернету. Он у всех разный. Расстояние всего в 10 миль может означать переход от широкополосного городского доступа к неравномерному сельскому покрытию, не говоря уже о разнице между странами. Обсудите потребности людей и выберите коммуникационные стратегии, подходящие каждому.

Младшие члены команды Бьерн Фриман-Бенсон описывает проблему младших членов команды (джуниоров) как один из трех вызовов распределенных команд: У начинающих разработчиков очень много вопросов. Они не знают, как делать свою работу. И в то же время они находятся на низшей ступени иерархии. Они не решаются перебивать и не хотят выглядеть обузой. В InVision [где Бьерн был техническим директором], все команды которой были полностью удаленными, джуниор-разработчики не могли видеть, что делают все остальные. Они боялись прервать других. «Они замирали и тянули время, — говорил Бьерн, — до самого последнего момента, пока их напрямую не спрашивали, чем они заняты» [Shore2019]. Бьерн Фриман-Бенсон. Три проблемы распределенных команд

Организуйте способы, которые позволят младшим членам команды догнать остальных, не чувствуя себя потерянными и мешающими другим. Парное и групповое программирование — отличные техники. Если они не подходят

См. также Парное программирование (глава 12) Групповое программирование (глава 12)

Глава 7.  Командная работа  141

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

Вопросы В физической комнате моей команды слишком шумно, я не могу сосредоточиться. Что мне делать? Иногда команда становится чрезмерно шумной и непоседливой. И это нормально — попросить вести См. также себя потише. Когда вы обсуждаете рабочие соглашеСогласование (глава 7) ния при начальном согласовании, поговорите о том, как удовлетворить пожелания каждого. Если этого Ретроспективы (глава 11) будет недостаточно, поднимайте этот вопрос также во время ретроспектив. Помните, что парное программирование — отличный способ отвлечь ваше внимание от фонового шума. Вы просто не заметите этот шум, разговаривая с вашим партнером. Точно так же эта проблема не свойственна и групповому программированию за счет фокусировки общего внимания на одной общей теме. Когда начинается разговор, вся команда перестает делать то, что делала, и начинает слушать. Что мы можем сделать, чтобы люди перестали так легко отвлекаться? Возможно, всей команде действительно нужно слышать эти разговоры, особенно в самом начале. Это помогает установить контакт и привести всех к общему пониманию. Со временем команды разберутся, какие разговоры можно с легкостью игнорировать. Если проблема продолжается, особенно в физической рабочей комнате, то попробуйте отходить немного подальше от остальных коллег, когда начинается разговор. Заинтересованные члены команды сами присоединятся к обсуждению, в то время как остальная команда продолжит работу.

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

142  Часть II.  Фокус на ценность в общей комнате. Многие люди могут тяжело воспринимать изменение рабочего пространства. Если их вынуждают перейти на новый порядок против их воли, то они, вероятно, найдут способ уйти из команды, даже если это равнозначно уходу из компании. Больше информации о том, как заручиться поддержкой, доступно См. также в главе 5. Если ваша команда не использует Парное программирование (глава 12) парное или групповое программироваГрупповое программирование (глава 12) ние, то уделите внимание организации рабочего пространства и рабочих соСогласование (глава 7) глашений, чтобы минимизировать шум и отвлекающие факторы.

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

Альтернативы и эксперименты Эта практика предназначена для беспрепятственного общения, и неважно, есть у вас буквально командная комната или нет. Но если у вас нет опыта непринужденного взаимодействия в пространстве такой комнаты (особенно физической), то попробуйте подобное общение в течение нескольких месяцев, прежде чем перейти к экспериментам с альтернативами. Трудно оценить, насколько это эффективно, пока не увидишь своими глазами. Группповое программирование еще См. также больше расширяет возможности сотрудничества, поскольку все члены команды Групповое программирование (глава 12) работают за одним компьютером. Возможно, это звучит странно, но в некотором смысле это «простой режим» совместной работы. Он особенно эффективен для команд, работающих удаленно, которым иначе пришлось бы очень постараться, прежде чем они добились бы той же эффективности, что и команды, работающие в офисе. Пожалуй, помимо группового программирования, больше ничто не приближается по эффективности к центральной идее общего рабочего пространства. Экспериментировать можно с деталями. Как вы можете улучшить общение? Можно ли

Глава 7.  Командная работа  143

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

Литература для дополнительного чтения В книге Agile Software Development [Cockburn2006] есть отличная глава, посвященная общению. В главе 3 Communicating, Cooperating Teams обсуждаются источники информации, качество коммуникации и множество других концепций, связанных с использованием общих командных комнат. The Remote Facilitator’s Pocket Guide [Clacey2020] содержит краткий и полезный материал о фасилитации. Книга в большей степени ориентирована на удаленные сессии, но советы, представленные в ней, будут ценны и для людей, работающих в формате личного общения.

БЕЗОПАСНОСТЬ

Аудитория

Гитте Клитгаард Мы без страха делимся противоречивыми точками зрения.

Вся команда

В 2012 году Google запустил проект «Аристотель» — внутреннее исследование, призванное определить, почему одни команды достигали успеха, а другие нет. Google учитывал несколько факторов: состав команды, общение вне работы, образование, являются ли члены команды экстравертами или интровертами, работают в офисе или удаленно, трудовой стаж, численность команды, индивидуальная продуктивность и др. Ничто из перечисленного не оказывало значительного влияния на эффективность, даже стаж и индивидуальная продуктивность. А что имело значение? Психологическая безопасность. Из пяти ключевых показателей динамики эффективных команд, обнаруженных исследователями, психологическая безопасность была, безусловно, самой важной. Исследователи Google обнаружили, что люди в команде, имеющей более высокую психологическую безопасность, с меньшей вероятностью уходили из компании, с большей вероятностью использовали потенциал разнообразных идей своих коллег, приносили больший доход и оценивались как эффективные высшим руководством в два раза чаще [Google2021]. Понятие командной эффективности

Выводы Google сделали психологическую безопасность центром внимания, однако это не новая идея. Она была введена в 1965 году Эдгаром Шейном и Уорреном

144  Часть II.  Фокус на ценность Беннисом в контексте проведения личных и организационных изменений. «Для того чтобы дискомфорт приводил к усилению желания учиться вместо усиления беспокойства… должна быть создана среда с максимальной психологической безопасностью» [Schein 1965, р. 44].

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

Как создать атмосферу безопасности Чувство безопасности очень индивидуально. Оно нематериально и зависит от контекста. Обмен информацией, безопасный для одних участников, может казаться небезопасным для других. Например, вы начинаете разговор с легкой светской беседы наподобие: «Чем вы занимались в выходные?» Один человек уверенно отвечает: «Я ходил в горы с женой». Другому не очень хочется отвечать. Он провел выходные со своим бойфрендом и беспокоится, что если поднимет эту тему, то пойдут неприятные разговоры о его сексуальной ориентации. Прежний опыт — тоже важный фактор. Я (Гитте) работала с 60-летним человеком, который всегда избегал упоминания пола своего мужа. Он говорил «мой партнер» вместо «мой муж» и никогда не использовал местоимения. Разумом этот человек понимал, что тема его отношений не вызывает у меня дискомфорта, и я никогда не обращалась с ним плохо, но он вырос в то время, когда быть геем было наказуемо, и инстинктивно старался себя защитить. Первая половина этого определения психологической безопасности («возможность быть собой») основывается на [Kahn1990]. Вторая половина («возможность выдвигать идеи») — на [Edmonson2014].

1

Глава 7.  Командная работа  145

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

Дать возможность высказаться всем Одно из больших преимуществ безопасности — то, что она дает возможность высказаться каждому. Чувствуя себя в безопасности, члены команды озвучивают свое мнение, не соглашаются, предлагают новые идеи, поднимают проблемы и в целом открывают возможности. Это не значит, что все идеи претворяются в жизнь. Это значит, что ваша команда рассмотрела больше вариантов, прежде чем приняла решение, — вариантов, которые вы иначе бы не увидели. Даже если люди чувствуют себя настолько безопасно, чтобы высказаться, некоторые от природы застенчивы, испытывают социальную тревожность или им просто некомфортно высказываться в группе. Вы можете облегчить им задачу, приняв эти особенности во внимание. Один из способов — начинать каждое собрание с краткого вступления. Оно может быть совсем небольшим, например: «Выразите одним словом ваше настроение сегодня» или «Расскажите, какая погода сегодня за вашим окном». Когда человек один раз уже сказал что-либо на собрании, ему легче заговорить еще раз позже. Кроме того, дайте возможность пропустить участие. Это покажет всем, что не высказываться тоже безопасно. Еще один способ — разделить большую дискуссию по маленьким группам в 2–4 человека. Один человек из каждой группы может поделиться выводами, сделанными группой, с остальными. Это даст возможность учесть мнения тех, кому некомфортно высказываться в условиях большой группы.

Открыто говорите об ошибках Когда мы совершаем ошибку, легко начать себя защищать, особенно если мы допустили оплошность. Сопротивляйтесь желанию проигнорировать или прикрыть свои ошибки. Вместо этого признайте их. Вы покажете остальным, что для них тоже безопасно признавать свои ошибки. У Мэтта Смита есть техника, называющаяся «Поклон неудачи» (the failure bow) [Smith2012]. Лучше всего она работает, когда становится общей нормой в команде. Когда вы сделаете ошибку, встаньте, вытяните руки высоко вверх. «Я ошибся!» — скажите это, широко улыбаясь. Остальные тоже начнут улыбаться и, может быть, даже аплодировать. Превратите ошибку во что-то смешное. Это ее обезвредит. Некоторым трудно признавать ошибки. Человек может винить себя в ошибке, думать, что команда будет его ненавидеть и его уволят. Я и сама так думала, когда исцелялась от перфекционизма.

146  Часть II.  Фокус на ценность Другими словами, вы можете создать среду, в которой безопасно говорить о своих ошибках, однако кто-то все же может бояться их совершать. Дайте людям свободу делиться (или не делиться) этим с другими наиболее удобным для них способом.

Будьте любознательны Демонстрируйте неподдельный интерес к чужому мнению. Если кто-то молчит и не очень хочет говорить, то спросите его, что он думает. Это даст понять, что его голос ценен. Но имейте в виду, что такому человеку может быть некомфортно, если к нему обратятся в присутствии большого количества людей. Если сомневаетесь, то перенесите обсуждение в меньшую группу — возможно, даже с глазу на глаз. Слушайте, чтобы понять, а не чтобы ответить. Слушайте, чтобы понять, Очень легко начать концентрироваться на том, а не чтобы ответить. что вы хотите сказать в ответ, вместо того чтобы слушать, что говорит другой человек. Если у вас уже наготове ваш следующий вопрос или заявление, значит, вы слушаете, чтобы ответить. Вместо этого сосредоточьтесь на том, что вам говорят или пытаются передать.

Научитесь давать и получать обратную связь В эффективной команде разногласия и противоречивые мнения — это не только нормально, но и ожидаемо. Именно так возникают лучшие идеи. Сделайте разногласия безопасными, сосредоточившись на предметах и идеях, а не на людях, их предлагающих. Используйте старый прием импровизации: каждый раз говорите «да, и…», чтобы развить чужую идею. Например, если кто-то предлагает поправки в коде, но не учел вопрос обработки ошибок, не говорите: «Ты забыл добавить обработку ошибок». Это перемещает фокус на человека и на то, что он забыл сделать. Вместо этого сфокусируйтесь на идее и развивайте ее: «Куда мы добавим обработку ошибок?» Или: «Давайте добавим сюда обработку ошибок». Некоторые разногласия могут носить личный характер. Например, кто-то может неудачно и довольно бесчувственно пошутить. Диана Ларсен предлагает следующий процесс обратной связи по межличностным вопросам. 1. Создайте открытость. Попросите разрешения дать обратную связь: «Жоржетта, могу я поговорить с тобой о том, что ты сказала сегодня во время стендапмитинга?» 2. Опишите поведение. Будьте конкретны насчет того, что случилось: «Сегодня во время стендап-митинга ты пошутила, что люди низкого роста не ходят на свидания. Это была твоя третья шутка на эту тему на текущей неделе». 3. Заявите о последствиях. Опишите, как это повлияло на вас: «Тема моего роста для меня чувствительна, и, хотя я и посмеялся, у меня все утро было плохое настроение». 4. Сформулируйте запрос. Объясните, что бы вы хотели изменить, поощрить или предотвратить: «Я бы хотел, чтобы ты перестала шутить на эту тему».

Глава 7.  Командная работа  147

5. Выслушайте ответ. Другой человек ответит. Выслушайте, чтобы понять, и дайте ему закончить мысль. 6. Обсудите следующие шаги. Сосредоточьтесь на том, что вы оба можете сделать, с учетом выстраивания отношений в дальнейшем. «Мне нравится твое чувство юмора, и я надеюсь, ты будешь продолжать шутить на другие темы. Я работаю над тем, чтобы быть менее чувствительным к этому вопросу, но это непросто. Я ценю то, что ты согласна сделать это для меня». Давайте обратную связь, чтобы поощрить поведение, которое вы хотите видеть, а также чтобы исправить поведение, которое вы хотите изменить. Людям может понадобиться несколько дней, чтобы переварить обратную связь, особенно если это что-то серьезное. Не ждите ответа сразу. Многим также трудно получать положительную обратную связь. Мне самой понадобилось несколько лет сознательных тренировок, прежде чем я научилась с благодарностью принимать положительную обратную связь, и у меня до сих пор бывают с этим проблемы в плохие дни. Получать личную обратную связь может быть особенно некомфортно, если вы сделали что-то, что задело чувства другого человека. Когда такое случается, не занимайте оборонительную позицию и не преуменьшайте опасения другого человека. Не извиняйтесь в манере: «Мне жаль, что ты почувствовал себя обиженным». Вместо этого признайте свою ошибку и попытайтесь загладить вину: «Я не хотел обидеть тебя своими шутками, но обидел. Я прошу прощения. Впредь я буду избегать подобных шуток. Пожалуйста, напомни мне, если я снова сделаю так». Подумайте над заключением рабочего соглашения о том, как давать и получать личную обратную связь. Некоторые советы можно найти в пункте «Разумные конфликты с обратной связью» главы 11.

Используйте эмпатию Люди подвержены фундаментальной ошибке атрибуции: мы склонны думать, что люди делают что-то из-за своих личных качеств, а не из-за ситуации, в которой оказались. Например, если мы подрезали кого-то на шоссе, это потому, что мы чуть не проскочили свой поворот. Если нас подрезал кто-то другой, это потому, что он плохой водитель и не уважает других. Когда вы не согласны с кем-то, поставьте Когда вы не согласны с кем-то, себя на его место. Вместо того чтобы подопредположите, что у него добрые зревать злонамеренность или некомпетентнамерения. ность, предположите добрые намерения: человек такой же умный и имеет благие намерения, как и вы, просто пришел к другому выводу. Попробуйте понять его позицию и причины, по которым его вывод отличается от вашего. Вы можете развить в себе эмпатию, разыгрывая разногласие по ролям постфактум. Попросите кого-нибудь послушать, как вы будете объяснять это разногласие. Объясните с вашей точки зрения, а потом с точки зрения оппонента. Приведите лучший, наиболее разумный аргумент для его позиции. Agile Conversations [Squirrel2020] — отличный ресурс, который позволит начать понимать последствия разговоров и научиться быть более эффективными.

148  Часть II.  Фокус на ценность

Позвольте себе быть уязвимым Делитесь личным и позволяйте людям видеть ваши уязвимости. Можно начать с малого: хобби, любимая игрушка в детстве или домашнее животное. Это укрепляет отношения и доверие. Со временем, когда вы дорастете до того, чтобы доверять вашим товарищам по команде, вы можете открыться еще больше. Люди приходят на работу вместе со всей своей индивидуальностью. Другими словами, то, что происходит дома, влияет на нас и на работе, так же как и все остальное, что делает нас такими, какие мы есть. Проводя вместе и хорошие, и плохие дни, люди начинают понимать настроение друг друга, что создает безопасность. Например, если вы не выспались, то можете быть ворчливым. Если вы поделитесь с окружающими этой информацией, то поможете им понять, что это не они вас раздражают… вы просто сегодня ворчливы. В 2007 году я проходила обследование на рак матки. Я паниковала и плакала и рассказала об этом в своей команде. Это было очень некомфортно, но безопасно. Когда пришло время идти к врачу на обследование, трое из моей команды позвонили мне, чтобы убедиться, что меня есть кому проводить на прием. Они знали, что я живу одна, и поддерживали меня. Это было чудесное ощущение. (В конечном счете пришли отрицательные результаты анализа — рака не было.)

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

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

Глава 7.  Командная работа  149

Моделирование поведения, которое вы хотели бы видеть Демонстрируйте поведение, которое хотели бы видеть у остальных членов вашей команды. Поощряйте высказывание мнений, будьте открытыми касательно ваших ошибок, любознательными, давайте обратную связь, проявляйте эмпатию и позволяйте себе быть уязвимым. Недостаточно говорить людям, что они в безопасности, или считать так. Демонстрируйте это. При обсуждении ошибок старайтесь не винить других и не брать вину на себя. Не говорите что-то наподобие: «Ах, я совершил ошибку, я такой глупый». Такое высказывание формирует мысль, что ошибки — это глупость. Вместо этого придайте своему сообщению такую форму, что работа — это процесс обучения, где ошибки ожидаемы, и обучение — часть результата: «Я ошибся, и вот чему меня это научило».

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

Не уклоняйтесь от конфликта Безопасность не означает, что люди всегда полуБезопасность не означает, чают то, чего хотят. Она подразумевает, что все что люди всегда получают то, мнения принимаются во внимание. чего хотят. Пытаясь создать ощущение безопасности, некоторые команды вместо этого создают ложную гармонию. Они начинают избегать конфликтов и подавлять инакомыслие. Это может казаться безопасным, но конфликт никуда не уйдет и будет лишь подспудно расти. Некоторые лидеры совершают ошибку, поощряя позитивность в своих командах. Они говорят что-то вроде «не будь таким негативным» или «будь командным игроком» — подразумевая «иди вместе со всей командой». Таким образом, люди понимают, что высказывать свое мнение небезопасно. Вместо этого, если вы заметили, что люди подавляют свое мнение, попросите их поделиться. Если кажется, что люди потакают ложной гармонии, то спросите их, какие негативные стороны они видят в какой-либо идее. Если вы видите проблему, которую никто другой не упомянул, то вынесите ее на обсуждение, но в доброжелательной манере. В то же время будьте готовы ошибаться. Концентрируйтесь не на том, чтобы быть всегда правым, а на том, чтобы вынести все мнения на открытое обсуждение, в ходе которого можно их обдумать, оспорить и улучшить. Ложная гармония и групповое мышление — обычные проблемы команд, находящихся на См. также стадии развития, называемой нормализацией. Динамики команды (глава 11) Больше информации об этом вы найдете в пункте «Стадия нормализации: мы — № 1» главы 11.

150  Часть II.  Фокус на ценность

Упражнение на построение взаимоотношений в команде Это забавное упражнение вы можете использовать для налаживания взаимопонимания в вашей команде. Оно хорошо работает как самостоятельное упражнение, а также может быть частью вашей начальной сессии согласования при разработке устава проекта (см. раздел «Согласование» далее в этой главе). Цель этого упражнения — показать членам команды, что у них гораздо больше общего, чем им кажется. Если вы работаете в общем помещении, то найдите в офисе большое открытое пространство, в котором можно свободно передвигаться. Если команда работает удаленно, то попросите каждого загрузить свое фото на общую виртуальную белую доску. (Готовьтесь, это будет весело!) Затем, когда будете готовы, повторяйте шаги, указанные ниже. 1. Один человек делает заявление о себе: «Я люблю собак». 2. Каждый, кто согласен с этим заявлением, подходит и становится рядом с этим человеком. Удаленные команды передвигают свое фото. 3. Следующий человек делает свое заявление: «Мой любимый язык программирования — Perl». И т. д. Продолжайте, пока время не истечет. Люди могут поделиться всем, чем захотят, многим или немногим.

Вопросы Что бы я ни делал, один из членов команды не хочет высказываться. Как я могу ему помочь? Как и со многими командными вопросами, лучшее, что можно сделать для начала, — это слушать. Поговорите с этим человеком, почему он не хочет высказываться. Подчеркните, что это не проблема, которую должен решить он. Это проблема команды. Вы хотите, чтобы ему стало легче вносить свой вклад в общее дело. Когда будете обсуждать возможности, имейте в виду, что хотя вы и хотите, чтобы его голос был услышан, это вовсе не обязательно должен быть именно голос. Некоторым людям удобнее излагать свои мысли в письменном виде, чем делиться ими спонтанно. Еще один вариант для такого человека — проговорить свои идеи с приятелем в команде. Это позволит заранее отрепетировать то, что он хочет сказать, или он может попросить приятеля представить его точку зрения. Я видел кое-что и знаю, что это повлияло на одного человека. Но меня беспокоит, что он не чувствует себя в достаточной безопасности, чтобы рассказать об этом. Что мне делать? Это зависит от сложности ситуации и от того, чувствуете ли вы себя в достаточной безопасности, чтобы действовать самостоятельно. В большинстве случаев можно начать с разговора с пострадавшим. Спросите, все ли у него нормально и не хочет ли он обсудить это. Если можете, то предложите поднять этот вопрос от его имени. Даже если вы не сможете это сделать, ваше предложение поможет человеку понять, что его замечают и кому-то не все равно.

Глава 7.  Командная работа  151

Если я чувствую, что какое-то событие выходит за рамки, то выскажусь на месте. Например, представьте, что Вон что-то сказал на собрании, но его проигнорировали. Обычно я обсудила бы это с Вон после встречи. Но позже на другом собрании Макс повторил то, что сказал Вон, и на этот раз все услышали. Здесь я вмешаюсь. У меня есть стандартная фраза для таких ситуаций: «Макс, мне понравилось, как ты перефразировал то, что до этого сказал Вон». Разве мы не проведем время с большей пользой, занимаясь своей работой, а не обсуждая свои чувства? Простые повторяющиеся задачи могут не требовать безопасности, но разработка ПО требует творчества, обучения и мыслительного процесса. Чтобы достичь наилучших результатов, вашей команде нужны все умы и мнения. Атмосфера небезопасности приведет к тому, что вы потеряете часть идей, люди будут неохотно указывать на ошибки, а возможности будут упускаться из-за предполагаемого риска. Вспомните выводы проекта «Аристотель». Безопасность была показателем номер один производительности команд Google. И даже если это не так, работа — огромная часть нашей жизни. Разве вы не хотите, чтобы она проходила в обстановке, в которой вы и ваши коллеги могут выражать себя без страха?

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

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

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

152  Часть II.  Фокус на ценность Альтернатива является попыткой изменить людей, а не окружающую среду. Теоретически вы можете поработать над развитием их смелости, чтобы им было комфортно высказываться, даже если они не чувствуют себя в безопасности. Но я не рекомендую этот подход. Люди могут измениться только сами, вы не можете сделать это за них. Даже если они найдут в себе смелость высказаться, не чувствуя себя в безопасности, страх будет снижать их креативность. В то же время эксперимент — отличный способ повысить безопасность. Будьте конкретны насчет экспериментов, которые проводите: даже планирование эксперимента с четкой датой окончания может создать ощущение безопасности, поскольку люди будут знать, что изменения можно отменить, если результат будет нерабочим. Создайте культуру проверки новых идей как в отношении безопасности, так и в целом внутри своей команды. Один из способов начать — проводить ретроспективы на тему безопасности. Обсудите, что См. также вы заметили в отношении безопасности в своей Ретроспективы (глава 11) команде и в других, и выберите несколько экспериментов, которые можно провети.

Литература для дополнительного чтения The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation and Growth1 [Edmonson2018] — новая книга Эми Эдмонсон, профессора Гарвардской школы бизнеса. Это хорошая книга о многих аспектах психологической безопасности, которую исследовала автор. Building a Psychologically Safe Workplace [Edmonson2014] — выступление Эми Эдмонсон на TEDx; легкое, быстрое погружение в тему. Time to Think: Listening to Ignite the Human Mind [Kline2015] посвящена тому, как создать пространство и время для размышлений на работе. Книга содержит практические советы, которые я использую на большинстве встреч.

ЦЕЛЬ Мы понимаем, ради чего работаем.

Аудитория Продакт-менеджеры, коучи

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

1

Глава 7.  Командная работа  153

В практике «Цель» объясняется, как сделать так, чтобы каждый понимал общую картину, а не только детали.

Начните с ви́дения Прежде чем у продукта появляется команда, у кого-то в компании рождается идея. Предположим, это некто в компании Wizzle-Frobitz (выдуманное название). «Эй! — восклицает он (или она), в порыве воодушевления смахивая свой кофе со стола. — Мы могли бы frobitz наши wizzle намного лучше, если бы у нас было ПО, которое сначала сортировало бы wizzle!» Как правило, обычно это происходит не так драматично. Основная мысль в том, что цель команды начинается как идея, ориентированная на результат. Продавать больше «железа», комплектуя его лучшим ПО. Привлекать более крупных заказчиков, более эффективно масштабируя. Продавать больше облачных сервисов, предоставляя технологию машинного обучения. Это все реальные примеры команд, с которыми я работал. Где-то в процессе перехода от идеи к команде часто теряется важная часть — ви́де­ ние лучшего будущего. Его загораживают детали. Вам нужно укомплектовать команду программистами, экспертами в предметной области и UX-дизайнерами. Вам нужно определиться с функциональностью, запланировать релизы и отчитываться о прогрессе. Быстрее, народ, поторапливайтесь! И это позор, поскольку нет ничего важнее, чем Нет ничего важнее, чем предоставить ви́дение. Если цель — продать больпредоставить ви́дение. ше облачных сервисов с помощью машинного обучения, то даже самый лучший продукт машинного обучения недостаточно хорош, если он не является частью облачной платформы. Если вы производите масштабирование с целью привлечь более крупного заказчика, то вам нужно убедиться, что выбранный вами способ масштабирования подходит для его потребностей. И наоборот, если вы ищете способ привлечь заказчиков, для которых вряд ли вообще требуется масштабирование, то какая разница, как вы его сделали?

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

154  Часть II.  Фокус на ценность в практике «Вся команда» главы 7, нужные См. также для этого навыки называются менеджментом продукта, и как минимум один человек с таВся команда (глава 7) кими навыками должен быть частью вашей команды. Если есть один визионер, то будет лучше, если он станет менеджером по продукту. Пока ви́дение ценно и достижимо, ежедневная вовлеченность его создателя в качестве менеджера значительно увеличит шансы команды поставить впечатляющий продукт. Если визионер не может участвовать поСм. также стоянно, как это часто бывает, то продактменеджером должен выступать кто-то еще. Вовлечение реального заказчика Постарайтесь заполучить кого-то, кто макси(глава 8) мально близок к ключевым стейкхолдерам. Как в детской игре в испорченный телефон, каждый дополнительный шаг между продакт-менеджером и ключевыми стейк­ холдерами снижает способность этих людей поддерживать и продвигать цель команды. В некоторых случаях у команды может быть несколько целей. Если концепции ключевых стейкхолдеров сильно различаются и их все нужно воплотить, то вы можете создать цель для каждого стейкхолдера. Работайте над одной из них в каждый момент времени, периодически переключаясь между ними.

Разработка несколькими командами Если ваша команда — часть горизонтально масштабированной группы команд (см. главу 6), то цель вашей команды будет отличаться от общей цели продукта или портфеля продуктов. Она будет связана с общей целью, но сосредоточена на специфической роли вашей команды. Например, ваша компания создает продукт для анализа информации о рейсах авиакомпании. Ваша команда отвечает за получение полетной информации от авиакомпании. Другая команда отвечает за карты аэропортов и направления. Третья — за уведомления о вылетах и прилетах. В этом случае общая концепция продукта может выглядеть как «мы предоставляем достоверную статистику с точностью до минут и информацию для авиапутешествий по всему миру». Но у вас как у команды, отвечающей за прием данных, вашей концепцией будет «мы предоставляем другим командам нашей компании данные, с помощью которых они могут своевременно и точно обслуживать своих заказчиков». Для вертикально масштабированных команд в этом нет необходимости. Они работают все вместе над общей целью.

Глава 7.  Командная работа  155

Задокументируйте цель Продакт-менеджеры в процессе обсуждений с  ключевыми стейкхолдерами Задача обсуждений — согласовать работу команды. и спонсором уточняют идеи и собирают их в проект документа о цели. Задача обсуждений — согласовать, над чем команда должна работать, почему она работает над этим и как выглядит успех. Это общее понимание отражается в вашем документе о цели. Вы будете его регулярно пересматривать и обновлять. Проект документа о цели — первый примерный набросок в документировании этого обсуждения. Он используется для того, чтобы развивать дискуссию. Формат документа зависит от стандартов вашей компании. Некоторые компании любят использовать ключевые показатели эффективности (Key Performance Indicators, KPIs) или подход OKR (Objectives and Key Results — цели и основные результаты). Каким бы ни был формат, вам в конечном итоге нужно ответить на три вопроса. 1. Ви́дение. Почему работа команды ценная? Опишите, как мир (или, по крайней мере, его маленькая часть) изменится, когда команда добьется успеха. Поясните, почему это важно для компании и ее заказчиков. Думайте о долгосрочной перспективе и сосредоточьтесь на ценности. 2. Миссия. Как команда может реализовать концепцию в следующие 3–6 месяцев? Опишите, что, по ожиданиям, команда должна выполнить и что лежит за пределами объема работ, но на высоком уровне. Оставьте больше пространства команде для проработки деталей. Сосредоточьтесь на итогах и ценности до результатов. Может быть полезным сначала подумать о конкретных результатах, но двигаться в обратном направлении, то есть начать с «почему», а не «что». 3. Показатели. Как члены команды узнают, что они на верном пути? Опишите до пяти кратких показателей успеха. Будьте конкретны и недвусмысленны. Избегайте разговоров о конкретных функциональностях (например, «поставить функцио­ нальность Х к дате Y»). Вместо этого пишите о коммерческих результатах, которых ожидают стейкхолдеры. Объясните, как понять по показателю, что ценность миссии была достигнута. Если это трудно сделать, то, вполне возможно, ваша миссия не сфокусирована на ценности. Документ о цели — это ориентир, а не Документ о цели описывает набор четких и жестких правил. Это способ механизм сотрудничества, помочь людям понять, чего команда пытаа не является контрактом. ется достичь. Таким образом, он отражает понимание ситуации на сегодняшний день. Если показатели не достигнуты, это не означает, что команду надо наказать. Если достигнуты, это не значит, что все перестают работать. Вспомните Манифест Agile: «Сотрудничество с заказчиком важнее согласования условий контракта». Документ о цели описывает механизм сотрудничества, а не является контрактом. В процессе работы и по мере накопления командой знаний о рынке цели будут меняться.

156  Часть II.  Фокус на ценность

Пример цели Ви́дение: команда «Снежный человек» помогает другим командам взаимодействовать на дальних расстояниях. Наши заказчики добиваются того же высокого уровня взаимодействия в случаях, когда команды сидят в одном рабочем помещении. Используя обычные инструменты для демонстрации экрана, человек становится узким местом для всего обсуждения. Наши инструменты позволяют участвовать каждому. Это превращает взаимодействие на расстоянии в эффективное и приятное занятие, в то же время давая нам возможность зарабатывать на оплате подписки лояльными клиентами. (Обратите внимание, ви́дение фокусируется на ценности в долгосрочной перспективе.) Миссия: наша первая миссия — создание инфоповода. Наша цель на данный момент — не в создании постоянного дохода, а в том, чтобы доказать жизнеспособность идеи и привлечь внимание к нашему уникальному взгляду на удаленное сотрудничество. Мы будем это делать, создавая инструмент для одновременной работы, повторяющей принцип работы с индексными карточками на столе. Это не инструмент продакт-менеджмента, не инструмент для отслеживания или проведения ретроспектив. Это «песочница» свободной формы, способная выполнять любую из этих задач. Она сфокусирована на взаимодействии и простоте. Она выделяется своим качеством. Она не предоставляет возможности для чата или видеоконференции, но по-прежнему сфокусирована на базовой функции «песочницы» для одновременного сотрудничества. (Обратите внимание, что миссия начинается с ценности, затем переходит к деталям конечного продукта.) Показатели 1. Мы представим первый макет и план для как минимум 20 потенциальных заказчиков. Мы будем считать, что достигли успеха, если 70 % из них скажут, что это решает их проблемы с взаимодействием. Так мы узнаем, является ли наш подход жизнеспособным. 2. Мы проведем демонстрацию ранней версии на стенде во время отраслевого мероприятия. Мы будем считать, что достигли успеха, если минимум 100 чело­ век остановятся и проявят интерес и по меньшей мере 50 подпишутся на бета-версию. Это будет означать, что люди заинтересованы в продукте. 3. Выпустив открытую бета-версию, мы будем считать, что достигли успеха, если минимум 500 команд подпишутся на нее за первый месяц. Это будет означать, что люди заинтересованы в продукте. 4. Через четыре месяца после запуска бета-версии продукта мы будем считать, что достигли успеха, если минимум 100 команд будут оплачивать продукт и пользоваться им регулярно, что будет определяться как минимум одной авторизацией и изменением в течение каждых двух недель. Это будет означать, что продукт полезен в реальной жизни. (Обратите внимание, что каждый показатель описывает, как он соотносится с целью. Существует множество способов, позволяющих команде оценивать свой прогресс уже на раннем этапе.)

Глава 7.  Командная работа  157

Внесите цель в свой устав Создав проект документа c предварительным описанием цели и утвердив его с вашими ключевыми стейкхолдерами, вы готовы обсудить его с остальными членами команды. Обычно это происходит во время сессии подготовки устава1, также называемой взлет, после одноименной книги [Larsen2016]. Подробная информация о том, как спланировать эту сессию, представлена во врезке «Планирование сессии подготовки устава» далее в текущей главе. Сессия подготовки устава обычно олицетворяет собой старт вашей новой инициа­ тивы, но при этом полезна для любой команды, которая хочет лучше понять общую картину, даже если уже работает в течение многих лет. Кроме того, допустимо проводить эту сессию за несколько недель до реального начала работ.

Проверьте черновик цели Сессия подготовки устава начинается с обсуждения цели команды2. Начните с презентации черновика ви́дения. Будет лучше, если его презентует тот, кто руководил подготовкой черновика. Обычно это делает продакт-менеджер, входящий в команду. Когда вы презентуете цель, не просто читайте ее, а объясняйте мысли, стоящие за словами. Предыдущие обсуждения. Компромиссы, которые были достигнуты и которые еще необходимо достичь. Эта предыстория позже поможет всем понять «почему» цели.

Получите общее согласие с ви́дением Ознакомившись с целью, проведите голосование по поводу согласия с ви́дением (см. пункт «Стремитесь к согласию» ранее в данной главе). Ви́дение принадлежит спонсору, так что цель вряд ли можно будет изменить, но проведение голосования выявит любые серьезные возражения. Если нужны изменения, то спонсор должен их одобрить. Если спонсор недоступен, то человек, руководивший созданием черновика цели, может быть его временным уполномоченным.

Совершенствуйте миссию За ви́дение отвечает спонсор, а за миссию — команЗа ви́дение отвечает спонсор, да. Именно она отвечает за претворение миссии а за миссию — команда. в жизнь, поэтому должна взять на себя и ответственность за нее. Чтобы помочь с формированием этой ответственности, запросите у команды обратную связь о миссии. (Пока не о показателях. Только о самой миссии.) Попросите дать реакции и комментарии, затем разделите команду на небольшие группы: кросс-функциональный коллектив, состоящий из членов команды и стейкхолдеров. На сессии не всегда готовится устав как документ, скорее это сессия, устанавливающая или стартующая проект. Далее оставим вариант «сессия подготовки устава». — Примеч. науч. ред.

1

Данная программа основана на [Larsen2016] (гл. 6), с небольшими изменениями.

2

158  Часть II.  Фокус на ценность Пусть каждая группа внесет в миссию улучшения: как небольшие поправки в формулировки, так и более значительные изменения. По истечении отведенного времени каждая группа представляет свои поправки и их обоснование, а остальная часть группы дает обратную связь. Фасилитатор помогает всем объединить их идеи в общую миссию. Для этого может потребоваться еще один раунд обсуждения в небольших группах. Иногда полезно перемешать состав групп. Как только команда скорректирует миссию, проведите еще один раунд голосования за согласие. Соответствует ли скорректированная миссия ви́дению? Удовлетворены ли стейкхолдеры тем, что миссия будет отвечать их потребностям? Готова ли команда взять на себя ответственность за достижение миссии? Когда вы будете вести это голосование, подчеркните, что миссия не обязательно должна быть идеальной. Она будет меняться со временем. Она должна быть просто достаточно хорошей на текущий момент.

Пересмотрите показатели И наконец, время пересмотреть показатели. Эта часть может быть самой спорной, поскольку они должны быть максимально конкретными. Хорошие показатели должны быть недвусмысленными. И это может пугать. Напомните всем, что показатели не являются Показатели — это ориентир, контрактом. Они служат ориентиром. Это способ а не контракт. проверить, находится ли команда на верном пути. Если ваша команда не достигает показателей, это значит, что вам нужна помощь или следует понизить ожидания. Если вы превышаете показатели, это значит, что вы готовы поднять планку и повысить ожидания. Показатели будут пересматриваться, как и все остальное, и они — не единственная бизнес-метрика, которой следует уделить внимание. Чтобы пересмотреть показатели, снова разделитесь на маленькие кросс-функ­ циональные группы. Поделите показатели между группами. Убедитесь, что с помощью каждого показателя можно проверять прогресс по достижению миссии, что для него возможен ясный ответ «да» или «нет» и команда способна достичь этого показателя. Проверьте изменения в большой группе, удостоверьтесь в общем согласии и продолжайте проверку, пока все возражения не будут благополучно разрешены. Пока группа работает над каждой частью, вы можете обнаружить новые детали, которые заставят вас вернуться и пересмотреть предыдущие части цели. Это нормально и ожидаемо. Это итеративный процесс.

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

Глава 7.  Командная работа  159

После того как цель будет утверждена, пригласите вашего спонсора, если он (она) еще не с вами. Вместе просмотрите изменения в цели, попросите поддержки и получите подпись спонсора. ПРИМЕЧАНИЕ Если во время вашей сессии подготовки устава вы обсуждаете и цель, и контекст (см. раздел «Контекст» далее в этой главе), то можете обсудить контекст и только потом пригласить спонсора.

Планирование сессии подготовки устава Сессии подготовки устава (chartering session) начинаются с обсуждения цели, но, помимо этого, обычно обсуждаются контекст и согласование (см. разделы «Контекст» и «Согласование» далее в этой главе). Если вы планируете обсудить все три элемента, то выделите на сессию два полных дня. Вы же не хотите спешить, а если закончите раньше, то никто не будет в обиде. Чего нельзя будет сказать, если процесс затянется. Удаленным командам нужно столько же времени, сколько и командам, работающим в режиме личного общения, — около 15 часов или, возможно, больше; но их сессия должна быть разбита на меньшие периоды, как правило, не превышающие четырех часов в день. Длительные собрания очень утомительны, если проводятся в виртуальном формате, поэтому разделите их. Убедитесь, что все могут полностью погрузиться в дискуссию, и проводите сессию с включенным видео, если это возможно (см. врезку «Личное общение» выше в текущей главе). Как вариант (особенно для новых команд), с помощью сессии подготовки устава бюджет, заложенный на поездки, можно использовать для построения взаимоотношений. Проведите сессию в приятном месте за пределами офиса и отведите дополнительный день на развлечения, которые позволят лучше узнать друг друга, и, возможно, даже на совместный осмотр каких-либо достопримечательностей. В сессии должны принимать участие ваш исполнительный спонсор, ключевые стейкхолдеры, члены команды и продакт-менеджер (если он/она уже не является частью команды). Спонсор открывает встречу, поприветствовав и поблагодарив участников, кратко описав бизнес-преимущества командной работы и заявив поддержку инициативы. Затем спонсор может уйти, если не желает участвовать в дискуссии. Будет лучше, если кто-то, имеющий навыки фасилитации, будет вести сессию, особенно при наличии шансов, что она перерастет в спор. Этим кем-то может быть коуч команды, но часто лучше привлечь представителя нейтральной третьей стороны. Вы можете попросить помочь коуча другой команды или нанять внешнего фасилитатора. В крупных организациях отдел кадров может иметь в своем штате профессионального фасилитатора. Когда обсуждение цели и контекста закончено, исполнительный спонсор возвращается, чтобы подтвердить свою поддержку. На этом участие стейкхолдеров завершается. Члены команды выражают им свою благодарность за участие

160  Часть II.  Фокус на ценность

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

Концепция, миссия и показатели (из раздела «Цель»). Контекстная диаграмма (из раздела «Контекст»). Рабочие соглашения и стандарты (из раздела «Согласование»).

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

Продвигайте цель Как только цель утверждена, сделайте ее краеугольным камнем проекта. СсылайСм. также тесь на нее в отчетах о работе команды, Информативное рабочее пространство предназначенных для стейкхолдеров, (глава 9) и в разговорах о ваших планах и приоритетах. Вывесите постер с целью на Визуальное планирование (глава 8) видном месте в командной комнате и обДемо для стейкхолдеров (глава 10) ращайтесь к ней во время сессий планирования. Не забывайте вовлекать в процесс работы вашего спонсора и других ключевых стейкхолдеров. Приглашайте их на визуальные сессии планирования. Убедитесь, что эти люди видят демо, даже если это происходит на сессиях с ограниченным доступом. Запрашивайте у них обратную связь относительно прогресса и просите помощи в улучшении ваших планов. Вовлекать стейкхолдеров может быть непросто, но вы все же пытайтесь. Энтузиазм и воодушевление этих людей могут говорить гораздо больше, чем любой документ. Если члены команды часто общаются со своими ключевыми стейкхолдерами, то будут лучше понимать свою цель и выдвигать больше идей, которые позволят повысить ценность продукта и снизить затраты. Ели гора не идет к команде, значит, команда должна идти к горе. Другими словами, если Попытайтесь вовлечь ключевых стейкхолдеров. стейкхолдеры не хотят приходить на сессии планирования, то командные продакт-менеджеры

Глава 7.  Командная работа  161

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

Обновляйте цель Цель команды будет меняться со временем. Показатели будут устаревать, и команда будет узнавать что-то новое о своих стейкхолдерах, заказчиках и рынке. В результате вам понадобится обновлять цель. Это изменяемый документ. Установите конкретное время для пересмотра и корректировки цели. Например, каждые 3–6 месяцев. Подготовьте новый черновик и соберите всех на новую сессию подготовки устава. Скорее всего, она пройдет значительно быстрее, чем в первый раз. Обычно концепция сильно не меняется, миссию потребуется слегка скорректировать, а показатели нужно будет обновить или заменить.

Вопросы Может ли вся команда участвовать в обсуждении проекта цели? Конечно! Это прекрасный способ для команды узнать поближе своих стейкхолдеров. Обычно одни члены команды больше заинтересованы, чем другие. Обсудите, как разделить работу внутри команды, возлагая ее на тех участников, кто имеет больше опыта работы со стейкхолдерами. Обсуждение цели привело нас к спорам, и согласия не предвидится. Должны ли мы продолжать в любом случае? С целью команды должен быть согласен не каждый стейкхолдер, а лишь ключевые стейкхолдеры. Даже если обсуждение цели команды привело к ожесточенным спорам, вам все же необходимо стремиться к общему ви́дению и цели. Иначе вы выпустите ПО, которое будет фрагментированным и никого не удовлетворит. Вероятно, вы сможете разбить цель на множество этапов, которые команда сможет выполнять последовательно. Если это не сработает, то попробуйте привлечь профессионального фасилитатора, который может выступать посредником в дискуссии. Наш спонсор постоянно меняет свое мнение. Как можно заставить его выбрать одно направление и придерживаться его? Как правило, быстро меняют цели спонсоры с предпринимательским мышлением. Это происходит не из-за отсутствия ви́дения или последовательности; просто они видят множество возможностей и меняют направление, чтобы использовать их все. Постоянное изменение цели может служить знаком, что то, что вы принимаете за цель команды, — на См. также самом деле временная стратегия в более крупной общей цели. Адаптивное планирование Если вам удастся идентифицировать эту более (глава 8) крупную цель, то адаптивное планирование сможет

162  Часть II.  Фокус на ценность помочь вам двигаться наравне с вашим спонсором. Здесь также может пригодиться свободное владение навыками на уровне оптимизации. Его акцент на обучение и использование всех возможностей будет прекрасно сочетаться с предпринимательской натурой вашего спонсора. Ваш спонсор может продолжать менять направления быстрее, чем вы будете воплощать в жизнь его идеи. В этом случае продакт-менеджер может выступать посредником, защищая команду от быстрых изменений и объясняя спонсору, какой объем работы команда может выполнить в данный момент.

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

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

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

Глава 7.  Командная работа  163

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

Литература для дополнительного чтения Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen2016] — комплексное руководство по планированию устава в Agile. Оно легло в основу практик в разделах «Цель», «Контекст» и «Согласование» этой книги. Особенно полезны рекомендации по подготовке и фасилитации сессий подготовки устава. Impact Mapping1 [Adzic2012] содержит милую дискуссию о том, как определить цели и создать хорошие показатели (автор называет их «измерители»), в главе Creating an Impact Map.

КОНТЕКСТ Мы знаем, с кем и с чем мы должны работать. Какие навыки доступны для вашей команды? Какие ресурсы у вас есть? Кто ваши стейкхол­ деры? Все это — часть контекста вашей команды: более широкой системы, в которую она встроена. Понимание контекста важно для снижения риска. Если вы не понимаете контекст, то люди или ожидания, о существовании которых вы даже не подозревали. легко могут застать вас врасплох.

Аудитория Продакт-менеджеры, коучи

Если вы не понимаете контекст, то люди и ожидания могут застать вас врасплох.

Запишите контекст в устав Сессия подготовки устава вашей команды, коСм. также торую мы обсуждали во врезке «Планирование сессии подготовки устава» ранее в данной глаЦель (глава 7) ве, — подходящий момент, чтобы обсудить ваш контекст. Вы также можете обсудить контекст и во время отдельной сессии, если это удобнее, но будет лучше, если вы сначала определите цель вашей команды. Это поможет каждому понять, что именно команда намеревается делать. Аджич Г. Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке.

1

164  Часть II.  Фокус на ценность В процессе обсуждения контекста вам будет нужно работать с  ключевыми стейкхолдерами, чтобы определить три аспекта контекста вашей команды: доступные навыки, границы и взаимодействие команды, а также ресурсы, выделенные ей. В дальнейшем вы посмотрите результаты с вашим исполнительным спонсором и попросите его подтвердить готовность предоставить то, чего не хватает1.

Доступные навыки Начните с просмотра навыков, доступных вашей команде. Попросите каждого члена команды представиться и описать навыки и опыт, которыми они владеют. Эти люди также могут рассказать о любых своих связях или разрешениях, имеющих отношение к делу. Пока человек будет говорить, фасилитатор может записывать ответы на флипчарт. Для удаленных команд можно выделить пространство на вашей виртуальной белой доске и использовать его в качестве виртуального флипчарта. Назовите этот список «Перечень навыков». ПРИМЕЧАНИЕ В «Разрешения» входят электронные разрешения (допуски), такие как «я имею возможность просматривать базу данных в эксплуатационной среде»; юридические разрешения, такие как «у меня есть корпоративная кредитная карта и право подписи при покупке оборудования»; социальные разрешения, такие как «мне разрешается разговаривать с тем расстроенным заказчиком».

Некто, имеющий опыт в эксплуатации, может сказать: «Я — Ха Лам, и я работаю в эксплуатации пять лет, два из которых — в этой компании. Моя специализация — инфраструктура как код (IaC), и у меня есть опыт в кибернетике. У меня хорошие связи с командой платформ и есть допуск к развертыванию в эксплуатационной среде». После того как все члены команды представились, создайте отдельный список людей, которые помогают вам, но не приписаны к команде на полный рабочий день. В список, вероятно, будут входить продакт-менеджер и коуч. Если они присутствуют на встрече, то также могут рассказать о себе; если нет — тот, кто знает их лучше всех, может рассказать об их навыках, опыте и т. д., включая время, когда они бывают доступны, и наиболее удобные способы общения с ними. Обсудив навыки всех участников, обратите общее См. также внимание на цель команды. (Вы можете записать ее на флипчарте или в общедоступном документе; кроме Цель (глава 7) того, можно раздать всем копии.) Прочтите несколько пунктов, а затем попросите участников свериться с перечнем навыков. Не пропущены ли какие-либо навыки или разрешения, которые могут понадобиться команде? Предложите команде одновременный мозговой штурм Этот план основан на [Larsen2016] (гл. 7), с некоторыми изменениями. Я добавил перечень навыков, частично вдохновленный активностью «Основная группа», и удалил их активность «Перспективный анализ», чтобы сохранить ее в разделе «Визуальное планирование» главы 8.

1

Глава 7.  Командная работа  165

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

Границы и взаимодействия Далее вы создадите контекстную диаграмму, выявляющую все разнообразие групп людей, с которыми придется работать вашей команде. Начните с подготовки большой поверхности для диаграммы. (Лучше приготовить ее заранее.) Она должна быть большой, поэтому скрепите вместе несколько флипчартов на стене или столе либо используйте большую белую доску. Удаленные команды будут использовать виртуальную доску, как обычно. Нарисуйте в центре круг, представляющий вашу команду. Когда будете готовы, предложите участникам мозговой штурм, чтобы записать каждую группу стейкхолдеров, с которой команде необходимо взаимодействовать, на отдельный стикер. Мыслите очень широко: важен каждый, кто влияет или подвергается влиянию работы команды как в позитивном, так и в негативном ключе. Сюда входят команды разработчиков ПО, с которыми взаимодействует ваша команда, включая команды — владельцы систем, с которыми будет коммуницировать ваше ПО; другие группы в компании, отвечающие за маркетинг, продажи и эксплуатацию; группы вне компании, такие как ваши заказчики, конкуренты и поставщики; и даже еще более отдаленные группы, например государственные регулирующие органы. Когда идеи закончатся, пусть люди разместят стикеры вокруг центрального круга, представляющего вашу команду. Одинаковые стикеры можно объединить. Например, вы можете сгруппировать вендоров программ в один стикер под названием «Вендоры ПО», но оставьте отдельный стикер для вашего провайдера облачной инфраструктуры. Похожим образом стикеры с указанием групп, имеющих минимальное влияние на вашу команду (и наоборот), можно выбросить. После того как все стикеры окажутся на доске, попросите участников подумать над тем, что они дают каждой группе стейкхолдеров и что получают от каждой группы. Пусть они обозначат все эти взаимодействия стрелками и добавят краткое описание. Если вы рисуете вашу диаграмму на бумаге, то начните с чего-нибудь временного, типа карандаша или другого стикера, чтобы было легко вносить изменения. Пока участники работают над диаграммой контекста, подготовьте еще несколько флипчартов. Озаглавьте их «Необходимые ресурсы» и «Коммуникации, которые необходимо обеспечить» и прикрепите рядом с флипчартами «Необходимые навыки» и «Необходимые разрешения». ПРИМЕЧАНИЕ Agile-команды избегают называть людей ресурсами. Это обезличивает. Под ресурсами я имею в виду такие понятия, как время, деньги, товары и сервисы.

166  Часть II.  Фокус на ценность Как только диаграмма контекста будет готова, вам нужно ее проанализировать. Разделите команду на небольшие кросс-функциональные группы и распределите между ними группы стейкхолдеров с диаграммы. Обсудите, как команда будет взаимодействовать с каждой группой заинтересованных лиц, и с помощью мозгового штурма определите необходимые команде навыки, разрешения и ресурсы. Таким же образом подумайте, с помощью каких коммуникационных способов эта группа будет взаимодействовать с командой. Запишите каждую идею на стикер и прикрепите на соответствующем флипчарте: «Необходимые навыки», «Необходимые разрешения», «Необходимые ресурсы» или «Коммуникации, которые необходимо обеспечить». И наконец, дайте всей команде подумать над диаграммой «Коммуникации, которые необходимо обеспечить» и решите, как упростить и скомбинировать ваши способы коммуникаций. Некоторые их виды могут подойти для нескольких групп. Например, вы можете информировать людей о прогрессе работы и дорожных картах с помощью рассылки по электронной почте. На данный момент вам нужно просто создать примерный план; команда будет его пересматривать в течение следующих недель. Выберите ответственного за каждый тип коммуникации, а также кого-то, кто будет регулярно всем напоминать выполнять запланированные действия. Когда ваша команда установит рабочий ритм, эти обязанности могут стать более гибкими, но в самом начале что-то может выпадать из поля зрения. Поэтому лучше будет пока иметь четко определенные обязанности. ПРИМЕЧАНИЕ Если принятие решения о том, как продолжить коммуникации, занимает больше, чем несколько минут, то отложите его до конца встречи. (Только не забудьте потом!) Не нужно тратить время остальных участников понапрасну.

Выделенные ресурсы По завершении двух предыдущих упражнений у вас должно быть три диаграммы, описывающие, что нужно вашей команде: «Необходимые навыки», «Необходимые разрешения», «Необходимые ресурсы». Теперь пусть участники одновременно поработают над сортировкой стикеров из каждой диаграммы, сгруппировав их в четыре категории: «строго необходимо», «необходимо», «желательно», «не нужно»1. В процессе сортировки люди могут добавить новые пункты. Проверьте результаты вместе со всеми присутствующими и убедитесь, что команды и стейкхолдеры достигли согласия в вопросе о необходимых пунктах и их категоризации. Небольшие разногласия — это нормально, так что не стремитесь к совершенству. Это называется приоритизация MoSCoW (must have, should have, could have and won’t have). Последняя категория обычно называется «не будет» (won’t have), но я называл ее «не нужно» (don’t need), чтобы отличать от того, что вы хотели бы, но не можете получить.

1

Глава 7.  Командная работа  167

Когда закончите с этим, стикеры с надписью «не нужно» можно выбросить. Добавьте на оставшихся стикерах примечания. 1. Кто может предоставить каждый элемент. 2. Насколько они готовы его предоставить. 3. Как его получить, если это неочевидно. Группа может работать над несколькими стикерами одновременно. В конце предложите всем сделать шаг назад и осмотреть все, что необходимо. Есть ли что-то важное, что необходимо команде, но получить это будет непросто? Если да, то выделите эти пункты. Вам понадобится обратиться к спонсору с просьбой предоставить это. Подготовьте несколько возможностей на рассмотрение спонсору. Например, если вам нужны навыки настройки баз данных, то вы можете предложить найти консультанта, пройти тренинг или нанять кого-то.

Обязательства спонсора Завершите обсуждение контекста, снова пригласив спонсора в комнату, если он не присутствовал при обСм. также суждении. Если вы также обсуждали изменения в уставе, имеющие отношение к цели, то сейчас подходящее время Цель (глава 7) для того, чтобы спонсор утвердил эти поправки. Затем обратите внимание на потребности команды. Просмотрите навыки, разрешения и ресурсы, которые ваша команда не может получить самостоятельно, и попросите спонсора взять на себя обязательство обеспечить их. Если он сделает это, то задача выполнена. Решите, кто в команде будет ответственным за напоминания по этим обязательствам и кто еще будет дополнительно напоминать о них, как было описано в предыдущем подразделе. Если ваш спонсор не может предоставить все необходимое, то внимательно изучите возЕсли ваш спонсор не может можные компромиссы. Как нехватка каждого предоставить все необходимое, из ресурсов, навыков или разрешений влияет то откровенно поговорите с ним о компромиссах. на способность команды достичь цели? Откровенно поговорите со спонсором о том, чем он рискует и чего хочет от команды. В ходе разговора помните, что спонсор должен сделать нелегкий выбор. Обычно эти люди оказываются перед выбором одной из двух плохих возможностей. Да, спонсоры владеют бюджетом команды, но их ресурсы не безграничны. Иногда спонсоры должны сделать трудный выбор между тем, чтобы дать команде все, о чем она просит, или надеяться на то, что она найдет достаточно ресурсов, позволяющих добиться результатов и без спонсорской поддержки. Некоторые элементы все же будут существенными, и без них команда не сможет достичь своей цели. Если вы не можете получить какие-либо важные ресурсы, то вам нужно будет проработать со спонсором возможности изменить или отменить цель либо отложить ее достижение.

168  Часть II.  Фокус на ценность

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

Вопросы Что, если у нас отсутствуют необходимые ресурсы, но спонсор не хочет слушать? Это трудная ситуация. Если вы знакомы с кем-то имеющим навыки дипломатии (например, продакт-менеджером, менеджером проекта или коучем), попросите их помочь донести это сообщение до спонсора. Тем временем работайте с тем, что есть, и продолжайте напоминать спонсору и бизнес-стейкхолдерам, что от вас ожидают, что вы сделаете X, Y и Z, но вы можете сделать только X и Z из-за ограниченности в ресурсах.

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

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

Глава 7.  Командная работа  169

Альтернативы и эксперименты Работа над контекстом для устава позволяет вам получить много информации о ситуации, в которой находится команда, но особенно важны следующие три результата. 1. Знание того, кто ваши группы стейкхолдеров и что вам нужно друг от друга. 2. Определение способов, с помощью которых вы будете общаться друг с другом. 3. Корректировка вашей цели и ожиданий стейкхолдеров в соответствии с навыками, разрешениями и ресурсами, доступными команде. Программа сессии подготовки устава, представленная здесь, — это только один из способов, позволяющих достичь этих результатов. Вы можете применить любой подход. Некоторые организации, вместо того чтобы проводить сессии подготовки устава, поручают руководителям проектов или бизнес-аналитикам провести интервью со стейкхолдерами и, исходя из результатов, создать набор документов. Это рабочий способ, но все же не стоит недооценивать значимость коллективной работы команды и заинтересованных сторон над тем, чтобы узнать точки зрения друг друга. Проведение сессии в сотрудничестве с ключевыми стейкхолдерами — прекрасная возможность создать взаимосвязи и обоюдную эмпатию. Это нечто гораздо более интуитивное и запоминающееся, чем пачка документов, на чтение которых некоторые люди так и не найдут времени. Вы все еще сможете проводить эксперименты, даже если будете придерживаться базовой идеи сессии подготовки устава. Начните с практики, описанной здесь, предпочтительно задействовав опытного фасилитатора, просто чтобы получить некоторые представления о том, как это должно работать. Затем начните экспериментировать. Например, долгая двухдневная встреча может быть очень изнуряющим мероприя­ тием. А что, если разделить ее на несколько более коротких? А как насчет специальных видов деятельности? Можете подумать о способах, позволяющих улучшить или заменить эти виды чем-то другим. Что, если сделать больше подготовительной работы заранее или пригласить других людей? Если ваша организация большая, то предложите провести такие сессии для других команд. Они ценны для любых команд, не только Agile, и даже не только команд разработки ПО. Эти сессии проводятся не только тогда, когда команда лишь создается; если она раньше не согласовывала устав, то ей наверняка будет полезна такая сессия независимо от того, насколько долго люди работают вместе. У вас будет много возможностей для эксперимента, и есть множество вещей, которые вы можете попробовать. Подумайте, чему вы можете научиться.

СОГЛАСОВАНИЕ Мы договорились о том, как будем работать вместе. Что такое «команда»? Это не просто группа людей, сидящих в одной комнате. Это даже не группа людей, которой поручили работать над одной и той же задачей.

Аудитория Продакт-менеджеры, коучи

170  Часть II.  Фокус на ценность Команда — это группа людей, которые полагаются Взаимозависимость — друг на друга, стремясь достичь общей цели. Эта взаи­ отличительный признак мозависимость — отличительный признак команды. команды. Это то, что делает команды такими успешными… и то, что все усложняет. Вероятно, вы помните работу над групповыми заданиями в школе. В лучшем случае вы их терпели. Мы все слышали ужасные истории о человеке, который в конечном итоге начал один делать всю работу, пока остальные выпрашивали оценки. Но мы слышали и истории об удивительных командах. Возможно, у вас тоже был такой опыт: быть частью прекрасной спортивной команды, музыкальной или волонтерской группы. Работая, команды заряжают энергией все вокруг. В чем разница между хорошими и плохими командами? В согласованности. Люди в команде, достигшей согласия, не только полагаются друг на друга, чтобы достичь общей цели, но и договорились о том, как будут работать вместе.

Запишите договоренности в устав Во время сессии подготовки устава вы можете согласовать договоренности (см. врезку «Планирование См. также сессии подготовки устава» выше в данной главе). В отличие от других этапов сессии (обсуждение цели Цель (глава 7) и контекста), стейкхолдеры не присутствуют при обКонтекст (глава 7) суждении договоренностей. В нем участвуют только члены команды и те, кто близко работает с командой, например продакт-менеджер. Как и в случае с другими дискуссиями об уставе, тема согласования может поднять некоторые деликатные вопросы. Будет лучше, если вы привлечете нейтрального фасилитатора. Хороший фасилитатор поможет уладить конфликты и сделать так, чтобы мнение каждого участника было услышано. В процессе согласования вы узнаете больше о людях в команде, создадите рабочие договоренности, которые будут направлять поведение команды, и установите стандарты1.

Узнайте друг друга Начните ваше обсуждение с того, что поможет лучше узнать друг друга. Врезка «Упражнение на построение взаимоотношений в команде» выше в этой главе — хороший способ положить начало общению. Затем проведите групповое обсуждение следующих вопросов. 1. Кто я? (Расскажите немного о себе, поделитесь своими положительными личными качествами, например, «внимательность к деталям», «терпеливость» или «дружелюбие».) 2. Что люди сразу узнают обо мне, как только знакомятся? (Это может быть хобби, любимые места для поездки в отпуск или любимое домашнее животное.) Эта программа основана на [Larsen2016] (гл. 6), с некоторыми изменениями.

1

Глава 7.  Командная работа  171

3. Почему я думаю, что эта группа хорошо подходит для достижения цели команды? 4. Каков самый важный факт из того, что другие должны знать обо мне, чтобы эффективно работать со мной? 5. Что все это для меня значит? Что я хочу получить от участия в работе команды и достижении ее цели? Сделайте круг по комнате, задавайте один вопрос за раз, дайте ответить каждому. Люди могут пропустить свою очередь, если им надо время подумать. Вернитесь к ним позже, прежде чем переходить к следующему вопросу. Этот разговор поможет членам команды увидеть друг друга как людей в целом, а не только имена, лица и названия должностей. Если у вас удаленная команда, то постарайтесь провести этот разговор с включенным видео.

Заключите рабочие соглашения Рабочие соглашения определяют поведение вашей команды, описывая то, чего вы ждете друг от друга. Со временем они будут меняться. Когда команда достигает зрелости, многие из рабочих соглашений становятся привычными, и их можно будет удалить из списка. Другие, наоборот, можно будет добавить, чтобы воспользоваться новыми идеями. Чтобы создать рабочие соглашения вашей команды, начните с того, что поделитесь историями о других командах, с которыми вы работали. Опишите, как они работали вместе, хорошо или плохо. Можете делать это по кругу или в произвольном порядке в зависимости от того, кто хочет говорить следующим. 1. Вспоминая ваш прошлый опыт работы в команде (любого типа, включая спортивные команды, церковные или музыкальные группы либо хоры), подумайте, когда вы были наиболее эффективны как член команды. Расскажите коротко об этом времени. Какие рабочие условия привели к эффективной работе? 2. Поразмышляйте о том времени и тех ситуациях в вашей жизни, когда вы сотрудничали с командой. Что вы заметили в отношении себя, своего вклада, что вам кажется ценным? Что вы больше всего цените в тех группах? 3. Что, по вашему мнению, является основным фактором, который создает, воспитывает и поддерживает эффективную командную работу? Что отличает ее от других? 4. Какие три желания вы бы загадали, чтобы ваш опыт в этой команде стал наиболее ценным? Пока люди делятся своими воспоминаниями, сделайте паузу, чтобы записать идеи потенциальных рабочих соглашений. Они могут относиться к чему угодно: стандарты поведения, например, «мы не прерываем говорящего»; особенные практики, например, «мы используем парное программирование для всего промышленного кода»; рабочие привычки, например, «меняя задачи, мы пишем сообщение об этом в групповой чат» и т. д. Запишите все, что может помочь команде лучше работать вместе. Пока не критикуйте предложения; просто собирайте их. После того как вы поделились своими историями, проверьте, рассмотрели ли вы категории, приведенные ниже в перечне. Если нет, то предложите рабочие соглашения

172  Часть II.  Фокус на ценность и относительно них. Вам не обязательно будет их выбирать, просто убедитесь, что вы их приняли во внимание. zz Практики, которые будет использовать ваша команда. Я рекомендую начать с каждой практики на уровнях, выбранных вашей командой. zz Для виртуальных команд — как вы будете общаться (см. пункт «Организация удаленного взаимодействия» выше в данной главе). zz Как вы будете принимать решения. zz Для физических команд — как вы будете решать проблему отвлекающего фонового шума. zz Для команд, которые не используют парное или групповое программирование, — как вы будете просить помощи, не отвлекая коллег (см. пункт «Всегда просите помощи, всегда помогайте» выше в данной главе). zz Обязательные рабочие часы, в течение которых вы можете ожидать, что все члены команды будут доступны. После генерации идей сократите их спиВыберите рабочие соглашения, сок до пяти самых важных, используя токоторые требуют особого внимания, чечное голосование (см. пункт «Работайте а не те, которые выполняются одновременно» выше в данной главе). Идей автоматически. может быть несколько больше или меньше. Предложите людям проголосовать за те предложения, на которые, как они считают, команде нужно обратить особое внимание, а не на те, которые выполняются автоматически. Убедитесь, что все согласны с окончательным списком, проведя голосование о согласии (см. пункт «Стремитесь к согласию» выше в данной главе). Если не получается достичь согласия по определенному пункту рабочего соглашения, то просто пока исключите его из списка. Вы сможете вернуться к нему позже. В завершение сформулируйте все рабочие соглашения и внесите их в окончательный список. Каждое должно заканчиваться предложением «Мы работаем вместе лучше, когда…» Опишите то, что надо делать, а не то, что не надо делать. Другими словами, вместо «мы не прерываем друг друга» запишите «мы даем людям закончить См. также мысль и только потом выражаем свою». Прикрепите список где-нибудь на видном Командная комната (глава 7) месте в вашей командной комнате. Вы можете сразу начать им пользоваться.

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

Глава 7.  Командная работа  173

что в Agile мало решений, которые нельзя изменить. Уорд Каннингем сказал об этом так (https://oreil.ly/IcikH): «Переломный момент в моей программистской карьере наступил, когда я осознал, что мне не нужно побеждать в каждом споре. Допустим, я разговаривал с кем-то о коде и говорил: “Я думаю, что лучший способ это сделать — это А”. А они отвечали: “Мы думаем, что лучший способ это сделать — это Б”. Я говорил: “Нет же. Это точно А”. Они отвечали: “А мы хотим это сделать с помощью способа Б”. Поворотный момент настал, когда я смог сказать: “Хорошо. Делайте с помощью способа Б. Если я ошибаюсь, это не причинит нам особого вреда. Даже если я прав, а вы делаете Б — нам и это не слишком повредит, поскольку мы можем исправить ошибки. Так что давайте узнаем, является ли это ошибкой”».

Исходя из этого, используйте следующие две рекомендации для создания своих стандартов. 1. Создайте минимальный набор стандартов, который позволит выполнять работу. 2. Предпочтите последовательность и согласованность, а не совершенство. В качестве первого стандарта решите, что подразумевать под сделанной работой. См. также Начните обсуждение, попросив участников Сделано Сделано (глава 9) предложить промышленный стандарт в качестве основы. (Для определения понятия «сделано» можете использовать чек-лист «Сделано Сделано» (Done Done) из главы 9.) Если в вашей компании уже есть стандарты, то начните с них. Если предложений для базового стандарта несколько, то обсудите варианты и выберите один, с которым согласны все. Ограничьте дискуссию несколькими минутами. Если вы не можете уложиться в это время, то начните без базового стандарта. Далее, используя одновременный мозговой штурм, подумайте о дополнениях или изменениях. Сгруппируйте идеи, используя диаграмму сходства (см. пункт «Работайте одновременно» выше в данной главе), а затем проведите точечное голосование, чтобы выбрать наиболее важные категории. Начиная с категории, получившей максимальное количество голосов, попросите кого-нибудь предложить подходящий стандарт. Проведите голосование за согласие, устраните возражения и перейдите к следующему предложению. Ограничьте обсуждение каждого варианта пятью минутами. Если не удалось договориться за это время, то пока просто пропустите это предложение. Повторюсь: у вас будет возможность пересмотреть свои стандарты позже. Отведите на все обсуждение 45 минут. После того как сформулируете определение понятия «сделано», повторите процесс с любыми другими нужными вам стандартами. Можно это сделать параллельно, разбившись на специализации, такие как программирование, UX-дизайн и эксплуатация. Резюмируем. 1. Начните с согласования по поводу базового стандарта. (Ограничьтесь пятью минутами.) 2. Внесите дополнения или поправки с помощью мозгового штурма. Сгруппируйте их по категориям. Проведите точечное голосование.

174  Часть II.  Фокус на ценность 3. Для каждой категории заключите соглашение об определенном стандарте. (Ограничьтесь пятью минутами.) 4. Отведите на все обсуждение 45 минут. Независимо от того, какие стандарты выберет ваша группа, у некоторых людей они поначалу будут вызывать раздражение или недовольство. Но со временем вы приспособитесь к ним. Во многом стандарты — это вопрос эстетики. Один из признаков профессионализма — это готовность отказаться от личных эстетических предпочтений в пользу командных.

Помимо форматирования Однажды я вел команду из четырех программистов, имевших очень сильно различающиеся подходы к форматированию. Когда мы обсуждали стандарты кодирования, я перечислил три разных подхода к скобкам и табуляции. У каждого был свой ярый сторонник. Я не хотел, чтобы мы погрязли в спорах, поэтому сказал, что все участники команды могут использовать тот стиль скобок, который они предпочитают. Результат был предсказуем: у нас было три разных подхода к форматированию нашего кода. Я даже увидел три разных варианта отступа в пределах одного короткого метода. Знаете, что меня удивило? Это было не так уж плохо. Конечно, текст программы выглядел скверно, и я бы предпочел что-то более последовательное, но все же код был читаемым. В конце концов, остальные наши стандарты кодирования имели большее значение, чем форматирование. Мы договорились, что важно именовать переменные и короткие методы понятным образом. Мы договорились использовать утверждения (assertions), чтобы быстро обнаруживать неправильно работающий код, не оптимизировать без измерений и никогда не передавать пустые ссылки (ссылки, которые не ссылаются ни на какой объект, null references) между объектами. Мы договорились о том, как надо и не надо обрабатывать исключения (exceptions), что делать с отладочным кодом (debugging code), когда и куда регистрировать события (events). Эти стандарты помогли нам гораздо больше, чем это мог бы сделать единый стиль форматирования. Каждый стандарт приносил конкретную пользу. Вероятно, именно поэтому мы смогли договориться о них, когда не смогли договориться о форматировании. Не поймите меня неправильно: иметь единое форматирование было бы лучше! Но, собирая в единое целое ваши стандарты программирования, не загоняйте себя в ловушку бесконечных споров о форматировании.

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

Глава 7.  Командная работа  175

Стандартам нужно какое-то время, чтобы устояться. Запланируйте встречу, на которой вы сможете обсудить ваши стандарты, через несколько дней после начала вашей совместной работы, и еще одну — еще через несколько недель. Одного часа должно быть достаточно. Это поможет вам применять ваши стандарты на практике. Если после этого возникнут разногласия по поводу стандарта, то договоритесь поэкспериментировать с одним подходом, потом с другим и затем вернитесь к этому вопросу. Вы можете изменить ваши рабочие соглашения и стандарты в любой момент. Просто объявите о своем См. также намерении команде, получите согласие и замените Ретроспективы (глава 11) флипчарт или его виртуальный эквивалент. Кроме того, удобно изменять рабочие соглашения во время ретроспектив.

Придерживайтесь договоренностей Люди совершают ошибки. Предположим, ваши коллеги профессиональны и имеют добрые намерения. Если кто-то не выполняет соглашения, то допустим, что у него есть причина, несмотря на свидетельства обратного. Ваша задача — найти эту причину и разобраться с ней. Такой подход продемонстрирует уважение к другим и повысит их уважение по отношению к вам. Используя парное и групповое программирование, а также коллективное владение См. также кодом, команда может находить ошибки Парное программирование (глава 12) и поддерживать самодисциплину. Кроме того, эти практики позволяют обсуждать Групповое программирование вопросы, не касающиеся ваших командных (глава 12) соглашений. Вдобавок они дают прекрасную Коллективное владение кодом возможность улучшить ваши стандарты; на(глава 12) много легче предлагать улучшение, сначала обсудив его с кем-либо. Автоматизированное соблюдение стандартов, как правило, менее эффективно. Некоторые используют автоматизированные системы для проверки своего исходного кода на соответствие стандартам или автоматически переформатируют код после регистрации. Это может работать, если команда все согласовала, однако обычно это заводит команды в ловушку чрезмерного принуждения. И даже хуже, люди часто используют эти автоматические инструменты как дубинку, чтобы навязать свое мнение. Возникает соблазн получить техническое решение межличностной проблемы, однако ничего не получится. Нужно сначала решить межличностную проблему. Инструменты не знают нюансов. В лучшем случае эти разногласия будут скрыты. Инструменты не решат проблему, а просто уберут ее из виду, и она незаметно продолжит расти. Вместо этого лучше начать, предпоНачните с предположения, ложив, что человек имел добрые намечто имелись добрые намерения. рения. Возможно, он неправильно понял

176  Часть II.  Фокус на ценность соглашение, или думает, что оно больше неприменимо, или по каким-то причинам не может соблюдать это соглашение. Если кто-то постоянно нарушает командные соглашения, то поговорите с ним наедине, чтобы узнать, нет ли с его стороны принципиального несогласия. Займите позицию коллективного решения проблем. Вместо того чтобы спросить: «Почему ты не работаешь с нулевыми значениями, как мы договаривались?», задайте вопросы: «Что ты думаешь о стандарте работы с нулями, о котором мы договорились? Не нужно ли нам его изменить?» Примите к сведению все возражения, доведите их до всей остальной команды и подумайте об изменении соглашения. Если кто-то согласен с соглашением, но все же не соблюдает его, то, возможно, оно применимо не в каждой ситуации. Спросите о конкретных случаях, замеченных вами. И повторюсь: делайте это в манере сотрудничества, а не конфронтации. Скажите нечто вроде: «Я согласен с тобой насчет того, как мы должны работать с нулями. Можешь объяснить, что происходит в этом случае в данной функции? Я не понимаю, почему этот код не проверяет на нули». Во время такого обсуждения вы можете узнать, что человек не понимает сути соглашения. К этому времени вы уже должны быть в ситуации, которая позволяет обсудить соглашение и его значение. Если это младший член команды и ему нужна помощь, то координируйте свои действия с остальной командой, чтобы убедиться в том, что более опытные коллеги-наставники уделяют им достаточно внимания. Есть еще одна возможность для команд — новичков в Agile. Изменение рабочих привычек действует разрушительно и может заставить людей думать, что они потеряли контроль. Иногда они реагируют, отказываясь менять те или иные мелочи. Упорное желание сохранить определенный стандарт или стиль общения, независимо от желания остальной части команды, может быть симптомом такой реакции. В этом случае, возможно, лучшее решение — позволить нарушению просуществовать несколько месяцев. Со временем, привыкнув к изменениям в своей среде, члены команды расслабятся и будут более склонны идти на компромисс.

Рабочие соглашения и коучинг Рабочие соглашения могут служить полезным инструментом для коучинга. Некоторые практики поначалу могут вызывать у людей дискомфорт. Как коуч, я считаю полезным говорить о том, что люди договорились сделать, вместо того, чтобы говорить им, что они не делают того, чего я от них хочу. Например, я тренирую команду, которая согласилась попробовать парное программирование, но не делает этого. Я не буду говорить: «Вы должны работать с парным программированием». Вместо этого я скажу: «Я заметил, что люди не соблюдают соглашение о парном программировании. Как вы думаете, в чем причина?» Затем я могу снова вернуться к этой теме, спрашивая, применимо ли все еще соглашение или, возможно, его необходимо изменить.

Глава 7.  Командная работа  177

Вопросы Что, если мы не можем договориться относительно стандартов и рабочих соглашений? Можно оказать давление на людей, чтобы они приняли соглашение, с которым не согласны, но это плохая идея. Это несогласие просто будет все время проявляться в других разговорах. Вместо этого попытайтесь отпустить ситуацию. Неужели это рабочее соглашение действительно настолько важно? Сфокусируйтесь на том, с чем вы все согласны. В процессе работы ваши разногласия разрешатся. Если это не то, что можно просто проигнорировать, то вашей команде нужна помощь профессионального медиатора. Поговорите с вашим коучем или руководителем о поиске того, кто может помочь. Такой человек может быть в штате вашего отдела кадров. В худшем случае может оказаться, что ваша группа просто не подходит для того, чтобы быть командой, и вам лучше собрать ее из других людей. У нас есть предыдущая работа, которая не отвечает нашим стандартам. Надо ли нам ее исправлять? Тратить много времени на исправление того, что не является неисправностью, дорого и рискованно, поэтому если ваша предыдущая работа в целом работает, то оставьте ее и займитесь другими проектами. Приводите каждую часть в соответствие со стандартом, когда понадобится внести изменения. Некоторые стандарты, такие как форматирование кода, можно автоматизировать. Не тратьте на это слишком много времени, но если для вас это не трудно, то лучше сделать. Не забудьте скоординироваться с другими командами в вопросе автоматизированных изменений, чтобы не повлиять на их работу, и отделите автоматизированные изменения от обычных, чтобы вашу историю контроля изменений было легко читать.

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

Показатели Когда ваша команда имеет эффективные рабочие соглашения: zz

она использует рабочие соглашения для предотвращения и разрешения конфликтов;

zz

ваши стандарты повышают читабельность и удобство сопровождения вашего кода и других артефактов;

zz

ваши стандарты позволяют членам команды легче понимать незнакомые части системы.

178  Часть II.  Фокус на ценность

Альтернативы и эксперименты Некоторые команды работают вместе настолько хорошо, что им не нужны четкие соглашения. Их соглашения — подразумеваемые. Однако прямое обсуждение соглашений поможет новым командам и даже большинству существующих избежать разрушительных споров в будущем. Точный формат дискуссии не важен. Формат, представленный в книге, был выбран потому, что является относительно быстрым и неконфликтным, но вы можете использовать другой подход. Придерживайтесь подхода, описанного в этой книге, пока не проведете несколько успешных обсуждений. Согласование может быть спорным, особенно когда команды переходят к конкретным соглашениям, таким как стандарты, и именно поэтому в книге подчеркивается необходимость отмены спорных соглашений. Получив такой опыт, поэкспериментируйте с изменениями. Помогут ли обсуждения в малых группах или интервью? Можно ли что-то подготовить заранее? Будут ли другие упражнения более быстрыми или эффективными? Вы можете пробовать разные варианты, не ограничивая себя.

ЭНЕРГИЧНАЯ РАБОТА Мы работаем в таком темпе, который позволяет нам делать нашу работу наилучшим, наиболее продуктивным образом сколь угодно долго.

Аудитория Коучи, вся команда

Я люблю свою работу. Мне нравится решать проблемы, писать хороший код, наблюдать за прохождением тестов и особенно удалять код при рефакторинге. Но если я в команде, которая имеет неясные цели, низкую коллективную ответственность и погружена во внутренние распри, я буду просыпаться в ужасе от перспективы идти на работу. Я буду находиться в офисе, но не смогу удержи­ваться от соблазна проводить утро за чтением своей электронной почты, а потом буду вяло копаться в коде, одновременно просматривая мало относящиеся к делу сайты. Мы все бывали в такой ситуации. Мы профессионалы, поэтому стремимся делать свою работу качественно, даже если чувствуем себя деморализованными. Но все же вспомните, когда вы были наиболее продуктивными. Вы замечаете, насколько велика разница, когда вы просыпаетесь и чувствуете стремление начать работу? Не чувствуете ли вы себя более удовлетворенным, закончив работу вовремя в конце дня и зная, что вы сделали нечто важное и нужное? Практика «Энергичная работа» заключается Профессионалы работают в том, что профессионалы могут хорошо выползначительно качественнее нять свою работу и в трудных обстоя­тельствах, и продуктивнее, когда полны однако работают качественнее и продуктивнее, энергии и мотивированны. когда полны энергии и мотивированны.

Глава 7.  Командная работа  179

Как быть энергичным Один из самых простых способов быть энергичным — это заботиться о себе. Уходить домой вовремя каждый день. Отключаться от работы и проводить свободное время с семьей и друзьями. Питаться здоровой пищей, заниматься спортом и высыпаться. Когда вы заняты другими делами, ваш мозг переваривает события дня. Часто бывает, что утром вы по-новому посмотрите на вещи. Если качественная жизнь вне работы — это «инь» активной работы, то сконцентрированность — это «ян». Когда вы на работе, уделяйте ей все ваше внимание. Отключитесь от всего, что вас отвлекает, например от электронной почты и мессенджеров, если они не являются частью вашего виртуального рабочего пространства. Поставьте телефоны на беззвучный режим. Попросите вашего руководителя оградить вас от ненужных совещаний и организационной политики. Когда «инь» и «ян» сбалансируются, вы будете просыпаться по утрам хорошо отдохнувшим и готовым начать новый день. А в конце дня вы будете уставшим (но не истощенным) и удовлетворенным выполненной работой. Это нелегко. Энергичная работа требует поддержки со стороны как рабочего пространства, так и домашней среды. Это еще и личный выбор. Невозможно заставить кого-то быть энергичным. Но вы можете убрать препятствия.

Поддерживайте энергичную работу Одна из моих любимых техник как коуча — напоминать людям уходить домой вовремя. Уставшие люди совершают ошибки и выбирают неверные решения. Возникающие в результате ошибки в конечном итоге обходятся дороже, чем сама работа. Это особенно относится к тем, кто приходит на работу больным; помимо того что эти люди плохо выполняют свою работу, так еще и могут заразить других. Парное программирование — еще один способ стимулировать энергичную рабоСм. также ту. Оно способствует концентрации, как никакая другая известная мне практика. Парное программирование (глава 12) Проведя полный рабочий день за парным Групповое программирование программированием, вы будете уставшим (глава 12) и удовлетворенным. Это особенно полезно Согласование (глава 7) в те моменты, когда вы не в лучшей форме. Работа в паре с кем-то бодрым и бдительным может помочь сконцентрироваться и вам. Групповое программирование не так эффективно в удержании концентрации (ее легко потерять), но помогает избежать ошибок, которые может допускать уставший человек. Agile-команды основаны на плотном взаимодействии и постоянном общении. Это может выглядеть как кошмар интроверта, но (я говорю это как интроверт) все не так плохо, как кажется. Взаимодействие направлено на идеи и результаты, а не на болтовню. Но даже в этом случае относитесь с пониманием к тому, что интровертам нужно восполнять энергию, и старайтесь создавать рабочие соглашения, которые будут помогать вам оставаться энергичными.

180  Часть II.  Фокус на ценность Иметь возможность питаться здоровой пищей на работе — еще один способ поддерживать энергию и активность. Хороший выбор — фрукты и овощи. Пончики и другая подобная нездоровая, но популярная еда способствуют спаду активности во второй половине дня. Природа работы также имеет значение. См. также Не каж­дая команда может накормить бедных или решить NP-полные задачи, но внятная Цель (глава 7) четкая цель может оказать большое влияние. Сформулировать и объявить цель команды входит в обязанности членов команды, имеСм. также ющих навыки менеджмента продукта. Для того чтобы быть внятной, цель должна Прогнозирование (глава 10) быть также достижимой. Ничто не разрушает мораль настолько быстро, как ответственность за недостижимую цель. Если команде необходимо отвечать за соблюдение определенных сроков и объема работ, то убедитесь, что цели реалистичны и основаны на прогнозах, сделанных командой. У каждой организации есть политики, имеющие отношение к цели. В одних случаях они приводят к здоровым переговорам и компромиссам. В других — могут приводить к необоснованным требованиям и обвинениям. Члены команды, имеющие навыки дипломатии, должны заниматься вопросами организационных политик, информируя остальных о том, что важно, и ограждать от неважного. Эти члены команды также могут помогать команде, оберегая ее от необязательных совещаний и конференц-звонков. Если предоставить информативное рабочее пространство и соответствующие дорожные карты, то необходимость в статус-митингах См. также отпадает. При наличии множества внешних помех рассмотрите возможность ежедневно Информативное рабочее прорезервировать основные рабочие часы (может странство (глава 9) быть, для начала всего час или два), в течеДорожные карты (глава 10) ние которых все договорятся не беспокоить команду. В каждой организации есть стандартные процессы и технологии, которые команда должна использовать. Когда эти стандарты препятствуют рабочему процессу, это может разочаровывать и деморализовывать членов команды. Постарайтесь объяснять «почему» вместе с «что», стоящими за каждым таким стандартом, и давать командам возможность обсудить создание исключений. Руководители команды могут помогать команде отстаивать эти изменения и преодолевать бюрократию. Наконец, команды, находящиеся на уровне нормализации (см. пункт «Нормализация: мы — № 1» главы 11), обычно полны энергии. Им еще и очень весело. Вы можете узнать такую команду по тому, насколько ее членам нравится проводить время вместе. Они вместе ходят на обед, обмениваются шутками и даже могут общаться в нерабочее См. также время. Вы можете развиться в команде до уровня нормализации, обращая внимание на Динамики команды (глава 11) динамики команды.

Глава 7.  Командная работа  181

Делайте перерывы Если вы стали больше ошибаться, чем продвигаться в работе, то пора сделать перерыв. Однако если вы похожи на меня, то в моменте как раз труднее всего остановиться. Мне обычно кажется, что решение вот-вот обнаружится (даже если это длится последние 45 минут), и я не хочу останавливаться, пока не найду его. Поэтому полезно, чтобы кто-то другой напомнил мне, что надо остановиться. Сделав перерыв или хорошенько выспавшись ночью, обычно я сразу нахожу ошибку. Иногда вполне достаточно перекусить или См. также немного прогуляться. Программистам может помочь предложение поменяться в своей паре Парное программирование местами. Однако, если уже конец рабочего дня, (глава 12) лучше отправиться домой. Командная комната (глава 7) В физической командной комнате обычно заметно, когда кому-либо нужен перерыв. Сердитая сосредоточенность, ругань с компьютером и резкие движения — это знаки. Если кто-то ушел в себя, не общается — это тоже может значить, что пора сделать перерыв. Когда я замечаю пару программистов, шепчущихся друг с другом, я спрашиваю их, сколько времени у них прошло с последнего успешно прошедшего теста. Часто я получаю робкий ответ и тогда напоминаю им, что пора отдохнуть. Предложение сделать перерыв требует определенной деликатности. Если вас уважают как лидера, то вы можете просто сказать людям, чтобы перестали работать. В противном случае отвлеките их от проблемы на минуту, чтобы они могли привести мысли в порядок. Попросите их немного помочь вам в чем-то или прогуляться с вами, чтобы обсудить проблему, с которой вы столкнулись.

Вопросы Я работаю в стартапе, и нормальной рабочей недели мне просто не хватает. Могу ли я работать дольше? Среда стартапа зачастую наполнена азартом и духом товарищества. Это приводит к увеличению энергии и может значить, что вы можете работать больше, не теряя способности к концентрации. В то же время стартапы иногда путают долгие рабочие часы с преданностью делу. Будьте внимательны, не позволяйте преданности делу перевесить здравую мысль о том, что вы слишком устали, чтобы вносить полезный вклад. У нас важный дедлайн, и нет никакой возможности все успеть, кроме как работать круглосуточно, не поднимая головы. Нам нужно временно отказаться от обычного режима работы? Ничто не может сравниться с многочасовыми хакатонами, когда команда приносит пиццу, все упорно работают не покладая рук и в последний момент все наконец получается. Мощный марш-бросок перед финишной чертой может помочь команде сплотиться, позволяя им чувствовать удовлетворение, стоя перед трудностями. Однако…

182  Часть II.  Фокус на ценность Бросок к финишной черте — это одно, Длительные переработки а постоянный спринт на многие киломене смогут решить ваших проблем тры — другое. Длительные переработки с планированием. не смогут решить ваших проблем с планированием, к тому же чреваты серьезными негативными последствиями. Том ДеМарко называет такие переработки «важной техникой снижения продуктивности», приводящей к снижению качества, личному выгоранию, повышенной текучке персонала и неэффективному использованию времени в течение рабочих часов [DeMarco2002] (гл. 9). Если вы переработали на этой неделе, то не повторяйте этого на следующей. Если я вижу команду, работающую таким образом каждый квартал или каждый релиз, то ищу более глубокие проблемы.

Предварительные требования Это контрпродуктивно, но в некоторых организациях судят о сотрудниках по количеству часов переработок. В такой обстановке вам, возможно, лучше пожертвовать энергичной и дополнительной работой. Это личный выбор, который можете сделать только вы и ваша семья. И наоборот, энергичная работа — не повод бездельничать. Создавайте атмосферу доверия честным ежедневным трудом.

Показатели Когда ваша команда энергична: zz

в ней присутствуют азарт и дух товарищества;

zz

команда вовлечена в свою работу и стремится сделать ее как можно лучше;

zz

команда демонстрирует постоянный еженедельный прогресс, и вы чувствуете, что способны поддерживать его сколь угодно долго;

zz

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

Альтернативы и эксперименты Эта практика также называется «Устойчивый темп», и альтернатива ей — хм… «не­ См. также устойчивый». Но некоторые организации Парное программирование (глава 12) делают энергичную работу еще более трудной. Если это происходит в вашей органиГрупповое программирование (глава 12) зации, то парное или групповое программирование может помочь уставшим членам команды оставаться сконцентрированными и находить ошибки друг друга. Как ни странно, работа над вашим ПО займет больше времени (потребуется найти и ис-

Глава 7.  Командная работа  183

править ошибки, допущенные уставшими членами команды), поэтому скорректируйте ваши планы соответствующим образом. Некоторые организации требуют, чтобы их сотрудники работали сверхурочно неделю за Одна общая характеристика неделей. К сожалению, эти гонки на выживание, проектов в стиле гонки на выживание — низкая также называемые режимами кризиса, случаются ожидаемая ценность. не из-за необходимости получения огромной ценности; как раз наоборот. Том ДеМарко и Тимоти Листер объясняют: «Из нашего опыта, общая характеристика проектов в стиле гонок на выживание — низкая ожидаемая ценность. Это проекты, направленные на выпуск продуктов, имеющих монументальную незначительность. Единственное реальное оправдание гонки на выживание — это то, что ее ценность настолько мизерная, что создание проекта по нормальной стоимости явно приведет к тому, что затраты превысят выгоду… Если проект настолько необходим, то почему компания не может выделить время и деньги на то, чтобы сделать его должным образом?» [DeMarco2003] (гл. 21).

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

Литература для дополнительного чтения Peopleware: Productive Projects and Teams1 [DeMarco2013] — классическая работа о мотивации и продуктивности программистов. Она должна быть первой в списке для чтения у каждого руководителя разработки программного обеспечения. В книге Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency [DeMarco2002] рассматриваются последствия длительной сверхурочной работы и перегрузки. В книге Joy, Inc.2 [Sheridan2013] описывается, как Menlo Innovations применяет свой вариант экстремального программирования для создания «энергичного» рабочего места. Это увлекательное произведение написано с точки зрения CEO.

ДеМарко Т. Человеческий фактор. Успешные проекты и команды.

1

Шеридан Р. Работа мечты. Как построить компанию, которую любят.

2

ГЛАВА 8

Планирование

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

Практика «Истории» поможет вашей команде планировать работу небольшими частями, ориентированными на интересы заказчика.

zz

Практика «Адаптивное планирование» позволит найти баланс между адаптивностью и предиктивностью, фокусируя планы команды на создание ценности.

zz

С помощью практики «Визуальное планирование» вы можете создавать планы, которые отражают контекст и варианты реализации.

zz

Практика «Игра в планирование» поможет создать подробный план, направляющий дальнейшие действия вашей команды.

zz

Благодаря практике «Вовлечение реального заказчика» команда научится включать в свои планы точку зрения заказчика.

zz

Используя практику «Инкрементные требования», вы научитесь выяснять детали требований к продукту непосредственно перед тем, как они понадобятся.

Источники планирования Agile всегда был адаптивным. Подзаголовок первой книги по экстремальному программированию звучал как «Примите перемены» (Embrace Change) [Beck2000a]. В предисловии к первой книге о Scrum подчеркивалось, что для снижения риска необходимо как можно раньше вносить коррективы. Адаптивность занимает настолько важное место в Agile, что трудно установить ее конкретные источники. В практике «Адаптивное планирование» объединены идеи, которые я видел и использовал многие годы; огромное влияние оказала книга Software by Numbers [Denne2004]. Источники практик «Инкрементные требования»

Глава 8.  Планирование  185

и «Вовлечение реального заказчика» также трудно установить, однако название последней я позаимствовал из второго издания книги по экстремальному программированию [Beck2004]. Практика «Визуальное планирование» основана на реальных рабочих практиках многих Agile-команд. Источниками вдохновения послужили карты историй Джеффа Паттона и карты влияний Гойко Аджича, и я добавил обе. «Истории» — одна из наиболее известных практик Agile. Она зародилась в XP под названием «Пользовательские истории», а потом упростилась до «Истории» во втором издании «Экстремального программирования». Практика «Игра в планирование» также пришла из XP.

ИСТОРИИ Мы планируем нашу работу небольшими частями, ориентированными на интересы заказчика.

Аудитория Вся команда

Истории (Stories) — вероятно, самая неверно понимаемая идея всего Agile. Истории — это не требования и не варианты использования (use Каждая история — cases). И даже не нарративы. Они гораздо проще, напоминание о необходимости чем все перечисленное. поговорить. Истории нужны для планирования. Это своего рода игральные карты игры в планирование. И все! Алистер Кокберн называет их долговыми обязательствами для будущей дискуссии. Каждая история напоминает о необходимости поговорить о чем-то, что команде нужно сделать. Их пишут на индексных карточках или их виртуальном эквиваленте так, чтобы можно было их взять, передвинуть с места на место и поговорить об их месте в ваших планах. Так как истории просто напоминают о необходимости поговорить, они не должны быть подробными. Фактически подробные истории — знак того, что люди неправильно их понимают. Предполагается, что у вас должна быть команда, помещение для нее и вы должны регулярно общаться друг с другом. История — напоминание. Способ начать обсуждение подробностей. Хотя истории должны быть краткими, при См. также необходимости их можно дополнять примечаниями. Если есть что-то важное, что вы хотите Вся команда (глава 7) запомнить, или техническая деталь, которую Командная комната (глава 7) нужно отслеживать, то запишите это. Но не чувствуйте себя обязанными добавить больше деталей. Карточка с историей не должна быть документом с требованиями. Это только напоминание.

186  Часть II.  Фокус на ценность К А Р ГО - К УЛ ЬТ

Мастерская писателей «Нам нужен тренинг на тему, как лучше писать истории, — вздыхает Рафаэла. — Я уже устала от того, что наша команда делает не то, что нужно». Вы не настолько уверены в этом. «Но разве истории не должны быть просто напоминанием о необходимости поговорить? — спрашиваете вы. — Может, нам нужно почаще говорить с владельцем продукта в процессе работы, задавать ему вопросы, показывать, над чем мы работаем, — то есть получать обратную связь, чтобы понимать, делаем ли мы правильный продукт?» Рафаэла фыркает: «Да. Желаю удачи в этом. Нет, что нам нужно — это чтобы владельцы продукта Лучше. Писали. Истории. Все на это жалуются. Я позабочусь о том, чтобы вытрясти на это бюджет. Уверена, я смогу найти инструктора, который скажет владельцам продукта то, что они должны услышать».

Как написать историю Все, что нужно сделать вашей команде, кроме См. также обычной административной работы, требует своей истории. Именно так работа получает Игра в планирование (глава 8) приоритет. Когда вы узнаете о чем-то, что нужно сделать вашей команде независимо от вашей роли в этом, запишите это на карточку и поставьте в очередь, чтобы обсудить на следующей игре в планирование. Вам всего лишь надо написать минимум, достаточный для того, чтобы начать обсуждение, и напомнить об этом в дальнейшем. Например: zz «Отчет о складских запасах»; zz «Полноэкранная демоверсия для ярмарки вакансий»; zz «Настраиваемый брендинг на экране входа в систему». Некоторым нравится использовать шаВам не обязательно использовать блоны Connextra, чтобы писать истории слешаблоны историй. дующего вида: «Как (роль) я хочу (что-либо), чтобы (результат)». Вы можете использовать данный формат, если хотите, но это не обязательно. Компания Connextra создала этот шаблон в порядке эксперимента, чтобы напоминать самим себе, как обслуживать своих пользователей. Вы можете попробовать провести собственный эксперимент или просто набросать пару слов. Хотя истории и короткие, у них все же есть две важные характеристики. 1. Истории представляют собой ценность для заказчика и описываются в его терминах. Они описывают ту работу, которая понятна и имеет ценность для заказчика, а не детали ее технической реализации в вашем будущем ПО. Это позволит

Глава 8.  Планирование  187

вашему локальному заказчику принимать обоснованные решения о компромиссах в приоритетах. 2. Истории имеют четкие критерии выполнения. Они не обязательно должны быть записаны на карточке, но заказчики в команде должны понимать, что значит для истории быть сделанной, и должны уметь описать это, когда их спрашивают. Следующие примеры не являются хорошими историями. zz «Автоматизировать интеграцию сборки» не отражает ценность для заказчика. zz «Развертывание на промежуточном сервере за пределами файрвола» описывает скорее детали реализации ПО, чем конечный результат. Не использует терминологию заказчика, и локальным заказчикам, вероятно, будет трудно расставить приоритеты. Лучше написать «Сделать демо для заказчиков».

Ценность для заказчика Истории должны быть ориентированы на заказчика (клиентоцентричными). Пишите их с точки зрения заказчика, таким образом, чтобы они предоставляли нечто полезное для самого заказчика, пользователей и стейкхолдеров — представителей бизнеса. За их приоритеты отвечают заказчики в команде; решив, что история не имеет ценности, они не добавят ее в план. Ориентированные на заказчика истории не обязательно одновременно имеют ценность и для конечного пользователя, но всегда должны быть ценными с точки зрения заказчиков в команде. Например, упомянутая история про создание демо никак не помогает конечным пользователям, но поможет вашему бизнесу продавать продукт. Подобным образом некоторые истории могут быть слишком мелкими для реальных заказчиков, чтобы о них беспокоиться. Например, если вы разрабатываете систему расчетов по кредитным картам, то одна из ваших историй может звучать так: «Специальная обработка для кода 54, означающего отказ торговой точки». Но заказчики в команде должны знать место каждой истории в общей картине и должны быть в состоянии принимать компромиссные решения о приоритетах. («Мы можем пока отложить вопрос о коде 54, но просто обязаны обрабатывать код 41, поскольку это сообщение о мошенничестве».) ПРИМЕЧАНИЕ Хороший способ сделать ваши истории ориентированными на заказчика — предложить, чтобы заказчики в команде писали их самостоятельно.

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

188  Часть II.  Фокус на ценность Будет лучше распределить технические детали по всем историям. Например, вместо одной истории См. также «Дизайн уровня предметной области» инкрементно Инкрементный дизайн изменяйте дизайн вашей предметной области в каж(глава 14) дой истории. Будет проще, если использовать эволюционный дизайн, который мы обсудим в главе 14. У разработчиков часто бывают трудности с созданием историй, ориентированных на заказчика. Нужно Строгая расстановка приоритетов — секрет продолжать практиковаться! Без этого заказчикам быстрых релизов ПО. в команде трудно принимать взвешенные решения по приоритизации, а строгая расстановка приоритетов — секрет быстрых релизов вашего ПО. Чтобы сделать истории ориентированными на заказчика, разработчикам нужно проговаривать их со своими заказчиками в команде. Объяснить им, какого результата они хотят добиться, и попросить описать это своими словами. Если нужно, можно добавить к истории примечание, напоминающее о технологии, с которой связана эта история. Например, если вы считаете, что команде нужно перейти на использование другой технологии базы данных, то можете объяснить это таким образом: «Нам нужно перенести наши статьи в базу данных, которая лучше обрабатывает полнотекстовый поиск. Поиск уже занимает более полсекунды, и по мере добавления новых статей ситуация будет ухудшаться». Заказчик может описать это так: «Остановить снижение производительности при поиске статей». А вы можете добавить: «(база данных для полнотекстового поиска)».

Разделение и объединение историй Истории могут иметь любой размер. Когда у вас впервые возникает какая-либо идея, ваши истории могут быть большими и пространными: например, онлайн-магазин мог бы иметь историю «страница оформления заказа». Однако чтобы обеспечить наглядность и контроль, команде нужно каждую неделю выполнять См. также несколько историй. Вы можете разделить большие Игра в планирование (глава 8) истории на более мелкие и объединить маленькие истории в большие в процессе игры в планирование. Объединять истории легко. Возьмите несколько взаимосвязанных историй, скрепите их вместе и напишите новую оценку на лицевой стороне, если используете оценки. В виртуальной среде вырежьте описания историй и вставьте их на одну виртуальную карточку. Разделять истории немного сложнее, так как нужно следить, чтобы они оставались ориентированными на заказчика. Хитрость состоит в том, чтобы найти суть истории, а не отдельные шаги, которые она подразумевает. Какую фундаментальную ценность предлагает история, а что является ее приукрашиванием сверх этой ценности?

Глава 8.  Планирование  189

Запишите эту фундаментальную суть как историю, а каждое приукрашивание — как дополнительную историю. Если вам трудно это представить, то в книге Майка Кона Agile Estimating and Planning1 [Cohn2005] есть отличная глава о том, как разделять истории. Он предлагает следующие варианты. (Примеры мои собственные.) zz

zz

zz

zz

zz

zz

Разделять в соответствии с приоритетами. Например, история «Страница оформления заказа» может быть разделена на истории «Оформление заказа» (высокий приоритет), «Купоны» (средне-высокий приоритет), «Подарочные чеки» (средненизкий приоритет) и «Подарочная упаковка» (низкий приоритет). Разделять по границам данных, поддерживаемых историей. Например, история о сборе платежной информации может быть разбита на «Сбор информации о кредитной карте», «Сбор информации о подарочной карте» и «Сбор информации о PayPal». Разделять на основе операций, которые выполняются в рамках истории. Например, история об обработке платежей кредитными картами может быть разделена на «Сбор информации о кредитной карте», «Подтверждение данных кредитной карты», «Оплата по кредитной карте». Разделять на отдельные CRUD-операции (Create, Read, Update, Delete — создать, прочитать, обновить, удалить). Например, историю об управлении данными клиентов можно разделить на «Добавить клиента», «Просмотреть данные клиента», «Редактировать данные клиента» и «Удалить клиента», а также «Список клиентов» и «Сортировка клиентов». Разделять по межсекторальным задачам (таким как безопасность, ведение журнала операций и обработка ошибок), сделав множественные версии вашей истории. Например, историю об оплате кредитной картой можно разделить на «Оплата по кредитной карте», «Регистрация оплаты по кредитной карте в журнале» и «Обработка отказа в оплате по кредитной карте». Разделять по нефункциональным задачам (таким как производительность, стабильность, масштабируемость и т. д.). Например, историю об оплате кредитной картой можно разделить на «Оплата по кредитной карте» и «Поддержка 100–200 транзакций по кредитным картам в минуту».

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

Крошечные истории Чем больше вы разделяете историю, тем труднее может быть сохранять ее ориентированность на заказчика. Не сдавайтесь. Если не получается, то, по крайней мере, опишите техническую задачу бизнес-терминами. Это позволит заказчикам в команде понять суть и сохранить контроль над приоритетами. Вдобавок так вам будет легче объяснять ваши планы и прогресс другим людям. Кон М. Agile: оценка и планирование проектов.

1

190  Часть II.  Фокус на ценность Например, ваша история «Отправить электронное письмо, когда банковский перевод завершится», с точки зрения программистов, подразумевает следующие задачи. 1. Отправить обратный вызов в банковский сервис. 2. Зарегистрировать в журнале вызов веб-хука (webhook). 3. Захватить веб-хук. 4. Выполнить разбор данных транзакций веб-хука и базы данных запросов. 5. Отправить POST сервису электронной почты. Превратите их в истории, переформулировав их в бизнес-терминах. 1. Попросить банк уведомить вас о завершении банковского перевода. 2. Записать в журнал уведомления о банковских переводах. 3. Предотвратить поддельные уведомления о банковских переводах. 4. Найти клиента, связанного с уведомлением о банковском переводе. 5. Отправить электронное письмо клиенту, когда получено уведомление о банковском переводе. Повторю еще раз: лучше иметь независимые друг от друга истории, но и этот вариант может пригодиться как запасной, если не можете придумать ничего другого.

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

Истории для документации Чтобы делать свою работу, Agile-командам См. также нужно совсем немного документации, поскольку они используют инкрементные треИнкрементные требования (глава 8) бования и эволюционный дизайн. Но иногда Инкрементный дизайн (глава 14) команде может понадобиться документация по другим причинам. Как правило, такая документация является частью работы над какой-либо другой, более крупной историей, но бывают и истории, специально предназначенные для написания документации. Истории для создания документации такие же, как и все остальные: сделайте их ориентированными на заказчика и определите специальные критерии их выполнения. Пример истории для документации: «Инструкция по настройке биллинга». В подразделе «Документация» далее в текущей главе можно найти дополнительную информацию по этой теме.

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

Глава 8.  Планирование  191

«Исправить ошибку многопользовательского ре­ См. также дактирования». Запланируйте эти истории как можно раньше, чтобы код оставался чистым и потребБез багов (глава 16) ность в ПО для трекинга багов была минимальной. Сделано Сделано (глава 9) Истории для багов трудно измерить. Часто больше всего времени при отладке уходит на выяснение того, в чем ошибка, и обычно вы не узнаете, как много времени это займет, пока не сделаете это. Вместо этого установите временные рамки, например: «У нас уйдет максимум один день на исследование этого бага. Если мы не починим его за это время, то обсудим проблему всей командой и запланируем еще одну историю». На карточке напишите: «Временной отрезок — 1 день».

Нефункциональные истории Производительность, масштабирование и стабильность (нефункциональные требования) тоже должны быть запланированы с помощью историй. Как и всем историям, им нужна конкретная цель, имеющая ценность для заказчика. Однако, в отличие от других историй, вам понадобится помощь разработчиков, чтобы ее определить. Недостаточно сказать: «ПО должно быть стабильным» или «ПО должно быть быстрым». Вы должны быть в состоянии описать, насколько стабильным или быстрым оно должно быть. Создавая нефункциональные истории, подумайте о приемлемой производительности (минимально необходимой для удовлетворительных результатов) и наилучшей возможной производительности — точке, за которой дальнейшая оптимизация малополезна. Вам не нужно записывать эти цифры на карточке или сразу определяться с ними, но часто бывает полезно это сделать. Зачем две цифры? Нефункциональные требования, особенно оптимизация производительности, могут отнять бесконечное количество времени. Иногда вы рано достигаете наилучшей цели: так вы узнае́те, когда пора остановиться. В других случаях у вас могут быть сложности в достижении приемлемой цели: благодаря этому вы понимаете, когда продолжать. Например, критерий производительности для веб-страницы может быть таким: «Поддерживать 500–1000 запросов в минуту, с задержкой 50–200 мс». Как и истории для багов, нефункциональные истории может быть трудно измерить. Для них вы также можете применять ограничения по времени.

Истории для эксплуатации и безопасности Недостаточно просто сделать ПО для пользователей. Если это онлайн-ПО, то вы должны См. также сделать так, чтобы можно было мониторить его, Сборка для эксплуатации управлять им и обеспечивать безопасность. На(глава 15) пример, нужно, чтобы вы получали уведомление, когда производительность снижается, а также Вся команда (глава 7) требуется способ проводить аудиты безопасности и реагировать на нарушения. Заказчики в команде часто с трудом понимают подобные истории, поэтому важно, чтобы люди с навыками эксплуатации и безопасности участвовали в процессе

192  Часть II.  Фокус на ценность планирования. Чтобы помочь заказчикам в команде определить приоритет этих историй, обсудите их в терминах той ценности, которую они обеспечивают, а не той технической работы, которая должна быть проделана. Часто ценность проявляется в виде снижения риска. Например, история о добавлении распределенной трассировки может звучать так: «Облегчить поиск источника проблем с производительностью во время сбоев производительности (распределенная трассировка)».

Спайк-истории Иногда разработчики не могут оценить разЦель спайк-истории в том, чтобы мер истории, поскольку недостаточно знают измерить другую историю. о технологии, необходимой для ее реализации. Когда это случается, создайте спайкисторию (spike story) для исследования технологии. Цель такой истории в том, чтобы измерить другую историю, а не выработать решение или исследовать все ее уголки и закоулки. Например, «разобраться, нужно ли разделить историю “отправить электронное письмо HTML” на более мелкие истории». Или более кратко: «спайк “отправить электронное письмо HTML”». Они называются спайк-историями, поСм. также скольку часто используют спайк-решение для исследовательской работы. Но это Спайк-решения (глава 13) не обязательно.

Истории для очистки (clean-up stories) Ожидается, что Agile-команды будут рабоСм. также тать таким способом, который позволяет им работать бесконечно долго. Это возможно Резерв времени (глава 9) благодаря наличию достаточного количества свободного времени в их графике, позволяющего постоянно совершенствовать свою кодовую базу. Если вы правильно организуете этот резерв, то вам не нужно специально планировать время на очистку. Части кода, над которыми вы работаете чаще всего, со временем автоматически становятся чище. Тем не менее иногда вы наследуете плохой код, и тогда стоит потратить дополнительное время на его очистку. Как и все другие истории, истории для Вам не нужны обязательные истории очистки должны быть ориентированы на для очистки, чтобы поддерживать заказчика. И они должны быть полностью чистоту вашего кода. необязательными. Вам не нужны обязательные истории для очистки, чтобы поддерживать чистоту вашего кода. Никто не захочет оказаться в ситуации, когда разработчики должны просить у заказчиков разрешения выполнить необходимую им работу или заказчики вынуждены просить разрешения у разработчиков пропустить какую-либо историю.

Глава 8.  Планирование  193

Если вы все же делаете отдельную историю для очистки кода, говорите о ней в терминах бизнес-выгоды, которую она дает. Часто эта выгода заключается в уменьшении количества времени, необходимого на разработку. Плохой код подвержен ошибкам, и, как правило, нужно много времени, чтобы безопасно его изменить. Так, например, вместо того чтобы говорить, что нужен «рефакторинг сервиса аутентификации», скажите, что требуется «уменьшить вероятность ошибок аутентификации» или «уменьшить время, необходимое для изменения параметров аутентификации». Скорее всего, вы не сможете количественно оценить подобное улучшение, но будьте готовы привести примеры, иллюстрирующие потенциальные преимущества. Например, такие: «Вы знаете, что мы продолжаем сталкиваться с проблемами и задержками, когда меняем что-то связанное с входом в систему? Так вот, то, что мы предлагаем, решит данную проблему». Работая с историями для очистки, не имеющими четкого момента, когда надо остановиться, используйСм. также те временные рамки. Чтобы убедиться, что вы можете Рефлексивный дизайн остановиться, когда ваше время истекло, избегайте (глава 14) полного переписывания кода. Вместо этого делайте его постепенный рефакторинг, поддерживая код в раРефакторинг (глава 13) бочем состоянии в любое время.

Совещания и другие организационные мероприятия Не создавайте отдельные истории для таких действий, как игра в планирование, общие собрания и другие организационные мероприятия. Если у вас есть нестандартные обязательства, привязанные к определенному времени, например тренинг или рабочие задачи вне офиса, то просто планируйте, что сделаете меньше историй на этой неделе.

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

См. также Рефлексивный дизайн (глава 14) Рефакторинг (глава 13)

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

194  Часть II.  Фокус на ценность Даже если заказчик понимает истории, ориентированные на разработчика, все же истории, Ваш план должен отражать ориентированные на заказчика, ведут к формиценность, и то же самое верно для историй. рованию более качественных планов. Ваш план должен отражать ценность, и то же самое верно для историй. Если ваши заказчики сами являются разработчиками (если вы разрабатываете ПО для разработчиков, например библиотеку или фреймворк), то ваши истории могут использовать ориентированный на разработчиков язык. Но даже в этом случае они должны отражать точку зрения вашего заказчика. Создавайте истории о потребностях вашего заказчика, а не о деталях реализации. Разве разработчики не должны делать программное обеспечение быстрым по умолчанию? Зачем нам нужны истории о производительности? В разработке ПО ничего не бывает бесплатно. Вы не обязаны создавать истории о производительности, но вам нужно знать, что означает «быстрый» в вашей ситуации, а разработчикам понадобится потратить время, чтобы это реализовать. Разбивка нефункциональных требований на отдельные истории не меняет количества необходимого на это времени; она просто позволяет вам лучше понимать, как тратится данное время, и контролировать этот процесс. Как нам найти время на техническую инфраструктуру и обширный рефакторинг, например, на замену тестового фреймворка? Выполняйте работу подобного рода инСм. также крементно, используя эволюционный дизайн и резерв времени в графике вашей Инкрементный дизайн (глава 14) команды. Обширный рефакторинг вы моРефлексивный дизайн (глава 14) жете выполнять с помощью историй для очистки, но все же обычно лучше подходит Резерв времени (глава 9) инкрементная работа.

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

См. также Инкрементные требования (глава 8)

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

Глава 8.  Планирование  195 zz zz

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

Альтернативы и эксперименты Основное различие между историями и составными элементами большинства планов заключается в том, что истории ориентированы на заказчика. Если вы по какой-либо причине не можете использовать такие истории, то заказчики не смогут эффективно участвовать в планировании. Это сведет на нет одно из основных преимуществ Agile — возможность создавать лучшие планы, объединяя знания и представления заказчиков и разработчиков. Кроме того, вам будет трудно демонстрировать прогресс стейкхолдерам. К сожалению, никакая другая практика здесь не поможет. Истории — простая идея, но они связаны с вечной проблемой разработки ПО: как принять решение, что именно создавать. Простая идея в сумме с серьезной проблемой приводят к тому, что у каждого участника имеется собственный взгляд на истории. Вы можете найти онлайн любые шаблоны и советы по написанию историй. Все они будут претендовать на то, что смогут решить эту проблему или что с ними команда будет лучше писать ПО. Все эти эксперименты, как правило, упускают суть. Истории — для разговора, а не для бумаги. Любое изменение, которое направляет фокус на документирование, а не на общение (шаблон, детализация, систематизация историй), движется в неверном направлении. Подобным же образом истории — не способ решать, что вы будете создавать. Они служат лишь напоминанием. Есть много очень хороших способов понять потребности заказчиков и бизнеса и претворить это понимание в жизнь. (О некоторых из них рассказывается в разделе «Визуальное планирование» далее в текущей главе.) Не используйте истории для формирования понимания бизнеса. Сначала сформируйте для себя понимание бизнеса, примите решение и используйте истории, чтобы напомнить себе об этих решениях и их обсуждениях. Джефф Паттон говорит, что истории — как фотографии из отпуска: напоминают вам, что происходило. Истории просто служат напоминанием, поэтому не должны быть сложными. Когда будете экспериментировать с историями, подумайте о том, чтобы придать большее значение разговорам и меньшее значение самой истории, при этом сделав достаточно для того, чтобы напомнить людям предмет обсуждения и принятое решение. Улучшайте отпуск, а не фотографии. Наконец, еще одной распространенной альтернативой является отслеживание историй в электронной таблице или инструменте отслеживания (трекинга) задач, а не на индексных карточках. Это может облегчить чтение списков историй, но затрудняет визуализацию и взаимодействие. Это потеря, которую трудно оценить, не имея определенного опыта. Поработайте с карточками по меньшей мере три месяца, прежде чем пробовать альтернативы. Даже если у вас виртуальная команда, лучше используйте виртуальные индексные карточки на виртуальной доске, а не таблицы и системы трекинга.

196  Часть II.  Фокус на ценность

АДАПТИВНОЕ ПЛАНИРОВАНИЕ Мы рассчитываем на успех. Аудитория

Представьте, что вас освободили от предваПродакт-менеджеры, рительных планов. «Увеличьте рентабельность заказчики инвестиций, — сказал ваш босс. — Мы уже обсуждали цели этой команды. Я рассчитываю, что вы проработаете детали. Можете написать собственные планы и сами установить даты релизов — просто сделайте так, чтобы мы получили действительно ценный продукт». И что теперь?

Ценные инкременты Создавайте ваши планы на Создавайте ваши планы на основе ценных иноснове ценных инкрементов. крементов (valuable increments)1. У них есть три характеристики. 1. Пригодность для релиза. Заканчивая работу над инкрементом, вы можете его выпустить и пожинать плоды своих усилий, даже если никогда больше не будете над ним работать. 2. Ценность. Данный инкремент некоторым образом приносит ценность вашей организации (см. врезку «Что ценно для организаций?» в главе 3). 3. Инкрементность. Инкремент не делает все сразу. Это только один шаг в нужном направлении. Не путайте ценные инкременты (valuable increments) с потенциально поставляемыми инкрементами (potentially shippable increments) — еще одним общим термином в сообществе Agile. Последние касаются наличия технической возможности у команды делать релизы изменений. Ценные инкременты — это те изменения, которые действительно приносят ощутимую пользу вашему бизнесу. Точно так же ценный инкремент может быть выпущен только тогда, когда достигнута его ценСм. также ность. Команды, использующие непрерывное развертывание, могут разворачивать свое ПО неНепрерывное развертывание сколько раз в день, но оно не будет выпущено до (глава 15) тех пор, пока не будет переключена конфигурация и данное улучшение продукта не станет доступно его целевой аудитории. Ценные инкременты обычно подпадают под следующие категории. zz Прямая ценность. Вы создаете, меняете или ремонтируете что-либо имеющее ценность. Оно становится выпущенным, когда ваша организация может пожинать В первом издании этой книги вместо этапов улучшения продукта, или инкрементов (valuable increments), я использовал термин «минимальная рыночная функция» (Minimum Marketable Feature, MMF) из [Denne2004]. Инкременты представляют ту же идею, но я изменил название, поскольку не все то, что ценно, является востребованным на рынке или функциональным.

1

Глава 8.  Планирование  197

zz

zz

плоды этих усилий. Например, если вы хотите улучшить удержание заказчиков, добавив новый отчет, то сможете считать, что сделали релиз этого отчета, когда его смогут использовать реальные заказчики. Исследовательская ценность. Вы проводите эксперимент, который должен дать вам представление о том, как повысить ценность. Можно считать ваш эксперимент выпущенным, когда он готов к запуску, включая решение о том, как интерпретировать результат. Например, если вы предполагаете, что можно увеличить количество регистраций клиентов, изменив процедуру регистрации, но не уверены, какая процедура лучше, то можете использовать A/B-тестирование1. Релиз этого эксперимента считается сделанным, когда A/B-тест активен, момент оценки данных определен, как и критерий для сохранения или отказа от новой процедуры. Ценность функций. Вы создаете возможность отложить или изменить решение, чтобы можно было воспользоваться преимуществом какой-либо ценной перспективы в будущем. Она считается выпущенной, когда вы можете без проблем отложить или изменить свое решение. Например, если вы думаете, что ваш поставщик пытается создать благоприятные для себя условия, чтобы поднять свои цены, то можете изменить свое ПО таким образом, чтобы оно поддерживало второго поставщика. Эта функция будет считаться выпущенной, когда вы сможете переключаться между поставщиками по своему желанию.

Инкрементам, имеющим исследовательскую ценность и ценность функций, требуется, чтобы люди чувствовали себя комфортно в условиях неопределенности и неоднозначности. Поэтому, хотя эти инкременты может применять любая команда, чаще они используются командами оптимизации. Вы будете отслеживать ценные инкременты См. также с помощью историй в вашем визуальном плане. Например, в предыдущем примере может быть Истории (глава 8) записано «TPS-отчет», «A/B-тест процедуры регистрации» и «аутентификация, независимая от Визуальное планирование (глава 8) поставщика». При желании вы можете добавить более подробные пояснения, но для большинства Цель (глава 7) продакт-менеджеров, которых я встречал, коротИнкрементные требования кой фразы было достаточно для напоминания. (глава 8) Вы должны уметь сформулировать три вещи: 1) почему этот инкремент ценен; 2) как его ценность соотносится с целью команды; 3) что означает «выпущен, сделан релиз» для этого инкремента на высоком уровне. Детали определяются позже (см. подраздел «Как создать план» далее в данной главе).

A/B-тестирование — это когда вы показываете разные элементы различным группам людей и оцениваете, какой из элементов дает лучшие результаты.

1

198  Часть II.  Фокус на ценность

Фокус на один инкремент за раз Стейкхолдеры любят, когда команды Фокус на выполнении одного работают одновременно над множеинкремента за раз улучшит скорость ством идей. Чувствуется, что делается поставки и повысит ценность. много работы и вся она имеет максимальный приоритет! Все так просто. И очень-очень расточительно. Фокус на выполнении одного инкремента за раз улучшит скорость поставки и повысит ценность. Рассмотрим команду, работающую над тремя инкрементами (рис. 8.1). В этом упрощенном примере все инкременты имеют одинаковую ценность: по завершении каждый из них будет приносить 4 доллара ежемесячно. Выполнение каждого занимает два месяца.

Рис. 8.1. Результат фокусирования внимания на ценности

Глава 8.  Планирование  199

В сценарии A команда работает над всеми тремя инкрементами одновременно. Завершение всех трех занимает шесть месяцев. Закончив, команда начинает получать 12 долларов ежемесячно. В сценарии Б команда фокусируется на выполнении одного инкремента за раз. Она делает релиз своего первого инкремента через два месяца — одну треть времени сценария А. Он начинает зарабатывать деньги, пока команда работает над следующим инкрементом. К концу седьмого месяца она заработала 36 долларов за то время, которое понадобилось сценарию А, чтобы заработать 12 долларов. И это без учета затрат на переключение между задачами и преимуществ более раннего выхода на рынок. Это легко полученные деньги. Чем чаще вы делаете релиз, тем больше поЧем чаще вы делаете релиз, лучаете, как показывает сценарий В. Он такой тем больше получаете. же, как сценарий Б, за исключением того, что команда научилась делить каждый из своих инкрементов пополам. Вместо того чтобы делать релиз инкремента стоимостью 4 доллара через два месяца, она делает релиз инкремента стоимостью 2 доллара через месяц. Через семь месяцев команда заработает 42 доллара. Конечно, некоторые идеи более ценны, чем другие. Сценарий Г показывает, что произойдет, если вы отделите наиболее ценные части и будете работать над ними в первую очередь. Этот сценарий такой же, как сценарий В, но инкременты имеют разную ценность. Изменение порядка таким образом, чтобы сначала делать релизы наиболее ценных инкрементов, позволяет сценарию Г заработать 50 долларов. Это три месяца легких денег по сравнению со сценарием А. В этом суть свободного владения навыками на уровне фокусировки. Фокус на небольших ценных инкрементах. Фокус на выпуске одного инкремента за раз. Фокус на релизе наиболее ценных идей в первую очередь. После каждого релиза используйте любую новую информацию, которую вы получили, адаптируйте ваши планы и сфокусируйтесь на наиболее ценном из оставшихся. Сценарии на рис. 8.1 упрощенные. В книге Software By Numbers [Denne2004] (гл. 2) приводится более сложный пример (табл. 8.1), основанный на реальном продукте. В своем примере авторы конвертируют пятилетний проект с двумя релизами в конце проекта (сценарий А) в пять ежегодных релизов, упорядоченных по ценности (сценарий Б). Производительность команды одинаковая в каждом сценарии. Таблица 8.1. Реалистичный пример фокусировки на ценности Сценарий А

Сценарий Б

Общие затраты

4,312 млн долларов

4,712 млн долларов

Выручка

5,600 млн долларов

7,800 млн долларов

Инвестиции

2,760 млн долларов

1,640 млн долларов

Возврат

1,288 млн долларов

3,088 млн долларов

Чистая приведенная стоимость @ 10 %

0,194 млн долларов

1,594 млн долларов

Внутренняя норма доходности

12,8 %

36,3 %

200  Часть II.  Фокус на ценность Сценарий А — маржинальные инвестиции с доходностью 12,8 %. Этот сценарий требует инвестиций 2,8 млн долларов и принесет прибыль 1,3 млн долларов. Учитывая риск разработки ПО, инвесторы могут с большей выгодой вложить эти деньги в другой проект. Сценарий Б (тот же самый продукт с более частыми релизами) — отличная инвестиция с доходностью 36,3 %. Хотя затраты при сценарии Б больше из-за проведения большего количества релизов, эти релизы дают продукту возможность быть самофинансируемым. В результате ему потребуется меньше инвестиций (1,6 млн долларов) и он принесет прибыль 3,1 млн долларов. Этот сценарий заслуживает финансирования. Взгляните еще раз на эти примеры. Каждый показывает впечатляющие приросты в ценности. При этом ничего не меняется, кроме способа релизов ПО командами.

Разделите инкременты Как показали примеры, чем меньше будут инкременты, на которые вы разделите ваш продукт, тем более ценной будет работа вашей команды. Помимо этого, каждый инкремент представляет собой возможность изменить направление, не понеся потерь. Если вы измените направление в середине работы над инкрементом, то она будет выполнена частично и ее придется отложить на неопределенный срок или выбросить. Когда же инкремент завершен, вы можете изменить направление работы, ничего не теряя. Чем меньше будут ваши инкременты, тем чаще вы можете адаптировать ваши планы и тем больЧем меньше будут ваши ше вы будете соответствовать философии Agile. инкременты, тем больше В идеальном мире ваши инкременты должны вы будете соответствовать быть разделены на самые мелкие базовые фрагфилософии Agile. менты, которые все еще могут иметь ценность, оправдывающую их релиз. В реальном мире трудно сделать эти инкременты настолько маленькими, особенно поначалу. Со временем вы, вероятно, научитесь видеть способы дальнейшего разделения инкрементов. Можно начать с лучшего предположения и разделить их позже. Agile — итеративный процесс. У вас будет множество возможностей для совершенствования. КЛЮЧЕВАЯ ИДЕЯ

Минимизируйте объем незавершенной работы Незавершенная работа (Work in progress, WIP) — это работа, которая была начата, но пока не завершена релизом. Agile-команды стараются минимизировать ее по нескольким причинам. Во-первых, это инвестиция, которая ожидает возврата. Как показано на рис. 8.1 (см. выше), чем чаще вы делаете релиз (чем меньше у вас незавершенной работы), тем выше окупаемость инвестиций, вложенных в вашу работу.

Глава 8.  Планирование  201

Во-вторых, WIP делает изменения более затратными. Когда вы меняете ваши планы, любую недоделанную работу нужно отложить. Со временем решения, которые вошли в эту работу, устаревают и должны быть переделаны. Код для незавершенных инкрементов особенно затратный: он либо увеличивает размер и стоимость поддержки вашей рабочей кодовой базы в эксплуатационной среде, либо должен храниться в отдельной ветви, которую становится все более сложно слить с эксплуатационной средой. Метафорически можно сказать, что незавершенная работа ржавеет. Ее нужно или обслуживать, или переделывать, или выбросить. А это затратно. Сведите ее к минимуму.

Делайте частые релизы и как можно раньше Вы можете выпускать новые версии ваСм. также ших инкрементов сразу, как только каждый из них готов, или можете дожидаться Непрерывное развертывание (глава 15) и собирать вместе несколько таких инкрементов, чтобы выпустить их одновременно в одном релизе. Хотя немедленный выпуск более ценен, иногда может быть эффективнее вывести на рынок несколько улучшений одновременно, чем выкладывать их по очереди. И похожим образом, если имеются изменения в пользовательском интерфейсе или другие расходы, связанные с релизом, то может быть проще покрыть эти расходы разом, чем постоянно делать небольшие изменения. ПРИМЕЧАНИЕ Некоторые команды используют практику непрерывного развертывания для развертывания своего кода несколько раз в день, но развертывание кода — это не то же самое, что релиз инкремента. Релиз инкремента не выполнен до тех пор, пока недоступен для использования. Для команд, использующих непрерывное развертывание, в релиз обычно входит изменение параметров конфигурации.

Иногда команды объединяют инкременты, поскольку технические ограничения делают частые релизы слишком затратными. Так делать можно, если вам это необходи­ мо, но будьте честны с собой насчет причин этого. Вдобавок к высоким затратам на рели­ зы вы несете дополнительные расходы, связанные с увеличением количества незавершен­ ной работы. Вы можете устранить оба вида затрат путем инвестирования в свободное владение навыками на уровне поставки. Некоторые команды планируют реПоезд всегда должен отбывать вовремя, лизы с помощью процесса релизов по распо расписанию. писанию, поезда с релизами (release train). Он представляет собой запланированную серию релизов, например, первый понедельник каждого месяца. Завершенные инкременты «садятся в поезд» и добавляются в данный релиз. Остальные ждут

202  Часть II.  Фокус на ценность следующего поезда. Неважно, насколько они близки к завершению, поезд всегда должен отбывать вовремя, по расписанию. ПРИМЕЧАНИЕ Фреймворк SAFe определяет Agile Release Train как контейнер для команд, что является неудачным переопределением термина1. Здесь я использую более простое оригинальное определение. Поезд с релизами — это просто запланированное расписание релизов. Не придавайте ему дополнительного смысла.

Поезда с релизами имеют множество преимуществ. Они дают маркетологам повод для праздника, а пользователям — дату для ожидания. Они позволяют стейкхолдерам быть уверенными в том, когда ожидать прогресса, и снимают давление с команд, которые (пока их инкременты короче, чем цикл релизов) могут подтверждать даты релизов, не беспокоясь о том, что именно они будут выпускать в каждую дату. В то же время решение отложить релиз инкремента как для объединения его с другим в единый релиз, так и для поезда с релизами в целом является решением отложить ценность. Кроме того, организации склонны использовать поезда с релизами, чтобы скрыть технические и организационные недостатки, препятствующие более частым релизам. Когда вы будете думать о своей стратегии релизов, ищите компромисс между преимуществами, которые дает объединение инкрементов, и ценой, которую придется заплатить за задержку их ценности, и будьте честны сами с собой в отношении причин такой задержки. К А Р ГО - К УЛ ЬТ

Вагон для скота Ваш релиз-менеджер, Иезекиль, созвал на встречу всех владельцев продукта: «Следующий поезд с релизами отправляется через три месяца! Что вы обязуетесь поставить?» Вы быстро обмениваетесь взглядами с Лавоной, одной из владелиц продукта, и она изображает взмах кнутом. Вы сдерживаете ухмылку и спешно надеваете маску «командного игрока», как только Иезекиль обращает на вас внимание. На прошлой неделе вы заставили свою команду сделать оценки и взять на себя обязательства, но с каждым кварталом ребята становятся все более угрюмыми. «Хештег — без оценок!» — сказала потом Роза, ваш лучший разработчик, прежде чем подать уведомление об увольнении. Вы информируете Иезекиль о принятом

Термин «поезд с релизами» появился задолго до SAFe. Самые ранние известные мне упоминания о нем есть в фреймворке разработки программного обеспечения 1993 года от компании Sun, который определяет этот термин таким же образом, как и я в этой книге. Данный документ отсутствует в публичном доступе, но [Rothman1998] ссылается на этот термин и использует похожее определение. Большое спасибо Говарду Феару и Дэйву Хаунслоу за то, что нашли эти ссылки.

1

Глава 8.  Планирование  203

обязательстве, но уже переживаете о том, на что будут похожи следующие три месяца. Когда вы медленно бредете со встречи, Лавона идет рядом, издавая тихое мычание: «Му-у-у-у-у. Ты же знаешь, что коровы в поезде едут на бойню, да?» — говорит она. Вы киваете и вздыхаете. «Я знаю, кто возьмет на себя ответственность, если мы не справимся с этой поставкой». Лавона останавливается и смотрит вам в глаза. «Я тут проводила небольшое исследование. Agile не должен быть таким. Мы не должны подстегивать наши команды, а потом принимать вину на себя, когда что-то не получается». «Конечно, — соглашаетесь вы. — Роза говорит, что мы работаем по итеративному “водопаду”, а не по Agile, но что мы можем сделать?» Лавона улыбается: «Здесь? Не очень много. Но у меня есть предложение о работе, и они хотят, чтобы я привела с собой еще одного хорошего продакт-менеджера. Ты участвуешь?» Она рассказывает подробности, и ваше настроение улучшается. Пришло время сойти с этого поезда.

Ваш первый инкремент Ваш первый инкремент может быть непростым. Ему нужно быть достаточно содержательным, чтобы быть интересным, но не настолько, чтобы вы ради него задерживали релиз. Один из способов думать о вашем первом инкременте — использовать термин минимально жизнеспособный продукт (Minimum Viable Product, MVP). Вопреки обычному пониманию этого термина, MVP — это не самый маленький продукт, пригодный для успешного релиза. Это скорее способ подтверждения ваших идей продукта. Эрик Рис определяет этот термин в своей очень авторитетной книге The Lean Startup1 следующим образом: Минимально жизнеспособный продукт (MVP) помогает предпринимателям как можно скорее начать процесс обучения. Однако это не обязательно минимальный продукт, который только можно себе представить; это просто самый быстрый способ пройти через цикл обратной связи «Создать — измерить — узнать» (Build — Measure — Learn), приложив минимум усилий. В отличие от традиционной разработки, которая обычно подразумевает длительный инкубационный период и стремится к совершенствованию продукта, MVP ставит целью начать процесс обучения, а не закончить его. В отличие от испытаний прототипов или тестов концепции, MVP предназначен не только для того, чтобы ответить на вопросы о дизайне продукта или его технической реализации. Его цель — проверить фундаментальные бизнес-гипотезы [Ries2011] (гл. 6). Эрик Рис 1

Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.

204  Часть II.  Фокус на ценность MVP — это не обязательно релиз или продукт в традиционном смысле. Это эксперимент, и он может быть у вас не один. По сути, настоящие MVP наиболее часто используются командами оптимизации. Является ли ваш первый инкремент минимально жизнеспособным продуктом в понимании Эрика Риса или просто наименьшим инкрементом, который понравится вашим покупателям и пользователям, зависит от вас.

Пример инкремента В 2005 году маленькая команда запустила Writely, онлайн-приложение для обработки текстов. В те годы, как и сейчас, рынок текстовых процессоров был уже достаточно развитым, поэтому создание минимального первого инкремента такого продукта могло казаться невозможным. Нужно было приложить много усилий, просто чтобы вступить в соревнование, не говоря уже о том, чтобы выдать что-то новое и убедительное. В необходимый набор функций входили базовое форматирование, проверка орфографии и грамматики, таблицы, рисунки, печать… список мог быть бесконечным. Вместо того чтобы вступить в соревнование, Writely сосредоточился на функцио­ нальностях, которые могли выделить его среди остальных: совместная работа, удаленное редактирование документов, надежное онлайн-хранилище и простота использования. Команда создала минимум, достаточный для того, чтобы проверить свою концепцию. По словам венчурного предпринимателя Питера Рипа, разработчики выпустили первую альфа-версию Writely через две недели после того, как решили его создать1. Конечно, вы могли никогда не слышать о Writely. Был ли их инкрементный подход неуспешен? Совсем нет. Через восемь месяцев после запуска Writely компанию купили. Сейчас она известна как Google Docs.

Адаптируйте свои планы Вы начнете думать о вашем первом инкременте до того, как будет написана первая строчка кода. Это тот момент, когда вы меньше всего знаете о том, что сделает продукт ценным. Вы даже можете знать многое, но всегда будете знать больше, после того как поговорите со стейкхолдерами, покажете им демо и сделаете реальные релизы. Со временем вы обнаружите, что некоторые ваши изначальные представления о ценности были неверными. Если вы измените план так, чтобы он отражал ваше новое знание (адаптируете его), то создадите более ценный результат. Думайте о вашем плане, что это и план Чтобы повысить ценность вашего ПО, изучения, и план создания. создайте возможности для обучения. Источники: сайт Writely и блог Питера Рипа. Страниц больше нет в сети, но их можно найти в интернет-архиве: домашняя страница Writely (https://oreil.ly/NWG6C), Writely is the seed of a Big Idea (https://oreil.ly/L2qmo), Writely — The Back Story (https://oreil.ly/DRv5X).

1

Глава 8.  Планирование  205

Думайте о вашем плане, что это и план изучения, и план создания. Сфокусируйтесь на том, что вы не знаете. В чем вы не уверены? Что могло бы быть хорошей идеей? Какие хорошие идеи вы можете проверить и подтвердить на практике? Не гадайте, создавайте инкременты для изучения. Тестируйте каждую неясность, затем адаптируйте план. Например, если бы вы создавали онлайновый текстовый процессор, то могли бы не знать точно, насколько обширной должна была быть ваша поддержка импорта документов Microsoft Word. Какая-то поддержка необходима, но какая? Реализация поддержки всех документов Word займет много времени. Добавление других, возможно более ценных, функциональностей также потребует времени. В то же время недостаточная поддержка может подорвать доверие к вам и привести к потере клиентов. Чтобы проверить эту неясность, вы можете добавить в ваше ПО элементарную функцию импорта (ясно обозначив ее как экспериментальную), выпустить ее и собрать сообщения о типах документов, которые пользователи пытаются импортировать. Информация, которую вы соберете, поможет вам адаптировать план и повысить ценность вашей команды. ПРИМЕЧАНИЕ Пользователи сетевого ПО привыкли к бета-версиям веб-приложений, так что в этом случае выпуск экспериментальной, незавершенной функциональности возможен. Чтобы выпустить продукт, предназначенный для более требовательных пользователей, может понадобиться использовать программу пререлиза, фокус-групп или какой-либо другой механизм получения обратной связи.

КЛЮЧЕВАЯ ИДЕЯ

Последний ответственный момент Agile-команды откладывают принятие необратимых решений до позднейшего ответственного момента1. Принятие решений в позднейший ответственный момент снижает ваши затраты и повышает вашу приверженность идеям Agile. Представьте, что вы злой деспот, действующий в условиях жесткого графика. Вы пообещали вашему императору, что вернете проект строительства его новой игрушки для уничтожения планет обратно в рамки графика. А теперь все застопорилось. Были кое-какие сложности, которые вы не могли предвидеть. Чтобы сохранить лицо, вы говорите императору, что его новая боевая машина полностью вооружена и в рабочем состоянии, хотя это не совсем так. А дальше, как вы знаете, отважная группа фотогеничной молодежи уничтожает вашу Звезду Смерти. Опять. Чем раньше вы принимаете решение, тем больше вероятность, что вы упускаете что-то важное. И если это так, то вы должны либо переделать работу, либо смириться с плохим решением. Это расточительно. Ожидая позднейшего

1

Lean Construction Institute ввел термин «позднейший ответственный момент». [Poppendieck2003] популяризировал его применительно к разработке ПО.

206  Часть II.  Фокус на ценность

ответственного момента, вы повышаете свою информированность, что дает вам возможность выбирать лучшие решения, которые, в свою очередь, приведут к меньшим потерям. При этом будет проще вносить изменения, поскольку у вас будет меньше работы, которую придется отменить или переделать. Обратите внимание, что используется выражение «позднейший ответственный момент», а не «позднейший возможный момент». Как говорит [Poppendieck2003], принимайте критическое решение «в тот момент, когда непринятое решение приведет к потере важной альтернативы. Если обязательство откладывается на период после позднейшего ответственного момента, то принимается решение по умолчанию, что в принципе не является хорошим подходом к принятию решений».

Как создать план Инкременты являются строительными блоками вашего плана, но не имеют никаких деталей. Проработка деталей требует много времени и труда. Хуже того, когда возникает необходимость адаптировать планы, часть этого труда может отправиться в мусор. Чтобы снизить потери и облегчить процесс планирования, применяйте метод наСм. также бегающей волны, предполагающий планироЦель (глава 7) вание в позднейший ответственный момент. При использовании этого метода детали доВизуальное планирование (глава 8) бавляются постепенно, точно перед тем, как Игра в планирование (глава 8) в них возникает необходимость. Период, на Планирование задач (глава 9) который каждый уровень детализации смотрит в будущее, называется горизонтом плаИнкрементные требования (глава 8) нирования. Планы в Agile имеют несколько горизонтов планирования (рис. 8.2). 1. Начните с цели команды, в которую будет входить ее миссия. 2. Используйте визуальное планирование для создания карты возможных ценных инкрементов, необходимых для выполнения миссии. 3. Продолжайте использовать визуальное планирование, чтобы разбить первые несколько инкрементов на наименьшие ценные инкременты, которые вы сможете придумать. 4. Используйте игру в планирование, чтобы еще больше разбить первые мелкие инкременты, в истории размером «в самый раз». 5. Применяйте планирование задач, чтобы разбить первые несколько историй на задачи разработки. 6. Непосредственно перед началом разработки истории используйте инкрементные требования, чтобы определить детали требований.

Глава 8.  Планирование  207

Рис. 8.2. Горизонты планирования

В подразделе «Ваша первая неделя» главы 9 рассказывается, как начать работу. Как только план будет готов, вы начнете использовать систему вытягивания для его выполнения. В такой системе вместо того, чтобы делать работу запланированными интервалами, вы делаете ее по требованию. В этом случае «вытягивание» происходит вследствие завершения задач. 1. Когда ваша команда завершает выполнение своих задач, ей нужны следующие. Вы планируете задачи, вытягивая истории из визуального плана на вашу командную рабочую доску, где разбиваете их на задачи. 2. В процессе вам может понадобиться больше историй. Когда это происходит, вам нужно запланировать сессию игры в планирование и вытянуть истории из вашего следующего маленького ценного инкремента. 3. Когда вы закончите один инкремент, вам нужно использовать визуальное планирование, чтобы вытянуть следующий маленький инкремент из ваших возможных инкрементов. 4. А когда вам понадобится больше идей для возможных инкрементов, вы вытянете их из ваших цели и миссии. 5. И наконец, приблизившись к завершению вашей миссии, вы пойдете к своему спонсору и вытянете новую миссию из концепции и цели вашей команды.

208  Часть II.  Фокус на ценность Как показывает рис. 8.3, для каждого уровня детализации нужны разные навыки.

Рис. 8.3. Навыки планирования

Пример плана Представьте, что ваша команда отвечает за сайт онлайн-магазина. Как в вашем случае планировать методом набегающей волны? Ниже представлен упрощенный пример, который показывает, как уровни детализации сочетаются друг с другом. 1. Цель. Общее ви́дение вашей команды — быть ведущим продавцом в вашей рыночной нише. Ваша специальная миссия — улучшить коэффициент конверсии: сделать так, чтобы больше людей посещало сайт с целью что-либо купить. 2. Возможные ценные инкременты. Чтобы выполнить эту миссию, вы думаете о нескольких возможных ценных инкрементах. Одна из идей — улучшить работу сайта на мобильных устройствах. Другая — улучшить страницу оформления заказа. Третья — улучшить работу поиска. Четвертая — предоставлять кури­ руемые обзоры товаров. 3. Наименьшие ценные инкременты. Обсудив идеи с различными стейкхолдерами, вы решаете, что улучшение страницы оформления заказа будет наиболее выгодным. Многие покупатели уходят с сайта, дойдя до этой страницы. Вы предлагаете идеи наименьших ценных инкрементов, какие только можете придумать: поддержку подарочных карт, запоминание данных кредитных карт покупателей, добавление поддержки купонов, поддержку PayPal и т. д. 4. Истории размером «в самый раз». Как показывает ваше исследование рынка, покупателям из Европы менее комфортно использовать кредитные карты

Глава 8.  Планирование  209

онлайн, и ваша статистика говорит о том, что максимальное количество прерванных попыток заказа совершают именно европейцы. Вы решаете, что вашим следующим инкрементом будет поддержка PayPal. Вы собираете всю команду, чтобы разбить инкремент на более мелкие составляющие. Вместе вы разрабатываете более подробные истории, в том числе: «Встроить PayPal в страницу оформления заказа», «Разрешить использование PayPal для подписок», «Обработка ошибок PayPal», «Обработка сбоев PayPal», «Возврат платежей через PayPal», «Интерфейс поддержки покупателей для оплаты через PayPal». 5. Задачи. Во время планирования задач вы выбираете несколько историй, над которыми команда будет работать в первую очередь, и разработчики разбивают их на задачи. «Интерфейс поддержки покупателей для оплаты через PayPal» получает такие задачи, как «Перенести CS UI в текущую версию фреймворка фронтенда», «Добавить PayPal к фронтенду CS» и «Добавить PayPal к бэкенду CS». 6. Детали. Пока разработчики закладывают основы, UX-дизайнер команды создает макет, показывающий потенциальные изменения в поддержке пользовательского интерфейса, и просматривает его с представителями отдела клиентской поддержки. После этого разработчики используют макет в качестве руководства для изменений, потом просматривают окончательный результат с другими локальными заказчиками и отделом клиентской поддержки.

Баланс адаптивности и предсказуемости Каждый уровень детализации в вашем плане имеет соответствующий горизонт планирования. Например, рис. 8.2 показывает, что задачи планируются на следующую неделю, истории — на следующий месяц; маленькие инкременты планируются на следующие три месяца, а возможные — на следующие шесть месяцев. Эти горизонты планирования — только пример. Вы должны выбрать собственные, основываясь на том, как будете соблюдать баланс адаптивности и предсказуемости. Например, если ваши планы меняются значительно, то можете готовить истории размером «в самый раз» только за две недели и маленькие инкременты всего за один месяц до непосредственной даты начала работ. Вместе с тем если вашим стейкхолВыбирайте ваши горизонты дерам нужно больше определенности, то вы планирования, основываясь на можете создавать истории размером «в сатом, как будете соблюдать баланс мый раз» за три месяца и маленькие инкреадаптивности и предсказуемости. менты — за шесть месяцев до даты начала работ. Чем длиннее ваши горизонты планироСм. также вания, тем больший объем работы окажется напрасным в случае изменения ваших плаДорожные карты (глава 10) нов и тем больше людей будут сопротивляться изменениям. С другой стороны, боПрогнозирование (глава 10) лее длинные горизонты планирования часто

210  Часть II.  Фокус на ценность необходимы для хороших дорожных карт, а горизонт планирования ваших историй определяет, насколько далеко в будущее могут заглядывать ваши прогнозы релизов. В конечном итоге выбор горизонтов планирования — компромисс между меньшим количеством потерь и большей гибкостью, присущей Agile (более короткие горизонты планирования), и большей определенностью и предсказуемостью (более длинные горизонты планирования). Неправильного ответа тут нет; только выбор между компромиссами. Если вы не знаете, что выбрать, начните с горизонтов, показанных на рис. 8.2.

Адаптивное планирование в действии Через несколько лет после свадьбы мы с женой провели двухмесячный отпуск в Европе. Это была самая сложная поездка, которую мы когда-либо совершали. Мы знали, что не могли полностью спланировать ее заранее, поэтому выбрали адаптивный подход. Мы начали с нашего ви́дения этой поездки: договорились побывать во многих городах, вместо того чтобы оставаться на одном месте. Мы обсудили, какие страны хотели увидеть, но не приняли никаких решений, которые обязывали бы нас посетить конкретную группу стран. Мы определили позднейший ответственный момент для различных решений по нашей поездке. Авиабилеты обычно дорожают со временем, поэтому мы забронировали перелеты в Лондон и обратно за месяц и запланировали побыть там с родственниками в начале и в конце поездки. Гостиницы, однако, нужно было уведомить за несколько дней до приезда. Мы также предприняли шаги, которые дали бы нам больше возможностей. Мы нашли хороший путеводитель по Европе. Мы купили проездной EuroRail, позволявший использовать прекрасную европейскую систему железных дорог для путешествий по всему континенту. Мы заплатили несколько дороже за проездной, но он давал нам возможность посетить больше стран. Приняв эти общие решения, мы оставили детали на позднейший ответственный момент. Во время поездки, за несколько дней до выезда в направлении следующего места, мы принимали решение, какие именно страну и город посетим. Мы останавливались около железнодорожных станций, смотрели расписание отбытия поездов и при необходимости резервировали билеты. Мы смотрели информацию об отелях в нашем путеводителе, отправляли электронные письма трем наиболее понравившимся и продолжали наслаждаться прогулками по городу. На следующий день мы подтверждали одну из броней отеля. В последний день мы бездельничали и выбирали из расписания поездов время для выезда. Затем, через 4–5 часов, мы приезжали в следующий город, оставляли вещи в гостинице и отправлялись смотреть город. Такой подход не только давал нам свободу действий, но был еще и простым и расслабляющим. Поскольку мы бронировали номер за день или два до приезда, ни один отель никогда не терял и не путал наши бронирования. Если город нам нравился, то мы оставались в нем подольше. Если не нравился — уезжали раньше. В наш медовый месяц мы были рабами своих заранее подготовленных планов и все время беспокоились о деталях поездки. В этой же поездке, гораздо более

Глава 8.  Планирование  211

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

Адаптивное планирование и организационная культура Идея провести два месяца, путешествуя по чужой стране без определенного плана, выглядит пугающе? На практике все было просто и расслабляюще, но когда я рассказывал историю нашей адаптивно спланированной поездки в Европу (см. врезку «Адаптивное планирование в действии» чуть выше), люди заметно беспокоились. Организации часто похожим образом реагируют на адаптивное планирование. Адаптивный план работает на достижение цели команды. Однако точно так же, как мы в нашей поездке достигли своей цели («получить удовольствие от посещения множества европейских городов»), не выбирая заранее конкретные города, адаптивная команда достигнет своей цели, даже если не сможет точно сказать, что именно она будет поставлять. Никакой другой аспект Agile не бросает Никакой другой аспект Agile больший вызов организационной культуре, не бросает больший вызов чем адаптивное планирование. Оно требует организационной культуре, чем изменений не только в команде разработки, адаптивное планирование. но и в системах отчетности, оценки и управления. Последствия выбора адаптивного планирования удивительным образом распространяются на разные подгруппы вашего сообщества стейкхолдеров, и люди часто испытывают шок и демонстрируют эмоциональные реакции в ответ на эту идею. В результате вы, возможно, не сможете повлиять на процесс изменений, движущийся в сторону адаптивного планирования. Если у вас нет поддержки со стороны высшего руководства, то любые изменения будут медленными и постепенными. Даже с поддержкой руководства эти изменения займут много времени. Чтобы вводить адаптивное планирование постепенно, попробуйте работать См. также в рамках вашей организационной культуры. Используйте планирование методом набегаПрогнозирование (глава 10) ющей волны, но установите ваши горизонты

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

Вопросы Нам нужно принять на себя обязательство делать релиз в определенные даты. Как поступить? Прочитайте раздел «Прогнозирование» главы 10. Если вы делаете прогнозы по дате и объему работы, то вам могут понадобиться удлинение вашего горизонта плани­рования и, как правило, свободное владение навыками на уровне поставки, чтобы ваши прогнозы были полезны. Если мы не планируем детально наши релизы, то что мы должны говорить о наших планах стейкхолдерам? Вы можете не планировать заранее все нюансы ваших релизов, однако все же можете показать стейкхолдерам дорожную карту. Если им нужно много деталей, то вам, возможно, понадобится удлинить ваш горизонт планирования (см. раздел «Дорожные карты» главы 10). Если мы используем короткие горизонты планирования, то как мы можем быть уверены, что достигнем цели команды? Если вы не уверены, что сможете достичь цели вашей команды, используйте ваш план для того, чтобы понять, сможете ли вы это сделать. Вам может понадобиться создать специальные инкременты для обучения, удлинить ваш горизонт планирования или сделать маленький релиз с ограниченной доступностью для тестирования критически важных концепций. Детали будут зависеть от вашей ситуации, поэтому, если вы не уверены, что делать, попросите совета у наставника.

Предварительные требования Адаптивное планирование требует участия руководителя и стейкхолдеров (см. главу 5). Любая команда может планировать в рамках своих ценных инкрементов. Кроме того, это зависит от имеющегося у вас объема поддержки. Работа над одним инкрементом за раз — это разумный и легкий способ повысить ценность вашей команды. Несмотря на его полезность, работа над одним элементом за раз вызывает отвращение у некоторых стейкхолдеров. Действуйте осторожно. Частые релизы требуют того, чтобы ваши заказчики и пользователи могли принимать такие релизы. Для большинства сетевого ПО это не проблема, поскольку пользователям не приходится ничего делать, чтобы получить обновление. Другие виды ПО могут требовать болезненных процедур развертывания, а некоторые даже дорогостоящих сертификационных тестов. Это может осложнить частые релизы. Создание экспериментов, опций и MVP требует, чтобы ваша организация смирилась с неопределенностью и верила, что у вашей команды достаточно знания рынка, чтобы принимать правильные решения. Обычно это требует от вашей команды свободного владения навыками на уровне оптимизации.

Глава 8.  Планирование  213

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

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

Альтернативы и эксперименты Адаптивное планирование повышает ценность благодаря гибкости в планировании и стратегическому подходу к релизам. Ищите возможность снижать затраты времени на планы, которые впоследствии отменяются, ускоряйте петлю обратной связи, чаще совершенствуйте ваши планы и сокращайте время до получения готовой ценности. Если у вас нет команды поставки, то могут возникнуть вопросы о том, как планировать техническую инфраструктуру. [Denne2004] предлагает сложную методологию инкрементного финансирования (Incremental Funding Methodology, IFM), отвечающую на этот вопрос. Команды со свободным владением навыками на уровне поставки изСм. также бегают этой необходимости, поскольку используют эволюционный дизайн для инкрементноИнкрементный дизайн (глава 14) го построения технической инфраструктуры. Команды, имеющие определенный продукт, не всегда нуждаются в усложненном плане. Вместо того чтобы думать в терминах инкрементов или релизов, эти команды отталкиваются от маленького списка историй

214  Часть II.  Фокус на ценность и постоянно выпускают небольшие изменения. Вы можете рассматривать это как адаптивный план с очень короткими горизонтами планирования. И наконец, адаптивное планирование часто рассматривается как альтернатива предиктивному, но, как показывает подраздел «Баланс адаптивности и предсказуемости» данной главы, скорее является комплексом различных горизонтов планирования. Если вы работаете в среде, где требуется предиктивное планирование, то подумайте, сколько адаптивных идей вы можете использовать вместе с длинными горизонтами планирования.

Литература для дополнительного чтения Software By Numbers [Denne2004] предоставляет убедительные и подробные аргументы в пользу проведения частых релизов. В главе 3 книги Lean Software Development [Poppendieck2003] обсуждаются преи­ мущества отсрочки принятия решений и долгого сохранения вариантов открытыми. В книге The Principles of Product Development Flow [Reinertson2009] автор глубоко погружается в принципы, лежащие в основе адаптивного планирования. Книга ориентирована скорее на физические продукты, чем на ПО, однако ее все же стоит прочитать.

ВИЗУАЛЬНОЕ ПЛАНИРОВАНИЕ У нас есть карта пути к достижению нашей цели.

Аудитория

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

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

См. также Вся команда (глава 7) Вовлечение реального заказчика (глава 8)

Глава 8.  Планирование  215

к составлению краткого плана, и ищите возможность привлечь реальных заказчиков. Если будут учитываться их точки зрения, то качество ваших планов улучшится. Разработчики могут активно участвовать или нет по усмотрению вашей команды. Многие разработчики предпочитают не посещать некоторые собрания — и, по правде говоря, им действительно лучше тратить свое время на что-то другое. В то же время разработчикам пойдет на пользу углубленное понимание плана, и их точка зрения часто улучшает планы. Я склонен оставлять это решение на усмотрение каждого разработчика. Даже если разработчики не участвуют, они все же должны понимать план и давать обратСм. также ную связь. Зарезервируйте время на обсуждение Игра в планирование (глава 8) плана с разработчиками. Подходящим моментом для этого может быть игра в планирование.

Картирование кластеров Картирование кластеров (Cluster Mapping) (рис. 8.4) — самый простой и гибкий, а также наиболее эффективный способ визуализировать ваши планы. Это моя любимая техника.

Рис. 8.4. Карта кластера

216  Часть II.  Фокус на ценность

1. Подготовьте истории с помощью мозгового штурма Чтобы создать карту кластера, сначала взгляните снова на цель вашей команды, затем примените См. также одновременный мозговой штурм (см. пункт «РабоЦель (глава 7) тайте одновременно» главы 7), чтобы сгенерировать Истории (глава 8) истории, соответствующие этой цели. Вы можете записывать любые истории, которые вам нравятся, Адаптивное планирование но помните, что они должны быть краткими, и не (глава 8) слишком вдавайтесь в детали. Вы начинаете с общего плана в долгосрочной перспективе. Например, если ваша цель — улучшить коэффициент конверсии для вашего онлайн-магазина, то вы можете написать истории наподобие «улучшенная поддержка мобильных устройств», «собственное мобильное приложение», «курируемые обзоры товаров», «улучшенная страница оформления покупки» и т. д.

2. Сгруппируйте истории в инкременты После мозгового штурма сгруппируйте истории (см. пункт «Работайте одновременно» главы 7), используя картирование сходства, затем поделите кластеры на ценные инкременты (см. подраздел «Ценные инкременты» ранее в данной главе). Одни истории станут самостоятельными инкрементами, другие сформируют инкремент, когда будут собраны вместе. Для последних создайте новую историю, целиком представляющую ценный инкремент. Отметьте каждую историю, которая представляет собой ценный инкремент. Для физических карточек мне нравится использовать забавный стикер, например, звезду или лицо с улыбкой. Работая с виртуальными эквивалентами, я меняю цвет карточки. Оставшиеся истории можно сохранить или выбросить в зависимости от того, насколько они ценны, по вашему мнению.

3. Организуйте инкременты Сделайте шаг назад и подумайте об инкрементах в контексте цели вашей команды, затем реорганизуйте их так, чтобы они лучше отражали ваше представление о том, как эта цель будет достигнута. Некоторые инкременты окажутся не относящимися к делу или относящимися к слишком далекому будущему. Их можно удалить или отложить. Некоторые инкременты будут отражать разные способы достижения одного и того же результата. Если вы не уверены, что выбрать, то сохраните оба! Ваш план — карта, а карты показывают разные пути к пункту назначения. Вы даже можете захотеть добавить несколько инкрементов исследовательского типа, которые помогут вам выбрать варианты. У вас может оказаться несколько инкрементов, которые не имеют прямого отношения к цели вашей команды, но все равно должны быть выполнены. Добавьте их на доску.

Глава 8.  Планирование  217

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

Дальнейшая разбивка инкрементов Как описывалось в разделе «Как создать план» ранее в данной главе, общий план будет состоять из множества уровней детализации.

См. также Адаптивное планирование (глава 8)

1. Цель. 2. Возможные ценные инкременты. 3. Наименьшие ценные инкременты. 4. Истории размером «в самый раз». Вы начали с цели вашей команды и использовали ее для того, чтобы создать возможные инкременты. Теперь вам нужно разбивать их на еще более мелкие элементы.

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

218  Часть II.  Фокус на ценность Например, если ваш продукт — онлайн-магазин и у вас инкремент «Улучшенная страница оформления заказа», то вы можете разбить его на следующие меньшие инкременты: «Запоминать данные кредитных карт», «Оформление платежа через PayPal», «Подарочная упаковка», «Купоны» и т. д.

2. Фильтруйте и повторите Далее проанализируйте новые инкременты и удалите (или пока отложите) те, которые не относятся к делу или относятся к слишком далекому будущему. Оставшиеся разделите на «высокий приоритет» и «невысокий приоритет». Повторяйте шаги 1 и 2, пока у вас достаточно маленьких инкрементов с высоким приоритетом, чтобы заполнить ваш горизонт планирования для «Наименьших ценных инкрементов». Например, если вы используете горизонты планирования, показанные на рис. 8.2 (см. выше), то остановитесь, когда наберете маленьких инкрементов на три месяца работы. ПРИМЕЧАНИЕ Просто используйте свое внутреннее ощущение размеров. Вы не делаете реальную оценку, просто решаете, когда остановить планирование, так что не стоит останавливаться слишком рано. Самое важное — найти маленький инкремент, над которым ваша команда будет работать в первую очередь. Вы всегда можете разбить больше инкрементов чуть позже.

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

3. Расставьте приоритеты Когда закончите, остановитесь и подумайте, См. также не приходят ли вам в голову какие-нибудь новые идеи. Затем решите, как вам приориДорожные карты (глава 10) тизировать маленькие инкременты с высоПрогнозирование (глава 10) ким приоритетом. Как минимум отметьте один, чтобы выпустить его первым, и еще один для предполагаемого второго релиза. Оставшиеся тоже можно приоритизировать или пока оставить в зависимости от того, что указано в вашей дорожной карте и прогнозах. Если вы используете физические индексные карточки, то запишите приоритет на маленький стикер и приклейте его на карточку. Таким образом, когда ваши приоритеты изменятся, вы сможете просто переклеить стикеры, не переписывая карточки. На этом уровень детализации «Маленькие инкременты» завершается. Это еще один удобный момент сделать перерыв и запросить обратную связь.

Глава 8.  Планирование  219

4. Сыграйте в игру в планирование Финальный уровень детализации вашего См. также визуального плана — разбивка ваших маленьких инкрементов на истории размером Игра в планирование (глава 8) «в самый раз». Для этого используйте игру в планирование. Когда закончите, у вас будет набор историй для каждого из ваших самых высокоприоритетных инкрементов. Разместите каждый набор на доске рядом с соответствующим инкрементом. Если вы прогнозируете релизы, то можете добавить их даты на доску. Окончательный результат будет выглядеть примерно как на рис. 8.4 (см. выше).

Карты влияния Иногда вам нужно больше вариантов структуры, чем могут обеспечить карты кластеров. Карты влияния (impact maps), показанные на рис. 8.5, — отличный инструмент для исследования доступных вам вариантов1. Никогда не стремитесь реализовать всю карту. Лучше найдите на ней самый короткий путь к цели! [Adzic2012] (с. 12–13). Гойко Аджич

Рис. 8.5. Карта влияния Большое спасибо Гойко Аджичу за его советы в этом подразделе.

1

220  Часть II.  Фокус на ценность Карта влияния — тип ментальных карт (mind maps). Если вы с ними не знакомы, то ментальные карты — это иерархическое дерево идей. Вы начинаете с основной идеи в центре карты. Идеи, относящиеся к ней, ветвятся из центра и создают собственные узлы. От каждой из этих идей ответвляются дополнительные идеи. И т. д. В данном случае на карте влияния «Почему» (цель) находится в центре, за ней следует «Кто» (влияющие стейкхолдеры), «Как» (влияния) и «Что» (инкременты). Чтобы создать карту влияния, используйте вашу доску для визуального планирования. В виртуальную доску может быть встроена функция карт влияния. Если у вас физическая доска, то используйте для узлов индексные карточки разного цвета. При необходимости их можно будет с легкостью передвигать. Как всегда, лучше работайте все вместе, чтобы избежать образования узких мест в рабочем процессе.

1. Начните с цели Начните с вашей цели. Это «Почему» на карте См. также влияния, и она размещается в центре. Данная цель должна некоторым образом иметь отноЦель (глава 7) шение к цели вашей команды. Это может быть сокращенная версия вашей миссии, следующих тестов миссии или и то и другое. На карте влияния все зависит от цели. Это пункт назначения, и карта покажет вам, как до него добраться. В примере команды «Снежный человек» (см. врезку «Пример цели» в главе 7) целью должно быть «100 командпокупателей».

2. Определите влияния с помощью мозгового штурма Следующий уровень карты влияния — «влияюСм. также щие стейкхолдеры», но, как правило, далее лучше использовать мозговой штурм для определения Контекст (глава 7) влияний. Это «Как» карты влияния. Как могут люди, находящиеся за пределами команды, помочь вам достичь вашей цели? Как они могут помешать этому? Каких изменений вы бы хотели в их поведении? Если вы создали диаграмму контекста (см. пункт «Границы и взаимодействия» главы 7), то группы стейкхолдеров, перечисленные на этой диаграмме, могут подать вам новые идеи. Например, существующие заказчики «могут порекомендовать нас в социальных сетях» или отраслевые журналы могут «публиковать положительные отзывы». Постарайтесь включить и негативные влияния, например регуляторы, которые «повышают требования к аудиту», или конкуренты, которые «меняют модель ценообразования». Поговорите о том, как их поведение отличается от сегодняшнего: если регулятор уже требует аудит, то правильной формулировкой влияния будет не «требование аудита», а «повышение требований по аудиту».

Глава 8.  Планирование  221

3. Определите влияющих стейкхолдеров Скорее всего, вы в итоге получите широкий выбор возможных влияний. Удалите те, которые не заслуживают внимания или находятся в слишком далеком будущем. Для остальных определите влияющих стейкхолдеров (группы, внешние по отношению к вашей команде, включая другие группы в вашей компании), которые создают влияния. Поместите их на карту на уровень «Кто», между целью и их влиянием. Сделайте шаг назад и осмотрите всю доску. Не хватает каких-нибудь важных участников? Подумайте об их влиянии и добавьте их на доску. Затем посмотрите на нее еще раз. Ищите недостающие влияния и удаляйте не относящиеся к делу.

4. Приоритизируйте влияния До этого момента вы мыслили широко и генерировали варианты. Теперь настало время сфокусировать ваше мышление. Какие влияния критичны для достижения вашей цели? Какие представляют собой легкодоступные цели? Какие являются предположениями, которые необходимо протестировать? Выберите влияния с самым высоким приоритетом. При работе в группе вам может помочь точечное голосование (см. пункт «Работайте одновременно» главы 7). После того как вы приоритизировали влияния, подумайте над прикреплением конкретных целей к максимальным влияниям. Например, влиянию «рекомендуйте нас в социальных сетях» может соответствовать цель «100 рекомендаций в социальных сетях в неделю». Это поможет вам понять ваш прогресс. Иногда вам будет удаваться достичь цели раньше, чем вы ожидали, и тогда вы сможете изменить приоритеты. В других случаях вы узнаете, что ваши усилия ничего не меняют, и вам понадобится сделать больше, чтобы проверить ваши предположения.

5. Определите инкременты с помощью мозгового штурма Теперь вы готовы к «Что» карты влияний. Цель карты влияний — Это ваши возможные инкременты. Замансфокусировать ваше внимание чиво думать о них как о наиболее важной на вашей цели и влияниях. части карты, но это не так! Цель карты влия­ ний — сфокусировать ваше внимание на вашей цели и влияниях, которых вы хотите добиться (или, наоборот, уменьшить). Для этого, конечно, вы используете инкременты, но считать их самым главным — это словно говорить, что машина — самая важная часть дорожного атласа. Для поездки она необходима, да. Для карты — нет. Подумайте о способах, с помощью которых ваша команда может поддержать каждое положительное влияние, уменьшить каждое негативное или узнать больше о предположениях, которые требуют проверки. Формулируйте ваши идеи в общих чертах. Например, касательно поддержки заказчиков, рекомендующих вас в социальных сетях, вы можете добавить «Автоматически публиковать скриншоты» и «Публиковать отзывы». Один из возможных подходов к работе с инкрементами — подумать о том, как можно упростить рабочий процесс или вызвать изменения в поведении людей. «Автоматически

222  Часть II.  Фокус на ценность публиковать скриншоты» выполняет обе задачи: вызывает изменение в поведении людей (за счет увеличения взаимодействия в социальных сетях) путем упрощения процесса (обычно это требует совершения множества действий: сделать скриншот, отформатировать его, открыть приложение социальной сети и вставить его туда). На данный момент у вас есть общий краткий план. Это подходящий момент для того, чтобы сделать перерыв и запросить обратную связь. На следующем шаге вы будете разбивать возможные инкременты на наименьшие ценные инкременты.

6. Разбейте инкременты на более мелкие составляющие Начните с поиска возможностей разделения влияющих стейкхолдеров и влияния, а не инкрементов. Например, влияние «Рекомендуйте нас в социальных сетях» можно поделить на «Рекомендуйте нас в Twitter» и «Рекомендуйте нас в Facebook». Влияющих стейкхолдеров можно поделить на «новых заказчиков» и «существующих заказчиков». Закончите так, как было описано в подразделе «Дальнейшая разбивка инкрементов» выше в данной главе. Окончательный результат будет выглядеть так, как показано на рис. 8.5 (см. выше).

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

Рис. 8.6. Перспективный анализ

Глава 8.  Планирование  223

Один из видов перспективного анализа — диаграмма влияния и вероятности (Impact and Probability chart), описанная в книге Дианы Ларсен и Эйнсли Нис Liftoff: Start and Sustain Successful Teams [Larsen2016]. Диаграмма довольно проста и эффективна.

1. Создайте диаграмму Чтобы создать диаграмму, нарисуйте большой график на вашей доске для визуального планирования или в ее виртуальном эквиваленте. Пронумеруйте вертикальную ось от –3 до +3, что будет представлять собой результат от «очень плохо» до «очень хорошо», и нарисуйте горизонтальную прерывистую линию на уровне отметки «0». На горизонтальной оси отметьте диапазон от «Не произойдет» до «50/50» и далее до «Произойдет». Нарисуйте вертикальную прерывистую линию на отметке «50/50».

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

3. Проверьте и уточните После того как все карточки будут на доске, остановитесь, чтобы внимательно просмотреть их расположение и скорректировать его. Это можно сделать одновременно. Результат будет похож на рис. 8.6 (см. выше).

4. Определите приоритетность результатов и создайте план Дальше с помощью точечного голосования выберите те результаты, которые наиболее важны для вашей команды (самые приоритетные). Их вы можете использовать в качестве вводных данных для одной из следующих визуализаций. Если вы проводите перспективный анализ как самостоятельную визуализацию, то с помощью мозгового штурма придумайте потенциальные инкременты, которые помогут вам достичь положительных результатов и уменьшить негативные. Добавьте их рядом с диаграммой вместе со стрелками, указывающими на соответствующие карточки. Наконец, разбейте потенциальные инкременты на более мелкие составляющие, как было описано в подразделе «Дальнейшая разбивка инкрементов» ранее в данной главе.

224  Часть II.  Фокус на ценность

Составление карты историй Карты историй (Story maps), представленные на рис. 8.7, особенно полезны, когда нужно сфокусироваться на том, как используется ваше ПО1. Они могут использоваться сами по себе, или вы можете с их помощью конкретизировать инкремент, созданный путем применения другого подхода.

Рис. 8.7. Карта историй

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

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

1

Глава 8.  Планирование  225

чит каждый? Как это соотносится с целью вашей См. также команды и ценностью, которую ожидает ваша организация? Цель (глава 7) На основе этого решите, какую тему или темы будет охватывать ваша карта историй. Вам не нужно Контекст (глава 7) накладывать на эту карту абсолютно все. Как говорит Джефф Паттон, «создать карту — это просто рассказать историю»1. Выберите начало и конец вашей Создать карту — это просто истории. В нашем примере с онлайн-магазином вы рассказать историю. можете рассказать историю о том, что происходит, когда кто-либо покупает какой-либо товар. Дальше вам нужно решить, хотите ли вы создать карту «сейчас» или карту «потом». Карта «сейчас» описывает, что люди делают сегодня. Она помогает вам поставить себя на их место. Обычно вам лучше начинать с карты «сейчас», если вы не слишком хорошо понимаете, как будет использоваться ваше ПО. Карта «потом» описывает, что люди делают после того, как у них появилось новое ПО. Обычно вы конвертируете карту «сейчас» в «потом», представляя, как ваше ПО улучшит ситуацию. Но вы можете создать карту «потом» и напрямую.

2. Определите шаги Создайте карту историй, буквально рассказывая, что происходит: сначала это, потом вот это, затем вот то. Она может охватывать несколько пользователей и систем: «Я делаю это, затем Татьяна делает вот это, потом система бэкенда совершает вот эти действия». Записывайте каждый шаг (также называемый пользовательская задача (user task)2) на индексной карточке, стикере или в виртуальном эквиваленте. Для примера с онлайн-магазином вы можете расписать шаги «искать товар», «читать отзывы», «добавить в корзину», «нажать “оформить”» и т. д. Расставьте их по порядку от первого до последнего. Если вы создаете карту «сейчас», то добавьте примечание о том, как все работает на практике. Сделайте примечание о недостатках и о том, что работает хорошо. Вы также можете написать, сколько времени занимает каждый шаг или как часто они происходят, — все, что, по вашему мнению, может быть полезным позже, когда вы будете думать об улучшениях. ПРИМЕЧАНИЕ Карты историй могут занимать много места. В физической командной комнате вы можете использовать свободную большую стену и стикеры вместо белой доски и индексных карточек. Используйте суперклейкие стикеры — вы же не хотите вернуться после долгих выходных и найти свою карту на полу!

В личном общении.

1

Джефф Паттон использовал термин «пользовательские задачи» в [Patton2014], но позже переключился на «шаги». Это помогает избежать путаницы с задачами в разработке.

2

226  Часть II.  Фокус на ценность Расписав все шаги, осмотрите всю карту от начала до конца и заполните все пробелы, какие найдете. Потом начните расширять свои представления об элементах карты. Как другие люди делают что-то другим образом? Что происходит, когда что-то идет не так? А что, если все идет отлично? Напишите новые стикеры для таких вариаций и добавьте их столбиком под соответствующим им шагом. В конце взгляните на изначальный список шагов и переместите те из них, которые кажутся дополнительными, ниже соответствующих им шагов. В процессе работы у вас будут появляться новые идеи, которые потребуют реорганизации вашей карты. И это хорошо. Когда закончите, у вас будет горизонтальная линия шагов, рассказывающих историю о том, что делают пользователи, и вертикальные линии вариаций, альтернатив и деталей, спускающиеся вниз от горизонтальной линии. У вас должна быть возможность «пройти по карте» от начала до конца, выбирая разные шаги из каждого столбца, чтобы рассказать разные версии одной истории. Иногда люди будут иметь разные мнения о том, в каком порядке расставить шаги. Просто выберите наиболее типичный порядок. До тех пор, пока вы можете рассказать историю, имеющую смысл, точный порядок шагов не важен.

3. Выделите активности пользователя Теперь преобразуйте карту в активности пользователя — набор шагов, которые выполняются вместе. Например, вы можете сгруппировать «Ввести адрес для выставления счета», «Ввести адрес доставки» и «Ввести данные кредитной карты» в единую активность «Оформление покупки». Пометьте каждую активность пользователя цветным стикером, разместив его над первым шагом в этой активности. Некоторые активности могут иметь только один шаг.

4. Идентифицируйте результаты и цели В конце подумайте о результатах и целях, которые могут иметь ваши пользователи. Разместите их на отдельных стикерах слева от карты. Они будут представлять разные версии истории, которую вы можете рассказать с помощью своей карты. Например, у вас может быть «Быстро купить определенный товар», «Поиск товара», «Выбрать между несколькими похожими товарами». Распределите результаты по порядку от самого высокого приоритета к низкому, затем передвиньте шаги, в том числе вариации и детали, так, чтобы они выстроились в один ряд с соответствующим результатом. При необходимости добавьте дополнительные шаги, чтобы рассказать историю каждого результата. Если шаг относится к нескольким результатам, то поместите его в результат с максимальным приоритетом. Затем нарисуйте горизонтальные линии, чтобы отделить каждый результат. (Приклеивать ваши стикеры на стену вы можете с помощью синей малярной ленты.)

5. Создайте карту «потом» Если вы создали карту «сейчас», то на данный момент вы готовы преобразовать ее в карту «потом». Посмотрите на активности и результаты и подумайте о том, что и как в них может улучшить ваше ПО. Добавьте стикеры другого цвета, описывающие, что должно быть добавлено, изменено или удалено.

Глава 8.  Планирование  227

Пока вы продумываете каждое изменение, попробуйте сыграть в игру «хороший — лучше — наилучший». Для каждого изменения спрашивайте: «Какой способ сделать это достаточно хорош для пользователей?», «Какой способ лучше?», «А какой способ наилучший?» Каждая идея получает собственный стикер. Так образуется коллекция компромиссов, из которых вы сможете выбирать, когда будете принимать решения об инкрементах и адаптировать свои планы. Когда закончите, сделайте перерыв и запросите обратную связь от членов команды, пользователей и других стейкхолдеров, которые не присутствовали при обсуждении.

6. Разделите карту на инкременты Теперь, когда ваша карта историй готова, вы можете подумать о том, как разбить ее на ценные инкременты. Для начала взгляните на активности пользователей (верхний ряд). Можете разделить их так, чтобы сформировать множество ценных инкрементов? Это не всегда будет возможно, но если можете, то сгруппируйте активности в инкременты, нарисовав вертикальные линии. Проверьте, что каждый из них является ценным сам по себе и его можно выпустить отдельно. Например, если активности в вашей карте онлайн-магазина были «Найти товар», «Оформить покупку» и «Отследить доставку», то вы можете создать два инкремента: «Найти товар + Оформить покупку» и «Отследить доставку». Далее взгляните на результаты (горизонтальные полосы). Какие из них могут быть выпущены отдельно? Иногда каждый результат представляет собой ценный инкремент. Возможно, вы даже сможете разделить шаги, принадлежащие какомулибо из результатов, на множество инкрементов. В других случаях вам может понадобиться сгруппировать множество результатов, чтобы сформировать инкремент. Нарисуйте квадратные рамки вокруг инкрементов. Получится что-то похожее на рис. 8.7 (см. выше). Снова сделайте перерыв и получите обратную связь.

7. Сыграйте в игру в планирование Получившиеся в результате квадраты — См. также это ваши наименее ценные инкременты. Дальше вам нужно доработать их с поИгра в планирование (глава 8) мощью игры в планирование. Шаги «потом», детали и вариации (отклонения) в каждом квадрате — это истории, которые вы возьмете с собой в игру в планирование. Когда это будет сделано, отправьте получившиеся истории обратно на вашу карту историй.

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

228  Часть II.  Фокус на ценность карточки в кластеры.) Он постоянно раскладывал их на собраниях и вносил небольшие поправки. Как минимум проверяйте свой план каждую неделю. Как только команда заканчивает работу над историями и инкрементами, проверяйте свои горизонты планирования и вытягивайте больше деталей, как написано в подразделе «Как создать план» выше в данной главе

Вопросы Что, если мы вынуждены использовать корпоративный инструментарий, который не позволяет нам сделать собственный визуальный план? Не позволяйте корпоративным инструментам мешать вам создавать и адаптировать ваш план. Если вам необходимо использовать такой инструмент, то рассматривайте его как еще одну точку зрения на ваш реальный план, как описывается в подразделе «Корпоративные системы отслеживания» главы 10. Делать двойную работу, конечно, расточительно, но хороший визуальный план — настолько ценная вещь, что оно того стоит. Как нам сконвертировать визуальный план в такой формат, который хотят видеть наша организация и стейкхолдеры? Есть много вариантов в зависимости от того, какая степень детализации нужна вашей организации. Прочитайте раздел «Дорожные карты» главы 10.

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

Глава 8.  Планирование  229

Визуальное планирование также требует руководства людьми, обладающими навыками См. также менеджмента продукта и разбирающимися в сфеВся команда (глава 7) ре деятельности заказчика. Без их участия вы, конечно, сможете создать визуальный план, но Цель (глава 7) он не будет хорошим. Имеет большое значение и ясная цель. Результат будет еще лучше, если вы пригласите ключевых стейкхолдеров и реальных заказчиков на ваши сессии планирования или, по крайней мере, запросите их обратную связь по черновым версиям вашего плана. Без обратной связи вы подвергаетесь риску туннельного видения. Вы можете построить что-то, что вам будет казаться правильным, но на самом деле не будет выполнять требования людей.

Показатели Когда вы создаете и правильно доводите до участников визуальный план: zz

стейкхолдеры и члены команды понимают не только, что будет сделано, но и почему это будет сделано;

zz

взаимосвязи между частями вашего проекта хорошо видны;

zz

стейкхолдеры и члены команды вносят новые идеи в результате более глубокого понимания контекста.

Альтернативы и эксперименты Вы можете сразу начать экспериментировать с этой практикой. Попробуйте каждую из представленных здесь карт по отдельности, затем в разных комбинациях и добавьте собственные идеи. Правильного ответа нет, так что экспериментируйте с любыми идеями, какие только сможете найти или придумать. Не бойтесь что-то менять; я меняю свои визуализации каждые несколько месяцев и каждый раз нахожу новые идеи и ощущаю азарт от открывающихся возможностей. Есть много способов визуализации планов. Один стартап, с которым я работал, создал диаграмму бизнес-приоритетов в четырех категориях («развитие бизнеса», «контроль затрат», «снижение рисков», «расширение возможностей»). Каждая из идей получила свой стикер в соответствии с приоритетом. Были сотни идей, и только нескольким из них был присвоен высокий приоритет. Остальные постоянно перемещались в разных направлениях, так как основатели стартапа выдвигали новые идеи и пересматривали старые. У другой команды было множество обязательств, привязанных к определенным датам. Команда разработала календарь обязательств с колонкой для каждой недели. Карточки, представлявшие собой обязательства на каждую неделю, приклеивались к соответствующей колонке. Каждую неделю команда просматривала обязательства, приближающиеся по срокам, и добавляла их в планирование задач этой недели. Существует множество и других вариантов. Экспериментируйте свободно!

230  Часть II.  Фокус на ценность

Литература для дополнительного чтения Impact Mapping [Adzic2012] — исчерпывающее руководство по картам влияния. Оно короткое, легкое для чтения, содержит много полезных советов. Если вы применяете карты влияния в своей практике, то его стоит приобрести. User Story Mapping1 [Patton2014] — исчерпывающий справочный материал по созданию карт историй. Это захватывающая книга, содержащая много полезного об историях и планировании в целом. Innovation Games2 [Hohmann2006] содержит огромное количество упражнений, которые помогут вам визуализировать и создавать ваши планы. Обратитесь к ней, когда будете готовы адаптировать визуализации, представленные в этой книге, под свои потребности.

ИГРА В ПЛАНИРОВАНИЕ В наших планах используются знания и опыт как бизнеса, так и разработки.

Аудитория

Вся команда Вы можете точно знать, что вы хотите сделать, но как вам составить пошаговый план? Здесь вам поможет игра в планирование. Несмотря на название, игра в планирование — не просто развлечение. В экономике понятие «игра» относится к ситуации, где «игроки выбирают действия и выигрыш зависит от действий всех игроков»3. Вот что такое игра в планирование. Это кооперативная игра, предназначенная для того, чтобы создавать наилучший выигрыш из возможных. Игра в планирование примечательна тем, как максимизирует количество информации, вложенной в ваш план. Она поразительно эффективна. У игры в планирование есть ограничения, однако если вы работаете внутри них, то я не знаю лучшего способа выяснить все детали вашего плана. Игра в планирование — всего лишь часть См. также вашего общего процесса планирования. Это способ разбить ценные инкременты, пригодИстории (глава 8) ные для отдельного релиза, на истории меньшего размера. В конце игры в планирование Цель (глава 7) у вас будет набор историй размера «в самый Визуальное планирование (глава 8) раз» для разработки. Напомню:

1) цель представляет собой общую цель и текущее направление; 2) визуальное планирование определяет варианты для ценных инкрементов; 3) игра в планирование обеспечивает пошаговый план, который вы будете использо­ вать для разработки каждого инкремента. Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО.

1

Хоманн Л. Бизнес-игры: создание революционных продуктов с помощью клиентов.

2 3

Это определение игры пришло из Глоссария международной экономики (А. Дирдорффа) (https:// oreil.ly/IsTY2).

Глава 8.  Планирование  231

К А Р ГО - К УЛ ЬТ

День планирования Сегодня опять день планирования, и вы в ужасе от этого. Вы точно знаете, что будет происходить. Сначала Захария и Мисси опоздают минут на десять-пятнадцать. Потом Ладонна с помощью проектора выведет ваш баг-трекер на стену. Она прочтет историю, в том числе все детальные требования, критерии готовности и все остальное. Все будут говорить об этом. Потом будет что-то вроде оценочных шагов с помощью покера планирования. Джон будет жаловаться, что оценка слишком велика. Клео скажет, что историю надо разбивать на более мелкие. Филлис скажет, что она уже потратила несколько часов на требования и менять истории — слишком большая работа. Корнелл скажет всем, чтобы просто продолжали работать. В конце концов после 10 минут болезненных споров у вас будет оценка, Ладонна внесет ее в систему, и вы перейдете к следующей. И так снова и снова. Это так мучительно и занимает долгие часы. Наверняка есть способы лучше.

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

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

См. также Визуальное планирование (глава 8)

232  Часть II.  Фокус на ценность историй (см. подраздел «Как создать план» ранее в данной главе). Например, если вы используете горизонт планирования, показанный на рис. 8.2, вам понадобится выбрать количество инкрементов, которого хватит примерно на месяц работы. Начните игру в планирование с просмотра цели команды, затем опишите, как выбранные вами инкременты вписываются в общий план и почему их важно сделать в первую очередь. Объясните, что делает эти инкременты ценными и что должно произойти, прежде чем их можно будет выпустить, и затем ответьте на все возможные вопросы от команды.

2. Вся команда определяет истории с помощью мозгового штурма Используйте одновременный мозговой штурм (см. пункт «Работайте одновременно» главы 7), См. также чтобы придумать истории, необходимые для реИстории (глава 8) лиза каждого инкремента. Запишите каждую на своей индексной карточке или виртуальном эквиваленте. Вы можете иметь некоторые предстоящие обязательства, запросы или активности, которые не соответствуют вашим самым приоритетным инкрементам, но все равно должны быть сделаны. Подготовьте истории и для них. Для всего, что требует какихлибо действий от команды, кроме рутинной работы компании, нужна своя история.

3. Разработчики определяют размер историй Разработчикам нужно пересмотреть карточки историй и рассортировать их в несколько групп: zz истории размера «в самый раз»; zz слишком большие истории; zz слишком маленькие истории; zz истории, размер которых невозможно определить, поскольку вы их не понимаете; zz истории, размер которых невозможно определить из-за технических неясностей. Истории имеют размер «в самый раз», когда вся команда может завершить от четырех до десяти (в среднем шесть) таких историй за неделю. Со временем у вас появится интуитивное ощущение истории размером «в самый раз». Однако для начала вы можете воспользоваться одной из оценочных техник, описанных в подразделе «Оценка историй» главы 9. ПРИМЕЧАНИЕ Почему от четырех до десяти историй в неделю? Вы можете выбрать любой размер для понятия «в самый раз», но 4–10 — хорошая начальная точка. Если будет больше, то вы можете прийти к тому, что будете тратить очень много времени на создание, организацию, отслеживание историй. Если меньше — вам будет трудно демонстрировать устойчивый прогресс.

Глава 8.  Планирование  233

Если истории слишком большие, то вместе со своими заказчиками разделите их на более мелкие. В подразделе «Разделение и объединение историй» данной главы описывалось, как это сделать. Если истории слишком малы, то комбинируйте их с другими историями. Если вы работаете с физическими индексными карточками, то можете буквально скрепить их друг с другом. Если вы не понимаете историю, то попросите ваших заказчиков в команде пояснить. Иногда им может понадобиться больше времени, чтобы разобраться. Пока они это делают, продолжайте заниматься оставшимися историями. Для историй, в которых есть технические неясности, создайте спайк-истории (см. пункт «Спайк-истории» ранее в данной главе). Сделайте отметку на первоначальной истории, что ее размер неизвестен. Я обычно пишу в углу «спайк».

4. Заказчики определяют приоритеты историй Заказчики, как только разработчики одобрят См. также размер истории «в самый раз», добавляют их в ваш визуальный план примерно в порядке приВизуальное планирование оритета. (глава 8) Для историй, у которых нет соответствующего инкремента, добавьте их там, где это наиболее целесообразно для вашей команды. Размещение их среди других историй в соответствии с приоритетом поможет гарантировать, что вы о них не забудете. Некоторые истории не стоят того, чтобы их добавлять. Они или неважны, или находятся слишком далеко в будущем. Продолжайте, выбросив их, — они устареют к тому времени, когда вы до них доберетесь. Если вы терпеть не можете выбрасывать свои истории, то сохраните их в каком-нибудь архиве. Заказчики, убедитесь, что вы понимаете каждую историю, которую добавляете. Вам нужно принимать правильные решения о том, что входит, а что нет в каждый релиз, а также решать, в каком порядке будут выстраиваться истории. Это значит, что истории должны соответствовать вашей точке зрения. Не позволяйте разработчикам заставить вас добавить историю, которую вы не понимаете. Разработчики, за вами последнее слово в вопросе историй, которые «в самый раз» и готовы к приоритизации. Не позволяйте заказчикам заставить вас принять историю, которая должна быть разделена на более мелкие или нуждается в спайкистории.

5. Повторяйте, пока план не будет завершен Продолжайте создавать, оценивать и размещать истории, пока не заполните свой горизонт планирования историй. Добавляйте дополнительные инкременты, если необходимо. Например, если вы нацелены на шесть историй в неделю и ваш горизонт планирования историй — четыре недели, то продолжайте, пока у вас не будет по меньшей мере 24 истории. Затем сделайте шаг назад и еще раз проверьте план с помощью вопросов, указанных ниже. zz Каждая история имеет размер «в самый раз», согласно мнению членов команды с навыками разработки?

234  Часть II.  Фокус на ценность zz

Каждая история, размер которой невозможно определить, имеет спайк-историю, приоритизированную для выполнения перед ней?

zz

Истории приоритизированы правильно, согласно мнению членов команды, имеющих навыки в сфере деятельности заказчика?

zz

В целом имеет ли ваш план смысл и ведет ли команду к достижению ее цели?

Попросите членов команды дать согласие на работу по вашему плану (см. пункт «Стремитесь к согласию» главы 7). Как только они подтвердят свое согласие, вы закончите данный этап работы.

Держите открытым окно возможностей Старайтесь создавать план, который позволит вам сделать релиз в любое время. Вам не нужно на самом деле делать релизы все время, но вы хотите иметь такую возможность даже в середине работы над любым инкрементом. Зачем это делать? Это позволяет вам держать открытым окно возможностей. Обычно, если появляется интересная новая возможность, пока вы находитесь в середине работы над инкрементом, то вам нужно ждать его завершения и потом или выбрасывать наполовину выполненную работу, или откладывать ее на неопределенное время в сторону, где она будет, метафорически говоря, ржаветь (см. врезку «Минимизируйте объем незавершенной работы» ранее в данной главе). Но если вы планируете свою работу так, что можете сделать релиз в любой момент, то можете принять решение, что половина ценности инкремента лучше, чем ничего, выпустить то, что есть, и сразу начать работать над новой возможностью. Чтобы держать открытым окно возможностей, создайте такой план, чтобы можно было делать релиз после каждой истории. Истории могут основываться на предыдущих историях, но не должны зависеть от последующих. Например, предположим, что вы создаете страницу оформления покупки, на которой взимается плата с кредитной карты пользователя. Вы могли бы сначала создать историю для каждого уровня вашей архитектуры: «Получить платежную информацию», «Сохранить платежную информацию» и «Отправить платежную информацию в систему обработки платежей». Иногда это называют горизонтальными полосами. Это простой способ создания историй, но он не позволит вам сделать релиз вашего ПО, пока вы не закончите все три истории. Они формируют выбор «все или ничего». Лучше создавать истории, которые содержат все три горизонтальных уровня, но обеспечивают более узкую самостоятельную утилитарность. Например, вы можете создать истории «Обработать платеж», «Запомнить одну карту» и «Запомнить и управлять несколькими картами». Это вертикальные полосы (рис. 8.8). Каждая строится на предыдущей, но вы можете сделать релиз после любой из них. Не волнуйтесь, если у вас пока не получается сделать так, чтобы ваши истории опирались друг на друга подобным образом. Для этого нужна практика. Возможность релиза после каждой истории позволяет вам быть более гибкими, но и немного

Глава 8.  Планирование  235

«скомканных» историй в вашем плане не нанесут большого вреда. Со временем вы научитесь делать ваши планы более ровными.

Рис. 8.8. Горизонтальные и вертикальные полосы

Как выиграть в игре в планирование Когда разработчики и заказчики в команде собираются, чтобы сыграть в игру в планирование, происходит нечто удивительное. Я называю это чудом сотрудничества. Это чудо, поскольку время появляется из ниоткуда. Как вы можете вообразить, этого чуда достичь непросто. Когда разработчики говорят, что история должна быть разделена на более мелкие, заказчики обычно задают вопрос, который вызывает у разработчиков зубной скрежет: «Почему это так дорого стоит?» Инстинктивно этот вопрос вызывает защитную реакцию: «Это стоит так дорого, поскольку разработка ПО — трудная работа! Почему вы меня допрашиваете?!» Разработчики могут реагировать иначе, лучше. Мысленно перефразируйте вопрос: «Помогите понять, какие у меня есть варианты». В ответ расскажите о том, что легко и что сложно. Например, вообразите, что вы создаете тостер и у вашего продакт-менеджера есть история для разработки функциональности автоматического выскакивания тоста по его готовности. Разработчики говорят, что историю нужно разделить, и когда

236  Часть II.  Фокус на ценность продакт-менеджер спрашивает почему, разработчики спокойно отвечают: «Ну, выскакивание тоста — это легко, надо просто отрубить электричество от электромагнита. Но определение готовности тоста — это что-то новое. Нам понадобятся датчик изображения и система машинного обучения для того, чтобы точно определить изменения в степени потемнения тоста для разных видов хлеба. С мраморным ржаным… будет сложно, не говоря уже о тостерной выпечке!» Это дает продакт-менеджеру возможность спросить: «А как насчет всех других тостеров вокруг? Как они определяют, что тост готов?» Разработчики строят красноречивую гримасу: «О, это полная ерунда. Они вообще не определяют готовность тоста. Они просто используют таймер». Теперь продакт-менеджер может ответить: «Так это отлично! Нашим заказчикам не нужен супертостер. Они хотят обычный. Используйте таймер, как все остальные». «А, ну окей. Тогда это совсем не сложно. Нам не нужно делить эту историю». Как правило, заказчики не знают, что просто, и придумывают истории, которые трудно реализовать. Точно так же разработчики могут не знать, что считают важным заказчики, и придумывают истории, в которых отсутствует ценность для заказчиков. При открытом и честном общении эти противоречивые тенденции можно примирить. Когда заказчики просят чего-то неважного, но сложного, разработчики указывают на затраты и предлагают более простые альтернативы. И заказчики меняют направление. Так время появляется словно ниоткуда. Это и есть чудо сотрудничества.

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

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

Глава 8.  Планирование  237

Вернемся к примеру с тостером. Вместо того чтобы объяснять выбор между оптическим датчиком и таймером следующим образом: «Мы думаем об использовании здесь оптического датчика Mark 4 Wizzle-Frobitz, позволяющего оптимально определять момент выбрасывания. Другой вариант — использовать 555-style IC. Оптический датчик лучше, но тогда нам понадобится обучить индивидуальную пользовательскую модель ML. Что вы предпочитаете?»,

попробуйте объяснить так: «У нас есть два способа определения готовности тоста. Мы можем использовать камеру или таймер. Камера позволит зажаривать тост в точном соответствии с предпочтениями пользователя, но реализация потребует нескольких дополнительных историй. Таймер не добавит дополнительной работы. Но пользователь, скорее всего, будет получать недожаренный или, наоборот, подгоревший тост. Что вы предпочитаете?»

Лицом к лицу с реальностью Заказчики, во время игры в планирование вы почти наверняка узна́ете информацию, которая вас расстроит. Даже если ваша команда не делает прогнозов, игра в планирование даст вам примерное понимание того, какое количество работы предстоит сделать. И почти всегда ее будет значительно больше, чем вы надеялись. Вы можете почувствовать искушение обвинить информирующего и прекратить игру в планирование. Или можете надавить на разработчиков, чтобы они не делили истории на части. Это будет ошибкой. Игнорирование неприятной реальности не уменьшит количества времени, затраченного на работу; задержки, возникшие из-за этого, просто заведут вас в тупик. Перефразируя Дэвида Шмальтца: каждый релиз содержит определенное количество связанных с ним разочарований. Вы можете Игнорирование неприятной или использовать игру в планирование, реальности не уменьшит количества чтобы раздавать его в умеренных дозах… времени, затраченного на работу. или нести его с собой целиком до самого конца. Ваш план может и так быть больше, чем вам хотелось бы, однако если разработчики просят еще разделить истории, то это, скорее всего, потому, что они хотят установить реалистичные ожидания. На практике я обнаружил, что на первых порах разработчики скорее недостаточно делят истории, чем наоборот. Но если они все же планируют слишком мелкие истории, это значит, что они просто выполнят больше историй, а вы сможете скомпенсировать все на следующей игре в планирование.

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

См. также Визуальное планирование (глава 8)

238  Часть II.  Фокус на ценность настает время снова провести игру в планирование. После этого проверьте еще раз, нужно ли вытянуть инкременты в ваш визуальный план. Стейкхолдеры тоже будут предлагать новые идеи и функциональности. Одни из них не будут стоить того, чтобы их внедрять, и их можно будет выбросить (вежливо!). Другие окажутся хорошими идеями для будущих инкрементов, и их можно будет добавить к пока еще менее детализированной части вашего визуального плана. А идеям, которые вы захотите реализовать скоро, понадобятся свои истории. Их нужно будет обсудить с командой, чтобы задать размер и приоритет. По мере приобретения опыта обсуждение, определение размера и приоритета начинают занимать всего несколько минут. Соответственно, одни команды просматривают новые истории в день их получения. Другие планируют большие сессии игры в планирование каждую неделю или две. Я считаю, что короткие частые сессии менее утомительны, чем долгие и более редкие, но оба подхода рабочие. Иногда стейкхолдеры будут пытаться обойти процесс приоритизации, общаясь с программистами напрямую. Правильной реакцией на это будет выслушать их запрос, записать его (на этот случай я всегда ношу с собой набор индексных карточек) и сказать им, что запросу будет присвоен приоритет, когда команда в следующий раз соберется на сессию планирования. Потом вы можете передать его своему локальному заказчику для отслеживания.

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

Предварительные требования Игра в планирование основана на нескольких простых предпосылках:

См. также

zz

есть члены команды, обладающие навыками в сфере деятельности заказчика, которые могут принимать разумные решения о приоритетах;

zz

есть члены команды с навыками разработки, которые могут надежно измерять истории;

zz

есть истории с минимальными зависимостями, ориентированные на заказчика.

Вся команда (глава 7)

Глава 8.  Планирование  239

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

Показатели Когда вы хорошо играете в игру в планирование: zz

заказчики и разработчики чувствуют, что они внесли свой вклад в план;

zz

ощущения давления и стресса направлены скорее на ограничения плана и возможные варианты, чем на отдельные лица или группы лиц;

zz

разработчики рекомендуют способы, позволяющие уменьшить работу, при этом выполняя цель команды;

zz

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

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

ВОВЛЕЧЕНИЕ РЕАЛЬНОГО ЗАКАЗЧИКА Мы понимаем цели и опасения наших заказчиков и пользователей.

Аудитория

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

240  Часть II.  Фокус на ценность членом нашей команды. Благодаря ей мы смогли создать действительно более ценный продукт. В Agile-команде заказчики (члены коман­ См. также ды, обладающие нужными навыками, чтобы представлять заказчика, пользователей Вся команда (глава 7) и интересы бизнеса) отвечают за выбор и приоритеты историй. В их руках ценность работы, выполненной командой. Это большая ответственность. Будучи заказчиком в команде, как вы узнаете, что выбрать? Часть этих знаний вы получили исходя из вашего предыдущего опыта и квалификации. Но вы не можете думать обо всем. Вас может настолько захватить ежедневная рутина, что вы потеряете из виду интересы вашего реального заказчика. Чтобы расширить свою перспективу, вам нужно привлечь реальных клиентов и пользователей. Наилучший подход к этому зависит от того, для кого вы делаете ПО. КЛЮЧЕВАЯ ИДЕЯ

Обратная связь и итерации Сосредоточенность Agile на обратной связи — одна из основных причин его успеха. Невероятно трудно предсказать, как будет принято ваше программное обеспечение. Трудно даже представить, как оно будет работать на практике. В результате команды часто обнаруживают, что первая версия их ПО содержит неожиданные недостатки. Не совсем баги, а скорее некоторые заблуждения в части того, что именно нужно было сделать. До появления Agile на релиз первой версии ПО у команды могли уйти годы. Когда неизбежные недостатки обнаруживались, оказывалось, что уже слишком поздно и слишком дорого что-то менять. Революционность идеи Agile была в том, чтобы выпускать ПО уже в первый месяц работы и так же часто и далее, что позволяло обнаруживать и устранять ошибки на ранней стадии. Предотвращайте ошибки, запрашивая как можно больше обратной связи. Подключайте к планированию заказчиков, пользователей и стейкхолдеров от бизнеса. Показывайте им макеты. Просите комментарии по текущей работе. Выпускайте версии ПО инкрементно и наблюдайте, как люди используют его в реальности. И затем действуйте, основываясь на обратной связи. Меняйте планы, вносите улучшения и повторяйте все снова.

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

Глава 8.  Планирование  241

Разработка платформ В горизонтально масштабированных группах команд (см. подраздел «Горизонтальное масштабирование» главы 6) некоторые команды могут делать ПО, предназначенное только для использования другими командами. Реальные заказчики такого типа разработки платформ — команды заказчика. И слишком часто разработчики платКомандам заказчика нужны гибкость, форм попадают в ловушку, делая инструавтономия и полное владение своим менты и библиотеки, которые «просты продуктом, ничего волшебного. в использовании». Но это не то, что нужно командам вашего заказчика. Им нужны гибкость, автономия и полное владение своим продуктом, ничего волшебного. Им нужно, чтобы они могли делать свою работу, не завися от вас, если понадобятся какие-то изменения. Как правило, это означает, что вам следует считать своими приоритетами простые программные интерфейсы с четкими зонами ответственности, минимальными побочными эффектами и «аварийным люком», который позволит команде погрузиться в нужные детали при необходимости. ПРИМЕЧАНИЕ Некоторые организации делят свои команды на старших разработчиков, которые разрабатывают платформы, и младших разработчиков, которые адаптируют (кастомизируют) эти платформы под разработку продуктов. Избегайте этого подхода. Довольно часто он приводит к построению собственной «башни из слоновой кости», пытающейся упростить кастомизацию, но на самом деле требующей от неопытных разработчиков постоянной работы по латанию дыр. Результат — беспорядочное нагромождение решений, которое трудно поддерживать.

Старайтесь работать в тесном сотрудничестве с представителями команд заказчика, когда делаете дизайн API (Application Programming Interfaces — «прикладные программные интерфейсы») и принимаете решения о технических возможностях. Сфокусируйтесь на том, чтобы дать возможность вашим заказчикам решать проблемы самостоятельно, так, чтобы вы не стали узким местом их рабочего процесса. Один из способов улучшить взаимопонимание — проводить «программы обмена», в которых один из ваших разработчиков на несколько недель меняется местами с разработчиком из команды заказчика. Если ваша команда делает вспомогательное ПО для других разработчиков в целом, а не для поддержки определенных команд, то вам лучше прочитать подраздел «Программное обеспечение для вертикального рынка» далее в текущей главе.

Внутренняя разработка на заказ Внутренняя разработка на заказ (in-house custom development) происходит, если ваша команда разрабатывает что-либо для собственного использования вашей компанией. Это классическая разработка в ИТ. В нее может входить разработка ПО для оптимизации операционной деятельности, автоматизация заводов вашей компании или составление отчетов для бухгалтерии.

242  Часть II.  Фокус на ценность В таких условиях команда работает сразу Превратите ваших реальных на нескольких заказчиков: исполнительного заказчиков в заказчиков в команде. спонсора, который платит за ПО, и конечных пользователей, которые его используют. Их цели могут не совпадать. В худшем случае вам будет необходимо удовлетворить запросы целого комитета спонсоров и множества групп пользователей. Несмотря на эти трудности, внутренняя разработка на заказ облегчает вовлечение реальных заказчиков, поскольку они легкодоступны. Лучшим вариантом будет принять заказчиков в вашу команду — превратить реальных заказчиков в заказчиков в команде. ПРИМЕЧАНИЕ Вместо того чтобы приглашать заказчиков присоединиться к вашей команде, может быть проще предложить вашей команде переехать поближе к заказчикам.

Чтобы этого добиться, попросите вашего исполнительного спонсора или одного из его доверенных помощников стать вашим продакт-менеджером. Он будет принимать решения по приоритетам, отражая стремление исполнительного спонсора создать ПО, представляющее ценность для организации. Кроме того, привлеките несколько конечных пользователей ПО в качестве экспертов в предметной области. Как в вышеупомянутом случае с химиком, они будут давать ценную информацию об использовании вашего ПО реальными людьми. Эксперты будут отражать стремление конечных пользователей использовать ПО, улучшающее их жизнь. Во избежание эффекта туннельного зрения См. также продакт-менеджер и заказчики в команде должны запрашивать обратную связь у своих коллег, проДемо для стейкхолдеров водя демо для стейкхолдеров и обсуждая с ними (глава 10) дорожные карты. Дорожные карты (глава 10) Если вам трудно уговорить исполнительного спонсора и пользователей присоединиться к команде, то прочтите информацию об аутсорсинге разработки (см. следующий подраздел). Если у вас множество спонсоров и групп пользователей, то прочитайте подраздел «Программное обеспечение для вертикального рынка» далее в текущей главе.

Аутсорсинг разработки Аутсорсинг разработки (outsourced custom development) похож на внутреннюю разработку на заказ (in-house custom development), но у вас может не быть таких связей, которые есть у внутренних команд в организации. В результате у вас может не получиться привлечь реальных заказчиков к работе в качестве заказчиков в команде. Но вы все же должны попытаться. Один из способов вовлечь в работу реальных заказчиков — предложить вашей команде переехать в офис заказчика, а не наоборот. Если вы не можете привести реальных заказчиков в вашу команду, то сделайте попытку привлечь их другим способом. Встречайтесь лично с вашими заказчиками

Глава 8.  Планирование  243

первую неделю-две работы над проектом, чтобы обсудить цель и контекст, визуальный план и познакомиться друг с другом. Если ваши офисы находятся неподалеку друг от друга, то встречайтесь снова на каждой демосессии для стейкхолдеров и сессиях планирования, а также время от времени на ретроспективах. Если вы разделены территориально и регулярные визиты невозможны, то оставайтесь См. также на связи с помощью видео- и телефонных конференций. Если у вас виртуальная команЦель (глава 7) да, то рассмотрите возможность предоставить Контекст (глава 7) заказчикам доступ в вашу виртуальную командную комнату. Постарайтесь встречаться Визуальное планирование (глава 8) по меньшей мере раз в месяц для обсуждения Демо для стейкхолдеров (глава 10) планов. Даже если ваша команда работает Игра в планирование (глава 8) в офисе, попробуйте использовать виртуальную белую доску для визуального плана, Ретроспективы (глава 11) чтобы было проще совместно просматривать и обсуждать планы.

Программное обеспечение для вертикального рынка В отличие от разработки на заказ (custom development), ПО для вертикального рынка разрабатывается для множества организаций. Однако, как и разработка на заказ, оно делается для определенной индустрии и часто адаптируется для каждого покупателя. Большинство продуктов «программное обеспечение как услуга» (software as a service, SaaS) попадает в эту категорию. Так как ПО для вертикального рынка имеет много заказчиков и у каждого свои потребности, вы должны быть осторожны, предоставляя реальным заказчикам слишком много контроля над направлением развития продукта. Вы можете прийти к тому, что ваш продукт будет идеально соответствовать потребностям вашего заказчика в команде, но оттолкнет всех остальных. Вместо этого в вашей команде должен См. также быть продакт-менеджер, который безошибочно понимает потребности ваших реальЦель (глава 7) ных заказчиков. Его работа (а она трудная) — принимать во внимание требования ваших реальных заказчиков и комбинировать их в единую четкую цель. Это подразу­мевает балансирование пожеланий людей, которые покупают продукт, с потребностями людей, которые используют продукт. В случае ПО для вертикального рынка их цели часто различаются и даже могут вступать в конфликт. Вместо того чтобы вовлекать реальных заказчиков в качестве членов команды, создайте Создайте возможности возможности для получения от них обратной для получения обратной связи. Некоторые компании формируют совет связи от реальных заказчиков, в который входят их наиболее важзаказчиков. ные заказчики. Организации таким образом

244  Часть II.  Фокус на ценность делятся с заказчиками своими планами релизов ПО и предоставляют им демо для тестов. В зависимости от ваших взаимоотношений с заказчиками вы можете попросить их пригласить к вам реальных пользователей, чтобы они присоединились к команде в качестве экспертов в предметной области. Другой вариант (как в вышеупомянутом примере с химиком) — вы можете пригласить предыдущих пользователей на роль ваших экспертов в предметной области. Вы также можете запрашивать обратную связь, используя участие в выставках и другие традиционные источники.

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

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

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

См. также Цель (глава 7)

Глава 8.  Планирование  245

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

Показатели Вовлекая реального заказчика и пользователей, вы: zz

улучшаете свои знания о том, как заказчики используют программное обеспечение на практике;

zz

лучше понимаете цели и опасения заказчика;

zz

используете обратную связь от заказчиков, чтобы пересматривать свои планы и программное обеспечение;

zz

повышаете ваши шансы поставить действительно полезный и успешный продукт.

Альтернативы и эксперименты Обратная связь — это необходимость, а непосредственное вовлечение реального заказчика — нет. Иногда лучшее ПО создают люди, которые имеют четкую концепцию и энергично добиваются ее реализации. В результате ПО имеет тенденцию становиться или полностью новым, или тщательно переосмысленным существующим продуктом. Кроме того, обратная связь от реальных заказчиков всегда информативна, даже если вы решите игнорировать ее. Данная практика предназначена для получения этой обратной связи из реального мира. Цель — создать ПО, которое реально отвечает потребностям заказчиков и пользователей, а не только представлениям вашей команды и организации об их потребностях. Пока вы будете думать о способах, позволяющих поэкспериментировать с этой практикой, сфокусируйтесь на общении и обратной связи. Что поможет вам получить представление о том, как воспринимаются ваши программы в реальном мире? Как вы можете уменьшить временной разрыв между идеей и получением обратной связи? Как принимать лучшие решения, основываясь на обратной связи? Чем больше у вас информации, тем более правильные решения сможет принимать ваша команда.

246  Часть II.  Фокус на ценность

ИНКРЕМЕНТНЫЕ ТРЕБОВАНИЯ Мы выясняем детали требований непосредственно перед тем, как они понадобятся.

Аудитория

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

Изменяемый документ с требованиями Agile-команды предпочитают общаться лицом к лицу, как рассказывается во врезке «Личное См. также общение» в главе 7. Заказчики в команде Вся команда (глава 7) (члены команды, обладающие навыками, позволяющими представлять интересы поКомандная комната (глава 7) купателей, пользователей и бизнес-стейкхолВовлечение реального заказчика деров) должны отвечать на вопросы команды (глава 8) о требованиях. Они выступают в качестве «изменяемого документа с требованиями». Они общаются с остальными членами команды с помощью разговоров, примеров и рисунков на доске. Это более быстрый и менее подверженный ошибкам способ, чем поддержание документа в актуальном состоянии, особенно для сложных тем. Когда разработчикам нужно понять требование, они просто спрашивают. От заказчиков в команде ожидают, что они разберутся с требованиями до того, как их будут спрашивать о них. Ключ к успеху здесь — их экспертные знания. В зависимости от потребностей вашего ПО в вашу команду должен входить кто-то с навыками управления продуктом, определяющий, что и как разрабатывать; кто-то с экспертными знаниями в предметной области, понимающий тонкости профессии, которую поддерживает ваше ПО; кто-то с навыками в области UX-дизайна, изучающий поведение пользователей и создающий продуктивный пользовательский интерфейс; и, может быть, даже реальные заказчики, которые предоставляют контекст о том, что значит использовать ПО в реальной работе. Например, когда я работал над актуарным продуктом, наш менеджер по продукту был актуарием, а спонсоры — старшими актуариями фирмы. У продукта для химического анализа продакт-менеджер имел докторскую степень по химии, у нас был специальный UX-дизайнер, и эксперт в предметной области был химиком-аналитиком. Даже эксперты должны учитывать все Не только представляйте себе, как разнообразие вариантов и проводить исслебудет принято ваше программное дование, прежде чем принимать решение. обеспечение: идите и узнавайте это. Заказчики, вы можете и должны разговари-

Глава 8.  Планирование  247

вать с покупателями, пользователями и другими стейкхолдерами (см. врезку «Обратная связь и итерации» ранее в данной главе). Не только представляйте себе, как будет принято ваше программное обеспечение: идите и узнавайте это. Задавайте вопросы, проводите эксперименты и демонстрируйте работающее ПО. Вы также можете вовлекать других членов команды. Например, если вы UXдизайнер, обдумывающий возможности пользовательского интерфейса, то обсуждение его с программистами команды может помочь добиться баланса между впечатляющим UI и низкой стоимостью его реализации. Заказчики сами решают, как запоминать все, что они узнали и решили. Что бы вы ни использовали, рассматривайте это как временные заметки. Главное, чтобы заказчики в команде могли взаимодействовать друг с другом. Если вы придете к необходимости иметь постоянные заметки или формальную документацию, то это можно сделать позже, как описывается в подразделе «Документация» далее в текущей главе.

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

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

248  Часть II.  Фокус на ценность на общей картине, и локальными заказчиками, фокусирующимися на деталях, как было показано на рис. 8.3 (см. выше).

Цель и визуальный план Сначала определите цель команды и визуальный план.

Игра в планирование

См. также Цель (глава 7) Визуальное планирование (глава 8)

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

Макеты, примеры заказчиков и критерии завершения Выясните детали каждой истории, прежде См. также чем разработчики начнут работать над ней. Вы должны быть в состоянии пояснить их, Примеры заказчика (глава 9) глядя на визуальный план. UX-дизайнеры, Сделано Сделано (глава 9) вам нужно подготовить макеты (мокапы), которые продемонстрируют, как, по вашим ожиданиям, будет выглядеть выполненная работа. Эксперты в предметной области, убедитесь, что вы готовы предоставить примеры сложных концепций данной области. Решите совместно, что для каждой истории будет значить быть сделанной.

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

Глава 8.  Планирование  249

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

Документация Хотя Agile-команды заменяют документацию личным общением, некоторые документы все же важны. Их планируют с помощью историй, как и любую другую работу. В некоторых случаях обновление документации может стать просто частью более крупной истории, но вы также можете создать специальные истории для документации, как обсуждалось в пункте «Истории для документации» ранее в данной главе. Постарайтесь не вводить документацию только ради документации. Как и во всем, что делается командой, убедитесь, что вам понятно, кому принесет пользу документация и почему она имеет ценность.

Документация по продукту Документация по продукту поставляется заказчику. Примеры такой документации — руководства пользователя, справочные страницы и справочная документация по API. Одна из команд, с которой я работал, собирала результаты тестов в формальный документ, который помогал заказчикам пройти процедуру одобрения у регулирующих органов.

250  Часть II.  Фокус на ценность Если у вашего ПО нет никакой документации по продукту, то вы можете сами задокументировать, что оно делает, — чтобы команда могла использовать эту информацию в дальнейшем. Лучше всего это делать сразу, пока воспоминания людей еще свежи, в рамках каждой истории, как часть командного определения понятия «сделано».

См. также Сделано Сделано (глава 9)

Эксплуатационная документация Эксплуатационная документация, также называемая runbooks, описывает стандартные практики и процедуры для разнообразных ситуаций, таких как развертывание ПО, реагирование на оповещения и аварийные ситуации, предоставление дополнительных ресурсов и т. д.

См. также Сборка для эксплуатации (глава 15)

Руководящая документация Ваша организация может требовать от вас создания определенных документов для целей управления или аудита. Постарайтесь, чтобы такой документации было минимальное количество, или выполните требования, творчески перепрофилировав те вещи, которые имеют большую ценность. Например, одна из команд использовала автоматические приемочные тесты, отчеты о покрытии кода (code coverage) и историю управления исходным кодом (source control), чтобы удовлетворить требования в части отслеживаемости. Не думайте, что аудиты требуют специального процесса. Они часто требуют, чтобы у вас просто имелся процесс (на ваш выбор) и чтобы вы могли продемонстрировать, что вы ему следуете. Это может позволить вам уменьшить количество документации по управлению куда больше, чем вы думаете. Например, вместо проведения формальных ревью кода команды использовали парное программирование и комментарии при подтверждении изменений в код (commit comments), чтобы соответствовать требованиям аудита в части экспертной проверки. Поговорите с аудиторскими группами заранее, чтобы сформировать атмосферу доброй воли и открыть возможности для творческих решений.

Исполнительно-техническая документация Agile-команды обладают глубоким пониманием, что они делают и почему. Но так как они не используют документацию, это знание исчезает, когда команда расформировывается. Когда ваша команда должна расформироваться или перейти к другой цели, Исполнительно-техническая найдите время на то, чтобы задокументиродокументация (As-built вать, что вы сделали. Это ваш финальный documentation) — это ваш финальный инкремент создания ПО. инкремент. Это как упаковывать одежду в коробки с нафталином: сейчас это вам

Глава 8.  Планирование  251

не нужно, но тот, кто унаследует вашу работу, будет благодарен, что вы потратили на это время. Ваша цель — предоставить информацию, которая позволит им сохранять и поддерживать код. Исполнительно-техническая документация может принимать форму письменных документов или пошаговых видеоинструкций. Обычно в них представлены обзоры важных концепций, таких как архитектура, дизайн и основные функциональности. Код и его тесты документируют детали. Алистер Кокберн советует записывать беседу с каким-нибудь красноречивым членом команды, в которой он с помощью белой доски объясняет систему программисту, не знакомому с ней. Дополните видео оглавлением, содержащим также временные метки для каждой части разговора.

Вопросы Не рискованно ли уменьшать количество документации? Может быть. Чтобы уменьшить количество документации, вам необходимо сначала заменить ее другими формами общения. Именно поэтому Agile-команды имеют заказчиков в команде — они заменяют документы с требованиями. Но вам все же может понадобиться задокументировать то, что разработала ваша команда. Если вы думаете, что это важно, то создайте для этого отдельную историю и приоритизируйте ее или включите данный пункт в ваше определение понятия «сделано». Наши заказчики не знают, что должна создать наша команда. Что нам делать? Начните с четкой, убедительной цели. Если ваши заказчики в команде не знаСм. также ют, как ее достичь, значит, у вас в команде не хватает важных навыков в сфере Цель (глава 7) деятельности заказчика. В этом случае Вся команда (глава 7) вы можете использовать традиционную Контекст (глава 7) методику сбора требований, такую как [Wiegers1999], но лучше все же найти людей с соответствующими навыками. Если вы еще этого не сделали, попробуйте определить контекст работы вашей команды и использовать его для лучшего понимания и пропаганды необходимых вам навыков. Что, если заказчики при проверках обнаруживают слишком много проблем, с которыми нам трудно справляться? С большой вероятностью это может случаться с новой командой, до того как разработчики и заказчики команды научатся работать вместе. В краткосрочной перспективе вам нужно писать новые истории для изменений, которые необходимо внести. В долгосрочной перспективе можно организовать работу так, чтобы заказчики См. также проводили больше времени, разговариГрупповое программирование (глава 12) вая с разработчиками о своих ожиданиях и проверяя текущую работу. Групповое Парное программирование (глава 12) программирование — наиболее яркое

252  Часть II.  Фокус на ценность выражение этой идеи. Другой вариант — работа заказчика и программиста в паре. Практикуясь, вы научитесь предвидеть запросы друг друга. Как программиста меня обижают некоторые вещи, которые заказчики указывают в своих отзывах. Они слишком придирчивы. Многие вещи, кажущиеся программистам придирками (например, цвет фона экрана или несколько пикселей выравнивания в пользовательском интерфейсе), являются для заказчиков свидетельством дополнительной полировки и профессио­ нализма. Это работает в обе стороны: некоторые вещи, важные для программистов, такие как качество кода и рефакторинга, часто кажутся заказчикам ненужным перфекционизмом. Вместо того чтобы расстраиваться из-за разницы во взглядах, попробуйте понять, что заботит заказчиков и почему. Узнав это, вы будете лучше предугадывать их потребности, что сократит необходимость в изменениях.

Предварительные требования Эта практика требует, чтобы в вашей команде были люди, имеющие время и навыСм. также ки, которые позволяют тщательно прораВся команда (глава 7) батывать детали. Без них у вашей команды будут трудности из-за недостаточных и неБез багов (глава 16) ясных требований. Визуальное планирование (глава 8) Не рассматривайте проверки ваших заказчиков как сессии поиска багов. Разработчики должны производить практически безошибочный код. Цель отзывов заказчиков заключается в том, чтобы привести ожидания заказчиков и работу программистов к единому знаменателю. Некоторые организации настолько высоко ценят письменные документы, что вы не сможете избежать документов с требованиями. Поговорите с вашим руководством о том, почему эти документы так важны и не может ли их заменить непосредственное общение. Возможно, исполнительно-техническая документация будет приемлемым компромиссом. Если нет, то включите истории для необходимых документов в ваш визуальный план.

Показатели Когда заказчики разрабатывают требования инкрементно: zz

разработчики работают над готовыми историями, в то время как заказчики выясняют детали будущих историй;

zz

у заказчиков наготове ответы на вопросы, касающиеся требований, что позволяет планированию и разработке проходить быстро и плавно;

zz

к моменту своей готовности история соответствует ожиданиям заказчиков.

Глава 8.  Планирование  253

Альтернативы и эксперименты Практика инкрементных требований, по сути, берет традиционную фазу предварительного сбора требований и распределяет ее вдоль всей протяженности процесса разработки ПО. Долгий процесс, когда заказчики пишут документ с требованиями, передают его разработчикам, а те его читают, заменяется прямым разговором заказчиков с разработчиками именно в тот момент, когда нужны детали. Обычно люди экспериментируют с этой идеей, сглаживая ее. Чаще всего команды не включают людей, имеющих опыт в сфере деятельности заказчиков, поэтому возвращаются к фазовому подходу и передаче документов. Это снижает их соответствие идеям Agile. Если вы ищете возможность для экспериментов, то попробуйте другое направление: расширяйте коммуникацию, повышайте экспертность знаний См. также и уменьшайте передачу из рук в руки. Групповое программирование — резульГрупповое программирование (глава 12) тат одного из таких экспериментов.

Литература для дополнительного чтения Badass: Making Users Awesome [Sierra2015] — великолепная книга о том, как делать продукты, которые понравятся людям.

ГЛАВА 9

Владение

Секрет первоклассного выполнения работы заключается в правильном понимании деталей, а никто не понимает их лучше, чем непосредственные исполнители этой работы [Poppendieck2003]. Lean Software Development: An Agile Toolkit

Agile-команды сами контролируют свою работу. Они сами для себя решают, что будут делать, как делить работу на задачи и кто в команде будет их выполнять. Все это основано на фундаментальном принципе Agile: люди, которые реально выполняют работу, лучше всех знают, что нужно делать. Их квалификация настолько велика, что позволяет им принимать решения относительно деталей. Однако такой подход подразумевает, что команда берет на себя не только контроль над работой, но и ответственность за ее выполнение. В этой главе содержатся практики, которые помогут вам взять на себя ответственность за работу и успешно ее выполнить. zz Практика «Планирование задач» позволяет вашей команде разбивать истории на задачи и решать, как они будут выполняться. zz Практика «Потенциал» помогает вашей команде браться только за то, что она в состоянии сделать. zz С помощью практики «Резерв времени» ваша команда повысит потенциал и сможет взять на себя надежные краткосрочные обязательства. zz Практика «Стендап-митинги» помогает членам команды координировать свою работу. zz Используя практику «Информативное рабочее пространство», ваша команда получит полезную информацию. zz Практика «Примеры заказчика» помогает вашей команде сотрудничать с экспертами. zz С помощью практики «Сделано Сделано» ваша команда сфокусируется на создании ПО, готового к релизу.

Глава 9.  Владение  255

Источники владения Самоорганизация и коллективное владение всегда были в центре идеи Agile. Способы, которыми команды планируют свои задачи, различаются. В XP и Scrum использовались короткие циклы, называвшиеся итерациями и спринтами. Другие методы, такие как язык шаблонов EPISODES Уорда Каннингема, использовали непрерывный поток работы [Cunningham1995]. В итоге XP и Scrum стали доминировать в мейнстриме, а непрерывный поток выпал из списка обычных практик Agile, пока не был введен вновь в 2005 году в составе метода Kanban Дэвида Андерсона. В практику «Планирование задач» входят и итерации, и непрерывный поток. Подход к итерациям основывается на XP, а подход к непрерывному потоку — на варианте Kanban Арло Бельши Naked Planning. Практика «Потенциал» происходит из XP, где она изначально требовала вычислений, называвшихся фактором загрузки. Мартин Фаулер и Кент Бек упростили идею до концепции «скорость» (velocity) в своей книге Planning Extreme Programming1 [Beck2000b]. Я переименовал ее в «потенциал» (capacity) во избежание некоторых распространенных заблуждений. Термин «резерв времени» (slack) был впервые представлен во втором издании по XP: Extreme Programming Explained [Beck2004]. Я подозреваю здесь влияние [DeMarco2002]. На меня повлияли оба этих источника, а также [Goldratt1992], хотя мой пример довольно уникален. Мой подход к стендап-митингам (stand-up meetings) прошел через фильтр множества источников. Его основу сформировал Daily Scrum. XP добавило «стояние» (standing up) и в итоге сформировало Daily Stand-Up. Так я впервые узнал об этом. А современный подход «прогулка по доске» (walk the board), похоже, возник из речи Брайана Марика на конференции в 2007 году [Marick2007b]. «Информативное рабочее пространство» — комбинация понятий «большие наглядные диаграммы» (big visible charts) из первого издания книги по XP, «информативное пространство» из второго издания книги по XP и «конвекционные потоки информации» (convection currents of information) Алистера Кокберна [Cockburn2006]. На практику «Примеры заказчика» в значительной степени повлияла работа с Уордом Каннингемом над его фреймворком для интегрированного тестирования (Framework for Integrated Test, Fit), инструментом, позволяющим заказчикам общаться через тесты. В первом издании этой книги данная практика называлась «Тесты заказчиков». Позже она превратилась в «Примеры заказчика» как результат моего опыта применения и преподавания Fit. Идея «Сделано Сделано» является общей и не имеет определенного первоисточника. Связанный с ней термин «критерии готовности» (Definition of Done) обычно приписывается Биллу Уэйку, хотя он говорит, что не он это начал2. С тех пор термин стал центральной частью Scrum.

Бек К., Фаулер М. Экстремальное программирование: планирование. — СПб.: Питер, 2002.

1

В личном общении.

2

256  Часть II.  Фокус на ценность

ПЛАНИРОВАНИЕ ЗАДАЧ У нас есть план на эту рабочую неделю.

Аудитория

Если вы следуете практикам, описанным Вся команда в главе 8, то в итоге придете к визуальному плану с несколькими уровнями детализации: ценные инкременты, которые возможно выполнить в долгосрочной перспективе, маленькие ценные инкременты, которые, вероятно, будут выполняться в среднесрочной перспективе, и специальные истории, которые будут сделаны в ближайшее время. План превращается в действие с помощью планирования задач: разделения историй на задачи и отслеживания прогресса команды. Поскольку Agile-команды — самоорганизующиеся (см. врезку «Самоорганизующиеся команды» в главе 7), создание задач, их распределение между членами команды и отслеживание полностью выполняются командой, а не руководителями. Планирование задач состоит из трех частей: рабочего ритма (cadence, используется также термин «каденция»), создания задач и визуального отслеживания.

Рабочий ритм Рабочий ритм (каденция, cadence) — это частота вашего планирования задач. В сообществе Agile существуют два общих подхода: итерации (также называемые спринтами1) и непрерывный поток (также называемый Kanban). Итерации — это периоды времени с фиксированной продолжительностью, длящиеся неделю или две. В начале каждой итерации вы выбираете набор историй для реализации и к концу периода ожидаете, что все они будут выполнены. Непрерывный поток, напротив, представляет собой бесконечную вереницу историй. Вы выбираете следующую историю, как См. также только предыдущая закончена. Команды — новички в Agile должны ис­ Потенциал (глава 9) пользовать итерации. Не потому, что они проРезерв времени (глава 9) ще (вообще-то они сложнее), а потому, что четкий ритм итераций дает командам возможность получать важную обратную связь, позволяющую понять, как ей совершенствоваться. И что еще важнее, благодаря правильному использованию вашего итерационного потенциала вы получаете резерв времени, позволяющий совершенствоваться. Непрерывный поток не имеет таких встроенных возможностей для совершенствования, какие есть в итерациях. Здесь сложнее заметить, когда работа идет 1

Слово «спринт» вводит в заблуждение. Разработка ПО больше похожа на марафон, чем на серии спринтов. Вам нужно работать в таком темпе, который вы можете поддерживать сколь угодно долго.

Глава 9.  Владение  257

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

Итерации Программная разработка обычно замирает постепенно. Сначала все идет хорошо: «Я закончу эту задачу, как только доделаю этот тест». Затем вы говорите: «Я закончу, как только исправлю этот баг». Потом вздыхаете: «Я закончу, как только исследую этот недостаток в API… на самом деле нет». Не успеете оглянуться, как потратите два дня на выполнение задачи, которую планировали сделать за два часа. Беда подкрадывается к команде постепенно. Каждая проблема отнимает всего лишь пару часов или день, поэтому не ощущается большой проблемой, но они множатся вокруг сотен задач в релизе. Совокупный эффект застает команды и их стейкхолдеров врасплох. Итерации позволяют вам обнаруживать проблемы на ранней стадии. Время итераций См. также строго ограничено: когда время истекло, итеСделано Сделано (глава 9) рация закончена. В начале итерации (а каждая обычно длится неделю или две) вы прогнозируете свой потенциал и выбираете истории, которые ему соответствуют. В конце итерации все истории должны быть «сделаны сделаны». Если это не так, то вы знаете, что у вас проблема. Итерации не предотвращают проблемы, а обнаруживают их, что позволяет вам исправлять лежащие в их основе причины. Итерации выполняются в соответствии с постоянным графиком. 1. Продемонстрировать результаты предыдущей итерации стейкхолдерам (полчаса). 2. Провести ретроспективу предыдущей итерации (один час). 3. Запланировать задачи для итерации (полчаса). 4. Разработать истории (остаток итерации).

См. также Демо для стейкхолдеров (глава 10) Ретроспективы (глава 11) Непрерывное развертывание (глава 15)

5. Развернуть ПО, если не используется непрерывное развертывание (автоматизировано). Многие команды начинают свои итерации в понедельник утром, но я предпочитаю итерации, которые начинаются утром в среду или четверг. Это позволяет командам уйти на длинные выходные, не пропуская важных событий. Вдобавок это снижает желание работать по выходным. Итерации могут иметь любую длительность, но большинство команд используют недельные или двухнедельные. Командам — новичкам в Agile лучше всего подходят итерации длительностью в одну неделю. Причина в том, что команды развивают свое понимание Agile, основываясь на том, сколько итераций они выполнили, а не

258  Часть II.  Фокус на ценность сколько недель опыта они получили. Чем короче итерации, тем быстрее команды будут совершенствоваться1. Вместе с тем итерации длиной в неделю окаСм. также зывают большее давление на команду. Это затрудняет активную работу и может помешать Энергичная работа (глава 7) выполнению рефакторинга. Кроме того, при Рефакторинг (глава 13) итерациях длиной в неделю труднее предсказыПотенциал (глава 9) вать потенциал, поскольку различные перерывы и праздники пропорционально больше, чем прерывания. Таким образом, как только ваша команда научится надежно завершать истории в течение каждой итерации, двигайтесь дальше и экспериментируйте с двухнедельными итерациями. Итерации длиной больше двух недель обычно являются ошибкой. Команды начинают использовать более длинные итерации, когда чувствуют, что им нужно больше времени, чтобы закончить работу. Но это только прячет проблему. Более длинные итерации не изменят количества имеющегося у вас времени; они изменят лишь перио­ дичность, с которой вы проверяете ваш прогресс. Если вам трудно закончить все к концу итеЕсли вам трудно закончить рации, то это не потому, что вам нужно больвсе к концу итерации, ше времени; это потому, что вам нужно больше то используйте более практики инкрементной работы. Сократите короткие итерации длительность ваших итераций, уменьшите истои уменьшите истории. рии и сконцентрируйтесь на решении проблем, которые мешают вам заканчивать истории.

Непрерывный поток Непрерывный поток является именно тем, чем кажется: непрерывным потоком историй без определенного начала и конца. Вместо того чтобы прогнозировать, что ваша команда может делать каждую неделю, установите лимит незавершенной работы (work in progress) — то есть над каким количеством историй ваша команда будет работать одновременно. Лучше всего от одной до трех. Чем меньше, тем лучше (см. врезку «Минимизируйте объем незавершенной работы» в главе 8). Как только этот лимит достигнут, больше новых историй начинать нельзя. Когда история «сделана сделана» (done done), ее убирают, освобождая место для новой. В теории непрерывный поток менее расточителен, чем итерации, поскольку вам не нужно предсказывать потенциал или рассчитывать истории так, чтобы они помещались во временные рамки итерации. На практике я не нашел этому подтверждения. Строгие временные рамки итераций удерживают внимание команды на завершении историй. Команды, использующие непрерывный поток, не имеют такой же срочной Я преподавал в классе, где студенты разрабатывали реальное программное обеспечение с помощью 90-минутных итераций. У них был такой же прогресс в совершенствовании, какой я видел у команд, использовавших итерации длиной в неделю.

1

Глава 9.  Владение  259

необходимости решать проблемы и урезать запланированный объем работы. Я рекомендую командам — новичкам в Agile сначала освоить итерации, а затем пробовать непрерывный поток. Тем не менее непрерывный поток хорошо подойдет командам, работающим с большим количеством маленьких непредсказуемых историй, например командам, занятым техническим обслуживанием и исправлением багов. Если ваши планы меняются настолько часто, что даже недельные итерации для вас слишком длинны, то ваш выбор — непрерывный поток. КЛЮЧЕВАЯ ИДЕЯ

Коллективное владение Agile-команды разделяют ответственность за результаты. Вся команда работает совместно, чтобы завершить истории, и каждый участник свободно выбирает работу, которую знает лучше всего, помогает тем, кто нуждается в помощи, и выясняет, как наилучшим образом внести вклад в работу, с которой пока знаком не очень хорошо. Если что-то идет не так, то команда совместно работает над решением проблемы; если все хорошо, то команда считает это общей заслугой. Некоторые команды назначают отдельных членов, чтобы они индивидуально работали над историями, но лучшие команды Agile делают это совместно. Они берутся за одну историю за раз или настолько близко к этому, насколько возможно, координируясь и взаимодействуя так, чтобы все делалось одновременно. Таким образом они избегают риска, когда один человек застревает на чем-либо и тормозит весь прогресс, а остальная команда об этом не знает. В командах поставки это общее владение распространяется также и на код. В разделе «Коллективное владение кодом» главы 12 описывается, как это работает.

Создание задач Начните планирование задач с выбора См. также историй. Если вы используете итерации, то выбирайте истории, основываясь на Потенциал (глава 9) своем итерационном потенциале: наприВизуальное планирование (глава 8) мер, 6 историй или 12 пойнтов. Если вы Игра в планирование (глава 8) используете непрерывный поток, то выбирайте истории в соответствии с вашим лимитом незавершенной работы, затем планируйте новую историю, когда эта заканчивается. В любом случае выбирайте только те истории, которые готовы к завершению: то есть вопросы сторонней зависимости решены либо же третья сторона готова участвовать.

260  Часть II.  Фокус на ценность Заказчики в команде выбирают истории, подбирая приоритетные из визуального плана. Они раскладывают их на столе или виртуальной доске и объясняют их остальным членам команды. Это должно происходить буквально мгновенно: команда уже видела истории во время игры в планирование. Далее используйте одновременный мозговой штурм (см. пункт «Работайте одновременно» главы 7), чтобы сформировать задачи, необходимые для завершения каждой истории. Делайте их маленькими: каждая задача на несколько часов работы. Запишите каждую задачу на карточку или ее виртуальный эквивалент и разместите рядом с историей, к которой она относится. Задачи могут быть любыми, на ваш вкус. Следует включить все, что нужно, чтобы закончить историю. Примеры: «обновить скрипт сборки», «добавить класс заказчика» и «макет платежной формы». Большинство задач будут создавать разработчики, но участвовать могут все. Планирование задач — активность, относящая­ ся к дизайну. Это способ, позволяющий добиться Планирование задач — активность, относящаяся общего понимания в команде. Если у всех одинак дизайну. ковые идеи, как разрабатывать ПО, это должно проходить быстро. Если нет — это отличная возможность обсудить все до начала разработки. Вам не нужно слишком сильно вдаваться в детали каждой отдельной задачи. Планирование задач нужно для того, чтобы все получили одинаковую картину происходящего, а не для того, чтобы окончательно решить, что делать. Оставьте людям возможность проработать детали, когда они непосредственно приступят к выполнению работы. Например, если одна из ваших задач — «добавить класс заказчика», то вам не нужно говорить, какие методы в него входят, если все программисты понимают место данного класса в общем плане. В процессе работы у разработчиков могут появляться вопросы о деталях каждой истории. Нужно, чтобы члены команды, имеющие навыки в сфере деятельности заказчика, могли отвечать на эти вопросы. На подготовку плана задач у вас должно уходить меньше 10–30 минут. Если она занимает больше, то вы, вероятно, слишком вдаетесь в детали. Если вы завязли в каком-то вопросе, то не решайте его во время совещания. Лучше добавьте его как отдельную самостоятельную задачу, относящуюся к дизайну. Например, если людям нужно решить, какую библиотеку аутентификации использовать, то можно добавить задачу «выбрать библиотеку аутентификации». Помните, что в работе должна принимать участие вся команда. Если вы создаете задачи в области дизайна, то убедитесь, что все члены команды, к которым это относится, имеют право голоса при принятии этих решений. Эти люди могут вместе работать над задачей. В качестве альтернативы команда может делегировать задачу подгруппе людей, которые выработают варианты, а затем отчитаются о результате большой группе. В любом случае это то, что следует сделать после первой встречи, посвященной планированию задач. Результатом встречи по планированию задач становится ваш первоначальный набор задач. В процессе работы вы можете обнаружить новые задачи. Это особенно

Глава 9.  Владение  261

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

Визуальное отслеживание Agile-команды совместно управляют своей работой, как было сказано во врезке «Коллективное владение» ранее в данной главе. Задания не назначаются конкретным людям. Вместо этого, когда кто-то готов начать работу над задачей, он смотрит на доступные задачи и выбирает из них такую, в которую может внести свой вклад, или ту, которая позволит ему чему-то научиться. Отслеживание прогресса и оказание помощи там, где нужно, — ответственность всей команды. Легко зациклиться на собственных задачах в ущерб общему прогрессу команды. Не забывайСм. также те оставаться в курсе общей картины и ставить Информативное рабочее проуспех команды выше завершения своих задач. странство (глава 9) Стендап-митинги помогут вам сделать шаг назад и подумать об общей картине, но еще более важным инструментом является ваша доска для отслеживания задач. Это центральная часть вашего информативного рабочего пространства. Мой любимый инструмент для отслеживания задач — большая магнитная доска. Мне нравится использовать шестидюймовую доску на колесиках. На одну сторону я помещаю визуальный план, а на другую — план задач. Если у вас удаленно работающая команда, то используйте виртуальную доску. Скорее всего, вам будет удобнее помещать план задач и визуальный план на одну и ту же доску. Доска с задачами — нервный центр вашей командной комнаты, как физической, так и виртуальной. Она делает ваш прогресс наглядным в любое время. Поддерживайте доску в актуальном состоянии. Когда вы начинаете работу над задачей, отмечайте на доске ваше имя или инициалы. Физические команды часто используют для этой цели специальные магниты с забавными картинками. Виртуальные команды могут загрузить любые собственные изображения.

262  Часть II.  Фокус на ценность В физической командной комнате приносите карточки с задачами на свой рабочий стол. Физическое действие в виде похода к доске и снятия с нее карточки будет помогать остальным членам команды быть в курсе ситуации. Даже простое наблюдение за передвижением людей вокруг себя позволяет понимать статус команды. В виртуальной команде вы можете так же повлиять на информированность команды о ситуации, раздав участникам планшеты, предназначенные для использования в качестве виртуальных досок. (Это хорошая идея в любом случае. Планшеты стоят недорого и упрощают рисование набросков.) Оставляйте планшет включенным и авторизованным в системе доски задач, чтобы вы могли видеть изменения. Его всегда можно выключить, если будет отвлекать. Лучший способ визуализации вашего плана задач — тот, который хорошо работает именно для Следите, чтобы ваш вашей команды. Здесь я представляю два варианта. подход к планированию задач оставался простым Вы можете поэкспериментировать с остальными. и наглядным. Однако следите, чтобы ваш подход оставался простым и наглядным, когда используете доску или ее виртуальный эквивалент. ПРИМЕЧАНИЕ Так называемые инструменты планирования Agile, такие как Jira, только вносят разногласия. Agile-команды постоянно экспериментируют с улучшениями и новыми рабочими процессами. Инструмент для планирования будет вам только мешать.

Сетка задач Сетка задач становилась хитом во всех командах, в которых я ее внедрял. Она простая и компактная. Чтобы ее создать, расположите истории вертикально, разместив историю с наивысшим приоритетом сверху. Справа от каждой истории в горизонтальную линию поместите задачи, связанные с этой историей, — в любом порядке, который кажется наиболее естественным. Их можно делать не по порядку. Когда люди готовы начать работу над задачей, они выбирают любую карточку, с которой готовы работать, начиная с верхнего левого угла. Как только задача завершена, пометьте карточку одним из способов: обведите зеленым маркером, добавьте зеленый магнит или измените цвет виртуальной карточки. (Лучше не делать надписи на карточках. Иногда задачи приходится пересматривать.) Когда все задачи из истории См. также завершены, последней задачей будет взглянуть на ваше определение понятия «сделано», внести Сделано Сделано (глава 9) финальные изменения, если нужно, и отметить карточку зеленым цветом. Сетки задач особенно полезны командам, работающим итерациями. Пример представлен на рис. 9.1.

Глава 9.  Владение  263

Рис. 9.1. Сетка задач

Доска детективов Помните, в криминальных драмах часто присутствует доска со всей имеющейся информацией о преступлении? Фотографии подозреваемых, улики, стрелочки от одного к другому? Это доска детективов, и именно так работает визуализация1. Пример показан на рис. 9.2.

Рис. 9.2. Детективная доска Арло Бельши познакомил меня с доской детективов как частью своего процесса обнаженного планирования (Naked Planning).

1

264  Часть II.  Фокус на ценность Каждая история получает собственную доску или ее часть, куда помещается все, что имеет отношение к этой истории. Задачи, макеты, документы… вообще все. Элементы группируются так, как команда считает нужным. Когда задача или какая-то часть информации обработана или больше не актуальна, команда удаляет ее с доски. Когда члены команды понимают, что что-то еще может быть полезным, они это добавляют. История сделана, когда доска пустая. Детективные доски особенно хорошо работают для команд, использующих непрерывный поток.

Кросс-командные зависимости Некоторые истории могут зависеть от людей вне команды. Так как истории маленькие (обычно примерно на день работы, если команда работает совместно), лучше подождать, пока эти сторонние зависимости не будут урегулированы. Подобным же образом, если для истории требуется, чтобы кто-то временно вступил в команду, подождите, пока этот человек освободится. Иначе вы в итоге получите частично сделанную работу (см. врезку «Минимизируйте объем незавершенной работы» в главе 8). Конкретнее: когда выбираете истории для планирования задач, не выбирайте истории с неурегулированНе выбирайте истории с неурегулированными ными зависимостями. Если вы используете итерации, зависимостями. то такие истории должны подождать до следующей итерации. Если вы используете непрерывный поток, то подождите, пока не откроется следующий слот. Если вы начинаете работать над историей и обнаруживаете, что у нее есть внешняя зависимость, то можно пока оставить ее в плане. Но ограничьте ее короткими временными рамками, например день или два. Если зависимость не будет решена за это время, то уберите ее из плана и замените. Я помечаю такие истории красным цветом и добавляю дату окончания срока действия. Некоторые истории может делать ваша команда, затем другая и затем снова ваша. Разбивайте такие истории на две: первая — подготовка истории для другой команды, вторая — история, которую вы начинаете после того, как другая команда завершила свою часть работы. Помните, истории должны быть ориентированы на заказчика, как было написано в подразделе «Ценность для заказчика» главы 8. В целом Agile-команды должны быть в состоянии взять на себя полную ответственность за разрабатываемые ими истории. Если ваша команда сталкивается с частыми задержками из-за кросс-командных взаимозависимостей, то что-то идет не так. Возможно, у вас не вся См. также команда или ваша организация выбрала неправильный Вся команда (глава 7) подход к масштабированию (см. главу 6). Попросите помощи у наставника.

Глава 9.  Владение  265

Принятие и выполнение обязательств по итерации Итерации — эффективный инструмент для улучшения способности вашей команды надежно поСм. также ставлять ПО. Чтобы полностью воспользоваться Доверие стейкхолдеров всеми его преи­муществами, рассматривайте ваш (глава 10) план итераций как обязательство: нечто такое, ради исполнения которого вы готовы приложить максимальные усилия. Поначалу у вас будут трудности с выполнением ваших планов итераций, поэтому берите на себя обязательства негласно, внутри команды. Обязуйтесь сами перед собой, не перед стейкхолдерами. Однако, практикуясь, вы станете достаточно последовательными, чтобы начать информировать о своих обязательствах и стейкхолдеров — и это потрясающий способ выстроить доверие. Однако, как бы то ни было, обязательства — собственный выбор команды. Agile-команды отвечают Обязательства — собственный выбор команды. за свою работу. Руководители, никогда не заставляйте ваши команды брать на себя обязательства. Это плохо заканчивается. Конечно, быть хозяевами своих обязательств не означает, что вы будете всегда завершать все, что запланировали. Что-то может пойти не так. Да, обязательство заключается в том, чтобы делать все, что необходимо (в пределах разумного) для завершения историй, входящих в данную итерацию вовремя. Но сюда входит и поиск решений для проблем, и честное, ясное информирование о тех проблемах, которые вы не можете решить. Чтобы выполнять свои обязательства, вы должСм. также ны знать о проблемах до того, как будет слишком поздно. Проверяйте прогресс команды во время Стендап-митинги (глава 9) ваших ежедневных стендап-митингов. Есть незаСделано Сделано (глава 9) вершенная задача, о которой говорили на предыРезерв времени (глава 9) дущем стендапе? Это может быть проблемой. Если вы в середине итерации, то проверьте, отмечена ли зеленым примерно половина карточек задач. Если нет, то велика вероятность, что вы не закончите все вовремя. Отмечена ли также зеленым половина историй? Если задачи сделаны, а истории — нет, то вам в последний день придется внезапно делать много работы, чтобы перевести истории в статус «Сделано Сделано». Обнаружив проблему, угрожающую исполнению ваших обязательств, проверьте, нет ли способа изменить план так, чтобы соответствовать обязательствам. Может ли помочь использование вашего резерва времени? Нет ли задачи, которую можно упростить или отложить? Обсудите ваши варианты в команде и пересмотрите план. Иногда проблема слишком серьезна, чтобы с ней можно было справиться так просто. В этом случае обычно вам нужно уменьшить объем работы в итерации.

266  Часть II.  Фокус на ценность Как правило, это подразумевает разделение какой-либо истории и откладывание части работы или полное удаление истории. Всегда держите итерацию под контролем, даже если для этого вам понадобится удалить из нее историю. Любая итерация, которая поставляет все истории текущего плана (даже если план меньше изначального), — это уже успех. Но ни при каких обстоятельствах не отодвигайте предельный срок итерации. Всегда завершайте итерацию вовремя. Это убережет вас от самообмана.

Незаконченные истории В конце итерации все истории должны быть в статусе «Сделано Сделано». Частично сдеСм. также ланные истории должны быть редкостью. Это Сделано Сделано (глава 9) означает, что они будут случаться иногда, в основном пока вы еще учитесь. Потенциал (глава 9) Незавершенный код вредоносен. Если вы не планируете завершить историю немедленно в следующей итерации, то вырежьте ее код из кодовой базы и верните историю обратно в ваш визуальный план. Если вы планируете завершить работу, то создайте новую историю, представляющую оставшуюся работу. Если вы используете оценки, то сделайте ее заново. Вам не нужно, чтобы частично сделанная работа была засчитана в ваш потенциал, поскольку тогда вы придете к тому, что опять возьмете на себя слишком много работы. Иногда, несмотря на все ваши усилия, вы будете обнаруживать, что ничего полностью не выполнено. Некоторые команды объявляют потерянную итерацию, когда это случается. Они откатывают код и начинают все сначала, как если бы итерации не было. Звучит сурово, но это хорошая практика. Итерации короткие, поэтому много кода вы не выбросите и у вас останется все, что вы узнали и чему научились, пока писали его в первый раз. В результате второй попытки получится лучший код. Компетентные команды редко имеют неЕсли у вас проблемы законченные истории. Если у вас проблемы с завершением историй, с завершением историй, то измените ваш подто измените ваш подход. ход. Снизьте ваш запланированный потенциал, разбивайте истории на еще более мелкие и координируйте общие командные усилия, нацеливая их на завершение каждой истории, прежде чем переходить к следующей. Если это не поможет, значит, что-то организовано неправильно. Спросите совета у вашего наставника.

Срочные запросы Это неизбежно: вы в середине работы над историей, все идет хорошо, а потом ктонибудь из стейкхолдеров говорит: «Нам в самом деле очень нужно взять в работу вот эту историю». Что вы будете делать?

Глава 9.  Владение  267

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

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

268  Часть II.  Фокус на ценность Начните с использования недельных итераций, а свой первый день — с планирования См. также вашей первой итерации. Обычно сюда вхоАдаптивное планирование (глава 8) дит выбор историй из визуального плана, но у вас на тот момент еще не будет плана. Визуальное планирование (глава 8) Вместо этого подумайте над одним ценным Игра в планирование (глава 8) инкрементом, который точно войдет в ваш первый релиз, и проведите миниатюрную сессию игры в планирование для этого инкремента. Придумайте 10–20 историй размера «в самый раз», хорошо понятных для всех. Эти несколько историй должны изобразить «вертикальную полосу» вашего ПО, также известную как «ходячий скелет». Они должны собрать крошечную часть каждой технологии, необходимой для вашего первого инкремента, так, чтобы вы увидели, что программа работает по-настоящему. Если инкремент подразумевает взаимодействие с пользователем, то создайте историю для отображения начального экрана или веб-страницы. Если в него входит база данных, то создайте историю для запроса небольшого количества данных. Если в инкремент входит отчетность, то создайте историю для примитивного отчета. Не ожидайте слишком многого от своих первых историй. Разработчикам понадобится установить техническую инфраструктуру. Поэтому истории должны быть очень маленькими. На начальном экране может не быть ничего, кроме вашего лого. Запрос в базу данных может иметь жестко заданные параметры. Отчет может выводить заголовки и нижние колонтитулы без информационных элементов. Как только у вас появятся начальные истории, вы готовы к планированию задач. Вы можете еще не знать См. также ваш потенциал, поэтому начните с создания задач для всего одной-двух историй. Ваши первые задачи будут Потенциал (глава 9) предназначены для установки технической инфраНулевое трение (глава 13) структуры: контроль версий, автоматическая сборСделано Сделано (глава 9) ка и т. д. Сделайте пока минимум, как описано в подразделе «Автоматизируйте инкрементно» главы 13. В ходе итерации продолжайте фокусироваться на одной или двух историях за раз, заканчивая одну полностью, прежде чем добавить следующую, и так до самого конца итерации. Выполненные истории определят ваш потенциал на следующую итерацию, как описано в подразделе «Ваш начальный потенциал» далее в этой главе. Невыполненные истории можно откатить или превратить в новые, как описывалось в подразделе «Незаконченные истории» ранее в текущей главе. Будет хорошей идеей, если программисты и отдел эксплуатации будут работать над первыми нескольСм. также кими историями вместе, как группа, даже если вы Групповое программироне планируете использовать групповое программирование (глава 12) вание в долгосрочной перспективе. Установите проектор или общий экран, чтобы каждый мог участвовать, пока люди по очереди управляют клавиатурой. Вам не обязательно использовать формальный подход группового программирования, но он может быть полезен.

Глава 9.  Владение  269

Групповая работа над вашими первыми историями помогает снизить ощущение хаоса, возникающее, когда люди только начинают работать вместе. Это поможет вам совместно установить первоначальные соглашения, такие как структура каталогов, имена файлов и пространства имен, базовые варианты дизайна и инфраструктурные решения. Некоторые разработчики или пары разработчиков могут отделиться от группы, чтобы заняться решением необходимых вопросов, например настройкой контроля версий или рабочих станций программистов, но бо́льшую часть времени вы должны работать вместе, командой. Пока разработчики и люди из отдела См. также эксплуатации работают вместе, заказчики в команде и тестировщики должны Адаптивное планирование (глава 8) заняться визуальным планом. Если у вас Визуальное планирование (глава 8) еще нет проекта цели, то начните с него. Другие члены команды могут работать Цель (глава 7) с заказчиками или разработчиками, по своему усмотрению. Каждая следующая неделя будет идти более гладко. Разработчики будут учиться, как делить истории, а заказчики — готовить визуальный план для вытягивания историй. Потенциал команды стабилизируется. Ощущение хаоса пройдет, и команда начнет работать в стабильном предсказуемом ритме.

Вопросы Как планирование задач может занимать менее 10–30 минут? У нас на это всегда уходит гораздо больше времени. Хитрость эффективного планироваСм. также ния задач в том, чтобы использовать его только для планирования задач. МноИгра в планирование (глава 8) жество команд используют свои сессии планирования для оценки и разделения историй, но лучше это делать в рамках отдельной сессии игры в планирование. Планирование задач должно быть сфокусировано на задачах. Истории должны быть готовы до того, как вы начнете. Еще одна хитрость — работать одновременно, используя свободный подход вместо инструментов для отслеживания задач (см. пункт «Работайте одновременно» главы 7). Команды, использующие систему трекинга, как правило, сталкиваются с проблемой узкого места процесса из-за того, что один человек управляет системой и это все замедляет. Используя эти две хитрости и немного попрактиковавшись, ваша команда легко сможет запланировать задачи менее чем за 30 минут. Если же планирование все еще идет медленно, то причиной может быть то, что людям трудно прийти к согласию по поводу того, что предстоит делать. Помните, что лучше создавать специальные задачи для открытых вопросов, чем пытаться решать их во время встречи по планированию задач. Если и это не поможет, то попросите совета у наставника.

270  Часть II.  Фокус на ценность Как нам запланировать время на исправление См. также багов? Каждый раз, когда вы находите баг, даже если Без багов (глава 16) он не связан с историями в вашем плане, заказчики в команде должны принять решение, исправлять его или нет. Если он должен быть исправлен, то добавьте соответствующие задачи в свой план независимо от того, имеют ли они отношение к вашим текущим историям. Эти задачи по исправлению багов — часть ваших рутинных процессов, и они не включаются в расчет вашего потенциала. Некоторые баги будут слишком большими, чтобы войти в вашу текущую итерацию. Создайте для них карточки историй и запланируйте их на следующую итерацию. Незамедлительное устранение поможет вам снизить количество багов, с которыми вы сталкиваетесь. Если у вас старая кодовая база с большим количеством багов, то пройдитесь по вашей базе данных багов и по каждому примите решение, исправлять их или нет в следующем релизе. Закройте или отложите баги, помеченные «не исправлять», а остальные превратите в истории. Все задачи в нашем плане зависят от кода, над которым все еще работают другие люди. Что нам делать? Вы можете писать код, зависящий от незавершенного кода. Поговорите с людьми, которые работают над тем кодом, и договоритесь об именах модулей, классов и методов. Затем сделайте заготовку той части, над которой они работают. В разделе «Коллективное владение кодом» главы 12 содержится больше информации по этой теме.

Предварительные требования И итерации, и непрерывный поток полагаются на небольшие истории — каждая примерно на один день, если команда работает совместно. Более крупные истории могут незаметно выполняться неправильно. Каждая история, законченная командой, должна См. также вести к прогрессу, который могут признать и оценить заказчики в команде — если не в эксплуатационной Истории (глава 8) (production) среде, то хотя бы в промежуточной (staging). Для этого требуется, чтобы истории были Инкрементный дизайн (глава 14) ориентированы на заказчика, а техническая инфраструктура создавалась инкрементно. Потенциал (глава 9) Последовательное выполнение обязательств Резерв времени (глава 9) в итерациях требует, чтобы ваши возможности основывались на измеренной реальности. Никогда не завышайте искусственно потенциал вашей команды. Но даже в этом случае чтото может пойти не так, поэтому ваша итерация должна содержать резерв времени, чтобы покрыть эти проблемы. Никогда не используйте обязательство как дубинку. Не заставляйте членов команды подписываться на план, с которым они не согласны. Не раскрывайте информацию об обязательствах по итерациям вне команды, пока у вас не будет подтвержденного списка успешных случаев выполнения таких обязательств.

Глава 9.  Владение  271

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

Альтернативы и эксперименты Выдающееся отличие Agile-планирования задач от не-Agile — коллективное владение. Команды Agile не только отвечают за свое планирование, но и совместно работают над выполнением плана. В не-Agile-командах обычно руководители распределяют задачи среди сотрудников, и люди фокусируются на своих индивидуальных задачах. Еще одно различие заключается в итеративной и поэтапной природе Agile. Маленькие истории приводят к стабильному инкрементному прогрессу. Команды демонстрируют этот прогресс с помощью работающего ПО каждую неделю или две. Они используют это ПО для получения обратной связи, которая, в свою очередь, заставляет их итеративно повторять свои планы. Когда вы задумаетесь о способах экспериментирования с планированием задач, помните об этих различиях. Однако не стремитесь слишком сильно к экспериментам: в планировании задач очень много тонкостей, особенно в итерациях, поэтому сфокусируйтесь на том, чтобы достичь действительно хороших результатов в назначении и выполнении обязательств по недельным итерациям, и только потом ищите альтернативы. Отведите на это по меньшей мере несколько месяцев. Когда будете готовы к экспериментам, самым очевидным вариантом будет попробовать непрерывный поток вместо итераций. Кроме того, вы можете поэкспериментировать с длиной итераций и размером историй. Некоторые команды предпочитают использовать очень маленькие истории, выполнение которых занимает всего несколько часов. Для таких команд задачи не являются необходимостью. Истории настолько малы, что сами по себе служат задачами. Область, в которой вы можете сразу начать эксперименты, — это визуализация вашей доски задач. Как наглядное представление процессов вашей команды, она может и должна меняться в любое время, когда у вас появляются идеи по улучшению ваших процессов. Одна из общеизвестных визуализаций задач — создание вертикальных обзорных полос (swim lanes), показывающих прохождение историй через разные фазы

272  Часть II.  Фокус на ценность разработки. Я избегаю этого подхода, поскольку Agile проявляет себя наилучшим образом, когда вы работаете над всеми фазами одновременно, — но, безусловно, это зависит от практик поставки. Командам, которые не стремятся к компетентности в области поставки, диаграмма обзорных полос может быть полезна.

Литература для дополнительного чтения Agile Estimating and Planning1 [Cohn2005] и Planning Extreme Programming2 [Beck2000b]. Каждая из этих книг предлагает альтернативные способы подхода к планированию итераций. Непрерывный поток часто называют Kanban. Однако Kanban — нечто гораздо большее, чем просто непрерывный поток. Kanban3 [Anderson2010] — хороший источник дополнительной информации по этой теме.

ПОТЕНЦИАЛ Мы знаем, за какой объем работы можем взяться. Аудитория Предполагается, что команды, использующие итерации, должны завершать каждую историю в каждой Разработчики итерации. Но как они узнают, за какое количество историй они могут взяться? Здесь и появляется понятие потенциала. Потенциал — это прогнозный показатель того, сколько работы команда может гарантированно выполнить за одну итерацию. Потенциал нужен только для того, чтобы спрогнозировать, что вы можете включить в вашу следующую итерацию. Если же вам нужно рассчитать, когда будет выпущен конкретный набор историй, то прочитайте раздел «Прогнозирование» главы 10. Если вы используете непрерывный поток вместо итераций, то вам не нужно беспокоиться о потенциале. Вы просто будете начинать новые истории, когда закончите предыдущие. ПРИМЕЧАНИЕ Изначально потенциал (capacity) назывался скоростью (velocity). Но я больше не использую этот термин, поскольку «скорость» предполагает такой уровень контроля, которого на самом деле не существует. Представьте автомобиль: его скорость легко увеличить; просто нажмите педаль газа. Но если вам нужно повысить потенциал автомобиля, то потребуются более серьезные изменения. Потенциал команды — то же самое. Его не так просто изменить.

Кон М. Agile: оценка и планирование проектов.

1

Бек К., Фаулер М. Экстремальное программирование: планирование. — СПб.: Питер, 2002.

2

Андерсон Д. Дж. Канбан. Альтернативный путь в Agile.

3

Глава 9.  Владение  273

Вчерашняя погода Потенциал может быть спорной темой. ЗаКогда на команды давят, чтобы они казчики хотят, чтобы команда поставляподписались на большее, чем могут ла больше каждую неделю. Разработчики сделать, проигрывают все. не хотят, чтобы их торопили или давили на них. Так как заказчики обычно пользуются вниманием спонсора команды, то имеют тенденцию побеждать… в краткосрочной перспективе. В долгосрочной перспективе, когда на команды давят, чтобы они подписались на большее, чем могут сделать, проигрывают все. Реальность побеждает, и разработка в итоге занимает больше времени, чем ожидалось. Чтобы избежать этих проблем, измеряйте свой потенциал. Не гадайте. Не надей­ тесь. Просто измеряйте. Это просто: вероятно, на этой неделе вы сделаете столько же, сколько сделали на прошлой. Это также известно как «вчерашняя погода», поскольку вы можете прогнозировать сегодняшнюю погоду, говоря, что она, скорее всего, будет такой же, как вчерашняя. Если конкретнее, ваш потенциал — это количество историй, которые вы начали делать и полностью закончили в предыдущей итерации. Частично сделанные истории не считаются. Например, если вы начали семь историй в прошлой итерации и завершили шесть из них, то ваш потенциал — шесть, и в следующей итерации вы можете взять в работу шесть историй. ПРИМЕЧАНИЕ Не усредняйте несколько итераций. Просто используйте предыдущую. В подразделе «Стабилизация потенциала» далее в этой главе объясняется, как установить стабильный потенциал без усреднения.

Подсчет историй работает, только если ваши истории примерно одного размера. Вы можете разделять и объединять истории, чтобы получить размер «в самый раз», как описывалось в подразделе «Разделение и объединение историй» главы 8. Со временем ваша команда научится делать истории одного размера. Поначалу ваши истории, скорее всего, не будут иметь одинаковый размер. В этом случае вы можете делать оценку историй, как я описываю в подразделе «Оценка историй» далее в данной главе. Чтобы измерить ваш потенциал, используя оценки, посмотрите на истории, которые вы начали и полностью завершили за последнюю итерацию. Сложите их оценки. Это и будет ваш потенциал. Например, если вы завершили шесть историй из тех, что начали в предыдущей итерации, и их оценки были 1, 3, 2, 2, 1, 3, то ваш потенциал — 1 + 3 + 2 + 2 + 1 + 3 = 12. Для следующей итерации вы можете выбрать любые понравившиеся вам истории так, чтобы их общая оценка равнялась 12. «Вчерашняя погода» — простой и при этом удивительно утонченный инструмент. Это петля обратной связи, которая приводит к магическому эффекту: если ваша команда недооценивает свою рабочую нагрузку и не может завершить все истории к концу итерации, то ваш потенциал снижается и вы беретесь за меньшее количество работы в следующий раз. Если вы переоцениваете свою нагрузку и заканчиваете

274  Часть II.  Фокус на ценность раньше, то ваша команда берет больше историй, ее потенциал возрастает и вы беретесь за большее количество работы. Это невероятно эффективный способ баСм. также лансировки нагрузки. В сочетании с резервом времени потенциал позволяет вам достоверно Резерв времени (глава 9) прогнозировать, сколько работы вы можете сделать за итерацию.

Потенциал и временные рамки итерации «Вчерашняя погода» опирается на строгие временные рамки итерации. Чтобы потенциал работал, никогда не засчитывайте истории, которые не получили статус «Сделано Сделано» в конце итерации. Никогда не сдвигайте, даже на несколько часов, предельный срок итерации. У вас может появиться соблазн немного обИскусственное увеличение мануть и отодвинуть предельный срок окончацифры вашего потенциала только ния итерации или засчитать историю, которая усложнит выполнение ваших почти сделана. Не делайте этого! Конечно, это обязательств. увеличит цифру вашего потенциала, но нарушит петлю обратной связи. Вы возьметесь за больший объем работы, чем сможете выполнить, усилив проблему в следующий раз и еще больше усложнив выполнение ваших обязательств. Один руководитель проекта, с которым я сотрудничал, хотел добавить несколько дней перед началом итерации, чтобы его команда могла немедленно приступить к работе, а он смог бы получить более впечатляющую цифру потенциала и гордо продемонстрировать ее своему руководителю. Сделав это, он обрек свою команду на провал: она не смогла поддерживать взятый темп в следующей итерации. Помните, что потенциал нужен для прогнозирования того, сколько вы можете уместить в итерацию. Это не показатель продуктивности. Потенциал не стабилен, когда команды только формируются и учатся работать по Agile. Для стабилизации потребуются три-четыре итерации. После этого у вас должен быть один и тот же потенциал на каждой итерации, если она не попадает на праздничные дни. Используйте ваш резерв времени в итерации, чтобы убедиться, что стабильно заканчиваете каждую историю. Если потенциал команды меняется больше чем один-два раза в квартал, то ищите более глубокие проблемы и задумайтесь о том, чтобы попросить помощи у наставника.

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

См. также Сделано Сделано (глава 9)

Глава 9.  Владение  275

Но как ваш потенциал вернется на прежний уровень? Парадоксально, но вам нужно быстро снижать потенциал и медленно повышать. Повышайте его лишь то­гда, когда вы не только завершили все запланированные истории, но и имели достаточно времени на уборку по окончании: вы вычистили плохие участки в коде, который был задействован в итерации, улучшили автоматизацию и инфраструктуру и позаботились о других важных, хотя и не срочных задачах, имеющих отношение к истории, над которой вы работали. Если вам хватило времени на уборку, то можете Повышайте потенциал, взять дополнительную историю. Если вы завертолько когда вам хватает шите ее до окончания итерации, то ваш потенциал времени на уборку повысится. по окончании работы. Я работаю со многими командами и вижу одну общую проблему — чрезмерное давление на график. Оно повсеместно снижает производительность команд, заставляет их торопиться, сокращать сроки и совершать ошибки. Эти сокращенные сроки и ошибки вредят их внутреннему качеству (качеству кода, автоматизации и инфраструктуры), а плохое качество приводит к тому, что все идет медленнее, из-за чего, как ни странно, им остается меньше времени на работу. Это порочный круг, который и дальше усиливает нагрузку на график и снижает производительность. Наиболее эффективный способ улучшить производительность команд в этой ситуации — снизить давление на график. Потенциал сделает это автоматически, если вы ему позволите. На рис. 9.3 показана стабилизация потенциала.

Рис. 9.3. Стабилизация потенциала

Тонкая ломаная линия показывает потенциал команды под высоким давлением. Это потенциал, если члены команды максимально торопятся. Вы можете увидеть, что он сильно переменчив. Несколько недель все идет гладко. В другие недели команда сталкивается с багами и проблемами качества. Толстая плавная линия показывает потенциал команды под низким давлением. Это результат следования правилу «быстро снижать и медленно повышать». Вы можете увидеть, что когда команде не удалось сделать все запланированное, ее члены понизили потенциал и не повышали его какое-то время.

276  Часть II.  Фокус на ценность Затененные пики представляют командный резерв времени: разница между потенСм. также циалом команды под низким давлением и коРезерв времени (глава 9) личеством времени, которое ей понадобилось для завершения своих историй. В течение нескольких недель команда имела очень большой резерв. В другое время — очень маленький. Когда у команды был большой резерв времени, участники использовали его для повышения внутреннего качества и решения тормозящих их проблем. Со временем это дополнительное усилие оправдывает себя. Так как члены команды не спешат изо всех сил, они постепенно повышают внутреннее качество и решают проблемы. В результате люди расслаблены, контролируют ситуацию и имеют больше времени, чем необходимо для уборки. Вот тогда они увеличивают свой потенциал. Результат — улучшение потенциала и работа, приносящая больше удовольствия, чем у команд, спешащих изо всех сил. Этот график иллюстрирует мой реальный Резерв времени — лучший из ваших опыт, а не какую-то абстрактную теорию. вариантов реального улучшения Я видел множество вариаций на эту тему количества работы, которую может в реальных командах. Может быть трудно выполнить ваша команда. стабилизировать потенциал, когда ваша команда находится под высоким давлением, но оно того стоит. Резерв времени — лучший из ваших вариантов реального улучшения количества работы, которую может выполнить ваша команда.

Почему точность оценки не имеет значения Потенциал автоматически подстраивается, если оценки неточные. Вот как это работает. Предположим, у вас есть 30 человеко-дней на одну итерацию. Для упрощения примера пусть все истории команды оцениваются в три дня работы каждая. Если оценки идеально точны, то команда должна быть в состоянии сделать 10 историй за итерацию (30 человеко-дней на одну итерацию ÷ 3 дня на историю). Но оказывается, что их оценки не идеально точны! Фактически они даже не рядом. На самом деле от команды требуются шесть человеко-дней на завершение каждой истории, а не три. В конце итерации команда закончила только пять историй (30 человеко-дней на одну итерацию ÷ 6 дней на историю). Измеренный потенциал команды — 15: члены команды закончили пять историй, оцениваемых в три дня каждая. Таким образом, в следующей итерации они могут взяться только за пять историй (потенциал 15 ÷ 3 дня на историю). И хотя их оценки совершенно неверны, они завершат все истории до единой (30 человеко-дней ÷ 6 дней = 5 историй). Эти расчеты приведены только для того, чтобы вы понимали петлю обратной связи. В реальном мире вам не нужно производить никаких расчетов. Сочетание потенциала и резерва времени необыкновенно простое и устойчивое. Просто стабилизируйте ваш потенциал, как я описал, и все получится.

Глава 9.  Владение  277

Оценка историй «Вчерашняя погода» полагается на стабильность, но у вашей команды могут быть трудности с созданием историй постоянного размера. Это нормально. Вы можете использовать оценку. Как обсуждалось во врезке в предыдущем подразделе, неважно, насколько точны ваши оценки, пока они постоянны. Это хорошая новость, поскольку программисты, как правило, оценивают очень плохо. Одна команда, с которой я работал, измеряла реальное время, которое занимали ее истории. Мы делали это в течение 18 месяцев. Оценки никогда не были точными: в среднем команда использовала около 60 % фактически необходимого времени. Но знаете что? Это было неважно, поскольку оценки, даваемые командой, были стабильны, по крайней мере в совокупности. У той команды был стабильный потенциал, и она постоянно завершала каждую историю в течение нескольких месяцев. Таким образом, делайте оценку ваших историй и не беспокойтесь о точности. Просто концентрируйтесь на стабильности. Вот как это нужно делать. zz

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

zz

Позвольте экспертам делать оценки. Сколько времени займет работа над ис­торией, по мнению членов команды, наиболее квалифицированных в этой работе?

zz

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

zz

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

zz

Округляйте в три корзины. Все, что больше, должно быть разделено; все, что меньше, — объединено. Чтобы выбрать свою корзину, разделите ваш потенциал на 12, затем умножьте на 2 и 3. Настраивайте результаты по мере необходимости. Например, если ваш потенциал находится между 9 и 14, то ваша корзина должна быть размером 1, 2 и 3. Если потенциал между 3 и 8, то ваша корзина должна быть размером 1/2, 1 и 11/2. Цель — иметь по меньшей мере четыре истории на итерацию и шесть в среднем.

Этот подход даст вам оценку в идеальных часах или днях. Реальная работа зай­мет гораздо больше времени, но это неважно: вы стремитесь к постоянству, а не к точности. Чтобы люди ошибочно не принимали ваши оценки за обязательства, называйте эти цифры пойнтами, а не часами или днями.

278  Часть II.  Фокус на ценность Когда вы наберетесь опыта, эти техники будут работать еще лучше. zz Ищите совпадения с другими историями. Что вы говорили о других историях, похожих на эту? Используйте те же оценки. zz Сравнивайте с другими историями. Эта история потребует в два раза больше работы или в два раза меньше, чем другая? Соответственно увеличьте или уменьшите оценку вдвое. zz Прислушайтесь к своему чутью. Используйте те цифры, которые вам кажутся правильными. У меня есть два вида оценочных сессий, которые вы можете использовать: разговорные оценки и оценки по сходству. В любом случае привлеките всех, кто имеет квалификацию, позволяющую выполнять эту работу (оценщики), и по меньшей мере одного заказчика в команде. Другие члены команды тоже могут присоединиться (для них обсуждения могут быть информативны), но это не обязательно.

Пример оценочной сессии: разговорная оценка Команда собралась для оценки историй. Элисса, одна из заказчиков в команде, начинает дискуссию. Кенна, Инга и Остин — программисты. Элисса: Вот наша следующая история. (Она читает историю вслух, потом кладет ее на стол.) «Отчет о запасах запчастей на складе». Кенна: Это часть усилий по устранению расхождений в складских данных, да? (Элисса кивает.) Мы уже сделали столько отчетов на сегодняшний день, что еще один не должен вызвать трудностей. Они обычно состоят из одного пункта. Мы уже отслеживаем складские запасы, так что нам не понадобится управлять какимилибо новыми данными. Есть что-то необычное в этом отчете? Элисса: Не думаю. Мы соберем макет. (Она вытаскивает распечатку и передает ее Кенне.) Кенна: Выглядит довольно понятно. (Она кладет бумагу на стол. Другие программисты смотрят ее.) Инга: Элисса, что это за колонка «возраст»? Не думала, что возраст имеет отношение к расхождениям на складе. Элисса: Верно, не имеет. Это количество рабочих дней с того момента, как запчасть поступила на склад. Мы подумали, что это будет полезно на будущее. Инга: Нужны рабочие дни, не календарные? Элисса: Совершенно верно. Инга: Как насчет праздников? Элисса: Мы хотим считать только те дни, в которые работаем. Без выходных, праздников и плановых остановок. Остин: Инга, я вижу, к чему ты клонишь. Элисса, у нас есть дата, когда запчасть поступила на склад, но мы сейчас не отслеживаем плановые остановки. Нам понадобится новый UI или поток данных, чтобы получить эту информацию. Это может усложнить экраны администраторов, а ты и Брэдфорд говорили, что

Глава 9.  Владение  279

простота администрирования важна для вас. Можем ли мы делать этот отчет в календарных днях? Элисса: Хм. Точное число неважно, но люди обычно мыслят в терминах рабочих дней, и если мы собираемся предоставлять эту информацию, то я бы хотела, чтобы она была точной. Что насчет праздников? Вы сможете это сделать? Инга: Мы можем считать, что праздники будут одни и те же каждый год? Элисса: Не обязательно. Но они не будут меняться слишком часто. Инга: Хорошо. Тогда мы можем пока поместить их в конфигурационный файл, вместо того чтобы создавать для них UI. Это обойдется дешевле. Элисса: Знаешь, я хочу отложить это на потом. Это поле — не самый главный наш приоритет, и я не думаю, что оно достойно дополнительных затрат. Давайте пока это оставим. Я сделаю для этого отдельную историю. (Она берет карточку и записывает: «Добавить колонку “возраст” к отчету о запасах запчастей».) Остин: Звучит неплохо. Этот отчет будет довольно простым. Для него нужен UI? Элисса: Все, что нам нужно сделать, — это добавить его в список на экране отчетов. Инга: Думаю, я готова сделать оценку. (Смотрит на других программистов.) Мне кажется, это довольно стандартный отчет. Это еще одна специализация для уровня отчетов с несколькими небольшими изменениями в логике. Я согласна с Кенной. Это один пункт. (Остин кивает.) Кенна: Один пункт. (Она записывает «1» на карточке истории.) Элисса, я думаю, мы не сможем оценить историю «возраст», пока ты не будешь знать, какой UI хочешь для этого. Элисса: Справедливо. (Добавляет стикер «Раб. дней? UI?» на карточку «возраст» и откладывает ее в сторону.) Наша следующая история...

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

280  Часть II.  Фокус на ценность Поначалу у разных членов команды будут разные идеи о том, сколько времени зай­ мет что-либо. Это будет приводить к нестабильным оценкам. Проговорите это, и если вы не сможете прийти к согласию, то используйте наименьшую оценку. (Помните, вам нужно только постоянство, а не точность.) Со временем, когда команда будет продолжать совместно делать оценки, ваши оценки будут синхронизироваться. Как правило, это происходит в течение трех или четырех итераций. Если участники понимают историю и лежащую в ее основе технологию, то смогут оценить каждую историю менее чем за минуту. Если им необходимо обсудить технологию или задать вопросы заказчикам, то оценка может занять больше времени. Я ищу способы завершить дискуссию, если процесс оценки начинает занимать больше пяти минут. Если каждая история требует подробного обсуждения, то что-то идет не так — см. подраздел «Когда оценить трудно» далее в текущей главе. ПРИМЕЧАНИЕ Некоторым нравится использовать для оценки покер планирования (planning poker)1. В нем участники тайно выбирают карточку со своей оценкой, затем одновременно раскрывают карты и обсуждают результаты. Это звучит забавно, но приводит к множеству ненужных дискуссий. Данный метод полезен, если людям трудно выражать свое мнение, но в других случаях обычно быстрее дать высказаться первым тому, кто не испытывает с этим неудобств.

Оценка по сходству Оценка по сходству (affinity estimating) — прекрасная техника быстрой оценки большого количества историй2. Она особенно полезна, когда у вас длинные горизонты планирования. Оценка по сходству — вариант молчаливого сопоставления (mute mapping) (см. пункт «Работайте одновременно» главы 7). Заказчик в команде кладет стопку карточек для оценки на стол или виртуальную доску. Один конец определяется как наименьший, а другой — как наибольший. Затем оценщики распределяют карточки вдоль этого спектра, группируя их в кластеры похожего размера. Карточки, которым требуются дополнительные пояснения от заказчиков, помещаются в отдельный кластер в стороне, как и карточки, которым требуется спайк-история (см. пункт «Спайк-истории» главы 8). Вся эта работа выполняется молча. Оценщики могут передвигать карточки, если не согласны с тем, где те находятся, но не могут это обсуждать. Выполнение этой работы в тишине помогает не отвлекаться, что обычно характерно для процесса обсуждения оценок. В результате составление карты оценок происходит очень быстро. 1

Покер планирования (planning poker) был изобретен Джеймсом Греннингом в 2002 году [Grenning2002] и позже популяризирован Майком Коном в [Cohn2005]. Компания Кона, Mountain Goat Software, LLC, зарегистрировала этот термин как торговую марку.

Оценка по сходству (affinity estimating) была изобретена Ловеллом Линдстромом в ранние дни экстремального программирования.

2

Глава 9.  Владение  281

Один человек рассказывал мне, что их команда оценила 60 историй за 45 минут в первый же раз, когда они пробовали этот метод. После того как все истории сгруппированы, команда отмечает каждый кластер цифрой оценки. Цифры на самом деле неважны, если верны относительные размеры. Другими словами, история в кластере, отмеченном цифрой 2, должна занимать в два раза больше времени, чем история в кластере, отмеченном цифрой 1. Однако для согласованности с разговорными оценками может иметь смысл делать оценки в идеальных часах или днях. Оценка кластеров должна занимать всего минуту или две. В конце выберите три кластера, совпадающих с вашими оценочными корзинами (описанными ранее). Например, если ваш потенциал равен 15, вы выберете кластеры, оцененные в 1, 2 и 3. Истории в более крупных кластерах должны быть разделены, а в более мелких — объединены. Карточки в ваших трех финальных корзинах готовы к работе. Запишите на каждой их оценки. Оставшиеся карточки нужно разделить, объединить, обсудить или исследовать с помощью спайк-историй в зависимости от того, в каком кластере они оказались. Это можно делать одновременно, а затем провести следующую сессию сопоставления оценок или последовательно, по одной за раз, с помощью разговорной оценки.

Когда оценить трудно Когда ваша команда только формируется, процесс оценивания будет довольно медленным и болезненным. По мере применения он будет улучшаться. Одна общая причина медленного оценивания — недостаточная подготовка со стороны заказчиков в команде. Поначалу оценщики задают вопросы, которые заказчики не принимали во внимание. В некоторых случаях заказчики могут иметь между собой разногласия насчет правильного ответа и должны разобраться с этим. Совещание заказчиков (customer huddle) (на котором заказчики вкратце обсуждают какой-либо вопрос, приходят к решению и возвращаются к оценке) — один из способов, позволяющих с этим справиться. Пока заказчики совещаются, оценщики продолжают оценку историй, с которыми им все понятно. Другой вариант — записать вопрос на стикер и приклеить его на карточку. Заказчики берут карточку и прорабатывают детали в своем темпе, затем приносят ее обратно на оценку к следующей сессии. Неопытность разработчиков также может быть причиной медленного процесса оценивания. Если оценщики не очень хорошо понимают истории, то должны будут задать множество вопросов, прежде чем смогут сделать оценку. Однако если они не понимают технологию, то нужно просто создать спайк-историю (см. пункт «Спайкистории» главы 8) и идти дальше. Некоторые оценщики стараются разобраться со всеми деталями истории до того, как делать оценку. Помните, что единственные детали, которые имеют значение во время оценки, — это те, из-за которых историю могут поместить в другую корзину. Сосредоточьтесь на деталях, которые могут изменить оценку, и отложите остальное на потом.

282  Часть II.  Фокус на ценность Такое чрезмерное внимание к деталям иногда является следствием того, что оценщик неохотно делает оценку. Это свойственно программистам, которые сталкивались в прошлом с использованием своих оценок против себя. Они будут пытаться делать максимально точные оценки, вместо того чтобы стремиться к «достаточно хорошему» постоянству. Сопротивление оценщиков может быть признаком организационных сложностей или чрезмерного давления на график либо может быть сопряжено с прошлым опытом, никак не связанным с нынешней командой. В последнем случае оценщики обычно со временем начинают доверять команде. Чтобы помочь с решением этих проблем во время сессии оценки, вы можете задавать наводящие вопросы. Например: zz

проблемы у заказчиков — требуется ли совещание заказчиков по этому вопросу? Не нужно ли сделать историю для этого вопроса и вернуться к нему позже?

zz

оценщики не уверены насчет технологии — не нужно ли нам создать спайк-историю для этого?

zz

оценщики задают очень много вопросов — у нас достаточно информации, чтобы оценить эту историю? Ответ на этот вопрос повлияет на оценку истории?

zz

история занимает больше пяти минут — может, вернемся к этой истории позже?

Защита оценки Это почти закон природы: заказчики в команде и стейкхолдеры неизменно разочарованы потенциалом своей команды. Иногда они выражают это в неуважительной манере. Члены команды, обладающие хорошими социальными навыками, могут помочь разрядить обстановку. Часто лучшим подходом будет игнорировать тон людей и расценивать комментарии как простые запросы информации. На самом деле некоторое количество обмена репликами даже полезно. Как обсуждалось в подразделе «Как выиграть в игре в планирование» главы 8, вопросы относительно оценок могут приводить к созданию лучших историй, сфокусированных на таких аспектах идей заказчиков, как высокая ценность и низкая стоимость. Однако будьте осторожны: вопросы моВежливо и твердо откажитесь менять гут заставить оценщиков усомниться в свовашу оценку, если на вас давят. их оценках. Разработчики, ваши оценки, скорее всего, корректны или по меньшей мере стабильны, что действительно важно. Меняйте свою оценку, только если узнали что-то поистине новое. Не меняйте ее лишь потому, что чувствуете, что на вас давят. Вы — те, кто будет реализовывать истории, и вы наиболее квалифицированны, чтобы делать оценки. Будьте вежливы, но настойчивы: Мне жаль, что вам не нравятся эти оценки. Мы уверены, что они корректны, но если они слишком пессимистичны, то наш потенциал автоматически возрастет,

Глава 9.  Владение  283

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

Если стейкхолдер отвечает недоверием или пытается запугивать, он может не осознавать, насколько невежливо себя ведет. Иногда может помочь, если вы просто объясните ему, как выглядит его поведение: У меня складывается впечатление, что вы не уважаете и не доверяете нашему профессионализму. Вы действительно имеете это в виду?

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

См. также Дорожные карты (глава 10)

Пoйнт (point) — метод оценки, ориентированный на единообразие. Он позволяет делать краткосрочные прогнозы, основываясь на результатах измерений. Наш потенциал по результатам измерений — 12 пойнтов, это означает, что мы закончили 12 пойнтов работы за прошлую неделю. Следовательно, мы прогнозируем, что сможем завершить 12 пойнтов работы на этой неделе.

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

Обычно собеседник на этом отступает, но если скажет «да», то детально отследите время каждого работника в течение недели. Это утомительно, но должно развеять сомнения, и вы можете использовать снова тот же отчет в следующий раз, когда кто-нибудь спросит. Подобные вопросы, как правило, исчезают по мере См. также того, как стейкхолдеры начинают доверять способностям команды выполнять поставленные задачи. Если этого Доверие стейкхолдене происходит или если отсутствие доверия особенно ров (глава 10) усложняет вашу ситуацию, то попросите помощи у вашего руководителя или наставника.

284  Часть II.  Фокус на ценность

Ваш начальный потенциал Когда вы планируете вашу первую итерацию, у вас еще нет никакой истории, поэтому у вас не будет ни потенциала, ни оценочных корзин. Начните с использования недельных итераций и корзин размером 1/2 дня, 1 день или 1,5 дня. Работайте над одной или двумя историями за раз, как обсуждалось в подразделе «Ваша первая неделя» ранее в данной главе. В конце первой итерации у вас будет потенциал, который вы сможете использовать для следующей итерации. Помните, что не нужно засчитывать незавершенные истории. Выбросьте их и создайте новые истории с новыми оценками, представляющими количество оставшейЧастично сделанная работа никогда ся работы. (Да, это означает, что вы не зане засчитывается. считаете частично сделанную работу. Она никогда не засчитывается.) Если у вас сделано меньше четырех историй, то разделите оценочные корзины на две (используйте двух-, четырех- и шестичасовые корзины) для вашей следующей итерации. Если сделано 12 историй, то увеличьте корзину вдвое (один, два и три дня). Продолжайте таким образом, пока ваш потенциал не стабилизируется. Ваш потенциал должен стабилизироваться после примерно четырех итераций. По мере приобретения опыта вы, в конце концов, сможете задавать размер историй так, чтобы завершать одно и то же их количество за каждую итерацию. Когда это станет привычным, вы можете совсем перестать делать оценки и просто считать истории. Но чтобы быть уверенными в правильности размера историй, вам все еще будет необходимо обсуждать их с заказчиками.

Как улучшить потенциал Стейкхолдеры всегда хотят больше потенциала. Это возможно… но не бесплатно. У вас несколько вариантов.

Повысить внутреннее качество Наиболее распространенная проблема с потенциалом — низкое внутреннее качество: плохой код, медленные и ненадежные тесты, плохая автоматизация и ненадежная инфраструктура. Это также называется техническим долгом. Внутреннее качество влияет на команду гораздо сильнее, чем любой другой фактор. Сделайте внутреннее качество вашим приоритетом, и оно значительно улучшится. Однако это не быстрый процесс. Командам, имеющим проблемы низкого внутреннего качества, часто предстоят месяцы или даже годы работы по очистке от проблем. Вместо того чтобы останавливать всю работу, чтобы разобраться с проблемами, См. также улучшайте качество инкрементно, используя резерв времени, как описывалось в подРезерв времени (глава 9) разделе «Стабилизация потенциала» ранее

Глава 9.  Владение  285

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

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

См. также Вся команда (глава 7)

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

См. также Энергичная работа (глава 7)

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

Поддерживать ограничение Люди, которые не могут участвовать в работе над задачами, связанными с ограничениями, будут иметь свободное время. Они должны сделать так, чтобы тем, кто работает над ограничениями, никогда не приходилось их ждать, но не должны работать на опережение. Это только создаст дополнительный объем незавершенной работы (см. врезку «Минимизируйте объем незавершенной работы» в главе 8). Вместо этого используйте дополнительное время для снижения нагрузки на активность, связанную с ограничением. Классический пример — тестирование. Некоторым командам нужно так много ручного тестирования, что последние дни каждой итерации у них полноИспользуйте стью посвящены тестированию ПО. Вместо того дополнительное время чтобы переходить к разработке следующего набора для снижения нагрузки функциональностей, программисты могут использона активность, связанную вать это время для написания автоматизированных с ограничением. тестов, что снизит нагрузку на тестирование.

286  Часть II.  Фокус на ценность

Обеспечивать необходимые ресурсы У большинства команд имеются все необходимые им ресурсы. (Помните, под ресурсами подразумеваются оборудование и сервисы, а не люди.) Однако если члены команды жалуются на медленные компьютеры, недостаточную RAM или неподходящий инструментарий, то обеспечьте им эти ресурсы. Всегда удивляет, когда компании экономят на своих командах разработки. Есть ли смысл экономить 5000 долларов на стоимости оборудования, если это стоит каждому полчаса в день? Команда из шести человек окупит эти затраты за месяц. А как насчет вероятных затрат из-за более медленных релизов?

Добавлять людей (осторожно) Потенциал связан с количеством людей, которые См. также могут работать в условиях ограничений вашей команды. Но если ваша команда не испытыПарное программирование вает крайней нехватки персонала и опытные (глава 12) сотрудники легкодоступны, то ее пополнение Групповое программирование не окажет немедленного эффекта. Как сказал (глава 12) [Brooks1995], «добавление людей в отстающий Коллективное владение кодом проект делает его еще более отстающим». Ожи(глава 12) дайте, что новым членам команды понадобится месяц или два, чтобы стать продуктивными. Командная комната (глава 7) Сократить этот срок может помочь плотное взаимодействие. Аналогично пополнение больших команд может вызвать трудности с общением и снижение продуктивности. Я предпочитаю, чтобы в команде, использующей парное программирование, было шесть программистов, и всегда готов добавить хороших программистов, чтобы достичь этого предела. После него я уже осторожен в плане добавления новых людей и крайне редко увеличиваю команду, если она достигла размера восьми человек. Другие навыки добавляются пропорционально, как рассказывается в разделе «Вся команда» главы 7.

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

Глава 9.  Владение  287

времени, которое они тратят на ожидание других людей. Время, которое они тратят на выполнение рутинных задач организации. Как часто они выбирают «короткий путь», выполняя задачи. Объем их резерва времени. Эти факторы различаются у каждой команды, поэтому вы не можете использовать потенциал для сравнения двух команд. Если у одной команды вдвое больший потенциал, чем у другой, это может означать, что у нее меньше затрат на рутину… но более вероятно, что у нее просто другой подход к оценке. Кроме того, у команд нет возможности контролировать большинство факторов, которые влияют на потенциал. В краткосрочной перспективе они могут только управлять количеством своих рабочих часов и количеством «коротких путей». Таким образом, команда, о которой судят по ее потенциалу, может ответить на это давление, только работая сверхурочно, делая работу небрежно или уменьшая свой резерв времени. Это может вызвать краткосрочный скачок потенциала, но снизит реальную способность команды поставлять продукт. Не разглашайте значение потенциала команды за ее пределами. Если вы руководитель, то не отслеживайте, не поощряйте и даже не обсуждайте потенциал, за исключением вопросов содействия его стабилизации. И никогда не называйте его производительностью. Чтобы понять, что нужно делать вместо этого, прочтите раздел «Менеджмент» главы 10. К А Р ГО - К УЛ ЬТ

Нужно торопиться «Вам нужно поторапливаться! — рявкает Бекки. Она руководитель вашего руководителя. — У команды Сильвы потенциал вдвое больше вашего. Это ненормально, что у вас вдвое меньшая производительность». «Окей… — говорите вы, с трудом подавляя желание сделать что-нибудь неблаговидное и наконец освободиться от всего этого. — Во-первых, команда Сильвы занята совершенно другой работой, поэтому значения потенциала несравнимы. Во-вторых, — вы пытаетесь улыбнуться, — я бы очень хотел повысить наш потенциал. Самое большое препятствие, которое нас сдерживает, — ограниченный доступ к Кристиане. Она не хочет, чтобы мы сами общались со стейкхолдерами, но при этом не может участвовать в наших сессиях планирования. Нам постоянно приходится переделывать работу». «Ох, только не надо, — не соглашается Бекки. — Она занята. А вы же Agile. Это значит — вы владельцы, и у вас ответственность, верно? Вот и разберитесь с этим». Неблаговидные поступки — это, наверное, не так уж и плохо, правда? К счастью, из-за угла выходит ваш руководитель, Даррел. «Бекки! Как хорошо, что я тебя встретил. Я услышал, что ты говорила насчет Кристианы, и у меня есть отличная идея. Ты права насчет владения и ответственности. Почему бы нам не забрать часть работы у Кристианы? Мы возьмем на себя общение со стейкхолдерами, а у нее освободится время для того, чтобы

288  Часть II.  Фокус на ценность

сфокусироваться на...» — Даррел уходит, увлекая за собой Бекки, и вы облегченно вздыхаете. Хорошо, что у вас есть Даррел, который может справиться с требованиями Бекки. Или вы можете просто сфальсифицировать более высокий потенциал. Умножение всех ваших оценок на три должно сделать свое дело.

Вопросы Как нам считать частично выполненные истории? Частично выполненные истории не считаются. При наличии нескольких таких историй в конце итерации создайте новую историю для оставшейся работы и заново оцените ее, если используете оценки. (Больше информации вы найдете в подразделе «Незаконченные истории» ранее в данной главе.) Та часть, которую вы сделали в этой итерации, не засчитывается в ваш потенциал; это значит, ваш потенциал снизится. Возможно, это звучит сурово, но если вы правильно используете итерации, потенциал и резерв времени, то частично выполненные истории должны случаться редко. Если они у вас есть, значит, что-то пошло не так. Снижение вашего потенциала высвободит резерв времени, необходимый вашей команде для решения проблемы. Как нам менять потенциал при добавлении или удалении людей из команды? Если вы добавляете в команду или выводите из нее только одного человека, то попробуйте оставить ваш потенциал без изменений и посмотрите, что получится. Другой вариант — изменять ваш потенциал пропорционально. В любом случае ваш потенциал примет правильное значение после следующей итерации. Как мы можем иметь стабильный потенциал? Люди уходят в отпуска, болеют и т. д. Резерв времени вашей итерации должен справиться с небольшими колебаниями доступности людей. Если отсутствует больше людей, как, например, в праздники, то ваш потенциал может снизиться на одну итерацию. Это нормально. Вы можете его восстановить в следующей итерации. Если у вас маленькая команда, то вы можете обнаружить, что даже одного дня отсутствия достаточно для дестабилизации потенциала. В этом случае вы можете попробовать использовать двухнедельные итерации. Возможные компромиссы обсуждались в пункте «Итерации» ранее в данной главе. Разве участие в совместной оценке историй не является лишней тратой времени для каждого? Людям требуется много времени на совместную оценку, но это время потрачено не зря. Сессии оценки нужны не только для оценки — вдобавок к этому они являются критически важным первым шагом в получении информации и прояснении того, что нужно сделать. Разработчики задают вопросы и проясняют детали, что часто порождает идеи, которые заказчики в команде даже не рассматривали. Иногда это сотрудничество снижает общие затраты, как описывается в подразделе «Как выиграть в игре в планирование» главы 8. Все разработчики должны присутствовать, чтобы убедиться в том, что они понимают, чем им предстоит заниматься. Их участие также улучшает стабильность оценок.

Глава 9.  Владение  289

Не рискованно ли делать оценки на основе самого квалифицированного члена команды? Может, нам лучше использовать среднего члена команды или наименее квалифицированного для большей безопасности? Петля обратной связи «Вчерашняя погода» избавляет от необходимости точной оценки, как описывается во врезке «Почему точность оценки не имеет значения» ранее в данной главе. Поэтому все варианты одинаково безопасны. Что действительно важно, так это стабильность оценок, а думать в терминах идеального времени и наиболее квалифицированного члена команды — самый легкий способ прийти к стабильности. Когда нам переоценивать наши истории? Поскольку оценки историй должны быть согласованными друг с другом, вам не нужно переоценивать истории, если только не меняется объем работы. И даже тогда не делайте переоценку истории после того, как начали над ней работать, поскольку вы будете знать уже слишком много деталей реализации, чтобы согласовать оценку с предыдущими. Вместе с тем если ваши ограничения меняются и оценки начинают делать разные люди, то и ваши оценки, и ваш потенциал должны начаться с нуля. Чтобы выполнить оценку, мы сделали несколько предположений, касающихся технического дизайна. А что, если он изменится? В Agile предполагается, что вы создаете ваш дизайн инкрементно и со временем полностью улучшаете его. В результате ваши оценки обычно будут оставаться стабильно согласованными друг с другом. Как нам работать с техническими взаимозависимостями в наших историях? При условии правильного инкрементного дизайна технические взаимозависимости См. также будут редкими, хотя и могут случаться. Как правило, я делаю отметку вместе с оценИнкрементный дизайн (глава 14) кой: «6 (4, если история Foo будет сделана первой)».

Предварительные требования Потенциал предполагает использование итераций и требует резерва времени, чтобы См. также сгладить небольшие проблемы и нестыПланирование задач (глава 9) ковки. Оценка требует доверия: разработчики Резерв времени (глава 9) должны верить, что они могут давать точные Доверие стейкхолдеров (глава 10) оценки, не опасаясь нападок, а заказчики и стейкхолдеры должны верить, что разработчики дают честные оценки. Этого доверия поначалу часто может не быть, и тогда вам нужно работать над тем, чтобы оно появилось. Независимо от вашего подхода к оценкам и потенциалу никогда не используйте значения потенциала или неверные оценки для нападок на разработчиков. Это быстрый и легкий способ разрушить доверие.

290  Часть II.  Фокус на ценность

Показатели Когда вы правильно используете потенциал: zz он последователен и предсказуем каждую итерацию; zz вы берете на себя итерационные обязательства и стабильно их выполняете; zz процесс оценки проходит быстро и легко или вообще не требуется; zz вы можете измерить большинство историй за минуту или две.

Альтернативы и эксперименты Идея в основе потенциала — это «Вчерашняя погода»: фокусироваться на стабильности и согласованности, а не точности; основывать свои прогнозы на прошлых измерениях и использовать их для создания петли обратной связи, которая будет автоматически сама себя корректировать. Количество подходов к оцениванию и прогнозиСм. также рованию бесконечно. Преимущество «Вчерашней погоды» — в простоте и надежности. Однако она не безРезерв времени (глава 9) упречна и полагается на резерв времени, чтобы компенсировать свои недостатки. Другие подходы много чего усложняют в попытке достичь большей точности. Несмотря на эту дополнительную сложность, я еще не видел, чтобы кто-то приблизился к тому, чтобы работать так, как комбинация петли обратной связи «Вчерашняя погода» и резерва времени. Вы можете поэкспериментировать в поисках лучших способов определения потенциала, но не делайте это сразу. Сначала научитесь применять подход из данной книги и надежно завершать итерации и поработайте с ним несколько месяцев. Смена подхода к планированию потенциала имеет глубокий эффект, и его трудно увидеть, не обладая достаточным опытом. Одна из известных мне наиболее популярных альтернатив — основывать потенциал на среднем значении предыдущих итераций, а не на одной прошлой. Другой подход — засчитывать истории, которые были начаты в одной итерации и закончены в другой. Я думаю, что оба подхода ошибочны: они основываются на желании повысить потенциал, но увеличивают только цифру, обозначающую потенциал, не увеличивая реальную способность команды поставлять продукт. Они лишь увеличивают вероятность того, что командам будет сложно выполнять свои обязательства. Лучше сделать над собой усилие, запланировать более низкий потенциал и использовать имеющийся резерв времени, чтобы повысить фактическую, реальную возможность команды поставлять продукт. Другой популярный вариант — движение без оценок (#NoEstimates), которое полностью отходит от них. Существуют два подхода без оценок, и я включил их в эту книгу. Первый — считать истории, вместо того чтобы оценивать их, как описывается в данной практике. Некоторые команды используют очень маленькие истории (больше дюжины на итерацию), чтобы это работало. Второй подход — вообще не использовать итерации, а вместо этого применять непрерывный поток, как описывается в разделе «Планирование задач» ранее в данной главе. Обе идеи стоит попробовать после того, как вы овладеете основами.

Глава 9.  Владение  291

РЕЗЕРВ ВРЕМЕНИ Мы выполняем наши обязательства по итерации.

Аудитория

Представьте, что кабель электропитания вашей Разработчики рабочей станции имеет строго определенную длину и едва дотягивается до розетки. Вы можете вставить вилку в розетку, туго натянув кабель, но малейшая вибрация приведет к тому, что он вывалится из розетки и электропитание компьютера отключится. Вы лишитесь всего, над чем работали. Я не могу позволить, чтобы электропитание моего компьютера пропадало по малейшему поводу. Моя работа слишком важна. В этой ситуации я бы передвинул компьютер поближе к розетке, чтобы кабель мог выдержать некоторые небольшие воздействия. (Потом я бы прикрепил кабель к полу, чтобы об него никто не мог споткнуться, поставил бы источник бесперебойного питания (uninterruptable power supply, UPS) и вложился бы в решение, позволяющее выполнять непрерывное резервное копирование (continuous backup solution).) Ваши планы на итерацию тоже слишком важны, чтобы быть разрушенными малейшим воздействием. Как и кабелю электропитания, им нужен резерв времени.

Сколько резерва нужно Количество резерва, которое вам нужно, не зависит См. также от количества проблем, с которыми вы сталкиваетесь. Оно зависит от степени хаотичности этих проблем. Потенциал (глава 9) Если вы всегда испытываете проблем точно на 20 часов в каждой итерации, то ваш потенциал автоматически их компенсирует. Однако если у вас будет между 20 и 30 часами проблем, то ваш потенциал будет колебаться то вверх, то вниз. Вам нужно 10 часов резерва, чтобы стабилизировать потенциал и выполнить свои обязательства. ПРИМЕЧАНИЕ Помните, что команда сама решает, какие обязательства принимать на себя и делиться ли своими планами по этим обязательствам за пределами команды. Более подробная информация представлена в подразделе «Принятие и выполнение обязательств по итерации» ранее в данной главе.

Эти цифры приведены только для иллюстрации. Вместо того чтобы измерять количество часов, которое вы тратите на решение проблем, воспользуйтесь петлей обратной связи потенциала, описанной в подразделе «Стабилизация потенциала» ранее в данной главе. Если ваш потенциал колеблется в большом диапазоне, то перестаньте подписываться на большее количество историй, чем позволяет ваш потенциал. Это приведет к тому, что он установится на более низком уровне, который будет содержать резерв времени вашей команды. С другой стороны, если вы все завершаете рано, включая время на очистку во всех частях кода, в которых что-то делали, то уменьшите ваш резерв, взявшись за маленькую дополнительную историю в следующей итерации.

292  Часть II.  Фокус на ценность

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

Повышать внутреннее качество Производительность команды напрямую связана с качеством ее кода, тестами, автоматизацией и инфраструктурой. Все вместе это составляет внутреннее качество ПО. Даже лучшие команды невольно накапливают проблемы внутреннего качества. Хотя вы должны всегда делать ваше ПО настолько чистым, насколько возможно, даже хорошая работа в конце концов перестает соответствовать вашим потреб­ ностям. Если ваше ограничение связано с програмСм. также мированием, то повышение внутреннего качества — верный путь к повышению потенциала. Рефлексивный дизайн (глава 14) Каждую итерацию, вместо того чтобы делать минимум, необходимый для создания чистого кода, ищите возможности также улучшить существующий код. Делайте это частью вашей повседневной работы. Если вы обнаруживаете, что ломаете голову над именем переменной или метода, то измените его. Если вы видите код, который больше не используется, то удалите его. Вдобавок к этим небольшим улучшениям ищите возможности для более масштабных усовершенствований. Возможно, у модуля слишком много задач, тест случайным образом не проходит или сборка идет медленно. Когда эти проблемы влияют на вашу работу, вносите усовершенствования инкрементно. Не смешивайте все улучшения в одно. Вносите усовершенствования ежедневно, по ходу всей итерации: час инкапсулирования структуры здесь, два часа корректи­

Глава 9.  Владение  293

ровки скрипта развертывания там. Каждое улучшение должно решать одну относительно маленькую Вносите усовершенствования проблему. Иногда вы сможете решить только часть ежедневно, по ходу более крупной проблемы — это нормально, если код итерации. улучшается. Вы сможете улучшить эту часть системы позже, когда будете работать над ней в следу­ ющий раз. Прежде чем начать, взгляните на доску задач См. также и сравните ее с количеством времени, оставшимся в итерации. Много ли задач выполнено, по сравнению Планирование задач с количеством прошедшего времени? Если да, то ко(глава 9) манда опережает график, так что вы можете заняться очисткой. Или наоборот, похоже, что команда отстает? Тогда сфокусируйтесь на ваших обязательствах по текущей итерации. У вас будут еще возможности в следующей итерации. Меняя количество времени, потраченное вами на внутреннее качество, вы можете удостовериться, что итерации проходят именно так, как планировалось. ПРИМЕЧАНИЕ Всегда оставляйте ваш код и ваши системы в несколько улучшенном состоянии, чем когда вы нашли их, неважно, сколько времени у вас есть. Вы не выбираете между «неряшливый» и «чистый»; вы выбираете между «немного чище» и «значительно чище». Всегда находите время для того, чтобы делать работу хорошо. Беспорядок отберет у вас больше времени, чем сбережет.

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

Развивать навыки в сфере деятельности заказчика Хотя команды в Agile должны быть кросс-функ­ См. также циональными, многие организации экономят на специалистах, разбирающихся в сфере деятельности Вся команда (глава 7) заказчика. Если ограничения вашей команды связаны с нехваткой знаний о заказчике, пользователях и потребностях бизнеса, то вам нужен резерв времени, чтобы узнать об этом больше. Изучайте предметную область. Приходите на совещания вместе с вашим продактменеджером. Интервьюируйте пользователей и говорите со стейкхолдерами. Как и в случае с повышением внутреннего качества, распределяйте это время равномерно по итерации и смотрите на прогресс команды, чтобы понять, сколько времени вы можете на это потратить.

294  Часть II.  Фокус на ценность

Посвящать время исследованиям и экспериментам Разработчики обычно склонны быть любознательными и должны непрерывно совершенствовать свои навыки. Удовлетворяя свое любопытство, они часто получают знания, которые улучшают их работу в команде. Время, посвященное исследованиям и экспериментам, также называется временем исследования (research time). Это отличный способ поощрить обучение, одновременно добавляя резерв времени в вашу итерацию. В отличие от других техник, этот блок активностей займет полдня в конце итерации. Если вы запаздываете с выполнением задач, то можете использовать небольшую часть времени исследования, чтобы выполнить свои обязательства. Если вы используете время исследоваВремя исследования дает вам ния, то посчитайте ваш потенциал, оснобуфер, но не нужно слишком вываясь на историях, которые закончены, на него полагаться. когда запланировано начало времени исследования, а не когда итерация должна заканчиваться по плану. Таким образом, если вы вклинитесь в ваше время исследования, то ваш потенциал автоматически снизится, так что вам не понадобится делать это в следующей итерации. Время исследования дает вам буфер, но не нужно слишком на него полагаться. Каждый член команды использует блок времени исследования для того, чтобы провести самостоятельное исследование темы по своему выбору. Это может быть исследование новой технологии, изучение неясной секции кода, тестирование новой практики, проверка идеи нового продукта или что-то еще интересное сотруднику. Есть только одно правило на это время: не работать ни над одной историей и не подтверждать код в эксплуатационной среде. ПРИМЕЧАНИЕ Если вы обеспокоены тем, чтобы люди не лентяйничали в это время, то пригласите всех на обед на следующий день и в ходе неформального общения попросите поделиться тем, что они узнали. В любом случае это может быть прекрасным вариантом для «перекрестного опыления» идей.

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

Глава 9.  Владение  295

Когда вы только внедряете практику времени исследования, вам может быть сложно решить, над чем работать. Подумайте, что вас озадачило недавно. Хотели бы вы узнать больше о вашем UI-фреймворке или коде? Есть ли какой-то язык программирования, который вы хотели попробовать, но в вашей организации он не используется? Возможно, вас всегда интересовали сети реального времени (real-time networking)? В ходе вашего исследования создавайте спайк-решения (маленькие отдельСм. также ные программы), демонстрирующие, что вы узнали. Если вы экспериментируете Спайк-решения (глава 13) с кодом эксплуатационной среды, то создайте временную ветку. Не пытайтесь сделать что-то полезное в широком смысле; это только уменьшит количество времени, отведенного на реализацию конкретных идей. Сделайте только то, чего будет достаточно для проверки концепции, затем переходите к следующей задаче.

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

Вопросы Если наши обязательства находятся под угрозой срыва, то должны ли мы временно отменить парное программирование, рефакторинг, разработку через тестирование и т. д.? Ведь исполнение обязательства — это самое важное? С опытом эти практики должны начать ускорять вашу работу, а не замедлять, но у них есть кривая обучения (или научения). Действительно, если вы их отложите, то на раннем этапе сможете быстрее выполнить свои обязательства. Но все же вы не должны использовать их в качестве источника резерва времени. Эти практики поддерживают вашу способность поставлять высококачественный код. Если вы не будете им следовать, то из-за снижения внутреннего качества ваша работа сразу замедлится. Вы сможете выполнить конкретные обязательства текущей итераСм. также ции, но сделаете это за счет следующей. Если вам не хватает резерва времени, Парное программирование (глава 12) чтобы справиться с обязательством, то Групповое программирование (глава 12) не понижайте свои стандарты. Лучше

296  Часть II.  Фокус на ценность измените свои планы, как обсуждается в подразделе «Принятие и выполнение обязательств по итерации» ранее в данной главе. Должны ли мы использовать парное или групповое программирование в течение времени исследования? Групповое программирование — это, как правило, лишнее. Парное программирование может пригодиться, если вы планируете взаимодействовать с коллегами по какому-либо вопросу, но необходимости в нем нет. Как резерв времени связан с историями для очистки? Истории для очистки — это специальные истории, предназначенные только для повышения внутреннего качества (см. пункт «Истории для очистки (clean-up stories)» главы 8). Честно говоря, они скорее являются ошибкой. Команда должна использовать свой резерв времени для того, чтобы постоянно улучшать свой код и другие системы. В историях для очистки вообще не должно быть необходимости. Но иногда вы наследуете ПО, которое можно значительно ускорить с помощью дополнительной чистки. В этих случаях заказчики в команде могут решить, что в список приоритетов нужно включить историю для очистки. Но это никогда не должно быть обязательным. Решение всегда принимают заказчики в команде, которым нужно соблюдать компромисс между пользой от дополнительной очистки ПО и пользой от другой работы, на которую команда могла бы потратить это время. В этом отличие от процедуры очистки, выполняемой с помощью командного резерва времени, которая остается на усмотрение разработчиков.

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

Показатели Когда ваша команда встраивает резерв времени в состав итераций: zz

команда стабильно исполняет свои обязательства по итерациям;

zz

члены команды редко (а скорее никогда) нуждаются в переработках;

zz

внутреннее качество стабильно улучшается, упрощая и ускоряя работу.

Глава 9.  Владение  297

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

Литература для дополнительного чтения В книге Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency [DeMarco2002] приводятся убедительные аргументы в пользу применения резерва времени во всей организации. The Goal1 [Goldratt1992] и Critical Chain2 [Goldratt1997] — два бизнес-романа, в которых обосновывается, почему для защиты обязательств и повышения пропускной способности команды нужно использовать резерв времени (или «буферы»), а не дополнять предварительные оценки.

СТЕНДАП-МИТИНГИ Мы координируемся для выполнения своей ­работы.

Аудитория

Вся команда Я испытываю особую неприязнь к статусмитингам. Вы наверняка знаете этот вид встреч: руководитель зачитывает список задач и спрашивает о каждой всех по очереди. Кажется, что встречи длятся вечно, хотя моя часть обычно занимает всего пять минут. Я узнаю что-то новое примерно за 10 минут. Остальные 45 минут — совершенно бесполезная трата времени. Голдратт Э. Цель. Процесс непрерывного улучшения.

1

Голдратт Э. Критическая цепь.

2

298  Часть II.  Фокус на ценность У организаций есть веские причины проводить такие встречи. Люди должны знать, что происходит. Но у Agile-команд есть более эффективные механизмы: информативное рабочее пространство позволяет узнавать статус, а ежедневные стендапмитинги служат для координации работ.

См. также Информативное рабочее пространство (глава 9)

К А Р ГО - К УЛ ЬТ

Сидячий стендап Сейчас 10:03 утра, и ваша команда опять собралась возле комнаты для стендап-митингов, ожидая, пока из нее выйдет предыдущая группа. «Напомни мне, почему нам опять нужна эта комната?» — спрашивает Стив. «Все остальные были заняты, — отвечает Висенте. Он ваш Scrum-мастер. — И нам нужен проектор. Смотри, они встают». Пять минут спустя вы все уже удобно устроились, и Висенте с помощью проектора направляет изображение из трекера задач на стену. «Окей, давайте начнем наш стендап, — говорит Висенте, откидываясь в кресле. — Джастин?» Джастин отрывает взгляд от своего телефона. «А, да. Ну-у… вчера я работала над историей № 1106. Сегодня я все еще работаю над ней. Препятствий нет». «Отлично, — отвечает Висенте. — Адриана?» «Все еще работаю над № 1109. Препятствий нет». Висенте продолжает опрашивать всех по кругу, внося обновления в трекер, пока люди отвечают в том же духе. «Окей, это все. Всем спасибо. Помните, что нужно обновить статус ваших историй, чтобы нам не пришлось этого делать на встрече. Увидимся завтра». Сейчас 10:20. Направляясь обратно к своему рабочему месту, вы размышляете о стендапе. Во всяком случае, это быстро. Но так… бесполезно. За исключением обновления в трекере, которое делает Висенте, все остальное выглядит пустой тратой времени. Чего не хватает?

Как проводить ежедневные стендапы Провести ежедневный стендап-митинг очень См. также просто. Каждый день в определенное время вся команда собирается на короткую, 5–10-минутную, Планирование задач (глава 9) встречу. Команды, работающие в офисе, собираются вокруг своей доски для трекинга задач. Виртуальные команды общаются по видеосвязи и также подключаются к виртуальной доске задач. Заведите привычку всегда начинать вовремя, даже если кто-то опаздывает.

Глава 9.  Владение  299

Стендапы предназначены для координации, Стендапы предназначены а не для обновления статуса. Если вам нужен для координации, текущий статус, просто посмотрите на доску а не для обновления статуса. для планирования задач. Но так как команда совместно владеет историями, несет за них ответственность и работает над их выполнением (см. врезку «Коллективное владение» ранее в данной главе), членам команды нужен способ координировать свою работу. Именно для этого и нужны стендап-митинги. Они позволяют членам команды синхронизироваться, чтобы те могли продолжать координировать свои действия по необходимости в течение дня. ПРИМЕЧАНИЕ Стендапы прерывают работу команды. В этом отношении особенно проблематичны утренние стендапы; так как члены команды знают, что встреча прервет их работу, они иногда просто теряют время, ожидая ее начала. Вы можете сгладить проблему, перенеся стендап на более позднее время дня, например перед обедом.

Наиболее эффективный подход для стендапов из тех, что я видел, называется «Прогулка по доске». Он состоит из четырех частей.

1. «Прогулка по доске» Стендап начинается с того, что члены команды просматривают одну за другой истории на доске, начиная с той, которая ближе всех к завершению. Люди, которые работали над каждой из историй, описывают, что изменилось и что осталось сделать, а также рассказывают любую другую новую информацию, которую команде нужно знать. Например: «Мы с Дженной закончили эту задачу, — говорит Бобби, указывая на доску. — Мы с На закончили вот ту задачу, так что эта история готова к финальной экспертной проверке. Я поговорил с Родни, и он сказал, что хочет быть ее проверяющим, но у него возникло какое-то срочное дело. Он должен вернуться в офис сегодня во второй половине дня. Мы планируем сегодня отметить эту историю зеленым, если не будет никаких сюрпризов». Члены команды должны просить помощи и проводить спонтанные сессии совместной работы по мере необходимости в течение дня, однако прогулка по доске — подходящий момент для менее срочной координации. Ниже представлены несколько примеров. zz Кто-то, кто хочет помощи: «Меня смущает тестирование нашего фронт­енда CSS. Кто-нибудь может рассказать мне об этом после стендапа?» zz Кто-то, обладающий новой информацией: «Я и Люсила попробовали новую библиотеку TaskManager, и она работала очень хорошо. Посмотрите, когда в следующий раз будете работать с параллелизмом». zz Кто-то, кому требуется сессия совместной работы: «У нас есть несколько историй, которым нужно задать размер. Мы можем запланировать быструю сессию игры в планирование после обеда?»

300  Часть II.  Фокус на ценность Вначале, пока люди еще только привыкают к стендапам, вам может понадобиться кто-то для фасилитации встречи. Лучше передавать эту роль, чтобы команда могла разделять лидерство. Фасилитатор должен следить за тем, чтобы не доминировать на встрече; его роль только в том, чтобы указывать на каждую историю и побуждать команду высказываться.

2. Фокус на завершении После прогулки по доске сфокусируйте внимание команды на том, что им необходимо для завершения работы, включая препятствия, которые не устранены. Команды, использующие итерации, должны воспользоваться возможностью проверить свои обязательства по итерациям, сказав примерно такие слова: «У нас осталось два дня, и мы прошли итерацию на 60 %. Похоже, мы выполнили больше 60 % задач, но только одна из наших историй отмечена как сделанная, поэтому сегодня мы должны сконцентрироваться на закрытии историй».

3. Выбирайте задачи Наконец, каждый решает, над чем будет работать дальше. Это разговор, а не одностороннее решение: «С учетом того, что сказала На о завершении историй, похоже, что эта задача должна иметь высокий приоритет в нашем списке. Кто-нибудь хочет поработать над этим со мной?» (На выступает добровольцем и берет карточку с доски.) «Кроме того, сегодня во второй половине дня я договорюсь с Родни насчет экспертной проверки той, другой истории». Таким же образом, если кто-то выбирает историю, по которой у вас есть информация, не забудьте упомянуть ее: «Когда начнете работать над этой задачей, поговорите со мной или Сеймуром. Мы внесли несколько изменений в нашу обертку над Fetch1, о которых вам нужно знать».

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

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

1

Глава 9.  Владение  301

1. Что я делал вчера? 2. Что я буду делать сегодня? 3. Что мне мешает? Такие встречи обычно превращаются в статус-митинги, а не в координационные, поэтому я предпочитаю «прогулку по доске». Кроме того, они, как правило, занимают больше времени или превращаются в бессодержательную перекличку.

Будьте краткими Цель стендап-митингов — вкратце скоординировать всю команду. Они не предназначены для полного описания всего, что произошло. Главное достоинство стендапов — краткость. Вот почему команды, работающие в офисе, проводят встречи стоя: их уставшие ноги напомнят им, что встреча должна быть короткой. Каждую историю обычно можно описать, используя всего несколько предложений. От 30 до 60 секунд вполне должно хватить. Вот несколько дополнительных примеров. zz

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

zz

Продакт-менеджер: «Я только что вернулся с торговой выставки, где получил отличные отзывы о UI и направлении развития нашего продукта. Это будет означать некоторые изменения в визуальном плане. Я поработаю над этим сегодня, и любой, кто хочет знать больше, может присоединиться ко мне».

zz

Эксперт в предметной области: «Синтия спрашивала меня вчера о финансовых правилах для этой истории. После этого я обсудил это с Татум, и оказалось, что там несколько больше работы, чем я думал. Я добавил эту задачу (показывает), чтобы обновить примеры, и хотел бы поработать с программистом или тестировщиком над этим, чтобы убедиться, что мы покрываем все базы».

Обычно стендап-митинги должны занимать всего около пяти минут, максимум десять. Если они постоянно занимают больше десяти минут, что-то не так. Несколько общих причин медленных стендапов таковы:

Стендап-митинги должны занимать всего около пяти минут, максимум десять.

zz

вместо карточек и доски или их виртуального эквивалента используются инструменты трекинга задач;

zz

доска задач обновляется во время стендапа, а не в течение всего дня;

zz

разговоры ведутся во время стендапа, а не в течение всего дня;

zz

подробные дискуссии ведутся во время стендапа, вместо того чтобы выносить их за рамки встречи;

302  Часть II.  Фокус на ценность стендап проводится в комнате для совещаний, а не в рабочей комнате вашей команды; zz участники встречи ждут, когда все соберутся, вместо того чтобы начинать всегда вовремя. Если ничто из перечисленного не похоже на ваш случай, то обратитесь за помощью к наставнику. zz

Вопросы Могут ли люди, не являющиеся членами команды, участвовать в стендапах? Да, но помните, что стендап организует команда и он проводится на благо команды. Если посторонние люди отвлекают от встречи или членам команды некомфортно говорить в их присутствии, то посторонние должны перестать участвовать. Члены команСм. также ды, имеющие навыки дипломатии, вероятно, смогут им сообщить об этом наилучшим обраДемо для стейкхолдеров (глава 10) зом. Вы можете использовать демо для стейкДорожные карты (глава 10) холдеров и дорожные карты, чтобы держать этих людей в курсе происходящего. Когда есть множество команд, иногда бывает полезно командам, плотно работающим друг с другом, отправлять своих людей на стендап-митинги друг к другу. В этом случае решите совместно, как позволить людям посещать встречи и сотрудничать, никому не мешая. Что, если кто-то опоздал на встречу? Начинайте без них. Стендапы длятся всего несколько минут, так что к моменту, когда опоздавшие придут, вы уже можете закончить. Вы можете попросить кого-либо заменить их, если необходимо. Если начинать всегда вовремя, это может способствовать установлению культуры пунктуальности. Нам все еще нужны стендап-митинги, если мы используем групповое программирование? Команды, которые используют групповое программирование, обычно постоянно коорСм. также динируются, так что технически стендапы им Групповое программирование не нужны. Но все же полезно каждый день (глава 12) находить время, чтобы обсудить прогресс и подумать о следующих шагах. У команд, использующих групповое программирование, это может происходить естественным образом. Если нет, то проведение запланированного стендапа должно помочь.

Предварительные требования Не позволяйте ежедневным стендапам задушить общение. Некоторые члены команды в какой-то момент обнаруживают, что ждут стендапа, вместо того чтобы разговаривать с кем-то, кто им нужен. Если вы видите, что такое происходит, временная отмена стендапов может на самом деле помочь улучшить общение. Знайте, что есть лидеры, которые любят доминировать во время стендапов. Будучи проверяющим, Джонатан Кларк метко выразился, что идеальный

Глава 9.  Владение  303

фасилитатор — это «харизматичный, но нетерпеливый коллега, который торопит и прерывает говорящих». Команда (и стендап ) — это собрание равных. Никто не должен доминировать.

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

Альтернативы и эксперименты Координация, а не статус — основная идея стендап-митингов. Команды — новички в Agile обычно испытывают с этим трудности; стендап кажется им более короткой и частой версией статус-митинга, но такие представления упускают суть. Во время стендапа избегайте излишней формальности. Люди часто экспериментируют, добавляя структуру (шаблоны, списки вопросов), но она может снижать уровень взаимодействия, а не повышать его. Вместо этого ищите варианты повысить способность команды нести коллективную ответственность за свою работу. Одна команда, с которой я работал, стала настолько эффективной в технике «прогулки по доске», что члены команды стали проводить очень короткие стендапы несколько раз в день. Вместо того чтобы назначать время для встреч, участники собирались сразу же, как только заканчивали свои задачи. Уже через 30–60 секунд они договаривались о том, над чем работать дальше, и разбирали задачи с доски.

Литература для дополнительного чтения It’s Not Just Standing Up: Patterns for Daily Standup Meetings [Yip2016] — хороший источник идей для экспериментов со стендап-митингами.

ИНФОРМАТИВНОЕ РАБОЧЕЕ ПРОСТРАНСТВО Мы настроены на прогресс. Аудитория

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

304  Часть II.  Фокус на ценность по помещению и рассматривают окружающую их информацию. Такой короткий выход из привычной зоны может приводить к внезапным открытиям. Виртуальным командам труднее добиться такого же эффекта «постоянно на виду», но тут работают те же принципы. Создавайте людям возможности получать информацию, не прибегая к сознательным ее поискам. Информативное рабочее пространство также позволяет ощутить прогресс команды, просто войдя в комнату — или авторизовавшись в общей сети в случае виртуального командного помещения. Оно передает информацию о состоянии дел, не отвлекая членов команды, и помогает повышать доверие стейкхолдеров.

Тонкие сигналы Суть информативного рабочего пространства  — информация. Пространство постоянно транслирует Информативное рабочее информацию команде. Этот процесс принимает пространство постоянно форму больших наглядных диаграмм, описанных транслирует информацию команде. далее, но может принимать форму тонких сигналов, что позволяет членам команды поддерживать их осведомленность о ситуации. Один из источников осведомленности о ситуации — видеть, что делают люди. В физическом командном помещении, меняя визуальный план, человек, вероятно, думает о предстоящей работе. Если кто-то стоит возле доски задач, то, возможно, может обсудить вопрос, над чем работать дальше. В середине итерации, если половина карточек на доске не сделана, команда движется медленнее, чем ожи­ далось. Ощущение комнаты — еще один сигнал. Здоровая См. также команда энергична. В воздухе висит гул активности. Люди общаются, работают вместе, шутят время Энергичная работа (глава 7) от времени. Команда не спешит и не суетится, но определенно продуктивна. Когда человеку или паре нужна помощь, другие это замечают, предлагают помощь, потом возвращаются к своим задачам. Когда кто-то завершает задачу, все на минутку прерываются, чтобы коротко отпраздновать это. В нездоровой команде тихая и напряженная атмосфера. Члены команды не говорят много или вовсе молчат. Есть ощущение чего-то серого и мрачного. Люди живут по часам, отсчитывая время прихода и ухода или, еще хуже, наблюдая, кто первый решится уйти. В удаленных командах эти сигналы не видны. Вместо этого приложите усилия, чтобы сообщать См. также о текущем статусе и настроении. Установите рабочие Согласование (глава 7) соглашения о том, как делиться информацией, например, оставлять примечания в групповом чате, и предложите способы приветствовать друг друга. Помимо собственно информации, рабочее пространство предоставляет людям и способы общения. Для команд, работающих в офисе, это означает множество

Глава 9.  Владение  305

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

Большие наглядные диаграммы Существенный аспект информативного рабочего пространства — большая наглядная диаграмма, или «излучатель информации». Цель такой диаграммы — отобразить информацию настолько просто и недвусмысленно, чтобы она проецировалась на все пространство.Удаленно работающие команды могут достичь похожего эффекта, используя одну виртуальную доску, представляющую их «комнату». Доска планирования задач (как на рис. 9.1) и доска для планирования задач (как на рис. 8.4) — примеры повсеместно используемых больших наглядных диаграмм. Вы встретите варианты таких досок у каждой Agile-команды, хотя многие совершают ошибку, пряча их в трекер проблем. Еще одна полезная диаграмма — командный календарь, который показывает важные даты, итерации и дни, когда члены команды будут отсутствовать в офисе (а также контактную информацию, если это необходимо). Для команд, работающих в офисе, подойдет большой пластиковый вечный календарь. Мне нравится также держать на видном месте цель команды — ви́дение, миссию и тесты миссии. Эта информация имеет тенденцию отходить на второй план через несколько недель, но все же хорошо иметь возможность указать на нее при необходимости. Избегайте рефлекторного побуждения Не позволяйте электронным компьютеризировать ваше информативное инструментам ограничивать то, что рабочее пространство. Ваша команда должвы можете сделать. на быть в состоянии менять свой процесс в любой момент, как только у кого-либо возникает хорошая идея. Благодаря бумаге для флипчарта, ленте и маркерам время, прошедшее от идеи до готовой диаграммы на стене, составит всего две или три минуты. В физическом командном помещении нет ничего более гибкого или удобного. Электронные инструменты работают дольше и ограничены запрограммированными функциями. Не позволяйте им ограничивать то, что вы можете сделать. Командам, работающим удаленно, конечно, приходится использовать электронные инструменты, но участники также должны отдавать предпочтение инструментам, которые упрощают быстрые изменения и обновления, а не пытаются автоматизировать. Обычных карточек, стикеров и инструментов для рисования, имеющихся в вашей виртуальной доске, должно быть достаточно.

306  Часть II.  Фокус на ценность

Диаграммы улучшений Один из типов большой наглядной диаСм. также граммы измеряет определенные параметры, которые команда хочет улучшить. Часто эти Ретроспективы (глава 11) параметры возникают во время ретроспектив. В отличие от доски для планирования или командного календаря, которые постоянно присутствуют в комнате, диаграммы улучшений остаются там только на несколько недель. Создавайте диаграммы улучшений как результат общего решения команды, и пусть она за них отвечает. Когда вы согласитесь создать диаграмму, договоритесь поддерживать ее в актуальном состоянии. Для некоторых диаграмм это означает, что все уделяют несколько секунд на то, чтобы сделать отметку на доске, когда меняется статус. Другие диаграммы подразумевают сбор некоторой информации в конце дня. Для таких коллективно выберите кого-нибудь, кто будет отвечать за обновление диаграммы. Диаграммы улучшений настолько же разнообразны, как и проблемы, которые испытывают команды. Принцип, стоящий за всеми ними, один и тот же: они взывают к нашему врожденному желанию совершенствоваться. Если вы демонстрируете прогресс в достижении общей цели, то люди обычно будут стараться улучшать свой статус. Подумайте над проблемами, с которыми сталкиваетесь, и над тем, какой тип диаграммы, если он есть, может помочь. В качестве примера команды Agile успешно использовали диаграммы, чтобы улучшить: zz

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

zz

переключение пар, отслеживая, сколько возможных комбинаций пар фактически работало парами во время каждой итерации (рис. 9.4, а);

zz

производительность сборки, отслеживая количество тестов, выполненных за секунду (см. рис. 9.4, б);

zz

отзывчивость поддержки, отслеживая возраст самого старого запроса (более ранняя диаграмма, которая отслеживала количество нерешенных запросов, привела к тому, что сложные запросы игнорировались);

zz

ненужные перерывы, отслеживая количество часов, потраченное на работу не по истории в каждой итерации.

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

Глава 9.  Владение  307

Рис. 9.4. Примеры диаграмм улучшений

Игры Хотя слишком большое количество диаграмм улучшений может снизить их влияние, более серьезная проблема возникает, когда команда чрезмерно заинтересована в увеличении цифр в диаграмме. Люди часто начинают воспринимать процесс как азартную игру. Игра начинается, когда люди фокусируются на цифрах за счет общего процесса. Обычный пример, который я встречаю, — программисты слишком фокусируются на улучшении количества имеющихся у них тестов или объема покрытия кода вместо совершенствования качества своего подхода к тестированию. Они выполняют тривиальные тесты, которые не несут никакой ценности, или сложны для выполнения, или выполняются медленно. Иногда люди даже не осознают, что делают это. Чтобы уменьшить эту проблему, используйте диаграммы улучшений осторожно. Обсуждайте новые диаграммы всей командой. Ясно обозначайте общие улучшения, которые хотите увидеть. Каждую неделю проверяйте, работают ли диаграммы, и снимайте их в течение месяца. К этому времени диаграмма уже или выполнит свою задачу, или окажется не в состоянии чем-то помочь. Кроме того, никогда не  используйте Никогда не используйте диаграммы диаграммы из вашего рабочего пространиз вашего рабочего пространства ства для оценки производительности. Даже для оценки производительности. не обсуждайте их за пределами команды. Люди, которые чувствуют, что о них судят по их производительности на диаграмме, с гораздо большей вероятностью вступят в игру. В разделе «Менеджмент» главы 10 можно найти информацию о том, что делать вместо этого.

308  Часть II.  Фокус на ценность

Вопросы Нам необходимо информировать о статусе людей, которые не могут или не хотят приходить в наше рабочее пространство регулярно. Как нам это делать, не применяя компьютеризированные диаграммы? Первое и главное — информативное рабочее См. также пространство предназначено для команды. Чтобы делиться информацией о статусе с людьми, Демо для стейкхолдеров не входящими в команду, используйте демо для (глава 10) стейкхолдеров и дорожные карты. Дорожные карты (глава 10) Наши диаграммы постоянно устаревают. Как вдохновить членов команды на их обновление? Первый вопрос, который нужно задать: «Действительно ли команда согласилась с этой диаграммой?» Информативное рабочее пространство должно приносить пользу команде, так что если члены команды не поддерживают диаграмму в актуальном состоянии, то, возможно, считают, что она не имеет смысла. Может быть, члены команды в пассивно-агрессивной форме игнорируют диаграмму, вместо того чтобы просто сказать вам, что она им не нужна. Могу сказать из собственного опыта: возможно, вы слишком сильно настаиваете на диаграммах. Снижения моей вовлеченности в диаграммы часто бывает достаточно, чтобы заинтересовать и привлечь команду. Иногда это означает, что нужно смириться с неидеальными или небрежными картинками от руки, но это себя оправдывает. Если ничего не помогает, то обсудите проблему во время ретроспективы или стендапмитинга. Поделитесь своим разочарованием и попросите у команды помощи в решении проблемы. Будьте готовы отказаться от части диаграмм, если команде они не нужны.

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

Показатели Когда у вашей команды есть информативное рабочее пространство: zz вы своевременно узнаёте обо всех проблемах, с которыми сталкивается команда; zz вы точно знаете, каков ваш прогресс по вашему текущему плану и сколько еще предстоит сделать; zz вы хорошо знаете, хорошо продвигается команда или столкнулась с трудностями; zz вы знаете, насколько хорошо команда решает проблемы.

Глава 9.  Владение  309

Альтернативы и эксперименты Если у вас нет командного помещения, но ваша команда работает в смежных офисах или кабинках с перегородками, то вы можете получить некоторые преимущества информативного рабочего пространства, размещая информацию в холле или общих помещениях. В этом эксперименте вас ничто не ограничивает. Ключ к данной практике — метафора кабины пилотов: иметь постоянно на виду всю необходимую информацию, чтобы автоматически замечать изменения и подсознательно понимать, когда что-то не по плану. Имейте это в виду, когда будете экспериментировать с визуализациями и плакатами. Вы можете начать экспериментировать сразу.

Литература для дополнительного чтения Agile Software Development [Cockburn2006] содержит интересную дискуссию в главе 3 Communicating, Cooperating Teams, в которой информация описывается как жар, а отвлекающие факторы — как сквозняки. Это источник метафоры «излучатель информации».

ПРИМЕРЫ ЗАКАЗЧИКА Мы правильно реализуем сложные детали. Некоторые программы довольно простые: Аудитория просто еще один UI поверх еще одной базы Заказчики, вся команда данных. Но часто наибольшую ценность представляет ПО, требующее особых экспертных знаний. Эта экспертность, или знание предметной См. также области, наполнена деталями, в которых трудно разобраться и которые легко понять неправильЕдиный язык (глава 12) но. Для обсуждения этих деталей используют примеры заказчика: конкретные примеры, иллюВся команда (глава 7) стрирующие правила предметной области. ПриВовлечение реального заказчимеры заказчика тесно связаны с единым языком, ка (глава 8) который представляет собой способ объединить язык, используемый программистами и экспертами в предметной области, и сам код. Для создания примеров заказчика вам понадобятся люди, обладающие экспертными знаниями в предметной области. Идеально, если они — часть команды. Если нет, то вам нужно их найти. В вашу команду могут входить люди, которые выработали «мирское» понимание предметной области. В эту категорию часто входят программисты, тестировщики и бизнес-аналитики. Они могут сами разрабатывать примеры заказчика. Но даже

310  Часть II.  Фокус на ценность в таком случае хорошей идеей будет проверить эти примеры вместе с реальными экспертами в данной области, поскольку могут встретиться каверзные детали, которые неспециалист поймет неверно. Чтобы создать и использовать такие примеры, следуйте процессу Описать, Продемонстрировать, Разработать.

Описать В процессе планирования задач посмотрите См. также на истории и решите, нет ли в них деталей, которые разработчики могли понять неПланирование задач (глава 9) правильно. Добавьте задачи по созданию примеров таких деталей. Вам не нужны примеры на все — только на каверзные. Примеры заказчика нужны для общения, а не для подтверждения того, что ПО работает. Например, если одна из ваших историй — «разрешить удаление счета», то вам не нужен пример удаления счета. Разработчики уже понимают, что значит удалить что-либо. Однако вам могут понадобиться примеры, показывающие, когда можно удалить счет, особенно если есть сложные правила, обеспечивающие удаление счета правильным образом. Если вы не знаете, что именно разработчики могли понять неправильно, спросите их! Но не совершайте ошибки, приводя слишком много примеров, по крайней мере поначалу. Когда эксперты в предметной области и разработчики впервые собираются вместе, чтобы создать примеры, обе группы часто бывают удивлены тем, насколько велико неверное понимание. Когда приходит время работать над примерами, соберите команду вокруг белой доски или сделайте общий документ, если команда работает удаленно. Участвовать может вся команда. Как минимум пригласите эксперта в предметной области, всех программистов и тестировщиков. Они все должны понимать детали, чтобы коллективно владеть продуктом (см. врезку «Коллективное владение» ранее в данной главе). Эксперты в предметной области начинают с краткого описания истории и соответствующих правил. Будьте лаконичны: это только краткий обзор. Сберегите детали для примеров. Например, дискуссия об удалении счетов может пойти следующим образом: Эксперт: Одна из наших историй — добавление поддержки удаления счетов. Вдобавок к макетам UI, которые мы вам дали, мы думаем, что будет хорошо добавить несколько примеров заказчика. Удаление счетов — не настолько простая операция, как кажется, поскольку мы должны вести аудиторский учет. Этот вопрос связан с определенным набором правил. Обычно можно без проблем удалять счета, которые не были отправлены заказчикам, чтобы люди имели возможность исправлять ошибки. Но как только счет был отправлен заказчику, он может быть удален только менеджером. И даже тогда мы должны сохранять копию для аудита.

Глава 9.  Владение  311

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

См. также Единый язык (глава 12)

Продемонстрировать После того как эксперт в предметной обСделайте правило конкретным, ласти сделал краткий обзор, постарайтесь попросив привести пример. удержаться от искушения заставить его продолжать описание правила. Вместо этого сделайте правило конкретным, попросив привести пример. Буквальный вопрос «Можете привести пример?» поможет сразу перейти к делу. Участники также могут начать, попросив привести пример, но предоставьте роль лидера эксперту в предметной области. Маленькая хитрость — можно сделать преднамеренную ошибку и дать эксперту возможность вас поправить1. Таблицы часто являются самым естественным способом предоставить примеры, но вам не нужно беспокоиться о форматировании. Просто сформулируйте примеры на доске или в общем документе. Дискуссия может быть продолжена следующим образом: Программист: То есть если счет не был отправлен, специалист по работе с заказчиком может удалить его, а если был отправлен, то не может? (Берет маркер и пишет на доске.) Пользователь

Отправлен

Можно удалить?

Специалист по работе с заказчиком

Нет

Да

Специалист по работе с заказчиком

Да

Нет

Эксперт: Верно. Программист (намеренно понимая неверно): Но CSR может.

1

Пользователь

Отправлен

Можно удалить?

Специалист по работе с заказчиком

Нет

Да

Специалист по работе с заказчиком

Да

Нет

CSR

Нет

Да

CSR

Да

Да

Я научился этой хитрости у Уорда Каннингема. Один из ее вариантов был позже популяризирован Стивеном Макгиди как закон Каннингема: «Лучший способ найти ответ в Интернете — это не задать вопрос, а опубликовать неверный ответ».

312  Часть II.  Фокус на ценность Эксперт: Нет. CSR не может. Может менеджер. (Программист передает маркер эксперту.) Пользователь

Отправлен

Можно удалить?

Специалист по работе с заказчиком

Нет

Да

Специалист по работе с заказчиком

Да

Нет

CSR

Нет

Да

CSR

Да

Да

Менеджер

Да

Да, но с копией для аудита

Тестировщик: А что насчет руководителя CSR? Или администратора? Эксперт: Руководители CSR не считаются менеджерами, а администраторы — да. Но даже администраторы должны оставлять копию для аудита. Пользователь

Отправлен

Можно удалить?

Специалист по работе с заказчиком

Нет

Да

Специалист по работе с заказчиком

Да

Нет

CSR

Нет

Да

CSR

Да

Нет

Менеджер

Да

Да, но с копией для аудита

Руководитель CSR

Да

Нет

Администратор

Да

Да, но с копией для аудита

Эксперт: Добавлю еще одно замечание. «Отправлен» вообще-то означает чтолибо, что могло привести к тому, что заказчик увидел счет, независимо от того, увидел ли он его на самом деле. «Отправлен» По электронной почте Распечатан Экспортирован в PDF Экспортирован в URL

Тестировщик: А что насчет предпросмотра? Эксперт: Никто никогда не спрашивал меня об этом. Ну… очевидно… хм… окей, я вам отвечу позже.

Глава 9.  Владение  313

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

Разработать Когда обсуждение закончено, запишите результаты для использования в дальнейшем. Обычно достаточно фото и скриншота белой доски. Примеры заказчика часто представляют наиболее важные элементы логики вашего программСм. также ного приложения. Обязательно задокументируйте Разработка через тестирование их. Я предпочитаю разработать автоматические (глава 13) тесты. Однако вместо того, чтобы слепо копировать каждый пример в соответствующий тест, я использую примеры в качестве источника вдохновения для создания более точных и тщательно продуманных тестов, которые могут служить документацией для других программистов. Для этого я распечатываю копию примеров и использую разработку через тестирование, чтобы инкрементно создавать тесты и код. Когда я пишу каждый тест и соответствующий ему код, то вычеркиваю примеры, которые покрывает тест. Проще всего, если у вас есть единый язык и модель предметной области. Напри­ мер, в вашу модель могут входить класс Invoice и метод canDelete(). В этом случае у нее могут быть такие тесты, как «позволять любому удалять счета, которые не были отправлены» и «позволять только менеджерам удалять счета, которые были отправлены». Пока разработчики будут работать над кодом, вероятно, выявятся некоторые пограничные случаи, которые не обсуждались в первоначальной дискуссии. В этом случае нормально вернуться к доске. Точно так же нормально задать вопрос, получить ответ и закодировать его. При любом варианте не забудьте обновить тесты и документацию.

314  Часть II.  Фокус на ценность

Вопросы Мы должны создавать примеры до того, как См. также начнем разработку? В этом не должно быть необходимости. Игра в планирование (глава 8) Создание примеров обычно может быть перИнкрементные требования (глава 8) вой задачей в вашей разработке. Если вам нужно исследовать несколько примеров во время игры в планирование, чтобы измерить историю, то вы можете создать примеры, но в целом этого делать не нужно. Помните, что требования, в том числе примеры заказчика, должны разрабатываться поэтапно вместе с остальным вашим ПО.

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

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

Альтернативы и эксперименты Некоторые команды любят использовать средства автоматизации тестирования на естественном языке, такие как Cucumber, для превращения примеров заказчика в автоматизированные тесты. Когда-то я был одним из тех, кто это делал, — Fit Уорда Каннингема был первым из таких инструментов в сообществе Agile, и я принимал в нем активное участие. Но со временем я понял, что ценность примеров была в обсуждении у доски, а не в автоматизации. В теории заказчики должны помогать в написании Fit-тестов и использовать результаты Fit, чтобы быть уверенными в прогрессе команды. На практике это случалось редко и особой пользы не приносило. Обычная TDD была более простым способом автоматизации и работала так же хорошо. То же самое можно сказать и об инструментах наподобие Cucumber. Cucumber вышел из сообщества разработок на основе поведения (Behavior-Driven Development, BDD), основанного Дэниелом Терхорст-Нортом, который всегда был решительным сторонником взаимодействия с заказчиком. Хотя я не думаю,

Глава 9.  Владение  315

что инструменты наподобие Cucumber необходимы, сообщество BDD может быть хорошим источником идей для экспериментов. Одна из таких идей — составление карты примеров (example mapping), способ подборки примеров с помощью индексных карточек [Wynne2015]. Вы можете исследовать и другие варианты создания примеров заказчика. Многие считают инструменты наподобие Cucumber полезными для структурирования коммуникации, и некоторые команды использовали их для упрощения аудитов и прочих сторонних проверок. Сначала несколько раз попробуйте простой подход, основанный на взаимодействии и использовании белой доски, чтобы у вас сформировалась база для сравнения. Когда будете экспериментировать с другими вариантами, помните, что примеры заказчика — средство для взаимодействия и получения обратной связи, а не для автоматизации или тестирования. Убедитесь, что ваши эксперименты расширяют и дополняют этот основной принцип, а не отвлекают от него.

Литература для дополнительного чтения В главе 7 книги Specification by Example [Adzic2011] содержится великолепный набор советов для запросов примеров заказчиков, и вообще сама она достойна того, чтобы ее прочесть.

СДЕЛАНО СДЕЛАНО

Аудитория

Мы закончили, когда готовы к эксплуатации (production-ready).

Вся команда

К А Р ГО - К УЛ ЬТ

Почти сделано — Привет, Валентина! — Ширли просовывает голову в кабинет Валентины. — Ты уже закончила ту новую функциональность? Валентина кивает. — Подожди секунду, — говорит она, продолжая что-то набирать. Поток щелчков клавиш нарастает в крещендо и наконец эффектно заканчивается. — Сделано! — Валентина триумфально поворачивается, чтобы взглянуть на Ширли. — Мне тоже потребовалось всего полдня. — Впечатляюще, — говорит Ширли. — Мы думали, это должно занять целый день, а то и два. Я могу уже сейчас посмотреть на нее? — Ну, не совсем, — говорит Валентина. — Я пока еще не интегрировала новый код. — Окей, — говорит Ширли. — Но как только ты это сделаешь, я же смогу на нее посмотреть, да? Мне не терпится показать ее нашим новым клиентам. Они нас выбрали специально из-за этой функциональности. Я собираюсь развернуть новую сборку на их испытательном стенде, чтобы они могли поэкспериментировать с ней.

316  Часть II.  Фокус на ценность

Валентина хмурится. «Ну, я бы пока ее никому не показывала. Я ее еще не протестировала. И ты не сможешь ее нигде развернуть — я еще не обновила ни скрипт развертывания, ни инструмент миграции». — Я не понимаю, — ворчит Ширли. — Я думала, ты сказала, что сделала. — Сделала, — настаивает Валентина. — Я закончила писать код в тот момент, когда ты зашла. Смотри, я тебе покажу. — Нет, мне не нужно смотреть код, — отвечает Ширли. — Мне нужно показать чтото нашим заказчикам. Мне нужно, чтобы это было завершено. На самом деле завершено. — Тогда почему ты это не сказала? — говорит Валентина. — Эта функциональность сделана — весь код написан. Просто не сделано сделано. Дай мне еще несколько дней.

Разве не было бы удобно, однажды закончив историю, больше к ней никогда не возвращаться? Как раз в этом заключается идея, стоящая за понятием «сделано сделано». Завершенная история — это не свалка неинтегрированного и непротестированного кода. Она готова к работе. Когда другие истории, запланированные для вашего текущего релиза, будут готовы, вы сможете сделать его, не выполняя никаких дополнительных действий. Частично сделанные истории увеличивают ваш объем незавершенной работы, и это повышает ваши затраты, как описано во врезке «Минимизируйте объем незавершенной работы» главы 8. Вместо того чтобы нажать кнопку и сделать релиз, вы должны закончить непредсказуемое количество работы. Это дестабилизирует ваши планы релизов и мешает вам принимать и выполнять свои обязательства. Чтобы избежать этой проблемы, убедитесь, См. также что ваши истории «сделаны сделаны». Если вы используете планирование задач, основанное на Планирование задач (глава 9) итерациях, все истории в итерации должны быть сделаны в конце каждой итерации. Если вы используете непрерывный поток, истории должны быть сделаны до того, как вы снимете их с доски. У вас должна быть техническая возможность делать релиз каждой завершенной истории, даже если вы на самом деле его не делаете. Что нужно, чтобы история была «сделана сделана»? Это зависит от вашей организации. Создайте определение понятия «сделано», демонстрирующее критерии завершенности историй для вашей команды. Я пишу свое определение на доске для планирования задач. Вот пример. zz

Протестировано (все автоматизированные тесты написаны и проходят).

zz

Код написан (весь код написан).

zz

Дизайн готов (выполнен рефакторинг кода, удовлетворяющий команду).

zz

Проинтегрирован (история работает от начала до конца (обычно от UI до базы данных) и совместима с остальным ПО).

Глава 9.  Владение  317 zz

Сборка (скрипт сборки работает со сделанным изменением).

zz

Развертывание (скрипт развертывания развертывает сделанное изменение).

zz

Мигрирует (скрипт развертывания обновляет схему базы данных и переносит данные при необходимости).

zz

Проверен на месте (заказчики подтвердили, что обновленное ПО соответствует их ожиданиям).

zz

Исправлен (все известные баги исправлены или запланированы к исправлению в рамках собственных историй).

zz

Приняты на месте (заказчики согласны, что история завершена).

Некоторые команды добавляют к этому списку пункт «Задокументировано», означающий, что у истории есть документация, справочный текст и она соответствует другим стандартам документации (см. подраздел «Документация» главы 8). Другие команды добавляют нефункциональные критерии, такие как ожидаемая производительность или масштабируемость. Это может приводить к преждевременной оптимизации или к трудностям завершения историй, поэтому я предпочитаю планировать этот вид нефункциональных требований со специальными отдельными историями. Компромисс — проверять ожидания в рамках чек-листа «Сделано Сделано», но не обязательно предпринимать какие-либо действия в соответствии с ними1. Например: «Проверить время отклика. Если оно > 500 мс, то оптимизировать или создать историю производительности». Со временем вы узнаете много нового о том, См. также что нужно для вашего ПО, и усовершенствуете ваш подход к разработке. Например, можете Ретроспективы (глава 11) начать с пункта «Протестировано вручную» в вашем определении понятия «сделано». В процессе улучшения вашего подхода вы можете добавить «Автоматизированные тесты написаны и проходят» и в итоге удалить запись «Протестировано вручную». Хорошо рассматривать изменения в вашем определении понятия «сделано» во время ретроспектив.

Как быть в статусе «Сделано Сделано» Agile работает наилучшим образом, когда вы Добивайтесь ежедневно ежедневно добиваетесь небольшого прогресса небольшого прогресса в каждом в каждом аспекте вашей работы, вместо того аспекте вашей работы. чтобы работать по фазам или резервировать несколько последних дней вашей итерации, имея целью привести ваши истории к статусу «Сделано Сделано». Этот способ работы окажется более простым, как только вы к нему привыкнете, и снижает риск получения незавершенной работы в конце итерации. Однако он полагается на некоторые практики из уровня поставки. Спасибо Биллу Уэйку за этот совет.

1

318  Часть II.  Фокус на ценность Программисты, используйте разра­ См. также ботку через тестирование, чтобы совмещать тестирование, написание кода Разработка через тестирование (глава 13) и дизайн. В процессе работы интегриНепрерывная интеграция (глава 13) руйтесь с остальной работой команды, Нулевое трение (глава 13) используя непрерывную интеграцию. Поэтапно улучшайте автоматизацию сборки и развертывания для каждой задачи, которая в этом нуждается. Создайте задачи для миграции базы данных, когда возможно, и работайте над ними в рамках каждой истории. Не менее важно вовлекать ваших заказчиков в команде. Когда вы будете работать над задачами в области UI, показывайте ваш прогресс заказчикам в команде, даже если интерфейс пока еще не работает. Заказчики часто хотят попробовать UI, когда видят его впервые. Это может приводить к удивительному количеству работы, которую приходится делать в последний момент. Таким же образом, когда вы завершаете задачи и интегрируете в единое целое различные части истории, запустите код, чтобы убедиться, что все работает вместе. Хотя это и не должно быть заменой автоматизированному тестированию, хорошо сделать проверку работоспособности, чтобы не было сюрпризов. В течение всего процесса вы можете найти опечатки, ошибки или явные баги. Если найдете, то исправьте их сразу — затем улучшите ваши рабочие привычки, чтобы избежать появления таких ошибок. В некоторых случаях вы можете обСм. также наружить баг или какой-нибудь другой сюрприз, значительно увеличивающий Без багов (глава 16) размер истории. В этом случае вы моАнализ инцидентов (глава 16) жете поработать с вашим заказчиком в команде и запланировать дополнительную работу в отдельной истории (или историях). Если баг — результат ошибки дизайна или кодирования, то запланируйте его незамедлительно в  следующую итерацию или историю, поскольку ошибки этого вида, как правило, увеличивают ваши затраты на разработку и их исправление со временем становится все более дорогостоящим. Однако не успокаивайтесь на этом: такой вид историй должен быть редким. Появление их чаще, чем несколько раз в квартал, говорит о неких проблемах. Если сюрпризы относятся к недостающим или неверно понятым требованиям, то сфокусируйтесь на улучшении вовлеченности заказчика. Если они имеют отношение к ошибкам кодирования, то улучшите свободное владение навыками на уровне поставки. Если ни один из этих вариантов не работает, то попросите помощи у наставника. Когда вы уверены, что история «сделана сделана», покажите ее вашему за­ казчику в команде для финальной проверки и приемки. Так как вы проверяли вместе с ним ваш прогресс по ходу разработки, это должно занять всего несколько минут.

Глава 9.  Владение  319

Находить время Ваша команда должна завершать 4–10 историй Секрет состояния «Сделано каждую неделю. То, что вам нужно доводить до Сделано» — в создании состояния «Сделано Сделано» так много истомаленьких историй. рий, может показаться невозможно большим объемом работы. Хитрость частично состоит в том, чтобы работать поэтапно, как только что описывалось, а не по фазам. Однако настоящий секрет — в создании маленьких историй. Множество команд — новичков в Agile создают истории, слишком большие, чтобы стать «сделанными сделанными». Они завершают кодирование, но у них не хватает времени, чтобы закончить все полностью. UI немного не в порядке, тесты не завершены, и то и дело появляются баги. Помните, вы — хозяева вашего расписания. Вы решаете, на сколько историй подписаться и какова их величина. Если ваши истории слишком большие, то уменьшите их! В подразделе «Разделение и объединение историй» главы 8 описывается, как это сделать. Создание слишком больших историй — естественная ошибка, но некоторые команды усугуСм. также бляют проблему, думая: «Ну… мы действительно Потенциал (глава 9) закончили историю, за исключением одного небольшого бага». Они засчитывают ее в свой потенциал, что только усугубляет проблему. Истории, которые не «сделаны сделаны», не засчитываются в ваш потенциал. Даже если в истории лишь несколько малозначимых багов в UI или вы закончили все, кроме нескольких автоматизированных тестов, она засчитывается как ноль при подсчете вашего потенциала. Это снижает ваш потенциал, давая вам больше времени, чтобы вы смогли закончить все в следующий раз. Вы можете посчитать, что это снижает ваш потенциал настолько, что вы можете завершать всего одну или две истории в неделю. Это значит, что ваши истории были слишком большими для начала. Разделите текущие истории и работайте над тем, чтобы делать будущие истории меньшими по размеру. Команды, использующие непрерывный поток, а не итерации, не отслеживают потенциал, но к ним применима та же идея. Вы должны начинать и заканчивать 4–10 историй за неделю, и каждая должна быть «сделана сделана». Если это не так, то уменьшите истории.

Организационные ограничения У вашей команды может не быть возможности делать релиз историй самостоятельно1. Идеал Agile — кросс-функциональные команды, обладающие всеми навыками и полномочиями, необходимыми для выполнения своей работы, как описано в главе 4, однако это не всегда возможно. Спасибо Басу Водде, Томасу Оуэнсу и Кену Пью за их вклад в этот подраздел.

1

320  Часть II.  Фокус на ценность Например, вашему юридическому отделу может потребоваться проверить текст истории перед ее релизом. Ваш отдел эксплуатации может не позволить вам делать собственные развертывания. Вам может понадобиться проводить сторонние проверки безопасности или проходить пользовательские приемочные испытания. Постарайтесь разобраться с максимально возможным количеством зависимостей до начала работы над историей, как описывалось в подразделе «Кросс-командные зависимости» ранее в данной главе. Например, если ваш юридический отдел должен одобрить текст, то напишите его и получите одобрение до начала работы над той историей, для которой он нужен. Для предрелизных зависимостей, таких как поверка безопасности или пользовательСм. также ские приемочные испытания, вы можете Без багов (глава 16) определить «сделано» как передачу ПО на проверку и релиз, а не реальный релиз. Примеры заказчика (глава 9) В ваше определение понятия «сделано» Устранение препятствий (глава 11) должны входить только те части, которые находятся под вашим контролем. Однако, насколько это возможно, рассматривайте эти финальные шаги как защитную сетку. Если они обнаружат проблемы, то рассматривайте их с той же серьезностью, что и дефекты, найденные в эксплуатационной среде. Со временем работайте над снижением количества времени, затрачиваемого на сторонние зависимости. Например, некоторые команды используют автоматизированные примеры заказчика, чтобы упростить стороннюю проверку. Заручитесь помощью вашего менеджера, чтобы изменить организационные требования и привнести в команду необходимые навыки.

Вопросы Что, если история не «сделана сделана» в конце итерации? Или попытайтесь еще раз позже, или создайте новую историю для того, что осталось (см. подраздел «Незавершенные истории» ранее в данной главе). Почему в вашем списке «Протестировано» идет раньше, чем «Код написан» и «Дизайн готов»? Разве мы не должны сначала подготовить дизайн, затем написать код и только потом тестировать? Список «Сделано Сделано» — не перечень шагов или фаз, которые необходимо выполнять последовательно; он служит для финальной проверки, помогающей убедиться, что вы ничего не забыли. Agile работает лучше всего, когда вы выполняете фазы разработки инкрементно и одновременно, а не по одной за раз. В части III описывается, как это работает. Почему в вашем списке нет ручного тестирования? Ручное тестирование заканчивается фазой «Протестировать и исправить» в конце разработки, что осложняет надежное и гарантированное завершение работы. В части III описывается, как заменить эту фазу инкрементным автоматизированным тестированием. Помните, что мой список — это лишь пример. Если ваша команда использует ручное тестирование, имеет дополнительные эксплуатационные требования или должна делать что-то еще, чтобы завершить историю, то добавьте это в ваш список.

Глава 9.  Владение  321

Предварительные требования Приведение историй в состояние «Сделано Сделано» требует участия всей команды — таСм. также кой, в которую входят как минимум заказчики, Вся команда (глава 7) а также, возможно, тестировщики, специалисты по эксплуатации, технические писатели и т. д. Командная комната (глава 7) У такой команды должна быть общая рабочая Разработка через тестирование комната, физическая или виртуальная. Иначе (глава 13) есть вероятность, что команда будет слишком часто задерживать выполнение задач из-за их Инкрементный дизайн (глава 14) передачи из рук в руки, что препятствует быстрому завершению историй. Кроме того, вам, вероятно, понадобятся разработка через тестирование и эволюционный дизайн, чтобы тестировать, создавать код и дизайн для каждой истории в такие короткие сроки.

Показатели Когда ваши истории в состоянии «Сделано Сделано»: zz вы не сталкиваетесь с неожиданно возникающими объемами работы; zz команды, использующие итерации, распределяют процессы завершения и окончательной доводки работы по ходу всей итерации; zz заказчики в команде и тестировщики имеют равномерную рабочую загрузку; zz приемка работы заказчиком занимает всего несколько минут.

Альтернативы и эксперименты Эта практика — краеугольный камень планирования в Agile. Если вы не достигли статуса «Сделано Сделано» после каждой истории или итерации, то ваш потенциал и прогнозирование будут ненадежными. Вы не сможете делать релизы по своему усмотрению. Как следствие, ваши планы релизов будут срываться, что помешает вам принимать и выполнять обязательства, а это, в свою очередь, будет подрывать доверие стейкхолдеров. Такая ситуация, скорее всего, будет приводить к стрессу и давлению на команду, снижать моральный дух команды и ее активность. Альтернатива статусу «Сделано Сделано» — заполнить конец вашего расписания косметической работой. В итоге вы получите неопределенный объем работы по исправлению багов, доработке UI, миграции данных и т. д. Многие команды работают таким образом, однако это вредит доверию и вашей способности поставлять продукт. Я не рекомендую так делать.

ГЛАВА 10

Ответственность

Если Agile-команды сами управляют своей работой и своими планами, то как их организации узнают, что команды все делают правильно? Как они узнают, что команда выполняет свою работу наилучшим из возможных способов с учетом имеющихся у нее ресурсов, информации и людей? Организации могут хотеть и даже стремиться к тому, чтобы команды следовали подходу Agile, но это не значит, что у команд есть карт-бланш делать все, что они захотят. Они все же подотчетны своей организации. Они должны демонстрировать, что тратят время и деньги организации соответствующим образом. В этой главе приводятся практики, которые помогут обеспечить подотчетность. zz Практика «Доверие стейкхолдеров» позволяет команде эффективно работать со стейкхолдерами. zz С помощью практики «Демо для стейкхолдеров» вы сможете давать обратную связь о том, как продвигается ваша команда. zz Практика «Прогнозирование» предсказывает даты релизов ПО. zz Используя практику «Дорожные карты», вы сможете рассказать о прогрессе и планах команды. zz Практика «Менеджмент» помогает командам совершенствоваться.

Источники ответственности Подотчетность скорее подразумевается, чем явно указывается в литературе об Agile. Во времена экстремального программирования в сообществе обсуждали «Билль о правах заказчика», раннюю версию которого можно найти в предисловии к первой книге об XP: Заказчикам и руководителям XP обещает, что они получат максимум пользы от каждой недели программирования. Каждые несколько недель они смогут видеть конкретный прогресс в достижении важных для них целей. У них будет возможность изменить направление проекта в середине разработки, обойдясь без чрезмерных затрат [Beck2000a]. Extreme Programming Explained, первое издание Вот точное заявление об ответственности: «Мы дадим вам максимально возможную ценность». Но XP не слишком много сказало о том, как продемонстрировать

Глава 10.  Ответственность  323

ответственность. Предполагалось, что вместо этого ПО, разработанное командой, будет говорить само за себя. Практика «Демо для стейкхолдеров» — пример такого типа ответственности. Он основан на обзорах спринтов в Scrum. Но руководители и организации хотят от своих команд больше, чем только ПО; они также хотят знать, что команды работают эффективно. Это привело меня к мысли о необходимости однозначно определить практики, которые Agile-процессы обычно обходят молчанием. Первая практика в этой главе — «Доверие стейкхолдеров». За ней стоит поистине фундаментальная идея — настолько фундаментальная, что я не могу сказать, откуда пришли мои конкретные практики. Они основываются на применении разных идей, о которых я слышал в течение многих лет, отмечая работавшие наилучшим образом. Дискуссия о практике «Дорожные карты» формировалась аналогично; я перепробовал множество идей и поделился теми, которые работают. «Прогнозирование» — еще одна идея, которая существовала с самых первых дней ПО, хотя обычно ее называют оценкой (estimating). Я впитал идеи из слишком большого количества источников, чтобы помнить их все. Мой любимый источник представляет вообще-то не совсем подход к прогнозированию. Это [Little2006], статья Тодда Литтла, которая сравнивает сотни прогнозов с реальными датами релизов. Автор приходит к четким заключениям о неопределенности и предсказуемости. Статья оказала сильное влияние на мои представления о прогнозировании и легла в основу дискуссии в этой книге. Дискуссия о практике «Менеджмент» в основном вдохновлена книгой Роберта Остина Measuring and Managing Performance in Organizations [Austin1996], а также идеями, накопленными в процессе работы с Дианой Ларсен в течение многих лет.

ДОВЕРИЕ СТЕЙКХОЛДЕРОВ Мы работаем со стейкхолдерами эффективно и без опасений.

Аудитория Продакт-менеджеры,

Я знаю человека, который работал в компании вся команда с двумя командами разработки. Одна использовала подход Agile, выполняла свои обязательства и регулярно поставляла ПО. Вторая все время боролась с трудностями: отставала от графика и не могла показать никакого работающего ПО. Однако когда в компании начались сокращения, расстались с Agile-командой, а не с другой! Почему? Глядя на эту борющуюся с трудностями команду, руководители видели стены, обвешанные формальными диаграммами, и программистов, просиживающих долгие часы за работой. Когда же руководители смотрели на Agile-команду, они видели, что люди общаются, смеются и уходят домой в пять вечера, не сделав ничего, кроме черновых набросков и диаграмм на доске. Нравится это вам или нет, ваша команда живет не в вакууме. Agile поначалу может казаться странным и отличающимся от привычного. «Они действительно

324  Часть II.  Фокус на ценность работают? — интересуются посторонние. — Как-то шумно и запутанно. Я не хочу так работать. Если это будет иметь успех, то и меня заставят это делать?» По иронии судьбы чем более успешен Agile, тем больше растут опасения. Алистер Кокберн называет их организационными антителами. (Он приписывает этот термин Рону Холидею.) Если оставить их без внимания, то организационные антитела одолеют и разрушат даже в целом успешную Agile-команду. Неважно, насколько вы эффективны в поставке ПО; у вас будут проблемы, если вы не добились Неважно, насколько расположения ваших стейкхолдеров и спонсора. вы эффективны; Да, поставка ПО и выполнение технических обяесли вы не добились зательств помогают, но навыки межличностных расположения ваших стейкхолдеров и спонсора, отношений, которые демонстрирует ваша команда, то у вас будут проблемы. могут быть не менее важными и помогут завоевать доверие к ней. Это звучит нечестно и нелогично? Конечно, ваша способность поставлять высококачественное ПО — единственное, что имеет значение! Это нечестно. Это нелогично. И именно так мыслят люди. Если ваши стейкхолдеры не доверяют вам, то не будут сотрудничать с командой, и это повредит вашей способности поставлять ПО. Они даже могут выступить против вас. Не ждите, пока стейкхолдеры осознают, как ваша работа может им помочь. Покажите им это.

Добавьте немного суеты Много лет назад я нанял небольшую местную транспортную компанию, чтобы перевезти мои вещи из одной квартиры в другую. Когда грузчики прибыли, я был впечатлен, увидев, что они суетятся — передвигаются максимально быстро от авто­ фургона до квартиры и обратно. Это было особенно неожиданно, так как оплата была почасовой. Им было невыгодно работать так быстро. Эти грузчики произвели на меня впечатление. Я чувствовал, что они были настроены удовлетворить мои запросы и при этом относились с уважением к моему бумажнику. Если бы я все еще жил в том городе и собирался еще раз переезжать, то, скорее всего, нанял бы их. Они завоевали мое расположение — и мое доверие. В случае команды, разрабатывающей ПО, суета — это активная, продуктивная работа. Это ощущение, что команда честно выполняет дневную работу за честную дневную оплату. Энергичная работа, информативное рабочее пространство, демо См. также для стейкхолдеров и соответствующие дорожные карты — все это способствует переЭнергичная работа (глава 7) даче ощущения продуктивности. Однако, Информативное рабочее пространвозможно, самое важное — это отношение: ство (глава 9) в рабочие часы относитесь к работе как Демо для стейкхолдеров (глава 10) к приоритетному занятию, заслуживающему вашего полного внимания, а не как Дорожные карты (глава 10) к бремени, которого хочется избежать.

Глава 10.  Ответственность  325

Проявите эмпатию Команды разработчиков часто имеют напряженные отношения с ключевыми стейкхолдерами — представителями бизнеса. С точки зрения разработчиков, это принимает форму нечестных требований и бюрократии, особенно в виде навязывания сроков и давления на график. Вы можете удивиться, узнав, что для многих из этих стейкхолдеров разработчики — это люди, у которых все козыри. Стейкхолдеры находятся в довольно пугающей ситуации, особенно в компаниях, не связанных с бизнесом продажи ПО. Задумайтесь на минуту над тем, как это может выглядеть: zz карьера спонсоров, продакт-менеджеров, стейкхолдеров часто находится на кону. Карьера разработчиков — часто нет; zz разработчики часто зарабатывают больше, чем стейкхолдеры, очевидно, не слишком утруждаясь и не соблюдая тех правил, которых стейкхолдеры должны придерживаться; zz разработчики обычно приходят на работу значительно позже, чем представители стейкхолдеров. Они и уходят позже, но стейкхолдеры этого не видят; zz для посторонних наблюдателей разработчики часто не выглядят заинтересованными в успехе. Кажется, что их больше привлекают изучение новых технологий, подготовка своего следующего карьерного скачка, поиск баланса работы и отдыха и офисные «плюшки», такие как игра в пинг-понг и бесплатные закуски; zz опытные представители стейкхолдеров имеют множество примеров из своей истории, когда разработчикам не удавалось поставить то, что было нужно, и тогда, когда это было нужно; zz стейкхолдеры привыкли, что разработчики отвечают на вопросы о прогрессе в работе, оценках и обязательствах, используя все способы: от высокомерия до многозначительного, но бесполезного технического жаргона; zz многие стейкхолдеры видят, что крупные технические компании хорошо поставляют ПО, что редко удается их компании, и они не знают почему. Я не говорю, что разработчики плохие или что это впечатление обязательно верно. Я предлагаю Относится ли ваша команда вам подумать, что означает успех для стейкхолдек успеху ее стейкхолдеров ров вашего проекта и относится ли ваша команда, с уважением, которого тот с точки зрения внешнего наблюдателя, к успеху заслуживает? ее стейкхолдеров с уважением, которого тот заслуживает.

Выполняйте обязательства Если ваши стейкхолдеры уже работали с командами разработки ПО, то, вероятно, неоднократно терпели неудобства их-за сорванных графиков, неисправленных дефектов и зря потраченных денег. Но в то же время, скорее всего, у них самих нет навыков разработки ПО. Это ставит их в неудобное положение, когда они вынуждены

326  Часть II.  Фокус на ценность полагаться на вашу работу, имея в прошлом неудачный опыт и не имея возможности понять, будет ли ваша работа чем-то лучше. Тем временем ваша команда ежемесячно потребляет десятки тысяч долларов на зарплаты и поддержку. Как стейкхолдеры могут понять, что вы разумно используете их деньги? Как они могут знать, что команда вообще компетентна? Стейкхолдеры могут не знать, как оценивать ваш рабочий процесс, но могут оценить результаты. Особенно информативны два вида результатов: работающее ПО и исполнение обязательств. Для некоторых именно это и означает ответственность и подотчетность: вы сделали именно то, что обещали сделать. Далее, ваши обязательства дают вашим стейкхолдерам возможность, в свою очередь, брать на себя обязательства в отношении их стейкхолдеров. Послужной список, подтверждающий вашу надежность, позволит снизить их обеспокоенность. В то же См. также время, если вы не выполняете обязательства Планирование задач (глава 9) и не предупреждаете об этом заранее, стейкхолдеры легко могут предположить, что вы Демо для стейкхолдеров (глава 10) намеренно оставили их в неведении. Прогнозирование (глава 10) К счастью, Agile-команды могут быть надежны в плане обязательств. Вы можете использовать планирование задач, основанное на итерациях, чтобы брать на себя обязательства на еженедельной основе, и можете демонстрировать, что исполняете свои обязательства ровно через неделю, с помощью демо для стейкхолдеров. Вы также можете использовать поезда с релизами для создания подобного темпа релизов и управлять вашими планами так, чтобы всегда выполнять релизы точно вовремя, как описано в подразделе «Запланированные даты релизов» далее в текущей главе. Такая упорядоченная поставка ПО с обяУпорядоченная поставка ПО зательством, взятым на одной неделе, и его с обязательством, взятым на выполнением на следующей способствует одной неделе, и его выполнением формированию доверия стейкхолдеров, как на следующей способствует ничто другое. Это очень эффективное средформированию доверия ство. Все, что вам нужно, — это создать план, стейкхолдеров, как ничто другое. который вы можете выполнить… и выполнить его. И делать так снова и снова.

Управляйте проблемами Я сказал: «Это все, что вам нужно»? Я сглупил. Все не так просто. Во-первых, вам нужно создать хороший план и выполнять его (см. главы 8 и 9). Во-вторых, как сказал поэт: «Лучшие планы мышей и людей / Часто идут вкривь и вкось...»1. «К полевой мыши», стихотворение известного шотландского поэта Роберта Бёрнса. Поэма начинается так: «Маленький, хитрый, трусливый, пугливый зверь, / О, какая паника в твоей груди!» Это напоминает мне мои ощущения, когда меня попросили интегрировать ветку, содержавшую функциональность годичной давности.

1

Глава 10.  Ответственность  327

Другими словами, некоторым релизам не удается прибыть в пункт поставки в последний день. Что вы предпринимаете, когда ваши планы, подготовленные наилучшим образом, идут вкривь и вкось? Вообще-то это ваш шанс проявить себя. Кто угодно может хорошо выглядеть, когда все в жизни идет так, как запланировано. Ваш истинный характер проявляется в том, как вы решаете неожиданно возникшие проблемы. Первое, что вам нужно сделать, — снизить предрасположенность к проблемам. Работайте над самыми сложными и самыми непонятными историями на максимально раннем этапе релиза. Вы обнаружите проблемы раньше и будете иметь больше времени на их решение. Столкнувшись с проблемой, начните с того, См. также что расскажите о ней всей команде. Поднимите этот вопрос самое позднее на следующем Стендап-митинги (глава 9) стендапе. Это даст всей команде шанс помочь Планирование задач (глава 9) в решении проблемы. Кроме того, хорошим способом заметить, Резерв времени (глава 9) что что-то идет не по плану, являются итерации. Проверяйте ваш прогресс на каждом стендапе. Если проблема относительно небольшая, то вы, вероятно, сможете компенсировать ее, используя ваш резерв времени. Иначе вам придется скорректировать ваши планы, как описано в подразделе «Принятие и выполнение обязательств по итерации» главы 9. Обнаружив проблему, которую не можете решить, расскажите о ней вашим стейкхолдерам. Они оценят ваш профессионализм, даже если она им не понравится. Обычно я жду дня проведения демо, чтобы рассказать стейкхолдерам о проблемах, которые мы уже решили самостоятельно, но немедленно довожу до их сведения информацию о более серьезных проблемах. Члены команды, имеющие дипломатические навыки, должны решить, с кем и когда лучше поговорить. Чем раньше вы раскроете информацию о проблеме, тем больше времени у вас будет на ее решение. Вдобавок это снизит градус паники: на раннем этапе люди меньше переживают о сроках и имеют больше умственной энергии для решения проблемы. Похожим образом чем раньше ваши стейкхолдеры узнают о проблеме (поверьте Стейкхолдеров расстраивает мне, они в конце концов все равно о ней узне само наличие проблем, нают), тем больше у них будет времени на ее а то, что их ошарашивают решение. Стейкхолдеров расстраивает не само проблемами. наличие проблем, а то, что их ошарашивают проблемами. Когда вы рассказываете заказчику о проблеме, расскажите и о вариантах смягчения ее последствий, если можете. Это хорошо, когда вы можете объяснить суть проблемы, но еще лучше, когда вы можете объяснить, что вы собираетесь с ней делать. Начало этого разговора может потребовать немалой смелости — но успешное решение проблемы может сотворить чудо в деле формирования доверия. Не тяните с информированием заказчика о проблеме только потому, что у вас пока нет решения. Наоборот, объясните ее, расскажите, что вы делаете для поиска решения и когда он сможет услышать от вас больше информации.

328  Часть II.  Фокус на ценность Остерегайтесь соблазна работать сверхурочно или использовать резерв времени, чтобы нагнать потерянное время. Это может работать неделю или две, но решить таким образом систематические проблемы не получится. А если позволить этому продолжаться, то можно создать дополнительные трудности.

Уважайте цели заказчика Когда Agile-команды только формируются, у отСм. также дельных членов команды обычно уходит какое-то время на то, чтобы начать думать о себе как о части Динамики команды (глава 11) команды. В самом начале разработчики и заказчики часто видят себя представителями разных групп. Новые заказчики в команде, как правило, особенно пугливы. Быть частью команды разработчиков — странное чувство; они бы предпочли работать в своем обычном офисе с коллегами. И к тому же, если заказчики в команде недовольны, эти самые коллеги (которые обычно имеют прямой доступ к ключевым стейкхолдерам команды) будут первыми, кто об этом услышит. Формируя новую команду Agile, приложите усилия, чтобы расположить к себе заказчиков в команде. Один из особенно эффективных способов сделать это — относиться к целям заказчиков с уважением. Это может даже подразумевать временный запрет на циничные шутки разработчиков о графиках и костюмах. (Конечно, уважение должно быть обоюдным, и заказчики тоже должны подавлять свои естественные склонности жаловаться на сроки и спорить с оценками. Я подчеркиваю здесь потребности заказчиков, поскольку они играют очень важную роль в восприятии стейкхолдеров.) Еще один способ для разработчиков принимать всерьез цели заказчиков — выдвигать креативные альтернативы, направленные на достижение этих целей. Если заказчик хочет что-то, что может занять много времени, или вносит значительные технические риски, то посоветуйте альтернативный подход, позволяющий достичь той же основной цели, но меньшей ценой. Таким же образом при наличии более впечатляющего способа достичь цели, который заказчики не приняли во внимание, вынесите его на обсуждение, особенно если он не очень сложный. По мере таких обсуждений в команде барьеры будут разрушены и доверие начнет развиваться. Когда стейкхолдеры увидят это, их доверие к команде также возрастет. Вы можете также построить доверительные отношения непосредственно со стейкхолдерами. Подумайте: в следующий раз, когда стейкхолдер обратится к вам с просьбой, что случится, если вы незамедлительно и доброжелательно выслушаете его, запишете как историю на индексную карточку и затем расскажете о ней продакт-менеджеру, чтобы тот внес ее в план или инициировал дальнейшее обсуждение? Вас это может отвлечь всего на 10 минут, но представьте, что почувствует стейкхолдер. Вы откликнулись на его озабоченность, помогли выразить ее и предприняли немедленные шаги для того, чтобы внести ее в план. Для стейкхолдеров это гораздо важнее, чем отправлять электронные письма в черную дыру вашей системы трекинга требований.

Глава 10.  Ответственность  329

Сделайте так, чтобы стейкхолдеры выглядели хорошо Даже если ваши непосредственные стейкхолдеры любят вас, им необходимо убедить своих боссов, чтобы те тоже вас полюбили. Что нужно вашим стейкхолдерам? Подумайте о ситуации, в которой они находятся, как их оценивают и что вы можете сделать, чтобы, в свою очередь, поддержать их. Один из вариантов — создать книгу ценностей, которую бизнес-стейкхолдеры смогут показывать своим боссам. Это регулярно обновляемый документ, в который вы записываете ценность, транслируемую стейкхолдерам. Он поможет напомнить стейкхолдерам, что вы для них сделали, и позволит им оправдать вашу работу перед остальной организацией. Например: «Релиз Х обработал 20 000 событий за первые два месяца, снизив частоту ошибок на 8 %». Хотя это и может выглядеть как маркетинговый ход (а это он и есть), данный способ позволяет командам оставаться сфокусированными на ценности. Обновление книги ценностей заставляет членов команды размышлять над тем, что они сделали для стейкхолдеров и заказчиков. Это помогает не допустить того, чтобы команда считала себя просто фабрикой для поставки историй.

Будьте честны В своем энтузиазме демонстрировать прогресс будьте осторожны и не переступайте черту. Пограничное поведение включает в себя замалчивание известных дефектов в демо для стейкхолдеров, приписывание себе историй, которые еще не завершены на 100 %, и продление срока итерации на несколько дней, чтобы завершить все, что содержится в плане итерации. Сокрытие правды подобным образом создает у стейкхолдеров впечатление, что вы сделали больше, чем на самом деле. Они будут ожидать, что вы завершите остальные истории так же быстро, хотя фактически вы еще не закончили предыдущие. В какойто момент вам придется все доделать, и получившаяся в результате задержка вызовет непонимание, разочарование и даже гнев. Даже кристально честные команды могут столкнуться с такой проблемой. Стремясь хорошо выглядеть, команды иногда берутся за большее количество историй, чем в состоянии хорошо реализовать. Они выполняют работу, но используют короткие пути, уделяя дизайну и рефакторингу недостаточно внимания. В итоге дизайн страдает, появляются дефекты, и команда вдруг обнаруживает, что замедлилась, стараясь улучшить внутреннее качество. Подобным образом не поддавайтесь искушению засчитать частично выполненные истории в свой потенциал. Если история завершена не полностью, то считается за ноль. Не приписывайте себе такие истории. Есть старая программистская шутка: первые 90 % работы занимают 90 % времени… и последние 10 % работы занимают 90 % времени. До тех пор, пока история не сделана полностью, невозможно точно сказать, какой процент был выполнен.

330  Часть II.  Фокус на ценность

Вопросы Почему строить доверие — это наша ответственность? Разве стейкхолдеры не должны внести свой вклад? Вы отвечаете только за себя. В идеале стейкхолдеры тоже много работают над взаимоотношениями, но это выходит за пределы вашего контроля. Разве не важнее быть хорошими, чем казаться хорошими? И то и другое важно. Выполняйте работу на отлично и делайте так, чтобы люди знали об этом. Вы говорите, что разработчикам лучше держать при себе шутки о сроках. Разве это не то же самое, что сказать разработчикам: «Замолчите и выполняйте работу в срок», как ни смешно? Вовсе нет. Каждый в команде должен иметь возможность высказываться и говорить правду, когда видит проблему. Однако есть большая разница между обсуждением реальной проблемы и обыкновенной циничностью. Помните, что карьера заказчиков часто стоит на кону. Они могут быть не в состоянии увидеть разницу между реальной шуткой и жалобой, замаскированной под шутку. Неуместная шутка может вызвать у них выброс адреналина так же легко, как и реальная проблема.

Предварительные требования Обязательства — это эффективный инструмент выстраивания доверия, но только если вы их выполняете. Не берите на себя обязательств перед стейкхолдерами, пока не докажете свою способность брать и выполнять обязательства внутри команды. Более подробную информацию можно найти в подразделе «Принятие и выполнение обязательств по итерации» главы 9.

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

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

Глава 10.  Ответственность  331

Литература для дополнительного чтения В книге Trust and Betrayal in the Workplace [Reina2015] представлен тщательный анализ того, как установить атмосферу доверия и что делать, когда оно разрушено. В книге The Power of a Positive No: How to Say No and Still Get to Yes1 [Ury2007] рассказывается, как сказать «нет», при этом сохранив важные для вас отношения. Диана Ларсен описывает эту способность как «вероятно, более важную в построении доверия, чем навык ведения переговоров любого масштаба».

ДЕМО ДЛЯ СТЕЙКХОЛДЕРОВ У нас всё по-настоящему.

Аудитория

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

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

1

332  Часть II.  Фокус на ценность установить контакт с ними и узнать о них больше информации, особенно если они активные участники. Аналогично, если люди, которые, как вы считали, жизненно заинтересованы в вашей работе, не присутствуют, то хорошей идеей будет узнать причины. Само демо — «момент истины» для команды. Оно дает вашей команде обратную связь в отношении способности вашей команды закончить начатую работу. Будет трудно обманывать себя, считая, что работа сделана, если вы не сможете продемонстрировать ее стейкхолдерам. В конечном итоге демо также служит обратной См. также связью и для стейкхолдеров. Оно показывает им, что вы — ответственная команда: прислушиваетесь к их Доверие стейкхолдеров потребностям и демонстрируете стабильный прогресс. (глава 10) Это крайне важно, поскольку помогает стейкхолдерам поверить, что ваша команда действует в их интересах.

Частота демо Начните с проведения демо еженедельно или каждую итерацию, если используете итерации длиннее недели. Всегда проводите демо в одно и то же время и в одном и том же месте. Это поможет установить ритм, облегчит людям планирование участия и придаст сильный импульс с самого начала. Если ваша работа не секретная, то приглашайте См. также всех в компании, кому это может быть интересно. Вся команда, ключевые стейкхолдеры и исполнительный Вовлечение реального спонсор должны присутствовать как можно чаще. По заказчика (глава 8) возможности пригласите реальных заказчиков. Вдобавок можно позвать другие команды, работающие рядом, и людей, интересующихся Agile. Если вы используете итерации, то проводите демо незамедлительно по окончании каждой из них. Я люблю проводить демо на следующий день, утром. Это поможет вашей команде поддерживать дисциплину, поскольку вы не сможете затянуть работу до следующей итерации. Как правило, на демо планируют 30 минут. Может быть и дольше, но время ваших самых важных стейкхолдеров очень ценное, поэтому лучше планировать короткие встречи, чтобы они могли участвовать регулярно. Пусть ваше решение основывается на их заинтересованности и доступности. Помните, что вы также всегда можете связаться с людьми после демо. Вместе с презентацией демо предложите стейкхолСм. также дерам способ попробовать что-то самостоятельно. Для этого варианта можно задействовать промежуточный Флаги функций (глава 15) (staging) сервер или, если вы используете флаги функций (feature flags, фича-флаги), специальные разрешения для учетных записей стейкхолдеров.

Глава 10.  Ответственность  333

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

Как проводить демо для стейкхолдеров Вести демо может кто угодно в команде. Лучший вариант — тот, кто наиболее тесно сотрудничает со стейкхолдерами. Как правило, это продакт-менеджер. Он (или она) может говорить с ними на одном языке и лучше всех понимает их точку зрения. Кроме того, такое взаимодействие подчеркнет, что потребности стейкхолдеров управляют работой команды. Продакт-менеджеры обычно просят разработчиков проводить демо вместо них. Я часто вижу такое, когда продакт-менеджер не видит себя частью команды или не чувствует, что достаточно хорошо знает ПО. Отклоняйте такие просьбы. Разработчики создают ПО не для продакт-менеджеров; вся команда, включая менеджера, создает ПО для стейкхолдеров. Продакт-менеджер — лицо этой деятельности, поэтому он (или она) должен сам вести демо. Чтобы продакт-менеджеры были более вовлеченными и ориентировались в продукте, помогайте им, вместе просматривая истории в процессе разработки. Подготовленная часть демонстрации должна занимать менее 10 минут. Вам не нужно показывать все детали. В процессе презентации разрешите задавать вам вопросы и давать обратную связь, но следите за тем, чтобы закончить вовремя. Если вам нужно больше времени из-за большого количества обратной связи, то это знак, что нужно проводить демо чаще. С другой стороны, если вам трудно привлечь участников или они кажутся незаинтересованными, то проведение демо реже может дать вам больше материала для обсуждения. ПРИМЕЧАНИЕ Если вы общаетесь с большим количеством людей, то вам может понадобиться установить правила относительно вопросов и прерываний, чтобы демо не заняло слишком много времени.

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

334  Часть II.  Фокус на ценность тем людям, которые до этого не были полностью посвящены в детали. Затем кратко опишите истории, над которыми команда работала с момента предыдущего демо. Если вы внесли в свой план любые изменения, которые могут вызвать обеспокоенность стейкхолдеров, то объясните, что случилось. Не приукрашивайте и не скрывайте проблемы. Полная прозрачность повысит доверие к вам. Ничего не упрощая и не преСпокойно опишите проблемы и то, увеличивая, вы продемонстрируете способкак вы с ними разобрались. ность вашей команды профессионально обращаться с проблемами. Например: Докладчик: Последние две недели мы были сфокусированы на совершенствовании нашей системы бронирования авиабилетов. Она уже завершена, и мы можем выпустить ее так, как есть, но добавляем «украшения», чтобы сделать ее более впечатляющей и упростить ее использование для наших заказчиков. Мы завершили все запланированные истории, но нам пришлось изменить визуализацию маршрута, как именно — я вам покажу через минуту. Это оказалось слишком дорого, так что нам понадобилось найти другое решение. Это не совсем то, что мы планировали, но мы довольны результатом.

После вступления пройдитесь по историям, над которыми работала команда. Вместо того чтобы буквально читать каждую историю, перефразируйте их так, чтобы они представляли контекст. Можно комбинировать истории или опускать детали, которые могут быть неинтересны стейкхолдерам. Потом продемонстрируйте результат в ПО. Истории без пользовательского интерфейса можно опустить или просто описать на словах. Докладчик: Наши первые две истории касались автоматического заполнения платежной информации пользователя при авторизации в системе. Итак, я зай­ ду как наш тестовый пользователь… нажму «бронирования»… и там вы можете увидеть, что платежная информация заполняется автоматически. Один из слушателей: А что, если они изменят свою платежную информацию? Докладчик: Тогда мы спросим их, хотят ли они сохранить изменения. (Демонстрирует.)

Стейкхолдерам часто есть что сказать в качестве обратной связи. В основном она будет незначительной. Если же это существенное изменение направления разработки, то подумайте, как вам лучше вовлечь стейкхолдеров во время разработки в следующий раз, чтобы потом не удивляться. В любом случае сделайте для себя пометку о поступившем предложении и пообещайте вернуться к этому позже. Слушатель: Система оповещает клиентов, когда их платежная информация устарела? Докладчик: В данный момент нет, но это хорошая идея. (Делает пометку.) Я посмотрю и вернусь к этому вопросу позже.

Глава 10.  Ответственность  335

Если вы столкнулись с историей, которая не заработала, как планировалось, то дайте простое объяснение. Не защищайтесь; просто объясните, что произошло. Докладчик: Наша следующая история касается визуализации маршрутов. Как я уже упомянул, нам для этого понадобилось изменить планы. Возможно, вы помните, что наш изначальный план был показывать этапы полета с помощью анимированного 3D-сюжета. Программисты были несколько обеспокоены производительностью, поэтому сделали тест, и оказалось, что рендеринг анимации нанесет серьезный удар по нашим затратам на облачные сервисы. Слушатель: Почему это так дорого? (Докладчик поворачивается к программисту.) Программист: Некоторые мобильные устройства не имеют возможности делать 3D-анимацию в браузере или не могут делать это плавно. Поэтому нам пришлось бы делать это в облаке. А время работы облачного графического процессора стоит очень дорого. Мы могли бы построить облачную версию и версию на клиентской стороне и, может быть, кешировать некоторые из анимаций, но нам бы понадобилось подробнее изучить статистику использования, прежде чем мы смогли бы сказать, насколько это помогло. Докладчик: Это всегда было скорее приятным дополнением, и повышенные облачные затраты того не стоили. Мы также не хотели тратить на это дополнительное время разработки, поэтому вернулись к обычной 2D-карте. Ни у кого из наших конкурентов вообще нет карты этапов полета. У нас не оставалось времени на анимацию карты, но, увидев результат (показывает), мы решили, что она выглядит достойно. Мы предпочли бы пойти дальше вместо того, чтобы тратить на это еще больше времени.

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

Подготовьтесь Перед началом демо убедитесь, что все истории, планирующиеся для демонстрации, в состоянии См. также «Сделано Сделано» и что у вас есть версия ПО, Сделано Сделано (глава 9) включающая их. Убедитесь, что у участников есть возможность попробовать демо самостоятельно. Вам не нужно создавать для демо безупречную презентацию с идеальной графикой, но все же нужно быть подготовленными. Вы должны быть готовы презентовать демо в течение 5–10 минут, а это значит, что вам следует знать свой материал и при этом быть лаконичными.

336  Часть II.  Фокус на ценность Чтобы подготовиться, просмотрите истоСм. также рии, которые были закончены с предыдущего демо, и выстройте их в порядке повествования. Цель (глава 7) Решите, какие истории можно объединить, Визуальное планирование (глава 8) чтобы лучше объяснить суть. Посмотрите на цель и визуальный план вашей команды и решите, как каждый набор историй связан с вашим текущим инкрементом, вашим ближайшим релизом и с миссией и концепцией в целом. Составьте план того, что вы хотите сказать. Наконец, проведите несколько репетиций. Сценарий вам не нужен (спонтанная речь звучит более натурально), но вы точно захотите потренироваться. Пройдитесь по тем элементам, которые хотите продемонстрировать, чтобы убедиться, что все работает в соответствии с вашими ожиданиями и данные для всех примеров присутствуют. Затем порепетируйте свое выступление. Сделайте это несколько раз, пока не будете спокойны и уверенны. Каждое следующее демо будет требовать все меньше и меньше подготовки и репетиций. В конце концов подготовка войдет в привычку и будет занимать всего несколько минут.

Когда дела идут плохо Иногда ничего не получается. Вам нечего показать стейкхолдерам, или то, что есть, их наверняка разочарует. В этой ситуации очень заманчиво сфальсифицировать демо. У вас может появиться соблазн показать UI, в котором нет никакой логики, или намеренно избежать демонстрации тех действий, в которых есть дефект. Это трудно, но вы должны быть честными Четко укажите на ограничения в отношении того, что происходит. Четко укавашего ПО и на то, что вы жите на ограничения вашего ПО и на то, что намерены делать с ними. вы намерены делать с ними. Фальсификация прогресса заставит ваших стейкхолдеров поверить, что потенциал команды больше, чем на самом деле. Они будут ожидать от вас продолжения в том же завышенном темпе, а вы постоянно будете отставать. Вместо этого возьмите на себя ответственность как команда (а не обвиняйте отдельных лиц или другие группы), старайтесь не занимать оборонительную позицию и проинформируйте стейкхолдеров о том, что вы делаете, чтобы предотвратить повторение подобных ситуаций. Например: Боюсь, на этой неделе нам нечего показать. Мы планировали показать вам отслеживание рейсов в реальном времени, но недооценили сложность взаимодействия интерфейса с бэкендом авиационных систем. Мы ожидали, что данные будут более чистыми, чем оказалось на самом деле, и не поняли сразу, что нам нужно будет создать собственную тестовую среду. Мы рано обнаружили эти проблемы и думали, что сможем их как-то обойти. Мы это сделали, но недостаточно вовремя, чтобы закончить что-то конкретное,

Глава 10.  Ответственность  337

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

Вопросы Что нам делать, если стейкхолдеры продолжают прерывать и задавать вопросы во время демо? Вопросы и прерывания — это прекрасно! Значит, стейкхолдеры вовлечены и заинтересованы. Если вас так часто прерывают и задают вопросы, что вы не можете уложиться в 30-минутный лимит времени, то, возможно, вам придется проводить демо чаще. Или, если это только один особенно заинтересованный человек, вы можете попросить его (или ее) отложить вопросы на более позднее время после встречи. Кроме того, можно планировать встречи длительностью больше 30 минут, особенно в первые месяц или два. Что нам делать, если стейкхолдеры продолжают придираться к нашему выбору решений? Придирки — это тоже нормально, они служат признаком интереса, когда вы начинаете проводить демо. Не принимайте их слишком близко к сердцу. Запишите идеи на карточки, как любую другую историю, и приоритизируйте их после встречи. Удерживайтесь от соблазна начать разбираться, приоритизировать или разрабатывать решения во время встречи. Это не только ее затягивает, но и нарушает дисциплину обычной практики планирования. Если придирки продолжаются по истечении первых одного-двух месяцев, то это может служить знаком, что заказчики в команде что-то упускают. Внимательно изучите их претензии, чтобы понять, есть ли более глубокая проблема. Стейкхолдерам очень нравится то, что они видят, и они хотят добавить набор функциональностей. Это хорошая идея, но нам уже нужно заниматься другими вещами. Что нам делать? Не говорите «нет» во время демо. И не говорите «да». Просто поблагодарите стейкхолдеров за их предложения и запишите их в качестве историй. По окончании демо заказчики в команде должны будут более внимательно посмотреть предложения и оценить их значимость относительно цели команды. Если они не вписываются в график команды, то член команды с навыками менеджмента продукта может сообщить это стейкхолдерам.

338  Часть II.  Фокус на ценность Что, если люди не приходят на демо или не вовлечены? Возможно, вы проводите демо слишком часто или они слишком длинные. Попробуйте проводить их реже и потренируйтесь говорить кратко. Кроме того, есть вероятность, что люди не понимают, какое отношение имеет к ним ваше ПО. Спросите ключевых стейкхолдеров, что вы можете сделать, чтобы демо стали более полезными и актуальными. Что, если у нас несколько команд, работающих над одним и тем же ПО? Возможно, имеет смысл объединить работу команд в одно демо. В этом случае выберите одного человека, который представит работу всех. Это потребует кросскомандной координации, и данная тема выходит за рамки этой книги, но такая координация у вас уже должна быть налажена как часть подхода к масштабированию. Прочитайте главу 6, чтобы получить больше информации. Если объединение работы всех команд в одно демо по какой-либо причине не имеет смысла, то вы можете продолжать проводить отдельные демо. Некоторые организации предпочитают планировать их проведение во время одной большой встречи, но это плохо масштабируется. Вместо этого лучше организуйте множество комбинированных демо (например, одно — для команд, работающих непосредственно с заказчиком, другое — для внутренней администрации, третье — для поддержки разработки и т. д.) и спланируйте их так, чтобы люди могли сами выбрать, в каком демо поучаствовать.

Предварительные требования Никогда не фальсифицируйте демо для стейкхолдеров, скрывая баги или показывая незавершенные истории. Вы просто навлечете на себя неприятности в будущем. Если вы не можете демонстрировать прогресс, не прибегая к подделкам, — это явный знак того, что у вашей команды проблемы. Замедлитесь и попытайтесь разобраться, что идет не так. Если вы не используете итерации, то попробуйте их. Если используете, то прочитайте подраздел «Принятие и выполнение обязательств по См. также итерации» главы 9 и попросите помощи у наставника. Проблема может заключаться Планирование задач (глава 9) в том, что вы пытаетесь сделать слишком много всего одновременно.

Показатели Когда ваша команда хорошо проводит демо: zz

вы вызываете доверие у стейкхолдеров;

zz

вы узнаёте, что стейкхолдеры увлечены больше всего;

zz

команда уверена в своей способности поставлять продукт;

zz

вы прямо говорите о проблемах, что позволяет вашей команде не давать им выходить из-под контроля.

Глава 10.  Ответственность  339

Альтернативы и эксперименты Демо для стейкхолдеров — четкий показатель вашей способности к поставке. Или у вас есть завершенные истории для демонстрации, или нет. Или ваши стейкхолдеры довольны вашей работой, или нет. Я не знаю альтернатив, которые могли бы предоставить настолько ценную обратную связь. Эта обратная связь — важная часть демо для стейкхолдеров. Обратная связь, касающаяся способности вашей команды к поставке, обратная связь, говорящая об удовлетворенности стейкхолдеров, а также обратная связь, которую вы получаете, наблюдая их реакцию и слушая их вопросы и комментарии. Когда вы экспериментируете с демо для стейкхолдеров, держите в голове эту обратную связь. Демо — не только способ поделиться тем, чем вы сейчас заняты. Это еще и способ узнать ваших стейкхолдеров. Некоторые команды упрощают проведение демо, записывая краткое видео. Это разумная идея, и ее стоит попробовать. Но видео не даст вам столько же обратной связи. Удостоверьтесь, что в любых экспериментах, которые вы пробуете, есть вариант, который позволяет подтвердить вашу способность выполнить работу и узнать у ваших стейкхолдеров интересующую вас информацию. Некоторые команды выворачивают демонстрацию наизнанку: вместо того чтобы показывать стейкхолдерам то, что они делают сейчас, они наблюдают за стейкхолдерами, которые сами тестируют их ПО. Это лучше всего работает в условиях непосредственного общения. Это также хорошо работает, если у вас множество команд, работающих в офисе: вы можете пригласить их всех в одно большое помещение и провести демо в стиле «базар» или «торговая выставка», когда стейкхолдеры могут перемещаться от команды к команде и наблюдать их работу1.

ПРОГНОЗИРОВАНИЕ Мы можем предсказать наши релизы.

Аудитория

«Когда вы закончите?» Программисты боятся Продакт-менеджеры этого вопроса. В разработке ПО столько нюансов, что просто невозможно точно знать, что осталось сделать, не говоря уже о том, сколько времени это займет. Тем не менее у стейкхолдеров есть реальная потребность знать, сколько времени займет работа. Им нужно планировать бюджет и координироваться с третьими сторонами. Чтобы сформировать доверие и продемонстрировать свою ответственность, вы должны быть в состоянии предсказать, когда будет релиз. Составление этих прогнозов обычно называется оценкой (estimate), но это неверный термин. Оценка — просто одна из техник прогнозирования, и даже не самая важная. Настоящий секрет хорошего прогнозирования — в понимании неопределенности и риска. Именно поэтому я называю это прогнозированием. Я узнал об этом подходе от Баса Водде. Подход «Базар» основан на технике «Ярмарка научных достижений», обсуждаемой в [Schatz2004].

1

340  Часть II.  Фокус на ценность

Неопределенность и риск На первый взгляд, Agile предлагает отличное реСм. также шение для прогнозирования: если вы используете итерации, то суммируйте ваши истории (или их Потенциал (глава 9) оценки), разделите на ваш потенциал — и вуаля! Резерв времени (глава 9) Получите количество итераций, оставшихся до завершения. В конце концов, потенциал и резерв времени дают вам возможность стабильно брать на себя итерационные обязательства и выполнять их. Разве это не должно означать, что вы можете взять на себя обязательства и по релизам? К сожалению, нет. Представьте, что вы в команде, которой нужно сделать 30 историй до релиза. Она стабильно делает шесть историй еженедельно, так что все займет пять недель, верно? Сегодня 1 января, поэтому вы говорите вашим бизнес-стейкхолдерам, что релиз будет через пять недель, 5 февраля. Они с энтузиазмом ждут нового релиза и начинают рассказывать о нем заказчикам. «Подождите — и увидите, что будет дальше. Ждите новостей 5 февраля!» За следующую неделю вы заканчиваете шесть историй, как обычно. В процессе вы обнаруживаете баг. Это небольшая проблема, но ее нужно решить до релиза. Вы добавляете историю, чтобы исправить баг в следующей итерации. 8 января у вас остается 25 историй. Вы сообщаете стейкхолдерам, что, вероятно, релиз будет несколько позже, чем 5 февраля. Они призывают вас немного ускориться. «Просто поднажмите, — говорят они. — Наши заказчики рассчитывают на релиз 5 февраля!» Пятнадцатого января во время демо ваши стейкхолдеры вдруг понимают, что одна из функциональностей нуждается в дополнительных средствах аудита. Вы добавляете четыре новые истории, чтобы удовлетворить эту потребность. С учетом шести законченных историй остается 23 истории, а это означает, что вы точно не закончите к 5 февраля. Вы предлагаете урезать функциональность, чтобы вернуть дату релиза к начальным условиям, но стейкхолдеры сопротивляются. «Мы уже сказали заказчикам, чего ожидать, — говорят они. — Мы просто скажем им, что будет задержка на неделю». На следующей неделе все идет гладко. Вы снова делаете шесть историй, и 22 января остается 17 историй. Вы на пути к релизу 12 февраля. Следующие несколько недель все идет не очень хорошо. Вы ждали, пока другая команда поставит специальный UI-компонент. Они обещали передать его вам в начале января, но продолжают сдвигать сроки. Теперь у вас закончились истории, над которыми можно работать. Вы берете несколько дополнительных необязательных историй наподобие «хорошо бы иметь», чтобы оставаться чем-то занятыми. Как обычно, вы завершаете шесть историй, но большинство из них новые. 29 января у вас все еще остается 15 историй. Потом команда, работающая над UI, проясняет ситуацию: они столкнулись с неожиданной технической проблемой. Компонент UI, на который вы рассчитывали, не будет готов еще минимум месяц. Вы пересматриваете свой план, добавляете истории, чтобы как-то обойти проблему отсутствующего компонента. 5 февраля, несмотря на завершение шести историй, у вас все еще 13 незаконченных историй. Ваши

Глава 10.  Ответственность  341

стейкхолдеры начинают расстраиваться. «Мы отложим релиз еще на одну неделю, до 19 февраля, — говорят они. — Вам просто нужно впихнуть все в последнюю историю. И мы не можем продолжать сдвигать дату! Нас съедят заживо в Twitter». Следующие две недели дела идут совсем не весело. Вы продолжаете искать новые истории, чтобы заменить отсутствующий компонент UI. Все работают сверхурочно, стараясь успеть к дате релиза, и вы сокращаете тестирование и резерв времени. Вы игнорируете своей потенциал и беретесь за большее количество историй, исходя из того, что дополнительное время сработает. Оно не срабатывает. На первый взгляд все выглядит хорошо. К 12 февраля вы завершаете девять историй! Однако на следующей неделе узнаёте, что четыре из них нужно переделать из-за багов и неучтенных исходных предположений. Если учесть все новые UI-истории, то оказывается, что работы слишком много. Когда приближается 19 февраля, у вас все еще остается четыре истории. В итоге на следующей неделе вы делаете релиз. 26 февраля. Вы ни разу не делали менее шести историй в неделю. Но каким-то образом релиз 30 историй изначального плана у вас занял восемь недель. Этот вид задержек называется рисками срыва графика.

Запланированные даты релизов Риски срыва графика непредсказуемы. Лучший способ прогнозировать Если бы вы могли их предсказать, то они риски срыва графика — определить, не были бы рисками — а были бы частью когда вы будете делать релиз, но вашего плана. И они неизбежны. Поэтому не что вы будете включать в него. лучший способ прогнозировать их — определить, когда вы будете делать релиз, но не что вы будете включать в него. Таким образом вы сможете скорректировать ваши планы в случае какого-либо сюрприза. В предыдущем примере если бы стейкхолдеры не сказали заказчикам, чего именно ожидать, то команда могла бы сократить пакет функциональностей и сделать релиз вовремя. Кроме того, информирование людей о том, что и когда вы будете выпускать, снижает ваше соответствие принципам Agile. Оно подразумевает поиск новой информации и ответное изменение планов. Если вы будете точно сообщать людям, что собираетесь делать, то вам придется менять ваш прогноз каждый раз, когда вы будете менять план. В лучшем случае это будет означать, что время и усилия, потраченные на предыдущий прогноз, были потрачены зря. Зачастую люди воспринимают ваши прогнозы как обязательства и расстраиваются, когда вы их меняете. Вместо этого прогнозируйте только дату релиза. Управляйте вашими планами так, чтобы быть готовыми выпустить в эту дату ваши самые ценные инкременты. Таким образом вы сможете сделать релиз вовремя независимо от того, что закончили. Обычный вариант этой идеи — поезд с релизами, который представляет собой См. также запланированную серию дат релизов (см. подраздел «Делайте частые релизы и как Адаптивное планирование (глава 8) можно раньше» главы 8).

342  Часть II.  Фокус на ценность

Как управлять своими планами Чтобы все успеть к запланированной дате релиза, нужно разделить работу на минимально возможные ценные инкременты. Сосредоточьтесь на том, чтобы как можно быстрее оказаться в состоянии, когда релиз возможен. Для этого отложите в сторону все истории, которые не обязательно выпускать. Этот простой минимум и будет вашим первым инкрементом. Как только вы его идентифицировали, посмотрите на истории, которые вы отложили, и решите, какие могут быть сделаны сами по себе, как дополнительные инкременты. Некоторые из них могут быть совсем маленькими, на одну историю — фактически это идеал. В идеальном мире вы бы хотели, чтобы каждая история была чем-то, что можно выпустить само по себе, не ожидая каких-либо дополнительных историй. Это позволит вам быть максимально гибкими и управлять своими планами. В подразделе «Держите открытым окно возможностей» главы 8 содержится больше информации по данной теме. Как минимум инкременты должны быть достаточно маленькими, чтобы вы могли легко закончить хотя бы один до даты вашего релиза. Заканчивая работу, следите за тем, сколько времени осталось, и используйте эту информацию, чтобы решить, что делать дальше. Если у вас много времени, то вы можете сформировать большой новый инкремент, ведущий ПО в новом направлении. Если времени остается не так много, то сфокусируйтесь на более мелких дополнительных инкрементах. Вы можете судить о размерах инкремента на основе внутреннего чутья. Если вам нужно больше точности, то используйте вре́менные прогнозы даты и объема работы (поговорим о них чуть позже), чтобы посмотреть, что подойдет, но не разглашайте их. Это даст вашей команде возможность поменять планы позже.

Прогнозы осуществимости Иногда вы просто хотите знать, стоит ли браться за идею, не прибегая к временны́ м и финансовым затратам на подробное планирование. Любой подход, не подразумевающий детального планирования, будет просто основан на внутренних ощущениях, и это нормально. Люди с большим опытом могут принимать правильные решения на основе своих внутренних ощущений. Чтобы сделать прогноз осуществимости, соберите вместе спонсора команды, опытного менеджера по продукту или проекту и одного-двух старших программистов — предпочтительно участников команды. Выбирайте людей с большим опытом работы в вашей компании. Попросите спонсора описать цели разработки, дату начала работы, состав команды и указать самую позднюю дату релиза, которая еще будет стоить затрат на нее. Затем спросите продакт-менеджера и программистов, считают ли они это возможным. Обратите внимание: вы не спрашиваете, сколько времени это займет. Это более трудный вопрос. Вам нужна первая, спонтанная реакция. Формулировка вопроса в терминах твердых ожиданий делает эту реакцию более надежной. Если ответ — безоговорочное «да», то имеет смысл инвестировать в месяц-другой разработки, чтобы вы смогли подготовить реальный план и прогноз. Если эксперты будут колебаться или скажут «нет», то существует риск. Стоит ли он инвестиций в более тщательный прогноз — зависит от спонсора.

Глава 10.  Ответственность  343

Прогнозы сроков и объема работы Лучше всего прогнозировать, когда, а не что вы будете выпускать, однако иногда вам все же необходимо прогнозировать и то и другое. Чтобы сделать это точно, нужно учитывать риски срыва графика. По сути, вы добавите некоторые дополнения, называющиеся поправкой на риск, чтобы компенсировать проблему. Формула выглядит так1: Количество оставшихся недель = количество оставшихся историй (или общая примерная оценка) ÷ еженедельная пропускная способность × поправка на риск Вы также можете спрогнозировать, сколько историй будет сделано к запланированной дате релиза: Количество выполненных историй (или общая примерная оценка) = количество оставшихся недель × еженедельная пропускная способность ÷ поправка на риск Вот что означает каждый из этих терминов: zz

количество оставшихся недель — количество времени от настоящего момента до даты вашего релиза;

zz

количество историй (или общая примерная оценка) — количество историй размером «в самый раз», которые должны быть завершены до релиза или будут сделаны к дате релиза. Если вы используете оценки, то это сумма оценок этих историй;

zz

еженедельная пропускная способность — если вы используете итерации, то это количество историй, законченных в последнюю итерацию (или сумма их оценок), поделенное на количество недель в итерации. Если вы используете непрерывный поток, то это количество историй, завершенных за последнюю неделю (или сумма их оценок). Не усредняйте несколько итераций или недель; здесь поможет поправка на риск;

zz

поправка на риск — табл. 10.12. Используйте столбец «Команда с высоким риском», если ваша команда не владеет свободно навыками на уровнях и фокусировки, и поставки. Выберите строку, соответствующую вашей желаемой вероятности успеть к запланированной дате или даже раньше. Например, прогнозы, сделанные с использованием строки «90 %», сбудутся к планируемой дате или раньше в девяти из десяти случаев.

Большое спасибо Тодду Литтлу за обратную связь по этой технике.

1 2

Эти цифры риска являются обоснованным предположением. Цифры, представляющие «высокий риск», основываются на [Little2006] и последующих обсуждениях с Тоддом Литтлом. Цифры, представляющие «низкий риск», основываются на симуляторе RISKOLOGY ДеМарко и Листера версии 4а, доступном по адресу https://systemsguild.eu/riskology. Я использовал стандартные настройки, но выключил отклонение производительности, так как потенциал автоматически подстраивается под этот риск.

344  Часть II.  Фокус на ценность Таблица 10.1. Эмпирические правила поправки на риск Вероятность

Команда с низким риском Команда с высоким риском

10 % (почти невозможно)

1

1

50 % (дело случая)

1,4

2

90 % (очень вероятно)

1,8

4

Прогноз сроков и объема работы зависит См. также от историй, размер которых был определен как «в самый раз» при игре в планирование. Игра в планирование (глава 8) Если вы не разбили все истории в вашем релизе до такого уровня детализации, то не сможете прогнозировать релиз. Вам понадобится использовать игру в планирование, чтобы сначала задать размер всех ваших историй. Таким же образом, если в релиз входят какие-либо спайк-истории, то вам понадобится завершить их все до того, как вы сможете сделать прогноз. Именно поэтому спайк-истории стоя́т отдельно в вашем плане; иногда ценно запланировать их заранее, чтобы вы смогли устранять риски и делать прогнозы. Обновляйте ваш прогноз в конце каждой итерации или раз в неделю, если используете непрерывный поток. При приближении даты релиза прогноз «сузится» до фактической даты релиза. Со временем составление графиков изменения прогнозируемых сроков релиза поможет вам видеть тренды, особенно если ваша пропускная способность нестабильна.

Пример сроков и объема работы Вернемся к примеру, приведенному выше. Чтобы сосчитать количество оставшихся недель, начните с количества оставшихся историй и пропускной способности команды. Как и раньше, у команды остается 30 историй, и она завершает шесть историй в неделю. Далее определите поправку на риск. Я обычно прогнозирую диапазон дат, имеющих вероятность 50–90 %. Это дает относительно узкий диапазон, который я могу преодолеть примерно за половину времени. Если я думаю, что моя аудитория не примет прогноз на основе диапазона, то использую только цифру 90 %. Конкретная поправка на риск зависит от того, к какой группе риска относится команда: высокого или низкого, что зависит от ее владения навыками. В этом случае предположим, что команда владеет навыками одновременно на уровнях фокусировки и поставки, поэтому относится к группе низкого риска. Это дает поправку на риск 1,4 и 1,8 для 50 и 90 % вероятности и позволяет получить следующие прогнозы: zz 50 % вероятности — 30 историй ÷ 6 историй в неделю × 1,4 поправка на риск = = 7,0 недель; zz 90 % вероятности — 30 историй ÷ 6 историй в неделю × 1,8 поправка на риск = = 9,0 недель.

Глава 10.  Ответственность  345

На рис. 10.1 показан прогноз в виде графика.

Рис. 10.1. Пример итерационного прогноза

Если команда составляет свой прогноз 1 января, то ее участники говорят стейкхолдерам, что сделают релиз «между 19 февраля и 5 марта». Каждую неделю команда предоставляет обновленный прогноз следующего вида: zz 1 января — остается 30 историй; прогноз: 19 февраля — 5 марта (7,0–9,0 недель); zz 8 января — остается 25 историй; прогноз: 19 февраля — 5 марта (5,8–7,5 недели; я всегда округляю); zz 15 января — остается 23 истории; прогноз: 26 февраля — 5 марта (5,4–6,9 недели); zz 22 января — остается 17 историй; прогноз: 19 февраля — 5 марта (4,0–5,1 недели); zz 29 января — остается 15 историй; прогноз: 26 февраля — 5 марта (3,5–4,5 недели); zz 5 февраля — остается 13 историй; прогноз: 26 февраля — 5 марта (3,0–3,9 недели); zz 12 февраля — остается 9 историй; прогноз: 5 марта (2,1–2,7 недели); zz 19 февраля — остается 4 истории; прогноз: 26 февраля — 5 марта (1,0–1,4 недели); zz реальный релиз — 26 февраля. Команда, упомянутая в примере, столкнулась со множеством проблем, но поправка на риск позволила ей сделать релиз вовремя.

Снижение риска Командам с высоким уровнем риска трудно составлять полезные прогнозы. Три месяца историй дают прогноз с вероятностью 50–90 % на 6–12 месяцев. Стейкхолдерам трудно принять такую высокую неопределенность.

346  Часть II.  Фокус на ценность Самый простой способ снизить риск — уменьшить размер инкрементов. Вместо того чтобы делать релизы историй объемом три месяца, делайте релизы историй объемом два месяца. Это даст прогноз на 4–8 недель с 50–90 % вероятности. Не так плохо. Более трудный, но и более эффективный способ — усовершенствовать ваши практики разработки. Вам не обязательно иметь отличное владение навыками на уровнях фокусировки и поставки, чтобы использовать колонку «Низкий риск» в таблице поправок на риск. Вам просто нужно быть в состоянии ответить утвердительно на каждый из следующих вопросов: zz Была ли у вас одинаковая пропускная способность в течение каждой из четырех последних итераций? (Или если вы используете непрерывный поток, то завершали ли вы одинаковое количество историй в каждую из четырех последних недель?) zz Если вы используете итерации, то были ли все ваши истории в четырех последних итерациях «сделаны сделаны»? zz Вы не добавили ни одной новой истории для исправления багов в течение четырех последних итераций (или недель)? zz В вашем самом последнем релизе, когда истории были закончены, смогли ли вы сразу сделать релиз в эксплуатационную среду, без дополнительной работы, ожидания контроля качества или других задержек? Разберитесь с первыми двумя вопроСм. также сами, введя практику резерва времени, как описано в подразделе «Стабилизация потенРезерв времени (глава 9) циала» главы 9. Чтобы решить проблемы, Разработка через тестирование обозначенные в двух последних вопросах, (глава 13) введите практики уровня поставки, начиная с разработки через тестирование и непреНепрерывная интеграция (глава 13) рывной интеграции.

Пользовательские поправки на риск Поправки на риск, показанные в табл. 10.1, — это просто обоснованные предположения. Если вы хотите быть более точными (и возможно, менее пессимистичными), то можете создать собственную таблицу. Однако для нее требуется очень много данных, и она не всегда стоит затраченных усилий. Чтобы создать собственную таблицу поправок на риск, вам понадобятся исторические данные об оценках релизов. Каждую неделю (или итерацию) составляйте базовую оценку релиза. Базовая оценка релиза — это количество оставшихся недель = остав­ шиеся истории (или общая оценка) ÷ недельная пропускная способность. Затем, когда релиз действительно состоится, сосчитайте, сколько времени в неделях он занял на самом деле с момента каждой из оценок. Если на вас оказывали давление, чтобы вы сделали его быстрее, или у вас было множество багов или исправлений, то используйте ту дату релиза, которая представляет реальный релиз (когда ПО на самом деле готово), — так ваши прогнозы будут представлять время, которое действительно нужно вашей команде для создания ценного релиза. В итоге вы должны прийти к нескольким парам цифр: оценочное (в неделях) и реально требующееся время (тоже в неделях). Разделите реальное время на оценочное,

Глава 10.  Ответственность  347

чтобы получить соотношение «реальное / оценочное» для каждой пары. В табл. 10.2 представлен пример. Таблица 10.2. Исторические данные оценок релизов Дата

Базовая оценка

Реальная

Реальное/оценочное

1 января

5,00 недель

8 недель

1,60

8 января

4,17 недели

7 недель

1,68

15 января

3,83 недели

6 недель

1,57

22 января

2,83 недели

5 недель

1,76

29 января

2,50 недели

4 недели

1,60

5 февраля

2,17 недели

3 недели

1,38

12 февраля

1,50 недели

2 недели

1,33

19 февраля

0,67 недели

1 неделя

1,50

В конце отсортируйте соотношения от самого маленького к самому большому. Добавьте еще одну колонку с позицией каждой строки в процентах. Другими словами, если у вас восемь строк, то значение соотношения в процентах для первой строки будет 1 ÷ 8 = 12,5 %. Это ваша пользовательская таблица поправок на риск. Проценты — это вероятность риска, и соотношение «Реальное / оценочное» — поправка на риск. Продолжение примера — в табл. 10.3. Таблица 10.3. Пример пользовательской таблицы поправок на риск Вероятность

Поправка на риск

12,5 %

1,33

25,0 %

1,38

37,5 %

1,50

50,0 %

1,57

62,5 %

1,60

75,0 %

1,60

87,5 %

1,68

100,0 %

1,76

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

348  Часть II.  Фокус на ценность

Вопросы Наша пропускная способность сильно меняется, поэтому прогнозы постоянно скачут. Можем ли мы использовать среднее значение пропускной способности, чтобы они были более стабильными? Стабилизировать пропускную способность См. также лучше с помощью потенциала и резерва времени. Если этот вариант не подходит, то можете Потенциал (глава 9) взять среднее за последние три недели (или итерации), чтобы стабилизировать прогноз Резерв времени (глава 9) или нарисовать график ваших прогнозов и добавить линии тренда. Наши прогнозы показывают, что мы делаем релизы слишком поздно. Что нам делать? Вам нужно сократить объем работы. Больше информации вы найдете в подразделе «Когда дорожная карта недостаточно хороша» далее в текущей главе. Наши эмпирические поправки на риск слишком велики. Можем ли мы использовать меньшее соотношение? Когда ваш прогноз не слишком оптимистичен, трудно удержаться от соблазна поиграть цифрами, чтобы улучшить ситуацию. Как человек, который был в такой ситуации и имеет подтверждающие данные, говорю вам, что это пустая трата времени. Так вы не измените реальных сроков релиза вашего ПО. Если у вас есть исторические данные, то можете составить пользовательскую таблицу поправок на риск, но если данных нет, то лучший вариант для вас — встретить неприятные новости с высоко поднятой головой и сократить объем работы.

Предварительные требования Запланированные даты релизов и прогнозы осуществимости подходят любой команде. Чтобы сделать прогноз даты и объема работы, вам нужна команда, работающая над актуСм. также альным ПО, для которого был сделан прогноз. Игра в планирование (глава 8) Вам нужно иметь историю, насчитывающую по меньшей мере четыре недели разработки, и вы можете прогнозировать инкременты только с историями, размер которых был заявлен как «в самый раз» при игре в планирование. Что еще более важно, убедитесь, что вам действительно нужен прогноз. Слишком многие компании просят прогнозы просто по привычке. Прогнозирование отнимает время, которое ушло бы на разработку. Не только время, требующееся на составление прогноза, но и время, необходимое для того, чтобы справиться со множеством эмоциональных реакций, которые прогнозы вызывают как у членов команды, так и у стейкхолдеров. Все это также усложняет адаптацию ваших планов. Как и во всем, что делает команда, имейте четкое представление о том, кому будут полезны прогнозы по датам и объемам работ, почему и в какой степени. Потом

Глава 10.  Ответственность  349

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

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

Альтернативы и эксперименты Существует много подходов к прогнозированию даты и объема работы. Описанный мною подход имеет преимущество одновременно в точности и простоте. Однако его зависимость от историй размера «в самый раз» делает его довольно трудоемким для прогнозов, предшествующих разработке. Другой недостаток — это объем исторических данных, требующихся для использования в пользовательских поправках на риск, хотя эмпирические правила часто довольно хороши. Альтернатива — использовать симуляцию Монте-Карло для усиления небольших объемов данных. Популярный пример — таблица Троя Мадженниса «Предсказатель пропускной способности», доступная по адресу https://www.focusedobjective.com/ courses/using-the-monte-carlo-forecasting-spreadsheets. Недостаток таблицы Мадженниса и подобных ей инструментов оценки заключается в том, что она просит вас оценивать источники неопределенности, а не использовать исторические данные. Например, таблица Мадженниса просит пользователя предположить диапазон оставшихся историй, как и диапазон количества историй, которые надо добавить (или разделить, используя ее терминологию). Эти предположения сильно влияют на прогноз, но являются всего лишь предположениями. Таблица была бы более надежной, если бы вместо предположений использовала реальные данные для расширения объема работы. Прежде чем начать экспериментировать с альтернативными прогнозами даты и объема работы, помните, что лучший способ сделать прогноз — выбрать запланированную дату релиза и строить свои планы так, чтобы успеть точно в срок.

Литература для дополнительного чтения В книге Software Estimation: Demystifying the Black Art [McConnell2006] представлен всесторонний анализ традиционных подходов к прогнозированию даты и объема работы. В статье Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty [Little2006] автор использует эмпирические данные, чтобы бросить тень сомнения на конус неопределенности (cone of uncertainty), одну из центральных идей

350  Часть II.  Фокус на ценность традиционного прогнозирования, обсуждаемого в книге Макконелла. (Данное издание также послужило основой подхода к прогнозированию даты и объема работы, описанного в этой книге.) В главе 2 книги The Leprechauns of Software Engineering: How Folklore Turns Into Fact and What to Do About It [Bossavit2013] автор отслеживает источники идеи конуса неопределенности и обнаруживает, что у нее нет эмпирической основы.

ДОРОЖНЫЕ КАРТЫ Наши стейкхолдеры знают, чего от нас ожидать.

Аудитория Продакт-менеджеры

В конечном итоге быть ответственным за результат означает делать так, чтобы инвестиции вашей организации приносили хороший доход. В идеальном мире ваши бизнес-стейкхолдеры будут доверять вашей команде делать это, избавив вас от пристального надзора. Это достижимо, но обычно сначала требуются год или два надежных по­ставок. Тем временем ваша организация хочет контролировать работу вашей команды. Демо для стейкхолдеров помогают, но менеджеры часто хотят знать больше о том, что вы делаете и чего ожидать. Вы поделитесь этой информацией в вашей дорожной См. также карте. В Agile дорожные карты не должны выДоверие стейкхолдеров (глава 10) глядеть как традиционные дорожные карты Демо для стейкхолдеров (глава 10) программного обеспечения. Я использую этот термин довольно свободно, чтобы охватить все разнообразие способов, с помощью которых команды делятся информацией о своем прогрессе и планах. Одни дорожные карты подробны и дают информацию по существу, ими нужно делиться с руководителями, другие — краткие и приукрашенные — предназначены для заказчиков.

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

Глава 10.  Ответственность  351

Подход Agile — это руководство, основанное на Подход Agile — это продукте. Оно подразумевает выделение бюджета руководство, основанное на текущую деятельность и оценку стоимости на продукте. того, что команда будет производить с течением времени. Продукт финансируется, если текущая стоимость в достаточной степени превышает текущие затраты. С момента финансирования стоимость и затраты на продукт тщательно контролируются, чтобы обеспечить достижение желаемой окупаемости инвестиций независимо от фактических характеристик продукта. Когда стоимость отличается от расчетной, затраты и планы корректируются соответствующим образом. Это адаптивный подход к руководству. Он предполагает, что команда будет искать информацию и новые возможности, потом менять свои планы так, чтобы воспользоваться преимуществами того, что она узнала. Успех определяется в терминах коммерческих результатов, таких как коэффициент рентабельности инвестиций (ROI). Руководству нужны дорожные карты, содержащие расходы, показатели стоимости, такие как выручка, и бизнес-модель. Хотя Agile адаптивный, а не предиктивный, многие Agile-команды подвержены проектному стилю руководства. Ваши дорожные карты должны учитывать эту реальность. Я предоставил четыре варианта — от максимально адаптивного до максимально предиктивного. Выберите вариант с наименьшим из номеров, с которым сможете работать. В некоторых случаях у вас будет несколько дорожных карт, например одна — для надзора со стороны руководства, а вторая — для продаж и маркетинга. Вы можете презентовать дорожную карту вашей команды в любом подходящем вам формате и с любой степенью детализации. Для внутренних дорожных карт обычно выбирают небольшую подборку слайдов, электронное письмо или Вики-страницу. Для дорожных карт, предназначенных для внешнего использования, подойдут глянцевая, менее детализированная веб-страница или маркетинговое видео.

Вариант 1. Только факты Дорожная карта «Только факты» — это совсем не дорожная карта в традиционном смысле этого слова. Это описание того, что ваша команда сделала на данный момент, без каких-либо предположений на будущее. С точки зрения ответственности и обязательств это самый безопасный вид дорожной карты, поСм. также скольку вы делитесь только теми вещами, которые Цель (глава 7) уже произошли. Ее также проще всего адаптировать, так как вы не даете никаких обещаний насчет будущих планов. В ней содержатся: zz цель вашей команды; zz что закончено и готово к следующему релизу; zz дата следующего релиза, если вы используете запланированные даты релизов (см. подраздел «Запланированные даты релизов» ранее в данной главе).

352  Часть II.  Фокус на ценность Кроме того, в дорожные карты, предназначенные для руководства, команды оптимизации вносят: zz текущие показатели коммерческой стоимости (выручка, удовлетворенность заказчика и т. д.); zz текущие затраты; zz бизнес-модель. Даже если руководству требуется более предиктивная дорожная карта, вариант «Только факты» может хорошо подойти для отдела продаж и маркетинга. Преимущество подхода «Только факты» заключается в том, что никто никогда не будет расстроен, если ваши планы изменятся, поскольку никто не знает, что планы изменились. В сочетании с поездами с релизами (см. подраздел «Делайте частые релизы и как можно раньше» главы 8) это может приводить к регулярным объявлениям о захватывающих новых функциональностях, которые люди могут получить прямо сейчас. Широко известный пример такого подхода — компания Apple, которая имеет тенденцию объявлять о новых продуктах, только когда они готовы к покупке. Он также характерен для видеоигр, использующих регулярные обновления вместе с маркетинговыми видео «Что нового», чтобы возобновить интерес и вовлеченность людей.

Вариант 2. Общее направление Стейкхолдеры часто хотят большего, чем просто факты. Они также хотят знать, что будет. План «Общее направление» обеспечивает хороший баланс. Предположения сведены к минимуму, так что ваша команда все еще может адаптировать свои планы, но в то же время и стейкхолдеры не остаются в полном неведении насчет будущего. В этой дорожной карте содержится все, что есть в варианте «Только факты», плюс: zz ценный инкремент, над которым команда работает в данный момент, и объяснение, почему он является наивысшим приоритетом; zz ценный инкремент (или инкременты), над которым команда, скорее всего, будет работать дальше. Инкременты представлены без привязки к датам. Команды оптимизации могут также добавлять гипотезы о коммерческих результатах предстоящих релизов.

Вариант 3. Дата и примерный объем работы В дорожной карте «Дата и примерный объем См. также работы» прогнозируемые даты релизов добавляются к варианту «Общее направление». Прогнозирование (глава 10) Это снижает соответствие принципам Agile и повышает риск, поскольку люди имеют склонность воспринимать такие дорожные карты как обязательства независимо от того, насколько часто вы предостерегаете от этого. Это ставит команды перед неудобным компромиссом: или вы используете консервативный прогноз, например, с вероятностью успеха 90 % и указываете

Глава 10.  Ответственность  353

пессимистичную дату релиза; или используете более оптимистичный прогноз, например, с вероятностью успеха 50 % и риском не успеть к заявленной дате. Более того, работа имеет тенденцию расти в объемах и заполнять все имеющееся время, так что более консервативные прогнозы, вероятно, приведут к меньшему количеству сделанной работы. Но так как дорожная карта не содержит деталей каждого инкремента, команда все еще может управлять своими планами, как описывалось в подразделе «Запланированные даты релизов» ранее в данной главе. Вместо того чтобы прогнозировать готовность каждой истории, сделайте консервативный прогноз для обязательных историй в вашем плане и рассматривайте его как запланированную дату релиза. Так вы получите прогноз, который сможете выполнить, не заглядывая слишком далеко в будущее. Тогда, если у вас остается дополнительное время (а если прогноз был действительно консервативным, то оно остается), вы можете использовать его для доработки и добавления других необязательных историй, которые «неплохо было бы иметь». Команды оптимизации обычно не используют этот вид дорожных карт. Бизнесзатраты не стоят получаемой выгоды. Однако эти карты могут быть полезными, когда нужно координировать работу с третьими сторонами, например с торговыми выставками или другими маркетинговыми мероприятиями.

Вариант 4. Детальные планы и прогнозы Этот вариант менее всего близок к стилю Agile и наиболее рискован. Это дорожная карта «Дата и примерный объем работы», в которой также содержится каждая история, имеющаяся в плане команды. В результате команда не может управлять своими планами, не обосновывая внесенные изменения. Это приводит к более консервативным прогнозам (что означает бо́льшую вероятность потери времени впустую) и меньшему желанию вносить изменения. Хотя это наиболее рискованный тип дорожной карты, организации часто склонны предпочитать именно его. Он кажется более безопасным, несмотря на то что в действительности является наименее безопасным. Неопределенность вызывает у людей дискомфорт, а эта дорожная карта позволяет им говорить уверенно. Однако эта уверенность — всего лишь иллюзия. Разработка ПО неопределенна по своей сути. Искусственная определенность Искусственная определенность только осложняет только осложняет адаптацию к изменяющимся адаптацию к изменяющимся обстоятельствам. обстоятельствам. Иногда вам все же придется предоставлять эту дорожную карту. Для этого делайте прогнозы, содержащие каждую историю, а не только обязательные. Как и с вариантом 3, вам понадобится сделать выбор между консервативными прогнозами, которые надежны, но потенциально ведут к потерям, и более оптимистичными, которые вы можете не выполнить. Команды, не обладающие свободным владением навыками на уровне фокусировки или поставки, обычно несут в себе много рисков, а это значит, правильный

354  Часть II.  Фокус на ценность консервативный прогноз покажет дату релиза где-то в будущем, слишком далеком, чтобы стейкхолдеры ее приняли. Обычно вам придется использовать менее консервативный прогноз, хотя дата, вероятнее всего, будет пропущена. Один из способов обойти эту проблему — делать прогнозы только ближайших релизов, если вы можете это себе позволить. В пункте «Снижение риска» (см. выше в данной главе) содержится более подробная информация по этой теме. Команды оптимизации не используют этот тип дорожной карты.

Корпоративные системы отслеживания Компании часто ставят задачу своим команОтслеживать команды дам использовать так называемые инструс помощью инструментов менты управления жизненным циклом Agile планирования — это ошибка. или другие инструменты планирования, чтобы можно было отслеживать работу команд и создавать отчеты автоматически. Это ошибка. Это не только вредит команде (которой нужна визуализация в свободной форме, которую она может легко менять и повторять), но и укрепляет и без того не соответствующий Agile подход к управлению. Agile-менеджмент представляет собой См. также создание систем, в которых команды принимают эффективные решения самостояМенеджмент (глава 10) тельно. Работа руководителя — обеспечить командам доступ к информации, контексту Цель (глава 7) и необходимой им поддержке. «ИнструменДемо для стейкхолдеров (глава 10) ты планирования Agile» имеют отношение ко всему что угодно, только не к Agile: они созданы для слежки и контроля за командами, а не для помощи им. В лучшем случае это дорогостоящее развлечение. Не используйте эти инструменты. Они повредят вашему стремлению быть Agile. Это не значит, что командами никто не управляет. Руководству все же надо держать руку на пульсе. Но это достигается с помощью периодического повторения цели команды, обеспечения наблюдения и обратной связи во время демо для стейкхолдеров и использования наиболее адаптивных дорожных карт из возможного (вдобавок к эффективному и активно вовлеченному менеджменту) командного уровня. Если от вашей команды требуют использования корпоративного инструмента отслеживания, то вносите в него только ту информацию, которую требует руководство. Для ежедневной работы используйте другие практики планирования, описанные в этой книге, копируя информацию в корпоративную систему по необходимости. Если в вашей дорожной карте только ценные инкременты, а не истории, это будет не слишком обременительно. Если вы должны вносить истории в вашу дорожную карту (чего я не рекомендую), то подумайте, нет ли легкого способа делать это. Возможно, вы сможете делать фотографию вашего визуального плана, вместо того чтобы переписывать карточки в систему. Возможно, руководителям следует более активно вовлекаться в сессии

Глава 10.  Ответственность  355

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

Когда дорожная карта недостаточно хороша В конечном итоге кто-нибудь попросит у  вас дорожную карту с  прогнозом даты, а потом скажет, что дата слишком далекая и вам нужно сделать поставку быстрее. Есть только один реалистичный способ Сократить объем работы — ускорить поставку — сократить объем рабоединственный способ ты. Вы должны удалить истории из вашего ускорить поставку. плана. Все остальное — это выдавать желаемое за действительное. Вы можете попытаться улучшить ваш потенциал (см. подраздел «Как улучшить потенциал» главы 9) или продолжать развивать навыки, но начать следует с сокращения объема. Все другие усилия требуют времени, и их влияние трудно предсказать. Если они окупятся, то вы сможете вернуть удаленные истории обратно. Иногда вам могут не позволить сократить объем работы. В этом случае вам предстоит трудный выбор. С реальностью не поспоришь, так что вам остаются дипломатические варианты решения. Вы можете или защищать свои позиции, отказываться менять прогноз и рисковать быть уволенными, или использовать менее консервативный прогноз, предложить более привлекательную дату и рисковать опоздать с релизом. Прежде чем принять решение, посмотрите на другие команды в вашей компании. Что происходит, когда они не успевают вовремя? Во многих компаниях даты релизов используются как дубинка (способ давить на людей, чтобы они работали больше и интенсивнее), но реальных последствий не несут. В других компаниях даты релизов — священные обязательства. Если вы попали в ситуацию, когда ваша дорожная карта недостаточно хороша и у вас нет возможности сократить объем работы, то попросите помощи. Положитесь на членов команды, которые понимают политику вашей организации, обсудите ваши варианты с руководителем, которому доверяете, или попросите совета у наставника. Помните: лучший подход к прогнозированию — если это возможно, выбрать запланированные даты релизов и управлять своими планами так, чтобы успеть точно в срок.

356  Часть II.  Фокус на ценность К А Р ГО - К УЛ ЬТ

Дедлайн Реальная история: у самой сложной команды, которую я когда-либо тренировал, были жесткие дедлайны. (А у кого их нет?) Реальный заказчик команды был критически важен: крупное ведомство, приносящее бóльшую часть дохода организации. Если бы мы не смогли удовлетворить его запросы, то рисковали бы лишиться огромной части жизненно важного бизнеса. Объем работы и дата готовности были фиксированными. Зная, что было поставлено на карту, я сделал надежный прогноз нашим главным приоритетом. Шесть недель спустя мы не только реализовали первый набор историй объемом на шесть недель — у нас уже был измеренный потенциал, полностью оцененный список оставшихся историй и прогноз относительно того, когда все будет сделано. Он показал, что мы опаздываем. Сильно опаздываем. Нам нужно было сделать поставку через семь месяцев. Прогноз показал, что это займет тринадцать. Я отнес прогноз директору. Все пошло прахом. Директор запретил нам делиться этими новостями с заказчиком. Вместо этого он приказал нам любым возможным способом сделать все в соответствии с первоначальным дедлайном. Мы знали, что не можем выполнить работу в соответствии с этими сроками. Мы не могли добавить людей; команда уже была полностью укомплектована, и новым программистам понадобилось бы много времени, чтобы ознакомиться с кодовой базой. Мы не могли сократить объем работы, поскольку не имели возможности признать наличие проблемы перед заказчиком. На кону стояли наши рабочие места, и мы старались, чтобы все получилось. Мы игнорировали закон Брукса («Добавление человеческих ресурсов в программный проект, не укладывающийся в сроки, приводит к еще большей задержке» [Brooks1995], с. 25), наняли группу программистов и сделали все, что смогли, чтобы быстро ввести их в курс дела, не отвлекая продуктивных членов команды от их работы. Несмотря на все наши усилия, мы поставили ПО с дефектами с шестимесячным опозданием — в пределах нескольких недель от даты нашего прогноза. Мы лишились заказчика. Я больше никогда не буду участвовать в сокрытии информации. Расписания не умеют хранить секреты. Чудес не бывает. Настоящая дата релиза в конце концов обязательно всплывет на поверхность. Вместо этого я делаю все, что в моих силах, чтобы представить наиболее точную картину происходящего. Если в данном релизе должен быть исправлен дефект, то я планирую исправление перед следующей историей. Если наш потенциал ниже того, что мне бы хотелось, я, тем не менее, делаю прогноз, основываясь на нашем реальном потенциале. Это реальность, и только будучи честным по отношению к ней, я могу эффективно управлять последствиями.

Глава 10.  Ответственность  357

Вопросы Как часто мы должны обновлять свою дорожную См. также карту? Обновляйте ее, когда появляется существенДемо для стейкхолдеров ная новая информация. Сообщать об изменени(глава 10) ях дорожной карты можно во время проведения демо для стейкхолдеров. Что мы должны говорить стейкхолдерам о вероятности прогноза? По моему опыту, стейкхолдерам трудно понять вероятность прогноза. Я даю диапазон дат, но не вдаюсь в детали насчет вероятностей. Если команда не отчитывается о детальных планах, то как руководители командного уровня понимают, что делают их команды? Руководители командного уровня могут напрямую посмотреть на доски планирования своих команд. Больше информации об управлении командами вы можете найти в разделе «Менеджмент» далее в текущей главе.

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

Показатели Когда вы хорошо используете дорожные карты: zz

руководители и стейкхолдеры понимают, над чем работает команда и почему;

zz

команде не мешают адаптировать ее планы.

Альтернативы и эксперименты Есть много способов презентовать дорожные карты, и я не вдавался в детали насчет специфических стилей презентаций. Экспериментируйте! Самый известный подход, который я видел, — наборы коротких слайдов, но некоторые также делают видео (в частности, для дорожных карт типа «Только факты»), ведут Вики-страницы и рассылают электронные письма с обновлениями статуса. Обсудите с вашими стейкхолдерами, что для них лучше. В ходе эксперимента ищите способы улучшить вашу способность адаптироваться и делать меньше прогнозов. Со временем стейкхолдеры начнут доверять вашей команде, поэтому будьте готовы к тому, что их ожидания изменятся. Вы можете обнаружить, что предыдущие требования, казавшиеся незыблемыми, больше неважны.

358  Часть II.  Фокус на ценность

Литература для дополнительного чтения Джоанна Ротман ведет отличную дискуссию об управлении ожиданиями в главе 7 книги Behind Closed Doors: Secrets of Great Management [Rothman2005].

МЕНЕДЖМЕНТ Мы помогаем своим командам достичь успеха.

Аудитория Руководители

Демо для стейкхолдеров и дорожные карты позволяют руководителям видеть, что производят их команды. Но руководителям нужно больше. Они хотят знать, работают ли команды эффективно и как они могут помочь им добиться успеха. В отличие от остальных практик данной книги, которые предназначены для членов команды, эта практика — для руководителей. В первую очередь для руководителей командного уровня, но идеи могут применять и руководители среднего и старшего звеньев. В рабочей среде, в которой команды сами решают, как будет сделана работа (см. врезку «Самоорганизующиеся команды» в главе 7), что делают руководители и как они помогают своим командам достичь успеха? Большинство организаций используют менеджмент на основе измерения: собирая показатели, Менеджмент на основе требуя отчеты и разрабатывая систему наград для измерения не работает. поощрения правильного поведения. Это проверенный временем подход к управлению, возвращающий нас во времена изобретения сборочного конвейера. Есть лишь одна проблема — он не работает. К А Р ГО - К УЛ ЬТ

Максимальное ускорение — Согласно этой книге, — говорит вице-президент по инженерным вопросам, держа в руках экземпляр Accelerate1, — высокопроизводительные организации имеют автоматизированные тесты. Начиная с этого момента любой регистрируемый вами код должен не менее чем на 90 % покрываться тестами. Это обязательное требование. Все, кто не согласен, могут искать другую работу. Тишину нарушает чей-то кашель. Затяжной, подозрительно похожий на фразу: «Корреляция — это не причинно-следственная связь». Вице-президент пристально смотрит в вашем направлении. Accelerate [Forsgren2018] — отличная книга. Я упоминаю увиденные мною случаи неправильного ее применения, а не подвергаю критике ее саму. Форсгрен Н., Хамбл Дж., Ким Дж. Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации. 1

Глава 10.  Ответственность  359

— Тебе обязательно нужно было делать это, стоя рядом со мной, Нелия? — жалобно говорите вы позже. — Здесь довольно трудно получить повышение. — Извини, — говорит она, совсем не выглядя виноватой. — Знаешь, я уже проходила через это раньше. Я могу рассказать тебе, что будет дальше. Во-первых, все будут в панике, поскольку на кон поставлена их работа. Во-вторых, руководители скажут, что ни один из наших дедлайнов не меняется, так как их бонусы зависят от соблюдения сроков релизов. В-третьих, у нас самый фиго… — Она бросает взгляд на банку ругательств. В ней уже столько взносов Нелии, что хватило профинансировать три из четырех последних «пончиковых» пятниц. — Хм, самый сомнительный пакет тестирования в мире. Много-много медленных, простеньких, ничего толком не проверяющих тестов. В итоге мы тратим все свое время, ожидая, пока пройдет тест, и разбираясь с фальшивыми ошибками тестов. И ничего не улучшается. — Вот поэтому я ненавижу всю эту белиберду с Agile, — продолжает она. — Тонны работы, ноль реальных результатов. Почему мы не можем просто писать код?

Теория X и теория Y В 1950-х Дуглас Макгрегор определил два противоположных стиля управления: теорию X и теорию Y. Каждый из них основывается на своей теории мотивации работников. Руководители, придерживающиеся теории X, уверены, что сотрудники не любят работу и пытаются ее избежать. Их нужно принуждать и контролировать. Внешние мотиваторы, такие как оплата, льготы и пособия, и другие формы поощрений — главный механизм, позволяющий заставить работников делать то, что нужно. Согласно теории X, разработка и внедрение внешних схем мотивации с использованием таких инструментов, как измерение и поощрение, — центральный элемент правильного менеджмента. Руководители, выбравшие теорию Y, верят, что сотрудникам нравится работать и они способны к самоуправлению. Они ищут ответственность и получают удовольствие, решая проблемы. Внутренние мотиваторы, такие как чувство удовле­ творенности хорошо выполненной работой, вклад в общее дело группы или решение сложных проблем, — основные движущие силы поведения работника. Согласно теории Y, центральный элемент правильного менеджмента — обеспечение контекста и вдохновения, что позволяет людям работать вне строгого контроля. Менеджмент, основанный на измерениях, — это подход теории X. Он основан на использовании внешних мотиваторов для стимулирования правильного поведения. Agile, напротив, — подход теории Y. Ожидается, что члены Agile-команд должны быть внутренне мотивированы на то, чтобы решать проблемы и достигать цели организации. Они должны быть способны сами решать, над чем им работать, а также кто и как будет выполнять работу.

360  Часть II.  Фокус на ценность Эти предположения встроены в основы Agile требует менеджмента, Agile. Успешным этот подход делает меоснованного на теории Y. неджмент, основанный на теории Y. А вот менеджмент, основанный на теории X, работать не будет. То, что он полагается на измерения и поощрения, искажает поведение и вызывает дисфункцию. Я объясню это чуть позже.

Роль руководителя в Agile Некоторые руководители беспокоятся, что в среде Agile для них нет места. Нет ничего более далекого от истины, чем это утверждение. Роль руководителя меняется, но не становится менее важной. Фактически, делегируя детали своим командам, руководители освобождают свое время, чтобы сфокусироваться на более значимой деятельности. Руководители в Agile управляют скорее общей системой работы, чем работой отдельных людей. Они настраивают свои команды на успех. Их работа заключается в том, чтобы направлять свои команды так, чтобы каждая делала правильный выбор, обходясь без непосредственного вовлечения руководства. На практике это означает, что руководители команд1: zz

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

zz

обеспечивают наличие коучей, в которых нуждается команда;

zz

выступают посредниками в межличностных конфликтах, помогают членам коман­ ды проходить через хаос изменений и формироваться как команда;

zz

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

zz

следят за прогрессом команды в развитии свободного владения навыками (см. чеклисты во введениях к частям II–IV) и координируются с коучами команды, чтобы обеспечить обучение и другие ресурсы, необходимые команде для достижения владения навыками;

zz

обеспечивают инструменты, оборудование и другие ресурсы, необходимые команде для того, чтобы быть продуктивной;

zz

делают так, чтобы команда понимала, как ее работа вписывается в общую картину организации, и чтобы у нее был устав (см. врезку «Планирование сессии подготовки устава» в главе 7), который регулярно обновляется;

Спасибо Диане Ларсен за ее вклад в подготовку этого списка.

1

Глава 10.  Ответственность  361 zz

делают так, чтобы команда понимала, насколько хорошо она соблюдает устав и как ее работу воспринимают заинтересованные стороны, в частности руководители и бизнес-стейкхолдеры;

zz

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

zz

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

zz

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

Дисфункция измерений Есть один пункт, который вы не увидите в этом списке, — показатели. Это потому, что менеджмент, основанный на измерениях, искажает поведение и вызывает дисфункцию. Приведу несколько примеров.

Менеджмент, основанный на измерениях, искажает поведение и вызывает дисфункцию.

Истории и пункты историй Руководитель команды хотел знать, была ли его команда продуктивной, поэтому отслеживал количество историй, которое команда завершала в каждой итерации. Команда сократила тестирование, рефакторинг и разработку дизайна, чтобы делать больше историй. Результатом стали понижение внутреннего качества, увеличение количества дефектов и снижение производительности. (Отслеживание потенциала приводит к такому же результату. Больше информации об этой общей ошибке вы найдете в подразделе «Потенциал — это не производительность» главы 10.)

Покрытие кода Один из топ-менеджеров поручил сделать так, чтобы весь новый код проходил тестирование. Целью было 85%-ное покрытие кода. «Весь новый код нуждается в тестировании», — сказал топ-менеджер. Хорошие тесты — маленькие, быстрые и целенаправленные, что требует внимательного и обдуманного подхода. Вместо этого команды данного топ-менеджера работали над выполнением показателей, используя самый простой и быстрый способ. Они писали тесты, которые покрывали большое количество кода, но были медленными и нестабильными, случайным образом сбоили и зачастую не проверяли ничего важного. Качество кода продолжало ухудшаться, производительность снизилась, затраты на техническое обслуживание выросли.

362  Часть II.  Фокус на ценность

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

Соотношение заявленного к сделанному Выполнение обязательств важно для выстраивания доверия, однако это нельзя считать хорошим показателем. Тем не менее одна компания сделала выполнение обязательств своей ключевой ценностью. «Ответственность здесь очень важна, — сказали они. — Если вы говорите, что собираетесь сделать что-то к определенной дате, то должны это сделать. Никаких отговорок». Их команды стали очень консервативными в своих обязательствах. Объемы работы росли и заполняли все отведенное время, снижая пропускную способность. Руководители начали отказываться от чрезмерно долгих временных графиков. Это подорвало моральный дух и создало напряженность в отношениях между руководителями и их командами. Команды делали работу торопливо и часто выбирали не лучший способ, что в итоге привело к снижению внутреннего качества, большему количеству дефектов, повышению затрат на техническое обслуживание и недовольству заказчиков.

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

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

Глава 10.  Ответственность  363

Все знают, что показатели могут вызывать проблемы. Но это лишь потому, что руководители выбирают плохие показатели, не так ли? Умный менеджер может предотвратить проблемы, умело балансируя показателями… Верно? К сожалению, нет. Роберт Остин объясняет, почему нет, в своей основополагающей книге Measuring and Managing Performance in Organizations: «Основной посыл этой книги состоит в том, что организационные измерения сложны. Организационный ландшафт усеян искореженными обломками измерительных систем, разработанных людьми, которые считали, что измерения — это просто. Если вы ловите себя на мыслях типа “Установить успешную измерительную программу легко, если вы просто выберете правильные критерии” — остерегайтесь! История показывает обратное» [Austin1996] (гл. 19).

Ситуация была бы другой, если бы в программной разработке можно было измерять все, что имеет значение. Но это невозможно. Есть слишком много важных вещей, которые (хотя и можно измерить каким-либо способом) не могут быть измерены хорошо. Внутреннее качество. Затраты на техническое обслуживание. Производительность разработки. Удовлетворенность заказчика. Устные рекомендации. Снова обратимся к Роберту Остину: «Как профессиональная активность, имеющая значительное ментальное содержание и не очень пригодная для ротации, программная разработка, похоже, особенно плохо подходит для менеджмента, основанного на измерениях… Есть свидетельства, что дисфункция измерения наносит вред программной разработке» [Austin1996] (гл. 12).

Люди (особенно в разработке ПО) ненавидят это сообщение. Мы любим фантазии о прекрасном рациональном и измеримом мире. Конечно, это просто вопрос правильного выбора измерений! Красивая история, но это ловушка. Нет способа измерить все, что имеет значение в разработке ПО. Нет способа измерить все, что имеет значение Результатом будет бесконечный цикл программ в разработке ПО. показателей, приводящих к дисфункциям, которые приводят к новым показателям, приводящим к новым дисфункциям. «Даже когда дисфункция обнаружена и выясняется, что [измерение] полностью не было достигнуто, [руководитель] может все еще сопротивляться выводу, что [измерение] не может быть достигнуто полностью. Вместо этого она может сделать вывод, что просто что-то неправильно поняла, когда пыталась изменить дизайн последней работы. Может начаться бесконечная последовательность попыток изменить дизайн работы, пока [руководитель] честно пытается понять правильно… В результате дизайнеры систем разработки ПО вечно переделывают дизайн, заменяя старые режимы контроля и выставляя новые, но структурно похожие режимы, предсказуемо не имеющие успеха» [Austin1996] (гл. 14).

364  Часть II.  Фокус на ценность

Делегируемое управление Даже если бы эффективная система измерения была возможна, измерения упускают главное. Agile требует менеджмента, основанного на теории Y, а не на теории Х, а он строится на внутренней мотивации, а не на измерениях и системах поощрений. Вместо того чтобы думать об измерениях Что члены вашей команды любят и поощрениях, сфокусируйтесь на том, что в своей работе? внутренне мотивирует членов команды. Что они любят в своей работе? Создание чего-то безумно грандиозного, что полюбят заказчики? Расширение границ технических возможностей? Быть частью высокофункциональной, слаженной команды? Затеряться в потоке продуктивной работы? Какой бы ни была мотивация, вдохновляйте вашу команду, показывая, как их работа будет отвечать их потребностям. Обеспечьте их необходимыми ресурсами и информацией. И сделайте шаг назад, чтобы они взяли на себя ответственность и совершенствовались.

Сделайте измерения несущественными Не то чтобы измерения и показатели не были полезны. Они полезны! Проблемы возникают, когда люди думают, что измерения будут использоваться для оценки их продуктивности. К сожалению, люди (особенно разработчики ПО) склонны цинично относиться к таким вещам. Важно не то, что говорят руководители; дисфункцию вызывает то, что думают люди. Чтобы избежать дисфункции, вы должны сделать неправильное использование этих данных структурно невозможным. Простейший способ сделать это — сохранять информацию приватно, внутри команды. Команда собирает данные, анализирует их и уничтожает. В качестве отчета команда выдает выводы и решения, а не данные, лежащие в их основе. Если никто их не видит, то нет и риска искажения. Если это невозможно, то агрегируйте данные так, чтобы их нельзя было связать с конкретными людьми. Вместо того чтобы использовать данные для оценки подчиненных, используйте их для оценки себя. Это применимо ко всем уровням организации. Руководители команды видят измерения команды, а не отдельных лиц. Директора видят измерения департамента, а не команды и т. д.

Идите в гемба Если руководители не получают данных о своих подчиненных, то как они узнают, насколько продуктивно работают люди? Они идут в гемба (gemba). Фраза «пойти в гемба» пришла из подхода «Бережливое производство» (Lean Manufacturing). Она означает «пойти и увидеть своими глазами»1. Идея в том, что 1

Gemba — японское слово, означающее «реальное место [где что-то произошло]», поэтому «пойти в гемба» буквально значит «пойти в реальное место».

Глава 10.  Ответственность  365

руководители узнают больше о том, что нужно, увидев реальную работу, а не глядя на цифры. Руководители, чтобы лучше узнать свои команды, пойдите и посмотрите своими глазами. Загляните в код. Просмотрите макеты UI. Посидите на интервью со стейкхолдерами. Посетите совещание по планированию. Затем подумайте, как бы вы хотели улучшить команду. Спросите себя: «Почему они уже не делают это сами?» Предположите добрые намерения: в большинстве случаев это не проблема с мотивацией; это вопрос возможности, организационных препятствий, или (не сбрасывайте это со счетов) идея уже рассматривалась и была отложена по веским причинам, которых вы просто не знаете. Crucial Accountabi­lity1 [Patterson2013] — отличная книга, в которой обсуждается, что делать дальше. Будьте осторожны, не используйте «пойти в гемба» как оправдание для микроменеджмента. Это способ улучшить ваше понимание, а не механизм контроля.

Спросите команду Компетентные Agile-команды знают о ежедневных деталях своей работы куда больше, чем кто-либо еще. Вместо того чтобы запрашивать измерения, руководители могут задать своим командам простой вопрос: «Что я могу сделать, чтобы помочь вашей команде стать более эффективной?» Выслушайте. Потом действуйте.

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

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

1

Паттерсон К., Гренни Дж., Максфилд Д. и др. Серьезный разговор об ответственности. Что делать с обманутыми ожиданиями, нарушенными обещаниями и некорректным поведением.

366  Часть II.  Фокус на ценность

они рекомендуют. Если они не знают, то попросите совета у наставников. Вот несколько вариантов, к которым может стремиться команда. zz

zz

zz

Есть ли у команды рискованные пробелы в тестах? Сделайте внутри команды анализ покрытия кода, отчет о пробелах, а не о первичных «сырых» данных покрытия кода, и выделите время для добавления тестов там, где они принесут наибольшую пользу. Нужно ли команде усовершенствовать свою дисциплину написания тестов? Обеспечьте коучинг и применяйте практики, улучшающие дисциплину, такие как парное и групповое программирование. У команды много непротестированного старого унаследованного кода? Вырабатывайте привычку добавлять тесты как часть работы над любым кодом. Очень скоро 20 % кода, над которым команда работает наиболее часто, будут иметь тесты. Остальные 80 % могут подождать.

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

Когда показатели необходимы Довольно часто у руководителей в крупных организационных системах связаны руки. Возвращаясь к Роберту Остину: «Важный факт, который необходимо осознать, — это что в иерархической организации каждый руководитель [тоже измеряется]… о  ее собственной производительности судят в основном по тому, насколько хорошо ее организация (то есть ее [работники]) работает в соответствии с той самой системой измерения, которую устанавливает [руководитель]. У [руководителя] тогда есть интерес установить простую в эксплуатации систему измерения. [Руководитель] и [работник] тайно вступают в сговор для взаимной выгоды» [Austin1996] (гл. 15).

Если вам необходимо о чем-то отчитываться, то предоставьте описание и качественную информацию, а не количественные данные, которыми можно злоупотребить. Расскажите о том, что ваша команда сделала и чему она научилась. Этого может оказаться недостаточно. От вас может потребоваться отчитываться в сухих цифрах. Сопротивляйтесь, если можете, но очень часто это вне вашего контроля. Если вы можете контролировать используемые измерения, то измеряйте результаты, максимально близкие к реальным. Одна из таких возможностей — скорость роста ценности (value velocity). Это мера производительности. Она измеряет

Глава 10.  Ответственность  367

производительность команды с течением времени. Чтобы ее сосчитать, измерьте два значения для каждого инкремента, выпускаемого командой: эффект, такой как доход; и время выполнения, которое представляет собой количество недель (или дней) от начала разработки до момента релиза инкремента. Затем разделите: ­эффект ÷ время = скорость роста ценности. Во многих случаях эффект не так просто измерить. Тогда вы можете оценить эффект каждого инкремента. Это должен сделать спонсор или ключевые стейкхолдеры вне команды. Все оценки должны быть выполнены одним и тем же человеком или сплоченной командой, чтобы они были совместимы друг с другом. Однако помните, что скорость роста ценности вызывает искажения в поведении, как и любой другой показатель. Какой бы показатель вы ни собирали, сделайте все возможное, чтобы защитить вашу команду от дисфункции. Большинство показателей вредят внутреннему качеству, затратам на техническое обслуживание, производительности, удовлетворенности заказчика и долгосрочной ценности, поскольку их трудно измерить и всегда есть соблазн подделать. Обратите внимание ваших команд на важность этих атрибутов и (если реально можете) обещайте им, что не будете использовать показатели в оценке эффективности.

Вопросы А что насчет «если вы не можете это измерить, то не сможете этим управлять»? Фразу «Если вы не можете это измерить, то не сможете этим управлять» часто приписывают Уильяму Эдвардсу Демингу, статистику, инженеру и консультанту в области управления, чьи работы оказали влияние на бережливое производство, бережливую разработку ПО и Agile. Деминг был очень влиятелен, неудивительно, что его цитата так широко известна. Есть только одна проблема: он этого не говорил. Он сказал обратное. Неверно предполагать, что если вы не можете измерить что-либо, то вы не можете этим управлять, — дорогостоящий миф1.

Предварительные требования Делегируемый стиль управления — организационная культура, которая понимает дисфункцию измерений. Несмотря на то что ей десятки лет (Деминг подчеркивал необходимость избавиться от менеджмента, основанного на измерениях, по меньшей мере в 1982-м2), она все еще недостаточно широко понята и принята. Эта цитата объяснена и помещена в контекст институтом Уильяма Эдвардса Деминга (https:// oreil.ly/FNeRb).

1

2

Принцип 12 из 14 принципов менеджмента Деминга: «А. Устраните барьеры, которые лишают почасового работника его права гордиться своим мастерством. Ответственность контролеров должна быть изменена с сухих цифр на качество. Б. Устраните барьеры, которые лишают менеджеров и инженеров их права гордиться своим мастерством. Это означает среди прочего упразднение ежегодной оценки или рейтинга заслуг и системы менеджмента на основе поставленных целей».

368  Часть II.  Фокус на ценность Agile все же может работать в среде, базирующейся на измерениях, но цель этой книги не в том, чтобы сказать вам, что просто работает; цель в том, чтобы сказать вам, что является лучшим. Делегируемый стиль управления — лучший вариант, если вы можете его использовать.

Показатели Когда вы правильно используете делегируемый стиль управления: zz

команды чувствуют, что настроены на успех;

zz

они несут ответственность за свою работу и принимают правильные решения без активного участия руководства;

zz

члены команды чувствуют уверенность, делая то, что ведет к лучшим результатам, а не к высшим баллам;

zz

члены команды и руководители не склонны снимать с себя вину и обвинять других;

zz

руководители хорошо понимают, что делают их команды и как они могут им помочь.

Альтернативы и эксперименты Основной посыл в этой практике (менеджмент, основанный на измерениях, ведет к дисфункции) — горькая пилюля для большинства организаций. Вас могут соблазнить альтернативы, которые обещают решить проблему дисфункции измерений с помощью сложных схем балансировки. Прежде чем сделать это, вспомните, что Agile — это подход к разработке, относящийся к теории Y. Правильный способ управлять Agile-командой — использовать делегируемый стиль управления, а не менеджмент на основе измерений. Если вы рассматриваете идеи с альтернативными показателями, то будьте внимательны. Дисфункция измерений не сразу становится очевидной. До этого могут пройти годы, так что идея может выглядеть великолепно на бумаге и поначалу даже казаться работающей. Вы не обнаружите ошибку до последнего момента, и даже когда обнаружите, будет слишком легко свалить вину в проявившейся проблеме на что-то другое. Другими словами, скептически относитесь к любому подходу к показателям, который не является хотя бы таким же тщательным, как подход [Austin1996]. Он основан на тезисах отмеченной наградами докторской диссертации по экономике Остина. Тем не менее есть и хорошие, продуманные подходы к Agile-менеджменту. Когда будете искать возможности для экспериментов, ищите варианты с подходом, делающим упор на сотрудничество и делегирование теории Y. Хорошей начальной точкой могут послужить ресурсы, перечисленные в подразделе «Литература для дополнительного чтения».

Глава 10.  Ответственность  369

Литература для дополнительного чтения Turn the Ship Around! A True Story of Turning Followers into Leaders [Marquet2013] — захватывающая книга и отличный способ узнать больше о делегируемом стиле управления. Автор описывает, как он, будучи капитаном американской атомной подводной лодки, учился применять делегирование в своей команде. Measuring and Managing Performance in Organizations [Austin1996] послужила источником вдохновения для многих тем в этой практике. Книга представляет строгую экономическую модель, оставаясь интересной и доступной. Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments, and Bad Behavior [Patterson2013] — хороший ресурс для руководителей, которым нужно вмешаться, чтобы помочь своим сотрудникам.

ГЛАВА 11

Совершенствование

Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Манифест Agile для разработки программного обеспечения Обратная связь и адаптация занимают центральное место в Agile, и то же самое верно в отношении самого подхода команды к Agile. Хотя вы можете начать со стандартного метода Agile, каждая команда должна сама настроить свой метод. Как и все остальное в Agile, эта настройка происходит с помощью итераций, размышлений и обратной связи. Подчеркивайте то, что работает. Улучшайте то, что не работает. В этом вам помогут следующие практики: zz с помощью практики «Ретроспективы» команда может непрерывно совершенствоваться; zz благодаря практике «Динамики команды» повышается способность команды работать совместно; zz практика «Устранение препятствий» позволит команде сосредоточить усилия по совершенствованию там, где они могут иметь наибольшее значение.

Источники совершенствования Хотя ретроспективы сейчас являются обычной практикой в Agile, в изначальных книгах об XP и Scrum1 их не было — или, собственно говоря, никаких явных практик улучшения. Непрерывное совершенствование явно занимало умы ранних приверженцев Agile, судя по его присутствию в Манифесте Agile, но ретроспективы до последнего времени не были формально обозначены в качестве практики. Первый известный мне метод Agile, включавший ретроспективы, был Industrial XP (IXP) Джошуа Кериевски в начале 2000-х. Ретроспективы в IXP были основаны на Project Retrospectives Норма Керта [Kerth2001]. Позже Диана Ларсен, которая тесно сотрудничала с Нормом Кертом, В частности, я имею в виду первое издание Extreme Programming Explained [Beck2000a] и Agile Software Development with Scrum [Schwaber2002].

1

Глава 11.  Совершенствование  371

в соавторстве с Эстер Дерби опубликовала очень влиятельную книгу Agile Retrospectives: Making Good Teams Great [Derby2006]. С этого момента ретроспективы перешли в Scrum и распространились по всему Agile-сообществу. Мой подход к практике «Ретроспективы» формировался в течение нескольких десятилетий экспериментов и опыта. Проводя первые эксперименты с непрерывным совершенствованием, я вдохновлялся постмортемами проектов — техникой, которая предшествовала Agile. Позже я позаимствовал идеи из [Kerth2001], затем работал с Джошуа Кериевски в IXP-команде и еще позже прочитал и добавил [Derby2006]. Конечный результат совместим с подходом Ларсен к ретроспективам, хотя и имеет небольшие различия. Диана Ларсен — не только гуру ретроспектив, но и эксперт в области динамик организаций и команд. Нам повезло, что она стала приглашенным автором в этой главе. Она написала разделы «Динамики команд» и «Устранение препятствий». Эти практики основаны на огромном опыте Дианы в области динамик организаций и команд, обе они предшествовали Agile.

РЕТРОСПЕКТИВЫ

Аудитория

Мы постоянно совершенствуем наши рабочие привычки.

Вся команда

КЛЮЧЕВАЯ ИДЕЯ

Непрерывное совершенствование Все Agile-команды — разные. Члены команды — разные, стейкхолдеры — разные, и то, что командам нужно делать, тоже различается. Это значит, что процессы каждой команды также должны различаться. Хотя обычно лучше начать изучать Agile со стандартного процесса, такого как тот, что представлен в данной книге, — это лишь начало, а не конец. Всегда есть способы заставить процессы команды работать лучше, и когда ваша ситуация улучшится, процесс должен измениться вместе с ней. Agile-команды постоянно ищут возможности совершенствовать свои процессы, рабочие привычки, отношения и окружающую среду. Все, что может улучшить работу, открыто для рассмотрения. Организации могут постоянно устанавливать ограничения вокруг процессов команды, но никогда не должны ожидать, что у каждой команды будет абсолютно один и тот же процесс. Чем больше команды могут адаптировать процесс к своим конкретным потребностям, тем более эффективными будут.

Ваша команда должна постоянно обновлять и улучшать свои процессы разработки. Использовать ретроспективы — отличный способ сделать это.

372  Часть II.  Фокус на ценность

Виды ретроспектив Самая обычная ретроспектива — пульсирующая (heartbeat), происходит с регулярной частотой. (Она также известна как итерационная ретроспектива.) Команды, использующие итерации, проводят ее в конце каждой итерации. Команды, использующие непрерывный поток, проводят ее в определенное время каждую неделю или две. В дополнение к пульсирующим ретроспекСм. также тивам вы можете проводить более длительные, более интенсивные ретроспективы, достигая Анализ инцидентов (глава 16) наиболее важных этапов. Такие поэтапные ретроспективы дают вам шанс более глубоко осмыслить свой опыт и обобщить ключевые уроки, чтобы поделиться ими с остальной организацией. Один из примеров — анализ инцидентов, о котором я расскажу далее в этой книге. Другие виды поэтапных ретроспектив выходят за рамки данной книги. Лучше всего они работают, когда проводятся нейтральными третьими сторонами, поэтому рассмотрите возможность пригласить опытного фасилитатора ретроспектив. Крупные организации могут иметь таких фасилитаторов в своем штате (для начала спросите отдел кадров), или можете привлечь внешнего консультанта. Если вы захотите провести эти ретроспективы самостоятельно, то прочитайте [Derby2006] и [Kerth2001] — это отличные источники информации.

Как проводить пульсирующие ретроспективы В каждой ретроспективе должна участвовать вся команда вместе с другими людьми, работающими с ней в тесном контакте, такими как продакт-менеджер. Больше никто не должен участвовать. Это даст возможность участникам более свободно высказывать свое мнение. Фасилитатором может быть кто угодно в команде. Фактически фасилитаторов лучше часто менять. Это помогает поддерживать интерес к встречам. Начните с людей, имеющих опыт фасилитации. Когда процесс ретроспективы наладится, дайте шанс другим членам команды побыть в этой роли. Фасилитатор никаким другим образом Фасилитатор никаким не участвует в ретроспективе. Его (или ее) роль другим образом не участвует заключается в поддержке общего направления в ретроспективе. ретроспективы и обеспечении того, чтобы голос каждого был услышан. Если членам команды трудно оставаться нейтральными, то команды могут обмениваться фасилитаторами, чтобы у каждой был нейтральный внешний фасилитатор. Я выделяю на свои ретроспективы 60–90 минут. Ваши первые несколько ретроспектив, вероятно, могут занять все 90 минут. Отведите на это побольше времени, но не стесняйтесь вежливо свернуть обсуждение и перейти к следующему шагу. Вся команда будет совершенствоваться, практикуясь, а следующая ретроспектива будет всего через неделю или две.

Глава 11.  Совершенствование  373

Как описывается в [Derby2006], ретроспектива состоит из пяти частей: подготовить почву; собрать данные; сгенерировать идеи; решить, что делать; закончить ретроспективу. В следующих подразделах я опишу простой и эффективный подход. Не пытайтесь в точности повторить временной режим; позвольте событиям идти в естественном темпе. Привыкнув к этому формату, измените его. Ретроспектива прекрасно подходит для апробации новых идей. Рекомендации представлены в подразделе «Альтернативы и эксперименты» далее в данной главе. Небольшое предостережение: ретроспективы могут навредить, если члены команды См. также используют их для нападок друг на друга. Если Безопасность (глава 7) у вашей команды проблемы с уважительным отношением друг к другу, то в первую очередь Динамики команды (глава 11) сосредоточьтесь на безопасности и динамиках команды.

Шаг 1. Первая директива (5 минут) В статье The Effective Postfire Critique глава Городской пожарной охраны Нью-Йорка Фрэнк Монтанья пишет: «Пожарные, как и все люди, ошибаются. Однако когда пожарные ошибаются в своей работе, это может угрожать их жизни, жизни их коллег и общества, которому они служат. Тем не менее пожарные будут продолжать делать ошибки и иногда повторять их» [Montagna1996].

Все ошибаются, даже если на кон поставлена жизнь. Ретроспектива позволяет учиться Никогда не используйте и совершенствоваться, и каждому нужно иметь ретроспективы для обвинений возможность безопасно делиться опытом и мнеили нападок на отдельных людей. нием. Команда никогда не должна использовать ретроспективы для обвинений и нападок на отдельных людей. Роль фасилитатора состоит в том, чтобы пресечь деструктивное поведение в зародыше. Чтобы помочь людям вспомнить о необходимости психологической безопасности, я начинаю каждую ретроспективу с повторения Первой директивы Норма Керта: «Независимо от того, что мы обнаружим, мы должны понимать и искренне верить, что каждый делал свою работу наилучшим образом, в соответствии с тем, что было известно на тот момент, его или ее навыками и возможностями, доступными ресурсами и сложившейся ситуацией» [Kerth2001] (гл. 1).

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

374  Часть II.  Фокус на ценность необходимо сначала решить, чтобы люди смогли говорить честно и открыто, как того требует ретроспектива. Если вы не знаете, в чем проблема, то попросите помощи у наставника. Просьба об устном согласии некоторым участникам может показаться странной, но она служит важной цели. Во-первых, если кто-то искренне против, то, вероятнее всего, скажет об этом, если нужно будет выразить согласие вслух. Во-вторых, тот, кто уже однажды высказался во время ретроспективы, скорее всего, заговорит снова. Устное согласие поощряет дальнейшее участие.

Шаг 2. Мозговой штурм (20 минут) Если все согласны с Первой директивой, то запишите на доске следующие категории: увлекательное, разочаровывающее, озадачивающее, продолжать, больше, меньше. Попросите членов команды поразмышлять о событиях с момента последней ретроспективы и используйте одновременный мозговой штурм (см. пункт «Работайте одновременно» главы 7), чтобы записать их реакции (то, что они считают увлекательным, разочаровывающим, озадачивающим) и предпочтения (то, что они хотят продолжать, делать больше или меньше). Если участникам трудно начать, то коротко напомните, что произошло с момента последней ретроспективы («Утром в среду у нас была сессия планирования…»). Делайте паузу после каждого пункта, чтобы дать людям шанс записать идеи. Другие участники тоже могут поделиться своими воспоминаниями. Когда идеи начнут заканчиваться, посмотрите на время. Если у вас оно осталось, то немного побудьте в тишине. Часто бывает так, что кто-нибудь скажет что-то, о чем умолчали, и это может вызвать новый раунд идей. Если времени у вас не осталось, то можете перейти к следующему шагу.

Шаг 3. Безмолвное сопоставление (15 минут) Далее используйте молчаливое сопоставление (mute mapping), чтобы рассортировать карточки по кластерам. Закончив, с помощью точечного голосования выберите один кластер, который предстоит совершенствовать. (О том, что такое молчаливое сопоставление и точечное голосование, рассказывается в пункте «Работайте одновременно» главы 7.) Если кластер-победитель не определился, то не тратьте времени на его выбор. Подбросьте монету или сделайте что-то подобное. Выбросьте карточки из других кластеров. Если кто-то хочет взять карточку для индивидуальной работы, это хорошо, но не необходимо. Помните: вы будете проводить следующую ретроспективу через неделю или две. Важные вопросы возникнут снова. ПРИМЕЧАНИЕ Разочарованы, что ваша любимая категория проиграла? Подождите несколько месяцев. Если она важная, то в конце концов выйдет в победители.

Глава 11.  Совершенствование  375

Шаг 4. Генерация идей (инсайтов) (10–30 минут) Предыдущие части этой активности были предназначены для сбора реакций и ощущений. Теперь пришло время анализа. Его можно проводить в виде расслаб­ ленной беседы в свободной форме. Записывайте ключевые идеи, спрашивайте у людей, которые молчат, что они думают. Постарайтесь записать, что считают ключевыми идеями участники, вместо того чтобы предлагать вашу собственную интерпретацию. Чтобы начать разговор, задавайте вопросы «почему». Почему выбранный кластер наиболее важно улучшить? Почему текущая ситуация недостаточно хороша? Почему что-то делается именно таким образом? С этого момента позвольте беседе развиваться естественным образом. Сохраняйте расслабленный темп и фокусируйтесь на исследовании идей, не переходя к поиску решений.

Шаг 5. Цель ретроспективы (10–20 минут) Настало время предложить варианты совершенствования. Попросите команду подумать над идеями улучшений в выбранной категории. Можно высказывать любые идеи, какие только придут в голову: выполнить какое-либо действие, изменить процесс, поведение или сделать что-то совершенно иное. Не пытайтесь высказывать идеальные или окончательные решения; просто предлагайте эксперименты, которые могли бы что-то улучшить. Это может помочь думать в терминах кругов и супа: чем команда управляет и на что может повлиять (см. подраздел «Круги и суп» далее в текущей главе). Не вдавайтесь слишком глубоко в детали. Достаточно общего направления. Например, если была выбрана категория «формирование пар», то идеи «чаще переключать пары» и «переключать пары по расписанию» вполне подойдут. Все это можно организовать как одновременный мозговой штурм или беседу в свободной форме. Однако если людям нужен перерыв в разговоре, то попробуйте применить технику, называемую «1 — 2 — 4 — Все». В этой технике люди начинают обдумывать варианты молча, про себя. Они записывают по одному варианту на стикер (или индексную карточку) и ограничиваются тремя самыми важными. Дайте им на это три минуты. Далее сгруппируйтесь по парам. Каждая должна выбрать из своих шести идей три самые приоритетные. Дайте им еще три минуты, дальше сгруппируйте пары в группы по четыре и предложите им уменьшить количество своих идей до двух лучших для четверки. Дайте им четыре минуты, затем каждая четверка должна поделиться своими результатами со всей командой. Группа может объединиться вокруг единственной хорошей идеи. В других случаях может образоваться несколько конкурирующих предложений. Если это происходит, то проведите еще одно точечное голосование, чтобы выбрать одно из предложений. Это ваша цель ретроспективы: усовершенствование, над которым вся команда будет работать до следующей ретроспективы. Ограничьтесь одним, чтобы команда могла сфокусироваться на нем.

376  Часть II.  Фокус на ценность Определив цель ретроспективы, попросите кого-нибудь выступить добровольцем для проработки деталей и дальнейших действий. В обязанности этого человека не будет входить продвижение этой цели или ответственность за нее (это работа всей команды), но он (или она) будет помогать людям помнить о цели по мере необходимости. Другие члены команды могут добровольно помогать, если захотят. Закончите собрание голосованием (см. пункт «Стремитесь к согласию» главы 7). Когда все согласны, ретроспектива окончена. Если по каким-то причинам вы не можете добиться согласия, то выберите другую идею или начните сначала на следующей ретроспективе.

Довести дело до конца Очень легко выйти с ретроспективы и подумать: «Ну вот, все сделано, до следующей недели». Если ничего не меняется, то ретроспектива не сработала. Убедитесь, что вы действительно выполняете цель ретроспективы. Если ничего не меняется, значит, ретроспектива не сработала. Чтобы помочь команде с дальнейшими дейСм. также ствиями, сделайте цель ретроспективы видимой. Если вы решили что-то сделать, то добавьте Информативное рабочее проэти задачи к вашему плану. Если меняете свой странство (глава 9) процесс, то обновите вашу доску планирования, Стендап-митинги (глава 9) чтобы визуализировать изменения. Если вы хотите, чтобы люди изменили свое поведение, то отслеживайте это с помощью большой наглядной диаграммы. Если меняете рабочее соглашение, то обновите ваш плакат с рабочими соглашениями. Сверяйтесь с целью ретроспективы ежедневно. Это можно делать во время стендап-митингов, напоминая членам команды о необходимости довести дело до конца.

Вопросы Несмотря на все мои усилия в качестве фасилитатора, наши ретроспективы всегда опускаются до обвинений и споров. Что я могу сделать? Приостановите ретроспективы и сосредоточьтесь на динамиках команды и установлении См. также психологической безопасности. Если это не сработает, то вам может понадобиться помощь извне. Динамики команды (глава 11) Рассмотрите возможность прибегнуть к помощи Безопасность (глава 7) специалиста по организационному развитию. Им может быть кто-то из сотрудников вашего отдела кадров. Мы придумываем хорошие цели ретроспектив, но потом ничего не происходит. Что мы делаем неправильно? Ваши идеи могут быть слишком масштабными. Помните: у вас только одна неделя, может быть, две, и у вас есть еще и другая работа. Попробуйте строить менее

Глава 11.  Совершенствование  377

грандиозные планы (возможно, на несколько часов работы) и работать над ними ежедневно. Другая возможная причина — в вашем См. также графике недостаточно резерва времени. При полной рабочей загрузке второстепенные Резерв времени (глава 9) задачи, такие как совершенствование ваших рабочих привычек, будут оставаться невыполненными. (Грустная ирония заключается в том, что усовершенствование ваших рабочих привычек даст вам больше времени.) И последнее: возможно, члены команды не чувствуют, что действительно имеют право голоса в ретроспективе. Взгляните честно на то, как вы ее проводите. Возможно, вы обманываете команду, вместо того чтобы способствовать ходу обсуждения? Попробуйте предложить кому-нибудь другому побыть фасилитатором на следующей ретроспективе. Некоторые люди не высказываются на ретроспективе. Как я могу воодушевить их на участие? Возможно, они просто застенчивы. Никто не обязан участвовать постоянно. Попробуйте начать следующую ретроспективу с какой-нибудь разминки и посмотрите, не поможет ли это. Вместе с тем, возможно, им есть что сказать, но они не чувствуют себя в безопасности. В этом случае сфокусируйтесь на создании безопасной атмосферы в команде. Одна группа людей (например, тестировщики) оказывается в меньшинстве на ретроспективах. Как мы можем удовлетворить и их потребности? Со временем каждая большая проблема получает свою долю внимания. Проводите ретроспективы несколько месяцев, прежде чем решить, какая группа оказалась бесправной. В одной команде, с которой я работал, было несколько тестировщиков, которые чувствовали, что их приоритеты игнорируются. Месяц спустя, после того как команда разобралась с другой проблемой, проблема тестировщиков заняла первое место в списках приоритетов каждого члена команды. Если время не помогает, то вы можете провести взвешенное точечное голосование. Дайте людям, чьи специализации недостаточно представлены, больше голосов. Наши ретроспективы всегда занимают очень много времени. Как нам их ускорить? Фасилитатор вполне может решительно свернуть обсуждение и двигаться дальше. Всегда можно оставить что-то на следующий раз. Если мозговой штурм или безмолвное сопоставление длятся очень долго, то вы можете сказать примерно такие слова: «Окей, у нас заканчивается время. У вас есть две минуты, чтобы записать финальные идеи (или внести окончательные изменения), и потом мы двинемся дальше». Тем не менее я предпочитаю поначалу позволять ретроспективам идти их естественным темпом, даже если они затягиваются. Это дает людям возможность привыкнуть к ходу ретроспективы, не переживая о времени. Ретроспектива мало что нам дает. Можем ли мы проводить ее реже? Если ваша команда компетентна в выбранной ею области и все идет гладко, то, возможно, осталось не так много аспектов, которые можно улучшать. В этом случае вы можете попытаться проводить ретроспективы реже, но все же продолжайте проводить их хотя бы ежемесячно.

378  Часть II.  Фокус на ценность Однако обычно это не тот случай. Более вероятно то, что ретроспектива просто устарела. Попробуйте ее изменить. Поменяйте фасилитаторов и попробуйте новые виды активности или сконцентрируйтесь на других темах.

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

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

Альтернативы и эксперименты Любой формат ретроспектив устаревает со временем. Меняйте его! Формат, представленный в этой книге, — хорошая начальная точка, но как только вы его освоите, начните экспериментировать с другими идеями. [Derby2006] — хороший источник информации, который поможет изучить нюансы проведения ретроспектив; кроме того, в нем также описываются разнообразные виды активности, которые вы можете попробовать. Опробовав эти идеи, посетите https://www.tastycupcakes.org, чтобы узнать еще больше информации. Некоторые считают, что час — это слишком мало для хорошей ретроспективы, и предпочитают 90 минут или даже два часа. Вы можете экспериментировать и с более долгими, и с более короткими вариантами. Некоторым видам активности, в частности, нужно больше времени. В ходе экспериментов проведите короткую «ретроспективу ретроспективы», чтобы оценить, какой эксперимент нужно повторить, а какой — нет. В главе 8 книги [Derby2006], Activities to Close the Retrospective, есть несколько идей. Помимо апробации новых видов активностей, вы можете экспериментировать с абсолютно другим подходом к улучшению процессов. Арло Бельши пробовал непрерывный подход, когда люди в течение недели записывали свои наблюдения и складывали записки в банку, а затем в конце недели просматривали их. У Вуди Зуилла есть упражнение, которое он называет «выявить хорошее» (turn up the good):

Глава 11.  Совершенствование  379

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

Литература для дополнительного чтения Книга Project Retrospectives1 [Kerth2001] — это основной ресурс для ретроспективных мероприятий, посвященных важным событиям. В книге Agile Retrospectives: Making Good Teams Great [Derby2006] авторы продолжают тему, начиная с того места, где остановился Керт, и обсуждают техники проведения всех видов Agile-ретроспектив. В статье The Effective Postfire Critique [Montagna1996] представлен интересный взгляд на подход к ретроспективе в профессии, связанной с жизнью и смертью.

ДИНАМИКИ КОМАНДЫ Диана Ларсен Мы стабильно совершенствуем нашу способность работать вместе.

Аудитория Вся команда

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

Что формирует команду Команда — не просто группа людей. В своей классической книге The Wisdom of Teams Джон Катценбах и Дуглас Смит описывают шесть характеристик, отличающих коман­ды от других групп: [Реальная команда] — это небольшое количество людей с взаимодополняющими навыками, приверженных общей цели, целям производительности и подходу, за которые они считают себя взаимно ответственными [Katzenback2015, chapt. 5] (курсив мой). The Wisdom of Teams 1

Керт Н. Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться вперед.

380  Часть II.  Фокус на ценность Арло Бельши предлагает другую характеристику: совместная история. Группа людей обретает ощущение себя как команды, проводя время за совместной работой. Если вы следовали практикам, представленным в этой книге, то у вас есть все предпосылки, необходимые для формирования отличной команды. Теперь вам нужно развить в себе способность сотрудничать.

Развитие команды В 1965-м Брюс Такман создал широко известную модель группового развития [Tuckman1965]. В ней он описал четыре (позднее — пять) стадии группового развития: стадия формирования, штормовая (она же штормление, бурление, конфликтная, конфронтация), стадия нормализации, стадия функционирования (исполнения) и стадия расставания (Forming, Storming, Norming, Performing and Adjourning). Эта модель показывает, как меняются степени товарищества и взаимодействия с течением времени. Идеальной модели не существует. Не восНе воспринимайте модель Такмана принимайте модель Такмана как неизбежную, как неизбежную, чисто линейную чисто линейную прогрессию. Команды могут прогрессию. демонстрировать поведение любой из четырех первых стадий. Изменения в составе, такие как приход новых членов или потеря ценных товарищей по команде, могут привести к тому, что команда вернется на более раннюю стадию. При изменениях в окружающей обстановке, например переходе от работы в общем пространстве на удаленную работу или наоборот, команда может регрессировать с более поздних стадий на более ранние. Тем не менее модель Такмана дает полезные подсказки. Она позволяет вам понять модели поведения ваших товарищей по команде, а также вы можете использовать ее как основу для дискуссий о том, как наилучшим образом поддерживать друг друга.

Стадия формирования: новенький в классе Команда формируется и начинает работать вместе. Отдельные участники могут иметь ощущение, не сильно отличающееся от того, что испытывает новичок в классе: они не стремятся к тому, чтобы работать с другими, но хотят чувствовать себя принятыми (или, скорее, не исключенными) остальной частью группы. Члены команды заняты сбором информации, которая позволит им ориентироваться на своей новой территории и чувствовать себя в безопасности. Вероятно, вы будете видеть реакции, такие как: zz

воодушевление, ожидания и оптимизм;

zz

гордость за индивидуальные навыки;

zz

обеспокоенность по поводу синдрома самозванца (страх показать себя недостаточно квалифицированным);

zz

начальная, осторожная привязанность к команде;

zz

подозрительность и беспокойство по поводу ожидаемой командной работы.

Глава 11.  Совершенствование  381

В процессе формирования команда может делать совсем мало работы, если вообще будет делать что-то относящееся к ее целям и задачам. Это нормально. Хорошая новость в том, что при поддержке большинство команд быстро проходят эту стадию. Командам на стадии формирования могут быть полезны мудрость и опыт старших членов команды, приобретенные в предыдущих командах, а также тех участников команды, которые тяготеют к действиям по сплочению группы или коучингу в области командного взаимодействия. Поддержите ваших товарищей по команде с помощью лидерства и четкого руководства. См. также (Больше информации о лидерских ролях в коЦель (глава 7) манде будет дано позднее.) Начните с поиска способов, которые позволят членам команды Контекст (глава 7) познакомиться с работой и друг с другом. СфорСогласование (глава 7) мируйте общее чувство единения сильных сторон и личностей в команде. Подготовить устав команды, содержащий цель, контекст и согласование, — отличный способ сделать это. Вам могут пригодиться и другие упражнения, помогающие узнать друг друга, такие как «Упражнение на построение взаимоотношений в команде» (см. одноименную врезку в главе 7). Наряду с подготовкой устава найдите время и для того, чтобы обсудить и разработать план команды. Сфокусируйтесь на том, что может быть сделано; выполнение каких-либо задач создаст ощущение первых успехов. (В подразделе «Ваша первая неделя» главы 9 описывается, как начать работу.) Найдите и сообщите о ресурсах, доступных команде, таких как информация, обучение и поддержка. Признайтесь в ощущениях новизны, неопределенности, растерянности и раздражения. Они естественны на этой стадии. Сессии подготовки устава должны были помочь команде разобраться с зонами ответственности, однако проясните любые оставшиеся вопросы, касающиеся рабочих ожиданий, границ полномочий и ответственности, а также рабочих соглашений. Убедитесь, что люди знают, как их команда сотрудничает с другими командами, работающими над тем же продуктом. Командам, работающим в офисе, объясните, над чем работают соседние команды, даже если это не имеет отношения к командной работе. В течение стадии формирования членам команды нужны следующие навыки: zz

одноуровневая коммуникация и обратная связь;

zz

групповое решение проблем;

zz

управление межличностными конфликтами.

Убедитесь, что членам команды доступны коучинг, наставничество или обучение этим навыкам по мере необходимости.

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

382  Часть II.  Фокус на ценность На данной стадии команда сталкивается со спорными вопросами. Это время турбулентности, совместного выбора направления, совместного принятия решений. Вот почему Такман и другие назвали эту стадию штормовой. Члены команды достигли определенной степени комфорта — достаточной, чтобы начать оспаривать идеи друг друга. Они понимают друг друга достаточно хорошо, чтобы знать, где возникают разногласия, и с готовностью выносят на обсуждение расхождения во мнениях. Такая динамика может приводить к творческой напряженности или деструктивным конфликтам в зависимости от того, как с ней обращаться. Ожидайте следующего поведения: zz нежелание справляться с задачами или множество разных подходов к тому, как это делать; zz настороженное отношение к подходам с непрерывным совершенствованием; zz резкие колебания отношения к команде и ее шансам на успех; zz недовольство недостаточным прогрессом или другими членами команды; zz споры между членами команды, даже когда они согласны по основному вопросу; zz сомнения в мудрости людей, которые выбрали структуру команды; zz подозрительное отношение к мотивам людей, которые назначили других членов команды (эти подозрения могут быть конкретными или обобщенными и зачастую больше базируются на предыдущем опыте, чем на текущей ситуации). Поддерживайте вашу конфликтующую команду, отслеживая подрывные действия, такие как оборонительное поведение, конкуренция между членами команды, формирование группировок или выбор сторон и ревность. Ожидайте повышенной напряженности и стресса. Заметив такое поведение, будьте готовы См. также вмешаться и описать примеры, которые видите. Например: «Я заметил, что вокруг Безопасность (глава 7) подхода к дизайну было много конфликтов и люди начинают формировать группировки. Есть ли способ вернуться к более коллегиальному обсуждению?» Поддерживайте прозрачность, откровенность и обратную связь и выявляйте типичные конфликтные ситуации. Открыто обсуждайте роль конфликта и давления в творческом решении проблем, включая взаимосвязь между психологической безопасностью и здоровым конфликтом. Празднуйте маленькие достижения команды. Когда вы заметите, что в команде участились случаи конфликтного поведения (а это обычно бывает через несколько недель после ее формирования), соберите команду для обсуждения темы доверия. 1. Подумайте о вашем прошлом опыте работы в команде любого типа. Когда вы больше всего доверяли своим коллегам по команде? Расскажите историю об этом времени. Какие условия способствовали формированию доверия? 2. Поразмышляйте о времени и ситуациях в вашей жизни, когда вы больше всего заслуживали доверия. Что вы замечаете в себе такого, что является ценным для вас? Как вы строили доверие с другими?

Глава 11.  Совершенствование  383

3. По вашему мнению, какой основной фактор создает и поддерживает доверие в организациях? Какой основной фактор создает, питает и поддерживает доверие среди членов команды? 4. Какие три желания вы бы загадали, чтобы сделать общение в вашей команде более доверительным и здоровым? Это трудная стадия, но она поможет членам команды набраться мудрости и заложит фундамент для следующей стадии. Ожидайте появления ощущения растущей сплоченности команды. По мере роста сплоченности продолжайте давать возможность всем членам команды выражать разнообразные мнения, вместо того чтобы заставлять их молчать ради фальшивой гармонии (см. пункт «Не уклоняйтесь от конфликта» главы 7).

Стадия нормализации: мы — № 1 Члены команды объединились в сплоченную группу. Они нашли комфортный рабочий темп и наслаждаются сотрудничеством. Они идентифицируют себя как часть команды. Фактически они могут идентифицировать себя настолько близкими и настолько наслаждаться совместной работой, что в рабочем пространстве появляются символы принадлежности. Вы можете замечать одинаковые или очень похожие футболки, чашки с названием команды или одинаковые наклейки на компьютерах. Виртуальные команды могут завести традицию дней «все в кепках» или дней «гавайских рубашек». Команды на стадии нормализации согласовали структуру и рабочие отношения. Взаимодействие позволяет развивать неформальные, неявные нормы поведения, дополняющие командные рабочие соглашения. Люди вне команды могут заметить ее «командность» и говорить об этом. Некоторые могут завидовать этому — особенно если члены команды начинают хвастаться своими успехами или объявлять свою команду «лучшей». Их гордость оправданна. Команды, находящиеся на стадии нормализации, успешно и стабильно двигаются в направлении к своей цели. Члены команды сталкиваются с рисками и успешно сотрудничают. Вы увидите следующее поведение: zz новая возможность конструктивного выражения критики; zz принятие и положительная оценка различий среди членов команды; zz чувство облегчения от того, что все это может хорошо работать; zz большее дружелюбие; zz люди чаще делятся личными историями и откровениями; zz открытое обсуждение динамик команды; zz желание обновлять рабочие соглашения и пересматривать вопросы границ с другими командами. Как вам воодушевлять вашу команду на стадии нормализации? Выходите за пределы границ команды и расширяйте кругозор участников. Способствуйте контактам с заказчиками и поставщиками. (Выезды за пределы офиса!) Если работа команды связана с работой других команд, то просите провести обучение в кросскомандных группах.

384  Часть II.  Фокус на ценность Кроме того, повышайте сплоченность команды и расширяйте свои горизонты. Ищите возможности для членов команды делиться опытом, например, совместно участвовать в волонтерских проектах или презентациях для остальной части организации. Убедитесь, что эти возможности подходят всем членам команды, чтобы ваши добрые намерения не создали группировки «своих» и «чужих». В навыки, необходимые нормализующимся командам, входят: zz обратная связь и умение слушать; zz процессы группового принятия решений; zz понимание точки зрения организации на работу команды. Книги, такие как What Did You Say? The Art of Giving and Receiving Feedback [Seashore2013] и Facilitators’ Guide to Participatory Decision-Making1 [Kaner1998], помогут команде обрести первые два навыка, а привлечение всей команды к общению с руководителями организации позволит наработать третий. Остерегайтесь попыток сохранить гармонию, избегая конфликтов. Не желая возвращаться на штормовую стадию, члены команды могут демонстрировать групповое мышление: форму ложной гармонии, когда члены команды избегают проявлять несогласие друг с другом, даже если оно оправданно. Groupthink: Psychological Studies Остерегайтесь попыток сохранить of Policy Decisions and Fiascoes [Janis1982] — гармонию, избегая конфликтов. классическая книга, исследующая этот феномен. Обсудите подходы к принятию командСм. также ных решений, когда увидите симптомы группового мышления. Одним из признаБезопасность (глава 7) ков является то, что члены команды удерживаются от критических замечаний ради сохранения мира, особенно если они высказывают критику позже, когда уже слишком поздно менять направление. Попросите членов команды критиковать и сделайте так, чтобы они чувствовали, что не соглашаться — безопасно. Один из способов избежать группового мышления — начинать дискуссии с определения желаемого результата. Работайте в направлении результата, вместо того чтобы отворачиваться от проблемы. Экспериментируйте со следующими базовыми правилами для командных решений: zz договоритесь, что каждый член команды будет действовать как ключевой оценщик; zz поощряйте открытые вопросы, а не просто заявления позиции; zz примите процесс принятия решений, который содержит определение хотя бы трех жизнеспособных вариантов, прежде чем выбор будет сделан; zz назначайте оппонента для поиска контраргументов; zz разбейте команды на маленькие группы для независимых дискуссий; zz запланируйте встречу «второго шанса», на которой можно пересмотреть решение. Кейнер С. Руководство фасилитатора. Как привести группу к принятию совместного решения.

1

Глава 11.  Совершенствование  385

Стадия функционирования (исполнения): синергия команды Фокус команды переключился на выполнение работы. Эффективность и производительность входят в распорядок дня. Члены команды связаны своей частью работы с остальной организацией. Они следуют знакомым, установленным процедурам принятия решений, устранения проблем и поддержания атмосферы совместной работы. Сейчас команда выполняет много работы. Команды на стадии функционирования превосходят ожидания. Они демонстрируют бо́льшую автономность, достигают более высоких результатов и развили способность принимать быстрые и высококачественные решения. Члены команды совместно добиваются бо́льших результатов, чем можно было бы ожидать при простом суммировании их отдельных усилий. Члены команды продолжают демонстрировать лояльность и взаимоподдержку, выражая при этом меньше эмоций по поводу сотрудничества и задач, чем на более ранних стадиях. Вы увидите следующее поведение: zz глубокое понимание личных и командных процессов; zz снижение потребности в фасилитативном коучинге. Такие коучи тратят больше времени на поддержание связей и урегулирование вопросов с остальной частью организации, чем на внутренние потребности команды; zz сотрудничество с учетом понимания сильных и слабых сторон членов команды; zz замечания наподобие «Мне не терпится поработать с этой командой», «Не могу дождаться, пока вернусь на работу», «Это моя самая лучшая работа» и «Как мы можем добиться еще большего успеха?»; zz уверенность друг в друге и вера в то, что каждый член команды вносит свой вклад в достижение целей команды; zz предотвращение или проработка проблем и деструктивных конфликтов. Люди, работавшие в командах, находящихся на стадии функционирования, навсегда запоминают этот свой опыт. У них есть истории об ощущении тесной связи со своими коллегами. Если команда проводит много времени на стадии функционирования, то члены команды могут очень эмоционально относиться к потенциальной возможности расформирования или реорганизации команды. Команды на стадии функционирования находятся на пике командного развития, однако им все еще необходимо учиться успешно работать с людьми, не входящими в команду. Вдобавок они не застрахованы от возвращения на предыдущие стадии. Изменения в составе команды могут нарушить равновесие, равно как и значительные организационные изменения и нарушения установленных рабочих привычек. И всегда есть возможности для дальнейшего совершенствования. Продолжайте учиться, расти и развиваться.

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

386  Часть II.  Фокус на ценность командой вместе, и которые помогают членам команды отправиться дальше, к новым свершениям.

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

Рис. 11.1. Модель командной коммуникации Ларсен

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

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

См. также Согласование (глава 7) Безопасность (глава 7)

Глава 11.  Совершенствование  387

Поддержите растущее доверие с помощью тройного обязательства Основываясь на доверии, ваша команда начнет См. также исследовать тройную природу командного обязательства: Цель (глава 7) zz приверженность цели команды; zz приверженность благополучию друг друга; zz приверженность благополучию команды в целом. Занесение в устав цели и соглашений поможет в построении этих обязательств. По мере укрепления приверженности доверие будет продолжать расти. Вместе с ним будет расти и чувство психологической безопасности. Когда приверженность и доверие начнут улучшать психологическую безопасность, наступает подходящее время для изучения движущих сил в команде. Какой бы равноправной ни была ваша команда, расстановка сил всегда существует. Это часть человеческой природы. Если не обращать на нее внимания или не решать, то расстановка сил может стать разрушительной. Лучше держать ее на виду, чтобы команда могла попытаться ее выровнять. Источники расстановки сил — в индивидуальном восприятии влияния друг на друга, способности добиваться результата и предпочтений в отношениях. Вынесите все это на открытое обсуждение, обсудив расстановку сил, имеющуюся в команде, и ее влияние на сотрудничество. Обсудите, как силы команды и отдельных ее участников могут быть использованы на благо всей команды.

Разумные конфликты с обратной связью Чем больше членов команды ощущают поддержку друг друга, тем больше адаптируются к конфликтам. Вместо позиции «ты против меня» люди начинают подходить к конфликтам с позиции «мы против проблемы». Сфокусируйтесь на развитии способности членов команды давать и получать обратную связь, как описано в пункте «Научитесь давать и получать обратную связь» главы 7. Подходите к обратной связи, преследуя такие цели: zz обратная связь, которую мы даем и получаем, — конструктивная и полезная; zz наша обратная связь — бережная и уважительная; zz обратная связь — неотъемлемая часть нашей работы; zz никто не удивляется обратной связи; мы ждем четко выраженного согласия, прежде чем давать обратную связь; zz мы даем обратную связь, чтобы поощрить какое-либо поведение, а также чтобы предотвратить или изменить поведение. Обратная связь между членами команды, находящимися на одном уровне, помогает справляться с межличностными конфликтами, пока они еще малы. Неудовлетворенное скрытое недовольство может перерасти в огромное недоверие. Навыки, которые члены команды развивают для обратной связи внутри команды, помогут им и в более крупных конфликтах с внешними силами.

388  Часть II.  Фокус на ценность

Искра креативности и инновационности Что такое инновация команды, если не столкновение идей, порождающее новый потенциал? Поддержание здоровых рабочих отношений в момент яростных споров — это командный навык. Он возникает из способности вступать в конфликты и перенаправлять их в сторону желаемого результата. Он стимулирует увеличение инновационности и креативности. Способность команды решать проблемы резко возрастает. Развивайте креативность команды, предлагая обучающие задачи и игровой подход. См. также Встройте их в ежедневную рутину команды. Ретроспективы (глава 11) Используйте резерв времени для изучения новых технологий, как описано в пункте «Посвящать время исследованиям и экспериментам» главы 9. Экспериментируйте с новыми идеями во время ретроспектив. Создайте условия для бесполезных причуд и проявления изобретательности (научите друг друга жонглированию!).

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

Совместное лидерство Мэри Паркер Фоллетт, эксперт в менеджменте, также известная как «мать современного менеджмента», была пионером в области организационной теории и поведения. Рассуждая о роли лидерства, она писала: «Мне кажется, несмотря на то что власть обычно означает власть “над” (власть одного человека или группы над другим человеком или группой), можно развить концепцию власти “с”: совместно развиваемой власти, действующей совместно, а не принудительно… И лидер, и его последователи следуют за незримым лидером — общей целью» [Graham1995] (с. 103, 172). Мэри Паркер Фоллетт

Эффективные Agile-команды развивают «власть с» среди членов команды. Они делят между собой лидерство (см. врезку «Самоорганизующиеся команды» в главе 7). Благодаря этому они получают максимум от своего сотрудничества и навыков всей команды.

См. также Вся команда (глава 7)

Глава 11.  Совершенствование  389

Мэри Паркер Фоллетт описывала «закон ситуации», в котором выступала за следование за человеком, лучше всего знающим ситуацию. Именно так должны функционировать Agile-команды. Это значит, что любой член команды может быть выдвинут на роль лидера. Каждый может быть лидером в одних ситуациях и подчиняться коллеге-лидеру — в других. Члены команды могут играть разнообразные лидерские роли, как показано в табл. 11.11. Люди могут играть множество ролей, а также переключаться между ними по желанию, и несколько человек могут выступать в одной и той же роли. Важный момент — это охват. Командам необходимо, чтобы ее члены занимали все эти роли. Таблица 11.1. Лидерские роли Ориентированный на выполнение задач

Ориентированный на сотрудничество

Направление

Пионер, инструктор

Дипломат, инфлюэнсер, последователь

Наставление

Комментатор, координатор

Промоутер, миротворец

Оценка

Критик, привратник, оппонент

Рецензент, наблюдатель

zz

Пионеры (направление, ориентированное на выполнение задач) задают вопросы и ищут данные. Они исследуют, что будет дальше, ищут новые подходы и приносят в команду новые идеи.

zz

Инструкторы (направление, ориентированное на выполнение задач) отвечают на вопросы, предоставляют данные и обучают остальных навыкам, ориентированным на решение задач. Они связывают команду с источниками информации.

zz

Дипломаты (направление, ориентированное на сотрудничество) связывают команду с людьми и группами за ее пределами, действуют как связующее звено и представляют команду на внешних совещаниях.

zz

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

zz

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

zz

Комментаторы (наставление, ориентированное на выполнение задач) объясняют и анализируют данные. Они добавляют информацию в контекст.

За исключением дипломатов, эти роли были разработаны Дианой Ларсен и Эстер Дерби, основываясь на [Benne1948].

1

390  Часть II.  Фокус на ценность zz

Координаторы (наставление, ориентированное на выполнение задач) связывают воедино направления работы таким образом, чтобы это имело смысл. Они объединяют и интегрируют данные и согласовывают действия команды с задачами.

zz

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

zz

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

zz

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

zz

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

zz

Оппоненты (оценка, ориентированная на решение задач) защищают команду от группового мышления, преднамеренно ища альтернативные точки зрения и выступая против привычного мышления. Они также проверяют решения команды на соответствие командным ценностям и принципам.

zz

Рецензенты (оценка, ориентированная на сотрудничество) гарантируют, что команда соответствует критериям приемлемости и реагирует на потребности заказчиков.

zz

Наблюдатели (оценка, ориентированная на сотрудничество) следят за тем, как вся команда работает вместе. (Хорошо или плохо работают члены команды?) Они оберегают психологическую безопасность команды и способствуют укреп­ лению здоровых рабочих взаимоотношений между ее членами.

То, что в этот список роль последователя входит как лидерская, может показаться странным, однако Последователь — особенно активное подчинение лидерству других помогает важная роль для тех членам команды учиться делиться руководящими людей, от кого ожидают лидерства. обязанностями. Это особенно важная роль для тех людей, от кого ожидают лидерства, таких как старшие члены команды. Команды, разделяющие друг с другом лидерство в соответствии с этими ролями, можно назвать командами лидеров (leaderful teams). Чтобы стать такой командой, обсудите вместе эти лидерские роли. Лучше всего делать это, когда вы замечаете неравномерность участия членов команды или чрезмерную зависимость от одного человека при принятии решений. Покажите всем список ролей и задайте следующие вопросы: zz

Сколько лидерских ролей каждый из членов команды естественным образом берет на себя?

Глава 11.  Совершенствование  391 zz

Не перегружен ли кто-нибудь лидерскими ролями? Или выполняет роль, которая ему не нравится?

zz

Какой из этих ролей нужно несколько человек? (Например, роль оппонента лучше распределять между несколькими членами команды.)

zz

Какой роли не хватает в нашей команде? Каковы последствия отсутствия коголибо в этой роли?

zz

Как мы можем заполнить недостающие роли? Кто хочет попрактиковаться в этом аспекте руководства?

zz

Что еще мы заметили касательно этих ролей?

Сфокусируйте членов команды на выборе способа, с помощью которого они будут обеспечивать эффективное сотрудничество, с учетом охвата лидерских ролей. Будьте готовы к созданию новых рабочих соглашений в результате этого обсуждения. Некоторые члены команды могут быть оппонентами от природы, но если они будут играть эту роль постоянно, то остальная часть команды может со временем попасть в ловушку обесценивания их комментариев. «О, не обращайте внимания. Ли всегда ищет самые мрачные, самые пессимистичные стороны во всем!» Необходимо обеспечить возможность передавать роль оппонента разным членам команды. Так она будет оставаться эффективной.

Токсичное поведение Токсичное поведение — это любое поведение, которое создает нездоровую и небезопасную атмосферу, снижает динамики команды или нарушает способность команды достичь ее цели. Если член команды демонстрирует токсичное поведение, то начните с напоминания Первой директивы ретроспективы: «Независимо от того, что мы обнаружим, мы должны понимать и искренне верить, что каждый делал свою работу наилучшим образом, в соответствии с тем, что было известно на тот момент, его или ее навыками и возможностями, доступными ресурсами и сложившейся ситуацией» [Kerth2001] (гл. 1). Предполагайте, что человек делает все наилучшим из возможных для него способов. Сначала ищите проблемы, связанные с давлением окружающей среды. Например, кто-то из членов команды не высыпается, поскольку у него родился ребенок. Или новый член команды может один отвечать за жизненно важную систему, с которой еще не очень хорошо знаком. Все вместе члены команды могут внести коррективы, которые помогут людям улучшить свое поведение. Например, договорившись перенести утренние стендапы, чтобы молодой родитель мог приходить попозже, или разделив ответственность за функционирование важной системы с кем-то еще. Следующий шаг — давать обратную связь данному человеку. Используйте процесс, описанный в пункте «Научитесь давать и получать обратную связь» главы 7, чтобы описать последствия такого поведения и попросить изменить его. Очень часто этого оказывается достаточно. Люди просто не осознавали, как их поведение влияет на команду, и будут вести себя иначе.

392  Часть II.  Фокус на ценность Иногда команды могут называть коллег Будьте осторожны, чтобы токсичными, хотя те на самом деле не деошибочно не посчитать оппонентов лают ничего плохого. Это легко может токсичными. случиться с людьми, которые часто берут на себя лидерскую роль оппонента. Они не соглашаются с идеями остальной команды или видят риск или препятствие, не ­замеченные другими, и не дают идее ход. Будьте осторожны, чтобы ошибочно не посчитать оппонентов токсичными. Они позволяют командам избежать группового мышления. Однако может иметь смысл обсудить возможность ротации этой роли. Если человек действительно демонстрирует токсичное поведение, то может См. также игнорировать замечания и обратную связь Безопасность (глава 7) от команды или отказываться подстраиваться под потребности психологической безопасности команды. Если это случается, то такие люди перестают быть полезны команде. Иногда это просто личностное несовпадение, и им будет хорошо в другой команде. В этот момент приходит время вмешаться вашему руководителю или тому, кто отвечает за назначение людей в команду. Объясните ситуацию. Хорошие руководители понимают, что продуктивность каждого члена команды зависит от всех остальных участников. Эффективный лидер вступится, чтобы помочь команде. Чтобы он мог сделать это, члены команды должны проинформировать его о том, что им нужно, а также о тех шагах, которые они уже предприняли, чтобы изменить поведение. Некоторые руководители могут сопротивляться удалению человека из команды, особенно если видят в этом человеке «суперзвезду». Вместо этого они могут предлагать команде приспособиться к его поведению. К сожалению, это вредит производительности команды в целом. По иронии судьбы это может еще больше усилить позиции «суперзвезды», так как этот человек подавляет окружающих. В этой ситуации вы можете только решить сами для себя, стоит ли терпеть токсичное поведение ради преимуществ, которые дает участие в этой команде. Если нет, то лучшим вариантом для вас будет перейти в другую команду или организацию.

Вопросы Разве не важно команде иметь одного лидера? Как это работает с командами лидеров? Наличие единственного лидера позволяет упростить комплексную проблему, но этот способ не так уж и удобен для самого человека в этой роли. Это также противоречит Agile-идеалу коллективного владения (см. врезку «Коллективное владение» в главе 9). Вся команда несет ответственность. Нет козла отпущения, который возьмет на себя ответственность, если все пойдет не так, или того, кто получит все награды, если все будет хорошо, поскольку успех и провал — результат сложного взаимодействия множества участников и факторов. Вклад каждого члена команды критически важен.

Глава 11.  Совершенствование  393

Это не просто абстрактная философия. Команды лидеров лучше делают свою работу и быстрее становятся высокопроизводительными. Совместное лидерство способствует формированию более сильных команд. Что, если у меня нет навыков, которые позволят улучшить динамики команды? Если вам некомфортно работать над навыками командной работы, это нормально. Вы все же можете помочь. Следите за коллегами, которые берут на себя лидерские роли, ориентированные на взаимодействие. Делайте все, что поддержит их усилия. Если в вашей команде нет людей, желающих взять на себя эти роли, то поговорите с вашим руководителем или спонсором о предоставлении коуча или другого члена команды, имеющего опыт в области динамик команды (см. подраздел «Навыки коучинга» главы 7).

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

См. также Энергичная работа (глава 7) Вся команда (глава 7) Командная комната (глава 7) Менеджмент (глава 10)

Показатели Когда у вашей команды здоровые динамики: zz

члены команды с удовольствием приходят на работу;

zz

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

zz

члены команды верят, что каждый в команде стремится к достижению ее цели;

zz

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

zz

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

394  Часть II.  Фокус на ценность чтения». И даже это — капля в море. Спросите у наставника, что он может порекомендовать. Продолжайте учиться и экспериментировать. Это дорога длиною в жизнь.

Литература для дополнительного чтения Кит Сойер сделал карьеру на изучении креативности, инновационности и импровизации и их корней в эффективном сотрудничестве. В Group Genius: The Creative Power of Collaboration [Sawyer2017] он предлагает познавательные истории и идеи. Роджер Ниренберг написал мемуары и руководство для лидеров: Maestro: A Sur­ prising Story about Leading by Listening [Nierenberg2009]. Эта книга внесла свой вклад в нестандартные способы размышлений о лидерстве. У автора также есть сайт с видео, в которых демонстрируются его техники: http://www.musicparadigm.com/videos/. The Wisdom of Teams: Creating the High-Performance Organization [Katzen­ back2015] — классическая, базовая книга о высокопроизводительных командах, их характеристиках и среде, способствующей их процветанию. Shared Leadership: Reframing the Hows and Whys of Leadership [Pearce2002] — сборник лучших идей о многолидерских командах и организациях. Он может быть сложным для чтения, но его стоит изучить, чтобы расширить свои представления о том, кто такой и что такое лидер.

УСТРАНЕНИЕ ПРЕПЯТСТВИЙ Диана Ларсен Мы решаем проблемы, которые замедляют нашу работу.

Аудитория Вся команда

Препятствия. Преграды. Затруднения, барьеры, помехи, загвоздки, угрожающие риски (также известные как надвигающиеся препятствия). Все эти слова описывают проблемы, которые могут подорвать производительность команды. Они могут быть очевидными: «Сеть не работает». Они могут быть неявными: «Мы неправильно поняли потребности заказчика и должны начать все сначала». А могут быть и такими: «Мы застряли!» Есть препятствия, которые на первый взгляд не видны. Есть такие, которые вырастают из сложных ситуаций. Одни препятствия являются симптомами более крупных проблем, а другие имеют не одну причину и похожи на многоголовую гидру. Некоторые препятствия являют собой непреодолимую силу, наподобие плохой погоды, и отягощены стоящими за ними культурой и традициями. А некоторые, наиболее ценные, находятся под вашим контролем и легкоразрешимы. Независимо от источника препятствия мешают команде и могут даже полностью остановить ее прогресс. Устранение препятствий возвращает команду в нужное русло. Некоторые члены команды ожидают, что люди с лидерскими званиями возьмут на себя Устранение препятствий — устранение препятствий, но устранение преэто ответственность команды. пятствий — это ответственность команды.

Глава 11.  Совершенствование  395

Не ждите, что ваш коуч или руководитель заметят и разберутся с препятствиями, мешающими команде. Позаботьтесь об этом сами. Точно так же некоторые команды создают доСм. также ски со списком препятствий или рис­ков, чтобы отслеживать все, что стоит на их пути. Я не реСтендап-митинги (глава 9) комендую так делать. Вместо этого устраняйте препятствия, как только заметите их. Вынесите Ретроспективы (глава 11) их на обсуждение на следующем стендапе, ретроПланирование задач (глава 9) спективе или сессии планирования задач и решите, как будете преодолевать каждое из них.

Выявление препятствий Чтобы устранить препятствия, вы должны сначала их выявить. Задайте следующие вопросы: zz Что нас замедляет? zz Что нам нужно из того, чего у нас еще нет? zz Где бы мы могли продемонстрировать больший прогресс, если бы не ...? zz Что нас останавливает или удерживает от ...? zz Что постоянно способствует появлению дефектов? zz Какие навыки нам нужны, которых у нас еще нет? Если ваша команда не может добиться прогресса, но, кажется, на ее пути нет никаких препятствий, то положитесь на список Уильяма Ларсена под названием TRIPE (Tools, Resources, Interactions, Processes and Environment): инструменты, ресурсы, взаимодействия, процессы и среда [Larsen2021]. Добавьте каждую из категорий в предыдущий список: какие инструменты нас замедляют? Какие ресурсы нас замедляют? Какие взаимодействия нас замедляют? И т. д.

Круги и суп Что вам делать с препятствиями? Подумайте о них в терминах кругов и супа. Каждую команду окружает сравнительно небольшой круг вещей, которые она может контролировать, и более широкий круг вещей, на которые она только влияет. За границами этих кругов находится суп: неизменные факты существования вашей команды. Суп нельзя изменить, и на него нельзя оказать какого-либо влияния. Все, что вы можете сделать, — это изменить реакцию на него вашей команды. Следующий вид активности, основанный на [Larsen2010], использует эту идею, чтобы помочь команде решить, как реагировать на препятствия. Шаг 1. Используйте одновременный мозговой штурм (см. пункт «Работайте одновременно» главы 7) для выявления действий, которые улучшат способность вашей команды выполнять свою работу. Запишите каждый пункт на отдельный стикер, физический или виртуальный. Шаг 2. Нарисуйте три концентрических круга на доске (рис. 11.2). Оставьте место для стикеров в каждом круге.

396  Часть II.  Фокус на ценность

Рис. 11.2. Круги и суп

Шаг 3. Работая одновременно, распределите стикеры по категориям следующим образом: zz команда контролирует — команда может самостоятельно выполнять эти действия; zz команда влияет — команда может рекомендовать изменения или убедить другую сторону помочь; zz суп — команда не контролирует и имеет слабую возможность повлиять. Шаг 4. Выберите пункт из одного из кругов, наСм. также чиная с внутреннего, и создайте для него задачи. Повторите при необходимости. Планирование задач Всегда заканчивайте вопросом: «Что еще мы мо(глава 9) жем сделать, чтобы предотвратить появление этого препятствия на нашем пути в будущем?»

Контроль: прямые действия Во время ежедневного стендапа двое участников команды сообщили о препятствии: «Нам нужна помощь. Бизнес-правила в этой истории для нас выглядят бессмысленными». Другой член команды сказал: «Я видел это раньше». После встречи несколько человек, знакомых с проблемой, собрались вместе, чтобы прояснить то, что непонятно. Они также обсудили способы, позволяющие избежать подобного недопонимания в будущем. Во время короткой ретроспективы перед перерывом команда группового программирования, работающая удаленно, обсуждала недавно появившийся фоновый шум. Он сильно мешал слышать друг друга. Потом один из членов команды вступил в разговор: «Это мой вентилятор! Я не заметил, что он направлен на мой микрофон». Он повернул вентилятор, и мешающий фоновый шум прекратился. Когда решение, устраняющее препятствия, находится под контролем вашей команды, предпримите прямые действия для его устранения.

Глава 11.  Совершенствование  397

Влияние: убедить или рекомендовать Во время еженедельной ретроспективы команда перечислила неясные бизнес-правила в качестве текущего препятствия. Затем она записала конкретные примеры того, когда похожие проблемы случались в прошлом, и сформулировала решение «улучшить доступ к экспертам в предметной области» как наиболее предпочтительное. Один из старших инженеров вызвался показать примеры одному из ключевых стейкхолдеров команды, чтобы они вместе смогли найти решение. Когда ваша команда не может контролировать решение См. также по устранению препятствия, а ваши стейкхолдеры могут, попросите их помочь вам. Контекст (глава 7) Эффективность влияющих действий зависит от степени понимания ваших стейкхолдеров. Если вы внесли контекст в ваш устав, то у вас должна быть контекстная диаграмма, показывающая группы ваших стейкхолдеров (см. пункт «Границы и взаимодействия» главы 7). Напомним: стейкхолдеры вашей команды — это все, кто влияет на ее работу, или те, на кого влияет работа команды. Чтобы лучше понимать, как влиять на ваших стейкхолдеров, создайте таблицу обязательств стейкхолдеров (рис. 11.3)1.

Рис. 11.3. Диаграмма обязательств стейкхолдеров

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

«Сделать так, чтобы это произошло» — стейкхолдер будет активно продвигать эти действия.

Диаграмма обязательств стейкхолдеров взята и адаптирована из [Beckhard1992].

1

398  Часть II.  Фокус на ценность Используйте таблицу следующим образом. 1. Ключевые стейкхолдеры. Перечислите имена ваших ключевых стейкхолдеров в первой колонке. Если стейкхолдер — это группа людей, то используйте в качестве ее названия имя вашего контактного лица в этой группе. 2. Требуемое обязательство. Обсудите степень обязательства, которое вашей команде необходимо получить от каждого из стейкхолдеров. Впишите «0» (для «целевого статуса») в соответствующей колонке. 3. Текущий статус. Определите степень обязательства каждого стейкхолдера по устранению препятствия. Это может потребовать участия членов команды, обладающих навыками дипломатии. Поставьте «Х» в соответствующей колонке. 4. Определить потребности. Когда Х (текущий статус) находится слева от 0 (требуемое обязательство), нарисуйте стрелку слева направо, чтобы их соединить. Таким образом команда узнает, кого они должны переместить. Если изменений получается много, то определите, с кем из стейкхолдеров работать в первую очередь. 5. Планировать стратегию. Всей командой решите, как вы будете влиять на каждого стейкхолдера, чтобы обеспечить необходимый вам уровень обязательства. Когда у вас будут нужные вам обязательства, вы можете просить стейкхолдеров, давших обязательства «Помочь этому произойти» и «Сделать так, чтобы это произошло», помочь вам с устранением препятствия.

Суп: измените вашу реакцию Проведя ежегодную оценку эффективности, команда с разочарованием узнала, что некоторые люди получили более высокий балл, чем другие, и соответственно более высокий бонус. Члены команды были расстроены, поскольку они были очень эффективной командой и каждый внес свой вклад в ее успех. Все попытки сделать ситуацию более справедливой провалились: оценка эффективности по баллам была общей политикой компании. Поэтому команда согласилась, что в следующем году тот, кто получит самый высокий бонус, устраивает вечеринку для всей команды. Это было не совсем то решение, которого бы все хотели, но оно превратило ситуацию, потенциально вызывающую распри, в событие, которого все ждут. Суп — это то, «как все устроено» в вашей организации. Он объединяет организационную культуру, бизнес-стратегию и бизнес-среду. Когда решение вашей проблемы с препятствием находится в «супе», вы можете только изменить свою реакцию на это. В любой сложной ситуации у нас есть три возможные реакции: изменить ситуа­ цию, изменить других или изменить себя. Суп нельзя изменить, а менять других непрактично, так что остается только один вариант. Измените себя. Признайте, что препятствие никуда не уйдет, поэтому сделайте встречу с ним более приемлемой, насколько это возможно. Встретившись с препятствием из «супа», ищите как минимум три способа реакции на него. Это может помочь выявить пять или десять разных реакций и отметить некоторые из них как безумные или полностью неприемлемые. Затем выберите из этих идей три наиболее приемлемые, из которых в итоге выберите одну, чтобы опробовать ее.

Глава 11.  Совершенствование  399

Вопросы Что, если член команды говорит, что нет никаких препятствий, но при этом мы не видим прогресса? Если кажется, что у кого-то из команды застопорилась работа, но он постоянно соСм. также общает, что препятствий нет, то вмешайтесь. Возможно, в его личной жизни происходят Безопасность (глава 7) какие-то события, которые отвлекают от рабоПарное программирование ты, и он может чувствовать себя слишком уяз(глава 12) вимым и не в безопасности, чтобы признать Групповое программирование это. Или он может действительно застрять на (глава 12) чем-то, но слишком привязан к своей задаче, чтобы просить помощи, желая разобраться самостоятельно. Запланируйте время, чтобы поговорить. Проявите сочувствие. Скажите о поведении, которое побуждает вас вмешаться. Это единственный способ, которым вы можете обнаружить препятствия, мешающие устранению препятствий. Обратите внимание члена команды на расхождение между его отчетами и результатами. Убедите его рассказать о проблеме. Подчеркните, что команда коллективно отвечает за работу (см. врезку «Коллективное владение» в главе 9) и просить помощи или передать задачу кому-то еще — совершенно нормально. Предотвратить эту проблему может помочь парное или групповое программирование. Что, если все наши препятствия возникают из-за других людей или команд? Всегда есть соблазн обвинить кого-то в своих проблемах, но поиски виноватых мешают вашей команде выбирать действия, помогающие контролировать проблему. Подумайте о том, как поведение вашей команды вносит свой вклад в проблему. Есть ли способы сделать что-то по-другому? Найдите часть динамики, которая может быть в вашей власти. Запланируйте межкомандный диалог с другими, чтобы изучить препятствие. (Вы можете попросить нейтральную сторону выступить посредником.) Объясните влияние на команду и ищите решение, удовлетворяющее обе стороны.

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

400  Часть II.  Фокус на ценность

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

Альтернативы и эксперименты Устранять препятствия в конечном счете нужно для того, чтобы помочь вашей команде стать более быстрой и эффективной. Не бойтесь экспериментировать. Например, концепция позитивного исследования (Appreciative Inquiry) меняет ситуацию. Вместо того чтобы фокусироваться на проблемах команды, ищите то, что наполняет ее энергией, и делайте это чаще. Отследите практики или события, благодаря которым команда прогрессирует. Анализируйте аспекты, в которых все идет хорошо, и изучайте, как команда может создать еще больше похожих преимуществ. Побочный эффект фокусировки на расширении сильных сторон команды — частое уменьшение количества проблем. Ката бережливого совершенствования (Lean Improvement kata) — еще один подход, фокусирующийся на долгосрочных препятствиях. Книга Джеспера Боэга Level Up Agile with Toyota Kata [Boeg2019] — руководство по этому подходу, ориентированное на программное обеспечение. Она особенно хорошо подходит для устранения препятствий, мешающих производству высококачественных продуктов.

Литература для дополнительного чтения The Little Book of Impediments [Perry2016] содержит подробное исследование того, как обнаруживать, отслеживать и ликвидировать препятствия; представлена в удобном формате электронной книги.

III НАДЕЖНАЯ ПОСТАВКА

Опять октябрь. Последний год (см. часть II) ваша команда много работала над развитием свободного владения навыками на уровне поставки и теперь являет собой слаженный механизм. Никогда вы не получали больше удовольствия от работы, чем сейчас: все мелкие раздражители и шероховатости, относящиеся к профессиональной разработке ПО (поврежденные сборки, утомительный поиск багов, тщательный анализ изменений), ушли в прошлое. Теперь вы можете начать задачу и уже через несколько часов увидеть ее в эксплуатационной среде. Вы жалеете только о том, что ваша команда свободно не владела навыками на уровне поставки с самого начала. Оглядываясь назад, можно сказать, что все было бы быстрее и проще, но люди хотели, чтобы все было медленно. Что ж, хорошо. Теперь вы знаете. Входя в командную комнату, вы видите Валери и Бо, работающих вместе за парной рабочей станцией. Они оба любят приходить пораньше, чтобы успеть до начала часа пик. Валери видит, что вы снимаете свой рюкзак, и привлекает ваше внимание. — Сможешь поработать в паре сегодня утром? — спрашивает она. Она всегда немногословна. — Мы с Бо работаем над обновлениями в реальном времени, и он сказал, что у тебя могут быть идеи, как тестировать сетевой код. Вы киваете: — Мы с Дунканом вчера включили это в спайк и нашли кое-что многообещающее. Хочешь поработать в паре или можем втроем организовать мини-группу? — Можешь поработать в паре с Валери, — Бо встает и потягивается. — Мне нужно сделать перерыв после сетевого кода. — Он притворно вздрагивает. — Даже CSS лучше, чем это. Валери закатывает глаза и качает головой. — Устраивайся, — говорит она вам. — Я пока налью себе еще кофе. Через полчаса вы с Валери уже достигли неплохого прогресса с сетевым кодом. Каждый раз, когда вы сохраняете изменения, дежурный скрипт запускает ваши

402  Часть III.  Надежная поставка тесты, а затем, секунду спустя, позвякивает, сообщая, как прошел тест: успешно или нет. Вы вошли в устойчивый ритм. В данный момент вы — водитель, а Валери — штурман. «Хорошо, теперь давай сделаем так, чтобы выдавалась ошибка, если сообщение пустое», — говорит она. Вы добавляете тест. Донг! Тест не прошел. Не останавливаясь, вы переключаетесь на промышленный код, добавляете оператор if и сохраняете изменение. Дзинь! Тест проходит. «А теперь, когда сообщение повреждено, — говорит Валери, — вы добавляете строку к тесту». Донг! Еще один оператор if. Дзинь! «Окей, у меня есть несколько заметок и о других пограничных случаях, — говорит Валери. — Но я думаю, сначала нам нужно вычистить эти if. Исключение метода validateMessage() должно помочь». Вы киваете, выделяете код и нажимаете клавишу Extract Method. Дзинь! Никаких проблем! Эти звуки — результат эксперимента, проведенного несколько месяцев назад. Несмотря на шутки о «программистах Павлова», они стали хитом. Ваша команда работает такими маленькими шагами, что бо́льшую часть времени код делает именно то, что вы от него ожидаете. Тесты ваших инкрементов занимают меньше секунды, так что звуки служат мгновенной обратной связью. Вам всего лишь нужно взглянуть на исполнителя тестов (test runner), когда что-то идет не так. Остальное время вы остаетесь в области работы, переключаясь между тестами, кодом и рефакторингом, а перезвон подтверждает, что все в порядке и под контролем. Еще через полчаса сетевые изменения сделаны. Вы потягиваетесь, пока Валери извлекает последний код из интеграционной ветки и запускает полный набор тестов. Через минуту он проходит, и она запускает скрипт развертывания. «Готово! — говорит она. — Пора выпить еще кофе, последишь за развертыванием?» Вы снова устраиваетесь в кресле и наблюдаете, как выполняется скрипт развертывания. Он тестирует ваш код на отдельной машине, затем сливает его в общую интеграционную ветку. Все в команде сливают свой код из нее и в нее каждые несколько часов. Это позволяет поддерживать синхронизацию команды и разрешать конфликты при слиянии на раннем этапе, до того как это превратится в проблему. Затем скрипт развертывает код на канареечном производственном сервере. Через несколько минут развертывание подтверждено, и скрипт помечает ваш репозиторий как успешный. Вы неспешно идете к доске задач и отмечаете сетевую задачу зеленым. «Все сделано, Бо! — зовете вы. — Готов заняться CSS?»

ДОБРО ПОЖАЛОВАТЬ НА УРОВЕНЬ ПОСТАВКИ Свободное владение навыками на уровне поставки нужно командам, которые Свободное владение навыками на уровне поставки нужно командам, которые хотят надежно поставлять ПО. Члены хотят надежно поставлять ПО. команды развивают свои технические навыки, чтобы их ПО требовало мало обслуживания, его было легко улучшать и развертывать и чтобы оно содержало минимум багов. В частности, команды, которые владеют навыками в поставке1: Эти списки получены из [Shore2018b].

1

Часть III.  Надежная поставка  403

выпускают свою последнюю работу с минимальным риском и затратами, когда бы их бизнес-стейкхолдеры этого ни пожелали; zz обнаруживают и исправляют недостатки в производственном жизненном цикле на раннем этапе, прежде чем те смогут навредить; zz способны предоставлять полезные прогнозы; zz имеют низкий уровень дефектов, поэтому тратят меньше времени на исправление багов и больше — на создание функциональностей; zz создают ПО с хорошим внутренним качеством, что удешевляет и ускоряет процесс изменений; zz имеют высокую удовлетворенность работой и моральный дух, что улучшает продуктивность и способствует удержанию сотрудников в команде. Чтобы достичь этого, команды должны развить определенные навыки. Для этого нужны инвестиции, описанные в главе 4. Команда отвечает требованиям бизнеса: zz качество написанного ею кода соответствует промышленному уровню, и последняя работа развертывается в среду, эквивалентную эксплуатационной, по меньшей мере ежедневно; zz представитель бизнеса в команде может делать релиз последней работы команды по желанию в любой момент; zz команда предоставляет полезные прогнозы своих релизов представителям бизнеса по запросу; zz команда координируется со своими бизнес-стейкхолдерами, чтобы выработать способ, позволяющий сопровождать ее ПО недорого и сколь угодно долго. Команда эффективно работает как команда: zz разработчики рассматривают код и другие подобные артефакты как принадлежащие всей команде, а не отдельным лицам, и разделяют ответственность за их изменение и улучшение; zz все повседневные навыки, необходимые для дизайна, разработки, тестирования, развертывания, мониторинга, технического обслуживания и т. д., вся командная работа доступны участникам в любой момент. Команда стремится к техническому совершенству: zz каждый раз, внося изменения в свое ПО, члены команды оставляют его внутреннее качество в несколько лучшем состоянии, чем оно было до их вмешательства; zz команда активно реагирует на ошибки, улучшая систему, допустившую ошибку, снижая вероятность ошибок в будущем; zz развертывание и релиз автоматизированы и требуют не больше 10 минут ручного труда; zz перед развертыванием ручное тестирование не требуется; zz члены команды знают, как их навыки влияют на их способность достичь целей команды и улучшить внутреннее качество, и проактивно стараются улучшить эти навыки. zz

404  Часть III.  Надежная поставка

ДОСТИЖЕНИЕ СВОБОДНОГО ВЛАДЕНИЯ НАВЫКАМИ НА УРОВНЕ ПОСТАВКИ Практики в этой части книги помогут вашей команде достичь свободного владения навыками на уровне поставки. По большей части они сосредоточены вокруг одновременных фаз. Большинство команд, даже Agile-команд, используют подход к разработке, основанный на фазах. Они могут работать итерациями, но внутри каждой из них следуют фазовому подходу в анализе требований, дизайна, написания кода, тестирования и развертывания (части А и Б на рис. III.1). Даже команды, использующие непрерывный поток, склонны разрабатывать каждую историю с помощью серий фаз, используя визуализацию обзорных полос для отслеживания прогресса.

Рис. III.1. Жизненные циклы разработки ПО

Часть III.  Надежная поставка  405

Но Agile по своей сути итеративный и инкрементный (поэтапный) подход. Каждая история занимает всего лишь день или два работы. Этого недостаточно для высококачественных фаз. На практике дизайн и тестирование обделяют вниманием. Качество кода со временем деградирует, командам трудно разобраться, как планировать необходимые работы по дизайну и инфраструктуре, и у них не хватает времени на тестирование и устранение багов. Чтобы избежать этих проблем, экстремальное программирование ввело техники, позволяющие разработке программ быть действительно инкрементной. Вместо того чтобы работать по фазам, команды XP работают над всеми аспектами разработки инкрементно и непрерывно (часть В рис. III.1). Несмотря на то что экстремальное программирование появилось в далеких 1990-х, его методы тестирования, кодирования и дизайна остаются самыми современными. Они дают самый высококачественный, самый продуктивный код из того, что я когдалибо видел. В последнее время движение DevOps расширило их, чтобы поддержать соСм. также временное развертывание на облачной основе. В сочетании с поэтапным планированием инАдаптивное планирование (глава 8) крементов и анализом требований эти техниИнкрементные требования (глава 8) ки позволяют командам регулярно и надежно поставлять высококачественное ПО. Практики в этой части основаны на XP. Если вы будете применять их вдумчиво и строго, то достигнете свободного владения навыками на уровне поставки. Практики сгруппированы в пять глав: zz в главе 12 описывается, как создавать ПО командой; zz в главе 13 показаны инкрементные сборка, тестирование и автоматизация; zz в главе 14 описывается, как делать инкрементный дизайн кода; zz в главе 15 рассказывается, как развертывать ПО надежно и в любой момент по своему усмотрению; zz в главе 16 описывается, как создавать ПО, которое будет делать то, что должно делать.

ГЛАВА 12

Сотрудничество

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

Практика «Коллективное владение кодом» поощряет членов команды улучшать код друг друга.

zz

Практика «Парное программирование» способствует перекрестному опылению идей и помогает членам команды понимать работу друг друга.

zz

С помощью практики «Групповое программирование» ваша команда объединяется для совместной работы.

zz

Практика «Единый язык» помогает членам команды понимать друг друга.

Источники сотрудничества Как это обычно бывает на уровне поставки, большинство практик в этой главе ведут свою родословную от XP1. Практики «Коллективное владение кодом» и «Парное программирование» пришли напрямую из XP. Групповое программирование — разновидность парного программирования. Вуди Зуилл формализовал его в качестве практики, основываясь на собственном опыте его применения с одной из команд в Hunter Industries. Первоначально Вуди называл эту практику «Программирование всей командой» (Whole Team programming), но он использовал название «Групповое программирование» для похожей активности (из [Hohman2002]), и это название прижилось. Групповое программирование также известно как программирование в ансамбле (ensemble programming).

1

Влияние экстремального программирования простирается, конечно, еще дальше. Один из наиболее заслуживающих внимания предшественников — язык шаблонов Уорда Каннингема EPISODES [Cunningham1995], включающий множество идей, в том числе парное программирование, которые позже перешли в XP.

Глава 12.  Сотрудничество   407

Я впервые услышал о едином языке от Джошуа Кериевски, который включил его в свой метод промышленного XP [Kerievsky2005]. Единый язык заменил практику XP «Метафора», которая не очень хорошо работала и в результате была удалена из второй редакции книги по XP. Я совершенно уверен, что Кериевски вдохновила прекрасная книга Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software [Evans2003]. Она же легла в основу моих рассуждений.

КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ КОДОМ Мы все вместе отвечаем за весь наш код.

Аудитория

Agile-команды совместно управляют своей работой, Разработчики как описывается во врезке «Коллективное владение» в главе 9. Но как это применимо в отношении кода? Коллективное владение кодом означает, что команда разделяет ответственность за свой код. Вместо того чтобы назначать ответственных за модули, классы или истории отдельных людей, команда владеет всем этим целиком. Это право и ответственность вносить улучшения в любой аспект командного кода в любое время. Фактически улучшенное качество кода — Исправляйте проблемы одно из скрытых преимуществ коллективнонезависимо от того, го владения кодом. Коллективное владение где вы их нашли. подразумевает (нет, ожидает), что каждый исправляет проблемы, которые находит. Если вы обнаружили дублирование, непонятные названия, плохую автоматизацию или даже код с плохим дизайном — неважно, кто его написал. Это ваш код. Исправьте его!

Как заставить коллективное владение работать Коллективное владение кодом требует тщаСм. также тельной координации в вопросах дизайна и планирования. Если вы используете групГрупповое программирование повое программирование, эта координация (глава 12) достается вам даром. В других случаях начать Планирование задач (глава 9) обсуждение можно на встрече по планированию задач. Когда вы будете обсуждать, как разбивать задачи, поговорите о дизайне. Записывайте задачи в терминах того, как изменится дизайн: «Добавить конечную точку (endpoint) к UserReportController», «Обновить ContactRecord», «Добавить колонки в таблицу базы данных GdprConsent». Когда будете готовы к новой задаче, вы можете выбрать любую задачу с доски планирования. В большинстве случаев вы просто возьмете следующую из списка,

408  Часть III.  Надежная поставка но можно и перескочить немного вперед См. также и выбрать задачу, которая вам интересна или хорошо соответствует вашим знаниям. Сделано Сделано (глава 9) В идеальном мире ваша команда будет фокусироваться на каждой истории: все будут выбирать задачи, принадлежащие одной и той же истории, и стремиться перевести ее в состояние «Сделано Сделано», прежде чем переходить к следующей. Это позволяет минимизировать объем невыполненной работы (см. врезку «Минимизируйте объем незавершенной работы» в главе 8) и рано выявлять риски. На практике это нормально, когда люди Не переходите к другой истории переходят к следующей истории, когда текутолько потому, что не знаете, щая близка к завершению. Но будьте остокак скоординироваться. рожны: когда вы новичок в коллективном владении, легко случайно прийти к тому, что каждый фактически будет владеть отдельными историями, вместо того чтобы действительно работать всем вместе. Не переходите к другой истории только потому, что не знаете, как скоординироваться. Когда вы беретесь за задачу, имеющую близкое отношение к другому человеку или паре, кратко обсудите ее с ними. Возможно, они взялись за фронтенд-задачу, а вы — за соответствующую бэкенд-задачу. Потратьте время на то, чтобы прийти к единому пониманию API. Кто-то один из вас или оба могут сделать в API заглушку из ничего не выполняющего кода, а затем один из вас может заполнить ее. Человек, который делает коммит своего кода вторым, отвечает за дополнительную проверку того, что все собранное воедино работает. В процессе работы над кодом у вас будут См. также возникать новые идеи, влияющие на работу других людей. Парное программирование Парное программирование (глава 12) поможет распространить эти идеи по всей команде. Вы также можете использовать ежедневные стендапы для того, чтобы изложить новые идеи. Если вы не используете парное или групповое программирование, то вам может понадобиться добавить ежедневные обзоры дизайна. Некоторые идеи заслуживают немедленного обсуждения. В физической командной комнате просто встаньте и объявите, о чем хотите поговорить. Люди подойдут к вам. В виртуальной команде объявите тему в командном групповом чате и пригласите людей присоединиться к вам в режиме видеозвонка. Больше информации вы можете найти в пункте «Легко входите в дискуссии и выходите из них» главы 7.

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

Глава 12.  Сотрудничество   409

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

Сотрудничество без конфликтов Поначалу коллективное владение кодом несет в себе возможности для конфликта. Все мелкие раздражители, связанные со стилем работы ваших коллег, усиливаются и подчеркиваются ярчайшим образом. Это хорошо (на самом деле хорошо!), поскольку дает вам шанс выровнять ваши стили. Но поначалу это может быть неприятным. Чтобы помочь процессу пройти гладко, определитесь с важными стандартами кода, См. также дизайна, архитектуры в ходе вашей сессии Согласование (глава 7) согласования устава. Когда вы впервые принимаете коллективное владение кодом, поГрупповое программирование пробуйте групповое программирование в те(глава 12) чение недели или двух, чтобы прояснить все Ретроспективы (глава 11) важные различия. Поднимайте вопросы о разДинамики команды (глава 11) ногласиях во время ретроспектив и предлагайте планы их решения. Уделяйте внимание динамикам команды. Если вы не используете групповое проСм. также граммирование, то вам понадобится найти способ, как не мешать друг другу во время Стендап-митинги (глава 9) ежедневной работы. Ежедневные стендапПланирование задач (глава 9) митинги — хороший способ координации, пока они короткие и сфокусированные. Дос­ Парное программирование ка планирования задач поможет вам быть (глава 12) в курсе текущей ситуации, особенно если она Непрерывная интеграция (глава 13) видна с того места, где вы сидите.

410  Часть III.  Надежная поставка Парное программирование поможет вам быть в курсе внесенных всеми изменений. Ваш партнер часто будет знать об изменениях, о которых вы не знаете, и наоборот. И даже если он не в курсе, при парном программировании проще попросить другую пару о помощи. Люди, работающие в паре, могут ненадолго отвлекаться, не влияя на свой прогресс, — один человек просто продолжает работать, пока другой разбирается с тем, что их отвлекло. На самом деле настаивайте на том, чтобы люди просили помощи, когда их что-то останавливает. Нет никакого смысла 30 минут биться головой о стену, если кто-то другой в команде уже знает ответ. И наконец, непрерывная интеграция предотвратит болезненные конфликты объединения и будет поддерживать синхронизацию общего кода.

Работа с незнакомым кодом Если вы работаете над проектом, в котором имеются куски кода, которые понимают один или два человека, то совместное владение кодом может пугать. Как вы можете взять на себя ответственность за код, который не понимаете? Вам лучше всего подойдет групповое программирование, по крайней мере поначалу. Оно поможет всей команде быстро делиться друг с другом своими знаниями. Если это вам не по вкусу, то используйте парное программирование. Чтобы использовать парное программирование для расширения своих знаний, вызывайтесь добровольцем работать над задачами, которые не понимаете. Попросите кого-нибудь, кто знает эту часть системы, поработать с вами в паре. В ходе работы избегайте соблазна сесть позади и наблюдать. Вместо этого возьмите клавиатуру и попросите партнера руководить вами. Благодаря тому, что клавиатура в ваших руках, вы можете контролировать темп: задавайте вопросы и убеждайтесь, что понимаете, что вас просят сделать. Больше информации см. в подразделе «Обучение при работе в паре» далее в текущей главе. Если никто не понимает код, то тренируйте свои навыки делать логические выводы. Вам не нужно точно знать, что происходит в каждой строчке кода. В хорошо спроектированной системе все, что вам нужно знать, — это за что отвечает каждый пакет, пространство имен или папка. Тогда вы сможете сделать вывод о том, за что отвечают классы и что делают методы, исходя из их имен. В подразделе «Реверсинжиниринг дизайна» главы 14 можно узнать более подробную информацию по данной теме. Хорошо написанные тесты также служат документацией и подстраховкой. Бегло просмотрите См. также названия тестов, чтобы понять, какой соответствующий код за них отвечает. Если вы не понимаете, Разработка через тестировакак что-либо работает, то измените это любым ние (глава 13) образом и посмотрите, что покажут тесты. ЭфРефакторинг (глава 13) фективный набор тестов покажет вам, когда ваши предположения неверны.

Глава 12.  Сотрудничество   411

В процессе этого обучения выполняйте рефакторинг кода так, чтобы он отражал ваш прогресс в понимании. Исправляйте запутанные имена и извлекайте переменные и функции. Таким образом вы систематизируете ваши знания, а также поможете следующему человеку. Техника Арло Бельши «Присвоение имени как процесс» [Belshee2019] — хорошая формализация этого подхода. Если вы работаете с плохо спроектированным кодом, который никто не понимает и у которого нет никаких тестов, то не все потеряно. Вы можете использовать характеристические тесты (characterization tests) для безопасного рефакторинга. В подразделе «Добавление тестов к существующему коду» главы 13 содержится больше информации по этой теме.

Преимущества для программистов То, что никто этого не понимает, — гарантия моей востребованности! Старая программистская шутка Коллективное владение имеет большой смысл для организации. Оно снижает риск, улучшает временной цикл и повышает качество благодаря привлечению к коду большего количества людей. Но имеет ли оно смысл для программистов? Не осложнит ли оно еще больше признание вашего вклада? Если честно, то может… Как обсуждается в подразделе «Измените вредные ка­дровые политики» главы 4, Agile требует, чтобы ваша организация признавала и ценила командный вклад больше, чем индивидуальный героизм. Если в ва­шей организации это не так, то коллективное владение кодом может вам не подойти. Даже если ваша организация ценит командную работу, перестать работать над большим куском кода нелегко. Может быть трудно справиться с желанием взять на себя почетную ответственность за особенно умное или элегантное решение. Но все же это хорошо для вас как для программиста. Почему? Вся кодовая база в вашем распоряжении — не только для изменений, но и для поддержки и совершенствования. Вы можете расширить ваши технические навыки. Вы узнаете новые техники дизайна и написания кода, работая с другими членами команды. Обучая других людей знаниям из вашей экспертной области, вы также можете практиковать свои навыки наставничества. Вы также не должны нести бремя технического обслуживания каждого куска кода, который напишете. Вся команда прикрывает вас. Со временем они будут знать ваш код так же хорошо, как и вы сами, и вы сможете уйти в отпуск, не ожидая постоянных звонков с вопросами и экстренных ситуаций. Поначалу немного страшновато приходить на работу и не знать точно, над какой частью системы вы будете работать сегодня, но это также и освобождает. У вас больше нет долгих подпроектов, растягивающихся на ночь или на выходные. Вы получаете разнообразие, вызов и изменения. Попробуйте — вам понравится.

412  Часть III.  Надежная поставка

Вопросы У нас есть действительно хороший фронтенд-разработчик/программист баз данных/ гуру масштабирования. Почему не использовать их навыки? Пожалуйста, так и делайте! Коллективное владение кодом означает, что каждый вносит вклад в каждую часть системы, но вам все же понадобятся эксперты, которые будут задавать тон. Как может каждый узнать всю кодовую базу целиком? Людей естественным образом притягивает та или иная часть системы. Они становятся экспертами в определенных областях. Каждый получает общее понимание кодовой базы в целом, но все не могут знать всех деталей. Несколько практик поддерживают этот подход к работе. Простой дизайн См. также и его фокус на ясности кода облегчаПростой дизайн (глава 14) ет понимание незнакомого кода. Тесты работают как подстраховка и источник Разработка через тестирование (глава 13) документации. Парное и групповое проПарное программирование (глава 12) граммирование позволяет вам работать Групповое программирование (глава 12) с людьми, разбирающимися в деталях, которые не понимаете вы. Разные программисты в нашей команде отвечают за разные продукты. Должна ли команда коллективно владеть всеми этими продуктами? Если вы объединили программистов в одну команду, то да, вся команда должна взять на себя ответственность за весь свой код. Если у вас несколько команд, то они могут делить ответственность между командами или не делить в зависимости от вашего подхода к масштабированию. В главе 6 можно найти больше информации по данной теме.

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

См. также Согласование (глава 7) Безопасность (глава 7) Командная комната (глава 7) Планирование задач (глава 9) Стендап-митинги (глава 9) Групповое программирование (глава 12) Парное программирование (глава 12) Непрерывная интеграция (глава 13) Простой дизайн (глава 14) Разработка через тестирование (глава 13)

Глава 12.  Сотрудничество   413

Безопасность критически важна. Если члены команды не чувствуют себя в безопасности, чтобы выражать и получать критику, или опасаются нападок в случае высказывания идей или озабоченности, то не смогут разделить владение кодом. Вместо этого будут возникать небольшие случаи «феодального владения» кодом. «Не меняй пока этот код. Тебе нужно поговорить сначала с Энтони, чтобы удостовериться, что он согласен». Коллективное владение также требует хорошей коммуникации. Вам понадобится командная комната, физическая или виртуальная, в которой люди смогут свободно общаться. Используйте планирование задач и доску задач, чтобы помочь людям понять суть своей работы, и стендап-митинги, чтобы координировать ее. Вам нужен способ, благодаря которому вся команда будет знать об изменениях. В них легко потеряться, так как любой человек может внести любое изменение в любой момент времени. Самые простые способы — парное и групповое программирование. Если они не подходят, то вам нужно будет приложить дополнительные усилия, чтобы информировать об изменениях. Ревью кода будет, вероятно, недостаточно. Большинство людей инстинктивно склоняются к документации в качестве решения, но это слишком затратно, как обсуждалось в главе 7. Попробуйте сначала более легкие решения. Один из вариантов — ежедневно проводить 30-минутные «резюме дизайна» для обсуждения новых идей и недавних изменений. Так как коллективное владение кодом повышает вероятность того, что люди будут менять один и тот же код, вам нужно минимизировать вероятность болезненных конфликтов при объединении кода. Лучший способ — непрерывная интеграция. В новых кодовых базах конфликты объединения более вероятны, поскольку кода мало. Групповое программирование может быть хорошим способом загрузки кодовой базы, даже если вы не планируете использовать его в долгосрочной перспективе. Хотя это и не всегда строго необходимо, простой дизайн и разработка на основе тестирования являются хорошими идеями для команд, использующих коллективное владение кодом. Они упрощают понимание и изменение кода. Несмотря на длинный список предварительных требований, коллективное владение кодом легко практиковать, когда все условия соблюдены. Все, что вам нужно, — общее согласие команды по поводу того, что каждый должен работать над любой частью кода, запрашивая и предоставляя помощь по мере необходимости. Вам не нужно, чтобы каждый знал любой фрагмент кода; члены команды просто должны быть в состоянии попросить помощи, работая над незнакомой частью кода, и великодушно предоставить свою помощь взамен.

Показатели Когда ваша команда хорошо практикует коллективное владение кодом: zz

каждый в команде постоянно вносит небольшие усовершенствования во все части кода;

zz

никто не жалуется на то, что члены команды меняют код, не спрашивая разрешения перед этим;

414  Часть III.  Надежная поставка zz zz

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

Альтернативы и эксперименты Главные альтернативы коллективному владению кодом — слабое и сильное владение кодом. Если вы работаете с кодом со слабым владением, то можете изменять любую часть кода, но хорошим тоном будет согласовать изменения с разработчиками, ответственными за его качество. В случае кода с сильным владением все изменения делаются только через его владельцев. Оба эти подхода умаляют присущую Agile сосредоточенность на командной работе, хотя слабое владение кодом не так плохо, как сильное. Оно может быть полезно командам, которые не используют парное или групповое программирование или у которых не получается оставлять код в лучшем состоянии, чем они его нашли. Но если вы можете, то попробуйте применить коллективное владение кодом. Это одна из тех идей Agile, которую часто упускают из виду, хотя на самом деле она является одной из главных. Она не всегда означает коллективное владение кодом, но, я думаю, это важная составляющая равенства. Хотя, вероятно, и можно быть компетентной командой поставки без коллективного владения кодом, я такого еще не видел. Используйте эту практику, пока не наберетесь опыта как компетентная команда поставки.

ПАРНОЕ ПРОГРАММИРОВАНИЕ Мы помогаем друг другу добиваться успеха.

Аудитория

Вы бы хотели, чтобы кто-то весь день загляРазработчики, вся команда дывал вам через плечо? Вы бы хотели тратить половину своего времени, сидя в скучной тишине и глядя на чей-то чужой код? Конечно, нет! К счастью, парное программирование работает не так. Парное программирование подразумевает работу двух человек за одним компьютером в одно и то же время над одним и тем же. Это одна из наиболее противоречивых идей Agile. Два человека работают за одним компьютером? Это странно. И это также чрезвычайно эффективно и, когда вы привыкаете, доставляет огромное удовольствие. Большинство знакомых мне программистов, которые практиковали парное программирование в течение месяца, обнаружили, что предпочитают его программированию в одиночестве. Что гораздо важнее, парное программироваСм. также ние — один из наиболее эффективных способов достижения коллективного владения и подКоллективное владение кодом линного взаимодействия команды в работе над (глава 12) кодом.

Глава 12.  Сотрудничество   415

Почему парное? Парное программирование — нечто большее, чем обмен знаниями. Помимо этого, оно улучшает качество ваших результатов. Это потому, что парное программирование удваивает ваш интеллектуальный потенциал. Когда вы работаете в паре, один человек является водителем. Он (или она) пишет код. Второй человек — штурман. Его (или ее) работа — думать. Будучи штурманом, иногда вы думаете о том, что набирает водитель. (Однако не спешите указывать ему на пропущенные точки с запятой, это раздражает.) Иногда вы думаете о том, что будет дальше. А иногда — о том, как ваша работа вписывается в общий дизайн. Такой порядок позволяет водителю свободно работать над тактическими задачами по созданию строгого, синтаксически правильного кода, не беспокоясь об общей картине, а штурману дает возможность рассматривать стратегические вопросы, не отвлекаясь на детали кодирования. Работая вместе, водитель и штурман выполняют работу более качественно и быстро, чем если бы это делал каждый из них по отдельности1. Кроме того, парное программирование закрепляет хорошие навыки программирования. Практики поставки требуют много самодисциплины. В процессе парного программирования вы будете испытывать позитивное давление коллег, побуждающее вас делать то, что необходимо. Вы также будете распространять знания и рекомендации по кодированию в команде. Как ни удивительно, вы также будете проводить больше времени в потоке — этом высокопродуктивном состоянии, в котором вы полностью сосредоточены на коде. Это другой вид потока, по сравнению с тем, когда вы работаете в одиночку, но он гораздо более устойчив к прерываниям. Для начала вы обнаружите, что ваши офисные коллеги с гораздо меньшей вероятностью отвлекают вас, когда вы работаете с кем-либо. А когда они это делают, один член пары может заняться тем вопросом, по которому вас прервали, в то время как другой продолжит работу. Далее вы обнаружите, что фоновый шум отвлекает меньше: ваши разговоры с вашим партнером по паре будут удерживать вас в фокусе. Если этих резонов недостаточно, то могу сказать, что программирование в паре — это действительно очень весело. Дополнительная умственная энергия поможет вам легче обойти препятствия. Бо́льшую часть времени вы будете взаимодействовать с умными людьми, вашими единомышленниками. Вдобавок если у вас устанут пальцы, то вы сможете передать клавиатуру вашему партнеру и при этом продолжать быть продуктивным.

Рабочие станции для парного программирования Чтобы получать удовольствие от парного программирования, необходима хорошая рабочая станция, независимо от того, работаете вы в офисе или удаленно. Командам, работающим в офисе, нужно предоставить достаточно места, чтобы два человека Одно из исследований обнаружило, что парная работа требует приблизительно на 15 % больше усилий, чем индивидуальная, но дает результат гораздо быстрее, при этом количество дефектов уменьшается на 15 % [Cockburn2001]. Все команды разные, так что лучше относиться к этим результатам с недоверием.

1

416  Часть III.  Надежная поставка могли сидеть рядом. Обычные офисные кабинки, где монитор расположен в углу, не подойдут. Они неудобны и требуют, чтобы один человек сидел за спиной у другого, что добавляет психологические и физические барьеры на пути к тому, что должно быть сотрудничеством с коллегами. Вам не нужна роскошная мебель для того, чтобы сделать хорошую парную рабочую станцию. Подойдет простой стол. Он должен быть шесть футов шириной (примерно 180 см), чтобы два человека могли комфортно разместиться бок о бок. На каждый стол нужен мощный компьютер. Подключите две клавиатуры и мышь, чтобы у каждого человека был свой комплект. Если у людей есть любимые клавиатура и мышь, то они могут принести их с собой. На такой случай предоставьте свободный доступ к USB-портам. Купите большие мониторы, чтобы обоим участникам пары было все хорошо видно. Учтите возможную разницу зрения людей, особенно в отношении размеров шрифтов и цвета. Некоторые команды устанавливают три монитора, при этом два внешних монитора зеркальны, чтобы каждый человек мог видеть код на мониторе напротив себя, используя центральный монитор для вспомогательных материалов. Если вы так делаете, то попробуйте установить утилиту, позволяющую мыши переходить за границы рабочего стола. Это позволит обоим программистам легко добраться до центрального экрана. Если ваша команда работает удаленно, то вам понадобятся совместный редактор кода и видеоконференция. Предоставьте несколько экранов, чтобы вы могли одновременно видеть друг друга и писать код. Существует множество IDE-надстроек и автономных инструментов для совместного редактирования, таких как CodeTogether, Tuple, Floobits и Visual Studio’s Live Share. Кроме того, можно совместно использовать экран в программе для видеоконференций, но инструмент для совместного редактирования позволит вам переключать водителей гораздо быстрее. Если вам нужно совместно использовать экран, то вы можете передавать контроль, выкладывая код во временную ветвь с текущей работой (work-in-progress). Напишите небольшой скрипт для автоматизации процесса. У Джеффа Лангра в [Langr2020] есть хороший обзор вариантов взаимодействия при удаленном написании кода.

Как работать в паре Я рекомендую работать в паре над всем производственным кодом. Команды, которые часто работают парами (но не исключительно парами), говорят, что в коде, написанном соло, они обнаруживают больше дефектов. Это совпадает с тем, что говорят исследования парного программирования, такие как [Cockburn2001], которые находят, что пары производят высококачественный код. Хорошее эмпирическое правило — работать в паре над всем, что вам нужно поддерживать, в том числе над тестами и автоматизацией. Когда вы начинаете работать над задачей, попросите другого программиста работать с вами. Если кто-то другой просит о помощи, то предложите ее. Руководители никогда не должны назначать партнеров, пары должны свободно и самостоятельно

Глава 12.  Сотрудничество   417

формироваться и переключаться в течение дня. В течение недели поработайте в паре с каждым разработчиком в команде. Это повысит сплоченность команды и будет способствовать распространению навыков и знаний в команде. Если вам нужен свежий взгляд, то поменяйте партнеров. Я обычно переключаюсь, когда расстроПолучите свежий взгляд, ен или застрял. Пусть один из партнеров остается поменяв партнеров. работать над задачей и введет нового партнера в курс дела. Часто даже объяснение проблемы новому человеку может помочь решить ее. Хорошая идея — менять партнеров несколько раз за день, даже если вы не чувствуете себя застрявшим на чем-то. Это поможет держать всех в курсе и работать быстро. Я переключаюсь на другого партнера, когда завершаю задачу. Если я работаю над большой задачей, то меняю партнера в течение четырех часов. Некоторые команды переключают партнеров в парах строго по расписанию. [Belshee2005] отчитывается об интересных результатах, получаемых при переключении каждые 90 минут. Это отличный способ приобрести привычку переключения, однако убедитесь, что все хотят его попробовать. Начиная парную работу, убедитесь, что вам физически комфортно. Если вы в одном помещении, то расположите стулья бок о бок, чтобы у каждого было достаточно личного пространства, и поставьте монитор так, чтобы он был хорошо виден. Когда вы в роли водителя, поместите клавиатуру прямо напротив себя. Следите за этим — почемуто новички в парном программировании склонны изгибаться, чтобы дотянуться до клавиатуры и мыши, вместо того чтобы подвинуть их к себе поближе. Кроме того, уделите время тому, чтобы договориться с партнером о предпочтениях друг друга. Когда вы в роли водителя, хотите ли вы, чтобы ваш партнер давал вам время на самостоятельное обдумывание каких-то нюансов? Или вы хотели бы, чтобы он (или она) управлял процессом и вам не приходилось останавливаться и думать? Когда вы — штурман, хотите ли вы, чтобы ваш водитель проговаривал вслух, о чем он думает, чтобы вы понимали направление движения? Или вы хотели бы иметь возможность концентрироваться на том, что будет дальше? Хотите ли вы строгого разделения ролей водителя и штурмана? Или предпочтете легкий, неформальный подход? Ожидайте поначалу чувства неловкости и неуклюжести, когда придет ваша очередь быть в роли водителя. Вам может казаться, что ваш штурман видит идеи и проблемы гораздо быстрее вас. Так и есть: у него гораздо больше времени на размышление, чем у водителя. Ситуация будет обратной, когда вы станете штурманом. Через некоторое время работа в паре будет ощущаться как что-то естественное. Пары производят код с помощью общения. В процессе работы думайте вслух. Двигайтесь маленькими шагами (отлично подойдет разработка на основе тестирования) и говорите о своих предположениях, краткосрочных целях, общем направлении и о любой См. также истории, имеющей отношение к делу. Если вас что-то смущает, то задавайте вопросы. Благодаря Разработка через тестирование обсуждению ваш партнер может узнать полезную (глава 13) информацию, так же как и вы.

418  Часть III.  Надежная поставка В процессе работы переключайте роли водителя и штурмана чаще — по меньшей мере каждые полчаса, а по возможности каждые несколько минут. Если вы — штурман и обнаруживате, что говорите водителю, какие кнопки нажимать, то попросите дать вам клавиатуру. Если вы — водитель и вам нужен перерыв, то передайте клавиа­ туру вашему штурману. Ожидайте, что устанете к концу дня. Пары обычно чувствуют, что работали больше и доСм. также бились большего, чем если бы работали поодиЭнергичная работа (глава 7) ночке. Практикуйте активную работу, чтобы поддерживать способность работать в паре ежедневно.

Эффективная навигация Пребывая в роли штурмана, вы можете испытывать желание вмешаться и забрать клавиатуру у вашего партнера. Будьте терпеливы. Ваш водитель часто будет высказывать свои идеи как словами, так и с помощью кода. Он будет делать опечатки и небольшие ошибки — дайте ему время исправить их самостоятельно. Используйте свое свободное время, чтобы подумать об общей картине. Какие еще тесты вам необходимо написать? Как этот код вписывается в остальную систему? Есть ли дублирование, которое вы хотите удалить? Может ли код быть более понятным? Может ли общий дизайн быть лучше? Есть ли шероховатости, которые надо устранить? Кроме того, уделите внимание потребностям вашего водителя. Людям, которые не знакомы с IDE или кодовой базой, могут понадобиться конкретные рекомендации. Но постарайтесь удержаться от микроменеджмента. Дайте людям свободу разобраться самостоятельно, если они этого хотят. Когда вы — штурман, ваша роль — помогать водителю быть более производительным. Думайте о том, что будет дальше, и будьте готовы дать рекомендации. Когда я штурман, мне нравится держать перед собой индексную карточку. Вместо того чтобы прерывать водителя, когда мне приходит что-то в голову, я записываю идею на индексную карточку и жду перерыва в работе, чтобы вынести ее на обсуждение. В конце сессии парного программирования я рву карточку и выбрасываю. Подобным образом, когда возникает какой-то См. также вопрос, уделите время поиску ответов, прежде чем водитель продолжит работу. Некоторые Спайк-решения (глава 13) команды держат для этой цели отдельные ноутбуки. Если вам нужно больше, чем несколько минут, то сделайте паузу в кодировании и поищите решение вместе. Иногда лучший способ это сделать — разделиться, провести исследования, двигаясь параллельными путями, и затем снова собраться вместе, чтобы поделиться тем, что удалось узнать. Особенно эффективный подход — спайк-решения. Хотя у штурмана обычно больше времени на раздумья, чем у водителя, это не значит, что водитель — бездумный автомат. У него тоже могут быть идеи по части дизайна. Поощряйте вашего водителя делиться своими мыслями, и когда у него

Глава 12.  Сотрудничество   419

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

Обучение при работе в паре Хотя парное программирование больше всего подходит для взаимодействия на равных, иногда работать вместе приходится людям с разным уровнем опыта. В этой ситуации важно восстановить равновесие между ними. Выделите навыки, которые каждый человек привносит в работу. Даже если одному будет нужно обучать другого коду, рассматривайте это как недостаток знаний, который легко восполнить, а не как недостаток способностей со стороны обучаемого или знак превосходства со стороны учителя. Если вам нужно ввести вашего партнера Цель в том, чтобы максимизировать в курс дела по какой-то части кода, то по­ производительность команды. мните, что следует быть терпеливым. Обучение вашего партнера тому, как работает код, замедляет вас, но цель не в том, чтобы максимизировать вашу производительность, а в том, чтобы максимизировать производительность команды. Хороший разработчик работает быстро и хорошо, но лучшие разработчики помогают так работать всем. Чтобы научить кого-либо кодированию с помощью парного программирования, начните с предоставления ему роли водителя. Это позволит ему контролировать темп. Направляя его работу, воздерживайтесь от прямых указаний о том, что делать. Вместо этого обрисуйте общую картину (может быть, даже начните с диаграммы на доске) и предоставьте ему возможность разобраться с деталями. Например, когда вносите изменения в сервис, не говорите: «Нам нужно изменить SuperMailClient. Нажми на source, теперь на infrastructure, а теперь на rest…» Вместо этого предоставьте контекст и направление: «Наша задача — изменить нашего вендора транзакционной почты SuperMail на BetterMail. Они оба обеспечивают REST APIs, так что все, что нам нужно сделать, — это изменить нашу обертку (wrapper) SuperMail на использование BetterMail. (Рисует структуру проекта на доске.) Все наши REST-клиенты находятся в папке infrastructure/rest, и каждый сервис имеет собственную обертку». Затем позвольте вашему партнеру самостоятельно просмотреть файлы проекта и найти файл, с которым необходимо работать. Как только человек, которого вы обучаете, сможет самостоятельно ориентироваться, вы можете поменяться ролями. Попросите его (или ее) стать штурманом и сказать вам, что нужно делать дальше. Однако будьте внимательны: когда вы окажетесь в роли водителя, у вас появится желание вырваться вперед и просто делать то, что, как вы знаете, нужно сделать. Чтобы это работало в качестве обучающей техники, вы должны подавить это желание и позволить партнеру установить темп.

Трудности Работа в паре поначалу может показаться неудобной или неприятной. Это естественное чувство, и обычно оно проходит через месяц или два. Ниже описаны несколько обычных трудностей и способы их преодоления.

420  Часть III.  Надежная поставка

Удобство Стоит повторить: парное программирование перестает быть удовольствием, если вам неудобно. Когда вы садитесь за работу в паре, займите удобную позу, настройте и оборудование, чтобы вам было комфортно. Уберите мусор со стола и обеспечьте достаточно места для ног. Договоритесь с партнером о размере шрифта и расположении монитора. Если вы работаете в паре в удаленном режиме, то перед началом работы уделите время тому, чтобы убедиться, что весь инструментарий настроен и работает безупречно. Некоторым людям (вроде меня) нужно много личного пространства. Другим нравится расположиться ближе. Когда вы начинаете работать в паре, обсудите ваши потребности в личном пространстве с партнером и спросите о его запросах.

Интроверсия и социальное беспокойство Интроверты часто беспокоятся, что парное программирование им не подойдет, но (сам являясь интровертом) я обнаружил, что это не соответствует действительности. Работа в паре может утомлять, однако она очень сфокусирована на идеях и результатах. Нет необходимости вступать в светские беседы, и вы обычно работаете с людьми, которых хорошо знаете и уважаете. Это очень продуктивное умственное взаимодействие, к тому же оно может быть очень веселым. Большинство встреченных мною интровертов, которые пробовали работать в парном программировании, полюбили его, как только прошли начальную кривую обучения. Конечно, люди не вписываются идеально См. также в предопределенные рамки личностных качеств. Парное программирование (и Agile в целом) моСогласование (глава 7) жет оказаться сложным для людей с социальным беспокойством. Если вы думаете, что парная работа будет трудной для вас или для кого-либо в вашей команде, то обсудите способы сделать эту работу более комфортной или найдите другие варианты, с помощью которых ваша команда может добиться коллективного владения кодом. Обсудить все это можно во время сессии согласования.

Стиль коммуникации Новым водителям иногда бывает трудно вовлекать своих партнеров: они берут под свой контроль клавиатуру и полностью закрываются от общения. Чтобы попрактиковаться в коммуникации и переключении ролей в парном программировании, рассмотрите парную работу в стиле пинг-понг. В этом упражнении один человек пишет тест. Другой выполняет его и пишет новый. Тогда первый человек выполняет его и пишет новый тест, таким образом повторяя всю процедуру. Еще один подход — попробовать работу в паре в сильном стиле. В этом подходе, который изобрел Левелин Фалько, все идеи должны проходить через руки другого человека [Falco2014]. Поэтому, когда у вас возникает идея, вы должны передать клавиатуру другому человеку и объяснить ему, как ее реализовать. Потом, когда у другого

Глава 12.  Сотрудничество   421

человека возникает идея, он передает клавиатуру вам и объясняет, что делать. Даже если вы не хотите делать так постоянно, это отличный способ попрактиковаться в общении с вашим партнером. Обратная сторона недостаточного общения — слишком много общения или, скорее, слишком грубое общение. Откровенная критика кода или дизайна полезна, но ее может быть трудно оценить поначалу. У разных людей разные пороги чувствительности, поэтому обратите внимание на то, как ваш партнер воспринимает ваши комментарии. Попробуйте трансформировать заявления (такие как «Этот метод слишком длинный») в вопросы или предложения («Не могли бы мы сделать этот метод короче?»). Примите на вооружение подход совместного решения проблем. Больше идей вы найдете в пункте «Научитесь принимать и давать обратную связь» главы 7.

Инструменты и привязки клавиш Даже если вы не падете жертвой бесконечных См. также войн редакторов «vi против emacs», вы можете посчитать раздражающими предпочтения ваших Согласование (глава 7) коллег по части инструментов. Попробуйте ввести стандарт на определенный инструментарий. Некоторые команды даже создают стандартный образ и используют его в процедуре контроля версий. Когда вы обсуждаете рабочие соглашения во время сессии согласования, обсудите еще и эти вопросы. Клавиатура и мышь могут быть еще одним источником раздоров. Если это так, то не нужно вводить стандарт. Люди с жесткими предпочтениями устройств вводавывода могут, меняя рабочие станции, переносить свои девайсы с собой. Только обеспечьте свободный доступ к USB-портам.

Вопросы Разве это не расточительно, когда два человека выполняют работу одного? На самом деле в парном программировании два человека не делают работу одного. В каждый момент времени используется только одна клавиатура, однако программирование — это больше чем набор кода. Один человек программирует, а другой думает наперед, предвидит проблемы и разрабатывает стратегию. Как мне убедить мою команду или организацию попробовать парное программирование? Попросите разрешения попробовать это в качестве эксперимента. Запланируйте месяц, в течение которого все будут работать в парах над рабочим кодом. Сделайте так, чтобы эксперимент обязательно продолжался целый месяц, поскольку парное программирование может быть некомфортным первые несколько недель. Не только попросите разрешения руководства; заручитесь также согласием ваших коллег по команде. Необязательно, чтобы они полюбили эту идею, пусть хотя бы не будут против нее.

422  Часть III.  Надежная поставка Нам действительно нужно программировать парами все время? Некоторый код этого не требует. Некоторые производственные задачи Если вам скучно во время работы повторяются настолько часто, что для них в паре — это верный признак не нужно дополнительной умственной энернедостатков дизайна. гии, которую обеспечивает парное программирование. Однако, прежде чем отказаться от парной работы, задумайтесь, почему ваш дизайн требует так много повторений. Это обычный признак недостатков дизайна. Используйте свободное время штурмана для размышлений над улучшением дизайна и рассмотрите возможность обсудить это со всей командой. Как я могу сконцентрироваться, когда кто-то со мной разговаривает? Когда вы в роли штурмана, у вас не должно вызывать особых трудностей быть на несколько шагов впереди вашего водителя. Если вам все же трудно, то попросите вашего водителя думать вслух, чтобы вы понимали ход его мыслей, или попросите вести, чтобы контролировать темп. Пребывая в роли водителя, вы можете иногда обнаружить, что у вас не получается решить проблему. Дайте знать об этом вашему штурману — у него могут оказаться идеи, которые помогут преодолеть препятствие. В других случаях вам может понадобиться всего лишь несколько минут тишины, чтобы обдумать проблему. Вполне нормально сказать об этом. Если вы часто оказываетесь в такой ситуации, то, возможно, предпринимаете слишком большие шаги. Используйте разработку на основе тестирования и продвигайтесь очень маленькими шагами. Положитесь на вашего штурмана, чтобы он См. также отслеживал, что вам нужно сделать (скажите ему, если у вас есть идея; он ее запишет), Разработка через тестирование (глава 13) и сфокусируйтесь всего на нескольких строках кода, необходимых для успешного выСпайк-решения (глава 13) полнения следующего теста. Если вы работаете с технологией, которую не вполне понимаете, то потратьСм. также те несколько минут на разработку спайкрешения. Вы и ваш партнер можете работать Групповое программирование над ним вместе или по отдельности. (глава 12) Что, если у нас нечетное количество проОбнаружение слепых зон (глава 16) граммистов? Нулевое трение (глава 13) Если в вашей командной комнате есть станция для группового программирования, то вы можете сформировать «мини-группу» из трех человек. Если нет, то существует много других способов, позволяющих программисту-одиночке быть производительным, не притрагиваясь к рабочему коду. Он (или она) может исследовать новые технологии или узнавать больше о технологии, которую использует команда. Они могут работать в паре с заказчиком или тестировщиком, чтобы просматривать недавние изменения, совершенствовать приложение или проводить исследовательское

Глава 12.  Сотрудничество   423

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

Предварительные требования Работа в паре требует комфортной рабочей среды. Большинство офисов просто не подготовлены к этому. Прежде чем пробовать парное программирование на полный рабочий день, подготовьте свое физическое пространство. Если у вас виртуальная команда, то подготовьте соответствующий инструментарий. Убедитесь, что каждый хочет участвовать, прежде чем начнете эксперимент с работой в парах. Она вносит большие изменения в рабочие стили программистов, и вы можете встретить сопротивление. Я обычно стараюсь обойти эту проблему, попросив людей попробовать месяц или два и потом решить. Если это не срабатывает, то можно попробовать работать парами часть рабочего времени или только с людьми, которые заинтересованы в этом. Однако я считаю, что парное программирование работает наилучшим образом, когда вся команда использует его полный рабочий день. Групповое программирование, как праСм. также вило, менее пугающее, чем парное. Если люди не хотят пробовать работу в парах, то Групповое программирование проверьте, не понравится ли им идея попро(глава 12) бовать групповое программирование.

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

424  Часть III.  Надежная поставка

Альтернативы и эксперименты Парное программирование — очень эффективный инструмент. За исключением группового программирования, я не знаю другой техники, которая была бы столь же эффективна. Сначала освойте парное (или групповое) программирование, прежде чем экспериментировать с альтернативами. Когда будете рассматривать альтернативы, не делайте ошибку, думая, что парное программирование — всего лишь модный способ ревью кода. Чтобы действительно заменить парное программирование, вам нужно заменить все преимущества, перечисленные ниже. Качество кода. Парное программирование привноСм. также сит в код много разнообразных точек зрения и приводит к множеству разговоров о коде, поэтому снижает Коллективное владение количество дефектов и улучшает качество дизайна. кодом (глава 12) Частое переключение пар помогает распространению знаний среди членов команды, что укрепляет коллективное владение кодом. Совместная работа помогает людям сфокусироваться, поддерживает самодисциплину и уменьшает отвлекающие факторы. Всего этого удается добиться, не принося в жертву производительность. Формальные ревью кода также могут снизить дефекты, повысить качество и поддерживать самодисциплину. В каком-то смысле парное программирование — это непрерывное ревью кода. Однако при ревью нельзя делиться знаниями так же подробно, как при парной работе, поэтому если вы используете коллективное владение кодом, то вам, вероятно, понадобится дополнить ревью кода обсуждениями дизайна. Поток. Парное программирование дает потоку более тонкие преимущества. Поскольку два человека сосредоточиваются на одной и той же проблеме, при объединении в пару как будто появляется запасной мозг. Если один человек отвлекся, то другой может «перезагрузить» его внимание и легко вернуть его назад, в нужное русло. Кроме того, легче игнорировать вездесущие отвлекающие факторы, такие как смартфоны, электронная почта, мессенджеры и прочие претенденты на ваше внимание. Там, где не используется парная работа, вам понадобится другой способ помочь людям оставаться сосредоточенными. Взаимодействие. Устойчивость парного программирования к прерываниям упрощает внутрикомандное взаимодействие. В идеале, когда один член команды застревает на каком-то вопросе, на который может ответить другой член команды, предпочтительнее, чтобы он обратился за помощью, а не «варился в собственном соку». Если вы работаете в паре, то ответить на вопрос почти ничего не стоит, поскольку ваш партнер продолжает работу. Имеет смысл просить помощи каждый раз, когда она вам нужна. Если вы не работаете в паре, то прерывания обходятся гораздо дороже. Тут вы должны принять решение, стоит ли время, сэкономленное благодаря ответу на вопрос, прерывания чужого процесса. На практике в команде, не работающей в парном программировании, гораздо меньше взаимодействия. Меньше шума и осведомленность о происходящем. У парного программирования есть еще одно преимущество, менее очевидное. В физической командной комнате при парной работе возникает негромкий фоновый гул разговоров. Можно ожидать, что

Глава 12.  Сотрудничество   425

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

Литература для дополнительного чтения On Pair Programming Биргитты Бокелер и Нины Сиссеггер [Bockeler2020] — хорошая онлайн-статья, в которой более подробно разбираются вопросы парного программирования. В статье Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience [Belshee2005] представлен занимательный взгляд на преимущества, которые дает переключение пар через строгие интервалы времени. В статье Adventures in Promiscuous Pairing: Seeking Beginner’s Mind [Lacey2006] исследуются издержки и проблемы неупорядоченного переключения пар. Обязательна для прочтения, если вы планируете попробовать подход Бельши.

ГРУППОВОЕ ПРОГРАММИРОВАНИЕ Мы используем идеи всей команды.

Аудитория Вся команда

В ранние годы экстремального программирования, когда парное программирование только набирало популярность, люди подшучивали над ним. «Если работать в паре хорошо, то почему бы и не попробовать втроем! — смеялись они. — Или просто посадить всю команду перед одним компьютером!» Они пытались принизить ХР, но Agile — это путь экспериментов, обучения и совершенствования. Вместо того чтобы предполагать, что что-то не будет работать, мы просто ставим эксперимент. Некоторые эксперименты работают, некоторые — нет. Так или иначе, мы делимся тем, что узнали. Именно это и произошло с групповым программированием. У Вуди Зуилла была групповая обучающая техника, которую он использовал для кодирования додзё. Его команда в компании Hunter Industries оказалась в затруднительном положении. Они решили попробовать групповую технику Вуди в реальной работе и посадили всю команду перед одним компьютером.

426  Часть III.  Надежная поставка Это сработало, и весьма хорошо. Вуди и команда поделились с другими тем, чему научились. И теперь групповое программирование используется по всему миру. ПРИМЕЧАНИЕ В некоторых странах термин «групповое программирование» (mob programming) имеет неприятный подтекст, поэтому люди называют эту практику «программирование в ансамбле» (ensemble programming). Оригинальное название, данное ей Вуди Зуиллом, было «программирование всей командой» (Whole Team programming). Но он сказал: «Я всегда говорил: мне все равно, как это называется. Хорошей командной работе стоит учиться, и я предлагаю людям называть это так, как они хотят»1.

Как работать в групповом программировании Групповое программирование — вариант парСм. также ного программирования. Как и в паре, в нем есть водитель, который пишет код, и штурПарное программирование (глава 12) маны, которые предлагают направление. В отличие от парного программирования, присутствует вся команда. В то время как один человек выступает в роли водителя, остальные члены команды отвечают за направления. Вы можете попробовать любой подход группового программирования, который вам нравится. Как сказал Вуди Зуилл, «нет никаких правил, кроме общей рекомендации: “Давайте разберемся, как повысить нашу способность хорошо взаимодействовать”»2. Экспериментируйте и выбирайте, что лучше для вас. Для начала попробуйте подход Вуди Зуилла. Он начинает с присутствия всей команды и ее готовности участвовать. Некоторые люди, такие как заказчики в команде, могут не фокусироваться конкретно на программировании, но должны быть готовы отвечать на вопросы и работают над теми же историями, что и программисты. Поверх этой базы добавляется слой сильного стиля парного программирования Левелина Фалько: все идеи должны проходить еще через чьи-то руки [Falco2014]. Когда приходит ваша очередь быть водителем, ваша работа — быть очень умным устройством ввода. Насколько умным — зависит от степени вашего знакомства с кодом и редактором. В одних случаях штурман может сказать: «А теперь обрабатываем случаи ошибок» — и водитель сделает тестовый прогон четырех тестов и соответствующий рабочий код, обойдясь без дальнейших подсказок. В других случаях штурман может сказать: «Теперь извлеките метод» — и водителю придется спросить, что вводить. Адаптируйте степень детализации к опыту каждого водителя в кодировании и работе с инструментами. И наконец, добавьте таймер. Для начала будет достаточно семи минут. Когда таймер срабатывает, водитель останавливается. Другой человек берет клавиатуру и продолжает Цитата из разговора с Вуди Зуиллом в Twitter (https://oreil.ly/RERXS).

1

Еще один отрывок из разговора с Вуди Зуиллом в Twitter (https://oreil.ly/UWIEK).

2

Глава 12.  Сотрудничество   427

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

Почему групповое программирование работает Групповое программирование работает, поГрупповое программирование — скольку это простой режим взаимодействия. простой режим взаимодействия. Значительная часть Agile концентрируется на общении и взаимодействии. Это секретный соус, делающий Agile более эффективным, чем другие подходы. А групповое программирование делает большинство практик взаимодействия Agile неактуальными. В них просто нет необходимости при групповом программировании. Стендап-митинги? Прекращаются. Коллективное владение кодом? Автоматически. Командная комната? Пара пустяков. Планирование задач? Все еще полезно, но как-то необязательно. Впервые услышав о групповом программировании, я жестко раскритиковал его. «Я получаю те же преимущества благодаря кросс-функциональной команде, командной комнате, работе в парах, частому переключению пар и хорошему взаи­ модействию», — сказал я. И был прав. Групповое программирование не даст вам ничего, чего бы вы еще не получили, имея хорошую команду. Но оно такое простое. Собрать людей в пары и научить взаимодействовать — трудно. Групповое программирование? Оно получается практически автоматически.

Рабочая станция для группового программирования Если у вас есть физическая командная комната, то организовать место для группового программирования очень легко. Вам нужны проектор либо телевизор с большим экраном (или несколько), столы, за которые люди могли бы сесть, и рабочая станция уровня разработки. Убедитесь, что все могут сесть комфортно, имеют доступ к компьютерам и белым доскам (для поиска нужной информации и обсуждения идей) и у них достаточно места, чтобы легко менять водителей. Некоторые команды имеют в своем распоряжении станции и для группового, и для парного программирования, чтобы люди могли переключаться туда-сюда по желанию. Если у вас команда, работающая в удаленном режиме, то организуйте видеоконференцию и попросите водителя показать свой экран. Когда приходит время сменить водителя, он перемещает свой код во временную ветку, а следующий водитель забирает его. Какой-нибудь скрипт, наподобие представленного на https://mob.sh, может помочь в этом процессе. Вы можете обнаружить, что вам нужно больше времени (возможно, десять минут вместо семи), чтобы уменьшить количество переключений.

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

428  Часть III.  Надежная поставка

Динамики команды Обратите внимание на взаимодействие членов команды и сделайте так, чтобы голос каждого был услышан. Установите рабочие соглашения, См. также сделайте так, чтобы выражать несогласие и обес­ Согласование (глава 7) покоенность было безопасно для людей, и обратите внимание на динамики команды. Если Безопасность (глава 7) кто-то склонен доминировать, то напомните Динамики команды (глава 11) ему, что нужно давать высказаться другим; если кому-то трудно высказываться, то спрашивайте мнение таких людей. Когда вы только начинаете использовать групповое программирование, стоит потратить несколько минут в конце каждого дня на очень короткую ретроспективу. Сфокусируйтесь на том, что хорошо работало и как делать этого больше. Вуди Зуилл называет это «включить хорошее».

Энергичная работа Групповое программирование не должно вас изСм. также матывать, но быть постоянно окруженным всей командой может быть несколько утомительным. Энергичная работа (глава 7) Позаботьтесь о себе. Вам не нужно быть включенным в каждый момент времени. Одно из преимуществ группового программирования заключается в том, что его процесс не зависит от каждого. Люди могут выпадать из процесса и возвращаться по необходимости. Если вам нужен перерыв на кофе или вы хотите просто развеяться, то сделайте это. Точно так же, если вам нужно проверить свою почту или позвонить по телефону, вы можете это сделать. Работа будет продолжаться без вас. Кроме того, вам не нужно согласовывать свои рабочие часы.

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

См. также Спайк-решения (глава 13)

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

Глава 12.  Сотрудничество   429

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

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

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

430  Часть III.  Надежная поставка

Вопросы Групповое программирование действительно эффективнее, чем работа поодиночке или в парах? Для новых команд почти наверняка. Эффективность команд зависит от того, насколько хорошо участники знают код и друг друга, а групповое программирование превосходит все остальные способы приобретения этого знания. Поэтому я рекомендую командам начинать с группового программирования (см. подраздел «Ваша первая неделя» главы 9). Для уже состоявшихся команд, по моему опыту, парное программирование более эффективно, чем одиночная работа. Будет ли групповое программирование еще более эффективно, чем парная работа? Для команд с хорошим командным помещением и отлично налаженным взаимодействием, возможно, нет. Для других команд, вероятно, да. Здесь слишком много переменных, чтобы сказать наверняка, поэтому попробуйте — и узнаете. Нам бывает трудно помнить о необходимости менять водителей. Что нам делать? Если люди забывают о таймере, то попробуйте использовать инструменты типа Mobster (доступен на http://mobster.cc). Когда время выходит, он гасит экран и водитель вынужден остановиться.

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

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

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

Глава 12.  Сотрудничество   431

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

См. также Парное программирование (глава 12) Коллективное владение кодом (глава 12) Планирование задач (глава 9) Стендап-митинги (глава 9)

Литература для дополнительного чтения Книга Вуди Зуилла и Кевина Медоуза Mob Programming: A Whole Team Approach [Zuill2021] содержит углубленный анализ «как» и «почему» в групповом программировании.

ЕДИНЫЙ ЯЗЫК Все в нашей команде понимают друг друга.

Аудитория Программисты

Попытайтесь объяснить бизнес-логику вашей текущей системы экспертам в предметной области. Сможете объяснить это в понятных им терминах? Сможете избежать программистских жаргонизмов, таких как названия структур дизайна, фреймворков, стилей кодирования? Ваш эксперт в предметной области в состоянии определить потенциальные проблемы в вашей бизнес-логике? Если нет, то вам нужен единый язык. Это способ унификации терминов, которые ваша команда использует в разговоре и коде, чтобы все могли эффективно взаимодействовать.

Дилемма экспертных знаний в предметной области Одной из проблем профессиональной разработки ПО является то, что программисты обычно не являются экспертами в той профессиональной области, для которой пишут ПО. Например, я помогал писать ПО, которое управляет заводскими роботами; руководит сложными финансовыми операциями; анализирует данные, получаемые от научного оборудования; проводит актуарные расчеты. Начиная работать с этими командами, я не знал ничего обо всех этих вещах. Это дилемма. Люди, которые разбираются в проблемной области (эксперты в предметной области), редко имеют квалификацию, необходимую для написания программ. Люди, которые могут писать программы (программисты), не всегда понимают что-либо в проблемной области. Преодоление этой проблемы — фундаментальный вопрос коммуникации. Эксперты в предметной области Задача — передать эти передают свои знания программистам, которые, в свою знания ясно и точно. очередь, кодируют эти знания в ПО. Задача — передать эти знания ясно и точно.

432  Часть III.  Надежная поставка

Говорить на одном языке Программисты должны говорить на языке экспертов в предметной области, а не наоборот. В свою очередь, эксперты должны говорить программистам, когда язык, который они используют, некорректен или запутывает. Под «языком» я подразумеваю термины и определения, которые используют ваши эксперты, а не буквально их родной язык. Представьте, что вы создаете программу для набора музыкальных партитур. Издательство, на которое вы работаете, предоставляет описание музыки в XML, и вам необходимо правильно его отобразить. Это трудная задача, наполненная на первый взгляд незначительными стилистическими выборами, которые жизненно важны для ваших заказчиков. В этой ситуации вы можете сфокусироваться на элементах XML, родительских элементах (parents), дочерних элементах (children) и атрибутах (attributes). Вы можете говорить о контекстах устройств, растровых изображениях и глифах. Если бы вы это делали, то ваш разговор звучал бы примерно так: Программист: Мы хотели бы узнать, как нам отображать этот ключевой элемент. Например, если первый дочерний элемент — G, а второй — 2, а элемент изменения октавы — это –1, то какой глиф нам использовать? Это скрипичный ключ? Эксперт (думая про себя: «Я понятия не имею, о чем они говорят. Но если признаюсь в этом, то они скажут в ответ что-то еще более непонятное. Лучше подыграю».): Хм-м.. конечно, G — это скрипичный. Отлично.

Вместо этого сконцентрируйтесь на терминах предметной области, а не на технических: Программист: Мы хотели бы узнать, как нам набирать этот ключ G. Он находится на второй линии нотного стана, но на одну октаву ниже. Это скрипичный ключ? Эксперт (думая про себя: «Ну это просто»): Он часто используется для партии тенора в хоровой музыке. Это скрипичный ключ, да, но поскольку он октавой ниже, мы используем два символа вместо одного. Я сейчас покажу вам пример.

Ответ эксперта во втором примере различается, поскольку он понял вопрос. Разговор из первого примера, скорее всего, приведет к багу в ПО.

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

Глава 12.  Сотрудничество   433

Программист: Я брал уроки фортепиано в детстве, поэтому знаю основы музыкальной грамоты. Но это было давно. Можете пройтись со мной по этой теме с самого начала? Эксперт: Мы набираем музыку для ансамблей и оркестров, так что это не совсем то же самое, что партитура для фортепиано, но ваш опыт будет полезен. Начнем с основ: партитура делится на нотные станы, каждый стан делится на такты, а ноты помещаются в такты. Программист: Понял. То есть основа в нашей программе — партитура. (Рисует квадрат и подписывает его «партитура».) Потом в каждой партитуре есть нотные станы. (Добавляет квадрат, подписанный «нотный стан», и рисует линию, соединяющую его с «партитурой».) В каждом нотном стане есть такты. (Добавляет еще один квадрат, подписанный «такт», и соединяете его с «нотным станом».) Сколько нотных станов может быть в партитуре? Эксперт: Это зависит от аранжировки. Четыре — для струнного квартета. Дюжина или больше — для оркестра. Программист: Но должен быть по меньшей мере один? Эксперт: Думаю, да. Партитура без хотя бы одного нотного стана не имеет смысла. У каждого инструмента должен быть нотный стан или несколько в случае инструментов с большим диапазоном, таких как пианино и орган. Программист: Окей, я немного запутался. У вас есть примеры, которые я мог бы посмотреть? Эксперт: Конечно. (Достает пример1.) Вот здесь наверху вы можете увидеть хор. Тут есть нотный стан для каждой партии, которую можно считать тем же, что и инструмент: сопрано, альт, тенор и бас. Потом идет большой нотный стан для арфы, большой и обычный нотные станы для органа и т. д. Программист (корректируя свой набросок на доске): То есть мы начинаем с партитуры, у каждой партитуры есть несколько инструментов, и у каждого инструмента — один или несколько нотных станов, и нотный стан может быть обычный или большой. И еще похоже, что инструменты могут быть сгруппированы. Эксперт: Верно, мне следовало это сказать. Инструменты могут быть сгруппированы в секции. Знаете, секция струнных инструментов, духовая секция. Программист (снова корректируя свой набросок): Понял. У нотного стана есть секции, в секциях есть инструменты и потом все остальное. Эксперт (смотрит на рисунок): Это только начало, многого пока не хватает. Нам нужны ключ, тональность и тактовый размер…

Результат этого разговора — нечто гораздо большее, чем просто набросок на дос­ ке. Он также может стать основой модели предметной области [Fowler2002] (гл. 9) в вашем коде. Она нужна не для каждой программы, но если ПО вашей команды подразумевает сложные правила предметной области, то данная модель — эффективный инструмент разработки. Вот здесь есть пример нот для оркестра: https://oreil.ly/HP5Zp.

1

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

Рис. 12.1. XML и предметно-ориентированное проектирование

Код не должен быть двусмысленным. Такая необходимость в жесткой формализации приводит к большему количеству обсуждений и проясняет непонятные детали. Я часто вижу ситуации, в которых программисты сталкиваются со сложной проблемой дизайна, задают вопрос эксперту в предметной области, и это, в свою очередь, приводит к тому, что эксперт ставит под сомнение некоторые из их изначальных предположений. Таким образом, ваш единый язык — это живой язык. Он хорош настолько, насколько хороша его способность отражать реальность. Как только проясните все детали с экспертами, закодируйте все, что узнали, в свою модель предметной области. Если она выявляет двусмысленности, то обращайтесь к экспертам, чтобы их прояснить. В ходе работы удостоверяйтесь, что ваш дизайн и язык, который вы разделяете с экспертами, См. также синхронизированы. Делайте рефакторинг кода, когда меняется ваше понимание предметной обРефакторинг (глава 13) ласти. Если этого не делать, то в итоге ваш дизайн не будет соответствовать реальности, что приведет к уродливым ляпам и багам.

Глава 12.  Сотрудничество   435

Вопросы Должны ли мы все вместе избегать использования технических терминов? В нашей предметной области бизнеса не упоминается ничего о GUI-виджетах или базе данных. Нормально использовать технический язык в тех областях, которые не имеют отношения к предметной области. Например, возможно, имеет смысл называть подключение к базе данных подключением, кнопку UI — кнопкой. Как нам документировать наш единый язык? В идеале вы кодируете свой единый язык в реальном дизайне вашего ПО с помощью модели предметной области. Если это не подходит, то вы можете задокументировать вашу модель на доске (можно на виртуальной), в общем документе или на Вики-странице. Однако будьте осторожны: поддержание этого типа документации в актуальном состоянии требует большого внимания. Преимущество использования кода для документаСм. также ции заключается в том, что код не может не отражать то, что ваше ПО делает на самом деле. С некоторой Простой дизайн (глава 14) долей осторожности вы можете разработать свой код так, чтобы он был самодокументированным. Мы программируем на английском, но это не наш родной язык, и наши эксперты в предметной области его не используют. Нужно ли нам переводить их термины на английский, чтобы единообразить с остальным нашим кодом? На ваше усмотрение. С одной стороны, слова не всегда переводятся напрямую, поэтому использование языка вашего эксперта в предметной области, вероятно, будет приводить к меньшему количеству ошибок, особенно если эксперты могут слушать и участвовать в разговорах программистов. С другой стороны, единообразие может облегчить другим работу с вашим кодом в будущем. Если вы решите переводить термины вашего эксперта на английский (или другой язык), то создайте словарь перевода для слов, которые используете, особенно для тех, перевод которых затруднен.

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

436  Часть III.  Надежная поставка что может быть непросто. Для начала изучите подраздел «Литература для дополнительного чтения» и подумайте о том, чтобы нанять коуча, который поможет вам в обучении.

Показатели zz zz zz

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

Альтернативы и эксперименты Говорить на языке экспертов предметной области — это всегда хорошая идея, но предметно-ориентированное проектирование — не всегда хороший выбор. Иногда ориентированное на технологию проектирование более простое. Это чаще всего так, когда ваши правила предметной области не очень сложные. Однако будьте осторожны: правила этой области могут быть более сложными, чем кажется на первый взгляд, и в этом случае ориентированное на технологию проектирование, как правило, имеет дефекты и высокие затраты на техническое обслуживание. Дальнейшее обсуждение этого компромисса см. в [Fowler2002]. Другой способ сформировать общее понимание предметной области — использовать метод штурма событий (event storming) Альберто Брандолини, который начинается с событий, случающихся в предметной области, а не с имен и отношений в ее модели. На момент написания этой книги каноническая книга Event Storming все еще писалась, но на странице https://www.eventstorming.com есть указатели на дополнительные ресурсы.

Литература для дополнительного чтения Domain-Driven Design: Tackling Complexity in the Heart of Software1 [Evans2003] — исчерпывающее руководство по созданию предметно-ориентированного проектирования. Глава 2, Communication and the Use of Language, послужила источником вдохновения для этой практики. В Patterns of Enterprise Application Architecture2 [Fowler2002] содержится хорошая дискуссия о компромиссах между моделями предметной области и другими архитектурными подходами в главе 2 (Organizing Domain Logic) и главе 9 (Domain Logic Patterns). Эванс Э. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем.

1

Фаулер М. Шаблоны корпоративных приложений.

2

ГЛАВА 13

Разработка

Это поразительно, насколько редко процессы разработки ПО на самом деле говорят о практических деталях разработки. Способ, которым ваша команда ведет разработку, имеет значение. Именно так вы проводите бо́льшую часть вашего времени. Эта глава содержит практики, которые могут ускорить вашу разработку и сделать ее более надежной. zz Практика «Нулевое трение» позволяет ликвидировать задержки, замедляющие процесс разработки. zz Практика «Непрерывная интеграция» обеспечивает готовность вашего последнего кода к релизу. zz С помощью практики «Разработка через тестирование » вы сможете делать так, чтобы ваше ПО выполняло именно то, что от него хотят программисты. zz Благодаря практике «Быстрые надежные тесты» тестирование не станет узким местом. zz Практика «Рефакторинг» позволяет программистам улучшить дизайн существующего кода. zz Практика «Спайк-решения» помогает программистам учиться с помощью небольших изолированных экспериментов.

Источники разработки Впервые я столкнулся с практиками, описанными в этой главе, в экстремальном программировании. Некоторые из них отсутствуют в оригинальных книгах об XP; вместо этого они упоминались в обсуждениях XP на Вики-страницах Уорда Каннингема на c2.com. Практика «Нулевое трение» — это современная версия «Десятиминутной сборки» в XP. Практика «Непрерывная интеграция» также пришла из XP. Ее обычно понимают не совсем верно, поэтому придумывают для нее новые названия (особенно популярны «магистральная разработка» (trunk-based development) и «непрерывная поставка» (continuous delivery)), но непрерывная интеграция в том виде, в котором ее определяет XP, охватывает оба варианта [Beck2004] (гл. 7).

438  Часть III.  Надежная поставка

Практика «Разработка через тестирование» — одна из самых известных практик XP. Изначально она называлась Test-First Programming. Связанная с ней практика «Быстрые надежные тесты» основана на моем опыте реального применения TDD в течение последних двух десятилетий, наряду с изрядной дозой вдохновения и идей, заимствованных из широкого сообщества Agile. Практика «Рефакторинг» предшествовала XP, но XP вывело ее в мейнстрим как основную. Практика «Спайк-решения» пришла из языка шаблонов EPISODES Уорда Каннингема [Cunningham1995]. Она основана на опыте его работы с Кентом Беком в Tektronix. Уорд Каннингем написал на Вики-странице на C2: «Я часто спрашивал Кента: “Какую простейшую вещь мы можем запрограммировать, которая убедит нас в том, что мы на правильном пути?” Такой выход за пределы имеющихся трудностей часто вел нас к более простым и убедительным решениям. Кент назвал этот процесс спайком»1.

НУЛЕВОЕ ТРЕНИЕ Когда мы готовы писать код, ничто не может нам помешать.

Аудитория Программисты, отдел эксплуатации

Представьте, что вы только начали работать с новой командой. Один из ваших новых товарищей по команде, Педро, сопровождает вас к рабочей станции разработчиков. — Так как ты новенький, мы начнем с развертывания маленького изменения, — говорит он, усаживаясь рядом. — Эта машина абсолютно новая, поэтому нам придется настроить ее с нуля. Сначала клонируем репо. — Он говорит вам команду. — Теперь запускаем скрипт build. Команды начинают бежать по экрану. — Мы используем программный инструмент для воспроизводимых сборок, — объясняет Педро. — Он определил, что у нас ничего не установлено, поэтому он инсталлирует IDE, инструментарий разработки и образы, необходимые для разработки и локального запуска системы. — Это займет некоторое время, — продолжает он. — Однако после первого запуска это происходит мгновенно. Инструмент снова обновляется только тогда, когда мы вносим изменения в конфигурацию. Давай я покажу тебе офис. Когда вы возвращаетесь, сборка завершена. — Окей, давай я покажу тебе приложение, — говорит Педро. — Набери rundev, чтобы запустить его. Информация снова начинает бежать по экрану. — Все это запускается локально, — гордо объясняет Педро. — Раньше у нас была общая тестовая среда, и мы постоянно наступали друг другу на пятки. Теперь это все Выдержка из спайк-решений на странице https://oreil.ly/QUTY6.

1

Глава 13.  Разработка  439

в прошлом. Сборка даже знает, какие сервисы запускать повторно в зависимости от того, какие файлы меняешь. Педро показывает вам приложение. — Теперь внесем изменения. Запусти watch quick. Он создаст и протестирует файлы, которые мы изменяем. Вы выполняете его инструкции, скрипт начинает работу и сразу выдает BUILD OK зеленым цветом. — Ничего не менялось с момента последнего запуска сборки, — объясняет Педро. — Поэтому скрипт ничего не сделал. Теперь внесем небольшое изменение. Он направляет вас к тестовому файлу, и вы добавляете тест. Когда вы сохраняете изменения, скрипт watch снова запускается и сообщает о сбое теста. Это занимает меньше секунды. — Мы очень много работали над скоростью нашей сборки и тестирования, — говорит вам Педро. Он явно гордится этим. — Это было непросто, но оно того стоило. Мы получаем обратную связь о большинстве изменений через секунду или две. Это сотворило чудеса с нашей способностью работать итерациями и быть продуктивными. Я не совру, если скажу, что это лучшая среда разработки из всех, в каких я только работал. Теперь завершим эти изменения и сделаем развертывание. Педро показывает вам изменения, которые необходимо внести для прохождения нового теста. Когда вы сохраняете изменения, скрипт watch снова запускает тесты примерно через секунду. В этот раз он сообщает об успешном результате. — Окей, теперь мы готовы к развертыванию, — говорит Педро. — Это пойдет в эксплуатационную среду, но не волнуйся. Скрипт deploy запустит полный набор тестов, и у нас также есть канареечный сервер, который проверяет, чтобы не случилось ничего плохого. Набери deploy, чтобы начать. Вы запускаете скрипт и наблюдаете за его работой. Через несколько минут он выдает сообщение INTEGRATION OK, затем начинает развертывать код. «Все, — сияя, говорит Педро. — Когда интеграция проходит успешно, можно предполагать, что развертывание тоже будет успешным. Если что-то пойдет не так, то мы получим сообщение. Добро пожаловать в команду!» Прошло меньше часа, а вы уже выполнили развертывание в эксплуатационную среду. Это разработка с нулевым трением: когда вы готовы писать код, ничто не может встать у вас на пути.

Обратная связь за секунду Скорость разработки — та область, где устранять трение очень важно. Когда вы вносите Когда вы вносите изменение, вам нужно получить обратную связь изменение, вам нужно получить обратную менее чем через пять секунд. связь об этом изменении менее чем через пять секунд. Лучше — менее чем через одну секунду. Самое большое — десять. Этот вид быстрой обратной связи меняет все. Вам легко экспериментировать и работать итерациями. Вместо того чтобы вносить большие изменения, вы можете работать очень маленькими шагами. Каждое изменение может состоять всего из

440  Часть III.  Надежная поставка одной или двух строчек кода, а это значит, вы всегда знаете, где у вас ошибки. Отладка становится чем-то из прошлого. Если обратная связь занимает меньше секунды, то она функционально мгновенна. Вы вносите изменение, смотрите на отклик и продолжаете работу. Если на это уходит от одной до пяти секунд, то процесс, по ощущениям, не будет мгновенным, но все еще приемлемым. Если на все уходит от пяти до десяти секунд, то процесс будет ощущаться как медленный. Вы начнете испытывать соблазн сгруппировать изменения. А если обратная связь будет занимать больше десяти секунд, то вы не сможете продвигаться маленькими шагами, и это будет вас замедлять. Чтобы достичь секундной обратной связи, установите скрипт watch, который будет См. также автоматически проверять ваш код, когда вы внесете изменение. Внутри скрипта исРазработка через тестирование пользуйте компилятор или линтер, кото(глава 13) рый будет сообщать вам о синтаксических ошибках, и тесты, которые будут сообщать о семантических ошибках. В качестве альтернативы вы можете настроить вашу IDE на проверку синтаксиса и запуск тестов, а не на написание скрипта. Это может быть простым способом начать работу, хотя в конечном итоге вам придется перейти на скрипт. Если вы начнете с подхода на основе IDE, то убедитесь, что его конфигурацию можно передать в ваш репозиторий и использовать всеми в команде. Вам понадобится возможность легко делиться усовершенствованиями. Когда вы сохраняете изменения, скрипт (или IDE) должен давать вам немедленную и недвусмысленную обратную связь. Если все работает, то он должен выдать сообщение ÎÊ. Если что-то не так, то он должен выдать сообщение FAILED и предоставить информацию, которая поможет вам решить проблему. Большинство людей настраивает свои инструменты так, чтобы они показывали зеленую полосу в случае успеха и красную — в случае неудачи. Вдобавок к этому я программирую свои инструменты так, чтобы они издавали какие-либо звуки (один звук для ошибок компилятора/линтера, другой — для ошибок в тесте и третий — для успешного завершения), но так делаю только я. По мере расширения вашей кодовой См. также базы добиться секундной обратной связи станет труднее. Обычно первый виновник — Быстрые надежные тесты (глава 13) скорость тестирования. Сконцентрируйтесь на написании быстрых надежных тестов. По мере продолжения роста вашей системы скорость сборки (компиляция или линтинг) станет проблемой. Решение будет зависеть от вашего языка. Поиск в сети по фразе «ускорить сборку » поможет вам начать. Обычно это будет подразумевать поэтапные (инкрементальные) сборки: кеширование части сборки так, чтобы перестраивался только код, в который внесли изменения. Чем больше будет становиться ваша система, тем более креативными вам нужно быть. В конце концов вам, вероятно, понадобится сконфигурировать две сборки: одну для быстрой обратной связи и другую для развертывания в эксплуатационную среду.

Глава 13.  Разработка  441

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

Знайте свой редактор Не давайте вашему редактору кода мешать вашему потоку мыслей. Это особенно важно в парном или групповом программировании: когда вы штурман, мало что может расстраивать больше, чем наблюдение за тем, как водитель борется с редактором. Не жалейте времени, чтобы научиться пользоваться вашим редактором действительно хорошо. Если в редакторе доступен автоматизированный рефакторинг, то узнайте, как им пользоваться. (Если нет, то поищите редактор получше.) Используйте преимущества автоформатирования и отправляйте конфигурационный файл форматирования в ваш репозиторий, чтобы вся ваша команда была синхронизирована. Научитесь использовать автодополнение кода, автоматические исправления, поиск функций и методов и навигацию по справочным материалам. Выучите комбинации горячих клавиш. Чтобы увидеть примеры того, насколько может улучшить жизнь хорошее владение редактором, посмотрите виртуозное представление Эмили Бач в ее видео Gilded Rose, особенно часть 2 [Bache2018].

Воспроизводимые сборки Что происходит, когда вы проверяете произвольный коммит из вашего репозитория? Скажем, годичной давности. (Попробуйте!) Он все еще работает? А тесты проходят? Или он требует какой-то эзотерической комбинации из инструментов и внешних сервисов, которые уже канули в Лету?

442  Часть III.  Надежная поставка Воспроизводимая сборка — это сборка, Каждое подтверждение (коммит) которая продолжает работать и проходолжно работать одинаково у любого дить свои тесты независимо от того, каразработчика. кие средства разработки вы используете и сколько лет коду, сборку которого вы выполняете. У вас должна быть возможность проверить любой коммит и ожидать, что он будет работать одинаково у любого разработчика. Вообще говоря, это требует двух вещей.

Управление зависимостями Зависимости (dependencies) — это библиотеки и программные инструменты, которые нужны вашему коду для работы. Сюда входят компилятор или интерпретатор, среда времени выполнения, пакеты, скачанные из вашего репозитория пакетов языков, код, написанный другими командами в вашей организации, и т. д. Чтобы ваша сборка была воспроизводимой, каждому нужно иметь одни и те же зависимости. Программируйте вашу сборку так, чтобы обеспечить корректную версию каждой зависимости. Она может или выдавать ошибку, когда установлена некорректная версия, или (что предпочтительнее) автоматически устанавливать правильную версию. Среди инструментов, которые это делают, — Nix, Bazel и Docker. Проверьте также версию вашего инструмента управления зависимостями. Простой способ сделать так, чтобы ваше ПО имело корректные зависимости, — поместить их в ваш репозиторий. Это называется вендорингом (vendoring). Вы можете смешать два подхода: например, команда с кодовой базой Node.js сделала вендоринг для своего каталога node_modules, но не сделала Node исполнимым. Вместо этого они запрограммировали свою сборку так, чтобы она давала сбой, если работала неправильная версия Node.

Локальные сборки Управление зависимостями обеспечивает одинаковую работу вашего кода на любой машине, но не делает того же для ваших тестов. Ваши тесты должны запускаться полностью локально, не связываясь через сеть. Иначе у вас, вероятно, будут противоречивые результаты, когда два человека делают тесты одновременно, и вы не сможете тестировать старые версии. Сервисы и данные, от которых они зависят, изменятся, и тесты, которые раньше проходили, станут сбоить. То же самое верно для случаев, когда вы запускаете код вручную. Чтобы получать непротиворечивые результаты и иметь возможность запускать старые версии, все, от чего зависит код, должно быть инсталлировано локально. Могут быть какие-то зависимости, которые невозможно запустить локально. В таком случае вам нужно запрограммировать свои тесты, чтобы они работали независимо от этих зависимостей, или у вас может не быть возможности воспроизвести результаты своих тестов в будущем. В подразделе «Моделирование нелокальных зависимостей» далее в текущей главе описывается, как это сделать.

Глава 13.  Разработка  443

Пятиминутная интеграция Если вы используете непрерывную интеграцию, то будете интегрировать несколько раз в день. Данный процесс должен быть сверхнадежным и быстрым. Это значит, для него нужен скрипт. Ваш скрипт должен выдавать успешный или неуспешный результат в течение пяти минут — максимум десяти. Пятиминутные результаты на удивление важны. Пяти минут достаточно для неСм. также большого перерыва и новой чашки кофе, Непрерывная интеграция (глава 13) пока вы следите за результатами. Десять минут — терпимо, но начинает наскучивать. Больше — и люди начнут работать над другими задачами, пока дожидаются получения результатов. Далее, если интеграция неуспешна, код останется в подвешенном состоянии, пока кто-нибудь к нему не вернется. На практике это ведет к системной интеграции и проблемам сборки. Не нужно, чтобы скрипт буквально завершался за пять минут, хотя это и желательно. Вместо этого он должен проверять код и выдавать успешный или неуспешный результат, прежде чем переходить к более длительным проверкам. В под­разделе «Многоступенчатые интеграционные сборки» далее в текущей главе объясняется, как это работает. Большинство команд не могут испольСм. также зовать пятиминутную интеграцию именно из-за скорости набора тестов. Решение — исБыстрые надежные тесты (глава 13) пользовать быстрые надежные тесты. КЛЮЧЕВАЯ ИДЕЯ

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

444  Часть III.  Надежная поставка

Контролировать сложность Часто упускаемый из виду источник трения команд разработки — сложность их среды разработки. См. также Стремясь сделать работу быстро, команды выПростой дизайн (глава 14) бирают популярные инструменты, библиотеки и фреймворки, чтобы решать общие проблемы разработки. По отдельности в этих инструментах нет ничего плохого. Но любой длительный процесс программной разработки должен иметь специализированные инструменты, и именно здесь быстрый и простой подход начинает подводить. Все эти инструменты, библиотеки и фреймворки создают огромную когнитивную нагрузку, особенно когда вам нужно погрузиться в их внутреннее устройство, чтобы заставить слаженно работать вместе. В конечном итоге все это добавляет трения. Гораздо важнее оптимизировать затраты на сопровождение, чем на изначальную разработку, как объяснялось во врезке «Оптимизировать для сопровождения» ранее в данной главе. Будьте внимательны к сторонним зависимостям, которые вы используете. Выбирая одну из них, думайте не только о проблеме, которую она решает; думайте о нагрузке на сопровождение, которую добавит эта зависимость, и о том, насколько хорошо она будет встраиваться в существующие системы. Простой инструмент или библиотека, которые могут вызывать ваши скрипты, будут отличным вариантом. Сложный «черный ящик» — вероятно, нет. В большинстве случаев лучше всего обернуть сторонний инструмент или библио­ теку в код, который вы контролируете. Задача вашего кода — скрыть базовую сложность и представить простой интерфейс, адаптированный под ваши потребности. В подразделе «Сторонние компоненты» главы 14 можно найти дальнейшие пояснения.

Автоматизировать все Автоматизируйте любое действие, которое команда выполняет неоднократно. Это не только снизит трение, но и уменьшит вероятность ошибок. Для начала это означает пять скриптов: zz build — использовать компилятор и/или линтер, запускать тесты и сообщать об успехе или неудаче; zz watch — автоматически запускать build при изменении файла; zz integrate — запускать build в среде, идентичной эксплуатационной, и интегрировать свой код; zz deploy — запускать integrate, затем разворачивать интеграционную ветку; zz rundev — запускать ПО локально для оценки и тестирования вручную. Конечно, вы можете использовать любые имена, какие захотите. Используйте реальный язык программирования для ваших скриптов. Они могут обращаться к инструментам, часть которых может иметь собственные конфигурационные языки, но организуйте их все с помощью реального кода, которым вы

Глава 13.  Разработка  445

управляете. По мере того как ваша автоматизация будет усложняться, вы оцените, насколько эффективен реальный язык программирования. Обращайтесь с вашими скриптами так же бережно, как и с реальным рабочим кодом. Вам не нужно писать тесты для них — скрипты может быть очень трудно тестировать, — но уделяйте внимание тому, чтобы они были хорошо написаны и продуманы и их было легко понять. Позже вы себя за это будете благодарить. У вас может появиться соблазн использовать свою IDE вместо скрипта watch. Для начала это нормально, но вам все равно понадобится автоматизировать вашу сборку для скрипта integrate, поэтому в итоге вы можете прийти к необходимости сопровождать две отдельные сборки. Кроме того, остерегайтесь блокировки: в конечном итоге IDE не сможет обеспечивать секундную обратную связь. Когда это происходит, вместо того чтобы бороться с IDE, переключитесь на подходящий подход на основе скриптов. Он более гибкий.

Автоматизируйте инкрементно Совершенствуйте вашу автоматизацию непрерывно и инкрементно (инкрементами), начиная с самой первой истории. В абсолютно новой кодовой базе это означает, что вашей первой задачей разработки станет настройка скриптов. Придерживайтесь простой автоматизации. Поначалу вам не нужны сложные инкрементные сборки или анализ графов зависимостей. Прежде чем вы напишете любой код, начните с написания скрипта build, который будет просто отвечать build OK. И ничего больше! Это как hello world для вашей сборки. Потом напишите скрипт watch, который не делает ничего, кроме запуска build при изменении файлов. Когда заработают build и  watch, создайте подобным образом пустой скрипт integrate. Поначалу ему нужно будет только запустить build в первозданной среде и интегрировать ваш код. В подразделе «Танец непрерывной интеграции» далее в текущей главе описывается, как это работает. Когда заработает скрипт integrate, вы готовы конкретизировать build. Напишите ничего не выполняющий код входной точки для вашего приложения. Он может просто говорить Hello world. Запустите build, чтобы скомпилировать сборку или выполнить линтинг, потом добавьте управление зависимостями для компилятора или линтера. Для начала оно может проверять номер версии относительно какой-либо константы, или вы можете инсталлировать программный инструмент для управления зависимостями. В качестве альтернативы вы можете использовать вендоринг для ваших зависимостей. Далее добавьте инструмент модульного тестирования и неуспешный тест. Не забудьте также добавить управление зависимостями для инструмента тестирования. Пусть скрипт build запустит тест, тот должным образом пройдет неуспешно и выдаст код ошибки. Далее проверьте, что скрипты watch и integrate корректно обрабатывают ошибки, и затем дайте тесту пройти успешно. Теперь вы можете добавить скрипт rundev. Скомпилируйте его, если необходимо, и запустите ваше ничего не делающее приложение. Сделайте так, чтобы оно автоматически перезапускалось при изменении исходных файлов. Сделайте рефакторинг так,

446  Часть III.  Надежная поставка чтобы скрипты build, watch и rundev не содержали дубликатов кода для наблюдения за файлами или компиляции. В конце создайте скрипт deploy. Дайте ему запустить integrate (не забудьте обработку сбоев) и затем разверните интеграционную ветку. Начните с развертывания на промежуточный сервер. Каким будет правильный способ — зависит от вашей системной архитектуры, но у вас есть только один рабочий файл, так что вам не нужно ничего сложного. Просто разверните этот один файл и его среду выполнения на одном сервере. Это так же просто сделать, как использовать scp или rsync. Для всего более сложного (обработки сбоев, мониторинга, конфигурирования (provisioning)) нужна история. (Например, «Сайт продолжает работать после аварии».) По мере роста вашей системы автоматизация тоже будет увеличиваться. ПРИМЕЧАНИЕ Если вы не выполняете развертывание на сервер, а вместо этого распространяете инсталляционные пакеты, то создайте с помощью deploy простой дистрибутивный пакет. Начните с пустого пакета, например ZIP-файла, просто содержащего ваш один рабочий файл и его среду выполнения. Более красивую и удобную для пользователя установку можно запланировать позже с помощью пользовательских историй.

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

Автоматизация устаревшего кода Роскошь увеличения автоматизации одновременно с кодом может оказаться недоступной. Часто вам придется добавлять автоматизацию к уже существующему коду. Начните с создания пустых скриптов build, rundev, integrate и  deploy. Пока ничего не автоматизируйте, только найдите документацию для каждой из этих задач и настройте скрипт так, чтобы он выдавал результаты на консоль. Например, скрипт deploy может выдать 1. Run esoteric_command 2. Load https://obscure_web_page и т. д. Дождитесь нажатия клавиши после каждого шага. Такая простая «автоматизация» не должна занимать много времени, так что вы сможете создавать каждый скрипт за счет вашего резерва времени. Когда будете

Глава 13.  Разработка  447

создавать каждый скрипт, он будет станоСм. также виться вашим новым источником истины с контролем версии. Старую документацию Резерв времени (глава 9) или удалите, или скорректируйте так, чтобы она описывала, как запустить скрипт. Далее используйте ваш резерв времени, чтобы постепенно автоматизировать каждый шаг. Сначала автоматизируйте самые простые шаги, затем сфокусируйтесь на тех, которые вызывают наибольшее трение. Ваши скрипты пока будут содержать смесь автоматизации и пошаговых инструкций. Продолжайте, пока скрипты не станут полностью автоматическими, затем начните искать возможности для дальнейшего совершенствования и упрощения. Когда скрипт build станет полностью автоматизированным, вы, вероятно, поймете, что он слишком медленный для секундной обратной связи (или даже десятисекундной обратной связи). В итоге вы захотите иметь сложный поэтапный подход, но можете начать с определения небольших фрагментов вашей кодовой базы. Обеспечьте цели сборки, которые позволят вам собирать и тестировать каждый фрагмент по отдельности. Чем меньше будут фрагменты, тем легче будет преодолеть десятисекундный порог. Как только широко используемая цель сборки составляет меньше десяти секунд, она становится достаточно быстрой, чтобы имело смысл создать скрипт watch. Продолжайте оптимизировать, с помощью вашего резерва времени внося небольшое усовершенствование за раз, пока не добьетесь, чтобы все цели были менее пяти секунд. В какой-то момент модифицируйте сборку, чтобы она автоматически выбирала цели, основываясь на том, что изменилось. Дальше совершенствуйте скорость и надежСм. также ность развертывания. Вероятно, это потребует улучшения тестов, так что займет какое-то Быстрые надежные тесты (глава 13) время. Как и раньше, используйте ваш резерв времени и улучшайте понемногу за раз. Если тест дает сбой в случайном порядке, сделайте его детерминированным. Если вас замедляют широкие тесты, замените их более узкими. В подразделе «Добавление тестов к существующему коду» далее в текущей главе объясняется, что нужно делать. Код никогда не будет идеальным, но в конце концов те части, с которыми вы работаете чаще всего, будут максимально усовершенствованы. Продолжайте использовать ваш резерв времени, чтобы вносить улучшения, как только столкнетесь с трением.

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

См. также Игра в планирование (глава 8) Резерв времени (глава 9)

448  Часть III.  Надежная поставка Кроме того, используйте ваш резерв времени, чтобы вносить усовершенствования, как только будете сталкиваться с пробуксовками. Но помните, что резерв времени предназначен для дополнительного усовершенствования. Если история требует изменений в автоматизации, то построить автоматизацию (и оставить скрипт, с которым вы поработали, хотя бы немного улучшенным, чем когда вы его нашли) — это часть разработки истории, а не часть вашего резерва времени. История не сделана, пока не сделана автоматизация. Кто отвечает за написание и поддержку См. также скриптов? Ими коллективно владеет вся команда. Коллективное владение кодом На практике члены команды с навыками про(глава 12) граммирования и эксплуатации берут на себя ответственность за них. У нас есть еще одна команда, которая отвечает за создание и развертывание средств автоматизации. Что нам делать? Рассматривайте их автоматизацию таким же образом, как вы рассматриваете любые сторонние зависимости. Инкапсулируйте их инструменты в скрипты, находящиеся под вашим контролем. Это даст вам возможность адаптировать их при необходимости. Когда происходит миграция базы данных? Миграция — часть вашего развертывания, но она может происходить после завершения развертывания. Более подробная информация доступна в подразделе «Миграция данных» главы 15.

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

Показатели Когда ваша команда работает с нулевым трением: zz

вы проводите время, занимаясь разработкой, а не программными инструментами, чек-листами и документацией о зависимостях;

zz

вы можете работать очень маленькими шагами, что позволяет вам обнаруживать ошибки на раннем этапе и тратить меньше времени на отладку;

Глава 13.  Разработка  449 zz

настройка новой рабочей станции для разработки — всего лишь вопрос клонирования репозитория и запуска скрипта;

zz

вы можете выполнять интеграцию и развертывание несколько раз в день.

Альтернативы и эксперименты Разработка с нулевым трением — идеал, к которому должна стремиться каждая команда. Лучший способ сделать это зависит от вашей ситуации, поэтому не бойтесь экспериментировать. Некоторые команды полагаются на свою IDE, а не на скрипты, чтобы обеспечить необходимую автоматизацию. Другие используют большие «доморощенные» инструментарии со сложными языками конфигурации. Я считаю, что эти подходы перестают работать, когда потребности команды возрастают. Такие подходы могут быть удобными вначале, но когда вы продолжаете работу, переключение может стать болезненным, и будет трудно делать это инкрементно. Будьте скептичны при оценке сложных инструментов, обещающих покрыть все ваши потребности в автоматизации.

НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ Мы держим наш последний код готовым к выпуску.

Аудитория Программисты, отдел эксплуатации

В большинстве случаев в программной разработке есть скрытый временной разрыв между моментом, когда команда говорит: «Мы закончили», и моментом, когда она действительно готова сделать релиз. Иногда этот разрыв может растягиваться на месяцы. Это ведь в сущности «такая мелочь»: заставить заработать код, написанный разными людьми, написать скрипт развертывания, предварительное заполнение базы данных и т. д. Непрерывная интеграция — более совершенный подход. Команды, использующие ее, поддерживают общий код в работающем и готовом к релизу состоянии. Конечная цель непрерывной интеграции — сделать релиз коммерческим, а не техническим реКогда заказчики в команде готовы шением. Когда заказчики в команде готовы к релизу, вы нажимаете кнопку к релизу, вы нажимаете кнопку и делаете и делаете его. его. Без суеты, без суматохи. Кроме того, непрерывная интеграция является неотъемлемой частью коллективСм. также ного владения кодом и рефакторинга. Если все вносят изменения в один и тот же код, Коллективное владение кодом (глава 12) то им нужен какой-то способ разделять эту работу. Непрерывная интеграция подходит Рефакторинг (глава 13) для этого как нельзя лучше.

450  Часть III.  Надежная поставка

Непрерывная интеграция — это практика, а не инструмент Одним из самых первых пользователей непрерывной интеграции была ThoughtWorks, аутсорсинговая фирма разработки ПО. Она создала инструмент, называемый «круиз-контроль» (CruiseControl), чтобы автоматически запускать свои скрипты непрерывной интеграции. Разработчики назвали его сервером непрерывной интеграции (continuous integra­ tion (CI) server), также называемым CI/CD-сервер или сервер сборки. С того времени популярность этих инструментов возросла в разы. Они настолько популярны, что инструменты стали подменять собой реальную практику. Сейчас многие думают, что «непрерывная интеграция» означает использование CI-сервера. Это не так. CI-серверы управляют лишь небольшой частью непрерывной интеграции: собирают и объединяют код по сигналу. Но непрерывная интеграция — нечто гораздо большее, чем запуск сборки. Фундаментально — это способность сделать релиз Непрерывная интеграция — нечто последней готовой работы вашей команды по гораздо большее, чем запуск сборки. желанию. Ни один инструмент не сделает это за вас. Для этого требуются три вещи.

Выполняйте интеграцию несколько раз в день Интеграция означает процесс объединения всего кода, написанного командой. Обычно это подразумевает объединение кода, полученного от каждого члена команды, в общей ветви вашего репозитория исходного кода. Эта ветвь проходит под множеством вариантов названий. Наиболее часто встречающиеся — «главная», «мастер», «магистральная». Я использую «интеграционная», поскольку люблю ясные названия, а это как раз то, для чего эта ветвь предназначена. Но вы можете использовать любое название, на ваш вкус. Команды, практикующие непрерывную интеграцию, выполняют интеграцию как можно чаще. Это «непрерывная» часть понятия непрерывной интеграции. Люди выполняют интеграцию каждый раз, когда завершают задачу, до и после каждого большого рефакторинга, и всякий раз, когда готовы переключить передачу. Может пройти от нескольких минут до нескольких часов в зависимости от работы. Чем чаще, тем лучше. Некоторые команды даже интегрируют по мере появления каждого коммита. Если вы когда-нибудь сталкивались с многодневными, болезненными слияниями кода, то такая частая интеграция может показаться глупостью. Зачем проходить через такую боль лишний раз? Секрет непрерывной интеграции в том, что на самом деле она понижает риск неудачного слияния. Чем чаще вы ее выполняете, тем менее это болезненно. Более частые интеграции означают более мелкие слияния, а те, в свою очередь, означают меньшие шансы конфликтов слияния. У команд, использующих непрерывную интеграцию, все еще бывают случайные конфликты слияния, но они довольно редки и легко разрешаются.

Глава 13.  Разработка  451

Никогда не допускайте неисправности интеграционной ветви Когда последний раз вы потратили часы, отыИнтеграционная ветвь должна скиваия баг в своем коде, только чтобы обнавсегда хорошо проходить сборку ружить, что это вовсе не ваш код, а устаревшая и все тесты. конфигурация или чей-то еще код? И наоборот, когда последний раз вы потратили часы, обвиняя конфигурацию или чей-то еще код, а потом поняли, что все это время это был ваш код? Чтобы предотвратить подобные проблемы, интеграционная ветвь должна быть заведомо исправной. Она должна всегда хорошо проходить сборку и все тесты. На самом деле это проще, чем кажется. Вам См. также понадобится автоматизированная сборка с хорошим набором тестов, и как только она у вас Нулевое трение (глава 13) появится, гарантия заведомо исправной интеграционной ветви — всего лишь вопрос валиРазработка через тестирование (глава 13) дации объединенного кода до перемещения его в интеграционную сборку. Таким образом, если Быстрые надежные тесты (глава 13) сборка не удастся, то интеграционная ветвь останется в своем прежнем, заведомо исправном состоянии. Однако сборка должна быть быстрой и завершаться менее чем через 10 минут. Если это не так, то всем членам команды будет слишком трудно совместно работать над кодом. Можно обойти проблему медленной сборки с помощью многоступенчатой интеграции, как обсуждается в подразделе «Многоступенчатые интеграционные сборки» далее в текущей главе.

Поддерживайте интеграционную ветвь в состоянии готовности к релизу Каждая интеграция должна быть максимально приближена к реальному релизу. Цель — сделать подготовку к релизу настолько обычным делом, что, когда вы действительно его сделаете, это не будет каким-то событием. Одна команда, с которой я работал, дошла до того, что делала релизы несколько раз в неделю. Члены команды написали маленькое мобильное приложение с большой красной кнопкой. Бу­дучи готовыми к релизу, они шли в местный паб, заказывали что-нибудь и нажимали на кнопку. Это означает, что в каждой истории содержатся задачи по обновлению скриптов сборСм. также ки и развертывания по мере необходимости. Сделано Сделано (глава 9) Изменения в коде сопровождаются тестами. Решены проблемы с качеством кода. ПодготовСборка для эксплуатации (глава 15) лены скрипты для миграции данных. Важные, но незаметные истории, такие как журналы Флаги функций (глава 15) (логи) и аудит, приоритизированы наряду со

452  Часть III.  Надежная поставка своими функциональностями. Незавершенные функциональности отключаются с помощью флагов или ключей. «Быть максимально приближенным к реальному релизу» — значит запустить скрипт развертывания и видеть, что он действительно работает. Вам не нужно проверять развертывание в эксплуатационную среду (это уже непрерывное развертывание, более продвинутая практика), но вы должны проверить развертывание в тестовую среду. То же самое касается ПО, которое находится не в онлайн. Если вы делаете встроенное ПО, то установите его на тестовом оборудовании или симуляторе. Если вы делаете мобильное приложение, то создайте пакет для отправки (submission package). Если вы делаете настольное приложение, то подготовьте установочный пакет. Не откладывайте грязную работу на самый конец (см. врезку «Минимизируйте объем незавершенной работы» в главе 8). Делайте ее непрерывно, в течение всего процесса разработки. С самого первого дня фокусируйтесь на создании «ходячего скелета», который можно было бы выпустить, если бы у него было хоть немного «мяса на костях», и стабильно добавляйте его с каждой историей и задачей.

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

Множество разновидностей непрерывной интеграции Непрерывная интеграция настолько популярна и настолько неверно понимается, что люди продолжают выдумывать новые термины для разных аспектов основополагающей идеи: zz CI-сервер представляет собой программный инструмент, который автоматически запускает скрипты сборки. Не имеет никакого отношения к непрерывной интеграции; zz разработка на основе магистрали (trunk-based development) подчеркивает «интеграционную» часть в непрерывной интеграции [Hammant2020]; zz непрерывная поставка подчеркивает ту часть непрерывной интеграции, которая относится к развертыванию [Humble2010]. Обычно воспринимается как «непрерывная интеграция + развертывание в тестовой среде»; zz непрерывное развертывание — поистине новая практика. Подразумевает развертывание в эксплуатационную среду при каждой интеграции. Обычно воспринимается как «непрерывная поставка + развертывание в эксплуатационную среду».

Глава 13.  Разработка  453

Хотя непрерывную поставку часто рассматривают как отдельную от непрерывной интеграции практику, Кент Бек описывал ее как часть непрерывной интеграции еще в 2004 году: Интегрируйте и сделайте полный продукт. Если цель — сжечь CD, то сожгите CD. Если цель — развернуть сайт, разверните его, пусть даже в тестовую среду. Непрерывная интеграция должна быть достаточно полной, чтобы в итоге первое развертывание системы не составило большой проблемы [Beck2004] (гл. 7).

Танец непрерывной интеграции Когда вы используете непрерывную интеграцию, каждый день имеет место небольшой хореографический танец. 1. Сесть за рабочую станцию и сбросить ее в заведомо исправное состояние. 2. Выполнить работу. 3. Интегрировать (и, возможно, развертывать) при любой подходящей возможности. 4. По окончании сделать очистку (cleanup). Эти шаги должны быть доведены до автоматизма См. также как часть вашей среды разработки с нулевой пробуксовкой. Нулевое трение (глава 13) Для шага 1 создайте скрипт, называющийся reset_repo, или что-то похожее. При использовании git команды выглядят примерно так (до обработки ошибок): git clean -fdx git fetch -p origin git checkout integration git reset --hard origin/integration git checkout -b $PRIVATE_BRANCH $BUILD_COMMAND_HERE

# # # # # # #

erase all local changes get latest code from repo, removing outdated branches switch to integration branch reset integration branch to match repo create a private branch for your work verify that you’re in a known-good state

Во время шага 2 вы работаете нормально, как обычно, включая коммиты и перемещение, как предпочитает ваша команда. Шаг 3 — интеграция. Вы можете это делать в любое время, когда проходят тесты. Попробуйте интегрировать хотя бы каждые несколько часов. Когда вы готовы интегрировать, объедините последние изменения в ветке интеграции с вашим кодом, убедитесь, что все работает вместе, затем дайте задание вашему CI-серверу протестировать ваш код и слить все обратно в интеграционную ветку. Ваш скрипт integrate автоматизирует эти шаги для вас. В git это выглядит примерно так (до обработки ошибок): git status --porcelain git pull origin integration $BUILD_COMMAND_HERE $CI_COMMAND_HERE

# # # #

check for uncommitted changes (fail if any) merge integration branch into local code build, run tests (to check for merge errors) tell CI server to test and merge code

454  Часть III.  Надежная поставка # The following steps help git $WAIT_COMMAND_HERE git checkout integration git pull origin integration git checkout $PRIVATE_BRANCH git merge integration

resolve merge conflicts # wait for CI server to finish # check out integration branch # update integration branch from repo # check out private branch # merge repo’s integration branch changes

CI-команда меняется в зависимости от вашего CI-сервера, но обычно она выполняет перемещение вашего кода в репозиторий. Позаботьтесь о том, чтобы настроить ваш CI-сервер на сборку и тестирование кода, прежде чем снова объедините код с интеграционной веткой, а не после. Таким образом ваша интеграционная ветка всегда будет в заведомо исправном состоянии. Если у вас нет CI-сервера, который может это делать, то вы можете использовать скрипт, предложенный далее. Повторяйте шаги 2 и 3, пока не закончите все запланированное на день. После того как выполните интеграцию последний раз, сделайте очистку: git git git git

clean -fdx checkout integration branch -d $PRIVATE_BRANCH fetch -p origin

# # # # # git reset --hard origin/integration #

erase all local changes switch to integration branch delete private branch get latest code from repo, removing outdated branches reset integration branch to match repo

Эти скрипты — только предложения, вы можете адаптировать их в соответствии с предпочтениями вашей команды.

Непрерывная интеграция без CI-сервера Выполнять непрерывную интеграцию без CI-сервера на удивление просто. В некоторых средах это может оказаться лучшим вариантом для вас, так как облачные CI-серверы могут быть удручающе слабыми. Все, что вам нужно, — это интеграционная машина, то есть дополнительная рабочая станция разработки или виртуальная машина, и небольшой скрипт. Начните с того, что запрограммируйте скрипт integrate, который вы запускаете на своей рабочей станции, на то, чтобы отправить ваши изменения в частную ветку. Команда git — git push origin HEAD:$PRIVATE_BRANCH. После того как код отправлен, вручную войдите в систему на интеграционной машине и запустите второй интеграционный скрипт. Он должен проверить частную ветку, дополнительно проверить, что никто больше не делал интеграцию с момента, когда вы выложили код, запустить сборку и тесты, затем добавить изменения обратно, в интеграционную ветвь. Запуск сборки и тестов на отдельной интеграционной машине необходим для того, чтобы обеспечить заведомо исправную интеграционную ветвь. Это предотвращает ошибки типа «на моей машине это работало». При использовании git команды выглядят примерно так (до обработки ошибок): # Get private branch git clean -fdx git fetch origin

# erase all local changes # get latest code from repo

Глава 13.  Разработка  455 git checkout $PRIVATE_BRANCH # check out private branch git reset --hard origin/$PRIVATE_BRANCH # reset private branch to match repo # Check private branch git merge integration --ff-only $BUILD_COMMAND_HERE

# ensure integration branch has been merged # build, run tests

# Merge private branch to integration branch using merge commit git checkout integration # check out integration branch git merge $PRIVATE_BRANCH --no-ff --log=500 -m "INTEGRATE: $MESSAGE" # merge git push # push changes to repo # Delete private branch git branch -d $PRIVATE_BRANCH git push origin :$PRIVATE_BRANCH

# delete private branch locally # delete private branch from repo

Если скрипт закончился неудачно, то внесите исправления на своей рабочей машине и затем интегрируйте снова. Благодаря этому скрипту неудачные интеграции не будут оказывать влияния ни на кого другого. Обратите внимание, что только один человек может делать интеграцию в каждый момент времени, поэтому вам понадобится какой-то способ контроля доступа. Если у вас физическая интеграционная машина, то побеждает тот, кто за ней сидит. Удаленную интеграционную машину вы можете настроить так, чтобы разрешался только один вход в систему за раз. Этот скрипт предназначен для синхронной интеграции; это значит, вы должны дождаться, пока интеграция закончится, прежде чем перейти к другой работе. (Я поясню это чуть позже.) Если вам нужна асинхронная интеграция, то вам лучше использовать CI-сервер. Многоступенчатые сборки могут использовать этот скрипт для синхронной части в целях ускорения, а затем передавать CI-серверу для вторичной сборки или развертывания.

Синхронная или асинхронная интеграция Непрерывная интеграция работает лучше всего, См. также когда вы ждете, пока она завершится. Это называется синхронной интеграцией, и она требует, чтобы Нулевое трение (глава 13) ваши сборка и тесты были быстрыми — желательно, Быстрые надежные тесты чтобы они завершались менее чем за пять минут или (глава 13) максимум за десять. Достижение такой скорости зависит от создания быстрых надежных тестов. Если сборка занимает слишком много времени, то вам придется использовать асинхронную интеграцию. В этом случае (такая интеграции требует наличия CIсервера) вы начинаете процесс интеграции, затем переходите к другой работе, пока CI-сервер делает сборку. Когда сборка закончена, CI-сервер сообщает вам результат. Асинхронная интеграция выглядит эффективной, но на практике оказывается довольно проблематичной. Вы берете код, начинаете работать над чем-то еще и затем, полчаса (или больше) спустя, получаете сообщение, что сборка завершилась

456  Часть III.  Надежная поставка неудачно. Теперь вы должны прервать свою работу, чтобы пойти исправлять ошибку. Во всяком случае, в теории. Чаще она просто откладывается на потом. В итоге вы получаете огромный объем просроченной на часы или даже дни работы, имеющий гораздо более высокую вероятность конфликтов при объединении. Особенно часто эта проблема касается плохо сконфигурированных CI-серверов. Ваш CI-сервер должен объединять код в интеграционной ветке только после того, как сборка выполняется успешно, чтобы интеграционная ветка была заведомо исправной, однако некоторые CI-серверы по определению сначала объединяют код, а потом запускают сборку. Если код повреждает сборку, то все, кто загружал его из ветки интеграции, блокируются. В сочетании с асинхронной интеграцией вы получите ситуацию, когда люди невольно загружают поврежденный код, а затем не исправляют его, думая, что это кто-то другой повредил сборку. Ситуация усугубляется, когда ошибки наслаиваются одна на другую. Мне попадались команды, в которых сборки оставались поврежденными целыми днями. Лучше сделать конструктивно невозможным повреждение сборки, введя правило сначала тестировать сборку. И все же лучше использовать синхронную интеграцию. Когда вы интегрируете, дождитесь успешного завершения интеграции. Если она неуспешна, сразу исправьте ошибку.

Многоступенчатые интеграционные сборки У некоторых команд настолько сложные тесты, измеряющие такие качества, как производительность, нагрузка или стабильность, что они просто не могут завершиться за 10 минут. Эти команды могут использовать многоступенчатую интеграцию. Многоступенчатая интеграция состоит из двух отдельных сборок. Нормальная сборка, или сборка подтверждения (commit build), содержит все необходимые составляющие, позволяющие продемонстрировать, что ПО работает: компиляция, линтинг, модульные тесты, узкие интеграционные тесты, несколько дымовых тестов. Эта сборка запускается синхронно, как обычно. Когда сборка подтверждения завершается успешно, интеграция считается успешной и код сливается в интеграционную ветку. Тогда асинхронно запускается более медленная вторичная сборка. Она содержит дополнительные тесты, которые не запускаются в нормальной сборке: тесты производительности, нагрузочные тесты, тесты стабильности и т. д. В нее также может входить развертывание кода в промежуточной или эксплуатационной среде. Если вторичная сборка не удалась, то Если вторичная сборка не удалась, команда получает сообщение, все бросают все бросают текущие занятия текущие занятия и занимаются решением и занимаются решением проблемы. проблемы. Это позволяет команде быстро вернуться к заведомо исправной сборке. Однако сбои во вторичной сборке должны случаться редко. Если это не так, то сборка подтверждения должна быть расширена так, чтобы обнаруживать подобные проблемы и решать их синхронно.

Глава 13.  Разработка  457

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

Запросы на слияние кодов (пул-реквесты) и ревью кода Запросы на слияние кодов не подходят для неПул-реквесты слишком прерывной интеграции. Они слишком медленмедленные для непрерывной ные. Непрерывная интеграция работает лучше интеграции. всего, когда периоды времени между интеграциями очень короткие (менее чем несколько часов), а для запросов на слияние кодов требуется день или два на подтверждение. Это повышает вероятность конфликтов при объединении кода, особенно для команд, использующих эволюционный дизайн (о котором я расскажу в главе 14). Вместо этого используйте парное или групповое программирование, чтобы избавиться от необходимости проводить ревью кода. В качестве альтернативы, если вам хочется сохранить ревью, то вы можете их проводить после интеграции, а не как необходиСм. также мый этап перед интеграцией. Запросы на слияние кодов не очень хороПарное программирование (глава 12) шо работают у команд, использующих непрерывную интеграцию, но все же могут служить Групповое программирование механизмом координации между командами, (глава 12) не связанными общим владением кодом. К А Р ГО - К УЛ ЬТ

Инструмент «Непрерывная интеграция? Что вы имеете в виду, говоря, что непрерывная интеграция может помочь? У нас уже есть инструмент CI». Ваш босс разговаривает по телефону с Agile-коучем. Это должен был быть телефонный отбор кандидатов, но сейчас не очень понятно, кто кого интервьюирует.

458  Часть III.  Надежная поставка

«Нет, они не работают вместе над историями. Здесь я руковожу процессом. Я назначаю истории для ресурсов, и каждая история получает отдельную ветвь функциональности. Несколько недель спустя ресурс предоставляет запрос на слияние кода, я его просматриваю и говорю им, что они сделали неправильно». Вы не слышите, что говорит его собеседник, но лицо вашего босса наливается интересным оттенком красного. «Послушайте, я попросил вас помочь нам с нашей проектной документацией, а не болтать какую-то чепуху про коммунистический стиль владения кодом и непрерывную интеграцию. Я говорил вам, у нас уже есть CI-инструмент. У нас есть реальные проблемы, которые надо решать. При объединениях кода происходит слишком много конфликтов, и никто не знает, как продолжить работу Тиффани с тех пор, как она уволилась. Мне нужно, чтобы мои ресурсы имели одинаковое понимание ситуации, и проектная документация — как раз тот способ, с помощью которого я хочу этого добиться. А теперь вы готовы прекратить тратить попусту мое время и помочь мне в этом или… алло? Алло?» Ваш босс швыряет телефон на стол и поворачивается к вам. «Поверить не могу! Еще один бросил трубку. Что не так с этими людьми?»

Вопросы Вы говорите, мы должны делать очистку в конце дня, а что, если у меня осталась незавершенная работа и я не могу сделать интеграцию? Если вы используете флаги функций и практикуете разработку через тестирование, то можете делать интеграцию в любой момент по мере прохождения тестов, которое должно происходить каждые несколько минут. Вы вообще не должны оказываться в ситуации, когда не можете делать интеграцию. Если работа встала, то хорошей идеей может быть удаление незавершенного См. также кода. Если вы часто делаете интеграцию, то его не должно быть много. Вы справитесь Флаги функций (глава 15) с работой лучше, если начнете все сначала Разработка через тестирование утром, на свежую голову. (глава 13) Разве синхронная интеграция  — это не потеря времени? Нет, если ваша сборка такая быстрая, какой должна быть. Это хорошая возможность сделать перерыв и подумать о дизайне, возможностях рефакторинга или следующих шагах. На практике проблемы, вызванные асинхронной интеграцией, отнимают больше времени. Кажется, мы всегда сталкиваемся с конфликтами объединения, когда выполняем интеграцию. Что мы делаем не так?

Глава 13.  Разработка  459

Одна из причин конфликтов объединения кода — редкая интеграция. Чем реже вы делаете интеграцию, тем больше изменений вам приходится объединять. Попробуйте делать интеграцию более часто. Еще одна возможная причина — ваши изменения накладываются на работу другого члена команды. Попробуйте больше говорить о том, над чем вы работаете, и более плотно координироваться с людьми, которые работают над кодом, имеющим отношение к вашему. Более подробная информация доступна в разделе «Как заставить коллективное владение работать» главы 12. CI-сервер (или интеграционная машина) постоянно завершает сборку неуспешно. Как можно сделать интеграцию более надежной? Сначала убедитесь, что у вас надежные тесты. Периодические сбои тестов — наиболее частая причина неуспешных сборок, которую я встречал. Если проблема не в этом, то вам, возможно, понадобится объединить и протестировать ваш код локально перед интеграцией. В качестве альтернативы, если у вас частые проблемы с неверными зависимостями, то вам может понадобиться поработать над См. также воспроизводимыми сборками, как было Быстрые надежные тесты (глава 13) описано в подразделе «Воспроизводимые сборки» ранее в данной главе.

Предварительные требования Непрерывная интеграция наиболее эфСм. также фективна в сочетании с синхронной интеграцией, что требует сборки с нулевой Нулевое трение (глава 13) пробуксовкой, для завершения которой Парное программирование (глава 12) нужно не более 10 минут. Иначе вам придется использовать асинхронную Групповое программирование (глава 12) или многоступенчатую интеграцию. Разработка через тестирование (глава 13) Асинхронная и многоступенчатая Быстрые надежные тесты (глава 13) интеграции требуют использования CIсервера, и он должен быть сконфигурирован так, чтобы проверять сборку до того, как она объединяет изменения с интеграционной веткой. Иначе, вероятно, в конечном итоге вы получите наслаивающиеся друг на друга ошибки сборки. Запросы на слияние кодов не очень хорошо работают в сочетании с непрерывной интеграцией, поэтому к ревью кода нужен другой подход. Лучше всего подходит парное или групповое программирование. Непрерывная интеграция полагается на сборку и набор тестов, которые будут тщательно тестировать ваш код, желательно с помощью быстрых надежных тестов. Разработка на основе тестирования, использующая узкие коммуникативные (sociable) тесты, — лучший способ достичь этого.

460  Часть III.  Надежная поставка

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

Альтернативы и эксперименты Непрерывная интеграция — базовая необходиСм. также мость для команд, использующих коллективное владение кодом и эволюционный дизайн. Без нее Коллективное владение кодом существенный рефакторинг становится нецелесо(глава 12) образным, поскольку вызывает слишком много Рефлексивный дизайн (глава 14) конфликтов объединения. Это мешает команде непрерывно совершенствовать дизайн, что необРефакторинг (глава 13) ходимо для успеха в долгосрочной перспективе. Флаги функций (глава 15) Самая часто встречающаяся альтернатива непрерывной интеграции — это ветки функциональностей, которые регулярно сливаются из интеграционной ветки и интегрируются в нее только тогда, когда каждая функциональность готова. Хотя ветки функциональностей позволяют вам держать интеграционную ветку в состоянии готовности к релизу, они обычно не очень хорошо работают с коллективным владением кодом и эволюционным дизайном, поскольку слияния в интеграционную ветку слишком редки. Использовать флаги функций — лучший способ См. также держать интеграционную ветку в состоянии готовности к релизу. Непрерывное развертывание (глава 15) Эксперименты с непрерывной интеграцией, которые я видел, предполагают доведение ее до крайности. Некоторые команды делают интеграцию по мере каждого коммита (каждые несколько минут) или даже каждый раз, когда проходит тест. Наиболее популярный эксперимент — непрерывное развертывание, которое попало в мейнстрим и будет обсуждаться дальше в этой книге.

Литература для дополнительного чтения Статья Мартина Фаулера Patterns for Managing Source Code Branches [Fowler2020b] — отличный ресурс для тех, кому интересно разобраться в различиях между ветками функциональностей, непрерывной интеграцией и прочими стратегиями ветвления. Continuous Delivery Джеза Хамбла и Дэвида Фарли [Humble2010] — это классика, и совершенно справедливо. В книге подробно обсуждается все, что вам нужно для непрерывной интеграции, с упором на автоматизацию развертывания.

Глава 13.  Разработка  461

РАЗРАБОТКА ЧЕРЕЗ ТЕСТИРОВАНИЕ Мы производим высококачественный код мелкими, легко поддающимися проверке шагами.

Аудитория

«Что действительно нужно языкам програмПрограммисты мирования, так это инструкция DWIM (Do What I Mean), — гласит известная шутка, — Делай то, что я подразумеваю, а не то, о чем говорю». Программирование — процесс с высокими требованиями. Оно требует систематического совершенствования, месяцев и лет усилий. В лучшем случае ошибки приведут к коду, который будет невозможно скомпилировать. В худшем — к багам, которые до поры до времени будут незаметными и проявятся именно в тот момент, когда смогут нанести максимальный вред. Разве не было бы чудесно, если бы существовал способ заставить компьютеры делать то, что вы имеете в виду? Техника, настолько эффективная, чтобы буквально избавляла от необходимости в отладке? Такая техника есть. Это разработка через тестирование, и она действительно работает. Разработка через тестирование представляет собой быстрый цикл тестирования, кодирования и рефакторинга. Добавляя функциональность, вы будете выполнять десятки таких циклов, внедряя и отлаживая ПО крошечными шагами, пока не останется ничего, что можно добавить или убрать. Хорошо налаженная TDD позволяет сделать так, чтобы код выполнял именно то, что вы подразумеваете, а не только то, о чем говорите. Вдобавок при правильном использовании TDD позволяет вам улучшить ваш дизайн, документирует код для будущих программистов, облегчает рефакторинг и оберегает от будущих ошибок. И что еще лучше — это весело. Вы всегда держите все под контролем и постоянно получаете подтверждение, что вы на верном пути. Конечно, TDD не идеальна. Она помогает программистам писать в коде то, что они намеревались написать, но не спасает программистов от неверного понимания того, что им нужно делать. Она помогает улучшить документацию, рефакторинг и дизайн, но только если программисты усиленно работают над этим. Кроме того, TDD имеет кривую обучения (learning curve): ее трудно добавить к устаревшей кодовой базе, и потребуются дополнительные усилия, чтобы применить ее к коду, который имеет отношение к внешнему миру, такому как пользовательские интерфейсы, сетевое окружение и базы данных. В любом случае попробуйте TDD. Она выигрывает от использования и других практик Agile, но не требует их. Вы можете использовать ее почти с любым кодом.

Почему TDD работает Во времена перфокарт программисты кропотливо проверяли свой код вручную, чтобы убедиться, что он скомпилируется. Ошибки при компиляции могли привести к неуспешным пакетным заданиям и интенсивным сессиям отладки. Сделать код пригодным для компиляции больше не является большой проблемой. Большинство IDE проверяет синтаксис, пока вы набираете код, а некоторые даже выполняют компиляцию всякий раз, когда вы его сохраняете. Петля обратной связи

462  Часть III.  Надежная поставка очень быстрая, ошибки легко находить и исправлять. Если что-то не компилируется, то нужно проверить не так много кода. Разработка через тестирование применяет тот же принцип к намерениям программиста. Подобно тому как современная среда предоставляет обратную связь по синтаксису вашего кода, TDD усиливает обратную связь, имеющую отношение к семантике вашего кода. Каждые несколько минут (каждые 20–30 секунд) TDD проверяет, делает ли код то, что, по вашему мнению, должен делать. Если что-то идет не так, то нужно проверить всего несколько строк кода. Ошибки становятся очевидными. TDD исполняет этот трюк, используя серию проверяемых гипотез. Вы продвигаетесь очень маленьTDD — это серия кими шагами и на каждом мысленно прогнозируете, проверяемых гипотез. что будет дальше. Сначала вы пишете немного тестового кода и даете прогноз, что он сработает неуспешно определенным образом. Затем пишете немного рабочего кода и прогнозируете, что теперь тест пройдет. Затем выполняете небольшой рефакторинг и даете прогноз, что тест опять пройдет. Если ваш прогноз всегда неверен, то вы останавливаетесь и выясняете, в чем дело, — или просто делаете резервную копию и пробуете еще раз. В процессе работы код и тесты объединяются, чтобы проверять корректность друг друга, и ваши успешные прогнозы подтверждают, что вы контролируете свою работу. Результат — код, который делает в точности то, что вы задумали. Вы можете забыть что-то или неверно понимать, что нужно сделать. Но можете быть уверены, что код делает то, что вы задумали. Когда вы заканчиваете, тесты остаются. Они подтверждаются вместе с остальным кодом и работают как живая документация ваших предположений о том, как он должен работать. Что еще более важно, ваша команда запускает тесты при каждой сборке, обеспечивая безопасность рефакторинга и продолжение работы кода так, как задумывалось изначально. Если кто-то случайно меняет поведение кода (например, вследствие ошибочной отладки), тесты становятся неуспешными, сигнализируя об ошибке. КЛЮЧЕВАЯ ИДЕЯ

Быстрая обратная связь Обратная связь и итерация — ключевая идея Agile, как обсуждалось во врезке «Обратная связь и итерации» в главе 8. Важный аспект этой петли обратной связи — скорость обратной связи. Чем быстрее вы можете ее получать, тем быстрее можете скорректировать курс и исправить ошибки и тем проще понять, что в следующий раз нужно делать по-другому. Команды Agile стараются ускорить свои петли обратной связи. Чем быстрее обратная связь, тем лучше. Это применимо к каждому уровню, от релизов («Были ли наши идеи о ценности правильными?») до ежеминутного кодирования («Делает ли та строка кода, которую я только что написал, то, что я задумал?»). Разработка через тестирование, нулевая пробуксовка, непрерывное развертывание и минимальные ценные инкременты адаптивного планирования — все это примеры ускорения обратной связи.

Глава 13.  Разработка  463

Как использовать TDD Чтобы использовать TDD, вам понадобится программистский фреймворк для тестирования. Исторически они называются фреймворками модульного тестирования (unit testing frameworks), хотя используются для всех видов тестирования. У каждого популярного языка есть один или даже несколько фреймворков — просто выполните поиск в Интернете по фразе « фреймворк модульного тестирования». Популярные примеры: JUnit для Java, xUnit.net для .NET, Mocha для JavaScript и CppUTest для C\++. TDD выполняет цикл «красный, зелеTDD не предотвращает ошибки; ный, рефакторинг», показанный на рис. 13.1. она их выявляет. Помимо времени, затраченного на обдумывание, каждый шаг должен быть очень маленьким, давая вам обратную связь в течение минуты или двух. Как ни странно, чем лучше люди разбираются в TDD, тем вероятнее, что они будут делать очень маленькие шаги и быстрее продвигаться вперед. Это потому, что TDD не предотвращает ошибки; она их выявляет. Маленькие шаги означают быструю обратную связь, а та, в свою очередь, означает, что ошибки можно исправлять быстрее и легче.

Рис. 13.1. Цикл TDD

Шаг 1. Подумать TDD основана на тестировании, поскольку вы начинаете с теста и потом пишете ровно столько кода, сколько необходимо для его прохождения. Есть поговорка: «Не пишите никакой рабочий код, если у вас нет неуспешного теста». Таким образом, вашим первым шагом будет начать несколько странный мыслительный процесс. Вообразите поведение, которое ваш код должен демонстрировать, а затем подумайте о самой первой части, которая позволит это реализовать. Она должна быть маленькой. Очень маленькой. Меньше пяти строк кода. Далее подумайте о тесте (также всего несколько строк кода), который будет неуспешным, пока не появится именно такое поведение. Подумайте о том, что проверяет поведение кода, не реализацию. Пока интерфейс не меняется, вы должны иметь См. также возможность изменить реализацию в любой момент, не меняя тест. Парное программирование (глава 12) Это самая трудная часть TDD, поскольку она требует, чтобы вы думали на два шага Групповое программирование вперед: первый — что вы хотите сделать; (глава 12) второй — какой тест потребует, чтобы вы Спайк-решения (глава 13) это сделали. Поможет парное и групповое

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

Шаг 2. Красная полоса Когда вы придумаете следующий шаг, напишите тест. Напишите достаточно тестового кода для текущего инкремента поведения — скорее всего, меньше пяти строк кода. Если получится больше — это нормально: просто попробуйте в следующий раз сделать меньший инкремент. Напишите тест с точки зрения открытого интерфейса кода, а не того, как вы планируете реализовать его внутреннее устройство. Соблюдайте инкапсуляцию. Это значит, что ваш первый тест будет использовать пока еще не существующие имена. Это делается намеренно, чтобы вы проектировали ваш интерфейс с точки зрения пользователя интерфейса, а не его разработчика. После того как тест написан, сделайте прогноз того, что произойдет. Обычно тест должен пройти неуспешно, что приводит к появлению красного индикатора выполнения в большинстве исполнителей тестов. Однако не прогнозируйте, что он просто потерпит неудачу, — предскажите, как именно это произойдет. Помните: TDD — это серии подтвержденных гипотез. Затем используйте ваш скрипт watch или См. также IDE, чтобы запускать тесты. Вы должны получить обратную связь в течение нескольких Нулевое трение (глава 12) секунд. Сравните результат с вашим прогнозом. Они совпали? Если тест не проходит неуспешно или терпит неудачу не так, как вы ожидали, то вы больше не контролируете свой код. Возможно, ваш тест поврежден или не тестирует то, что должен по вашему замыслу. Устраните проблему. Вы должны быть всегда в состоянии спрогнозировать, что произойдет. Одинаково важно исправлять как неожиданные успехи, так и неожиданные неудачи. Ваша Ваша цель — всегда знать, что цель — не только сделать так, чтобы тесты прошделает код и почему. ли; она в том, чтобы держать под контролем свой код — всегда знать, что он делает и почему.

Шаг 3. Зеленая полоса Сначала напишите достаточно рабочего кода, чтобы тест прошел. Повторюсь: в большинстве случаев вам должно понадобиться меньше пяти строк кода. Не беспокойтесь о чистоте дизайна или элегантности концепции; просто сделайте то, что нужно, чтобы тест прошел. Очень скоро вы сделаете очистку. Сделайте еще один прогноз и запустите тесты. Это ваша вторая гипотеза. Тесты должны пройти, в результате чего появится зеленый индикатор выполнения. Если тест не пройдет, то вернитесь к заведомо хорошему коду как можно

Глава 13.  Разработка  465

быстрее. Часто ошибка бывает очевидной. Вы же написали всего лишь несколько новых строк кода. Если ошибка неочевидна, то подумайте о том, чтобы отменить все изменения, и попробуйте еще раз. Иногда лучше удалить или закомментировать новый тест и начать сначала, с еще меньшим инкрементом. Ключевая задача — сохранить контроль. Всегда есть соблазн прыгнуть выше головы и решить проблему, вместо того чтобы сохранить резервную копию и попробовать еще раз. Я тоже так делаю. И все же заработанный тяжелым трудом опыт научил меня тому, что пробовать еще раз, используя меньший инкремент, — почти всегда быстрее и проще. Это не мешает мне впадать в отчаяние (всегда кажется, что решение где-то рядом), но в итоге я научился устанавливать таймер, чтобы минимизировать ущерб. Если вы не можете заставить себя отменить изменения сразу, то установите таймер на 5–10 минут и пообещайте себе, что сделаете резервную копию и начнете сначала, используя меньший инкремент, когда сработает таймер.

Шаг 4. Сделать рефакторинг Когда ваши тесты снова проходят, вы можете См. также сделать рефакторинг, не опасаясь что-то повредить. Просмотрите код, имеющийся у вас Рефакторинг (глава 13) на данный момент, и поищите, что можно улучшить. Если вы работаете в паре или используете групповое программирование, то спросите, нет ли каких-нибудь предложений у вашего штурмана. Выполняйте рефакторинг инкрементно, чтобы добавлять каждое улучшение пошагово. Используйте очень маленькие рефакторинги (меньше минуты или двух каждый и точно не больше пяти минут) и запускайте тесты после каждого. Они должны всегда проходить. Как и до этого, если тест не проходит и ошибка не сразу очевидна, то отмените рефакторинг и просто вернитесь к заведомо хорошему коду. Выполните столько рефакторинга, сколько вам захочется. Сделайте код настолько чистым, См. также насколько сможете, не заботясь о том, чтобы сделать его идеальным. Сделайте так, чтобы Простой дизайн (глава 14) дизайн был сфокусирован на текущих потребностях ПО, а не на том, что может случиться в будущем. Пока выполняете рефакторинг, не добавляйте никаких функциональностей. Рефакторинг не должен менять поведение. Для нового поведения нужен неуспешный тест.

Шаг 5. Повторить Когда будете готовы добавить новое поведение, начните цикл сначала. Если все идет гладко и каждая гипотеза совпадает с реальностью, то вы можете «повысить передачу» и делать более крупные шаги.

Ключ к успешной TDD — маленькие инкременты и быстрая обратная связь.

466  Часть III.  Надежная поставка (Но, как правило, не больше пяти строк кода за раз.) Если столкнетесь с проблемами, то «понизьте передачу» и двигайтесь меньшими шагами. Ключ к успешной TDD — маленькие инкременты и быстрая обратная связь. Каждую минуту или две вы должны получать подтверждение, что двигаетесь в верном направлении и ваши изменения делают то, чего вы от них ожидаете. Обычно вы пройдете через несколько циклов очень быстро, затем потратите больше времени на обдумывание и рефакторинг для новых циклов, потом снова ускоритесь. К А Р ГО - К УЛ ЬТ

Разгром, основанный на тестах — Ах, да, TDD, — хмурится Алиса, — пробовала я это однажды. Это катастрофа. — Что случилось? — спрашиваете вы. У вас TDD работало хорошо, но с некоторыми вещами было трудно разобраться. Возможно, вы что-нибудь посоветуете. — Окей, так значит, TDD — это кодирование ваших спецификаций с помощью тестов, правильно? — объясняет Алиса немного снисходительно. — Вы начинаете с того, что выясняете, что, по вашему мнению, должен делать ваш код, потом пишете все тесты, чтобы они полностью его определяли. Затем пишете код до тех пор, пока тесты не пройдут. Но это просто глупо! — негодует она. — Постановка спецификации в начало процесса требует от вас принятия решений до того, как вы полностью поймете проблему. И вот у вас есть все эти тесты, которые трудно изменить, вы вкладываетесь в решение и не будете искать лучшие варианты. Даже если вы решаете что-то изменить, все эти тесты заблокированы вашей реализацией, так что почти невозможно что-то изменить, не переделывая всю работу. Это просто смешно! — Я… Я не думаю, что это TDD, — бормочете вы, заикаясь. — Звучит ужасно. В TDD предполагается, что нужно продвигаться маленькими шагами, не писать все тесты авансом. И еще предполагается, что вы тестируете поведение, а не реализацию. — Нет, ты не прав, — твердо говорит Алиса. — TDD — это разработка, где сначала идут тесты. Пишете тесты, потом пишете код. И это комшмар. Я знаю, я это пробовала.

Ешьте луковицу с середины Самое сложное в TDD — это разобраться, как делать маленькие шаги. К счастью, проблемы кодирования похожи на луковицы: у них есть слои. Хитрость с TDD состоит в том, чтобы начать со сладкой, сочной середины и затем проложить себе путь наружу. Вы можете использовать любую стратегию, которая вам нравится, но я использую следующий подход. 1. Главный интерфейс. Начните с главного интерфейса, к которому вы хотите обратиться, потом напишите тест, который обращается к этому интерфейсу простейшим способом. Используйте это как возможность посмотреть, как интерфейс

Глава 13.  Разработка  467

работает на практике. Это удобно? Имеет смысл? Чтобы тест прошел, вы можете просто жестко закодировать ответ. 2. Вычисления и ветки. Вашего жестко закодированного ответа недостаточно. Какие вычисления и логика лежат в основе вашего нового кода? Начните их добавлять, одна ветка и одно вычисление за раз. Сосредоточьтесь на удачном случае: как будет использоваться код, когда все будет правильно работать. 3. Циклы и обобщение. Ваш код будет часто предусматривать циклы или альтернативные способы использования. Как только вы реализуете основную логику, добавьте поддержку этих альтернатив, по одной за раз. Скорее всего, вам понадобится сделать рефакторинг логики, которую вы встроили в более общую форму, чтобы код сохранял чистоту. 4. Особые случаи и обработка ошибок. После того как вы обработаете все успешные случаи, подумайте обо всем, что может пойти не так. Вызываете ли вы какой-либо код, который может сгенерировать исключение? Делаете ли вы какие-то предположения, которые требуют проверки? Напишите тест для каждого. 5. Утверждения времени выполнения (runtime assertions). В процессе работы вы можете определить ситуации, которые могут возникнуть только в результате ошибки программирования, такой как индекс массива, выходящий за его пределы, или переменная, которая никогда не должна равняться нулю. Добавьте утверждения времени выполнения для этих случаев, чтобы они быстро вызывали аварийное завершение (см. подраздел «Быстрое завершение с ошибкой» главы 14). Их не нужно тестировать, так как они являются просто дополнительной страховочной сеткой. Может оказаться полезной мнемоника ZOMBIES Джеймса Греннинга: протестируйте ноль (Zero), затем один (One), потом много (Many). Пока тестируете, обратите внимание на границы (Boundaries), интерфейсы (Interfaces) и исключения (Exceptions), при этом сохраняя код простым (Simple) [Grenning2016].

Пример TDD Проще всего понять TDD, если смотреть, как кто-либо работает с ней. У меня есть несколько серий онлайн-видео, демонстрирующих реальную TDD. На момент написания этого текста самая последняя — серия TDD Lunch & Learn. Она состоит из 21 эпизода, охватывающего все: от основ TDD до тяжелых проблем, таких как сетевое окружение и тайм-ауты [Shore2020b]. Первый из этих примеров использует TDD для создания функции кодирования ROT-13. (ROT-13 — простой шифр Цезаря, в котором abc становится nop, и наоборот.) Это очень простая проблема, но при этом хороший пример того, как даже небольшие задачи можно разбивать на очень маленькие шаги. В этом примере обратите внимание на техники, которые я использую в работе с небольшими инкрементами. Инкременты могут даже казаться смехотворно маленькими, но это облегчает поиск ошибок и помогает мне быстрее двигаться вперед. Как я сказал, чем больше у вас опыта в TDD, тем более маленькие шаги вы можете делать и тем быстрее это позволяет вам идти вперед.

468  Часть III.  Надежная поставка

Начните с главного интерфейса Подумать. Первым делом мне нужно было решить, с чего начать. Как обычно, хорошая начальная точка — главный интерфейс. Каким бы мне хотелось его видеть? Этот пример был написан на JavaScript (а именно на Node.js), у меня был выбор между созданием класса и просто экспортом функции из модуля. Мне показалось, что не было особого смысла создавать полноценный класс, поэтому я решил сделать просто модуль rot13, который экспортировал функцию transform. Красная полоса. Теперь, зная, что хочу сделать, я мог написать тест, который испытывал этот интерфейс простейшим способом: it("runs tests", function() { assert.equal(rot13.transform(""), ""); });

 

Строка 1 определяет тест, а  строка 2 утверждает актуальное значение, rot13.trans­ form(""), совпадающее с ожидаемым значением "". Некоторые библио­

теки утверждений ставят ожидаемое значение первым, но в этом примере используется Chai, которая ставит первым актуальное значение. Прежде чем запустить тест, я выдвинул гипотезу. Конкретно, я предсказал, что тест пройдет неуспешно, поскольку rot13 не существовал, и именно это и произошло. Зеленая полоса. Чтобы тест прошел, я создал интерфейс и жестко запрограммировал ровно столько кода, чтобы было достаточно для теста: export function transform() { return ""; }

Жесткое кодирование возвращаемого значения — это своего рода трюк, и я часто пишу немного реального кода на этом первом шаге. Но в данном случае не было больше ничего, что код должен был сделать. Сделать рефакторинг. Ищите возможности для рефакторинга каждый раз, используя цикл. В этом случае я переименовал тест из «запускать тесты», что оставалось от моей изначальной конфигурации, в «ничего не делать, если вводные данные пустые». Очевидно, это полезнее для будущих читателей. Хорошие тесты документируют, как код должен работать, а хорошие названия тестов позволяют читателю получить общее понимание, бегло просматривая названия. Обратите внимание: название говорит о том, что делает рабочий код, а не тест: it("does nothing when input is empty", function() { assert.equal(rot13.transform(""), ""); });

Вычисления и ветви Подумать. Теперь мне нужно было закодировать основную логику преобразования ROT-13. В конечном итоге я знал, что хочу перебирать строку в цикле и преобразовывать по одному символу за раз, но это был слишком большой шаг. Мне нужно было придумать более маленький шаг. Более маленький шаг — «сконвертировать один символ», но даже это слишком велико. Помните, чем меньше шаги, тем быстрее вы можете продвигаться вперед.

Глава 13.  Разработка  469

Мне нужно было разбить их на еще более маленькие. В итоге я решил просто преобразовать одну прописную букву в соответствующую ей, находящуюся на 13 символов впереди. Заглавные буквы и цикл после z отложим на потом. Красная полоса. С помощью таких маленьких шагов было легко написать тест. it("transforms lower-case letters", function() { assert.equals(rot13.transform("a"), "n"); });

Моя гипотеза заключалась в том, что тест провалится, ожидая "n", но получив "", и именно это и случилось. Зеленая полоса. Сделать так, чтобы тест прошел, было легко: export function transform(input) { if (input === "") return "";

}

const charCode = input.charCodeAt(0); charCode += 13; return String.fromCharCode(charCode);

Хотя это был маленький шаг, он вынудил меня проработать важный вопрос конвертации букв в коды символов и обратно, ответ на который мне понадобилось искать. Небольшие шаги позволили мне решить эту проблему изолированно, что упростило задачу определить момент, когда я понял правильно. Сделать рефакторинг. Я не видел никаких возможностей для рефакторинга, поэтому пришло время снова вернуться в начало цикла. Повторить. Я продолжил таким же образом, двигаясь маленькими шажками до тех пор, пока главный алгоритм преобразования букв не был завершен. 1. Строчная буква вперед: a → n (как я только что показал). 2. Строчная буква назад: n → a. 3. Первый символ перед a не сдвигается: ` → `. 4. Первый символ после z не сдвигается: { → {. 5. Заглавные буквы вперед: A → N. 6. Заглавные буквы назад: N → A. 7. Еще пограничные случаи: @ → @ and [ → [. После каждого шага я просматривал код и при необходимости делал рефакторинг. Итоговые тесты показаны ниже. Цифра соответствует шагу. Обратите внимание, как некоторые шаги привели к новым тестам, а другие расширили существующий тест: it("does nothing when input is empty", function() { assert.equal(rot13.transform(""), ""); }); it("transforms lower-case letters", function() { assert.equal(rot13.transform("a"), "n");  assert.equal(rot13.transform("n"), "a");  });

470  Часть III.  Надежная поставка it("transforms upper-case letters", function() { assert.equal(rot13.transform("A"), "N");  assert.equal(rot13.transform("N"), "A");  }); it("doesn't transform symbols", function() { assert.equal(rot13.transform(""), "");  assert.equal(rot13.transform("{"), "{");  assert.equal(rot13.transform("@"), "@");  assert.equal(rot13.transform("["), "[");  });

Рабочий код показан ниже. Проследить соответствие каждого шага коду труднее, поскольку было выполнено много рефакторинга (больше информации см. в эпизоде 1 в [Shore2020b]), но вы можете видеть, что TDD — итеративный процесс, постепенно заставляющий код разрастаться. export function transform() { if (input === "") return "";

}

let charCode = input.charCodeAt(0); if (isBetween(charCode, "a", "m") || isBetween(charCode, "A", "M")) { charCode += 13; } if (isBetween(charCode, "n", "z") || isBetween(charCode, "N", "Z")) { charCode -= 13; } return String.fromCharCode(charCode);

     

function isBetween(charCode, firstLetter, lastLetter) {  return charCode >= codeFor(firstLetter) && charCode rot13.transform(), "Expected string parameter" ); });

     

it("fails fast when wrong parameter type provided", function() { assert.throws( () => rot13.transform(123), "Expected string parameter" ); });

     

Глава 13.  Разработка  473

Конечно, я следовал циклу TDD и добавлял тесты по одному за раз. Их реализация означает добавление защитного условия (guard clause), которое я тоже реализовал инкрементно: export function transform(input) { if (input === undefined  || typeof input !== "string" throw new Error("Expected string parameter"); } ...



) {

 

Хорошие тесты также служат документацией, поэтому на последнем шаге я все­ гда просматриваю тесты и думаю о том, насколько информативными они будут для будущих читателей. Обычно я начинаю с общего случая «успешный вариант», затем перехожу к специфике и особым случаям. Иногда я добавляю несколько тестов, только чтобы прояснить поведение, даже если мне не нужно менять рабочий код. Так же было и с этим кодом. Вот тесты, которыми я закончил: it("does nothing when input is empty", ...); it("transforms lower-case letters", ...); it("transforms upper-case letters", ...); it("doesn’t transform symbols", ...); it("doesn’t transform numbers", ...); it("doesn’t transform non-English letters", ...); it("doesn’t break when given emojis", ...); it("fails fast when no parameter provided", ...); it("fails fast when wrong parameter type provided", ...);

И финальный рабочий код: export function transform(input) { if (input === undefined || typeof input !== "string") { throw new Error("Expected string parameter"); }

}

let result = ""; for (let i = 0; i < input.length; i++) { let charCode = input.charCodeAt(i); result += transformLetter(charCode); } return result;

function transformLetter(charCode) { if (isBetween(charCode, "a", "m") || isBetween(charCode, "A", "M")) { charCode += 13; } else if (isBetween(charCode, "n", "z") || isBetween(charCode, "N", "Z")) { charCode -= 13; } return String.fromCharCode(charCode); } function isBetween(charCode, firstLetter, lastLetter) { return charCode >= codeFor(firstLetter) && charCode = codeFor(firstLetter) && charCode = firstLetter && letter = codeFor(firstLetter) && charCode = firstLetter && letter = firstLetter && letter = "a" && letter = "A" && letter = "n" && letter = "N" && letter = "a" && letter = "A" && letter = "n" && letter = "N" && letter = "a" && letter = "A" && letter = "n" && letter = "N" && letter = "a" && letter = "A" && letter = "n" && letter = "N" && letter = "a" && letter = "A" && letter = "n" && letter = "N" && letter