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

Извлеченные уроки

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

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

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

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

Учимся получать удовольствие от работы

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

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

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

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

Извлеченные уроки

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

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