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

"Чи можу я виконувати тестування програми, використовуючи лише автоматизовані тести та без ручного тестування, щоб я міг протестувати додаток максимально ефективно?

Критерії прийняття: 1. Перетворіть 50 існуючих вручну тестів на повністю автоматизовані тести. 2. Тести повинні бути виконані менше ніж за 1 годину "

Я хочу отримати розуміння від спільноти, якщо є сенс використовувати "розповіді користувачів" для роботи, яка підтримує процес розробки програмного забезпечення, не робиться програмістами і не призводить безпосередньо до отримання коду. Або це слід поводити / класифікувати по-різному (наприклад, в JIRA)?

Оновлено 6/7/2011 - перефразоване питання, щоб зосередитись на терміні "історія користувача".

Так

будь-яка зацікавлена ​​сторона, будь-яка функція, яка покращує систему

[нехай починаються пуристські низини!]

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

Це не означає писати історії користувачів для кожної функції.

Якщо ви хочете писати історії користувачів для кожної функції, вам не обов’язково бути Agile. Ви просто пишете історії користувачів для кожної функції.

Історії користувачів! = Agile.

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

Agile - це спосіб управління проектами. Ви можете використовувати Історії користувачів чи ні в проекті Agile.

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

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

Якщо QA не отримає свою історію, скільки реальної втрати бізнесу?

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

Це не має для мене сенсу. «Історія користувача» по суті - це лише те, що історія користувача, а не історія керівника проекту, не історія розробника, не історія інженера із забезпечення якості.

З цього приводу програмне забезпечення:

1. Визначальний
2. Тестируемо

Вдосконалення процесу є відкритими і, як правило, суб'єктивними.

Критерії прийняття: 1. Вдосконалення до тестування 1 (за x / y)

Як ви вимірюєте поліпшення тестування? Для цього немає визначеного контракту.

І на незв’язаній ноті я НАДІЙНИЙ НАДІЙ, що ваш приклад, поданий вище,

Чи можу я виконувати тестування програми, використовуючи лише автоматизовані тести та без ручного тестування, щоб тестувати програму якомога ефективніше?

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

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

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

На мою скромну думку, так, ви можете використовувати розповіді користувачів для проектів розробки програмного забезпечення, а не лише для вдосконалення процесів. Візьмемо для прикладу, 3 роки тому я був найкращим чоловіком на весіллі свого друга, і я використовував методологію Agile та розповіді користувачів для планування весілля. Усі завдання, які нам довелося виконати, були написані як історії користувачів з критеріями особистості, наміру, обґрунтування та успішності для кожної історії користувача. Усі залучені сторони взяли участь у нашій щоденній розбитці, щоб обговорити, що ми робили попереднього дня і що ми будемо робити в цей день. Усі були географічно розігнані, отже, ми проводили конференц-дзвінки для наших щоденних зустрічей з обговореннями, планування спринту, ретроспективів, написання розповідей та сесій оцінки .... як ви це назвали, ми це зробили. У нас було 6 спринтів (3 місяці), і весілля отримало приголомшливий успіх, і жоден камінь не залишився не розвернутим.

У вас є серйозна проблема, коли ви вкладаєте внутрішні "історії користувачів" у поєднання з фактичними історіями користувачів.

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

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

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

Внутрішні «розповіді користувачів» пишуть кури.

Фактичні історії користувачів пишуть свині.

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

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

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

Якщо QA не показує тестування на покращення тестування, ніхто не виходить з бізнесу. Гроші не втрачаються.

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

Не змішуйте внутрішніх ("курячих") та реальних ("свинячих") зацікавлених сторін.

У коментарі "курей та свиней" пропущено суть. Внутрішні зацікавлені сторони - це кури, якщо мова йде про продукт, що розробляється (якщо він не розробляється для них), але вони є свинями, коли мова йде про процес розробки.

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

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