Zabawy ze SCRUM

Jakiś czas temu wystartowaliśmy z nowym projektem (jeszcze nie mogę powiedzieć czego dotyczy), w którym mamy więcej wykorzystanych praktyk z kategorii Agile niż inne do tej pory.

Przede wszystkim – iteracje (trzytygodniowe).
Właśnie zakończyliśmy pierwszą. Odbyła się prezentacja iteracji, na której niestety nie było klienta. Był za to szef w roli klienta wewnętrznego- to on bywał na spotkaniach z klientami, więc był najlepszym substytutem na jaki nas było stać.

Ze scrum używamy dziennika zaległości produktowych (product backlog), który ciągle się rozrasta. Na razie sukcesem jest to, że przed końcem pierwszej iteracji w dzienniku mieliśmy wystarczająco elementów, żeby zacząć następną.

Tak wygląda wykres burndown dla zakończonej właśnie iteracji:
iteracja1_burndown_chart

Staramy się stosować stopniowe zbieranie wymagań i stopniowy rozwój architektury z tym, że to drugie przetestowaliśmy już wcześniej w mniejszych pod-projektach. Pomijając fakt, że jest to zwyczajnie przyjemne podejście – gdybyśmy chcieli zebrać wszystkie wymagania, to trwałoby to do końca października. Gdyby jeszcze do tego projektować wszystko “z góry” – następny miesiąc by minął do startu projektu.

Po pierwszej retrospekcji doszliśmy do wniosku, że zbyt mało energii zostało włożone w etap planowania iteracji. Tym razem bardziej się na tym skupiliśmy. Jednak efekty, jeśli będą widoczne, to dopiero podczas kolejnej iteracji.

Udało nam się też wykonać krok w kierunku ciągłej integracji (CI):
– używamy MySchemaShell do migracji struktury bazy danych
– własnego narzędzia dla startowych danych testowych (też programik Shell) + do generowania obiektów ACL
– Selenium dla prostych (na razie) testów interfejsu, dla zabezpieczenia się przed sytuacją, gdy jest dwie godziny do prezentacji iteracji, nie ma odważnego do przeklikania systemu w celu znalezienia wpadek. No i te wpadki znajduje klient. Te testy trochę trwają, ale na pewno mniej niż ręczne “śmiganie po stronie”.

Co do testów jednostkowych – na razie jest plan, aby umieszczać je w krytycznych miejscach. Co w praktyce oznacza testowanie reguł biznesowych umieszczonych w warstwie modelu.

Jeśli pojawi się więcej ciekawostek – na pewno nie omieszkam napisać.

Share Button

Nowe odkrycie – Phing

Zawsze myślałem, że z uwagi na to iż PHP jest językiem skryptowym wszysto co jest związane z procesem budowania i kompilacji – nie dotyczy PHP właśnie…

Tzn. zawsze wiedziałem, że kompilacja się odbywa podczas wykonywania kodu, więc mnie nie zajmowała. Klawisz F9 z Delphi czy BorlandBuildera zastąpiony został przez klawisz F5 w przeglądarce ;)

Jeśli chodzi o budowanie (Crtl+F9 zdaje się ;)) to wiedziałem, że zawarta jest w tym procesie. Reszta mnie nie interesowała, więc osunąłem się w słodkie objęcia ignorancji.

Czytając książki sugerujące stosowanie systemów ciągłej integracji (CI) i konsolidacji myślałem sobie, że spoko, fajnie by było, ale jednak w PHP nie ma czegoś takiego jak integracja i konsolidacja.

Nie mogłem bardziej się mylić ;) Dopiero przy trzeciej książce, w której wspomniana jest CI mnie olśniło:
Budowanie aplikacji to cały proces, który zmienia czysty kod z repozytorium w działającą aplikację!

A zatem obejmuje stworzenie bazy danych o odpowiedniej strukturze(*), ustawienie odpowiednich uprawnień do katalogów, które tego wymagają, wypełnienie bazy danymi startowymi i wszystkie inne czynności wymagane do poprawnego używania aplikacji.

