Критерии за приемане за писане на критерии за приемане

Критерии за приемане за писане на критерии за приемане

Много от екипите за разработка са твърде запознати с разочарованията от незадоволителните критерии за приемане или дори от липсата на критерии. Определянето на никакви изисквания е като подготовка за битка без план за действие - екипът е предприел повече стъпки към провал, отколкото към успех. Предлагам конкретни предложения за изработване на критерии за приемане, които могат да подобрят всеки гъвкав процес.

Първо, нека дефинираме бързо критериите за приемане.

Критериите за приемане са „условията, на които даден софтуерен продукт трябва да отговаря, за да бъде приет от потребител, клиент или други заинтересовани страни“. (Microsoft Press)

Достатъчно лесно, нали? Не точно. На този етап бих се запитал дали тук спира дефиницията ми за критерии за приемане. В допълнение към определението по-горе, всеки собственик на продукта трябва да има готови отговори за следните въпроси:

Как изглеждат тези условия? Кой създава тези условия? Колко условия трябва да има? Как се измерват резултатите?

Обикновено критериите за приемане се инициират от собственика на продукта или заинтересованата страна. Те са написани преди всяко развитие на функцията. Тяхната роля е да предоставят насоки за бизнес или ориентирана към потребителя перспектива.

Написването на критериите обаче не е отговорност единствено на собственика на продукта. Критериите за приемане трябва да бъдат разработени като съвместни усилия между разработчиците и собственика на продукта.

Създаването на тези критерии заедно помага на екипа за разработка да разбере желанието. Също така помага на собственика на продукта да улови липсващи подробности. Освен това собственикът получава по-добро разбиране за осъществимостта, сложността и обхвата.

Форматиране на критерии за приемане

Критериите могат да бъдат написани в различни формати. Повечето отбори се навеждат към два специфични типа: ориентирани към правила или сценарии .

Изискванията, ориентирани към правилата, са директни. Те изброяват наблюдаеми резултати. „Показване на баланса на извлеченията при успешно удостоверяване.“

От друга страна, ориентираните към сценарии критерии са склонни да следват шаблона „Дадено ... Кога ... Тогава ...“. Това е получено от поведенческо развитие (BDD). Това изискване очертава очаквания наблюдаем резултат. Това се случва, когато дадено действие се изпълни при даден контекст.

3 характеристики на ефективните критерии за приемане

1. Тестируемо с ясно дефинирани резултати за преминаване / неуспех

Имате проверими критерии. Това позволява на тестерите да потвърдят правилно, че са изпълнени всички желани условия. Ако критериите не бяха проверими, тогава нямаше да има начин за проверка. Тези критерии трябва да бъдат изпълнени или не. Разработчикът трябва да знае точката, в която е постигнат критерият. Всяка неяснота може да удължи усилията върху историята.

Например, критерий за приемане гласи „увеличете броя на наличните записи в падащо меню“. Разработчикът няма представа колко нови записи да добави и може да си позволи да приеме номер въз основа на опита си с продукта. По същия начин ръчният тестер може да вземе същата свобода и да приеме различна дефиниция за увеличение. Това води до объркване, което ще се върне обратно към собственика на продукта.

2. Недвусмислени и кратки

Тук критериите за приемане на писане се превръщат в изкуство. Академичните есета подчертават значението на яснотата и лаконичността. По същия начин писането на критерии за приемане налага същото ниво на организация и грижи.

Подобно на писането на литературно произведение, публиката трябва да се има предвид. Тези, които четат критериите за приемане, трябва да разберат написаното. В противен случай тези думи са напълно безполезни. Ако те са дълги и изпълнени с жаргон, тогава основните точки от очертаните условия може да не се натъкнат. Много хора могат да пропуснат съществени подробности в море от думи, когато бъдат притиснати от времето. Дори когато не са притиснати от времето, много хора могат лесно да бляскат дълги размазвания.

Вместо да хвърляме вината върху липсата на внимателно четене на другите, човек може активно да представи критерии за приемане, които са лесни за четене, направо до точката и лишени от излишни подробности.

3. Установете споделено разбиране

Това е може би най-важната характеристика и тази, която най-много се приема за даденост. Ако всички членове на екипа не са на една и съща страница, тогава процесът и производителността стават застрашени. Ако екипът за разработка прегледа критериите за приемане, преди да продължи напред с историята, минимизира объркването. По отношение на критериите трябва да се изяснят и критериите да се актуализират съответно.

Имал съм опит, при който всички членове на екипа са били част от писането на критерии за приемане. Това позволи на всички да разберат всички части на историята. Той също така предостави възможности на членовете на екипа да се обадят с въпроси и идеи. Подобен процес обаче не винаги може да бъде идеален, особено за по-големи екипи.

Въпреки това е важно всеки член да може да прочете критериите за приемане. Оттам нататък всеки член трябва да разбере как да приведе историята в завършеност. Независимо дали е в разработка или тестване.

Когато твърде много е проблем

Вече проучихме опасността от неясни критерии за приемане. Това води до риск от въвеждане на чужди функции в историята. Може обаче да съществува и изненадващо обратният случай: критериите за приемане могат да станат твърде подробни.

„Критериите за приемане трябва да посочват умисъл, а не решение“ ( Segue Technologies )

Осигурете план на „какво“ (намерение) вместо „как“ (изпълнение). В противен случай екипът за разработки може да бъде лишен от възможността да проучи различни начини за решаване на проблема. В тези редове може да се измислят по-добри реализации след първоначалните мисли за решение.

След като напишете критериите си за приемане, можете да се запитате: „Колко е твърде много?“

Виждал съм истории, които варират от нулеви критерии за приемане до повече от петнадесет (или поне се е чувствал така).

Като правило, аз лично обичам да виждам три до осем критерия за приемане на история. Въпреки това, към горния край на тази граница, около пет или повече критерии за приемане, бих проверил управляемостта. Щях внимателно да проверя, за да видя, че историята не може да бъде разделена на по-малки, по-управляеми истории.

Други не биха се съгласили и биха спорили, че осем вече биха били твърде много. Въпреки това обичам да се навеждам към предоставяне на колкото се може повече „подробности“, без да жертвам лаконичността.

Сега какво?

Добре, излъгах. Не предоставих изчерпателен списък на критериите за приемане за писане на критерии за приемане. Желаните характеристики като сбитост, яснота и разбиране са субективни. Предназначих ги да бъдат.

Вярвам, че няма „правилен“ формат за писане на критерии за приемане. Тяхната коректност се измерва с ефективността на екипа.

Силно препоръчвам първоначално да използвате шаблон. Те осигуриха на много екипи солидна и безопасна структура, която насърчава доброто писане на критерии за приемане. Не позволявайте обаче тази структура да ви спре да напредвате в идеи, които могат да насърчат ефективността и ефикасността.

Ако сте собственик на продукт или клиент, който пише критерии за приемане, ви предизвиквам да помолите екипа си за разработка за обратна връзка относно текущите критерии за приемане. С малко грижи, практика и организация, създаването на ефективни критерии за приемане се превръща в мощен инструмент за подобряване на работния процес на всеки екип.

Още за четене

  • //rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important - от Maryna Z. и Dmiriy G.
  • //www.leadingagile.com/2014/09/acceptance-criteria/ от Steve Povilaitis
  • //www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ от Segue Technologies
  • //agileforgrowth.com/blog/acceptance-criteria-checklist/ - от Камлеш Равлани