Agile , який спочатку радує, а потім викликає депресію

На дворі був лихий 2007-й рік

Приблизно в цей же час деякі IT -компанії України почали переймати західний досвід і впроваджувати на своїх проектах нову методологію розробки софта - Agile ( aka «методика гнучкого увертня -програміста »). Вся наша команда гордо збиралася кожен день о 11 ранку на SCRUM - мітингу, де кожен розповідав про поточний стан справ і про те, що він планує за сьогодні зробити . Ці збори зазвичай займали не більш 10-15 хвилин, але до них також потрібно було хоч трохи підготуватися. Тим більше що замовники - швейцарці, а значить, спілкування англійською . Тобто ще мінімум 5-10 хвилин йшло на те , щоб прикинути, про що говорити . Але найчастіше напередодні виникав якийсь аврал , і вранці нічим було похвалитися . А значить, для підготовки до SCRUM - мітингу потрібно було ще більше часу , щоб пояснити причини свого не такого бравого просування в роботі . У підсумку вся ця епопея з номінально короткими зборами займала від півгодини реального часу. Але нам подобалося. Всі ці різнобарвні листочки для кожного завдання, з написаними поверх них іменами і кількістю годин, естімейшн покер , парне програмування, мінімум документації і такий бойовий темп з реально працюючим прототипом продукту - це все приваблювало. Ми так повірили в Agile і SCRUM , що пару чоловік з нашої команди навіть замовили собі додому по SCRUM - дошці з пробки.

XP

Що стосується екстремального програмування , то народна мудрість говорить - « безпечну річ екстремальної не назвуть ». Короткі цикли « деливери » - це екстремально , так, але наскільки виправдано ? Одна справа, якщо реліз відбувається кожні два тижні, або раз на місяць , але ж бувають і крайнощі. Наприклад , я знаю одну геймдев компанію, де реліз відбувається мало не щовечора . Чи то у них дуже недовірливий клієнт , чи то вони хочуть стимулювати співробітників щодня пушіть свою роботу, щоб було видно, хто над чим працює - складно сказати . І ось кожен день вони виділяють однієї людини - білд - інженера, який займається складанням. А програмісти, звичайно ж, по півдня займаються перевіркою свого коду , який ввечері піде в продакшн . Клієнт задоволений - у нього реал- тайм картинка ситуації на проекті і працюючий код . Але скільки зайвих рухів тіла роблять при цьому програмісти та тестувальники ? Особисто я б вважав за краще один раз принести одне важке відро води , ніж сто разів ходити за водою з кухлем у руці.

TDD

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

Парне програмування

Парне програмування не могло не викликати захоплення. По-перше , удвох думається швидше, та й друга пара очей досить ефективно ловить орфографічні та логічні помилки в коді. По-друге , немає кращого способу підтягти людини в програмуванні, ніж посадити його в пару з більш досвідченим розробником і навчити його думати по -іншому. Ми із задоволенням користувалися цією можливістю повчитися один у одного , тому як якщо б не Agile і XP , начальство дивилося б на нас як на дармоїдів . Але хіба для парного програмування так вже обов'язково брати на озброєння XP ? Коли я більш ніж рік тому прийшов на нову роботу , то з подивом виявив , що ніхто там не молиться на Agile . Більш того, розробка велася в класичному Waterfall . І в той же час я регулярно бачив випадки парного програмування. Хлопці не соромилися нікого, а наші мудрі начальники навпаки заохочували роботу в зв'язці. Так що зовсім не обов'язково сліпо слідувати популярним методологіям в розробці софта, коли можна взяти для себе лише саме корисне і необхідне .

Agile майже римується з « вигорають »

