Дэвид Андерсон - Канбан. Альтернативный путь в Agile

Существует причинно-следственная связь между количеством незавершенных задач и средним временем выполнения, и эта зависимость линейна. В производстве эти отношения известны как закон Литтла. Пример двух команд из Motorola предполагает наличие корреляции между увеличением времени выполнения и снижением качества. Похоже, что увеличение времени выполнения оборачивается существенно худшим качеством. В нашем случае увеличение среднего времени выполнения в 6,5 раза повлекло за собой более чем тридцатикратное увеличение первичных ошибок. Более долгое время выполнения связано с увеличением количества незавершенных задач. После выявления этого примера я стал использовать незавершенные задания как средство контроля качества и убедился в наличии взаимосвязи между их количеством и исходным качеством кода. Однако на момент написания этой книги не существует научных подтверждений этого эмпирически полученного результата.

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

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

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

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

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

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

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

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

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

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

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

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