Чи слід ділитися історією користувача між розробниками? [зачинено]

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

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

Потім настає хаос. Кому «належить» яка історія? Що означає "чи не завершено"? Чи варто скласти дві окремі історії для бек-енд-фронту? Якщо так, чи не порушує це ідея історій користувачів на основі функції? У нашій системі є поняття «підзадачі», що полегшує деякі з цих проблем. Але підзадачі додають додаткову складність. Чи є кращий спосіб? Це "поганий" спосіб використання Scrum?

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

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

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

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

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

EDIT: Я хотів створити резервні копії вищезазначених питань деякими джерелами. Характеристики хорошої історії користувача коротко представлені абревіатурою під назвою " ІНВЕСТ ". Його створив Білл Уейк і популяризував рух Scrum. Особливо зверніть увагу на елементи, що стосуються історій, незалежних та вертикальних.

Ще трохи інформації тут і тут .

Кому «належить» яка історія?

Хто б не схопив цю історію. Вони важливі з організаційної точки зору - одна людина відповідає за роботу. Після того, як ви знайдете двох людей, занадто легко передати долар.

Чи варто скласти дві окремі історії для бек-енд-фронту? Якщо так, чи не порушує це ідея історій користувачів на основі функції?

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

Це "поганий" спосіб використання Scrum?

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

Поки процес працює на вас, він не може бути таким поганим.

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

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

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

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

Але в будь-якому випадку, я рекомендую ніколи не називати історію "виконаною", поки команда не погодиться, що це зроблено, включаючи тестування. Таким чином, кожен має шанс дати свій внесок. І якщо ви поєднуєте це з ідеями щодо колективного володіння кодом та оглядами коду, то вся історія все одно є «власністю» команди. Це може бути призначено для різних людей по дорозі, але якщо хтось поза межами (хворий / відпустка / занадто багато зустрічей? / Інше) роботу все одно можна виконати.

Моя команда часто приймає історії користувачів як частину нашої ранкової зустрічі / SCRUM. Таким чином кожен може легко визнати або оспорити, чи справді це "зроблено". В іншому випадку ми просто дозволяємо нашому інженеру із забезпечення якості - якщо вона впевнена, що вона перевірена і працює, і всі завдання виконані, то ми називаємо це виконаним.

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

Суть епосу - мати більшу мету, яка не обов'язково вписується в єдиний спринт / ітерацію. З часом усі історії закінчуються і епопея закінчується. Епоси розміщені у випуску.

Потім настає хаос. Кому «належить» яка історія? Що означає "чи не завершено"?

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

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