Скрам

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

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

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

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

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

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

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

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

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

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