Чи дозволений у scrum код довільного рефакторингу

Фон

• Моя команда використовує scrum
• Наразі мені не призначено жодного завдання
• Більше відкладених завдань у відставанні немає
• Сьогодні День праці для мого клієнта.

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

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

А як щодо інших днів, коли я маю вільний час між спринтами.

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

Я справді не хочу атакувати інші відповіді, але хіба ніхто більше не пише тут автоматизованих тестів? Ось цікаве читання від Мартіна Фаулера для тих, хто займається Scrum без належних методів інженерних програм. Роберт К. Мартін також багато про це говорить тут .

Отже, на мою відповідь ... Словом, це виглядає так:

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

А тепер для довгої відповіді:

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

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

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

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

Scrum насправді нічого не говорить про рефакторинг.

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

Я б сказав, що ні, це не так. Це незалежно від виду робіт (рефакторинг тощо).

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

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

Я теж не скажу. Повторний факторинг часто призводить до випадкових помилок, якщо ним не керувати належним чином.

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

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

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

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

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

Scrum нічого не говорить про рефакторинг (див. Лекцію Роберта К. Мартіна "Земля, яку Scrum забув").

У завданнях Scrum завдання орієнтовані на функції вашого програмного забезпечення, визначені замовником, а не на технічну заборгованість за погашення за допомогою рефакторингу. Це абсолютно різні рівні абстракції. Замовник здебільшого не в змозі оцінити необхідність.

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

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

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

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

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

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

Тримайте технічні речі подалі від замовника та виконуйте свою роботу як професійний розробник.

Ось один підхід: роби і те, і інше!

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

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

Потім погляньте, щоб включити його через один з двох каналів:

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

Щойно ви отримаєте фактичну покупку, ви зможете застосувати або повторити свій спайк і фактично об'єднати код у гілку основної лінії (головний тощо).

Це матиме ряд переваг:

• Усі ваші коди кодуються одним і тим же процесом, тестуються, QA, у конвеєрі випуску тощо.
• Ви отримуєте офіційну покупку, в тому числі від менеджера продуктів, що рефакторинг - це частина ремесла, а не те, що потрібно «прокрастися» у свято. Запитайте себе, чому ви не «прокрадаєтесь», а фактична функція може допомогти в перспективі.
• Ви можете попросити парування, перегляд коду, qa, devops та іншу підтримку, яка може знадобитися для зміни коду факторингу. Це все буде офіційно, відповідно до політики та процедур та вище ради.
• Якщо ви є публічно проданою компанією з дотриманням SOX, вам, ймовірно, потрібно / потрібно провести такий формальний процес (тобто документувати його, а потім виконувати його).
• Ви отримуєте кращу репутацію як із менеджером продукту (зміна була здійснена швидко), так і командою розробників (поліпшилася база даних)
• Організація прагне піклуватися про якість коду, яка корисна для продуктивності, моралі, утримання працівників та багатьох інших причин.
• Вплив на швидкість проекту можна легше відстежити, якщо включена вся робота. Не можна призначати жодних точок, оскільки саме присутність може використовуватися для впливу на швидкість.
• Розробники, ймовірно, знайдуть інструменти, які заохочують простіші огляди коду, такі як Fisheye, Github тощо.
• Розробники, швидше за все, бачать деякі основні стандарти (іноді задокументовані, іноді немає), які спрощують код спільного використання, а отже, і рефакторинг. Іноді велика частина рефакторингу - це вибір стилю, а потім його широке застосування (заміна суміші підходів на один).

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

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

• виправлення проблеми дизайну чи архітектури
• покращення впровадження

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

З цієї відповіді :

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

У моїй попередній роботі у нас був якийсь scrum, з більшими спринтами (2-3 місяці). Оскільки у нас були певні затримки між спринтами (1 місяць), ми використали цей час для аналізу програмного забезпечення та рефакторингу коду.