Скрам

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

Что происходит, если фактические значения сравниваются с оценками и планами

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

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

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