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

Найбільшим недоліком спритного розвитку, який я зазнав, є те, що люди, які не беруть участь у розробці, зосереджуються на мантрі, що історія користувача (3–10 ідеальних днів для людини) не повинна містити більше 1–3 речень на кшталт:

Як замовник, я можу використовувати пошук у текстовому форматі, щоб знайти продукти, які шукаю.

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

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

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

• Нам потрібні булі оператори, такі як AND і OR.
• Нам потрібен нечіткий пошук усіх термінів.
• Нам потрібно шукати як окремі слова, так і фразу.
• Ми не хочемо знайти продукти, які відповідають критеріям X, Y та Z.
• Ми хочемо сортувати результат. Ну, і, до речі, користувач може вибрати критерії сортування у комбінованому полі з параметрами a, b і c.

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

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

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

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

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

У вас є якась довідка?

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

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

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

Першим питанням здається, що ви не повинні застосовувати оцінки часу до історій користувачів. Ви повинні взяти історію та застосувати "точки історії", які є загальною оцінкою складності від 1 до БЕЗПЕЧНОСТІ. Історії часто виконують щось на зразок 1,2,3,5,8,13,20 ... (Кожна організація має свої правила.) Вони, як правило, застосовують щось на зразок:

1 - Ви можете це робити уві сні, і навряд чи це варто реалізувати. 2 - Ви це розумієте і можете швидко здійснити це з невеликим ризиком перевищення. 3 - Ви це розумієте, але може статися сюрприз чи два. 5 - Це буде невеликим дослідженням і має невелику кількість ризику. 8 - Це велике завдання, потребує багато досліджень і може не вміститися у спринті. 13 - Це величезно, і точно не впишеться у спринт. Є великий ризик. тощо.

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

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

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

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

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

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

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

З мого досвіду, багато змін чи проектів, над якими я працюю, вирішують саме цю справу. Користувальницький X хоче чогось, і вони мають уявлення про те, чого хочуть, але вони дають вам лише невелику електронну пошту, яка відповідає вимогам. Це здебільшого тому, що клієнт не «точно» знає, чого хоче. Ось чому більшість завдань нашого відділу обслуговування клієнтів - це деталізація цих потреб клієнтів та фільтрація необхідної інформації, а також передбачення того, чого КЛІЄНТ дійсно хоче або що їм дійсно потрібно.

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

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

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

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

Замовник

Я хочу шукати товари

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

• Пошук продуктів
• Сортувати результат
• Фільтруйте результати пошуку

Розробник Я отримував історії користувачів від менеджера продуктів. Я проаналізував кожну історію користувача та склав список завдань для кожної історії користувача.

• Пошук продуктів
  1. Завдання 1: Зміни бази даних
  2. Завдання 2: Зміни на стороні сервера
  3. Завдання 3: Зміни переднього кінця

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

Наші історії користувачів аналізуються та уточнюються в наступному порядку (з деякими варіаціями курсу):

Довідкова служба -> Власник продукту -> Менеджер продуктів -> Ведучі відділу (старші розробники, потенційні клієнти тощо) -> Розробники

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

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