Jak tworzysz oprogramowanie bez kryteriów akceptacji?

W jaki sposób wspólnie opracowujesz oprogramowanie w zespole 4-5 programistów bez kryteriów akceptacji, nie wiedząc, co testerzy będą testować dla wielu (2-3) osób działających jako właściciel produktu.

Wszystko, co mamy, to szkicowa „specyfikacja” z kilkoma zrzutami ekranu i kilkoma punktorami.

Powiedziano nam, że będzie to łatwe, więc te rzeczy nie są wymagane.

Nie wiem, jak postępować.

Dodatkowe informacje

Otrzymaliśmy trudny termin.

Klient jest klientem wewnętrznym, teoretycznie mamy właściciela produktu, ale co najmniej 3 osoby testujące oprogramowanie mogą zawieść element roboczy po prostu dlatego, że nie działa tak, jak ich zdaniem powinno działać, a przejrzystość tego, czego oczekują, jest niewielka lub żadna. do czego faktycznie testują, dopóki się nie powiedzie.

właściciele produktu nie są dostępni, aby odpowiedzieć na pytania lub wyrazić opinię. Nie ma z nimi regularnych zaplanowanych spotkań ani połączeń, a informacja zwrotna może potrwać kilka dni.

Rozumiem, że nie możemy mieć idealnej specyfikacji, ale pomyślałem, że normalne byłoby posiadanie kryteriów akceptacji dla rzeczy, nad którymi pracujemy w każdym sprincie.

Iteracyjny proces osiągnie to ładnie, bez szczegółowych specyfikacji.

Po prostu stwórz szkicowy prototyp, poproś klienta o opinię, dokonaj zmian w oparciu o opinię i powtarzaj ten proces, aż aplikacja zostanie zakończona.

To, czy klient jest wystarczająco cierpliwy, aby to zrobić, to inne pytanie. Niektórzy klienci i programiści wolą ten proces; ponieważ klient jest zawsze praktyczny, (ostatecznie) dostanie dokładnie to, czego chce.

Nie trzeba dodawać, że w ten sposób nie będziesz pracować na umowę na czas określony lub na czas określony.

Jeśli to, co mówisz, jest prawdą, a specyfikacja nie jest wystarczająco dobra, abyś mógł zacząć (i jesteś szczery w tej ocenie), polecam to podejście:

1. Przeczytaj szkice i „szkicowe” specyfikacje, które otrzymałeś.
2. Napisz własną specyfikację do poziomu, który wystarczy, abyś mógł kodować. Być może będziesz musiał zrobić mnóstwo domysłów.
3. Pokaż swoją specyfikację klientowi do sprawdzenia. Zwróć uwagę na części, które im się podobają, i uzyskaj więcej informacji na temat części, które według nich są błędne.
4. Powtarzaj kroki 2 i 3, aż Ty i klient zsynchronizujecie się.
5. Masz teraz odpowiednią specyfikację.

Jeśli Twój klient miał rację, gdy powiedział „będzie łatwo”, ćwiczenie to powinno być bułką z masłem.

Jeśli twój klient się mylił i faktycznie istnieją różne braki i luki w wymaganiach, twoja wersja specyfikacji szybko zilustruje problem i poinformuje go, że się mylili (bez konieczności wskazywania palcem lub argumentowania), ponieważ być tuż przed nimi i oczywiste. Twoja specyfikacja posłuży również jako doskonałe narzędzie do dyskusji w celu wyjaśnienia tych dwuznaczności i będzie służyć jako zapis kluczowych decyzji w miarę ich korygowania wraz z ich opiniami.

Właściciel produktu wręczył ci prototyp; oddaj mu lepsze (dopóki nie skończysz)

Wygląda na to, że otrzymałeś papierowy prototyp na rozpoczęcie projektu. To nie jest straszny początek. Sugeruję, abyś skontaktował się z właścicielem firmy w tym samym języku , dostarczając prototypy o stopniowym rozwoju.

Twoje prototypy powinny zaczynać się od papieru, przechodzić na cyfrowe makiety, a następnie budować przy użyciu „prawdziwych” technologii.

Treehouse ma do tego doskonały przewodnik, który zawiera następujące wnioski:

Wspaniałą rzeczą w prototypowaniu za pomocą frameworka jest to, że prototyp często staje się prawdziwą witryną, ponieważ struktura i styl są już na miejscu. Nie ma potrzeby ponownego tworzenia strony od zera, jeśli będzie ona korzystała z tej samej platformy.

