Переваги Scrum для самих розробників? [зачинено]

Якщо Scrum є методологією управління проектами, як би ви «продали» його розробникам у команді, яка задоволена своєю нинішньою ситуацією?

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

Але як можна переконати розробників прийняти Scrum? Як Scrum полегшив би їхнє життя?

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

Однак це також принесе багато видимості прокрастинаторам, недобросовісним розробникам, божевільним індивідуалістам, ... іншими словами, поганим розробникам.

Scrum - меч з двома кінцями

Scrum принесе вам можливість вирішити ці проблеми. Ось чому він такий потужний.

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

Стік рангів / відставання утримує важливі кінці від маршів смерті

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

Скажіть, оскільки він займає «важливі особливості» високо в списку відсталих, допомагає розробникам проактивним чином керувати цим напруженням двома способами. По-перше, ви можете оцінити "улюблену функцію" високо у відставанні, так що він / він, швидше за все, буде щасливим. По-друге, це дає дуже візуальну та конкретну відповідь на те, «оскільки ми перемістили« мерехтливі віджети »до 1-го місця, дуже ймовірно, що ми не збираємось потрапляти до« підстрибуючих зайчиків »у цьому спринті, оскільки зараз це 7-й ранг. вам комфортно з цим компромісом? "

Я також виявив, що при коротких спринтах "зовнішні контролери" менше засмучуються через відкладення роботи. Якщо "мерехтливі віджети" не перетворюють його на "етап 1", а "етап 2" не закінчується до 9 місяців, спонсор "мерехтливих віджетів" сильно засмучується. Але якщо "мерехтливі віджети" є стеком 7, а не 1, оскільки насправді є ще 6 важливих речей, які потрібно зробити першими, це означає, що ми, ймовірно, дістанемося до нього в спринті + 1 або в гіршому спринті + 2, що означає він з'явиться через 12 або 18 тижнів (використовуючи 6-тижневі спринти). На мій досвід, очікування 3 місяця є "прийнятним" для нетерплячих - до того ж, назад у моделі "водоспад" з етапами 3+ місяців,

Нарешті, якщо ми доходимо до кінця спринту і все зайняло більше часу, ніж очікувалося, дуже приємно мати можливість перенести відстаючі предмети 5-6-7 до наступного спринту і переконатися, що ми виконали 1-2-3 -4 з високою якістю та без тижня 70 годин. Зрештою, ми обов’язково потрапимо до 5-6-7 наступного спринту. Знову ж таки, враховуючи більш короткі часові рамки, пов'язані з відстрочкою, "зовнішні контролери", як правило, більш зручні з цим, і не наполягайте на тому, щоб ми просували віху два тижні і замовляли вечері щовечора, "щоб просто пройти через неї".

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

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

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

Пару речей:

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

• Історія балів! Який розробник не любить отримувати бали за заняття !! !!! Якщо серйозно, це краще, ніж отримувати значки в SC2 або Переповнення стека.

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

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

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

Приємно відступати кожні три-чотири тижні і робити подих і хоча б змінити темп.

Самоорганізуючі команди, здається, дають трохи більше різноманітності в роботі.

Принаймні, теоретично, під час спринту менше перебоїв і «надзвичайних ситуацій».

Щоденна зустріч стоячи змушує програмістів говорити кілька слів щодня.

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

Діаграми згоряння є досить ефективним засобом легкої ваги для відстеження прогресу.

Перевагою для розробника є ранні відгуки (від клієнта, тестера, власника продукту тощо).

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

PS: scrum - це не методологія, а рамка.