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

• Название: Канбан. Альтернативный путь в Agile
• Автор: Дэвид Андерсон
• Жанр: Корпоративная культура, бизнес
• Год: 2017
• ISBN: 978-5-00100-530-8

«Канбан» в переводе с японского – «сигнальная доска». В производстве такая доска используется для визуализации нарастающих темпов, что позволяет выпускать больше продукции с меньшими затратами. Яркий пример – подход компании Toyota, благодаря которому в течение многих лет эффективно реализуется принцип «точно в срок» с минимальными издержками.

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

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

На русском языке публикуется впервые.

---

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

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

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

Кто лучше?

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

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

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

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

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

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

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

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

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

Неявное знание

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

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

Баланс между нагрузкой и пропускной способностью

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

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

Создание резерва времени

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