Możesz także podać formalną specyfikację, zwłaszcza jeśli martwisz się obwinianiem za zły wynik. Ale prawdopodobnie uzyskasz więcej informacji zwrotnych od prototypów.

Dotrzymaj terminu

Pamiętaj, że twoje późniejsze wysiłki nie będą klasycznymi „prototypami”, ponieważ nie będą one jednorazowe (lub ich części nie będą). Ostatnia, najzdolniejsza iteracja, którą wykonasz, zanim termin stanie się twoją dostawą.

Twój termin jest najlepiej zdefiniowanym wymaganiem. Mieć coś kompletnego i spójnego, co możesz dostarczyć na czas.

Współpracuj ze swoimi testerami

Jeśli ten luźny proces jest dla Twojej firmy czymś nowym, testerzy prawdopodobnie są jeszcze bardziej zagubieni niż Ty i mogą cię szukać . Musisz poświęcić trochę czasu na początku procesu. Poinformuj ich szefa, że ​​próbujesz pomóc im w przeprowadzeniu rzetelnego testu bez formalnych kryteriów akceptacji.

Dowiedz się, czy testerzy mają coś, czego potrzebują, na przykład dokumentację potwierdzającą testy, do której możesz „wrócić”.

Spróbuj przetestować pierwszy projekt

Ponieważ nie masz żadnych wymagań formalnych, zachęcanie do testowania przypadków testowych w celu zapewnienia pewnej struktury.

Zapoznaj się ze znajomością Test First Design i / lub programowaniem opartym na testach i przekaż testerom wskazówki dotyczące procesu w razie potrzeby. W przypadku takiego szybkiego projektu nie trzeba być ekspertem w tym procesie. Ale stosowanie sprawdzonej metodologii dobrze odbije się na tobie i twoich testerach.

Trzymaj się standardów, szczególnie w przypadku interfejsu użytkownika

Nie masz wymagań dotyczących wyglądu i stylu, ale masz termin. Użyj cudzych prac projektowych, aby zminimalizować pracę, którą musisz wykonać, aby stworzyć profesjonalnie wyglądający artefakt.

Wybierz standardowy interfejs użytkownika dla swojej witryny i nie dostosowuj go, chyba że / dopóki nie zostaniesz do niego skierowany. Nie wiem dla jakiej platformy się rozwijasz, ale Bootstrap lub Google Material Design to dwa przykłady.

Komunikuj się, ale nie dręcz się

Sugeruję wysyłanie jednego e-maila do właściciela produktu dziennie. Wysyłaj więcej niż tylko w nagłych przypadkach.

Jeśli masz pytania, opisz, jak postąpisz, jeśli nie otrzymasz wskazówek. Na przykład:

Czy użytkownicy tej aplikacji będą musieli uzyskać do niej dostęp za pomocą urządzeń mobilnych? W tej chwili zakładamy, że będzie to system wyłącznie do komputerów stacjonarnych / laptopów.

Nie panikuj

Brałem udział w wielu projektach dla ludzi, którzy nie znali terminu „wymaganie”. Większość zakończyła się sukcesem. Bezpośredni właściciele produktów dają swobodę tworzenia doskonałych rozwiązań.

Zauważ, że niektórzy właściciele projektów w tych projektach nie byli w stanie zadowolić i ukryli się za „Jestem zbyt zajęty, aby ...” usprawiedliwić ich niekompetencję. Ale większość była „zachwycona” wynikami końcowymi.

Projekt polega na zmniejszaniu niepewności do momentu osiągnięcia pewności :

• Na początku zawsze jest pewien stopień niepewności. Czasami jest trochę dwuznaczność wymagań. Czasami są bardzo szkicowe. Musisz ćwiczyć w ramach pracy.
• Sztuką jest iteracyjne zmniejszenie tej niepewności (łączenie analizy, projektowania i wdrażania), udoskonalanie historii użytkowników i wdrażanie systemu.
• Testy przypadków / scenariuszy i kryteria akceptacji będą musiały zostać wyjaśnione w ten sam sposób. Przyczynią się do zmniejszenia niepewności co do jakości i poprawności (między innymi).
• Na koniec osiąga się wystarczającą pewność: klient otrzymuje przetestowany produkt, który odpowiada jego potrzebom i może być używany.

