Ощадливе виробництво в IT-компанії: рекомендації щодо вдосконалення розробки програмного забезпечення

Щоб підтримувати прості й зрозумілі технічні рішення під час розроблення програмного продукту, треба дотримуватися трьох важливих принципів програмного забезпечення

Принципи розроблення програмного забезпечення

Роберт Мартін у книжці «Чистий код» приділяє увагу таким принципам розроблення програмного забезпечення:

1. DRY;
2. YAGNI;
3. KISS.

Принцип 1

DRY (Don’t Repeat Yourself – не повторюйся) – принцип розроблення програмного забезпечення, спрямований на зменшення дублювання коду, яке може призвести до поганого рефакторингу та неналежного обслуговування. Іншими словами, якщо вам потрібно скопіювати та вставити ті самі точні рядки коду, які забезпечують ту саму функціональність, то є ймовірність, що у коді будуть різні імплементації одних і тих самих рішень. Тож головне кредо принципу DRY (рисунок 1) – кожна частина знань повинна мати єдине, однозначне, авторитетне представлення в системі.

Принцип 2

YAGNI (You Ain’t Gonna Need It – вам це не знадобиться) – це принцип, адресований розробникам, які люблять думати наперед і програмувати додаткові функції, припускаючи, що вони знадобляться їм пізніше. Принцип YAGNI (рисунок 2) був розроблений у контексті екстремального програмування (XP) і висуває вимогу припинити цю звичайну практику та впроваджувати лише ті функції, які були справді необхідні, замовлені чи обговорювалися.

Якщо реалізуються лише ті вимоги, які мають бути чітко реалізовані, то це надає деякі переваги.

Принцип 3

KISS (Keep It Simple and Stupied – зробіть це якомога простіше) – це принцип, який зосереджується на простоті як на засобі та меті. В основу принципу (рисунок 3) закладено кредо не ускладнювати речі, а завжди шукати або використовувати найпростіше рішення для розв’язання проблеми.

Простота має свої переваги, що, своєю чергою, свідчить про важливість застосування цього принципу у програмуванні.

Тож у разі застосування зазначених принципів можна зменшити технічні та командні втрати.

Пропозиції щодо вдосконалення системи управління ощадливим виробництвом

Проаналізувавши персональну продуктивність кожного розробника, було виявлено такі види втрат:

• організаційні:
  • загальні зустрічі;
  • часта зміна пріоритетів;
  • додаткові витрати часу під час зустрічей;
• на рівні процесу:
  • загальні скрам-процедури (чи працюють вони належним чином);
• командні:
  • менторинг нових людей;
  • безперервна інтеграція/безперервне доставлення;
  • рецензія коду;
• технічні:
  • дублювання коду;
  • технічний борг;
  • неякісний код;
  • непотрібний код.

Аналізувати треба втрати із найвищим ступенем марнотратства, а для їхнього усунення можна врахувати наступні пропозиції.

1. Втрати на рівні процесу

Тут втрати найбільші, тому зміни потрібно втілювати саме у цій сфері.

Основні пропозиції щодо мінімізації:

• збільшення взаємодії всередині команди;
• підвищення обізнаності командою бізнес-процесів компанії;
• зменшення ризиків непередбачуваних витрат часу;
• постійне стеження за поточними пріоритетами бізнесу;
• краще, ніж підготовка, є лише завчасна підготовка.

2. Командні втрати

Посідають друге місце за марнотратством.

Основні пропозиції щодо покращення:

• автоматизація тестування та запровадження перевірок ітерацій у неробочий час;
• заохочення співробітників до самостійного тестування своєї роботи;
• спрямування рецензії коду на обізнаність інших членів команди зі змінами та зосередження на пропозиціях щодо поліпшення коду;
• запровадження інструкції з основними пунктами стосовно очікувань від рецензії;
• об’єднання розробників на етапі проходження рецензування змін.

3. Технічні втрати

