Как могат дигиталните компании да развият конкурентно предимство в бъдеще насочено първо към технологиите? Като използвате лийн мисленето, за да осигурите постоянно обучение и трансформирате начина, по който мислят и работят хората, които създават програмен код.
Автор: Бен Елерби, Вицепрезидент – Инженеринг, Theodo – UK
Софтуерното разработване се промени много откакто бе създаден Аgile манифеста и по-широкото Agile движение, което се роди в началото на 2000-та година. Напоследък разработчиците в много компании са доста по-свързани с крайния клиент на системата, която създават и редовно се фокусират над екипното подобрение.
Лийн произходът на Аgile принципите са добре разбрани от лийн практиците, участващи в проектите по развиване на Аgile – от кратки цикли за обратна връзка към постоянно подобрение под формата на ретроспекции. Дори терминологията на лийн бива използвана (понякога не по предназначение) в Аgile среда – помислете за канбан дъските и системата „аndon“.
Книгата „Лийн софтуерно разработване“ от Попендайк свърши добра работа относно ясното очертаване на лийн инструментите, който са приложими при писането на софтуер. На практика много разработчици, който познавам никога не бяха чували за лийн мисленето докато не са попаднали на тази книга, изследвайки Agile и Scrum. Книгата е чудесен източник за намиране на лийн практики, които са адаптивни към контекста на софтуерното разработване, без да са прекалено стриктни или следващи универсалния подход за различаващи се ситуации – добре известна слабост в някои от Аgile рамките като Scrum.
Въпреки всичко това, все пак има нещо, което възпира софтуерните разработчици от тоталното приемане на силата на лийн мисленето. Мнозина се опитват да преодолеят подхода базиран на инструменти и да променят начина, по който хората в организацията мислят (проблем, с който се сблъскват специалисти от различни индустрии).
Промяната във фокуса от използването на инструменти към начин на мислене е засегната в детайли в книгата „Лийн стратегия“. В Тheodo сме щастливи че имахме сенсей – който освен всичко е автор на книгата – той ни вдъхновява за промяна в начина, по който работим. Когато Майкъл Бале започна да идва на гемба тур бяхме разтревожени, докато в един момент не осъзнахме, че само лидерският екип ще бъде подложен на това предизвикателство (това беше релаксираща мисъл за мен преди самият аз да стана част от лидерския екип). Със своето критично око, Майкъл ни окуражаваше да създадем култура на обучение и среда, благоприятна за непрекъснато усъвършенстване – вместо да разчитаме на някакво предварително поднесено решение.
Всичко това може да звучи доста теоретично за разработчиците на софтуер и донякъде трудно да се прилага към ежедневните обстоятелства. Всъщност, едва когато видите лийн принципите в действие в реална ситуация, можете напълно да разберете въздействието, което този алтернативен начин на мислене, работа и управление може да има. И това е вярно, независимо дали пишете софтуер, произвеждате коли, управлявате пекарна или преподавате на студенти.
Спомням си един от тези „aха“ моменти, когато видях потенциала на лийн мисленето в света на Agile софтуерната разработка. Преди няколко години ръководех голям проект с много разработчици, които пишеха и пускаха в действие програмен код ежедневно. С напредването на проекта, осъзнахме, че има риск някои от грешките да се появяват на няколко места заради повторение на кода, което ще направи уеб апликацията по-бавна. Вместо да използвам познатия подхода отгоре-надолу, аз организирах ежедневна Kaizen среща с разработчиците.
Всеки път, когато пускаха в действие някоя от функциите, повторението на кода и начина, по който сайта работи се записваха. Всеки следобед екипът се събираше, за да разгледа записите и да анализира първопричините за проблемите, като класифицира появата им по видове в Парето диаграма. Бяха идентифицирани краткосрочни и дългосрочни контрамерки и – най-важното – екипът се учи по време на целия процес. Едва година по-късно, когато се върнах на посещение при същия клиент, разбрах в действителност колко мощно може да бъде лийн мисленето, когато става въпрос за създаване на обучителна среда.
Нашите екипи отдавна вече бяха предали щафетата на обучените от нас вътрешни инженерни екипи на клиента. Нов разработчик се присъедини към екипа в същия ден от посещението ми. Той току-що беше инсталирал софтуера и беше в процес на изпращане на първата си функция. Тъй като чаках да пристигне техническия директор, използвах шанса да наблюдавам работата му. Той въведе кода си, задействайки автоматизираното стартиране на компилация и след това получи червено съобщение за грешка. Той прочете на глас: „Kaizen проверка неуспешна: Дублирането на кода се увеличава“. Това беше механизъм poka-yoke, който бяхме добавили преди повече от година, след като анализирахме предишното дублиране на код. Разработчикът преработи кода си, за да премине проверката. Бях доволен, знаейки, че нашата дългосрочна контрамярка все още работи.
След срещата ми с техническия директор се върнах обратно в офиса за разработване на отворен план и видях екипа струпан пред бяла дъска. Те анализираха първопричината за дублирането на кода, тъй като проверката на новия кодер, беше изпратила съобщение до мейла на Kaizen групата. Докато работеха съвместно с разработчика, за да разберат ситуацията, той се поучи от опита им, а екипът научи, че конкретна част от базата данни на трета страна, която използваха, имаше несъвместими интерфейси, които предизвикваха дублирането. Екипът продължаваше да се подобрява с всеки изминал ден.
Pазлична парадигма за софтуерно разработване
Аз вярвам, че въвеждането на теорията за лийн мислене в програмирането е начинание, изискващо ново поколение от лийн разработчици. Твърде много организации са все още вкопчени в стари бюрократични структури, които са причина те да инвестират в мениджмънт обучения от бизнес гледна точка без да осъзнават, че бъдещето на една организация в свят воден от технологии лежи в ръцете на хора, които развиват своите технически възможности. В крайна сметка е трудно да си представим успешна дигитална трансформация, която не взима предвид дигиталната страна на бизнеса!
Компаниите, които ще успеят в настъпващите несигурни и бързо променящи се времена са тези, които осигуряват възможност на своите разработчици да работят по Лийн методология. Да приложиш метод като Scrum и да кажеш, че си Аgile вече не е достатъчно. Дори, когато възприемем лийн методологията като мениджъри, ние сме длъжни да направим повече от създаването на няколко слайда в презентация за постоянно подобрение или да направим упражнение свързано с карта на стойностните потоци. Трябва да се фокусираме върху това къде се създава стойност, а именно: въвеждане на Лийн мисленето в софтуерното развитие означава трансформацията да премине в „гемба“, разработчиците да променят своя начин на мислене, писане на програмен код, изграждане на функции и създаване на учебна култура, която позволява непрекъснато подобрение.
В този дух аз стартирах нов подкаст с Майкъл Бале, за да вдъхновя ново поколение Лийн практици в света на софтуерното разработване. Майкъл осигури теорията и своето уникално разбиране за Лийн, а аз осигурих инженерния опит от разработването на софтуер до изграждане на модерни облак архитектури. Нашата цел е да разгледаме реални проблеми, с които ежедневно се сблъскват разработчиците и да ги погледнем през призмата на Лийн. До този момент засегнахме теми включващи въздействието на малки партиди върху цялостните технически структури, непрекъснато усъвършенстване на нерегулярни задачи и „гемба“ насочена към създаването на код. Можете да намерите Лийн Дев подкаста на предпочитана от вас подкаст платформа или в платформата на Anchor.fm/lean-dev
Бен Елерби, Вицепрезидент – Инженеринг, Theodo – UK