ITRampage

Слово workflow походить від двох англійських слів work – робота та flow – потік, тобто workflow – це потік роботи тут все здавалося б зрозуміло, але… Не всі розуміють що таке потік, чому саме ця метафора використовується.

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

Натомість у багатьох компаніях можна побачити надскладні заплутані workflow, що “течуть” усіма можливими напрямами та які майже ніхто не розуміє. Це все ДУУУУЖЕ сильно сповільняє розробку, збільшує складність та розмиває відповідальність.

Майже будь-яку задачу можна розглядати логістично, тобто через рух у певному не метричному просторі. Переміщення – це результат, а відношення переміщення до пройденого шляху – це ефективність. Ідеальна ефективність – це коли переміщення рівне шляху. Ось фактори, що впливають на співвідношення переміщення до шляху, або на ефективність:

• Локальність змін. Погана гранулярність/модульність/мікросервісна топологія збільшують необхідний шлях у рази. Це стосується не тільки ефективності розробки рішення, але й ефективності самого рішення (See Data-Oriented Design). Також важлива локальність виконавців. Двоє розробників з однієї команди справляться із завданням значно швидше, аніж двоє розробників із різних команд.
• Кількість людей необхідних для виконання змін. Розподіл роботи між багатьма людьми, трекінг стану виконання та синхронізації результатів їх праці – це також додаткові кроки на шляху, які часто займають навіть більше часу, аніж сама розробка.
  • Кількість комунікацій/точок синхронізації між людьми.
• Вимоги до рішення. Рішення саме по собі може бути більш або менш складним. Важливо аби люди, що відповідають за дизайн/архітектуру рішення намагалися будь-що позбутися усього вторинного й прагнули до максимально простого рішення.

Коли ми бачимо складні workflow, то одразу можна зробити висновок про низьку ефективність. Мало того, запозичення складних workflow є культом вантажу.

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

Будь-яке переміщення задачі у інший стан – це щонайменше один додатковий крок. Будь-яке повернення задачі у попередній стан (review, QA reject, …) – це щонайменше два додаткових кроки. Усі складні workflow – це певною мірою намагання видати пересування на милицях за інтенсивну інтелектуальну працю.

Ідеальний випадок

Аби розв’язати проблему, нам необхідно уявити собі як має виглядати ідеальне рішення. Теорія Розв’язання Винахідницьких Задач (ТРИЗ російською) Альтшуллера пропонує цікаву ідею ідеального об’єкта – об’єкта, якого немає, але функція якого виконується. Іншими словами, це розв’язання проблеми без підвищення складності і з застосуванням наявних механізмів та підходів.

В нашому випадку ідеальний об’єкт – це ідеальний workflow. Як він має виглядати? Він виглядає так, що ти сам береш і робиш, або ж делегуєш роботу іншому. Тобто ідеальний workflow – це коли розробник самостійно чи у парі з іншим розробником, якщо використовується підхід парного програмування, бере і виконує завдання, від пропрацювання вимог, до розгортання у production.

Багатьом це здається неможливим, але я працював у парі компаній, де все саме так і було. Крім того, не забуваймо, що Річі та Керніган всього за три тижні розробили мову та компілятор С, текстовий редактор та операційну систему UNIX. По тижню на кожен проєкт. Це було б не можливо зі складним workflow та якби над проєктами працювало кілька десятків розробників.

Code Review

Code Review майже усіма вважається необхідною та дуже корисною практикою. Але хто ті усі? Невже мільярди мух не можуть помилятися і у лайні дійсно щось є? Усі – це ті, хто постійно жаліється на поганий код та необхідність його рефакторити чи переписувати, усі ті, хто допускають величезну кількість дефектів, помилок, вразливостей, створюють дуже не ефективні рішення з поганою модульністю та без дотримання принципу локальності.

В усіх проєктах, які скотилися у лайно був процес Code Review. Чи варто продовжувати витрачати час на Code Review, якщо все так погано?

Цікаво ще те, що більшість компаній прагнуть впровадити CI/CD (Continuous Integration, Continuous Delivery), при тому, що ці підходи суперечать Code Review, оскільки затримують власне Continuous Integration змін.

Якщо Вас дійсно хвилює перевірка якості коду – використовуйте практику парного програмування, яка не просто підвищує якість коду, а й дозволяє розробникам швидше навчатися та обмінюватися досвідом, а також значно підвищує ефективність. Парне програмування – це саме той випадок, коли 1 + 1 = 3, або й 5.

Feature Branches

Використання Feature Branches / Git Flow та інших подібних підходів суперечить CI/CD. Зміни мають надходити кожного дня, бажано декілька разів на день. Merge conflict’и мають бути винятковими ситуаціями, а не правилом.

Я працював у декількох проєктах, де управління гілками та вирішення merge-конфліктів були на стільки складним, що потребували більшого часу, аніж власне розробка. Розв’язувати подібні проблеми планувалося через ще більше ускладнення управління гілками та workflow.

Quality Assurance

Quality Assurance – це дуже складна тема, яку довіряють переважно людям, в яких не вистачило здібностей та/або натхнення стати розробниками, та які завершили курси тривалістю від кількох тижнів до 3-6 місяців. Ця тема заслуговує міріад публікацій, то ж тут я зазначу тезисно лише декілька моментів:

• QA – це не позиція, а відповідальність. QA має займатися кожен, а не хтось окремий.
• Розробники більш компетентні перевіряти якість рішень, оскільки набагато краще розуміють систему із середини.
• Якщо розробники допускають велику кількість дефектів – проблема у менеджменті (дедлайнах), якості вимог, або у самих розробниках. Так звані QA цих проблем не вирішують. Вони лише збільшують кількість залучених людей, кількість необхідних комунікацій/точок синхронізації, ускладнюють та сповільняють workflow, суперечать CI/CD.
• Регресії, яких усі цілком справедливо бояться є свідченням поганої архітектури: поганої модульності, порушення принципу локальності. Дуже часто це пов’язано з використанням саме об’єктноорієнтованого програмування та таких патернів, як, наприклад Entity. Так звані QA здатні лише великою ціною боротися з наслідками, а не причинами.

SCRUM

SCRUM – це не agile, хоча його автор Джеф Сазерленд і є одним із підписантів Manifesto for Agile Software Development. Усі ненавидять SCRUM, окрім менеджерів проєктів та SCRUM-майстрів. SCRUM створювався не для розробки інформаційних систем, а прийшов із військової справи.

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

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

Команді не потрібні спрінти. Це штучні цикли, через які лише витрачається час на ритуали, які нікому не потрібні. Спрінти також дуже часто суперечать CI/CD.

Метафори не працюють

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

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

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