Niezwykle ważne jest, aby móc cały ten proces zautomatyzować. Jedna z rzeczy jakich nauczyłem się podczas mojego, dwuletniego już, stażu w zawodzie to:
Jeśli jest do wykonania skończony ciąg operacji oraz
informacja o tych operacjach zapisana jest w pamięci ludzkiej
to
istnieje skończona, stosunkowo mała, liczba powtórzeń ciągu tych operacji, że
przynajmniej jedna z operacji nie zostanie wykonana.

Nazywę tą regułę “Zasadą zapominania”. Dlatego warto zautomatyzować ten proces przy pomocy chociażby narzędzia Phing (jest to php’owy odpowiednik Ant’a).

Możliwe, że niedługo napisze Wam co i jak z tym Phing.

* Nigdy nie wiedziałem dlaczego przechowywanie struktury bazy w repozytorium jest moją obsesją. Widać podświadomie czułem, że kiedyś będę używał Project Build System(s).

Share Button

Działanie 8.1 i 8.2: Dlaczego warto dwa razy się zastanowić zanim się na nie rzucimy

O tej porze roku – prawdziwy urodzaj. Wszyscy razem z wiosną budzą się i piszą projekty o unijne dotacje. Te o których myślę to działania 8.1 i 8.2 – projekty, których osią często jest szeroko rozumiany “system informatyczny”.

W tym artykule chciałbym zwrócić uwagę na ukryte problemy, których możesz nie być świadom pisząc projekt z myślą o tym, żeby po akceptacji zlecić go zewnętrznej firmie budującej systemy informatyczne.

Przede wszystkim specyfika wsparć unijnych wymaga, aby taki system został w (niemal) 100% wyspecyfikowany. To jest wymóg szkodliwy, zakładający że

  • klient dokładnie wie czego mu potrzeba
  • potafi doskonale wyartykuować swoje myśli
  • analityk w lot złapie o co klientowi chodzi i…
  • … idealnie zamodeluje te wymagania

Takie rzeczy możliwe są co najwyżej w przyszłowiowej “erze” (czyt. w reklamie i marketingu). Każdy kto miał styk z wytwarzaniem oprogramowania w stylu wodospadowym (dokładnie takim jaki wymusza UE) wie, że to bardzo rzadko jest możliwe.

Wykorzystując analogię budowlaną, gdyby projektem był dom, to musiałbyś najpierw móc opisać słowami jaki dom potrzebujesz. Nie zamówiłbyś u architekta szkicu (prototypowanie!) bo masz nadzieję, że szkic upchniesz w całym projekcie i zapłaci Ci za niego unia. Wszystko co możesz to powiedzieć co chcesz móc robić w tym domu:
spać, kąpać się, zjeść obiad, zaparkować samochód, oglądnąć telewizję, urządzić przyjęcie.
Czy z czymś takim poszedłbyś do firmy budowlanej, żeby oszacowali koszty zbudowania takiego domu?
Niech masz wstępnego projektu, bo zapłaci za to Unia. Nie masz żadnego szkicu i chcesz do planu dodać jakieś szacowanie, bo Unia wymaga, żeby na samym początku podać kwoty.

Z powyższej listy, można wywnioskować, że potrzebna Ci kuchnia (chcesz jeść), salon (tv + przyjęcie), garaż, sypialnia, łazienka. Doświadczony wykonawca domyśli się, że potrzebujesz też toalety mimo iż na liście “zrobić siku” zapomniałeś umieścić. Ale nie domyśli się, że salon powinien mieć przynajmniej 200m bo przyjęcia chcesz dla 100 osób organizować. Nie wie ile tych sypialni. Czy w ogóle chcesz ogród? Może ogrzewanie? Nie wspomniałeś nic o oknach, ani drzwiach.

Przejdźmy dalej. Kolejną wadą projektów wspieranych przez Unię jest to, że Unia za to płaci. Tym razem będzie analogia zakupowa. Wyobraź sobie, że idziesz do sklepu na zakupy i:

  1. bierzesz 500zł własnej ciężko zarobionej krwawicy
  2. ktoś daje Ci 500zł i to co wydasz to Twoje, czego nie wydasz – musisz oddać

