Agile-просвітлення, прийди!

Agile manifesto

Agile-люди

Agile-mindset

Agile...ти мене заєбав.

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

       В основному в цій темі зараз все крутиться довкола двох слів підходів - Waterfall і Agile. При всій своїй важкості Waterfall model є чіткою і логічною системою, що пропонує класичне поетапне створення продукту - збираємо вимоги, проектуємо, програмуємо, тестуємо, впроваджуємо. Але стандартний, і на перший погляд такий логічний підхід на сьогодні в світі програмування практично прєдан анафемі, тобто витіснений т.з. "гнучким" підходом, ім"я якому - Agile. От зібрались люди, яким набридло все планувати і робити послідовно, і написали отакий документ:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation 
• Responding to change over following a plan 

 (С) http://agilemanifesto.org/

Досить! Не буде більше PRDшок, специфікацій, довгих стадій проектування, збору вимог! Це не для нас! Ми будемо слідувати наступним принципам. 

    І стало так. Але, як завжди, диявол - у деталях. Людям мало було самого лише маніфесту і принципів. Вони, незважаючи на бажання бути гнучкими, вимагали конкретики. Адже емоційні формулювання маніфесту і принципів допускали не набагато менше трактовок, ніж Святе Письмо, і кожна людина розуміла Agile по-іншому. Потрібні були жерці, які б трактували сакральні тексти, і пропонували конкретні рецепти як зробитися Agile.

      І такі жерці народилися на вимогу часу. І стали вони нести за гроші і просто так "Agile-цінності" в маси, мозок яких був вражений ватерфолом і іншими єресями. Конкретики це не додало, проте дало можливість заробити грошей і авторитету огромній масі народу, які позиціонували себе як Agile-евангелісти і Agile-коучі. Згодом для простоти розуміння і конкретизації абстрактний Agile був конкретизований в два "фреймворки", які є найбільш популярними в наші дні процесами розробки програмного забезпечення. SCRUM і Kanban. І ось нарешті - подумали всі - все стане ясно і зрозуміло. Людство отримає чіткий рецепт випікання якісного софта у встановлені терміни за очікувані гроші.

А рецепт був наступний.

1. Є представник замовника, який знає все на рівні замовника і часто навіть краще, при цьому грамотний технічно. Він миттєво відповідає на всі питання щодо проекту, незалежно від складності. Називається він Product owner.

2. В команді є людина, яка організовує процес спілкування між членами команди і замовником, слідкує за тим щоб у всіх був Інтернет, і т.д. Зветься SCRUM-майстер.

3. Продакт овнер набиває список задач в т.з. беклог.

4. Працюємо ітеративно т.з. "спрінтами" довжиною в 2-4 тижні. На початок спрінта ми беремо з беклога стільки задач, скільки встигнемо зробити за спрінт, і 2 тижні фігачимо код. При цьому втручатись в нашу роботу під час спрінта ніхто права не має. На кінець спрінта показуємо продакт овнеру що зробили, і він нас хвалить.

5. Щоб всі знали що хто робить, і які проблеми має - раз в день ми збираємось на денний Скрам, який триває до 15 хвилин.

Класно і просто. Слідуй правилам, і все в тебе буде ок. Що тут пояснювати? Все влазить на півлисточка, або в одну картинку.

    Але диявол, як завжди, в деталях. Як в договорах з банком, маленькими літерами написано, що для того щоб це спрацювало, люди в команді мають бути не просто людьми, а agile-людьми. Якщо ти не віриш, молись хоч все життя - нічого не допоможе. Спочатку Ти повинен прийняти Бога. При цьому на тему що таке "прийняти Бога", і як це зробити можна говорити без кінця. Ще одна примітка вимагає, щоб команда була кросфункціональною, самоорганізованою, і високомотивованою. Крім того, задачі в беклогу мають бути повністю визначені і зрозумілі, а продакт овнер має відповідати практично миттєво на будь-яке питання.

     В основному через ці "деталі" одним листочком справа не обмежилась. Замість простоти через ці "деталі" народились тисячі апокрифів, які трактують вже в свою чергу Скрам на свій лад. Існує неймовірна кількість книжок, статей, презентацій, і всі вони - конкретно різні. Часом принципово різні. А канону все нема. Перелопативши тони сторінок, я все більше розумію, що толком не знаю що говорити на презентації, і як відповідати на можливі питання, щоб не червоніти. Можливо, просвітлення прийде до мене у сні?