Agile - Що ми робимо неправильно?

Я розробник у спритній команді, і ми намагаємось використовувати Scrum.

Тому я поставлю тут гіпотетичну проблему для ілюстрації ситуації.

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

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

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

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

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

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

Це не має нічого спільного з Agile або Scrum.

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

Першим кроком до відновлення є визнання проблеми та припинення її погіршення.

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

Щоб усунути існуючу проблему, дивіться чудові відповіді на те, що я успадкував 200K рядків коду спагетті - що тепер?

У вас там є те, що Мартін Фаулер називає "в'ялим скрадом".

Якщо ви правильно прочитали всі 12 принципів, що стоять за маніфестом "Agile" , то ви побачите, що ви не вдається на більшості з них.

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

Чи можете ви сказати, що ви постачаєте справді працююче програмне забезпечення? Або просто програмне забезпечення, яке ледь працює?

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

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

Постійна увага до технічної досконалості та гарного дизайну підвищує спритність.

По-справжньому головний принцип. Я вважаю, що це слід розмістити у ВЕЛИЧИЙ ЧЕРВЕНІ ПІСЛЯ на сторінці. Тут найбільше ви провалюєтеся.

Через регулярні проміжки часу команда розмірковує про те, як стати ефективнішою, а потім налаштовує та відповідно коригує свою поведінку.

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

З вашого коментаря

Як запобігти цьому в спритному?

По-перше, дізнавшись, що насправді спритний. Scrum не спритний. Деякі кажуть, що Scrum - це найгірший складний фреймворк, оскільки надто легко досягти вашої точної ситуації. Вам слід дізнатися про інші спритні рамки. Я рекомендував би екстремальне програмування. Що чітко вирішує ваші проблеми. Рішення не прості (зосередитись на технічній майстерності завдяки надійному автоматизованому тестуванню, програмуванню пар та безперервній доставці), але високоефективні. Як повідомляється у звіті State of DevOps .

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

До того, що ви описуєте, є два окремих аспекти :

• Відсутнє загальне розуміння / бачення і тому не є ефективним
• Як виміряти успіх / прогрес і загальну вартість

Спускатися неправильним шляхом або бігати по колах

На мій досвід, головна причина цього трапляється в тому, що , намагаючись швидко створити код, команди активно відхиляють випадки використання або вимоги, про які вони вже знають або про які можна легко дізнатися. Подумайте про це так: 10-20 років тому люди намагалися написати гігантські характеристики і продумати все заздалегідь і часто не вдалося. Вони або зайняли занадто довго, або щось пропустили. Одне з наукових досліджень минулого полягає в тому, що в розробці програмного забезпечення є речі, які ви не можете знати, і речі сильно змінюються, отже, ідея швидко повторюватись і швидко отримувати певний розумний вихід. Це дуже хороший принцип. Але сьогодні ми перебуваємо на іншій крайності: "Мені це не байдуже, тому що це частина наступного спринту" або "Я не подаю цю помилку, я маю справу з нею, коли вона з’явиться знову".

1. Зберіть усі випадки використання , вимоги, залежності та обмеження на високому рівні , які ви можете знайти. Помістіть це у вікі, щоб усі учасники та розробники могли їх бачити. Додайте до них, коли з’явиться щось нове. Поговоріть зі своїми акціонерами та користувачами. Використовуйте це як контрольний список під час розробки, щоб запобігти впровадженню речей, які не сприяють кінцевому продукту або є способом вирішення однієї проблеми, але викликають три нові.
2. Сформулюйте концепцію високого рівня . Я не говорю про проектування інтерфейсів або класів, а натомість грубо окреслив проблемну область. Які основні елементи, механізм та взаємодія в кінцевому рішенні? У вашому випадку це повинно зробити це очевидним, коли використання методу jquery-вирішення допомагає як проміжний крок і коли це викликає лише додаткову роботу.
3. Підтвердьте свою концепцію за допомогою зібраного вами списку. Чи є в ньому явні проблеми? Чи має сенс? Чи існують більш ефективні способи досягнення тієї самої вартості користувача, не викликаючи довгого технічного боргу?

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

Будьте в курсі невдалої помилки : якщо ви почнете з одного типу архітектури чи бази даних, більшість людей вагаються, щоб змінити її середнього проекту. Тож корисно вкласти якийсь час у створення «найкращого здогадки про освіту», перш ніж розпочати впровадження матеріалів. Devs мають тенденцію швидко писати код. Але часто, маючи пару макетів, живих прототипів, скріншотів, каркасних передач тощо, можна зробити навіть більш швидку ітерацію, ніж написання коду. Просто пам’ятайте, що кожен рядок написаного коду або навіть одиничні тести ускладнюють знову змінити загальну концепцію.

Вимірювання успіху

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

Ваш приклад "завантаження" досить непоганий. У мене були такі речі в минулому, коли всі (включаючи продажі, PO, користувачів) погоджувались, що це дратує. Але це не впливало на успіх продукту і не викликало довгострокової заборгованості. Тож ми її відкинули, бо з dev-ресурсами були ще цінні речі.

Моя порада тут:

