Канбан. Альтернативный путь в Agile - [12]

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

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

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

Кто лучше?

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

Согласно диаграмме, проект был завершен примерно в середине марта 2004 года, но на самом деле команда продолжала работу над программами до середины июля. Половина команды разработчиков OTA DM были отозваны со своего проекта, чтобы помочь в работе над ошибками. В июле 2004 года руководитель бизнес-подразделения объявил продукт готовым, несмотря на то что не был уверен в его качестве. Продукт перешел к команде поддержки. За это время 50 % клиентов отменили заказы, усомнившись в качестве продукта. Хотя члены команды поддержки сохраняли хорошие личные отношения с разработчиками продукта, они разуверились в их профессионализме. По их мнению, продукт был плох, а разработчики оказались ни на что не способны.

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

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

Частые релизы порождают доверие

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

Когда я рассказываю об этом в аудитории, я всегда спрашиваю девушек, о чем они думают после первого свидания. Предлагаю такую ситуацию: свидание понравилось, но парень не звонит уже две недели. После этого он появляется на пороге с букетом цветов и извинениями. Я прошу сравнить его поведение с поступком человека, который уже по дороге домой посылает первое СМС: «Отлично провел вечер, очень хотел бы встретиться снова. Позвоню завтра?» – а затем действительно звонит. Кого выберет девушка? Часто казалось бы малозначительные поступки вызывают больше доверия к человеку, чем яркие, но совершаемые от случая к случаю.

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

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