Przykłady
Na ostatnim spotkaniu ze studentami padły prośby o dobre źródła przykładów dla UML i PHP.
Na początek przypominam poprzednie moje wpisy: Modelowanie (lista zasobów o UML na końcu, linki nadal aktywne) i Konfiguracja środowiska deweloperskiego (z listą podręczników do PHP).
Dodatkowe zasoby:
Agile a organizacja światowej informacji
Uczestniczyłem kilka dni temu w spotkaniu pod tytułem (mniej więcej) “jak to robimy w Googlu”, zorganizowane przez Kraków GTUG.
Petra Cross opowiadała o tym w jaki sposób zorganizowana jest produkcja oprogramowania w Google. Opowiadanie było z perspektywy tech-leada małego zespołu (pracującego prawdopodobnie przy gmail).
Spróbowałem porównać ciekawostki od Petry z tym jak pracują moje zespoły. Zaznaczam, że mogłem coś przekręcić i całe zestawienie ma charakter poglądowy.
| G | E |
| Stosują podejście agile, zorientowane na samooroganizujące się zespoły | Stosujemy podejście agile, w którym ważną rolę grają zespoły; w założeniu „empowered” i samoorganizujące się |
| Nad zespołem jest tylko product manager (odpowiedzialny za to co ma być zrobione) i manager zarządzający zasobami; całość wygląda bardzo anarchistycznie, ale wszystkim rządzi potrzeba biznesowa | Zespół podlega kilku managerom. Staramy się ograniczyć inwazyjność ich działań. |
| Zespół rozwija jeden produkt na raz; może być kilku product managerów wrzucających zagadnienia dla zespołu | Zespół zajmuje się rozwijaniem i utrzymaniem kilkunastu różnych produktów (na jednej platformie). Na raz dzieje się 1-3 projektów, w których 1-6 ludzi definiuje co mamy wykonywać. |
| Zespoły deklarują się czy używają Scrum czy Kanban, ale też sa w tym bardzo nieortodoksyjni i definiują własne podejście | Przyjęliśmy określać to robimy jako Scrum. I jest to całkiem dobre przybliżenie. Trudno jednak ukryć, że mają miejsce niedociągnięcia, a ktoś może stwierdzić, że nawet odstępstwa. |
| Zespoły są w miarę stałe, ale po przepracowaniu (nie mniej niż) 18 miesięcy w zespole, pracownik jest zachęcany do zmiany zespołu | Zespoły w miarę stabilne. W ciągu 10 miesięcy w 2 zespołach: 2 osoby wyszły i 3 osoby przyszły.Pomiędzy zespołami po kilku miesiącach zaczęły się roszady, wywołane sytuacją w projektach. Temat na osobny artykuł. |
| Iteracje trwają 1-2 tygodnie, planning 15-30 minut | 2-tygodniowe iteracje; planning różnej długości, zdarzały się kilkugodzinne, przy starcie nowego projektu |
| Zespoły są 3-5 osobowe | Zespoły 8-osobowe |
| Spotkania codzienne 10-15 minut; tylko jedna osoba mówi na raz | Spotkania codzienne 15 minut; czasem i 3 osoby mówią na raz, a i tak wyrabiamy się w 15 minut; no dobrze, kiedyś byłwało 20 minut |
| Zadania / user stories estymowane są w punktach, w zakresie 1-5 (maksymalnie 8 ) | Zadania estymowane w godzinach, user stores estymowane czasem w punktach czasem w godzinach. |
| Praca z domu jest możliwa, ale od zespołu wymagane jest, żeby spędzali codziennie w biurze trochę czasu razem | Praca w stałych godzinach, praca z domu w wyjątkowych przypadkach |
| Team velocity używane przez product managera (zupełnie w niezrozumiały dla mnie sposób) do oceniania jak szybko dany feature zostanie zrobiony przez zespół | Commitment-based planning. Na podstawie wyceny i oceny sytuacji, zespół deklaruje ile jest w stanie wypracować podczas sprintu. |
| Stosują ciągłą integrację (monitor widoczny dla wszystkich, z zielonym lub czerwonym paskiem) | Ciągła integracja under development. |
| Stosują promiscuous pairing – codzienie zmienianie par | Pairing sporadyczny, „swarming” gdy trzeba rozwiązać jakiś problem |
| Stosują rotację części obowiązków związanych z obsługą zespołu; tech-lead pośredniczy w komunikacji z innymi zespołami | Obsługa zespołu wykonywana przez jedną osobę (mnie). Komunikacja w projekcie realizowana na zasadzie odpowiedniości. Deweloper z deweloperem. Manager z managerem. |
| Retrospekcje robią raz na miesiąc, albo rzadziej; retrospekcja trwa 1 godzinę. | Retrospekcja na koniec sprintu. 1 godzina wystarcza. |
| Zawsze z backlogu brany jest task o najwyższym priorytecie, bez względu na to czy deweloper ma jakiekolwiek w nim doświadczenie; jeżeli nie ma, to się uczy | Często przemyka się przebieranie w taskach. Zadania biorą osoby, które wykonają zadanie najszybciej/najlepiej. Sytuacja zmienia się tak często, że nikt nie może wykonywać tylko jednego typu zadań. |
| Obowiązkowy jest code review – używają jakichś własnych narzędzi wspomagających | Przeglądy kodu nie są obowiązkowe, ale są zwykle wykonywane. |
| Stosują planning poker | Nie na każdym planningu, ale zwykle na początkowych w każdym projekcie. |
Jak testujesz swoje aplikacje?
Załóżmy, że spotkałem siebie sprzed kilku lat. Jednym z wielu pomysłów który chciałbym sobie “sprzedać”, jest ten, który poniżej opiszę. Wiem, że nie wystarczy przekonywać mnie do jakiegoś rozwiązania, lecz trzeba sprawić żebym sam doszedł do właściwego wniosku. Zacząłbym tak:
Ja: Jak testujesz swój system?
Ja2006: Mamy dosyć rozbudowane środowisko do testu. Poszczególne elementy sieci operatora telekomunikacyjnego są w nim dostępne. Na przykład mamy bazy danych o strukturze dokładnie takiej jak w środowisku docelowym. Pozostałe elementy są symulowane przez różne narzędzia.
Ja: Czy testujesz poszczególne komponenty oddzielnie?
Ja2006: Charging udało nam się wydzielić i jest testowany oddzielnie. Przy pozostałych komponentach jest zbyt wiele zależności. Nie zawsze ładujemy wszystkie komponenty na raz, żeby zaoszczędzić czas.
Ja: A co ze scenariuszami wyjątkowymi?
Ja2006: Wtedy gdy dostajemy nieprawidłowy komunikat lub zostaje przekroczony czas oczekiwania? Albo słynne wyciąganie wtyczki? Z tym jest problem. Część scenariuszy udaje nam się zasymulować, ale na pewno nie wszystkie.
Ja: Jak długo trwa sprawdzenie ostatnio wprowadzonej zmiany?
Ja2006: Od kilku do kilkunastu minut. W przypadku trudnych scenariuszy, czasem dłużej. Dobrze było by to trochę przyspieszyć, ale nikomu to nie przeszkadza.
Ja: Automatyczna regresja?
Ja2006: W strefie marzeń. Część scenariuszy testowych jest wykonywanych automatycznie, ale duża część wymaga sprawdzenia logów z kilku symulatorów…
Ja: Co z testami jednostkowymi?
Ja2006: Jak najbardziej. Mamy jednak problem z ilością zależności. Framework’i, których używamy, są zbudowane w sposób tak niezorientowany na testowalność. Wydaje się, że nigdy nie widziały rozwoju aplikacji większej niż demo…
Ja: Rozczulasz się nad własnym lenistwem. Potrafisz wyciąć komponent z otoczenia?
Ja2006: No radzę sobie. Trochę kombinowania z ClassLoader‘em, właściwie wystarczy odpowiednio spreparować Classpath i po kłopocie. No trzeba jeszcze napisać te wszystkie stuby.
Ja: Posiedzisz jeszcze z ludźmi, którzy na co dzień używają asemblera, to docenisz, że możesz pracować w technologii z taką ilością ułatwień. Po kłopocie nie jest, ale poćwiczysz Mockito i powermock. Będzie o wiele prościej.
Ja2006: A co z TestNG i aspektami?
Ja: Myślisz, że z tym co pokazałem pójdzie łatwo? Lepiej skup się na tym co chcesz zmienić. Może, gdy reszta branży rzuci się na interfejsy sterowane falami mózgowymi…
Ja2006: Czas uruchomienia testu nie jest dobry. Z przyzwyczajenia godzimy się z tym. Ale gdyby nie trzeba było wykonywać tego całego osadzania na platformie. Jeżeli da się poszczególne komponenty testować oddzielnie, to pozostaną “tylko” problemy z integracją, które też będzie łatwiej zlokalizować. Dla testów uruchamianych w jednej maszynie wirtualnej nie będzie problemów z synchronizacją symulatorów i zbieraniem wyników testu. Wtedy też użycie Cobertura, czy też eclEmma będzie miało sens.
Ja: Dodaj do tego Hudson, Maven i Sonar.
Ja2006: Ale jak przekonać współpracowników?
Ja: Wiesz, że przekona ich tylko działający przykład. A najlepiej rozwiązanie, które niewiele zmieni ich przyzwyczajenia. Pozostaje jeszcze zmanipulowanie najmłodszych współpracowników, którzy nie wpadli jeszcze w rutynę. Wystarczy zarazić ich swoją wiarą.
Ja2006: Ale to wszystko ma sens i zadziała?
Ja: Oczywiście.
Nietechnicznie na GeeCON
W ubiegłym tygodniu miałem przyjemność uczestniczyć w GeeCON. Z założenia konferencja skoncentrowana na nowinkach technicznych wokół Java, przyniosła mi też dużo ciekawych tematów związanych ogólnie z pracą przy tworzeniu oprogramowania.
Prezentowanych zagadnień było mnóstwo, do tego często równolegle w kilku salach. Mogę zaproponować jako skuteczny mój sposób wyboru prezentacji w takiej sytuacji: 1. odrzucam wszystkie, które zawierają w tytule nazwę technologii, której nie używałem; 2. wybieram prelegenta, który najprawdopodobniej na co dzień komunikuje się po angielsku.
Blackbelt rewitalizacja
Prawie trzy lata temu trafiłem na stronę, której koncept niezmiernie przypadł mi do gustu. Do tego stopnia, że zastanawiałem się nad stworzeniem bardziej specjalizowanej wersji, do wiedzy której nie można z różnych względów publicznie udostępnić. To, że BlackBeltFactory (aka JavaBlackBelt v4) tak się rozwinęło, bardzo mnie cieszy. Nawet nieuchronna komercjalizacja wygląda rozsądnie i również jest czynnikiem wspierającym rozwój pomysłu.
Sam portal przysłuży mi się przy szkoleniach, które przygotowuję. Będę przekierowywać na niego osoby, które zechcą się pochwalić swoją wiedzą zdobytą w jednym z powszechnie uznanych tematów (Java na początek). Ambitnie zakładam, że zdołam też wymyślić jakieś ciekawe pytanie w tematach którymi się interesuję. Na początek zostałem sprowadzony do parteru przez wyniki testów z tematów, które uważałem za dobrze mi znane. Niestety automat nie reaguje na argumenty w rodzaju “znajomość tego szczegółu nie jest niezbędna”, “powinniśmy dążyć do rozwiązania win-win”, … Trzeba będzie przysiąść na fałdkach, a przede wszystkim zrewidować swoją wiedzę pod kątem tego co mogę zaoferować. Pożyteczne ćwiczenie.
Moim kolegom udało się zrealizować podobny pomysł na przekazywanie wiedzy, jestem pełen podziwu: majca.pl działa i pomaga radzić sobie z matematyką.
Mindmapping
Od dłuższego czasu rysuję często mapy myśli. Daleko mi do używania technik opisywanych w podręcznikach wideo publikowanych rzez prawie każdego producenta narzędzi wspomagających. Rysuję tylko gdy używam komputera w dosyć prostym programie FreeMind. Do tego notorycznie porzucam swoje mapy gdy tylko zaczynają być zbyt skomplikowane lub zaczynam zajmować się nowym tematem. Wspominam o porzucaniu, gdyż spotkałem się również z podejściem ładowania nowych tematów do jednej wielkiej mapy, którą można by nazwać “mój mózg”.
Najczęściej mapuję notatki, ze spotkań, z wykładów, jeżeli tylko mam przy sobie komputer i temat może rozwinąć się w nieprzewidywalnym kierunku. Ostatnio, przygotowując raport, do którego zbierałem wiadomości od kilkunastu osób, wszystkie informacje zbierałem w jednej mapie. Notowałem na bieżąco rozmowy telefoniczne oraz przepisywałem zapiski z kartek, gdy tylko wracałem ze spotkania.
Istnieją narzędzia do dzielenia się mapami, inaczej niż przez zerkanie przez ramię: mind42 czy mindmeister. Jeszcze się do tego typu współpracy nie przekonałem. Nadal notatkę ze spotkania z mapy przepisuję do bardziej tradycyjnej formy tekstowej “bulletowej”. Zresztą przy tej operacji doprecyzowuję informacje i sumaryczny efekt jest mimo wszystko znacznie bardziej czytelny, nawet dla mnie.
Podsumowując, każdy może używać mapowania myśli zgodnie ze swoim upodobaniem. Ale warto spróbować, jeżeli tylko obserwujesz, że Twoje notatki są zbyt chaotyczne i trudno jest się w nich połapać nawet autorowi.
Ćwiczenie z programowania
Mam dwie propozycje na łączenie przyjemnego z pożytecznym, programowania połączonego z czystą rozrywką. Na początek LightBot – ćwiczenie mózgu w przebijaniu się przez rekursję, wyrażenia warunkowe, czy po prostu scenariusze dłuższe niż 5 kroków.
Dla chcących poduczyć się programowania sterowanego zdarzeniami oraz podstaw Java, wart zainteresowania jest Robocode.
Zarządzanie personelem (1)
Cel wykładu to przedstawienie podstawowych “miękkich” zagadnień, które brane są przy organizacji projektów.
Kto to jest pracownik wiedzy? Dlaczego zarządzanie takimi pracownikami (do których również zaliczają się zarządzający takimi pracownikami itd.) wymaga przyjęcia trochę innych założeń niż w “manufakturowym” systemie? Jeżeli ważną cechą pracownika staje się samodzielność, podejmowanie ryzyka, organizowanie swojej pracy, to zmienia się charakter pracy szefa. Jeżeli szef przewodzi ludziom bardzo inteligentnym i jednocześnie bezczelnie świadomym tego faktu, lepiej od szefa orientujących się w wielu zagadnieniach, to powinien postarać się o nowe źródła autorytetu.
Wyraźną tendencją w rozwoju pracowników jest generalizacja. Najlepiej w formie generalizującego specjalisty, który ma swoją główną domenę, w której stara się osiągnąć najwięcej (lub od której dawno temu zaczął), lecz usilnie poznaje domeny sąsiednie.
Gdy ludzie “techniczni” uczą się zarządzania, analizy biznesowej, w jakim kierunku rozwija się kadra zarządzająca? Wiele spraw zmienia się. Wielu managerów stosuje to od dawna, dla innych jest to trudna do przebycia bariera. Trzeba nauczyć się pozwolić innym osiągać rezultaty, wspierać ich jak najlepiej, zaspokajając potrzeby (w tym potrzeby bezpieczeństwa, szacunku, docenienia). Czasem wskazywać kierunek. Ale należy oduczyć się prowadzenia za rękę.
Cel jest dosyć oczywisty. Zmotywowani i samodzielni pracownicy, pomimo tego, że doprowadzenie ich do takiego stanu jest kosztowne, pracują wielokrotnie wydajniej od wyrobników. Nie jest jednak konieczne budowanie “supergrup”, składających się z wyczynowo wydajnych ludzi. O wiele tańsze jest budowanie zespołów wokół zmotywowanych pracowników.
Można śmiało stwierdzić, że 80% efektów pracy firmy jest osiągane dzięki wynikom pracy 20% pracowników. Jednak wyciąganie wniosku, że można sporo w firmie zaoszczędzić, jest pochopne. Przede wszystkim nie jest pewne którzy pracownicy stanowią te 20%. Najprawdopodobniej również te 20% nie mogłoby pracować wydajnie i długo, gdyby nie pomoc ich otoczenia. Bazując na tej samej zasadzie można stwierdzić, że 80% roszczeń i problemów jest generowane przez 20% pracowników. Pokuszę się o twierdzenie, że te dwudziestki pokrywają się w dużym zakresie. Co stanie się, jeżeli zbudujemy zespół superwydajnych pracowników? Zagęścimy problemy, zmniejszając szanse na ich wczesne rozładowanie.
Jeżeli ludzie w zespole wzajemnie się uzupełniają, rekompensują swoje braki i wzmacniają zalety, to może warto dobierać ludzi według klucza. Wystarczy znaleźć i zdefiniować odpowiedni klucz. Na podstawie teorii Junga, Myers i Briggs opisały typy osobowości, podzielone na 4 grupy zawierające biegunowe zachowania:
Extraversion – Introversion
Sensing – iNtuition
Thinking – Feeling
Judgment – Perception
Żadna grupa ani biegun nie mają zabarwienia negatywnego czy pozytywnego. Po prostu są obserwowalne i jednym odpowiadają, a innym nie. Pewne profile osobowości mają lepsze predyspozycje do wykonywania określonych zadań.
Pytanie czy jest z tego konkretny pożytek? Cóż, jako osoba o mocno zarysowanym biegunie “P”, pomimo tego że nie przywieszam etykietek łatwo i szybko, to jednak miałbym spory problem rezygnując z “labelkowania” ludzi. Z samoobserwacji wnoszę, że nawet po tylko pobieżnym zapoznaniu się z teorią, zwiększyła mi się tolerancja na typy osobowości niekompatybilne z moim, zwłaszcza te z “J”.
Problem w tym, że jeden klucz doboru, nawet dobry, nie wystarcza. Trzeba wziąć pod uwagę zakres kompetencji, który powinien pokrywać zespół. Poza tym nie zawsze ma się wiele możliwości manewru. Uczenie się tolerancji na innych jest zdecydowanie najefektywniejsze.
Interesujące miejsca w sieci:
- Test osobowości zgodnie z MBTI
- Enneagram, inne podejście do oceny
Przykładowa specyfikacja wymagań
Na blogu O wymaganiach wygrzebałem post zawierający przykładową specyfikację wymagań, podobną do tej, która jest wymagana do zaliczenia przedmiotu. Materiał jest świetny, szkoda że nie zwróciłem na niego uwagi wcześniej.
Testowanie (1)
Cel wykładu to przedstawienie zagadnień związanych z weryfikacją oraz tego do czego testowanie oprogramowania może się przydać poza końcowym zaliczeniem pracy.
Testowanie to zasadniczo porównanie jakiegoś stanu ze wzorcem. Pozwala to nam:
- uzyskać potwierdzenie zgodności z wymaganiami
- stwierdzić, że ostatnie zmiany nie wprowadziły błędu
testując często, mamy lepszą kontrolę nad zmianami, które są mniejsze - potwierdzić, że wcześniej występujący błąd został usunięty
żeby mieć pewność, że znów nie wystąpi, wystarczy dodać dobry test - sprawdzić nowe pomysły
testami można rozpoznawać temat, który nas interesuje
Testy to zbiór przypadków w których określamy warunki początkowe i końcowe oraz scenariusz postępowania. Mogą zostać zapisane w formie dokumentów (instrukcje testu, przypadki testu) albo programów, które wysyłają do testowanego programu dane wejściowe i odbierają wyniki.
Testy zapisane w formie dokumentów zwykle muszą być wykonane z udziałem człowieka, lecz te “oprogramowane” mogą być zwykle wykonane automatycznie, zaoszczędzając dużo czasu testerom. W naszym nieidealnym świecie trzeba niestety najpierw sporo się napracować i poświęcić czas zanim czas będzie można zaoszczędzić. Zbiór testów, które są stabilne, mogą być wykonywane automatycznie, stosuje się w ramach testów regresyjnych.
Jako test można określić również aktywności związane z weryfikacją dokumentów, kodu, modelu, interfejsu użytkownika. Inspekcje są często wspierane przez listy kontrolne, które określają kryteria zatwierdzenia dokumentu.
Czasem debugowanie jest mylone z testowaniem. Debugowanie występuje gdy błąd już wystąpił i szukamy źródła, testowanie może pomóc uniknąć błędu, oraz bardziej precyzyjnie pozwala na wskazanie źródła. Debugowania nie da się uniknąć, ale zapominanie o rozwijaniu porządnej strategii testów odbija się mocno w dłuższej perspektywie.
Testowanie pojawia się na różnych etapach tworzenia oprogramowania. W modelu wodospadowym weryfikacja pojawia się pod koniec pracy. Nie znaczy to oczywiście, że wcześniej nie ma testowania. Są wykonywane przeglądy oraz testy pojedynczych fragmentów. Jednak osiągnięcie przeglądu wyników, rzeczywistego stanu systemu, jest możliwe dopiero w końcowej fazie.
Modele iteracyjne i inkrementalne, takie jak Agile Unified Process, wprowadzają jak największy zakres testów jak najwcześniej. Gdy możemy zobaczyć pojedynczy scenariusz przechodzący przez cały system, możemy z dużym prawdopodobieństwem prawidłowo ocenić czy zmierzamy w dobrym kierunku. Zwykle dopiero testy end-to-end pokazują klientowi wytworzenie interesującej dla niego wartości.
Im wcześniej i im większy zakres testów uda nam się uruchomić, tym:
- szybciej i taniej poprawimy błędy po zmianach:
osoba, która wprowadziła zmianę jest dostępna
zakres ostatniej zmiany nie jest duży
nie zostały wprowadzone błędy wywołane poprzednim błędem - wcześniej możemy przedstawić wyniki klientowi, prezentując rzeczywisty postęp prac
Większy zakres i większa szczegółowość testu nie jest za darmo. Niestety (dla użytkownika końcowego) trzeba ostrożnie balansować pomiędzy dokładnością, czasem i kosztem testów. Wszelkie metody (również oparte o teorię grafów) zapewniające, że zostanie przetestowane to co powinno być przetestowane i nic poza tym, znajdują zastosowanie przekładające się na duże zyski dla przemysłu.
Podsumowując, dobre testy:
- znajdują błędy
- pozwalają na wykrycie błędów jak najwcześniej
- są proste
- są tanie w utrzymaniu
- można je wykonywać często
