Witam,
Chce sobie odświeżyć wiedzę odnośnie zarządzania projektem IT z użyciem metodyk zwinnych a konkretnie SCRUM.

Czytam już któreś opracowanie i wszystko jest dla mnie jasne oprócz szacowania, oceniania historyjek,zadań w backlogu ogólnym i potem sprint backlogu oraz takie sprawy jak baza danych itp.


Rozumiem że jest spotkanie z klientem i zebranie wymagań.
Przychodzi PO i ustala się przedewszystkim historyjki albo usecasy do "oprogrmowania" które stają się jednostkami w backlogu...

od razu pytanie co z wymaganiami niefunkcjonalnymi? według mnie to ograniczenia mówiące jak oprogramować konkretne zadania w ramach jakiegoś wymagania funkcjonalnego... czy się mylę?

Załóżmy że mamy 10 historyjek/usecasów np.

złożenie zamówienia, wystawienie faktury, przyjęcie płatności, rejestracja w serwisie....
i wiadomo że to należy podzielić na zadania dla programistów które są małymi, kilkugodzinnymi rzutami pisania kodu/rysowania/testowania

Co jednak z czasochłonnymi wspólnymi rzeczami takimi jak projekt i stworzenie bazy danych?
Konfiguracja serwera?
Stworzenie szablonu layoutu strony?

Są to rzeczy które nie są podzbiorem żadnego UC, ani też nie są samym w sobie UC/historyjką ... i co z nimi ? Jak umieszczać je w backlogu czy też potem na tablicy?
---------------------

Co do samego szacowania to z tego co doczytałem historyjki powinien szacować PO w jakiđtam sposb a zadania tworzy i szacuje czasowo zespół ...dla mnie to jakieś takie oderwane od jakiegokolwiek sensu .... Czy ktoś może to wyjaśnić jak wygląda to w praktyce ?



Ostatnia rzecz to tablica.
Pojawiają się sekcje historyjek, powstają kartki z zadaniami i jak rozumiem programista wybiera sobie kartke/zad do realizacji, podpisuje ją i wiesza w "in progress" itd itd.