Taka jest zasada stopniowego opracowywania: wymagania, kryteria i wyniki będą opracowywane krok po kroku, podobnie jak zrozumienie przez klienta własnych oczekiwań i wymagań dzięki zaangażowaniu w proces rozwoju.

Czy to problem ?

Szkicownik początkowe wymagania, tym większa niepewność i dłuższy czas potrzebny do wykonania zadań. Więc to tylko kwestia, kto wykona dodatkową pracę i kto pokryje koszty.

Odpowiedź na te dwa pytania powinna znajdować się w umowie. Lub będzie przedmiotem negocjacji. I klient musi zaakceptować dodatkowe zaangażowanie (głównym argumentem będzie „śmieci, śmieci”, chociaż radzę zdecydowanie przedstawić je w bardziej dyplomatyczny sposób ;-))

„ Nie ma regularnych zaplanowanych spotkań ”. Dlaczego więc nie zaczniesz od planowania regularnych spotkań ? Sam fakt, że masz wielu właścicieli produktów, gwarantuje, że Twój projekt NIE będzie łatwy, ponieważ każda z tych osób BĘDZIE mieć sprzeczne wymagania, które MUSZĄ być omówione osobiście ze wszystkimi obecnymi interesariuszami.

Ponadto naprawdę, naprawdę, naprawdę polecam prowadzenie szczegółowego dziennika decyzji . Przynajmniej zapisujesz wszystko, co ktoś postanowił, wraz z datą i listą osób obecnych przy podejmowaniu decyzji. Jeszcze lepiej, jeśli potrafisz zapisać DLACZEGO coś zostało ustalone tak, jak było. Nie ma znaczenia, czy jest to plik na komputerze, strona w intranetowej wiki, czy notatnik na biurku. Dziennik chroni ciebie i projekt: kiedy tester mówi, że jakiś element „zawodzi”, możesz wskazać, że tak postanowiono z tymi ludźmi i nie jest to twój problem, ale to między nimi a testerami. Jeśli prowadzi to do zmiany specyfikacji, to jest w porządku, ale w tym momencie nie mogą oczekiwać, że dotrzymają terminu, który mieli na myśli - albo muszą skrócić zakres w innym miejscu.

Projekt bez wyraźnych wymagań, luźne przywództwo, nie definicja gotowe (DoD), nikt nie chce być odpowiedzialny przed upewniając się, że masz potrzebne informacje, aby wykonywać swoją pracę w sposób terminowy i spełniają ich termin jest recepta dla projektu niepowodzenie.

Iteracyjny rozwój nie jest złą sugestią, ale wymaga ścisłej współpracy między właścicielami produktów i deweloperami. Spróbuj złapać kogoś na haczyku, mówiąc: „Wiemy, że będziemy mieć pytania. Kto może być regularnie dostępny, aby upewnić się, że otrzymają odpowiedzi, aby dostawa projektu nie została opóźniona?” Umów się z kimś regularnie, aby sprawdzić postępy i usunąć przeszkody. Jeśli się nie pokażą lub odmówią, skontaktują się z uprzejmą pisemną korespondencją i opóźnią lub nie odpowiedzą na dokumenty. Jeśli właściciele produktu nie mogą być dostępni, poproś ich o przedstawienie przedstawiciela, który może być.

Kolejną cechą charakterystyczną iteracyjnego rozwoju jest to, że zmiana wymagań wymaga zmiany osi czasu. Nie możesz zobowiązać się do dotrzymania terminu, jeśli nie możesz opracować osi czasu, i nie możesz opracować osi czasu, jeśli nie masz pojęcia, co należy zrobić. Zamiast dogmatycznie pytać o specyfikację, przejrzyj aktualną specyfikację, udokumentuj wszelkie pytania, które Ty lub zespół masz na temat tego, jak ma ona działać, umów się z właścicielami produktu na omówienie jej i udokumentuj odpowiedzi. Gdy skończysz, otrzymasz specyfikacje oparte na ich decyzjach, na które możesz następnie poprosić właścicieli produktów (na piśmie). Celem specyfikacji jest usunięcie niejednoznaczności i utworzenie DoD, co dokładnie może zapewnić sesja pytań i odpowiedzi. Jeśli istnieje sprzeciw wobec specyfikacji, nie nazywaj jej specyfikacją.

