Кога една задача се счита за изпълнена? Когато задачата отговаря на изискванията. Изискванията обаче могат да бъдат умишлено неясни или написани на високо ниво. Макар изискванията да ни казват какво трябва да прави цялостният продукт, те не определят всички стандарти, на които той трябва да отговаря.
Това е задачата на друг артефакт за гъвкаво управление на проекти, наречен критерии за приемане. В тази публикация в блога разглеждаме какво представляват критериите за приемане, защо са ви необходими и как да ги формулирате за вашия проект.
Какво представляват критериите за приемане?
Произхождащи от софтуерното инженерство, критериите за приемане са набор от условия, които трябва да изпълни нова функция/добавка, за да бъде считана за завършена.
В буквален смисъл това са критериите, въз основа на които дадена функция би била приета от собственика на продукта или клиента.
Характеристики на ефективните критерии за приемане
Критериите за приемане са последната проверка за това дали продуктът/функцията е готов за потребителя. Те са печатът за одобрение, че продуктът/функцията е достатъчно добър/а за производство.
За да бъдат ефективни, критериите за приемане трябва да бъдат:
Фокусирани върху потребителя: Екипите създават критерии за приемане от гледна точка на потребителя, за да гарантират съгласуваност с бизнес целите.
Ориентирани към резултата: За разлика от потребителската история, критериите за приемане определят желания резултат. Следователно, те също трябва да бъдат измерими.
Конкретни: Всеки критерий трябва да бъде конкретен и приложим към един аспект на функцията.
Например, „трябва да отговаря на десетте най-често срещани уязвимости на OWASP“ може да бъде ефективен критерий, тъй като се отнася конкретно до сигурността.
Краткост: Те трябва да бъдат кратки изречения. Трябва да използват език и терминология, които разработвателският екип използва и с които се чувства комфортно.
Независимост: Добре е да се уверите, че един критерий за приемане не зависи от друг, създавайки мрежа от сложности.
Проверяемост: Това е най-важният аспект. Добрите критерии за приемане трябва да бъдат проверяеми. Обикновено това става под формата на резултати „да“ или „не“.
Защо критериите за приемане са важни?
Всеки софтуерен екип знае как да събира изисквания по гъвкав начин, за да определи точно какво се нуждае собственикът на продукта/клиентът. Защо тогава ни е нужен още един артефакт, ще попитате вие? Ето защо.
Често срещан контекст
Критериите за приемане създават общо разбиране между собствениците на продукти, разработчиците и анализаторите на качеството за всяка функция. Те избягват объркване, субективно тълкуване и потенциални недоразумения.
Съгласуване на продукта
Критериите за приемане служат като скала, която измерва съответствието на продукта/функцията с изискванията, целите и задачите. Те свързват кода обратно с бизнеса.
Ефективност на тестването
Когато имате ясно дефинирани критерии за приемане, вашите екипи по качеството могат да автоматизират и ускорят процеса на гъвкаво тестване. Те също така създават повторяемост между спринтовете.
Ефективност в управлението на проекти
Добрите критерии за приемане позволяват по-добро наблюдение, проследяване и контрол на проекта. Те дават ясна представа защо дадена функция е върната за преработка, което помага на проектните мениджъри да оптимизират процесите.
Положително приключване
В основата си критериите за приемане очертават дефиницията за „завършено“ в гъвкавите проекти. Така че, когато всички критерии за приемане са изпълнени, можете с увереност да пуснете продукта на пазара, знаейки, че сте направили всичко необходимо.
Ако това ви е убедило да включите критерии за приемане в проектите си, ето как да започнете.
Как да напишете критерии за приемане
Колкото и да е изкусително, изготвянето на критерии за приемане не е работа за един човек. За да бъдат ефективни, критериите за приемане трябва да включват мненията на различни заинтересовани страни. Обикновено собственикът на продукта изготвя критериите за приемане с техническата помощ на екипа за разработка.
По-долу е представен стратегически и всеобхватен подход за съвместно изготвяне на критерии за приемане с помощта на универсален инструмент за управление на продукти като ClickUp.
1. Разберете целта на критериите за приемане
Първата стъпка е да разберете защо пишете критерии за приемане. Дали е само за QA да провеждат тестове? Дали е очертано от клиента? Дали това са изисквания за съответствие? Дали това е доказателство за концепция? Разберете целта на критериите за приемане, за да се уверите, че са ефективни за тази аудитория и нужда.
Докато действителните критерии за приемане ще бъдат ясни и подлежащи на тестване, документът с целта ще разгледа подробно причините за това. Например, да приемем, че един от критериите за приемане е „активиране на схема за контраст при слабо зрение“.
В документа с целта може да се посочи: „Функциите за хора с намалено зрение са от основно значение за нашето приложение, тъй като обслужваме клиенти на възраст над 50 години. Продукт, който е лесен за използване от тази аудитория, ще намали значително тежестта на домашните посещения за нашия екип на място.“
ClickUp Docs е чудесно място, където да съберете цялата информация и да определите целта си. Използвайте го като наръчник, за да синхронизирате всички заинтересовани страни (в буквален смисъл!) относно необходимостта и важността на критериите за приемане.
Сътрудничейте в реално време, като правите редакции, оставяте коментари и маркирате хора за обратна връзка. Когато приключите, можете да създавате задачи директно от ClickUp Docs.
Бонус: Въведение в епичните истории и функциите, което ще ви помогне да напишете вашите потребителски истории.
2. Започнете с истории на потребители
Сега, когато контекстът е готов, е време да започнете да пишете. Започнете с историята на потребителя. Прегледайте пътя на потребителя, който всяка функция трябва да улеснява, и напишете съответните критерии за приемане.
Докато използвате ClickUp Tasks за вашите потребителски истории, можете да създадете персонализирани полета за конкретни детайли като ролята на потребителя, целта, желания резултат, зависимости и т.н. С цялата тази информация на едно място, помислете как трябва да изглежда „завършено“.
Ако сте напълно начинаещ в тази област, ето един подходящ за начинаещи шаблон, с който да започнете. Използвайте шаблона за потребителски истории на ClickUp, за да управлявате истории, да ги разделите на задачи, да приоритизирате функции, да ги разработвате и да доставяте продукти от световна класа.
3. Напишете критериите за приемане
Въз основа на историята на потребителя напишете критериите за приемане. Най-лесният начин да направите това е под формата на списък за проверка. Например, когато създавате формуляр с едно поле за абонамент за бюлетин, списъкът ви с критерии за приемане може да изглежда така:
- Потребителят трябва да може да въведе своя имейл адрес.
- Системата трябва да изпрати потвърждаващо имейл до предоставения и потвърден имейл адрес.
ClickUp Task Checklists може да се справи с всичко това в рамките на задачата, която сте създали за потребителската история. Под всяка задача добавете списъци с критерии за приемане, приложими за нея.
Имате ли общи критерии за сигурност или производителност, приложими за всички задачи? Няма проблем! Създайте шаблон за контролен списък и го приложете автоматично към всички съответни задачи.
4. Използвайте формата „Дадено-Когато-Тогава“
Друг начин за дефиниране на критерии за приемане е чрез използване на формата „Дадено-Когато-Тогава“ (GWT). Просто казано, ето как изглежда тя.
- Дадено: Начално състояние или контекст на софтуера
- Кога: Действие или събитие, което потребителят предприема
- След това: Очакван резултат
По същество това означава, че при даден приемлив критерий (
Когато създавате същата функция за абонамент за бюлетин,
- Дадено: Потребителят се опитва да се абонира за бюлетина.
- Кога: Потребителят въвежда валиден официален имейл адрес
- След това: Изпраща се автоматичен имейл, потвърждаващ абонамента им.
5. Сътрудничество със заинтересованите страни
Добрите критерии за приемане не се пишат в изолация. Обикновено продуктовите мениджъри внасят перспективата на потребителя и бизнес нуждите. Дизайнерският екип се фокусира върху потребителското преживяване, използваемостта, достъпността и т.н. Развойният екип допринася за техническите спецификации. DevOps се грижи за производителността и използването на ресурсите.
За да сте сигурни, че вашият продукт отговаря на всички тези изисквания, трябва да напишете критериите за приемане съвместно. С ClickUp това може да бъде изненадващо лесно.
За всяка задача от потребителската история добавете критериите за приемане под формата на списък за проверка, персонализирано поле, описание или коментар. Използвайте вложените коментари на ClickUp, за да обсъдите всеки критерий за приемане, и @mention за комуникация със заинтересованите страни. Възлагайте задачи за действие и др.
6. Бъдете кратки и ясни
Опитайте се да не използвате съюзи в критериите за приемане. Без „и“ или „или“. Бъдете кратки, за предпочитане с едно просто изречение. Използвайте думите „трябва“ и „задължително“ вместо „може“, „може би“ или „възможно е“.
7. Гарантирайте тестваемост
За да сте сигурни, че критериите за приемане са изпълнени, трябва да ги тествате. Начинът, по който формулирате критериите, играе решаваща роля в това. Уверете се, че критериите за приемане са подходящи за изготвяне на тестови случаи. Нека разширим предишния пример.
Ако критерият за приемане е „потребителят трябва да може да въведе своя имейл адрес“, тогава тестът ще бъде:
Стъпки:
- Въведете имейл адрес
- Натиснете Enter
Резултат:
- Ако отговорът е „не“, покажете съобщението „Моля, въведете официалния си имейл адрес“.
- Потвърдете имейл адреса като официален
- Ако да, покажете съобщение: „Благодарим Ви за абонамента. Изпратихме Ви потвърждаващо имейл“.
8. Прегледайте и ревизирайте
През целия процес на разработка следете и оптимизирайте критериите си за приемане. С ClickUp можете също да създадете отчети за всеки от тях, за да видите какво изисква вашето внимание.
Използвайте таблата на ClickUp, за да създадете персонализирани джаджи за критериите за приемане, които са важни за вас. Вижте кои функции изостават и разработете стратегии за преодоляване на основната причина.
С това научихте какво да правите. Сега нека обърнем внимание на това, което не трябва да правите.
Често срещани грешки, които трябва да избягвате при изготвянето на критерии за приемане
При техническите, функционалните и оперативните параметри можете да допуснете множество грешки при изготвянето на критерии за приемане. Ето някои от често срещаните грешки, които екипите обикновено правят.
Да го правите сами
Собствениците на продукти често се чувстват под натиск да напишат критериите за приемане сами. Дори и да е с добри намерения, този подход може да пропусне техническата експертиза на екипа за разработка.
Винаги изготвяйте критериите за приемане съвместно.
Пренебрегване на потребителя
Тъй като критериите за приемане са в края на процеса на разработка, лесно е да се забрави за потребителското преживяване. Това е сериозна грешка.
Винаги създавайте критериите си за приемане с оглед на крайния потребител.
Фокусирайте се върху това как
Критериите за приемане не се отнасят до това как трябва да работи софтуерният инструмент. Те се отнасят до резултатите, които трябва да постига. Написването на критерии за приемане, които определят „как“ да се напише функцията, може да има обратен ефект.
Винаги се фокусирайте върху очакваните резултати и изходи.
Да остане неясен
Неясните или широки критерии за приемане постигат обратния на желания ефект: те оставят място за интерпретация. Това означава, че резултатът може да варира в зависимост от тестиращия, обстоятелствата или дори средата.
Винаги формулирайте критериите за приемане по ясен, конкретен и недвусмислен начин.
Добавяне на прекалено много
Макар да няма скала за това какво е разумно число, е голяма грешка да се пишат прекалено много. Всъщност, наличието на прекалено много критерии за приемане може да означава, че трябва да разделите самата потребителска история на по-малки части. Разгледайте гъвкавите точки на потребителската история, за да потвърдите тази теория.
Винаги изброявайте само абсолютно необходимите критерии за приемане.
Най-добри практики за изготвяне на критерии за приемане
Критериите за приемане са важен инструмент за съвместна комуникация за екипите за разработка на софтуер. В тази секция ще се съсредоточим върху това как можете да ги направите възможно най-ефективни.
Бъдете ясни
Обяснете критериите за приемане на всички заинтересовани страни. Разработчикът трябва да разбере какво означават критериите за приемане. А анализаторът на качеството трябва да знае как да ги превърне в тестов случай.
Използвайте прост език
Напишете критериите за приемане на ясен и разбираем език. Не използвайте технически термини. Особено не се опитвайте да казвате на разработчика как трябва да бъде написан кодът.
Поддържайте резултатите бинарни
Критерият за приемане е изпълнен или не е изпълнен. Няма частично изпълнен или 80% изпълнен. Затова напишете критериите за приемане като изявления за успех или неуспех.
Направете го измерим
Най-лесният начин да постигнете резултати от типа „преминат/непреминат“ е да ги направите измерими. Например, ако вашият критерий за приемане е „скорост на зареждане на страницата по-малко от 3 секунди“, той е лесен за тестване и преминаване.
Правете само разумни предположения
Често собствениците на продукти могат да смятат нещо за „очевидно“, като се има предвид колко близо са до потребителя. За разработчика това може да не е толкова очевидно. Затова, ако можете да го избегнете, не правете никакви предположения. Когато е необходимо, правете разумни предположения в сътрудничество с екипа.
Примери за критерии за приемане
Нека разгледаме някои примери за критерии за приемане в реалния свят, не само в разработката на софтуер, но и в други области.
Пример 1: Разработка на софтуер (използване на метода с контролен списък)
Задача: Функционалност за търсене в уебсайт, базиран на съдържание.
Критерии за приемане:
- Трябва да има текстово поле, в което потребителите да въвеждат своите търсения.
- Резултатите трябва да се показват под формата на списък.
- Резултатите трябва да се отварят в нова страница.
- Резултатите трябва да бъдат разпределени по страници.
Пример 2: Разработка на софтуер (използване на метода GTW)
Задача: Функция за запазване на час
Критерии за приемане:
- Предполагаме, че съществуващ клиент иска да си запази час
- Те въвеждат своя имейл адрес и избират предпочитан час за среща.
- Назначението им трябва да бъде резервирано и потвърдено по електронна поща.
Пример 3: Написване на съдържание (използване на метода с контролен списък)
Задача: Напишете блог пост от 1000 думи за най-новия филм с Том Круз.
Критерии за приемане:
- Използвайте американски английски
- Използвайте Оксфордската запетая
- Въведението трябва да е с дължина по-малко от 200 думи.
- Включете 3-5 вътрешни линка
Пример 4: Маркетинг (използване на GTW) метод
Задача: Стартирайте рекламна кампания, базирана на намерения, в Google Търсене.
Критерии за приемане:
- Даден потребител е в някой от интерфейсите за търсене на Google
- Когато потребителят въведе ключова дума в нашия списък с
- След това покажете
Ролята на критериите за приемане в гъвкавите методологии
Ако agile се състои в разбиването на монолитите на малки, управляеми части и постепенното им изграждане, критериите за приемане го подчертават.
Например, можете да разделите голямата си платформа за електронна търговия на малки части, една от които е функцията „Добави в количката“.
В рамките на добавянето в количката може да има няколко малки функционалности, като например какво става, ако продуктът е изчерпан, или как потребителят може да коригира количеството, което да добави в количката. Добре написаните критерии за приемане помагат да се фокусирате върху тези подробни детайли.
В рамките на гъвкавите методологии критериите за приемане помагат за:
Определяне на резултатите: Критериите за приемане показват на екипа по качеството как изглежда една завършена функция.
Улесняване на дискусиите: Агилната разработка не се отнася само до кода. Тя се отнася до решаването на бизнес проблеми с помощта на технологиите. Критериите за приемане спомагат за улесняването на тези дискусии, за да се постигнат правилните компромиси и свързаните с тях решения.
Създаване на мултифункционални екипи: Продуктовите мениджъри, бизнес анализаторите, дизайнерите, разработчиците, тестерите и оперативните екипи придобиват общо разбиране за продукта въз основа на критериите за приемане.
Постигане на напредък: След като критериите за приемане бъдат изпълнени, задачата преминава към следващия етап от жизнения цикъл на разработката на софтуера.
Доставяйте по-добри продукти по-бързо с ClickUp
Една от ключовите стъпки в създаването на добър софтуер е да се спазват посочените критерии за приемане. Въпреки това, сред десетките документи, доклади, срещи, планиране и дискусии, често се случва някои елементи да бъдат пропуснати. Избегнете това с инструмент за управление на продукти като ClickUp.
ClickUp не е просто мениджър на задачи. Това е цялостна платформа, проектирана с оглед на екипите за разработка на продукти. С мощните задачи на ClickUp можете да планирате и график на потребителски истории, да добавяте критерии за приемане, да ги свързвате с тестови случаи и да ги премествате бързо и ефективно по веригата.
Доставяйте по-бързо с ClickUp Brain, за да генерирате идеи, създавате пътни карти, обобщавате дискусии и изготвяте документация. Следете цялостната картина и подробните детайли на едно място с ClickUp Dashboards. Вижте дали ClickUp отговаря на вашите критерии за приемане за отлично решение за управление на продукти.