Od razu przychodzi pytanie co/kto decyduje który p[rogramista powinien robić co, w jakiej kolejności, itd. Wydaje się to łatwe do oszukiwania. Inna sprawa że skrajni specjaliści typu graficy często muszą pewnie czekać na innych i czy to tacy nie powinni ustalać co kiedy jest robione? Prosze powiedzieć jak to jest w empirycznym środowisku produkcyjnym...


dziekuje

Zapytam jeszcze o godne polecenia kompleksowe,proste i darmowe narzędzie do wspierania prowadzenia projektów IT w scrum'ie:)

pozdrawiam
KB

Nie jestem team leaderem ale pracuję w tej metodyce, więc powiem może jak to mniej więcej wygląda...

Jeśli chodzi o niefunkcjonalne, to są one zazwyczaj rozpisywane jako jeden z tasków w ramach usecase'a, ale często mając na uwadze istniejące inne user stories, by potem przykładowo, w połowie projektu nie przebudowywać modelu danych od nowa. Znamy bowiem z reguły mniej więcej na ich podstawie ogólny zarys modelu i powiązań między jego elementami, czy encjami z nich wynikających.

Najlepiej gdyby frontend o choć jeden sprint wyprzedzał kodowanie backendu. Programiści bowiem dostają gotowy szablon, pod który tylko kod piszą i ewentualnie zgłaszają uwagi do front-end developera. Zazwyczaj jest to jednak luksus i oba elementy idą równolegle. Przynajmniej na samym początku projektu.

Sam projekt, jego analiza, MUSZĄ poprzedzać etap kodowania. Czemu? Bo inaczej nie oszacujesz poprawnie czasochłonności projektu. Nie powiesz ile co potrwa. A i tak najczęściej kończy się to na zasadzie: "Oszacowany czas należy pomnożyć razy dwa (lub trzy - zależy od technologii i zasobów) by wyszedł najprawdopodobniejszy faktyczny czas zakończenia projektu". Wynika to właśnie z faktu wzięcia pod uwagę takich rzeczy jak ewentualne choroby pracowników, poprawki w backlogu czy change requesty ze strony klienta.

Poprawne IMHO postępowanie to wspólna analiza z klientem i podział na user stories, z wyszczególnieniem co i jak oraz priorytetami dla każdego z nich. To pierwsze szacowanie. Potem następują jakieś wstępne założenia, wybór teamu. To etap drugi, gdyż wiadomo mniej więcej wtedy kto ma jakie umiejętności i można realniej oszacować możliwości zakończenie. Front-ent można już dla najbardziej priorytetowych rzeczy budować oraz bardzo wstępny, ogólny, model danych. To ułatwi potem pracę, gdyż mając ogólny widok całości, prościej zauważyć powiązania i ewentualnie zmienić priorytety user stories. By nie zaszła sytuacja, gdy w połowie projektu nagle robi się rzecz od której zależą te, pierwotnie wybrane jako ważniejsze.

Co do praktyki z zadaniami. Szacowanie nie leży tyle w gestii product ownera co wspólnego jego wysiłku z team liderami. Oni podczas rozmów z ekipą wstępnie szacują czas i z product ownerem decydują co jest istotne, co nie, co można wyrzucić lub dodać. Product owner czasem ma mylne wrażenie priorytetów lub tego co jest a co nie jest potrzebne. Team liderzy wiedzą też dość ogólnie ile co może zająć szacunkowo. Etap zadań to jednak faktycznie domena stricte programistów w teamie. Najczęściej pierwszego dnia sprintu prowadzą oni jakąś wspólną rozmowę, gdzie decydują które z dostępnych user stories będą rozpatrywane, dzielą je na zadania i szacują każde z zadań czasowo. Muszą wziąć też poprawkę na ewentualne bugi z poprzedniego lub poprzednich sprintów. Potem zgłasza się takie coś do akceptacji na dany sprint. Gdy już mamy zadania, programiści najczęściej łapią się za te, które uważają za sobie odpowiadające lub najbardziej pilne. Zazwyczaj da się wydzielić niezależne na tyle, by każdy miał coś do robienia. Jeden się łapie za opracowanie dokładnego i działającego modelu danych, inny za testy, jeszcze inny za choćby rozpykanie flow funkcjonalności i tak dalej. Czasem niektóre osoby będą wzajemnie współpracować (model danych + flow). Z czasem jednak model danych będzie już istniał i jedynie drobne modyfikacje będą zachodziły. To niemal eliminuje konieczność porządnego rozpatrywania tego elementu. Encje już będziesz miał, tylko będziesz musiał je zgrać W miarę zgrany zespół powinien już na etapie rozpisywania zadań i szacowania ich wiedzieć, co ile zajmie. To właśnie na tej podstawie się decyduje, które user story będzie w danym sprincie, oraz ile team ich weźmie. Czasem jedno user story zajmie cały sprint, innym razem sprint to będzie i 5 lub więcej user stories. Zależy to od ich stopnia komplikacji czy ilości osób w teamie (urlopy, choroby, święta), a dokładniej dostępnych osobogodzin.

To tylko wydaje się skomplikowane i dziwne, ale to się sprawdza przy teamie jakoś tam metodologię ogarniającego i wiedzącego, choć w stopniu minimalnym, co ile może zająć. Siada się zazwyczaj razem, patrzy na user story (często na etapie analizy powstaje jakiś ogólny wireframe na jakim potem się bazuje) i określa konieczne zadania. Także te poboczne, nie związane ściśle z funkcjonalnością, ale które mają na nią wpływ. Mając już zadania, przystępuje się do ich czasowego oszacowania. Łapiesz też błędy i uwagi po demie (o ile wystąpią) i określasz ich dodatkowy narzut czasowy. Teraz, mając w miarę dokładne oszacowanie, porównujesz je z dostępnymi osobogodzinami i albo dokładasz kolejne user story albo decydujesz tylko na to co masz.

Tablica... Tutaj przyda Ci się jakiś issue tracker. Na chwilę obecną w zasadzie najwięcej osób łapie się za Redmine'a, ale nie jest on jedyny. Oczywiście dobór oprogramowania zależy także od tego jak ma wyglądać cały proces produkcyjny. Ty skupiłeś się tylko na tablicy, ale przecież kod trzeba testować, deployować na serwer, zapewnić jakiś system kontroli jego wersji. Tutaj od razu wchodzi wiele innych dodatkowych narzędzi i to też trzeba ogarnąć jakoś. Zwłaszcza gdy łapiesz się za wdrożenie continuous integration. Bo wtedy dopiero zaczyna się zabawa na serio.

Wow... po raz kolejny nie zawiodłem się na ekipie z tego forum. Wielkie dzięki!

Tak jeszcze podsumowując i odrobinę rozszeżając:

według rasowego SCRUMa kolejność powinna być chyba taka...

1. rozmowa PO z klientem
2. wypisanie historyjek/funkcji przez PO
3. priorytetyzacja historyjek/funkcji przez PO
4. wyjaśnienie historyjek zespołowi i wspólne szacowanie "punktów" dla danej historyjki
5. znając "prędkość punktową zespołu"/sprint dobieramy według priorytetu historyjki na dany sprint by nie przekroczyć prędkości

Jednak nie mam zielonego pojęcia po co wprowadzać sztuczne punkty które koniec końców są przekładane na czas w momencie zmiany historyjki na konkretne zadania, dlaczego więc nie szacować tego właśnie tak?... Inna sprawa że bez ogromnego doświadczenia oszacowanie pracochłonności "modułu" ktorego się nigdy wcześniej nie wykonywało i to jeszcze w jakichś punktach jest jak dla mnie strzałem między azje a meksyk...
Na koniec czy prędkość zespołu przy pierwszymn sprincie się jakoś zakłada nie mając żadnych danych historycznych ?


Jeśli ktoś umie rozwiać moje wątpliwości i odp na postawione pytania to będę bardzo wdzięczny.

PS: jakimi narzędziami wspieracie się na co dzień albo co polecacie z przeszłości ?

Szacowanie punktowe, jak to nazwałeś, to zgrubne określenie stopnia trudności zadania, jego złożoności. Czasem trudno jednak to przełożyć na faktyczny czas z prostej przyczyny - różna biegłość osób w danej technologii. To co jednej osobie zajmie 5 godzin, inna będzie robić przez 10 lub 15 Stąd między innymi zakłada się inną ilość osobogodzin na dzień. Początkujący może przykładowo mieć ich 3, lepszy 4, a wymiatacz 6 na dzień realnej pracy. W ten sposób zespół złożony z 2 początkujących, 2 średniaków i wymiatacza to będzie realnie 20 godzin pracy przy projekcie na dobę. Z czasem poznajesz możliwości osób, wdrażają się oni i możesz zwiększać im z 3 na 4 i wyżej. Po prostu weryfikuje ich umiejętności czas przy projekcie. Z reguły więc początkowo specjalnie się nie doszacowuje tego i zaniża wartość by z czasem przyspieszać. Po 2-3 miesiącach już wiesz z reguły co i jak. Dopiero wtedy możesz faktycznie i realniej szacować wartość każdego członka zespołu, poznać ich silne i słabe strony oraz ewentualnie posyłać na określone typy zadań, z którymi radzi sobie najlepiej.

Trzyma się wtedy w miarę blisko planu lub przekracza go by mieć rezerwę. W ten sposób nawet jeśli początkowo nie będzie szło idealnie, to stopniowo można nadganiać, gdyż osoby znają już sam system, co gdzie jest i jak współdziałają elementy. Praca z kodem może więc zazwyczaj przyspieszać, choć zakładaliśmy stałą prędkość. średnią w punktach na sprint jako pewien "wyznacznik". Musiałoby się zawalić naprawdę coś, by w efekcie zliczyć wtopę.

Poza tym nie zakładaj nigdy stałej długości sprintu. To jest niby reguła, ale dość elastyczna Jeśli widzisz, że jedna funkcjonalność nie ma szansy by w sprincie się zmieścić, uzgadniasz przedłużenie sprintu by ją ogarnąć. Oczywiście są rzeczy, które ciężko ogarnąć nawet jeśli jesteś wymiataczem. Przykład? Piszesz wersję kolejną serwisu, który wciąż jest rozwijany Czemu to trudność? Ponieważ zakładasz, że nowa wersja zastąpi obecną na wiele miesięcy wcześniej. Jak jednak zaplanujesz integrację, skoro obecna ciągle jest rozwijana równolegle? Bazujesz na niej w jakiś sposób, ale nieustannie wersje 1.x i 2.x się rozjeżdżają Musisz więc mieć zapas na ich integrację. A zauważ, że zazwyczaj nie są w pełni kompatybilne - to raz. Dwa, że w końcu musi nastąpić ich scalenie, choć dane pod spodem będą niemal na pewno miały inną strukturę. No i są to już dane produkcyjne. Masz więc w chwili zatrzymania serwisu i implementacji nowej wersji tylko jeden strzał, który musi być celny.

Co do oszacowywania, nie musi to być punktowe. Przykładowo w projekcie gdzie jestem szacuje się nie punkciki, ale właśnie czas konieczny do wykonania określonego zadania. Zwyczajnie każdy w zespole określa szacunkowo ile to może zająć. Później średnia zaokrąglana w górę do godzin. Sumuje się i już wiadomo ile user story może zająć.

Co do narzędzi to może określ o jaką gałąź narzędzi Ci chodzi? W firmie bowiem z tego co wiem, niemal każdy projekt używa innych, dopasowanych do technologii użytych przykładowo. Inne będą użytkowane w małych projektach, inne w dużych, jeszcze inne w małych firmach, a zupełnie inne w korporacjach. Nawet w takim czymś jak systemy kontroli wersji jest to niejednoznaczne. Jedni preferują na Gita, inni Mercuriala, zaś jeszcze inni wybiorą Bazaar. Z issue trackerów część tortu weźmie Redmine, część JIRA czy Bugzilla. Skoro zauważyłeś już choćby konieczność istnienia backloga i całego przepływu dokumentów na linii developerka - klient, to gdzieś to też musi być trzymane. Nieprawdaż? No więc dochodzi oprogramowanie do tego także. Może być nawet Microsoft Exchange czy jakaś forma trackerów. Mogą być narzędzia w stylu Kanbana czy kombajny w stylu Confluence. Tego jest naprawdę ogrom i z częścią z nich na pewno się ludzie tu spotkali lub spotkają prędzej czy później. Nawet takie pierdółki jak oprogramowanie do videokonferencji czy klienty pocztowe można tu zaliczyć W końcu ono także jest wykorzystywane.

Super, rozumiem!

Zastanawiam się teraz jeszcze jak wygląda phpowy team tworzący jakiś portal/platformę ?

Np. chcemy zduplikować jakiś duży portal typu uproszczona wersja allegro albo silnik sklepu typu presta shop i tworzymy np 8 osobowy zespół...

Jak byście poskładali taki team ? Pewnie typowii koderzy php, ktoś od BD jakiś grafik i htmlowiec... osobna osoba od JS/AJAX/jQuery ? integrator? tester? ... w jakich proporcjach?
(wiem że nie da się dokładnie powiedzieć ale jakiś układ który miałby szanse wytworzyć po kilku miesiącach taki soft)

dzieki!

Zespół myślę w stylu:
1 team lider - on zajmuje się rzeczami abstrakcyjnymi w stylu choćby BDD czy prowadzi dialog na linii klient - developerzy, szacuje czas, dobiera zadania na sprint i wiele rzeczy okołoprojektowych.
1 tester - dedykowany. BDD jest fajne, ale nie wyłapie wielu rzeczy lub też "nie zauważy". Przykładowo problemów z wyświetlaniem layoutu - klienci lubią pixel perfekt. BDD sprawdza funkcjonalności, ale to człowiek może wprowadzić "element chaosu" i nieprzewidywalności - klikając gdzie popadnie lub celowo preparując złośliwy kod. To taka pierwsza linia obrony kodu przed audytem bezpieczeństwa. Lepiej już na poziomie firmy wyłapać największe zagrożenia i je wyeliminować.
1 osoba od html/css - ma ona tworzyć to co widać dla programistów, przygotowywać style do użycia, rozplanować elementy i ich położenie. To ona głównie będzie siedzieć i dogadzać klientowi, by nie marudził on nadto i nie truł reszcie zespołu
1 lub 2 od front endu - no chyba że chcemy front- i back-end połączyć, zdając się na doświadczenie programistów.
3 lub 4, czyli reszta to faktyczny team backendowy, zajmujący kodowaniem. Oczywiście jeśli rezygnujemy z dedykowanych front-endowców, zwiększamy tu liczbę odpowiednio.

Nie wiem czy wiesz, ale przyjmuje się empirycznie, że optymalna wartość tych ostatnich waha się około 3-5 na team. Oczywiście projekt może mieć wiele ekip, ale to ten przedział jest uznawany za dość bezpieczny dla pojedynczego teamu backendowego.

Na chwile obecną zaspokoiłeś moją ciekawość Kolego!



dzieki wielkie jeszcze raz

@thek: dzięki za fajne teksty w temacie