Є третіми за марнотратством, але від цього не стають менш важливими. Основні пропозиції щодо вдосконалення:

• автоматична перевірка якості програмного коду на етапі внесення змін;
• проведення рефакторингу та декомпозиції безпосередньо під час внесення змін для спрощення заплутаності коду та поліпшення його розуміння.

4. Організаційні втрати

Оскільки організаційні втрати становлять трохи більше ніж 4%, то на поточний момент зміни має сенс вносити лише як рекомендації, як проводити зустрічі командам, щоб зустрічі тривали менше часу та на них були присутні лише необхідні люди.

Зміни на рівні процесу: вдосконалення системи

Оскільки попередньо було визначено, що втрати на рівні процесу мають найбільшу частину марнотратства, то впровадження змін має сенс починати саме з цієї частини.

Поточний скрам-процес слід модифікувати наступним чином.

1

Продукт-менеджери один раз на спринт (можна рідше, але не частіше) презентують пропозиції щодо нової функціональності. Команда уважно слухає презентацію, ставить уточнювальні запитання, щоб краще зрозуміти побажання бізнесу.

Тривалість цієї зустрічі не повинна перевищувати 60 хвилин.

2

Перед кожним спринтом команда збирається на попередній грумінг та вирішує, які задачі з наступного спринту вже повністю зрозумілі, тобто вся команда знає, як їх виконати. У разі якщо задачі не цілком зрозумілі, тоді варто, щоб розробник, тестувальник та продукт-менеджер їх додатково дослідили. У таких випадках до спринту додається окрема задача щодо дослідження.

Тривалість цієї зустрічі не повинна перевищувати 45 хвилин.

3

На етапі грумінгу відбувається оцінювання задач. Команда розглядає тільки зрозумілі задачі (завдяки попередньому грумінгу). У разі презентації задач після проведення додаткового дослідження її здійснює продукт-менеджер, відповідальний розробник або тестувальник.

Тривалість цієї зустрічі не повинна перевищувати 90 хвилин.

4

На планінгу команда за середньої статистичної швидкості бере задачі відповідно до заздалегідь проставленого продукт-менеджером пріоритету.

Тривалість цієї зустрічі не повинна перевищувати 30 хвилин.

5

Упродовж всього спринту учасники команди мають записувати свої думки для майбутньої ретроспективи – це допоможе скоротити витрати часу на згадування подій, які відбулися. Скрам-майстер має чітко слідкувати на часом обговорення кожного питання (5 хв на обговорення будь-якої проблеми). Після обговорення команда має записати на дошці дії для вирішення обговорюваної проблеми та дотримуватися їх у подальшій роботі.

Тривалість цієї зустрічі не повинна перевищувати 60 хвилин.

Якщо перелічити витрати часу, наявні після впровадження змін скрам-процедур, то виходить, що кожний член команди розробки почне витрачати на скрам-процеси приблизно 8 годин, що на 3 години та 15 хвилин менше, ніж було раніше. У відносних показниках це становить трохи менше ніж 29%.

Зміни на рівні команди: що у фокусі

Переходячи до оптимізації командних витрат, варто сфокусуватися на таких пунктах:

• зменшити час очікування перевірки після внесення змін;
• у перевірку мають бути включені якомога більше базових сценаріїв, тестування яких автоматизоване та дає змогу виявити помилки на ранніх стадіях, що уможливлює уникнення додаткових витрат;
• рецензія коду має відбуватися якомога швидше та відповідати критеріям, прийнятим командою;
• у разі важких задач автор презентує свої зміни іншим членам команди.

Розглянемо алгоритм імплементації наведених пунктів.

Крок 1. Безперервна інтеграція/безперервне доставлення

Безперервна інтеграція передбачає:

