środa, 29 stycznia 2014

clean code - wprowadzanie część 3

Szacowanie

Strach przed szacowaniem zadania wydaje się być naturalny, ale czy musi tak zawsze być ? Szacowanie to odwieczny konflikt między PM a programistą. Dlaczego tak się dzieje ? Ponieważ PM traktuje szacowanie jako zobowiązanie, a programista jako przypuszczenie.
Profesjonalista nie podejmuje zobowiązań kiedy nie ma pewności, że je wypełni w zadanym czasie. Jeśli nie jesteś pewien, że zdołasz to zrobić w zaproponowanym przez siebie czasie po prostu odmów.

Bazując się na Twoich szacunkach inni zaczną tworzyć swoje plany.

TIP : PERT



Latające palce
Członkowie zespołu siedzą przy stole i omawiają wszystkie zadania w danym sprincie. Omawiają co może skomplikować dane zadanie i jak można je zaimplementować. Na raz uczestnicy podnoszą palce do góry i pokazują liczbę od 0 do 5 w zależności od własnego przeczucia co do pracochłonności zadania.
Jeśli będzie pełna zgoda, znaczy to, że zadanie zostało zaakceptowanie. W przeciwnym wypadku zaczynamy proces od nowa. Zgoda nie musi być całkowita. Odchylenie można ustalić na początku spotkania.








 Planning Poker
Każdy członek zespołu dostaje zestaw kart z różnymi numerami. Prowadzący wymienia zadanie i zaczyna się dyskusja. W końcu wszyscy muszą zdecydować jaką kartę wybrać. Aż do momentu pokazania karty, nikt nie ma prawa jej widzieć poza właścicielem. Jeżeli wszystkie numery są podobne następuje zaakceptowanie szacunku w przeciwnym wypadku postępujemy dokładnie tak samo aż do skutku. Siła tego narzędzia to dyskusja.







Szacowanie : Stożek niepewności (Cone of uncertainty)

















Stożek niepewności przypomina programiście, że jego początkowe szacowania mogą się różnić od końcowego stadium zadania nawet o 400%. Obrazuje nam jeszcze jak wygląda stosunek : szacunek od stadium projektu.


Żeby poprawić swoje szacowania głównie potrzebujemy :
 - historii, który rozmiary mogą być porównywane w stosunku do siebie samych
 - systemu punktowego do śledzenia postępów

Istnieje terminy:
   - szacunek względny (przez triangulacje) jest to taka sytuacja kiedy robiłeś coś podobnego do  bieżącego zadania tym samym masz jakiś pogląd sytuacji, możesz te zadaniu w pewien sposób porównać ze sobą.

 - szacunek bezwględny - kiedy nie istnieje żadna rzecz do której możesz porównać swoje zadanie, aby przynajmniej w przybliżeniu stwierdzić ile to Ci   de facto zajmie czasu np wyrzucenie dwóch piątek kością do gry pod rząd.

System punktowy pozwala wprowadzić wymyślona jednostkę miary, którą będziemy estymować nasze zadanie. Możemy też dzięki temu śledzić postępy i szacować względnie.
Zaletą tego systemu jest to, że uświadamia nam iż nadal mamy do czynienia z szacunkiem a nie wartością znaną np czas . Jest łatwy, szybki i prosty.

TIP : Pamiętaj , że programista nie pracuje wydajnie przez cały dzień , więc mówienie, że coś zajmie np 3 dni musi brać tę zależność pod uwagę.

Tip : The Burn-Down Chart -> czyli coś dla  PM'ów

Burn-Down Chart jest  to graficzne przedstawienie pozostałych do wykonania w projekcie prac względem czasu. Wykres pokazuje także szacowany czas pracy do zakończenia projektu.















źródło : http://www.agilenutshell.com/


Presje

Najważniejsze jest to żeby opanować stres. Zamartwianie się niewiele pomoże. Nieprzespane noce, podobnie. Najgorsze co możesz zrobić to zacząć się spieszyć. Wtedy utoniesz do reszty.

Tip : Informuj o kłopotach zawczasu.

Pamiętaj : Zły kod zawsze spowalnia.

Współpraca

Kodu jest własnością zespołu (collective code ownership). Bardzo złym symptomem jest to jak którykolwiek z programistów w zespole buduje mur otaczający jego kod i odmawia zmian pozostałym.

Praca w parach się opłaca.
Jeśli nigdy tak nie pracowałeś to spróbuj.
To najlepszy sposób bezpośredniego dzielenia się wiedzą. Technika ta pozwala również rozpowszechniać dobre wzorce i praktyki oraz wzbogaca cały zespół w solidną wiedzę na temat projektu. Dotyczy to zarówno części biznesowej jak i technicznej.
Niektórzy mogą powiedzieć, że tracimy zasoby bo dwie osoby robią to samo.
Okazuje się jednak, że to błędne myślenie. Taka inwestycja zwraca się bardzo szybko, ponieważ potem okazuje się, że kod napisany jest lepiej (real-time code review), zawiera mniej błędów. Następny atut tej metody, że każdy członek zespołu może bezboleśnie poprawiać błędy w wielu obszarach aplikacji, bo istnieje duże prawdopodobieństwo, że w którym z tych obszarów już empirycznie uczestniczył.

Tip : XP

Swarming (z ang - rój) czyli równoległa praca wielu członków zespołu nad jednym wybranym problemem.
Przykładowe zastosowanie : eliminacja wąskich gardeł, detekcja błędów, dotarcie zespołu etc.

Zespoły i projekty

Zgranie zespołu wymaga czasu. Po pewnym czasie każdy wie co ma robić i w czym jest dobry.
Zadaniem analityka jest zdefiniowanie wymagań biznesowych, czasem tworzenie zautomatyzowanych testów UAT.
Testerzy również mają tworzyć takie testy.
Jak więc jest różnica?  Analityk koncentruje się  na biznesie , a tester na poprawności. Analityk z reguły przechodzi przez optymistyczną ścieżkę, a tester powinien zastanowić się co można zepsuć w tym całym procesie.
Menadżer zaś monitoruje postępy zespołu, definiuje priorytety i harmonogramy.
Ktoś w zespole scrumowym musi pełnić role mistrza. Jego odpowiedzialnością jest ochrona procesów oraz metod wyznaczonych przez zespół.

Tip : Zespół tworzy się trudniej niż projekt

Ok. na tym zakończyliśmy rozważania 'filozoficzne'.

Teraz przejdziemy do clean code w czystym wydaniu. Bazując na pracach Uncle Boba omówimy sobie jak pisać 'czysty', czytelny kod. Po prostu przedstawimy kilkanaście recept i porad, który wyniesie jakość Twojego kodu na wyższy poziom.

dalej ->

Brak komentarzy:

Prześlij komentarz