Розробка програмного забезпечення дуже змінилася з того часу, як був написаний 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

Джерело статті:
https://planet-lean.com/lean-software-development/