Програми з вихідними днями, відкладеними історіями користувачів

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

Моя відповідь була така

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

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

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

Як я можу вирішити питання, перш ніж воно забруднить команду?

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

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

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

• Не повинно бути людей, які займаються лише бек-ендом. Поширений Agile підхід - це створення функціональних команд, що складаються з узагальнюючих фахівців, які практикують спільне володіння кодом. Люди не повинні бути зосереджені виключно на задньому або передньому розвитку, хоча вони, звичайно, краще досвідченіші або кращі в деяких речах, ніж інші.
• Архітектура не заробляє цінності. З точки зору користувача - єдина перспектива, яка насправді має значення - не має значення, чи є у вас шари чи мови домену або навіть якщо рішення запрограмовано. Важливо лише те, чи створили ви цінність для користувачів. Запропонована «історія» від бек-енд-розробника - це нісенітниця - це зведення проектних рішень, які з точки зору користувача / замовника нічого не роблять для досягнення потрібної функціональності. Іншими словами, будь-яка історія користувача може бути досягнута будь-якою кількістю різних дизайнів архітектури. Цілком можливо, що історія користувача може бути завершена без будь-яких модифікацій. Це не робить його недійсною історією.
• Мислення системно все ще є критичним. Хоча архітектура може не отримувати цінності, вона все ще має важливе значення для успіху. У бек-енд-розробника є певні поваги. Ви повинні думати про те, як ви будете будувати систему. Ви повинні записувати ці рішення. Уся система важлива, навіть якщо лише особливості передньої частини - це речі, які отримають усю славу.

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

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

Це здається соціальною проблемою, тому воно потребує соціального рішення.

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

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

Найкраще рішення - це, напевно, поговорити з відповідними розробниками (окремо або як група) та вирішити основну проблему, яка, як видається, викликає повагу. У якийсь момент це, ймовірно, доведеться перейти до управління.

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

Дійсно, це проблема. Очевидно, що ви не вирішите це історіями!

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

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

Іншими словами: примусьте всіх виробляти цінність для своїх кінцевих користувачів.

^{(*) Примітка: не всі сюжети повинні мати передній або зворотний компонент. Елементи користувальницького інтерфейсу можна переробити без додаткових зворотних робіт, а продуктивність - особливість .}

Ваші проблеми:

• У вас є шари управління у вашому бізнесі, де вони не служать ніякій меті. Сквер, спритний, мені все одно. Управління та розвиток повинні бути виокремлені з бізнес-проблем, якими займається менеджер із продуктів, який має @ @ $ $ ing поняття про технології. Можливо, це спрацювало для Стіва Джобса, але я ніколи не був у ситуації, коли недоброзичливі менеджери, близькі до розробника, були здоровою справою або в кінцевому підсумку служили для виробництва найкращого продукту, який команда могла б зробити.

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

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

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

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