• паралельне запускання тестів на агентах Jenkins/Bamboo, що дає змогу прискорити їхнє проходження та отримання результатів;
• проведення повторюваних перевірок інтеграцій завершених версій у неробочий час та надання звіту про виконання на електронну пошту усім зацікавленим особам;
• здійснення перевірок успішності проходження розробниками тестів на своїй робочій станції;
• виконання будь-якої роботи із Jenkins/Bamboo у неробочий час, що дасть змогу розробникам та тестувальниками продовжувати свою роботу без переривань.

Крок 2. Рецензія коду

Оскільки усі зміни мають пройти рецензування й беручи до уваги кількість коментарів до змін, можна дійти висновку, що в учасників команд різне розуміння того, як готовий код має виглядати та які принципи побудови коду мають бути застосовані.

Кожна команда повинна сформувати свій список необхідних пунктів, які мають бути виконані кожним розробником перед тим, як віддавати зміни на рецензію. У разі великих змін розробник має презентувати внесені зміни членам своєї команди (архітектор також може бути присутнім).

На презентації автор:

• аргументовано пояснює внесені ним зміни;
• відповідає на запитання;
• у разі кворуму вносить зміни у свій код відповідно до рішення команди.

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

Крок 3. Автоматизація тестування

Тестувальники разом із розробниками мають написати тести (кожний на своєму рівні) для перевірки того, що програмний код відповідає бізнес-вимогам.

Тести мають бути включені до CI та запускатися щоразу, коли вносяться зміни.

Це має сприяти не допусканню змін, що не відповідають бізнес-вимогам, та виявленню будь-яких помилок в імплементації якомога раніше, що дасть можливість скоротити витрати тестувальників та на внесення повторних змін розробниками.

За умови втілення всіх запропонованих змін витрати команди будуть становити:

• очікування завершення CI мають становити 15 хв;
• тривалість рецензії коду – 90 хв;
• враховуючи, що розробник протягом спринту робить 4 задачі, то командні витрати на розробника становлять 8,75%.

Зміни технічних підходів

Оскільки під час внесення змін у програмний продукт кожний розробник користується своїм відчуттям щодо якості змін, то й надалі підтримка такого програмного коду або внесення змін у нього може супроводжуватись зайвими часовими витратами.

Найчастіше, коли розробник намагається вносити зміни у програмний код, він насамперед сподівається розібратися у логіці цієї частини коду або всього продукту загалом. Нерідко трапляється й таке, що поточна архітектура системи є доволі складною, й найрозповсюдженіший варіант, який обирає розробник, – це спрощення архітектури (або конкретного блоку) продукту та оновлення документації для неї.

Виходить, що рефакторинг змінює програмний код продукту та при цьому не змінює зовнішньої поведінки продукту.

Для того, щоб спрощення складності системи відбувалося, необхідно дотримуватися принципів розроблення програмного забезпечення (DRY, YAGNI, KISS), що є основним пунктом змін у роботі команди.

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

Для того, щоб принципи програмного забезпечення застосовувалися, необхідно їхнє використання прописати в інструкції до рецензії коду. Тоді кожний розробник перед тим, як представити свої зміни, перевірятиме, щоб усі пункти з інструкції були виконані. А якщо якісь пункти будуть пропущені, то на етапі рецензування на них вкажуть інші члени команди.

Але навіть чітко прописані інструкції не можуть повністю запобігти появі невідповідного коду. Тому, щоб цьому запобігти, треба перевірку коду додати до CI-процесу – за такого підходу це збереже час команди, а розробник, який вносить зміни, буде знати про порушення інструкцій набагато раніше.

Для виконання автоматизованої перевірки можна скористатися спеціальним технічним продуктом – SonarQube.

SonarQube – це інструмент підвищення якості коду, який виконує поглиблений аналіз, створює на основі нього звіт для забезпечення надійності коду, визначає та виправляє дублікати коду й потенційні помилки.

SonarQube (рисунок 6) використовується як для забезпечення якості коду, так і для його захисту.

Використання SonarQube дасть змогу:

