Obecnie używamy JIRA do śledzenia naszych prac programistycznych. Moje kierownictwo chce sformatować i skategoryzować wszystko jako „Historie użytkowników”, w tym zadania niezwiązane z programowaniem. Na przykład:

„Czy jako menedżer testów mogę przeprowadzać testy aplikacji, korzystając wyłącznie z testów automatycznych i bez testów ręcznych, aby przetestować aplikację tak skutecznie, jak to możliwe?

Kryteria akceptacji: 1. Przekształć 50 istniejących testów ręcznych w testy w pełni zautomatyzowane 2. Testy muszą zostać wykonane w czasie krótszym niż 1 godzina ”

Chcę uzyskać poczucie od społeczności, czy sensowne jest wykorzystywanie „historii użytkowników” do pracy, która wspiera proces tworzenia oprogramowania, nie jest wykonywana przez programistów i nie prowadzi bezpośrednio do dostarczenia kodu. A może należy to traktować / klasyfikować inaczej (na przykład w JIRA)?

Zaktualizowano 6/7/2011 - Przeredagowane pytanie, aby skupić się na terminie „historia użytkownika”.

tak

każdy interesariusz, każda funkcja usprawniająca system

[niech zaczną się głosy purystów!]

„Moje kierownictwo chce używać Agile do wszystkiego, w tym zadań niezwiązanych z programowaniem”.

Ten sposób nie myśli pisząc historie użytkownika dla każdej funkcji.

Jeśli chcesz pisać historie użytkowników dla każdej funkcji, niekoniecznie jesteś zwinny. Po prostu piszesz historie użytkowników dla każdej funkcji.

Historie użytkowników! = Zwinne.

Historie użytkowników to sposób na zebranie i zrozumienie wymagań. Można je stosować w sposób idealnie wodospadowy, jeśli chcesz. Niektórzy to robią.

Zwinny to sposób zarządzania projektami. Opcji użytkownika można używać w projekcie Agile lub nie.

Historie użytkowników do zarządzania długiem technicznym i zadaniami wewnętrznymi - znowu - nie ma nic wspólnego z byciem Zwinnym.

Wielu ludzi jest bardzo zadowolonych z dodania funkcji „technicznych” lub „wsparcia” do sprintu bez marnowania czasu na pisanie fałszywej „historii użytkownika” dla użytkowników wewnętrznych, o ograniczonej wartości dodanej i nie interesujących się nimi.

Jeśli QA nie dowie się o tym, ile to jest rzeczywistych strat biznesowych?

Jeśli prawdziwi interesariusze nie dostaną swoich historii, firma naprawdę cierpi.

To nie ma dla mnie sensu. „Historia użytkownika” w istocie jest po prostu historią użytkownika, a nie historią Project Managera, nie historią programisty, a nie historią Inżyniera Zapewnienia Jakości.

W tym przypadku oprogramowanie to:

1. Definiowalne
2. Testowalny

Ulepszenia procesu są otwarte i zazwyczaj subiektywne.

Kryteria akceptacji: 1. Udoskonalenie testowania 1 (x / r)

Jak mierzysz Ulepszenie w testowaniu? Nie ma na to określonej umowy.

I na niepowiązanej notatce szczerze NADZIEJĘ, że twój przykład podany powyżej,

Czy jako menedżer testów mogę przeprowadzać testy aplikacji, korzystając wyłącznie z testów automatycznych i bez testów ręcznych, aby testować aplikację tak skutecznie, jak to możliwe?

... jest po prostu przykładem, ponieważ jest w tym tyle złego, że nie mogę nawet zacząć opisywać.

Dług techniczny można traktować w podobny sposób jak historię użytkownika, ale czasami może to być dość brzydkie. Na przykład, aby mieć historię typu: „Jako programista chcę mieć działające testy jednostkowe, aby mieć pewność, że testy sprawdzą, czy inne zmiany coś zepsują”, nie ma dużej wartości dla właściciela produktu ale może to być dobry pomysł dla zespołu, aby zrobić to w ramach własnego refaktoryzacji, która jest częścią pracy w sprincie.

Podoba mi się pomysł, aby zadania były oddzielne od historii użytkowników, ponieważ zadania te nie będą czymś, co chciałbyś pokazać użytkownikowi końcowemu systemu, ale mogą pomóc poprawić konserwację i czas, jaki może to zająć opracuj nową funkcję. W zależności od liczby zadań, pod względem ogólnej liczby punktów, ponieważ niektóre zadania mogą trwać 2 minuty, a inne mogą trwać 2 tygodnie, to może się zdarzyć, że to decyduje, czy zespół bierze sprint i nie wprowadza nowych funkcji, ale działa na temat zadań związanych z czyszczeniem rzeczy, które widziałem kilka razy w miejscu pracy.