Zagadka: Które zakupy zaowocują zakupem naprawdę potrzebnych rzeczy?
Dokładnie tak samo jest z “systemem informatycznym”. Gdy Ty za niego płacisz – jesteś zainteresowany funkcjonalnościami, które naprawdę zwiększą Twoją wydajność. Gdy płaci Unia – upychasz tam ile się da bo “a nuż się przyda”. Najważniejszym problemem w tym wypadku jest to, że takie upychanie kilkuktornie komplikuje projekt. A to z kolei

  • zwiększa koszt całego projektu (tym się nie przejmujemy, bo unia płaci),
  • implikuje jeszcze mniej dokładne niż “wróżenie z fusów” szacowanie (ryzykujemy obsówę projekty – Unia może nie zapłacić, ale nie przejmujemy się, bo w umowie załączymy kary umowne i wykonawca zapłaci)
  • skutkuje skomplikowanym do wdrożenia systemem, pełnym niepotrzebnych funkcji, który muszą opanować Twoi pracownicy (robi się nieprzyjemnie, bo za to Unia nie zwraca, płacisz tylko Ty)

Dlatego warto się zastanowić, czy zwyczajnie warto. Czy na prawdę chcesz mieć Wielką Kobyłę za 150 tysięcy złotych, pełną niepotrzebnych funkcji, która była robiona w pośpiechu i przez to nikt nie chce nawet zaglądnąć do jej kodu, żeby cokolwiek zmodernizować? Czy chcesz czekać na Wielką Kobyłę za 150 tysięcy półtorej roku i kiedy dostaniesz ją do testów (sic!) wiesz, że otoczenie biznesowe i konkurencja zmieniły się na tyle, że przydało by się mieć juz coś lepszego?

Alternatywą jest system mniejszy. Zawierający 10% funkcjonalności Wielkiej Kobyły. Ale są to te rzeczy, które zwiększają Twoją wydajność (a co za tym idzie konkurencyjność) na przykład trzykrotnie. Może zapłacisz za nie więcej niż 10% ceny Wielkiej Kobyły i z własnej korzyści, ale spójrz na stosunek cena/korzyści. A co jeśli dodam do tego taki bajer:
Po dwóch miesiącach Twoi pracownicy uzywają systemu. Oni stają się specjalistami w zakresie jego obsługi i mogą współpracować przy jego rozwoju. Na pewno będą miec świetne pomysły, aby nieco ulepszyć działanie programu znów poważnie zwiększając swoją wygodę (wydajność!) pracy.
Przypomnij sobie ile razy używając Standardowego Programu (MsExcell, Outlook, Firefox etc.) miałeś poczucie “Kurcze, gdyby zmienić tutaj to i to, to bym się mniej naklikał przy tych codziennych … (raportach, analizach, wstaw cokolwiek)”.

To są rzeczy, których nie przewidzisz projektując Wielką Kobyłę.

Dlatego zamiast liczyć złotówki (150tys.) których nie musiałeś wydawać, policz korzyści których nie udało Ci się osiągnąć. Wiem, że to boli bardziej i nie jest takie proste. Nie mam pojęcia czy Twoja księgowa to potrafi ;).

Możesz też spróbować odpowiedziec na pytanie: Czy na przyjęciu/konferencji/piwku z ludźmi z branży wolisz:
a\ Opowiedzieć o tym jak to ostatnio wdrożyliście Customer Relationship Management Entenrprise Edition (nazwa kodowa Wielka Kobyła) za 150 tysięcy złotych, podciągnąć spodnie, odchrząknąć, a potem obwąchać pobliską latarnię i zaznaczyć swoje terytorium*
b\ Pochwalić się jak udało Wam się zwiększyć wydajność jednego z działów trzykrotnie za mniej niż miesięczną pensję dla tego działu. Polecić ekipę, z którą naprawdę dobrze się Wam pracowało. Następnie wrócić tego wieczoru do domu z długonogą menadżerką (ew. wspaniale umięśnionym, przystojnym menadżerem) spragnioną szczegółów na temat tego projektu.

Na zakończenie: pamiętaj, że ekonomia to coś więcej niż rachunkowość. Więc przestań liczyć tylko dutki na koncie.

(*)wiem, odpowiedzi są tendencyjne, ale to nie jest nielegalne ;)

Share Button