Jak powinniśmy obsługiwać dodatkowe funkcje kosmetyczne w sprintach Scrum?

Czytałem dokumenty Scrum i mówi, że zadania w Sprint powinny być „potencjalnie możliwe do wysłania”.

Jestem zmieszany tym, co to oznacza. Załóżmy, że celem w Sprint 1 był „formularz rejestracji użytkownika”.

Ile szczegółów muszę dodać, aby coś było gotowe do wysyłki? Na przykład:

1. Mogę pokazać prostą formę z polami bez fantazyjnej stylizacji i oznaczyć je jako gotowe
2. Mogę po prostu przeprowadzić weryfikację po stronie klienta jako oznaczoną jako wykonaną, ale po stronie serwera jest również opcja lub jedno i drugie
3. Mogę również dodać kilka fantazyjnych podpowiedzi jQuery, najechanie kursorem, captcha, kolory, etykiety formularza
4. Potem jest mnóstwo stylizacji na temat wyświetlania komunikatów o błędach na ekranie

Mogę robić bez końca na jeden temat. Jak więc to podzielić i kiedy mogę myśleć o tym jako o wysyłce gotowej.

Czy też muszę napisać każdą najmniejszą możliwą rzecz, taką jak wyświetlanie błędów, wyskakujących okienek lub tekstu lightbox jako podzadań i umieszczać je jako sprint. Doprowadziłoby to do tysiąca zadań dla całego projektu.

Mam na myśli, że jeśli niektóre działają dla Internet Explorera, a niektóre dla Firefoksa, to znowu muszę je również podzielić na zadania. Muszę poświęcić im czas, a kiedy kierownik zapyta mnie, co zrobiłeś w tym czasie, nie będę miał żadnych zadań do powiedzenia, ale w rzeczywistości wszystkie one są częścią rejestracji użytkownika

Uzgodnij to z właścicielem produktu i zespołem Scrum, a nie z Internetem. Powinno to zostać określone w twojej definicji ukończenia i będzie w dużej mierze zależeć od tego, jak działa zespół.

Chociaż ta funkcja powinna być „ możliwa do wysyłki” (nienawidzę tego terminu w Scrumie), można argumentować, że funkcjonalność jest możliwa do wysyłki bez interfejsu użytkownika. Wiele osób cierpi z powodu tego nieporozumienia w Scrumie - celem sprintu jest zdobycie jak największej liczby (najlepiej wszystkich) „Gotowych”, ale zdecydowanie nie musi być wbudowane w coś, co można by wydać.

Ważne jest, aby wyprasować takie rzeczy wcześnie, aby wszyscy w zespole pracowali nad wspólnym celem. Etos Scrum to komunikacja, więc zapytaj zespół Scrum i wyciągnij logiczny wniosek.

Możesz pracować w zespole, w którym interfejs użytkownika jest generalnie obsługiwany osobno, na przykład przez inny zespół lub gdy eksperci zajmujący się interfejsem użytkownika zdecydują, jak powinien wyglądać formularz itp. Alternatywnie, w małym projekcie / zespole można oczekiwać, że interfejs użytkownika zostanie zbudowany tak jak Ty iść.

Dopóki wszyscy znają odpowiedź, nie ma znaczenia, jaka jest odpowiedź.

Jeśli elementy kosmetyczne są częścią tej funkcji, prawdopodobnie powinny być wykonane jako część historii. Chodzi o to, że kiedy powiesz, że historia jest skończona, nie powinieneś już więcej kodować konkretnej funkcji. Jednak ostatecznie decyduje o tym właściciel produktu - mogą chcieć cech kosmetycznych, a może nie. Powinno to zostać określone w kryteriach akceptacji.

Nie musi to oznaczać, że jest gotowy do użycia przez użytkownika końcowego, oznacza tylko, że jest gotowy dla kogoś . Że ktoś może być testerem lub innym zespołem, takim jak zespół zaplecza.

Jeśli pytasz o to jako programista, odpowiedź brzmi „wiesz, ponieważ właściciel produktu powie ci, czy chce funkcji kosmetycznych, czy nie”.

Jeśli pytasz o to właściciela produktu, musisz po prostu zdecydować, czy chcesz podzielić funkcję na więcej niż jedną historię. Nie ma wymogu, poza tym, że musi cię zadowolić , jako sposobu na zadowolenie klienta .

Pamiętaj: celem nie jest ścisłe przestrzeganie scrum. Celem jest dostarczenie wysokiej jakości oprogramowania dla użytkownika końcowego. Użyj tego jako przewodnika, gdy zmagasz się z takimi pytaniami. Czy dodanie kosmetyków w tej samej historii co czysto funkcjonalne części pomoże dostarczyć kod jakości do klienta? Czy może podzielenie tego na dwie historie pomoże? Albo odpowiedź jest jasna, albo nie ma znaczenia i możesz zrobić wszystko, co działa dla twojego zespołu.

„Potencjalnie nadający się do wysyłki” oznacza nadający się do wysyłki niekoniecznie coś, co wysyłasz. Na przykład:

Internetowy formularz rejestracyjny, który wygląda okropnie i nie ma potwierdzenia na polach, może być odpowiedni w niektórych sytuacjach, takich jak projekt szkolny, ale w biznesie o wartości wielu milionów dolarów zaszkodziłby marce, aby pokazać ją użytkownikom końcowym. Kod może być wysyłany bez bycia czymś, co chciałbyś wysłać lub że marketingowy lub prawny pozwoliłby ci wysłać.