Moim skromnym zdaniem, tak, możesz wykorzystywać historie użytkowników w projektach niezwiązanych z oprogramowaniem, a nie tylko w zadaniach związanych z ulepszaniem procesów. Weźmy na przykład 3 lata temu byłem najlepszym człowiekiem na ślubie mojego przyjaciela i wykorzystałem metodologię Agile i historie użytkowników do planowania ślubu. Wszystkie zadania, które musieliśmy wykonać, zostały napisane jako historie użytkowników z osobowością, intencją, uzasadnieniem i kryteriami sukcesu dla każdej historii użytkownika. Wszystkie zaangażowane strony wzięły udział w naszym codziennym scrumie, aby omówić, co zrobiliśmy poprzedniego dnia i co będziemy robić tego dnia. Wszyscy byli rozproszeni geograficznie, dlatego organizowaliśmy telekonferencje na nasze codzienne spotkania scrumowe, planowanie sprintu, retrospektywy, pisanie opowiadań i sesje szacunkowe ... no tak, zrobiliśmy to. Mieliśmy w sumie 6 sprintów (3 miesiące), a ślub był zdumiewającym sukcesem bez kamienia, który nie został odwrócony.

Masz głęboki problem, gdy łączysz wewnętrzne „historie użytkowników” z rzeczywistymi historiami użytkowników.

Przeczytaj ponownie dowolną liczbę definicji „interesariusza”.

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

Przeczytaj je bardzo, bardzo uważnie, aby zobaczyć różnicę między kurczakami a świniami.

Wewnętrzne „historie użytkowników” są pisane przez kurczaki.

Rzeczywiste historie użytkowników są pisane przez świnie.

Twoje „zorientowane na kurczaka” historie użytkowników nie są bardzo ważne. Bez względu na to, jak bardzo kierownictwo chce je śledzić, jakby były prawdziwymi historiami użytkowników o prawdziwej wartości, nie są prawdziwymi historiami użytkowników i nie tworzą wartości w ten sam sposób.

Na niewyraźnym brzegu argumentu leży kwestia kontroli jakości. Kontrola jakości jest ważna i bez niej nic nie działa.

To nie magicznie czyni QA nagle świnią. To sprawia, że ​​nadal nie są zainteresowanymi stronami. Zapewniają wsparcie, infrastrukturę i niezbędne podstawy do dalszej pracy. Ale te „historie użytkowników” zasadniczo różnią się od prawdziwych historii użytkownika.

Jeśli QA nie wykazuje testowania poprawy w testowaniu, nikt nie wychodzi z biznesu. Pieniądze nie są stracone.

Jeśli użytkownik nie może przede wszystkim prowadzić działalności, oznacza to, że nie ma firmy. Pieniądze są stracone. Cała operacja jest całkowitą porażką.

Nie mieszaj wewnętrznych („kurczaków”) i prawdziwych („świńskich”) interesariuszy.

Komentarz „kurczaki i świnie” nie ma sensu. Interesariusze wewnętrzni to kurczaki, jeśli chodzi o opracowywany produkt (chyba że jest dla nich opracowywany), ale są świniami, jeśli chodzi o proces rozwoju.

Pytanie, które zadajesz, brzmi, czy formuła zdania „As a , Chciałbym móc _ , więc mogę __ "byłoby przydatne do definiowania i ulepszania procesów biznesowych, w których ulepszenia nie wymagają pisania nowego kodu oprogramowania. Natknąłem się na ten wątek, ponieważ myślę o zrobieniu tego samego i szukam najlepszych praktyk, ale moją silną intuicją jest to, że odpowiedź na twoje pytanie brzmi „tak”. Celem struktury zdania jest naprawdę zmusić pisarza do wyodrębnienia rozwiązań, które on / on może już mieć na myśli i skupić się na tym, co użytkownik - w tym przypadek, użytkownik procesu - chce być w stanie to zrobić. Nie widzę powodu, dla którego historia użytkownika nie byłaby przydatna w przypadku zastosowania do procesu.

Punkt dotyczący kryteriów akceptacji jest dobry, ale nie musi być dogmatyczny w tym względzie (co zresztą jest zwinny). Dobrym ćwiczeniem przy projektowaniu dowolnego procesu biznesowego jest pytanie: „Skąd będę wiedział, czy zmiana procesu osiągnęła mój cel?” Prawdą jest, że nie zawsze można uruchomić automatyczny test, aby odpowiedzieć na to pytanie, ale nie jest to powód do dyskwalifikacji historii użytkownika jako narzędzia.