Nie wierz nikomu, kiedy ci powiedzą, że będzie łatwo . Czasami to naprawdę jest tak proste, jak się wydaje, i mogę w to uwierzyć, jeśli (i tylko wtedy ) znam właścicieli produktów wystarczająco dobrze, aby w pełni ufać, że wymagania są tak proste, jak im się podoba, i specyfikacje, w których byłem pod warunkiem, że są zrozumiałe (jeśli nie, planuję sesję pytań i odpowiedzi i dokumentuję ją). Byłem w zbyt wielu sytuacjach, w których łatwość z punktu widzenia operacji jest niezwykle trudnaz punktu widzenia rozwoju lub myślisz, że jesteś całkowicie skończony i słyszysz słowa rozpaczy („A tak przy okazji, zapomnieliśmy o…”). Przykład ... „Wszystko, co musisz zrobić, to odczytać te pliki PDF z repozytorium dokumentów”, które podczas testów akceptacyjnych zamieniają się w „Och, zapomnieliśmy, że niektóre z nich zostały odczytane na boki w całkowicie niespójny sposób, i niektóre mają zdefiniowany niewłaściwy rozmiar strony, a niektóre wymagają dołączenia tych trzech stron i potrzebujemy ich wszystkich, aby wyświetlały się tak samo. Naprawdę łatwo to naprawić, prawda? ".

Chodzi o to, że może być naprawdę łatwe, a szybkie spotkanie może to potwierdzić, umożliwiając udokumentowanie wszystkich założeń i uzyskanie potwierdzenia, że ​​są one dokładne i prawidłowe. Polecam wstać, aby usunąć przeszkody, które musisz napisać działającemu kodowi, który spełnia ich oczekiwania, ponieważ niezależnie od tego, czy stąpasz na palcach, ktoś i tak prawdopodobnie będzie niezadowolony. Jeśli jesteś wytrwały w uzyskiwaniu odpowiedzi na pytania i irytujesz kogoś, zapomni o tym, gdy dostarczysz świetny produkt na czas, który spełnia wymagania. Jeśli nie dostaniesz wyjaśnienia i nie dostarczysz, nikt nie będzie pamiętać, że powiedzieli ci, żebyś ich nie robił.

Bez specyfikacji masz pracę zespołową. Idź zwinny.

Usiądź przy PO i przygotuj kilka krótkich początkowych historii. „Dostarczymy tylko ten ekran, z tym przyciskiem, który zmienia się w„ bing! ””. Postaw na niektóre AC. Dostarcz historię. Zademonstruj historię. Okazuje się, że przyciski powinny być czerwone. Podnieś błąd lub nową historię. Dostarcz przyciski, które zaczynają bong i huk I tak dalej.

Wspólnie określ i dostarcz małe pionowe plastry, które są często demonstrowane.

Jeśli klient nie będzie z tobą współpracował w ten sposób, poszukaj wyjścia.

Spędziłem kilka prac, wykonując projekty zgodnie z twoimi planami. Tak długo, jak organizacja producentów wie, jakie decyzje projektowe podejmujesz i dlaczego musisz je podejmować, powinieneś czuć się dobrze. Z drugiej strony, jeśli nie rozumieją decyzji projektowych, należy je nacisnąć dla przynajmniej pisemnego dokumentu testu akceptacji użytkownika.

Potrzebujesz szczegółowej, weryfikowalnej specyfikacji, zanim zaczniesz pisać kod. To fakt i nie można tego obejść.

Jeśli nikt inny nie chce napisać tej specyfikacji, to programiści muszą ją napisać. Otrzymujesz więc niepełną specyfikację. Przekształcasz go w pełną specyfikację (co oznacza, że ​​„to właśnie zamierzam wdrożyć, chyba że ktoś inny powie mi, żeby tego nie robić”). Przekazujesz tę specyfikację interesariuszom i dajesz im szansę na modyfikację specyfikacji. Tylko szansa na zmodyfikowanie specyfikacji - nie cofanie jej, na przykład mówiąc „Nie lubię tego w ten sposób”. W tym momencie jest to Twoja specyfikacja lub mogą podać inną specyfikację, ale nie mogą jej usunąć.

Dobrym pomysłem może być szybki przegląd od kolegów, którzy mogą ulepszyć specyfikację. Ale i tak masz specyfikację, piszesz odpowiednio kod, testerzy odpowiednio testują. I wykonałeś swoją pracę: miałeś specyfikację i ją wdrożyłeś. Jeśli specyfikacja nie jest tym, czego chce klient, jest to po prostu odpowiedzialność właściciela produktu lub klienta, któremu nie przeszkadzało napisanie dobrej specyfikacji.