Канбан. Альтернативный путь в Agile - стр. 21
Снижение количества незавершенных задач, или сокращение продолжительности итерации, оказывает серьезное влияние на исходное качество. Судя по всему, отношение между количеством незавершенных задач и исходным качеством нелинейно, то есть ошибки растут непропорционально увеличению количества незавершенных задач. Таким образом, видимо, двухнедельные итерации лучше четырехнедельных, а недельные еще лучше. Более короткие итерации повышают качество.
Логика представленных свидетельств подсказывает, что имеет смысл ограничить число незавершенных задач при помощи канбан-системы. Если мы знаем, что управление незавершенными задачами пойдет на пользу качеству, то почему бы не прописать формальные правила ограничения их количества, тем самым высвободив менеджеров для другой деятельности?
Из тесной взаимосвязи между незавершенными задачами и качеством следует, что этап 2 нашего рецепта должен внедряться параллельно с этапом 1 или сразу после него.
Кто лучше?
Я вмешался в деятельность команды разработки сервера закачек OTA в рождественскую неделю 2003 года и сообщил ведущему программисту, что незавершенных задач слишком много, время разработки велико, а завершено на самом деле не так много. Я посетовал, что все это приведет к потерям в качестве. Мои опасения были услышаны, и в январе 2004 года в работе команды появились некоторые изменения. В итоге в 2004 году сократились и незавершенные задачи, и время выполнения. Однако эти перемены произошли слишком поздно: команда уже успела наделать много ошибок.
Согласно диаграмме, проект был завершен примерно в середине марта 2004 года, но на самом деле команда продолжала работу над программами до середины июля. Половина команды разработчиков OTA DM были отозваны со своего проекта, чтобы помочь в работе над ошибками. В июле 2004 года руководитель бизнес-подразделения объявил продукт готовым, несмотря на то что не был уверен в его качестве. Продукт перешел к команде поддержки. За это время 50 % клиентов отменили заказы, усомнившись в качестве продукта. Хотя члены команды поддержки сохраняли хорошие личные отношения с разработчиками продукта, они разуверились в их профессионализме. По их мнению, продукт был плох, а разработчики оказались ни на что не способны.
Как ни странно, если бы в то время кто-то из посторонних спросил разработчиков: «Кто здесь самый умный?» – они указали бы на одного из членов той самой злополучной команды. Такую же реакцию вызвал бы вопрос «У кого здесь больше всего опыта?». Проанализировав резюме, вы убедились бы, что средний опыт команды разработчиков сервера закачек превосходил опыт команды, отвечавшей за управление устройствами, на три года. По бумагам выходило, что команда сервера закачек лучше. И некоторые из ее членов до сих пор в этом уверены, несмотря на множество свидетельств обратного.