Але тижнів змінилися місяцями, і ми почали відчувати на собі деякий «вигорання ». Справа в тому, що якою б ідеальною не була методологія - завжди будуть вилазити незаплановані баги , які вимагають більше часу, ніж планується. Щоб латати всі ці дірки і в понеділок виглядати так, ніби в тебе все ідеально, доводилося працювати на вихідних. Майже щоденні овертайми навіть не обговорювалися - кожен думав над тим, що йому потрібно буде говорити на наступний день на SCRUM - мітингу . І ситуація була така, що ніхто не хотів виглядати на зборах « слабаком ». Тому кожен намагався побільше зробити ввечері і раніше прийти на роботу , щоб встигнути до 11 щось закінчити і сказати що - небудь у дусі - «Цей функціонал готовий, але його потрібно потестіть » або « Новий сервіс працює, але у мене не було часу його повністю перевірити ». І звучить начебто добре - щось працює , щось готове , щось функціонує, залишилася лише дрібниця , дурниця - потестіть . Ми ніби збирали «лайки » від замовників. Їм подобалося, що у нас справа йде на лад і крутиться. Ми , будучи зеленими студентами , ловили їх схвальні кивки і надихалися працювати довше, більше, краще . Але в цій гонитві за словами « я це зробив » і « воно працює » завжди ховалося і дещо інше - безліч хвостів, і накопичується через стрес вічних дедлайнів втому. Майже ніколи не бувало так , щоб можна було перевести дух і працювати в звичайному режимі. Завтра мітинг, в п'ятницю реліз . Так йшли місяці, поки проект нарешті не закінчилася і ми не злізли з Agile - голки. І хоча я в майбутньому зустрічав Agile і в менш фанатичною формі, ми з друзями прийшли до висновку, що Agile - це фактично белко - колісне підприємство, яке орієнтується в першу чергу на клієнта, заганяючи при цьому своїх співробітників в виснажливі цикли регулярного « деливери ». Так чи інакше, я зробив знижку на своє приватне пересичення цією методологією й успішно забув про Agile на кілька років. До вчорашнього дня .

Ложка дьогтю у вигляді 10 хвилин SCRUM -мітингу

Вчора я зустрів Антона - розробника однієї київської IT -компанії , який, хоч і не пив алкогольного , але був у пригніченому стані. Я почав розпитувати його про життя і про роботу . Виявилося, що в житті все непогано. На роботі теж все добре. Крім одного . І тут я почув давно забуте слово « Agile ». Антон - вельми товариська молодий чоловік, ще студент , при цьому чудово справляється зі своєю роботою. Від чого ж його пригнічує Agile ? Чому його не радує робота так , як могла б ? Виявляється, справа в банальних зборах. Але яким чином всього лише 10 -хвилинний SCRUM - мітинг може отруювати програмісту життя? Може, у Антона всього лише загострене почуття раціональності ? Що , якщо він розуміє, що мітинги - як маленький театр , де кожен грає свою роль? Що якщо він, як і я , не любить брати участь у цій гонці « я зробив найбільше» і « я єдиний з команди, хто реалізував такий складний функціонал » (особливо якщо це вдається далеко не завжди ) ? А може , вся справа в тому , що не буває щоденних зібрань за розкладом, без яких - зовсім ніяк. Адже всі це розуміють. SCRUM - мітинги більше нагадують бюрократичний ритуал , ніж нагальну необхідність. Для галочки. Щоб на зустрічах з клієнтами гордо говорити про те, що, мовляв, «У нас все в топленому шоколаді - за канонами Agile і SCRUM ». Може, весь цей Agile існує для того, щоб тримати співробітників в їжакових рукавицях , тиснути з них соки і поїти їм клієнтів ? Хотілося б вірити, що є і більш гуманні способи підняти продуктивність.

Тому цікава ваша думка :

Чи подобається вам Agile ? Наскільки ефективний цей підхід до розробки ? Як ви ставитеся до SCRUM - мітингів ? Яку методологію ви використовували б (або використовуєте) у своєму стартапі ?

Опубліковано: 26/11/14 @ 12:08
Розділ Різне

SEO Блог