Як нам поводитися з додатковими косметичними властивостями в спринтах Scrum?

Я читав документи Scrum, і там сказано, що завдання Sprint повинні бути "потенційно доступними для виконання".

Мене бентежить, що це означає. Припустимо, у спринті 1 метою була «форма реєстрації користувача».

Скільки деталей потрібно додати для того, щоб бути готовим до відправки? Наприклад:

1. Я можу показати просту форму з полями без фантазійних стилів і позначити їх як виконані
2. Я просто можу зробити перевірку на стороні клієнта як позначку як зроблено, але сторона сервера - це також варіант або обидва
3. Я також можу додати декілька підказок інструментів jQuery, наведення курсора, капчу, кольори, мітки для форми
4. Тоді існує ціла багато стилів щодо того, як відображати повідомлення про помилки на екрані

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

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

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

Погодьтеся з цим власником продукту та командою Scrum, а не Інтернетом. Це має бути визначено у Вашому Визначенні Готово, і багато в чому залежатиме від того, як працює команда.

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

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

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

Поки команда всі знає відповідь, не має значення, що це за відповідь.

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

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

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

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

Пам’ятайте: мета - не суворо дотримуватися скрути. Мета - доставити високоякісне програмне забезпечення кінцевому користувачеві. Використовуйте це як посібник, коли боретеся з подібними питаннями. Чи додавати косметику в ту ж історію, що й суто функціональні частини, допоможуть вам надати якісний код вашому клієнту? Або допоможе розірвати це на дві історії? Або відповідь ясна, або це не має значення, і ви можете робити все, що працює для вашої команди.

"Потенційно доступний для перевезення вантажів" означає можливість доставки, не обов'язково щось, що ви доставляєте. Наприклад:

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

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

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

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

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

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

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

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

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

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

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

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