Відставання завдань «розміру куса» паралельно відставанню від «основної» функції?

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

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

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

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

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

Це викликало реакцію серед нас із навчанням ScrumMaster "uh-uh". Є одне відставання. Два відставання задають питання про те, який предмет №1 справді є найважливішим, які елементи списку визначають реальну швидкість, і до якого з двох відставань, до якого насправді належить історія (будь-яке розмежування за розміром / складністю матиме деякі випадки, які відносно відносяться довільно в одну чи іншу сторону). "Нехай процес працює", - сказали ми; якщо зміна дійсно є важливою для кінцевих користувачів, вони дадуть достатньо шуму, щоб змусити керівників відділів приймати рішення про час / гроші на борту, і вони натрапляють на свідомість команди розробників до вершини відставання.

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

Я розповім про кілька моментів, які, сподіваємось, допоможуть вам знайти свій шлях:

1. " SCRUM " - це спритність. Потрібен здоровий глузд. Якщо зміна - це кілька хвилин зміни, я не думаю, що вам не потрібні відставання. Якщо це більше 2 годин, я думаю, ви повинні задуматися над цим. Не слід робити все, що є «легко виграшним». У SCRUM ви працюєте за пріоритетами. Я вважаю, що ПІ повинен отримати інформацію про те, що ви отримуєте від додавання та зусиль, які він вимагає. Тільки тоді PO може вирішити, важливо це чи ні. Переходячи до SCRUM, іноді виникає багато питань, і розробники часто скажуть «але це займе лише кілька годин». І що? Кілька годин - це час, не все, що є коротким, потрібно включати.
2. Я колись працював над проектом, де у нас був "відставання в інженерії" . Цей збір містив елементи, запропоновані розробниками для вдосконалення продукту. Ці елементи не мали явного значення користувача (але мали неявне значення для користувача). Наприклад: рефакторинг компонента в коді. Ми описали зміни, зусилля та виграш (у цьому випадку ви нічого не можете представити користувачеві. Але якщо такий рефакторинг спричиняє швидше розвивати нові можливості, то для користувача це, безумовно, виграш). Наш PO вирішив, що під час версії ми повинні інвестувати 10% кожного спринту (в середньому) на такі позиції. Перед кожним спринтом, коли PO вирішував питання про відставання спринту, він переконався, що у нас є 10% відбітків від інжинірингу. Отже, відставання 2 версії -> 1 відставання спринту.
3. Буфери - Коли починають працювати в SCRUM, люди часто забувають, що ми, як програмні інженери, ми залишаємось у світі невизначеності. Це нормально, щоб рахувати 1 день роботи 6 годин замість 8. Скажімо, у вас 15-денний спринт, це означає, що у вас є додаткові 30 годин, які ви ходите на зустрічі, на речі, які зайняли занадто багато часу, і так - також для тих маленьких речі, які є надто незначними, щоб пам’ятати, але є частиною нашого дводенного завдання.
4. Будьте зосередженими - Не останнє, але в SCRUM важливо залишатися зосередженим. Вирішіть, скільки ваших загальних зусиль, і який пріоритет, інвестувати в такі завдання і не забудьте вкласти цей час та зусилля. Не дрейфуйте, щоб працювати над «дрібничками» лише тому, що їх мало. У вас є PO, який допоможе вам прийняти рішення, і ви маєте здоровий глузд.
5. Будьте спритними - І, врешті-решт, не забудьте спробувати різні методи, щоб підійти до проблеми, запитайте себе, чи справді це найкращий спосіб. Поліпшити в дорозі.

Удачі :)

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

У моєму останньому проекті ми зауважили, що розробникам потрібно було щодня небагато часу, щоб оновити чи очистити голову і т. Д. Їм було надано бюджетний час (.5 годин на день або 2,5 години / тиждень), протягом якого вони могли робити все, що завгодно, протягом причина (з можливістю застосувати до чогось на роботі). Щоб все не було дисципліновано, від них попросили задокументувати свою діяльність, щоб вони могли отримати кредит за будь-які досягнення тощо. Маючи певний бюджет на "цукерку", вкладався в наші терміни і не дозволяв речам виходити з рук.

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

Ви повинні зберігати невеликі історії в головному відставанні.

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

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

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

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

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

Що часто трапляється зі мною, це те, що зацікавлені сторони вимагають LargeImportantProject та SmallLessImportantTask. Дилема полягає в тому, чи повинен Малий Менш важливий Завдання чекати, коли закінчиться великий важливий проект (чи матимуть блокпост)? Є компроміси, і мій досвід полягав у тому, що власник продукту повинен вирішити. (Якщо власник продукту не приймає рішення, команда розробників повинна здогадатися.)

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

Ефективність може бути жахливою, але я бачив, що користь переважає вартість двома важливими способами.

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

На мою думку; Ваша проблема полягає в тому, що завдання ставлять пріоритетні завдання у відставанні. Наприклад, "пріоритет" може враховувати як важливість, так і те, як швидко він може бути виконаний. Те, що не так важливо, але може бути завершено за 10 хвилин, може мати більш високий пріоритет, ніж щось більш важливе, на що знадобиться кілька тижнів.

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

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

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

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

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

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

- Постійно змінюються вимоги

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

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

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

- Різні підходи до архітектури, рішення, прийняті рамки

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

- Процес збору вимог

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

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

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

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