Jest to coś, co programiści (i inni ludzie, którzy są w tym momencie w trakcie opracowywania, np. Projektanci) byliby szczęśliwi z wydania tak, jak jest teraz, nawet jeśli z jakiegoś powodu tak naprawdę nigdy nie zostałby wydany w ten sposób (np. musi zostać przetłumaczone na inne języki, zanim będzie można je wysłać komukolwiek - Kanada ma surowe zasady dotyczące zakupu przez rząd oprogramowania, które uwzględnia w równym stopniu francuski, jak i angielski).

Jest to punkt kontroli jakości, patrzysz wszystkim w oczy i pytasz, czy byliby szczęśliwi, wysyłając go takim, jaki jest teraz, bez dodatkowej pracy, bez sprawdzania, czy zrobili to ostatnie. Słyszałem, że to się nazywa punkt kontrolny inżyniera samolotu. Patrzysz inżynierowi w oczy i pytasz, czy są gotowi towarzyszyć Ci podczas lotu testowego.

Chodzi o to, aby być jak najbardziej zwinnym. Im szybciej możesz dostać coś dla prawdziwych użytkowników; niezależnie od tego, czy są to wersje beta kodu do wyboru osób, czy testy A / B w Twojej witrynie, tym lepiej. Jeśli pokażesz użytkownikom kod, który jest zbyt szorstki, szorstki zgodnie z ich oczekiwaniami dotyczącymi Twojego produktu, przekażą ci bezużyteczne informacje zwrotne. Będą rozmawiać o rzeczach, na które nie szukasz informacji, takich jak: nie podoba im się, że przycisk jest żółty lub pole tekstowe nie pokrywa się z etykietami. Jeśli jest wystarczająco dobry, możesz uzyskać przydatne informacje zwrotne. Im szybciej otrzymasz tę opinię, tym lepiej! Możesz zweryfikować dopasowanie produktu / rynku oraz przyjęte założenia dotyczące funkcji, którą próbujesz zbudować.

Wysyłka tej funkcji jest najmniej istotną częścią tego. Ważne jest przeniesienie zespołu programistów i dokończenie historii użytkowników. Osiągnięcie punktu, w którym można stwierdzić, że coś zostało zrobione, jest świetną motywacją.

W moim rozumieniu każda historia powinna być „gotowa” i „nadająca się do wysyłki” w zakresie, w jakim jest gotowa do spożycia przez kogoś , niekoniecznie przez użytkownika końcowego . Tak więc twoja historia może dostarczyć pewne funkcje, które mogą być następnie dostarczone właścicielowi produktu, który może zdecydować o udostępnieniu go użytkownikom końcowym lub powtórzeniu tej funkcji.

To powiedziawszy, nie jest wykluczone włączenie stylizacji do historii „Jako użytkownik końcowy będę mógł się zarejestrować”. W naszym zespole staramy się, aby każda historia była jak najmniejsza, aby zachować wyższą przewidywalność i zapewnić, że jesteśmy w stanie dostarczyć to, co obiecujemy. Jeśli mamy gotowy projekt i uważamy, że jego zastosowanie jest trywialne, jest to uwzględnione w historii. Jeśli uważamy, że może być trochę iteracji w projekcie, to osobna historia - być może wielokrotna.

Oprócz innych świetnych odpowiedzi na to pytanie, możesz również myśleć o cechach kosmetycznych jako o zmiennym zakresie części trójkąta zakres-zasoby-czas. Upewnij się, że spełniasz podstawowe wymagania tej historii i dodaj ładne rzeczy, jeśli masz czas.

Scrum nie powinien gwarantować dostarczenia określonych funkcji w określonym czasie. Ma zapewnić maksymalną użyteczną pracę, która jest możliwa w danym czasie. Jeśli „opcjonalne” funkcje kosmetyczne nie zostaną wykonane podczas tego sprintu, powinno to być spowodowane tym, że nie były możliwe.

Zależy to od osoby ustalającej wymagania, „właściciela produktu”. Jako programista mogę być zadowolony ze niestylizowanej strony „formularza rejestracyjnego”, która po prostu dowodzi, że logika biznesowa w moich usługach internetowych działa poprawnie, a rejestracja pozwala na uwierzytelnienie się na innych zasobach w systemie. W rzeczywistości „potencjalnie nadający się do wysyłki”, ponieważ niekoniecznie oznacza to, że dosłownie wyślemy go do klienta, może pozwolić, aby był to wynik pierwszej historii użytkownika na ten temat, szczególnie jeśli zespół techniczny i zespół projektowy to osobne zasoby z osobnymi zaległościami.

W przypadku bardziej dojrzałego projektu możesz wysłać wersję funkcji zaprojektowaną przez programistę, z minimalnym stylem, do klienta pilotażowego lub beta, ale wróć do tej samej funkcji zarówno w przypadku modyfikacji funkcjonalności (w oparciu o opinie), jak i ukończenia projektu.

Metodologia Agile ma na celu zaspokojenie twoich wymagań w kierowaniu procesem rozwoju oprogramowania, a nie odwrotnie. Nie wpadnij w pułapkę, zakładając, że jednym z opisów metodologii jest Prawda i Jedyny Prawosławny Wymóg. Łatwiej powiedzieć niż zrobić, oczywiście, szczególnie jeśli jesteś w dużej organizacji, w której Scrum stał się pretekstem do wywołania chaosu w zespole programistów.