O technologii i biznesie naszym zdaniem
Archive for luty, 2010
We begin to see a rainbow. But will there be the treasure?
lutego 22nd
There are views, nice views. Views of growth, prosperity, success. Still a lot to do – but what’s been done, is going now in the right direction. Not only the number of projects is rising – but the number of our own developers as well. It’s just like in a nature – the better soil, the better plants – but also bigger crops so more hands are needed.
After quite successful beginning of this year we had another office party – it helps us not to forget where we work 
Simply a statement from our marketing materials which says “Members of Espeo are its greatest value” it’s totally true! And what was this time? A mysterious place in deep woods with classical tenpin bowling facilities – it was truly something! None of us was experienced in it – so it was seriously challenging for every member of our crew. How astonishing emotions were there, you couldn’t simply imagine.
Leading was changing every single minute, every point counted, every move was… a crap 
There were some moves worth seeing, but basically – we were poor. Especially… me, to be honest. At first it wasn’t going so badly – but as the time passed by, so did our “talent”. Nonetheless there were winners – however I wasn’t among them.
We really enjoyed it. And we enjoy what’s going on around us. A temperature is rising, a sun is less and less timidly showing behind the clouds and our company is growing thanks to proper watering. After the raining times there is a rainbow on the sky. Now let’s find the rainbow treasure!
Zwinny projekt okiem programisty.
lutego 12th
Czym jest Agile dla programisty? Co zmienia zastosowanie zwinnego podejścia w porównaniu z klasycznym waterfall?
Klasyka
Mam za sobą kilka większych lub mniejszych projektów realizowanych klasycznie. Obserwowałem pracę programistów z różnych perspektyw. Ciekawa jest tu obserwacja jak zmienia się nastawienie pojedynczych ludzi, jak i całych zespołów do realizacji projektu. Człowiek potrafi zaadaptować się niezwykle szybko do środowiska w jakim przebywa…
W klasycznym podejściu rola programisty ogranicza się w zasadzie do ‘klepania kodu’. Powszechnie przy tym narzeka się na analityków, projektantów, a także testerów. Często nie dostrzega się klienta, czy nawet celów projektu, poza należną premią oczywiście 
Jak wygląda (w uproszczeniu oczywiście) klasyczny warterfall
Miejsce programisty jest w zasadzie tylko przy etapie ‘kodowanie’. Jego rolą jest naklepanie treści do tego co wymyślił projektant… i przekazanie następnie do testera – z nadzieją aby ten nie wykrył tych drobnych obejść, które często wynikały z nieścisłego gdzieniegdzie projektu. W końcu po co zawracać sobie tym głowę – projektant widocznie tak chciał to ma.
Do takiej roli bardzo dobrze przygotowują wszelkie uczelnie. Po prostu trzeba doskonale znać narzędzia i język w którym się koduje. Działamy jak algorytm – na wejściu analiza, na wyjście dajemy działający kod. Nie ma znaczenia co gdzieś daleko za nami chciał klient, ani czego oczekuje po wdrożeniu. Jesteśmy tylko połączeniem projektanta z testerem.
Czasami rzeczywistość zaskakuje nas jak drogowców zimą Faza analizy się przedłuża i nie ma czasu na projekt Wówczas implementujemy często wynik analizy bez projektu… Jeśli przedłużyła się analiza – znaczy, że dziedzina jest trudna, pewnie implementacja też się przedłuży, więc może faza testów też jest niepotrzebna? Najważniejsze jest przecież wdrożenie… Tego chce klient (a może nie?).
W takich projektach Project Manager ma niełatwe zadanie. Ślęczy nocami nad znienawidzonym M$ Projectem, aby zgrać wszystkie etapy. Każdy próbuje zwalić winę na innego… To już temat na zupełnie osobny artykuł…
Programista podejmuje decyzje jedynie na temat tego czy użyć pętli while czy może lepiej for. Całą resztę zrzuca na projektanta lub PMa.
Agile
Jak wygląda zwinny proces rozwoju oprogramowania z punktu widzenia programisty?
Uproszczony schemat Agile
Tutaj idziemy przez całość zagadnień małymi kroczkami. Za każdym razem wykonujemy analizę, projekt implementację i integrację z całością. Za każdym razem dostajemy informację zwrotną od klienta czy to co zrobiliśmy to jest to czego oczekuje. Klient dostaje gotowe fragmenty, które może używać. Sam decyduje które fragmenty chce najszybciej.
A co robi teraz programista? Otóż niestety ma sporo więcej pracy. Przejmuje po części role analityka, projektanta, testera i wdrożeniowca… Niestety ma więcej pracy i odpowiedzialności. Ale myślę że praca ta jest dużo ciekawsza i posiada dużo większe możliwości rozwoju.
Niestety jednak, tutaj napotykamy problem. Większość absolwentów kierunków informatycznych nie jest dobrze przygotowana do przejęcia tych wszystkich ról. Nie wystarczy więc powiedzieć – od dziś pracujemy w agile. Trzeba nieustannie podnosić kwalifikacje pracowników.
Poszczególne fazy, z racji tego że nie są one w pełni formalnie osadzone, różnią się też sporo od tych znanych z podejścia klasycznego. Nie powstaje zwykle jakiś spójny dokument zwany analizą, czy projektem, który jest normalnie akceptowany i odbierany przez klienta. Za to klient akceptuje gotowa działające kawałki. Wydaje się, że ma to głębszy sens – za abstrakcyjnym dokumentem projektu nie widać zwykle gotowego systemu.
Uczelnie wypuszczają całą masę programistów. To samo w sobie nie jest złe, są oni zwykle doskonali w programowaniu… Jednak spotyka się takich którzy nie słyszeli nigdy akronimu SOLID. Podczas studiów wykonuje się niezliczone ‘projekty’ programistyczne. Niewiele z nich jednak przechodzi przez fazy analizy, projektowania, czy nawet testowania! A te umiejętności wśród programistów są niezbędne aby swobodnie realizować zwinny projekt.
Jest to jedna z trudności (i wyzwań) dla zwinnych zespołów – w klasycznym podejściu każdy ma swoją działkę w której nabywa umiejętności; w agile każdy jest specjalistą od wszystkiego Postaram się dalej pokazać, że to nie taki diabeł straszny jak go malują.