Історії користувачів занадто високі та концептуальні, керівництво очікує, що розробники заповнять пробіли

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

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

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

Ви зрозуміли, що ви найкраще бачите.

Тісно пов’язаний і якимось чином дає відповідь: Скільки деталей про історію користувача може розраховувати розробник?

Хитрість - не уникати заготовок. Хитрість полягає в тому, щоб заповнити ці заготовки якомога раніше в процесі розробки.

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

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

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

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

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

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

Це здається мені не дуже "XP".

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

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

Підводячи підсумок, ви знаходитесь у такій ситуації:

1. Ви новачок.
2. Проект (я припускаю, що ви говорите про запущений проект) має надзвичайні часові обмеження.
3. Очікується, що розробник заповнить бланки на власний розсуд.
4. Компанія, в якій ви працюєте, має намір практикувати XP. Однак, схоже, користувацькі історії не застосовуються таким чином, що вписується в методологію XP. З іншого боку, " Очікується, що розробник заповнить бланки на власний розсуд ".

Подумайте над пунктом 4: Я вважаю, що спритні практики повинні бути адаптовані до потреб та культури компанії / команди (а не навпаки). Визначте, де компанія дотримується методології XP та де вона відхиляється. Це основа для конструктивного підходу до ваших проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

Хтось повинен задавати питання, якщо історія занадто розпливчаста. Де відбувається тестування приймання ?

Історії користувачів призначені для зміни. З цим потрібно розібратися.

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

Працювали над новими та існуючими продуктами, і в обох були випадки, коли вимоги, де лише 5- рядок, і ми повинні були заповнити пробіли та зробити «розуміючий» або більш детальний документ.

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

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

XYZ мені незрозумілий. Чи означає це ABC? Або я щось пропускаю? (Припустимо, XYZ - це вимога. Припустимо, ABC - це припущення, яке я хотів би зробити як розробник)

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

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

Як розробник,

Мені потрібно повністю зрозуміти специфіку історії користувача,

так що я можу впевнено оцінити та здійснити це.

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