Як ви ставитеся до витрат занадто швидких змін?


11

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

Нещодавно я успадкував невелику базу коду, яка була баггі, неповною і навіть не могла впоратися з найпростішим сценарієм. Я можу вирішити технічні проблеми, але я отримую декілька електронних листів, текстів або телефонних дзвінків на день, в яких говориться: "OMG, ВИ ПОВИНЕН працювати над цим ПРАВИМО !!! Що ще гірше - це те, що більшість речей - це незначні деталі, які навіть не стосуються того, що програмне забезпечення насправді повинно робити, і на це в будь-якому разі знадобиться кілька днів. Я намагався пояснити, що часу існує лише стільки і що ми повинні сфокусуватися на найважливіших речах, але, здається, щось перекладається в перекладі, оскільки те саме відбувається через день чи два.

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


Чи дотримується ваша команда якась спритна методологія?
Аарон Куртжальс

Я б сказав, що ми спритні, але не дотримуйтесь певної спритної методології, окрім тих, що інструменти (PivotalTracker, Jenkins тощо) накладають чи підтримують.
Trystan Spangler

Ви говорите спритний, я б сказав спритний, але;)
Марцін Санецький

Відповіді:


12

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


5
+1 за те, що є однією і єдиною правильною відповіддю. Як ви це скажете - "Після того, як ітерація почалася, ви не можете її змінити". Яку частину "CANNOT" ви не розумієте?
mattnz

+1 до відповіді та до коментаря mattnz ("Яку частину" CANNOT "ти не розумієш?"): У мене була подібна проблема: тритижнева ітерація, і протягом третього тижня колега починає бути надзвичайно креативним і змінюватись / переміщати речі. Agile означає велику гнучкість, але для цього є деякі нижчі межі: після того, як ви закріпили кілька мінімальних одиниць роботи, слід зосередитися на них, не відволікаючись на них.
Джорджіо

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

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

9

Ось як я вирішив подібну проблему .. Ще в часи, коли ми були спритними перед Agile.

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

Це зашкодить, коли ви скажете клієнту, що ви не можете працювати над його завданням, оскільки ви працюєте над неважливою задачею X, яка має той самий пріоритет, що і його останній запит. Потім ви кажете йому, що на цьому рівні пріоритетів стоїть 50 тривіальних і неважливих завдань перед його останнім запитом. Тепер справжній улов - усі ці завдання знаходяться на рівні першочергового рівня (Найвищий), встановленому ... HIM ... Тож він не може відкинути вас від завдання, яке ви виконуєте. Тепер, коли ви закінчите переміщення віконної рамки на 3 пікселі вліво, щоб звільнити довше слово в ісландському перекладі на рідко використовуваний варіант конфігурації .....

Я також зачинив двері в офіс SD, зачинив їх і зняв телефони з гачка. Електронні листи ігнорувались до 10:00, 12:00 та 2:00. Незважаючи на те, що люди думали і відчували, світ все ще ходив навколо сонця, ми закінчили свою роботу, а "Клієнти" отримали програмне забезпечення швидше і краще, ніж будь-коли в минулому.

Минуло кілька тижнів, щоб пріоритети вирішили щось більш реалістичне, ми змогли відчинити двері і т. Д. .... Але система зберігалася досить довго. Можливо, вам не потрібно бути настільки екстремальними (ми це зробили), і вам буде потрібна підтримка вищого керівництва. Але це спрацює….


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

Мені подобається ідея, коли клієнт встановлює пріоритет, важкою частиною є встановлення закону і сказати: «Я почав із завдання X, ні, зараз ви не можете змінити пріоритет»
sevenseacat

2

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

Деякі приклади того, що має визначати ваш SOP

  • Які процедури слід дотримуватися, коли клієнт або внутрішня організація вимагає змін
  • Які наслідки та / або вплив на контроль якості або перевірку цього товару?
  • Який спосіб обґрунтовано визначити термін доставки? Це ітерація? Наступна версія?

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

Кінцевий результат вас незадоволює, і це не в інтересах ваших компаній.

Зі сторони, можливо, ви успадкували хтось безлад, викликаний такою кричущою неповагою до його / її посади та обов'язку. Людям, які перебувають у цій ситуації, важко виготовити якісний продукт. Чи це диво? Інженерія програмного забезпечення 101.


2

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

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

Коли у вас є розмова віч-на-віч або телефонна розмова, корисно повторити те, що людина просить вашими власними словами, а потім задайте свої питання щодо нових вимог та пріоритету. "Якщо я правильно розумію, ви говорите, що ми повинні припинити роботу над поточним пріоритетом X і тепер зосередитись на пріоритеті хвилини Y. Це велика зміна. Чи можете ви пояснити зміни в бізнесі? працювати, ніж просто змінювати інтерфейс користувача. Чи відбудуться зміни в інших бізнес-процесах, наприклад, виставлення рахунків чи товарних запасів (наприклад)? Чи очікуєте, що ці нові елементи даних з’являться у всіх місячних звітах? " Корисно також сказати щось про ефект "Ви розумієте, що якщо ми продовжимо ці нові зусилля, це затримає випуск поточного першочергового X принаймні на (тиждень, місяць,

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

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

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


0

Схоже, ніхто про це ще не згадував, спринт та його користувацькі історії ideally should be locked till the next sprint(типовий спринт займає 2-4 тижні). Під блокуванням - я маю на увазі, що жодних додаткових завдань не слід додавати у вже запущений спринт.

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

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


0

Scrum виконує роль Scrum Master, яка була б людиною, яка повинна вирішити вказані вами проблеми.

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

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

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


0

Agile Manifesto говорить, що одним з найбільш фундаментальних принципів є:

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

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

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.