1. Зберігайте все, навіть невеликі помилки, як квитки у вашій системі квитків . Приймайте активне рішення, що знаходиться в межах проекту, а що ні. Створіть основні віхи або відфільтруйте їхні відставання, щоб у вас завжди був "повний" список всього, що ще потрібно зробити.
2. Майте суворий порядок важливості та чітку межу, де проект можна вважати успішним. Який рівень стабільності / якості коду / документації насправді потрібен кінцевий продукт? Постарайтеся провести кожен день роботи якнайкраще, вибираючи зверху. Працюючи над одним квитком, спробуйте вирішити його повністю, не вводячи нові квитки (якщо тільки немає сенсу відкладати речі через нижчий пріоритет). Кожне зобов'язання повинно приводити вас вперед до своєї кінцевої мети, а не збоку чи назад. Але підкреслимо це ще раз: іноді хак, який надасть додаткову роботу пізніше, все ще може бути чистим позитивом для проекту!
3. Використовуйте свій PO / користувачів, щоб визначити цінність користувача, але також попросіть своїх розробників визначити вартість техніки . Зазвичай нерозробники не можуть судити про те, яка справжня довгострокова вартість (не лише вартість впровадження!), Тому допоможіть їм. Будьте в курсі проблеми з киплячою жабою: багато маленьких, нерелевантних проблем можуть з часом привести команду до місця. Спробуйте кількісно оцінити, наскільки ефективно може працювати ваша команда.
4. Слідкуйте за загальною метою / витратами. Замість того, щоб думати від спринту до спринту, скоріше дотримуйтесь думки про те, "чи можемо ми як команда зробити все необхідне до кінця проекту" . Спринти - це лише спосіб розбити речі та встановити контрольно-пропускні пункти.
5. Замість того, щоб хотіти щось показати рано, побудуйте свій курс на найшвидшому шляху до мінімально можливого продукту, який можна надати користувачеві. Тим не менш, ваша загальна стратегія повинна передбачати перевірені результати між ними.

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

Хитрість тут полягає в тому, щоб сперечатися із загальною вартістю проекту: якщо, наприклад, PO вимагає приймати ярлики, щоб скласти крайній термін, кількісно визначте обсяг роботи, який необхідно виконати після того, щоб вважати виконаний проект!

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

Підсумок

Щоб зварити його: Швидкий та мінімальний шлях - це хороший підхід. T він проблема полягає в інтерпретації «швидкої» і «мінімальний». Завжди слід враховувати довгострокову вартість (якщо тільки у вас немає проекту, де це не має значення). Використання ярлика, який займає лише 1 день, але створює технічну заборгованість у 1 місяць після дати доставки, коштує вашій компанії більше, ніж рішення, яке зайняло 1 тиждень. Негайно почати писати тести здається швидко, але не, якщо у вас концепція недосконала, і вони зафіксували неправильний підхід.

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

Сподіваюся, що це допомагає!

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

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

Якщо вони кажуть, що це останнє, то те, що ви робите неправильно, це те, що ви не даєте їм того, що вони хочуть.

Одним з наріжних каменів Scrum є прозорість. Якщо ви робите scrum, вам слід робити спринт-огляди з замовником. У цих оглядах ви говорите клієнту, що ви вирізаєте кути, щоб швидше доставити програмне забезпечення? Якщо ні, то ви повинні бути. Вам потрібно бути на 100% чітким для клієнта щодо наслідків вашого дизайнерського вибору, щоб дати їм шанс прийняти обгрунтоване рішення щодо того, чи постачаєте ви програмне забезпечення відповідного рівня якості.

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

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

У результаті, ви (як розробник) можете зробити власне планування. Ніхто не каже вам доставити якусь функцію за х днів. Якщо хтось каже, що ви доставляєте за х днів, ви не робите Scrum.

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

Давайте вивчимо, що ви робите, відклавши на хвилину Agile.

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

Це називається "Взяття технічного боргу". Мартін Фаулер описав "Квадрант технічної заборгованості" у своєму блозі по двох осях: "Нерозважливий проти розсудливий" та "Умисний проти ненавмисного".

Ви чітко вирішите використовувати відому стару технологію jquery, яка віддаляє вас від однієї з експрес-цілей (а саме програми на одній сторінці). Ви робите це для швидкої доставки. Це навмисне.

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

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

Те, що ви робите, неправильно на самому базовому рівні. Це погана інженерія !

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

Що вам слід зробити, це зменшити рівень боргу . Поговоріть зі своїм начальником, поговоріть зі своїм клієнтом. Вам потрібно вчора працювати над ремонтом.

Просто перестаньте використовувати Agile ...

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

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

Причини цього можуть бути відсутні:

• Архітектор не має досвіду (як і ваші перші десять проектів хобі)
• У архітектора немає часу
• Архітектор не має влади (менеджер каже ні, чи так, але лише для деяких частин)
• Команда вірить у певну методологію вуду, яка врятує їх (Це все випрасується, тому що ми використовуємо Agile)

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

1. Стан коду перешкоджає можливості команди вчасно доставляти та помилки.
2. Чим більше можливостей ми додамо, тим гірше вони стануть.
3. Тому дійсно має сенс призупинити, переосмислити та (можливо, кардинально) переробити деталі.

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

Сказавши це, менеджери можуть зробити багато, щоб погіршити справи:

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

Дивлячись на це таким чином, легко зрозуміти, як деякі інтерпретації спритного та негідного насправді насправді ще швидше пройдуть вас по цьому маршруту!

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

Інший підхід полягає в плануванні спринтів, щоб використовувати лише 25-50% від вашої спроможності команди. Потім Devs записує свій час на реальні квитки (записуйте час, який він повинен був пройти без рефакторингу) та час рефакторингу (один великий квиток на тиждень, без циклів затвердження, лише обговорення між розробниками). Якщо рефакторингу немає, ви можете витягнути квитки з спринту наступного тижня. Ви коригуєте відсотковий повзунок на найближчі тижні, оскільки базовий код проекту поліпшується.

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

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

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

наприклад, ви можете мати нефункціональну вимогу:

"Усі нові функції повинні бути записані в React"

і

"Усі асинхронні виклики повинні реалізовувати завантажувальний спінер і обробляти помилки"

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