КАК МЫ С ПОМОЩЬЮ LEAN РЕШИЛИ ПРОБЛЕМУ ДУБЛИРОВАНИЯ КОДА
Разработка программного обеспечения очень изменилась с тех пор, как был написан Agile манифест, а Agile движение было широкомасштабным, появившись в начале 2000 годов.
В наши дни разработчики во многих компаниях крепче связаны с конечным потребителем систем и постоянно фокусируются на улучшении себя, как команды.

Agile принципы происходят от Lean, это прекрасно понимают практики Lean методологии, которые активно участвуют в проектах Agile разработки - от коротких циклов обратной связи к постоянному совершенствованию, в форме проведения ретроспектив. Даже терминология Lean содержит в себе Agile - канбан доски и «Андон».
Книга «Software Development» Попендика позволила более четко изобразить инструменты Lean, которые можно применить в практике написания программного обеспечения. На самом деле, насколько я знаю, многие разработчики не слышали о Lean мышлении, пока не наткнулись на эту книгу, в ходе исследования Agile и Scrum. Книга - отличный ресурс для поиска методов Lean практик, которые можно адаптировать к контексту ИТ. Если вы имеете директивный характер, то вам известно о слабых местах Agile и Scrum.

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

Смещение фокуса с инструментов на образ мышления подробно описано в книге «Lean стратегия». В компании Theodo, нам очень повезло, что у нас был сенсей (Майкл Балле), который является одним из авторов книги, вдохновляет на перемены. Ранее мы очень волновались, когда Майкл Балле приходил прогуляться в нашей Гембе (местом, где создается ценность), пока мы не поняли, что работа команды лидеров может ставиться под сомнение. Это был момент расслабления для меня, прежде чем я стал членом команды лидеров. Своим критическим взглядом на все, Майкл подталкивал нас создавать культуру обучения и окружения, которое способствует постоянному совершенствованию, вместо того, чтобы заставлять нас полагаться на заранее подготовленное решение.

Все это может показаться немного теоретическим для разработчиков программного обеспечения и несколько трудновыполнимым для их ежедневного использования. На самом деле только тогда, когда вы увидите Lean принципы в действии в реальной жизни, вы сможете понять, как может повлиять это альтернативное мышление, работа и управление на организацию. И это действительно так, независимо от того пишете вы код программного обеспечения, или проектируете авто, управляете пекарней или обучаете.

Я помню этот момент, когда я увидел потенциал использования Lean мышления в мире Agile software development. Несколько лет назад, я руководил большим проектом, в котором большинство разработчиков писали код и выпускали его ежедневно. Во время продвижения проекта, мы поняли, что есть риск, некоторые ошибки могут появляться в нескольких местах одновременно, из-за дублирования кода, что приведет к замедлению работы. Вместо того, чтобы подходить к этому вопросу сверху вниз, я организовал ежедневные кайдзен встречи с разработчиками. Каждый раз, когда они собирались сделать релиз функции, мы фиксировали дублирования кода и производительность. Ежедневно команда собиралась вместе, чтобы взглянуть на данные и проанализировать основные причины проблемы, классифицируя их возникновения по Диаграмме Парето. Внедряли краткосрочные и долгосрочные контрмеры, и важно то, что команда училась в течение всего процесса. Лишь год спустя, когда я вернулся к этому клиенту с визитом, я действительно понял насколько сильным может быть Lean мышление, когда дело доходит до создания учебной среды.

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

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

Другая парадигма разработки программного обеспечения.

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

Компании, которые преуспеют в это неопределенное и изменчивое время - это те, кто инвестирует в то, чтобы дать своим разработчикам возможность работать с Lean. Использовать такие фреймворки, как Scrum и говорить, что вы Agile, тольок этого недостаточно. Даже когда мы используем Lean, нам, как менеджерам необходимо делать в разы больше, чем просто создать несколько слайдов о «постоянном улучшении» или строить карту потока создания ценности.

Нам нужно сфокусироваться на том, где создается ценность: внедрение Lean в разработку программного обеспечения означает трансформация Гемба, изменение способа мышления разработчиков, написание кода и создания культуры обучения, которая позволяет непрерывно улучшаться.

Именно поэтому, я запустил новый подкаст с Майклом Балле, чтобы вдохновить новое поколение практиков Lean. Во время разговоров Майкл рассказывает теорию и свое уникальное понимание Lean методологии, а я делюсь своим инженерным опытом, от программирования ПО к созданию современной облачной архитектуры. Наша цель разобрать реальные проблемы, с которыми сталкиваются разработчики и взглянуть на них с точки зрения Lean. Подкаст можно найти по ссылке: https://anchor.fm/lean-dev

ВОЗНИКЛИ ВОПРОСЫ?
Запишитесь на консультацию, и наш менеджер свяжется
с Вами в самое ближайшее время
16.04 / 2021