• виявляти проблеми з якістю коду під час його розроблення;
• здійснювати перевірку на відповідність стандартам, прийнятим у команді/компанії;
• виконувати докладний опис знайдених помилок;
• знаходити шляхи для їхнього усунення.

Використання SonarQube та дотримання інструкцій дає можливість підвищити якість й зменшити потенційні помилки у коді програмного продукту. Такі зміни позитивно вплинуть на зменшення кількості помилок у продукті, чим підвищать стабільність продукту для кінцевого користувача.

Після втілення змін можна підрахувати технічні витрати, беручи до уваги такі показники:

• середнє значення кількості дефектів на розробника у спринт 2 і необхідний час для виправлення неправильної поведінки, що у середньому становить 60 хв;
• оновлення коду до нових версій їхніх залежностей, що стається раз на квартал – 2 год;
• розв’язання технічного боргу для внесення необхідних змін, що стається раз квартал – 5 год (5,42%).

Зміни на рівні організації: що не так із зустрічами

Очевидним є факт, що майже 32% часу команди витрачається на різні зустрічі.

Основним варіантом зменшення витрат на зустрічі є пропозиція щодо мінімізації кількості необхідних учасників, що дасть змогу скорити загальний час зустрічі та не витрачати час інших людей, які не мають там перебувати.

Дотримання цих простих умов кожним співробітником компанії може допомогти зменшити часові витрати на зустрічі для людей, які там не мають бути. Також такі зміни будуть спонукати до зменшення тривалості зустрічей, оскільки кількість зацікавлених осіб буде мінімально достатня.

Оскільки ці зміни будуть впливати на усі зустрічі в компанії, то порахувати, як зміняться організаційні витрати, можна доволі умовно, бо загальні зустрічі відбуватимуться з такою самою регулярністю. Наразі такі витрати охоплюють 4,53% й приблизно можна очікувати, що вони будуть зменшені до 4%.

Персональна продуктивність

Формула для розрахунку персональної продуктивності:

FF = 0,8 × (1 – Орг) × (1 – Про) × (1 – Ком) × (1 – Тех).

З огляду на розраховані дані після втілення змін можна отримати новий фокус-фактор для розробника:

FF = 0,8 × (1 – 0,04) × (1 – 0,0808) × (1 – 0,0875) × (1 – 0,0545) = 0,61.

Тобто запропоновані зміни зможуть підвищити фокус-фактор кожного співробітника на:

або:

FF = 8 × (0,61 – 0,505) = 0,84 год (чи 50 хв).

Рекомендації для розробників

1

Для впровадження системи ощадливого виробництва в частині зменшення втрат слід проводити:

• рецензування коду іншими розробниками для підвищення обізнаності зі змінами кодової бази;
• ретельне планування проєкту розробниками для уникнення затримок та перевитрат;
• затвердження чітких, лаконічних та повних вимог до продукту перед початком розроблення для запобігання змінам вимог пізніше;
• ретельне тестування продукту для виявлення дефектів на ранніх етапах розроблення;
• регулярний аналіз продуктивності продукту для виявлення можливих поліпшень;
• визначення надійності продукту пріоритетом у розробці;
• дотримання принципів розроблення програмного забезпечення кожним розробником, щоб зробити програмний код простішим та зрозумілішим;
• регулярний рефакторинг для покращення якості кодової бази;
• формалізація загальних правил проведення зустрічей.

2

Для вдосконалення системи управління ощадливим виробництвом IT-компанії необхідно:

• посилити відповідальність команди розробки та гнучкість;
• залучити команду до регулярної комунікації із бізнесом для кращого розуміння бізнес-процесів;
• формалізувати інструкції щодо готовності змін у коді до їхнього рецензування;
• впровадити автоматичну перевірку кожної зміни кодової бази на відповідність функціональним вимогам та загальній якості програмного коду;
• формалізувати інструкції щодо написання коду та методики для зменшення його складності й підвищення читабельності;
• застосувати загальні правила проведення зустрічей.