Scrum: Чи нормально, що дизайн / UX історії користувача відбуватиметься в тому ж спринті, що і реалізація

Зараз я перебуваю у спринті (два тижні), де дизайнеру належить визначити вимоги та UX конкретної історії користувача.

У цьому ж спринті я повинен реалізувати цю конструкцію. Під час планування спринту мені довелося подумати, як довго триватиме ця невизначена історія користувача.

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

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

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

Отже, моє запитання

як ви справляєтесь із залежностями в плануванні спринту?

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

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

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

Однак ви цього не робили, і тепер ваше питання ...

як мені зараз підходити до спринту?

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

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

По-перше, велика різниця між залежностями між історіями / завданнями та невизначеністю в обсязі / зусиллях розповіді / завдання.

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

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

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

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

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

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

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

Чи задачі щодо дизайну виражені як розповіді та які визначення вашої команди

• історія готова
• історія робиться

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

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

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

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

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

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

Ще кілька тренувань не можуть нашкодити ... Можливо, робота з дизайнером стане для вас можливістю придбати нові навички UX? ... це спостерігає за склянкою наполовину, а не напівпорожньою :))