Darmowy fragment publikacji:
IDZ DO
IDZ DO
PRZYK£ADOWY ROZDZIA£
PRZYK£ADOWY ROZDZIA£
SPIS TREœCI
SPIS TREœCI
KATALOG KSI¥¯EK
KATALOG KSI¥¯EK
KATALOG ONLINE
KATALOG ONLINE
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
TWÓJ KOSZYK
TWÓJ KOSZYK
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
CENNIK I INFORMACJE
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
O NOWOœCIACH
O NOWOœCIACH
ZAMÓW CENNIK
ZAMÓW CENNIK
CZYTELNIA
CZYTELNIA
FRAGMENTY KSI¥¯EK ONLINE
FRAGMENTY KSI¥¯EK ONLINE
Sprzedaj swój program.
Droga do udanych
projektów programistycznych
Autorzy: Jared R. Richardson, William A. Gwaltney Jr.
T³umaczenie: Dariusz Biskup
ISBN: 83-246-0408-1
Tytu³ orygina³u: Ship it! A Practical Guide
to Successful Software Projects
Format: B5, stron: 256
Stwórz niezawodne oprogramowanie spe³niaj¹ce oczekiwania u¿ytkowników
(cid:129)Wykorzystuj odpowiednie narzêdzia projektowe.
(cid:129)Wdra¿aj nowoczesne metodologie.
(cid:129)Szybko rozwi¹zuj problemy.
Dyskusje nad wadami i zaletami przeró¿nych metodologii tworzenia oprogramowania,
maj¹ce na celu wy³onienie najlepszej z nich, zwykle do niczego nie prowadz¹.
Zwolennicy poszczególnych metodologii, takich jak Rational Unified Process,
programowanie ekstremalne i inne, staraj¹ siê udowodniæ, ¿e to ich stanowisko jest
poprawnym sposobem realizacji projektów informatycznych. Tymczasem nie istnieje
„jedyne s³uszne” i uniwersalne podejœcie, które sprawdza siê we wszystkich
okolicznoœciach. Wybór w³aœciwej metodologii w ogromnej mierze zale¿y od typu
projektu i wielkoœci zespo³u pracuj¹cego nad nim. Nale¿y kierowaæ siê nastawieniem
czysto pragmatycznym, czyli wybraæ tak¹ metodologiê, która bêdzie najbardziej
korzystna dla okreœlonego projektu. Niew³aœciwy wybór mo¿e skoñczyæ siê pora¿k¹.
Ksi¹¿ka „Sprzedaj swój program. Droga do udanych projektów programistycznych”
to zbiór wskazówek przedstawiaj¹cych narzêdzia i techniki, dziêki którym ka¿dy projekt
programistyczny zakoñczy siê sukcesem. Czytaj¹c j¹, nauczysz siê korzystaæ
z nowoczesnych instrumentów wykorzystywanych do projektowania oprogramowania,
kontroli wersji kodu Ÿród³owego i œledzenia procesu usuwania b³êdów. Dowiesz siê,
w jaki sposób zorganizowaæ pracê zespo³u projektowego i wdra¿aæ metodologiê
wytwarzania oprogramowania. Porady, które znajdziesz w tej ksi¹¿ce, pomog¹ Ci
rozwi¹zaæ problemy pojawiaj¹ce siê podczas realizacji projektów programistycznych.
Poznasz nowoczesne metody oraz dowiesz siê, kiedy i jak z nich korzystaæ.
Wydawnictwo Helion
ul. Koœciuszki 1c
44-100 Gliwice
tel. 032 230 98 63
e-mail: helion@helion.pl
(cid:129)Planowanie infrastruktury
(cid:129)Dobór narzêdzi projektowych
(cid:129)Automatyzacja zadañ
(cid:129)Tworzenie listy zadañ
(cid:129)Rola kierownika technicznego
(cid:129)Metodologia pocisku smugowego
(cid:129)Rozwi¹zywanie problemów
Wskazówki zawarte w tej ksi¹¿ce sprawi¹, ¿e ka¿dy prowadzony przez Ciebie projekt
zakoñczy siê w terminie i zmieœci w wyznaczonym bud¿ecie.
Przedmowa ..............................................................................................7
Wprowadzenie ......................................................................................11
Rozdział 1. Wstęp .................................................................................15
1.1. Nawyk doskonałości ................................................................................. 16
1.2. Pragmatyczny punkt widzenia ................................................................... 18
1.3. Mapa drogowa ......................................................................................... 20
1.4. Jak postępować? ....................................................................................... 23
1.5. Jak czytać tę książkę? ................................................................................ 23
Rozdział 2. Narzędzia i infrastruktura .............................................29
1. Programowanie w piaskownicy .................................................................. 34
2. Zarządzanie zasobami .............................................................................. 37
3. Twórz skrypty kompilacji i konsolidacji ...................................................... 43
4. Kompilacja automatyczna ......................................................................... 49
5. Śledzenie problemów ................................................................................ 55
6. Śledzenie nowych funkcji .......................................................................... 60
7. Uprząż testowa ........................................................................................ 63
8. Wybór narzędzi ........................................................................................ 71
9. Kiedy nie eksperymentować? ..................................................................... 73
4
Sprzedaj swój program
Rozdział 3. Pragmatyczne techniki projektowe ..............................77
10. Praca przy użyciu listy zadań .................................................................... 78
11. Kierownik techniczny ................................................................................ 93
12. Codzienna koordynacja i komunikacja ...................................................... 103
13. Przeglądy kodu ...................................................................................... 116
14. Wysyłanie powiadomień o zmianie kodu .................................................. 128
15. Podsumowanie ....................................................................................... 133
Rozdział 4. Metodologia pocisku smugowego ................................135
Rozdział 5. Popularne problemy i sposoby ich rozwiązania ........165
16. Pomocy! Przejąłem cudzy program .......................................................... 166
17. Testowanie nietestowalnego programu ..................................................... 168
18. Funkcje ciągle mają błędy ....................................................................... 169
19. Testy? Przestaliśmy je wykonywać ........................................................... 171
20. U mnie to działa! ................................................................................... 173
21. Problemy z integracją kodu ..................................................................... 174
22. Problemy z kompilacją i konsolidacją projektu .......................................... 175
23. Klienci są niezadowoleni ......................................................................... 177
24. Masz niezdyscyplinowanego programistę .................................................. 178
25. Twój menedżer jest niezadowolony .......................................................... 183
26. W zespole nie ma współpracy .................................................................. 185
27. Nie potrafię przekonać innych do istotnych kwestii .................................... 186
28. Nowy standard postępowania nie pomógł ................................................. 190
29. W firmie nie wykonuje się automatycznych testów ..................................... 193
30. Niedoświadczeni programiści bez mentora ............................................... 195
31. Projekt — marsz śmierci ......................................................................... 195
32. Ciągle proponowane są nowe funkcje ......................................................... 197
33. Nigdy nie kończymy ............................................................................... 198
Dodatek A Zestawienie wskazówek ................................................203
Dodatek B Zarządzanie kodem źródłowym ....................................207
Dodatek C Narzędzia tworzenia skryptów kompilacji .................213
Spis treści
5
Dodatek D Systemy ciągłej integracji .............................................219
Dodatek E Oprogramowanie do śledzenia problemów .................223
Dodatek F Metodologie programowania .........................................227
Dodatek G Środowiska testowe .......................................................231
Dodatek H Literatura uzupełniająca ..............................................237
Skorowidz ............................................................................................243
Nigdy nie myl działania z postępem.
Autor nieznany
laczego niektórzy produkują oprogramowanie wysokiej jakości
w terminie lub przed terminem, podczas gdy inni (wielu innych,
niestety) spóźniają się, przekraczają budżet lub zupełnie rezygnują?
Istnieje wiele teorii tłumaczących ten stan rzeczy i wiele metodologii pró-
bujących go poprawić. Jednym z fundamentów tych metod jest poprawa
współpracy.
Jeśli nie piszesz swoich programów w garażu, będziesz współpracował z in-
nymi. A nawet jeśli piszesz swój program w domu, płaci Ci za niego Twój
klient. Większość z nas pracuje w ramach zespołu programistów. Pracuje-
my z naszymi kolegami, wspólnie pisząc programy.
Chociaż dobra współpraca nie gwarantuje powodzenia w projekcie, zła
współpraca niemal na pewno oznacza jego niepowodzenie.
współpraca
78
Sprzedaj swój program
W niniejszym rozdziale opiszemy kilka technik pracy grupowej ułatwiają-
cych sprawne i efektywne zarządzanie projektem. Dzięki tym technikom
staniesz się bardziej świadomy stanu swojego projektu, jak również po-
stępów osiąganych przez Twoich współpracowników. Spowodują one, że
Twoja praca stanie się łatwiejsza, efektywniejsza i będzie Ci sprawiać więk-
szą satysfakcję.
Nie istnieje jednolita lista technik poprawiających funkcjonowanie projektu.
Każdy projekt i każdy zespół pracowników jest inny. Sztuką jest uspraw-
nianie zarówno procesu tworzenia oprogramowania, jak i zrozumienie efek-
tywnej pracy grupowej.
Rozwijając swoje umiejętności, zawsze natkniesz się na jakąś sztuczkę,
której nie znałeś, oraz jakiś nawyk, którego powinieneś się pozbyć. Techni-
ki, które tutaj opisujemy, uważamy za najbardziej przydatne. Obejmują
one między innymi:
listę zadań,
t
kierownika technicznego,
t
codzienne spotkania,
t
przeglądy kodu,
t
powiadomienia o zmianie kodu.
t
Być może pamiętacie te wytyczne jako część większego rysunku na stronie 20,
który tutaj pokazany jest we fragmencie (patrz rysunek 3.1).
10. Praca przy użyciu listy zadań
Często do koordynowania własnej pracy używamy list zadań. Lista taka
może być sformalizowana tak, aby mogła być wykorzystywana w pracy
grupowej.
Dawniej, pracując nad mniejszymi projektami, aby koordynować naszą pra-
cę, korzystaliśmy często ze zwykłych notesów. Lista zadań wywodzi się
z naszych osobistych notatek o rzeczach, których nie chcieliśmy zapomnieć.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
79
Rysunek 3.1
Techniki projektowe
Gdy przechodziliśmy na funkcje kierownicze, lista zadań zaczęła zawierać
pozycje dotyczące całego zespołu programistów i wówczas notatki na pa-
pierze stały się nieefektywne. Po wielokrotnym pokazywaniu listy zadań
współpracownikom zaczyna się poszukiwać alternatywnych sposobów jej
zapisywania i udostępniania. Tablica funkcjonuje dobrze dla małych ze-
społów, zwłaszcza w dużym pomieszczeniu. Obecnie staramy się korzystać
ze stron internetowych lub wiki. Niektórzy do tworzenia list zadań wyko-
rzystują arkusze kalkulacyjne1. Każdy ma dostęp do stron internetowych,
a ich edycja jest bardzo łatwa.
Za pomocą listy zadań ustalasz swój dzienny i tygodniowy plan zajęć. Za
jej pomocą porządkujesz pracę swoją i całego zespołu. Jeśli jesteś przytło-
czony pracą, nie wiesz, za co się zabrać, przeglądasz swoją listę zadań,
aby znaleźć punkt zaczepienia. Jeśli utknąłeś przy pracy nad jakimś trud-
nym problemem i chcesz na chwilę zająć się czymś innym, lista zadań
wskazuje Ci pozycje, których możesz użyć jako alternatywnego zajęcia.
W ten sposób będziesz zawsze pracował nad najważniejszymi problemami.
1
Joel Spolsky korzysta z arkusza Excela do edycji swojej listy zadań. Przedstawia również wiele
argumentów za tym rozwiązaniem. Więcej informacji na stronie http://www.joelonsoftware.com/
articles/fog0000000245.html.
80
Sprzedaj swój program
Do czego potrzebna jest lista zadań?
Jak często pracowałeś nad projektem, w którym każdy był zawsze czymś
zajęty, a który nigdy się nie kończył? Ważne funkcje były zapominane,
pracownicy bezczynnie czekali na te, które nie były gotowe, programiści nie
wiedzieli, czym się zająć w dalszej kolejności.
Ktoś musi zapisać wszystkie funkcje, nadać im priorytet i zlecać pracow-
nikom do wykonania zadania znajdujące się na pierwszej pozycji listy za-
dań. Tworzony jest centralny punkt organizacji pracy Twojego zespołu
pozbawiony niedogodności związanych z korzystaniem z bardziej złożo-
nych procedur.
Pracownicy, którzy korzystają z listy zadań, nigdy nie są bezczynni. Kiedy
zakończą swoje aktualne zadanie, sprawdzają listę, wybierają zadanie, któ-
remu przypisano wysoki priorytet, i biorą się do pracy. Programiści mogą
wybrać swoje następne zadanie spośród tych, które są dla nich najbardziej
interesujące, ale kierownik techniczny powinien mieć pewność, że te o naj-
wyższym priorytecie są w toku lub na najwyższej pozycji na liście.
Ponieważ programiści mają różne umiejętności, kierownik techniczny może
zgadzać się na wyjątki, ale zasadniczo pozycje drugorzędne nie powinny
być wykonywane, dopóki nie zostaną zakończone zadania o najwyższym
priorytecie.
Lista zadań (jako narządzie pracy grupowej) daje kierownictwu oraz klien-
tom możliwość oceny produktu przed poniesieniem nakładów na nowe
funkcje. Zawsze taniej jest usunąć nową funkcję, zanim spędzi się tydzień
nad jej programowaniem! Ile razy zdarzyło Ci się skończyć program i usły-
szeć od klienta: „Program jest w porządku, ale byłoby świetnie, jeśli za-
miast funkcji X, Y i Z zostałaby dodana funkcja A”? Przy wykorzystaniu
listy zadań tworzony jest zarys dokumentacji, która może być udostępnia-
na innym we wczesnych fazach rozwoju produktu.
Lista zadań wprowadza również w zespole dużą elastyczność. Zapewnia,
że najpierw wykonane będą pewne prace projektowe, gdyż wymaga podzie-
lenia programu na funkcje, a funkcje na pozycje listy. Ponadto, ponieważ
program jest podzielony na funkcje, możliwe jest w razie potrzeby usuwa-
nie lub dodawanie nowych pozycji.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
81
Jaś pyta...
Co to jest wiki?
Wiki jest to prosta metoda tworzenia stron internetowych. Stro-
ny internetowe są pisane w uproszczony sposób tak, aby każdy
mógł modyfikować ich zawartość. Strony wiki zaprojektowane są
w sposób zachęcający do szerokiej współpracy.
Strona typu wiki wygląda na początku dokładnie jak każda inna.
Różnica polega na tym, że istnieje na niej odsyłacz „Edycja stro-
ny”. Kliknięcie go powoduje wyświetlenie prostego edytora tek-
stowego pozwalającego na bardzo łatwe modyfikowanie strony.
Więcej informacji na stronie http://pl.wikipedia.org/.
82
Sprzedaj swój program
W każdej firmie znajdzie się osoba (lub osoby), która ma w zwyczaju
wpadać niespodziewanie i pytać, dlaczego pewna funkcja nie jest jeszcze
zakończona albo dlaczego nikt nad nią nie pracuje (z jej punktu widzenia
najważniejsza jest ta funkcja, na której jej zależy). Mając zdefiniowany ze-
staw zadań, którym przypisane są priorytety, można jej pokazać, nad jakimi
funkcjami trwają prace i dlaczego są one najważniejsze. Takie wyjaśnienie
z reguły zadowala taką osobę i udowadnia, że wykonywana jest użytecz-
na praca.
Pełna lista funkcji z przypisanymi sensownie priorytetami zwiększa wza-
jemne zaufanie w zespole, kierownictwie i innych grupach, które mogą być
zależne od naszych funkcji. Posiadanie listy zadań pokazuje, że praca wy-
konywana jest w sposób zaplanowany.
WSKAZÓWKA 14
Pracuj z listą zadań
Jak korzystać z listy zadań?
Listy zadań możesz używać w pracy własnej lub całego zespołu. Obydwa
sposoby są łatwe i efektywne. My korzystamy z niej na oba te sposoby.
Rozpoczęcie korzystania z osobistej listy zadań jest łatwe. Najpierw nale-
ży utworzyć listę wszystkich zadań, nad którymi pracujesz (lub które na
Ciebie czekają). Następnie przy pomocy kierownika technicznego nadaj
wszystkim pozycjom priorytety. Na koniec oszacuj czas potrzebny na zre-
alizowanie każdej pozycji. Nie przejmuj się, jeśli na początku oszacowanie
okaże się nietrafne, z czasem się poprawisz.
Wprowadzenie grupowej listy zadań również nie jest trudne, jeżeli pro-
dukt jest dobrze zdefiniowany. Pozwoli ona całemu zespołowi zrozumieć
ogólny kierunek, w jakim zmierza projekt.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
83
Lista zadań jako narzędzie organizacyjne
W naszej pracy zawodowej pełniliśmy wiele różnych ról. Z reguły,
jak większość ludzi, mieliśmy jednocześnie do wykonania wiele
zadań i bardzo mało czasu na ich realizację. Kiedy próbujemy za-
planować sobie pracę nad tymi projektami, na ogół dzielimy swój
czas pomiędzy tak wiele zadań, że nie udaje nam się osiągnąć
żadnego znaczącego postępu.
Naszym rozwiązaniem jest wykorzystanie listy zadań również do
organizacji własnej pracy. Zawsze używamy grupowej listy zadań
dla całego zespołu, stwierdziliśmy, że posiadanie własnej kopii
zawierającej, co mamy do zrobienia, również jest bardzo pomocne.
Każdego ranka zrób listę czekających Cię zadań i nadaj im prio-
rytety. Na koniec dnia przejrzyj, co udało Ci się z niej wykonać,
a czego nie. Oceń, czy nie udało Ci się wszystkiego wykonać, po-
nieważ byłeś zbytnim optymistą, czy też coś w ciągu dnia ode-
rwało Cię od wykonywania zaplanowanych zadań. Pełniejsze omó-
wienie sposobów posługiwania się własną listą zadań można
znaleźć w książce Stephena Coveya „Siedem nawyków skutecz-
nego działania”.
1.
Zapisz na tablicy każdą funkcję, którą dodajesz do projektu.
Może to zająć chwilę i często może się okazać, że jedna tablica
nie wystarczy.
2.
Każdej funkcji nadaj priorytet. Uwzględniaj zdanie odpowiednich
osób (kierownictwa, klientów itd.). Idealnie jest, jeśli uczestniczy
w tym cały zespół, ale jeśli rzetelnie zebrałeś opinie pracowników,
wygodniejsze może być uwzględnienie tylko kierownictwa.
Przepisz wszystkie funkcje w kolejności nadanych priorytetów.
3.
Dołącz do każdej pozycji prognozowany czas wykonania.
4.
Dopóki nie zostaną zakończone pozycje o najwyższym priorytecie, nikomu
nie wolno pracować nad tymi o niższym priorytecie. W ten sposób wszystkie
najważniejsze zadania są w toku, zanim rozpoczęte zostanie wykonywanie
tych o niższym priorytecie.
84
Sprzedaj swój program
Rysunek 3.2
Lista zadań na stronie intranetowej
Korzystanie z listy zadań jest więc stosunkowo łatwe. Aby jednak zachować
efektywność, lista zadań musi spełniać kilka zasad. Musi ona:
Być ogólnie dostępna.
t
Mieć przypisane priorytety.
t
Mieć prognozy czasu wykonania.
t
Być dynamiczna.
t
Być wymierna.
t
Być ukierunkowana.
t
Przyjrzymy się teraz, jakie jest znaczenie każdej z tych reguł i co one ozna-
czają dla nas oraz dla naszego zespołu.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
85
Jaś pyta...
Co to są kanały RSS?
Kanały RSS są sposobem powiadamiania o zmianach zawartości
strony internetowej. Są bardzo popularne na stronach o często
zmienianej treści (na przykład serwisy informacyjne lub strona in-
formująca o statusie kompilacji). Strona internetowa z obsługą
kanałów RSS generuje listę zmian lub nowych treści w postaci
pliku XML.
Czytnik RSS jest to program, który sprawdza wszystkie zaprenume-
rowane kanały RSS i pokazuje nowe treści. Generatory RSS umiesz-
czone są na serwerach WWW, a więc czytnik RSS jedynie sprawdza
plik znajdujący się na serwerze i pokazuje zmiany.
Czytnik RSS jest wygodnym narzędziem gromadzenia informacji
w zwięzłej formie. Wiadomości są zbierane, aż użytkownik zechce
je odczytać.
Ogólnie dostępna
Lista zadań zespołu musi być ogólnie dostępna. Tajna lista nie ułatwia
współpracy. Umieść listę zadań na tablicy lub na stronie internetowej,
utwórz dla niej kanał RSS. W każdym przypadku powinno być możliwe
łatwe jej przeczytanie. Posiadanie listy zadań przed oczami ułatwia zacho-
wanie perspektywy. Daje ona przegląd niewykonanych zadań, który można
łatwo prześledzić — zwłaszcza kiedy wykonuje się kilka zadań jednocze-
śnie. Jej publiczna dostępność pozwala również na orientację kierownictwa
w bieżących działaniach.
Przypisane priorytety
Lista zadań musi mieć nadane priorytety. Bardzo ważne jest rozpoznanie
różnych rodzajów funkcji związanych z projektem: funkcji niezbędnych, po-
żądanych i nieistotnych. Musisz dokonać tych rozróżnień, przypisując prio-
rytety pozycjom listy — w przeciwnym wypadku tylko stracisz czas. Zawsze
86
Sprzedaj swój program
istnieje zestaw podstawowych funkcji, które muszą być zrealizowane, zanim
produkt trafi do sprzedaży; są to funkcje o najwyższym priorytecie. Mogłyby
one obejmować na przykład ekran logowania, instalator lub bazę danych.
Produkt nie może po prostu bez nich działać. Ładniejszy kolor tła w oknie
dialogowym O programie… prawdopodobnie można uznać za zadanie
nieistotne.
Nigdy nie ignoruj nadanych priorytetów. Zakończ wszystkie zadania o wyż-
szym priorytecie, zanim zaczniesz pracę nad mniej ważnymi, chyba że ist-
nieje istotny — i przekazany wszystkim — powód, aby tymczasowo zawiesić
zadanie z wysokim priorytetem.
Rysunek 3.3
Czytnik kanałów RSS
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
87
Prognozy czasu wykonania
Do listy zadań zawsze powinien być przypisany harmonogram. Nie musi
być on nienaruszalny, ale powinien zawierać prognozę czasu wykonania dla
każdej funkcji zawartej na liście. Po zrealizowaniu pozycji i rejestracji jej
rzeczywistego czasu wykonania, należy zwrócić uwagę na różnice.
Z czasem prognozy czasu wykonania będą się stawać coraz bardziej do-
kładne. Po kilku próbach kierownik techniczny powinien być w stanie two-
rzyć przybliżone harmonogramy projektów na podstawie list zadań poszcze-
gólnych członków zespołu. Podobnie powinno być w przypadku kierownika
projektu. Nie istnieją błędne prognozy. Jedne będą dokładniejsze, inne mniej.
Nie martw się, jeśli na początku popełnisz duży błąd. Tej umiejętności na-
biera się z czasem2.
Dynamiczna
Lista zadań, jeśli ma być efektywna, musi być dynamiczna. Zespół musi
być w stanie dostosowywać się do zmian. Kierownik techniczny będzie ko-
rygował priorytety funkcji; będą pojawiały się nowe funkcje, a inne będą
znikały. Priorytety zmieniają się. I tak powinno być! Zanim się do tego
przyzwyczaisz, może być to frustrujące, ale pamiętaj, że Twoja firma stara
się być konkurencyjna na zmieniającym się rynku. Również Ty musisz być
elastyczny. Zamiast z tym walczyć, staraj się to zaakceptować.
Zmiany listy zadań zwykle oznaczają, że klienci i udziałowcy przyglądają
się projektowi i poświęcają mu swoją energię i czas, dając przydatne sprzę-
żenie zwrotne. Większość klientów czeka na koniec projektu i dopiero wtedy
mu się przygląda. Wówczas jest już jednak za późno. Zawsze lepiej otrzy-
mywać sprzężenie zwrotne wcześniej, nawet jeśli ciągłe zmiany listy zadań
będą frustrujące. Jeśli lista zadań przez jakiś dłuższy czas się nie zmienia,
to nie odzwierciedla prawdopodobnie aktualnych priorytetów w projekcie.
2
Jeśli istnieją trudności przy wyznaczaniu prognoz, spróbuj ograniczyć listę możliwości; na przykład
każda prognoza czasu wykonania może być jednodniowa, tygodniowa, dwutygodniowa
lub czterotygodniowa. Na początek nie dopuszczaj innych możliwości.
88
Sprzedaj swój program
Wymierna
Jeżeli lista zadań ma przynosić efekty, każda pozycja na niej musi być wy-
mierna. W końcu muszą istnieć kryteria pozwalające stwierdzić, że zadanie
zostało zrealizowane i może być usunięte z listy.
Kryterium to eliminuje nieprecyzyjne pozycje w rodzaju „Poprawienie wy-
dajności”, a promuje takie jak „Skróć czas logowania do poniżej pięciu
sekund” lub „Generuj raport X w czasie krótszym niż 10 sekund”. Sfor-
mułowanie celu, którego stan jest binarny, umożliwia stwierdzenie, czy zo-
stał on zrealizowany. Cel w rodzaju „Poprawienie wydajności” może trwać
przez cały czas życia produktu i pozostać czarną dziurą.
Jeśli masz na liście zadań pozycje, które nie są wymierne, zastanów się nad
tym, jakie jest rzeczywiste wymaganie. Czy pozycja wynika z zapotrzebowa-
nia na szybsze generowanie raportów czy szybszy start systemu? Podziel
tę pozycję na dobrze zdefiniowane, binarne cele, a następnie zapytaj osobę,
która wyznaczyła pierwotny cel, o jej zdanie o zmodyfikowanych celach.
Ten przegląd upewni Cię, że rzeczywiście bierzesz pod uwagę wymaga-
nia klienta.
Harmonogram według funkcji
zamiast harmonogramu według terminów
Harmonogramowanie według terminów ma tę wadę, że klientom
sprzedawane są przecież funkcje produktu, a nie dni kalendarzowe.
Jeśli zespół korzysta z listy zadań i wszystkie pozycje są uporząd-
kowane według priorytetów, wówczas prace nad programem
podporządkowane są funkcjom, a nie terminom. Kierownictwo
firmy może spojrzeć na listę zadań i narysować kreskę pod funk-
cjami, które chce mieć w następnej wersji. Następnie dodawane
są czasy wykonania poszczególnych funkcji i obliczana jest data
wyprodukowania nowej wersji. Specyfika produktu i branży za-
decyduje, ile czasu należy poświęcić na wewnętrzne testy i wersje
beta, ale moment zamrożenia prac nad programem zostanie ja-
sno ustalony.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
89
Jeśli dział sprzedaży zdecyduje, że określona funkcja musi być
uwzględniona, wówczas jej priorytet na liście zadań może się zmie-
nić i może ona stać się funkcją, która znajdzie się w gotowym
produkcie. Czas potrzebny na stworzenie nowej funkcji musi być
oczywiście dodany do daty końcowej projektu.
Taki sposób pracy pozwala działowi sprzedaży oraz kierownictwu
dostrzec zależność pomiędzy dodawaniem nowych funkcji, a cza-
sem koniecznym na ich zrealizowanie. Nie muszą już podejmować
decyzji o terminach realizacji projektu oraz funkcjach produktu,
będąc w próżni. Zamiast abstrakcyjnego porównywania dwóch nie-
określonych funkcji, porównują dwie jasno zdefiniowane z okre-
ślonymi czasami realizacji.
Uważamy, że dzięki temu podejściu produkt dostępny jest wów-
czas, gdy jest gotowy, tak szybko jak to możliwe. Unika się rów-
nież arbitralnego wyznaczania terminów, które nie są przestrze-
gane. Nasza branża słynie z niedotrzymywania terminów i nic
dziwnego, jeśli weźmiemy pod uwagę sposoby, w jakie piszemy
programy. Zamiast na siłę zakładać arbitralny termin na arbitral-
ny zbiór funkcji, firmy powinny pytać swoich programistów, co
są w stanie wykonać! Jeśli programiści nie są w stanie wykonać
zadania, to czy lepiej jest dowiedzieć się o tym teraz czy później,
kiedy termin zostanie już przekroczony? A jeśli programiści są
w stanie wykonać zadanie przed terminem, czy nie byłoby dobrze
wiedzieć o tym i dodać ewentualnie nowe funkcje lub wysłać pro-
gram klientowi wcześniej?
Za pierwszym razem kiedy będziesz kończył produkt w opisany
sposób, kierownictwo będzie zaniepokojone. Za drugim razem,
będą odprężeni. Za trzecim będą mieli zaufanie, że ich programiści
dostarczą to, co obiecali!
Jeżeli pozycja nie może być wyrażona za pomocą wymiernych celów, wów-
czas nadaj jej najniższy priorytet i zajmij się tymi o wyższym priorytecie.
Całkowite usunięcie pozycji mogłoby być błędem, jeśli była ona jednak
istotna; pozycja musi być jednak przekształcona w wymierne części.
90
Sprzedaj swój program
Jaś pyta...
Co to jest zamrożenie kodu?
Zamrożenie kodu to moment, od którego kod programu nie może
już podlegać zmianom. W trakcie trwania projektu kod programu
podlega nieustannym zmianom. Po jego zamrożeniu zmiany zo-
stają zatrzymane, tylko poważne poprawki błędów mogą być wtedy
wykonane. Nowe funkcje oraz poprawki drobnych błędów nie są
dopuszczalne.
Często zamrożenie kodu przechodzi w odwilż, w miarę jak nie-
przemyślane zmiany przedostają się do programu.
Ukierunkowana
Zapewne zauważyłeś, że omawialiśmy zarówno indywidualne listy zadań,
jak i grupowe. Każdy rodzaj listy jest bardzo ważny i musi być w swojej
treści odpowiednio ukierunkowany. Lista zadań dla całego zespołu będzie
dużo bardziej rozbudowana i będzie zawierać wszystkie niewykonane za-
dania dla całego projektu. Twoja osobista lista zadań będzie zawierała mniej
pozycji związanych z zespołem (czasem tylko jedną pozycję z całego pro-
jektu), ale jak tylko ją zrealizujesz, przeniesiesz pozycję z listy grupowej na
swoją własną.
Mimo swojej prostoty lista zadań jest skutecznym narzędziem na wielu
szczeblach. Poprawia Twoją organizację pracy i zwiększa dostęp do infor-
macji dla kierowników projektu. Tworzenie i nadawanie priorytetów pozy-
cjom listy zadań wymaga przemyślenia własnej pracy i nakreślenia kolejnych
kroków. Każdy wielki bilardzista powie Ci, że ma zaplanowane następne
osiem uderzeń — podobnie jest z wielkim programistą.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
91
Przykład listy zadań
Oto przykład indywidualnej listy zadań uporządkowanej według priorytetów:
1.
Dodaj nowy raport wyświetlający formanty utworzone
w ciągu dnia.
2.
Dodaj nowy raport wyświetlający formanty utworzone przez
pracownika.
3.
Sprawdź błąd #12345 (raport miesięczny wskazuje, że liczba
utworzonych formantów wynosi zero).
4.
Zainstaluj narzędzia programistyczne na swoim nowym
komputerze.
5.
Sprawdź nowe formaty raportów. Mogą one być dobrym
dodatkiem do następnej wersji.
Zauważ, że najważniejsze pozycje są na pierwszych miejscach. W tym
przypadku nowe funkcje są ważniejsze niż poprawki błędów, ale nie zawsze
tak jest. Ponadto instalacja nowego komputera i projekt badawczy są u dołu
listy. Te pozycje mogą wypełnić czas w wolnych chwilach (na przykład gdy
czekasz na kogoś) lub gdy potrzebujesz przerwy. Ważne jest umieszczanie
na liście zadań o niskim priorytecie, aby uniknąć ich zapomnienia.
Od czego zacząć?
1.
Przez cały dzień zapisz każde zadanie, nad którym pracujesz
(to będzie lista zadań zakończonych).
2.
Zapisz swoje codzienne działania w sformalizowany egzemplarz
listy zadań.
3.
Poproś kierownika technicznego o pomoc w nadaniu priorytetów
i dodaj wstępne prognozy czasu wykonania.
4.
Rozpocznij pracę od pozycji listy o najwyższym priorytecie
— bez oszustw! Jeśli jakiś kryzys zmusi Cię do zajęcia się
czynnością o niższym priorytecie, zarejestruj to.
92
Sprzedaj swój program
Dodaj wszystkie nowe zadania do listy.
5.
6.
Przenoś pozycje na listę czynności zakończonych po zrealizowaniu
zadania (dzięki temu łatwiej przeżyć raporty o statusach
i „polowania na czarownice”).
Tworzenie listy zadań zmusza do organizacji swojej pracy i nadania jej
priorytetów. Tak samo jak pisanie pamiętnika pomaga przemyśleć i zrozu-
mieć, co się robiło. Lista pozwala uporządkować własne zadania na dość
wysokim poziomie i bez zbędnej formalizacji.
Przeglądaj listę zadań każdego ranka. Aktualizuj ją, kiedykolwiek pojawiają
się nowe zadania... zwłaszcza krytyczne, pojawiające się w ostatniej chwili
— mógłbyś o nich zapomnieć, gdy ktoś zapyta, co robiłeś przez cały ubie-
gły tydzień.
Postępujesz prawidłowo, jeśli...
Czy każde Twoje bieżące zadanie znajduje się na liście?
t
t
Czy lista zadań poprawnie odzwierciedla Twoje aktualne
obowiązki?
t
Czy kierownik techniczny lub klient pomagał Ci nadawać
pozycjom listy priorytety?
t
Czy lista jest ogólnie dostępna (elektronicznie lub w inny
sposób)?
Czy skorzystałeś z listy, aby wybrać swoje kolejne zadanie?
t
Czy potrafisz szybko aktualizować i udostępniać listę?
t
Sygnały ostrzegawcze
Nie dodajesz zadań do listy, ponieważ jesteś „zbyt zajęty”.
t
Aktualizacja listy zajmuje więcej czasu niż realizacja zadań.
t
t
Realizacja pozycji listy przez członków zespołu ciągnie się
tygodniami (wskazówka: pozycje są zbyt rozbudowane).
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
93
Lista zadań jest aktualizowana rzadziej niż raz w tygodniu.
t
Priorytety na liście nie odpowiadają rzeczywistym priorytetom.
t
t
Lista zadań jest trzymana w ścisłej tajemnicy i nie jest widoczna
dla osób spoza zespołu.
t
Poza listą zadań zespołu istnieją inne ogólnie dostępne wersje
(które różnią się między sobą).
Jaś pyta...
A jeśli mój zespół nie chce korzystać z listy zadań?
Nawet jeśli Twój zespół nie korzysta z listy zadań, możesz posłu-
giwać się nią we własnym zakresie. Zapisz ją na tablicy lub w note-
sie, w palmtopie lub na swojej stronie internetowej. Poproś kierow-
nika technicznego o pomoc w ustaleniu priorytetów i wykorzystaj
jego rady do uporządkowania swojej pracy. Zaznaczaj, które po-
zycje już wykonałeś, i przeglądaj listę co tydzień. Korzystanie z listy
w taki sposób będzie dla Ciebie równie efektywne, jak byłoby efek-
tywne dla całego zespołu. W końcu dobry kierownik techniczny
zauważy, że korzystasz z listy zadań i zacznie jej używać dla całego
zespołu. Będziesz zaskoczony, jak szybko dobre nawyki stają się
popularne. Może to chwilę potrwać, ale ludzie zawsze w końcu
przekonują się do czegoś, co jest skuteczne.
11. Kierownik techniczny
Kierownik techniczny ponosi techniczną odpowiedzialność za projekt pro-
gramistyczny. Obecność kierownika technicznego zwalnia menedżera firmy
od technicznych obowiązków na rzecz kogoś z lepszymi predyspozycjami,
on sam może natomiast zająć się innymi biurokratycznymi sprawami. Me-
nedżer może być jednocześnie kierownikiem technicznym, ale nie jest to
konieczne, a często wręcz niepożądane. Obecność oddzielnego kierownika
technicznego jest wskazana, jeśli menedżer nie ma dostatecznej wiedzy tech-
nicznej lub jeśli zespół pracuje jednocześnie nad kilkoma projektami.
kierownik
techniczny
94
Sprzedaj swój program
Dlaczego potrzebny jest kierownik techniczny?
Czy zdarzyło Ci się pracować pod kierownictwem menedżera, który nie ro-
zumiał używanej przez Ciebie technologii? Tego typu osoby ustalają niere-
alne terminy, nie rozumieją opóźnień i narzekają na harmonogramy. Wszyst-
ko to dzieje się dlatego, iż nie rozumieją tego, co robisz i jak funkcjonują
wykorzystywane przez Ciebie technologie. Dla osoby, która nigdy nie pra-
cowała jako programista, zrozumienie Twojej pracy będzie trudne. Podczas
gdy w dziale sprzedaży mogą pracować osoby, które wiedzą tylko, jak ko-
rzystać z Twojego programu, w przypadku kierownika technicznego wy-
magana jest dokładna wiedza na temat tego, jak ten program funkcjonuje.
Osoba odpowiedzialna za harmonogramowanie funkcji i koordynowanie
pracy programistów, aby być efektywna, musi rozumieć, jak działa kod pro-
gramu. Potrzebujesz osoby biegłej technicznie, która będzie w stanie wyja-
śnić technologie związane z produktem menedżerom bez wiedzy technicznej.
Potrzebujesz osoby, która będzie pośrednikiem pomiędzy zespołem progra-
mistów a zarządem firmy. Potrzebujesz kierownika technicznego.
Na ogół kierownik techniczny jest członkiem zespołu, który awansuje na
stanowisko kierownicze. Rozumie on techniczne problemy zespołu dzięki
swojemu doświadczeniu w programowaniu. Nie zobowiązuje się do niere-
alnych terminów, ponieważ rozumie, czego wymaga pozornie prosta nowa
funkcja. Kierownik techniczny może wyeliminować, a przynajmniej zmniej-
szyć, wtrącanie się kierowników bez odpowiednich kompetencji.
Po jednej stronie znajduje się menedżer bez kompetencji technicznych, po
drugiej taki, który cały dzień pogrążony jest w pisaniu programów i nie
kontaktuje się ani z kierownictwem, ani z klientami. Jest to stereotypowy
programista ukrywający się w swoim biurze i unikający pozatechnicznego
świata. Ale wówczas firma opracowuje programy, których nikt nie chce,
a priorytety wynikają raczej z kaprysów menedżera, a nie z potrzeb klien-
tów. Za każdym razem powstaje produkt, który zalega na półkach. Kierow-
nicy wyższych szczebli nie wiedzą, czym Twój zespół się zajmuje, a więc
zakładają, że nie robi nic, to z kolei niweczy Twoje szanse na premie,
podwyżki i awanse. Twój zespół potrzebuje adwokata, który znajdzie czas
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
95
na pisanie raportów i przygotowywanie prezentacji dla menedżerów, klientów
i wszystkich osób, dla jakich znajomość Twojego projektu jest istotna. A więc
jeszcze raz: Twój zespół potrzebuje kierownika technicznego.
Kierownik techniczny żyje więc w dwóch światach. Musi pracować wspól-
nie z programistami i ich rozumieć, a jednocześnie spotykać się z mene-
dżerami, klientami i innymi kierownikami technicznymi, aby przekazywać
informacje o pracy własnego zespołu. Poświęcając czas na spotkania z klien-
tami, jest jedyną osobą, która wie, jakie funkcje powinien wykonywać two-
rzony program.
Kierownik techniczny spełnia następujące funkcje:
Zapewnia, że priorytety zespołu odpowiadają potrzebom klienta.
t
t
Odpowiednio przedstawia wykonywane w zespole zadania
kierownictwu firmy.
t
Izoluje programistów od menedżerów wyższego szczebla,
którzy nie mają przygotowania technicznego.
t
Tłumaczy techniczne kwestie udziałowcom bez odpowiedniego
przygotowania.
Przekazuje pozatechniczne problemy programistom.
t
Jaś pyta...
Kim jest udziałowiec?
Udziałowiec jest to osoba, która ma związek z Twoim produktem.
Pracując nad projektem, powinieneś wiedzieć, kim będą jego od-
biorcy. Twoimi udziałowcami mogą być klienci, ale jeśli ich jeszcze
nie poznałeś, może ich zastąpić dział sprzedaży lub marketingu.
W małych firmach udziałowcami mogą być inwestorzy. W więk-
szych firmach udziałowcami są czasem inne działy, które rozwi-
jają swoje produkty, opierając się na Twoich. Jest bardzo istotne,
aby rozpoznać te osoby tak, aby stworzyć produkt, którego po-
trzebują.
96
Sprzedaj swój program
Jakie więc czynności musi wykonać kierownik techniczny, aby zrealizować
te zadania?
Zakres odpowiedzialności kierownika technicznego
Kierownik techniczny ma kilka ważnych obszarów odpowiedzialności, które
różnić się będą w zależności od rodzaju firmy i składu zespołu. Oto mini-
malna lista kompetencji kierownika technicznego:
ustalanie wytycznych dla programistów,
t
zarządzanie listą funkcji projektu,
t
ustalanie priorytetów,
t
izolowanie członków zespołów od czynników zewnętrznych3.
t
Przyjrzyjmy się bliżej każdej z tych dziedzin.
Ustalanie wytycznych dla programistów
Kierownik techniczny jest reżyserem zespołu, ustala kierunki i priorytety.
Współpracuje z każdym programistą przy tworzeniu i modyfikowaniu oso-
bistej wersji listy zadań (patrz: podrozdział 10. na stronie 78). Kierownicy
techniczni korzystają ze swojej znajomości postępów, problemów oraz pro-
gnozowanych terminów realizacji związanych z ich zespołem, tak aby wytwo-
rzyć ogólny obraz stanu projektu oraz śledzić jego postępy. Jako pojedyn-
czy punkt kontaktowy dają oni możliwość szybkiego powiadamiania o statusie
projektu dla wszystkich zainteresowanych.
Zarządzanie listą funkcji projektu
Kierownik techniczny jest głównym nadzorcą listy funkcji związanych z pro-
jektem. Zapotrzebowanie na nowe funkcje nie jest przekazywane bezpośred-
nio programistom, tylko wszystkie są najpierw zgłaszane do kierownika
technicznego. Zarządza on wszystkimi zmianami na liście funkcjonalności.
3
Istnieje ryzyko przesadnej izolacji, która może pozbawić wartościowych sprzężeń zwrotnych.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
97
Kierownik techniczny jest jedyną osobą, która rozumie nie tylko powiąza-
nia techniczne każdej funkcji, ale zna również życzenia udziałowców pro-
jektu. Kierownik techniczny dodaje i usuwa funkcje oraz ukierunkowuje
wysiłki poszczególnych programistów.
Kierownik techniczny oraz udziałowcy najpierw ustalają zakres pracy po-
przez stworzenie listy funkcji (najlepiej za pomocą listy zadań!). Następ-
nie kierownik spotyka się z całym zespołem, aby oszacować czas potrzebny
na realizację każdej funkcji. Czasem oznacza to podział rozbudowanej
funkcji na kilka pozycji listy zadań. Następnie przypisuje on poszczególne
zadania programistom i ustala wstępny harmonogram projektu (wstępne
oszacowania podlegają zmianom w miarę postępów projektu, ale więcej na
ten temat później).
Zarządzanie listą funkcji przez kierownika technicznego bardzo pomaga
w sytuacji, gdy ciągle pojawiają się osoby próbujące dodać do projektu nowe
funkcje. Kierownik techniczny pełni rolę bufora filtrującego zapotrzebowa-
nia i ustalającego dla nich rozsądne priorytety.
Kierownik techniczny może być bardzo przydatny jako pośrednik w kontak-
tach z zespołem programistów. Na przykład w wielu firmach spotyka się
kilku nadmiernie „kreatywnych” pracowników. Mają oni zawsze wspaniałe
pomysły, ale rozpraszają tym innych pracowników. Ten typ pracowników
ma zwyczaj zjawiać się, kiedy inni są najbardziej zajęci.
Jeden szczególnie kreatywny pracownik (Ernest), którego znaliśmy, był gor-
szy niż inni. Aby zniwelować jego wpływ, kazaliśmy mu przynosić pomy-
sły do nas (a nie do programistów). Następnie dodawaliśmy jego pomysł
na nową funkcję do listy zadań (która znajdowała się na tablicy). Po jej
dodaniu porównywaliśmy ją z funkcjami o priorytecie pierwszym (wymaga-
ne funkcje) i wszyscy zgadzaliśmy się, że nie zasługuje ona na taki priorytet.
Następnie dokonywaliśmy kolejno porównań z funkcjami o coraz niższym
priorytecie. Okazywało się, że zawsze kończyliśmy na najniższym priorytecie
— piątym, związanym z opcjonalnymi, mało istotnymi funkcjami.
98
Sprzedaj swój program
Ostatecznie Ernest poznał nasz system i zaczął sam dodawać swoje funkcje
na dole tablicy, poniżej tych o priorytecie piątym. Ponieważ umieszczał je
na liście zadań, jego funkcje nie były zapominane. Niektóre ostatecznie zo-
stawały dodane do naszego produktu, ale zawsze umieszczane były w na-
stępnej wersji, a nie w bieżącej. Postępując tak z kreatywnymi osobnikami,
dajemy im możliwość zgłaszania swoich pomysłów, a zespół nie jest odry-
wany od bieżącej pracy i nie traci czasu na nieistotne funkcje.
Ustalanie priorytetów
Tworzenie nowej listy zadań powinno być uporządkowane. Bez tego każ-
dy mógłby po prostu wybrać interesujące go funkcje, a zaniedbać te, które
są konieczne. Określenie poprawnego priorytetu dla każdej z funkcji jest
niemal tak samo ważne jak samo umieszczenie pozycji na liście! Na szczę-
ście jest to problem, który możesz zlecić swojemu kierownikowi technicz-
nemu. Musi on współpracować z udziałowcami projektu, aby ustalić prio-
rytety funkcji.
Udziałowcy mają duży wpływ na priorytety funkcji i zawsze wykazują szcze-
gólne zainteresowanie projektem oraz jego powodzeniem. Nie mają oni
jednak na ogół przygotowania technicznego niezbędnego do podejmowa-
nia właściwych decyzji. Często po prostu nie wiedzą, co jest technicznie
możliwe oraz praktyczne.
Kierownik techniczny współpracuje z udziałowcami, aby ustalać priorytety
funkcji. Może on wykonać tę czynność, ponieważ zna zdolności swojego
zespołu (pojęcie, które nieustannie podlega zmianom), a także techniczne
szczegóły projektu.
W trakcie tego procesu kierownik techniczny pozna pozatechniczne po-
wody, dla których udziałowcy domagają się pewnej funkcji. Kierownik
techniczny oraz udziałowiec pracują razem i osiągają kompromis przy usta-
laniu priorytetów. Ta współpraca pomaga wyważyć racje udziałowca bez
przygotowania technicznego i kierownika technicznego, który nie ma kon-
taktów z klientem.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
99
W praktyce kierownik techniczny nie musi się spotykać z udziałowcem, aby
dyskutować o każdym detalu. Z czasem zaczną się nawzajem rozumieć
i sobie ufać.
Izolowanie programistów
od czynników zewnętrznych
Priorytety
Z priorytetami skojarzone są liczby. Najwyższy jest priorytet pierw-
szy, najniższy piąty. W razie potrzeby można stosować inną nume-
rację. Obecnie korzystamy z zakresu od jeden do pięć, ale w innych
sytuacjach stosowaliśmy zakres od jeden do dziesięć. Istotniejsze
jest uporządkowanie, a nie zakres.
Priorytet pierwszy: funkcje wymagane.
Dotyczy funkcji, bez których absolutnie nie można sprzedać
produktu.
Priorytet drugi: funkcje bardzo ważne.
Można by sprzedać produkt bez zawarcia tych funkcji,
ale jest to niewskazane.
Priorytet trzeci: funkcje przydatne.
Jeśli znajdziesz czas, zrealizujesz je, ale na pewno nie opóźnią
one daty zakończenia projektu.
Priorytet czwarty: funkcje dekoracyjne.
Funkcje te poprawiają odbiór programu.
Priorytet piąty: funkcje nieistotne.
Jeżeli masz czas na dodawanie funkcji nieistotnych, to znaczy,
że jesteś przed terminem i masz wolny budżet.
Jesteś w środku zawiłego projektu. Szło Ci świetnie przez cały poranek,
dokonywałeś znacznych postępów. Wtedy natrętny pracownik działu sprze-
daży wpada, aby zadać pytanie dotyczące następnej wersji, czym kom-
pletnie Cię rozprasza. Złościsz się, nawet gdy tylko o tym czytasz? Nie
przeciążenie
poznawcze
100
Sprzedaj swój program
tylko Ty — każdemu pracuje się lepiej, jeśli nikt mu nie przerywa. Bada-
nia wykazały, że do 40 czasu pracy może być marnowane wskutek prze-
rywania4. To tak jakbyś szedł do domu po przepracowaniu mniej niż pięciu
godzin! Naukowcy mają nawet swoje określenie na to zjawisko: przeciążenie
poznawcze5. Wiedząc o tym, kierownik techniczny musi dokładać wszelkich
starań, aby pozwalać pracować swojemu zespołowi bez zakłóceń. Świetną
metodą jest wykorzystanie kierownika technicznego jako punktu kontakto-
wego dla programistów. Zawsze pozwalaj kierownikowi technicznemu bu-
forować przerwania, niezależnie od tego, czy pochodzą z działu IT czy od
udziałowców.
Skąd pochodzą pozycje listy zadań?
Z jakich źródeł zbierane są funkcje umieszczane na liście zadań? Czy
można użyć dokumentacji z analizy wymagań? Analiz wymagań z innych
projektów? Historii użytkowników? Kartek z notesu? Dużego rządowego
kontraktu? Nie ma to znaczenia. Ważne jest, aby znać funkcje, które można
umieścić na liście zadań i nadać im priorytety. Lista zadań nie zastępuje
Twojej preferowanej metody zbierania wymagań. Zamiast tego gromadzi
informacje z każdego źródła i przedstawia je w precyzyjnym i zrozumiałym
formacie.
Jeszcze raz wyjaśnijmy to precyzyjnie. Lista zadań nie zastępuje sposobu
gromadzenia wymagań. Zastępuje ich sposób przedstawienia Twojemu ze-
społowi i współpracownikom.
Jak wygląda Twój kierownik techniczny?
Kierownicy techniczni dzielą swój czas pomiędzy zadania programistyczne
i zarządcze. Będą zdarzały się dni, a nawet tygodnie, w których kierownik
techniczny będzie działał tylko w jednym z tych zakresów, ale większość
dni zostanie pomiędzy nie podzielona.
4
5
Badania potwierdziły, że zmuszanie pracownika do zmiany kontekstu może mieć poważny wpływ
na wydajność. Koszt waha się od 20 do 40 — http://www.umich.edu/~bcalab/multitasking.html.
Dr David Levy bada, w jaki sposób jednoczesne wykonywanie kilku zadań wpływa na nasze
zdrowe i wydajność: http://seattletimes.nwsource.com/pacificnw/2004/1128/cover.html.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
101
Kierownik techniczny jest strażnikiem projektu. Kierownicy techniczni utrzy-
mują pracowników na wytyczonym szlaku oraz zapewniają sensowność listy
funkcji. Informują również kierownictwo o postępach zespołu i upewniają
się, że punkt widzenia klienta jest brany pod uwagę. Twój kierownik tech-
niczny musi być prawdziwym omnibusem.
Oczywiście szerokie kompetencje kierownika technicznego mogą przy-
czynić się zarówno do sukcesu, jak i niepowodzenia projektu (lub jego
części). To nie jest łatwa praca; wymaga przygotowania technicznego,
zdolności komunikacyjnych oraz umiejętności równoczesnego wykonywa-
nia kilku czynności.
Każdy projekt powinien mieć dobrego kierownika technicznego i każdy pro-
gramista powinien starać się nim zostać przynajmniej raz. Nawet jeżeli nie
będziesz pełnił tej funkcji na stałe, nauczenie się jego umiejętności spowo-
duje, że staniesz się bezcenny dla swojego zespołu i firmy.
WSKAZÓWKA 15
Stwórz stanowisko kierownika technicznego
Od czego zacząć?
Jeśli masz aspiracje, aby zostać kierownikiem technicznym, musisz udowod-
nić, że jesteś w stanie radzić sobie z dodatkową odpowiedzialnością. Za-
poznaj się z zakresem obowiązków i próbuj im sprostać. Dobrowolnie wy-
konuj tak wiele obowiązków kierownika technicznego, ile potrafisz. Nie
czekaj, aż ta praca spadnie Ci z nieba; pokaż, że starasz się o to stanowisko
i potrafisz sobie na nim radzić.
Korzystaj z listy zadań (patrz: podrozdział 10. na stronie 78) do swojej
własnej pracy, ale także prowadź ją dla swojego zespołu. Monitoruj pracę
bieżącą, jednocześnie pamiętając o zbliżających się projektach.
102
Sprzedaj swój program
Oceniaj procesy realizowane w zespole. Lokalizowanie słabych punktów
oraz poszukiwanie standardów i pomysłów rozwiązujących problemy postawi
Cię w nowej perspektywie. Jeśli na przykład istnieje problem z zapewnieniem
poprawnej kompilacji kodu, powinieneś zainstalować system CI (patrz: pod-
rozdział 4. na stronie 49), aby rozwiązać ten problem.
Nie rezygnuj, jeśli nie awansujesz na stanowisko kierownika technicznego
natychmiast. Ucz się i rozwijaj, aż pojawi się następna okazja. Nie każdy
ma predyspozycje, aby zostać kierownikiem technicznym, ale zmierzanie
do tego daje szerszy obraz całego projektu, co czyni Cię bardziej efektyw-
nym pracownikiem. Stajesz się lepszym programistą, myśląc o tym, jak zo-
stać kierownikiem technicznym.
Jeśli właśnie zostałeś kierownikiem technicznym, przygotuj szkic mapy dro-
gowej — wykres pokazujący, w którym miejscu aktualnie znajduje się zespół
oraz w jakim kierunku chcesz, żeby zmierzał. Jakimi problemami się zaj-
miesz? Do jakich prac będziesz zachęcał?
Wykonaj listę wszystkich znanych problemów. Następnie przepytaj pra-
cowników, czy znane są im inne problemy. Kiedy uznasz, że lista jest
gotowa, zdecyduj, którymi pozycjami możesz się zająć, a którymi nie.
Codzienne spotkania są znakomitym sposobem nadzorowania prac ze-
społu bez niepotrzebnego nękania pracowników (patrz: podrozdział 12.
na stronie 103).
Postępujesz prawidłowo, jeśli...
Jako kierownik techniczny powinieneś być w stanie pozytywnie odpowie-
dzieć na poniższe pytania:
Czy wiesz, nad czym pracuje każdy pracownik w Twoim zespole?
t
t
Czy potrafisz wygenerować podsumowanie statusu projektu
w czasie krótszym niż 5 minut?
Jakie jest następne 5 – 10 funkcji produktu?
t
Czy potrafisz szybko wymienić usterki o najwyższym priorytecie?
t
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
103
Jaki ostatni problem został rozwiązany przez Twojego pracownika?
t
t
Czy pracownik przyszedłby do Ciebie, jeśli potrzebowałby
rozstrzygnięcia jakiejś ważnej kwestii?
Sygnały ostrzegawcze
Oto kilka sygnałów ostrzegawczych świadczących o tym, że kierownik tech-
niczny jest nieefektywny lub zbyt apodyktyczny:
Nie rozumie kontekstu pracy każdego z pracowników.
t
Swoją obecnością przerywa pracę innych.
t
Przypisuje sobie pracę zespołu.
t
Nie rozwiązuje problemów lub — co gorsza — je stwarza.
t
Niedokładnie prognozuje czas pracy.
t
t
Nie jest świadomy technicznych umiejętności swoich pracowników
lub (i) czego oni chcą się nauczyć.
Nie zwraca uwagi na konflikty personalne.
t
12. Codzienna koordynacja
i komunikacja
Ostatnią rzeczą, której pracownicy oczekują, jest większa liczba spotkań.
Jeśli Twój zespół spotyka się co tydzień, wówczas każde spotkanie trwa
prawdopodobnie przynajmniej godzinę. Obejmuje ono omawianie ogłoszeń,
ubiegłotygodniowej pracy i planów na następny tydzień. Codzienne spo-
tkania są zupełnie inne. Są to krótkie spotkania zespołu, które zachęcają
do kontaktów i komunikacji bez niepotrzebnego rozbijania codziennego
harmonogramu pracy.
104
Sprzedaj swój program
Każdy pracownik krótko opowiada, nad czym pracuje i na jakie natknął
się problemy. Dobrą regułą jest, aby poświęcać nie więcej niż jedną – dwie
minuty na pracownika. Pamiętaj, że to spotkanie angażuje każdego pra-
cownika, a więc powinno być krótkie i na temat, tak aby nie angażować
dużych nakładów gotówkowych (ang. burn rate).
Do czego potrzebne są codzienne spotkania?
Najprostszym sposobem radzenia sobie z zakłóceniami w komunikacji jest
częstsze rozmawianie z pracownikami. To pomoże zrozumieć, gdzie leży
problem, i daje szansę naprawienia go.
Większość ludzi stara się realizować cele zespołu. Niestety ludzie mają
skłonność do nierozumienia celów lub zatracania kierunku, co oznacza, że
należy podejmować czynności korygujące.
Spotykaj się częściej ze swoim zespołem i pozwól wszystkim opowiadać
o swojej pracy. Celem jest dokonywanie częstych korekt kursu: jeśli chcesz
jechać samochodem, wybierasz kierunek, ale nie trzymasz się go bez wzglę-
du na wszystko. Kierujesz samochód na właściwy kierunek, a następnie wy-
konujesz mnóstwo drobnych korekt, kręcąc kierownicą w prawo lub w lewo.
Zjedziesz z trasy i rozbijesz samochód, jeśli będziesz czekał zbyt długo na
korektę. Twój projekt programistyczny również skończy się fiaskiem, jeśli
zbyt długo nie będziesz przeprowadzał żadnych korekt.
WSKAZÓWKA 16
Dokonuj częstych korekt kursu poprzez codzienne spotkania
Co dają codzienne spotkania?
Codzienne spotkania dają wiele korzyści, których możesz zacząć doświad-
czać od pierwszego dnia, gdy zaczniesz je stosować.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
105
Jaś pyta...
Czym jest wskaźnik nakładów gotówkowych
(ang. burn rate)?
Wskaźnik nakładów gotówkowych opisuje, ile kosztuje bieżąca
działalność firmy, a więc wynagrodzenia, czynsz, elektryczność,
świadczenia itd. Jest to kwota pieniędzy wydawana niezależnie
od tego, czy praca jest wykonywana, czy nie jest. Jeśli przepro-
wadzasz jakieś spotkanie, zawsze cofnij się o krok i oblicz, ile Cię
ono kosztuje na godzinę. Jeśli to policzysz, spotkania będą na
ogół krótsze.
Niech na przykład praca programisty kosztuje 100 zł na godzinę
(po uwzględnieniu pensji oraz kosztów pośrednich). Jeśli w ze-
spole pracuje 10 osób, wskaźnik nakładów gotówkowych wynosi
1000 zł na godzinę, 8000 zł na dzień i 40 000 zł na tydzień.
Następnym razem gdy będziesz organizował spotkanie i zacznie
się ono z dziesięciominutowym opóźnieniem lub wszyscy przez
30 minut będą słuchać opowieści o wakacjach Marka, oblicz, jakie
są koszty. Jeśli Twój produkt ma trzy miesiące spóźnienia, jakie były
w tym czasie koszty prac programistycznych? Pamiętaj, że ten przy-
kład nie bierze pod uwagę kosztów utraconych korzyści podczas
zmarnowanego czasu.
Zeszliśmy z kursu... znowu
Istnieją programiści, którzy wiecznie schodzą z kursu. Najczęściej są to
programiści niedoświadczeni oraz indywidualiści. Nowi pracownicy nie mają
doświadczenia i będą spędzali czas nad rozwiązywaniem problemów dawno
rozwiązanych. Indywidualiści są starsi i bardziej doświadczeni, ale schodzą
z kursu równie często. Codzienne spotkania pozwalają obie te grupy pro-
gramistów utrzymać na właściwym kursie.
106
Sprzedaj swój program
Wyważanie otwartych drzwi
Niedoświadczony programista będzie rozwiązywał problemy, które nie po-
trzebują rozwiązania. Bystrzy młodzi programiści rzadko spotykają proble-
my, których nie potrafią rozwiązać, ale te, które rozwiązują, zwykle zostały
już rozwiązane przez kogoś innego. Nieszczęśliwie dla nich, inni progra-
miści nie rozmawiają z nimi wystarczająco dużo, aby im o tym powiedzieć.
Zamiast uczyć się na błędach swoich współpracowników, nowi programiści
wyważają otwarte drzwi i nie robią zbyt dużych postępów.
Zauważysz ten problem, gdy programiści zaczną wykorzystywać struktury
danych języka programowania. Ci programiści tworzą sprytne formanty
GUI, które powielają to, co przygotował inny programista miesiąc temu.
Każdy w firmie pisze własną kopię każdego narzędzia. Jeśli istniałaby ko-
munikacja, wówczas narzędzia te można by pisać jednokrotnie. Jednak
programiści w tego typu firmach są zbyt zajęci, aby ze sobą rozmawiać.
W efekcie każdy z nich ma formanty GUI o nieco innym wyglądzie i z wła-
snymi procedurami obsługi łańcuchów znaków.
Gdy Twój zespół spotyka się codziennie, a Wasz nowy pracownik Marek
mówi wszystkim, że zaczyna opracowywać nowy zestaw formantów GUI,
Agnieszka może mu powiedzieć o formantach, nad którymi ona i Michał
pracowali w ubiegłym roku. Być może nie są one dokładnie tym, czego on
potrzebuje, ale stanowią dobry punkt wyjścia dla jego pracy. Zamiast pra-
cować od zera, Marek będzie korzystał z pracy już wykonanej przez jego
kolegów. Jeśli prowadzimy codzienne spotkania, wówczas mamy forum dla
tego rodzaju dyskusji. Nie musimy czekać, aż Marek przez przypadek wspo-
mni o swoich formantach GUI podczas obiadu albo przerwy na kawę.
Indywidualiści
Wszyscy kiedyś pracowaliśmy z programistami-indywidualistami. Mają oni
skłonność zatracać kierunek i dryfować, nie wiadomo gdzie. Brną praco-
wicie przez przypadkowo wybrany kod i „poprawiają” go poprzez porząd-
kowanie nagłówków metod, szlifowanie algorytmów i formatowanie nawia-
sów. Indywidualiści nie mają wystarczająco dużo dyscypliny, aby zakończyć
jakiekolwiek zlecone zadanie i na ogół przynoszą więcej szkody niż pożytku.
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
107
Jeden programista-indywidualista, którego znamy, porządkuje nagłówki
metod i usuwa nieużywane argumenty. Przykładowo w jego rękach wiersz
doSomething(String foo, Integer bar)
przekształciłby się w
doSomething(String foo)
Niestety, ten programista, podobnie jak inni indywidualiści, nigdy równo-
cześnie nie zmienia kodu, który używa metody doSomething, wskutek czego
jego zmiany często powodują niepowodzenia kompilacji.
Indywidualiści będą poprawiać wydajność algorytmów, ale ich zmiany
spowodują, że program zacznie generować błędne wyniki. Będą spędzać
godziny na formatowaniu programu tak, aby odpowiadał ich gustom. Indy-
widualiści mają zbiór nawyków, które stosują bo „tak trzeba”.
Nad indywidualistami można zapanować dosyć łatwo. Po pierwsze: prze-
prowadzaj codzienne spotkania. Po drugie: zwracaj uwagę na codzienne
raporty indywidualistów. W tym miejscu dobry kierownik techniczny za-
uważy ich dryfowanie, zanim zajdzie ono za daleko. I na koniec: kierownik
techniczny musi mieć pewność, że ich praca jest warta całego dnia spę-
dzonego w biurze. Taka taktyka nie eliminuje całkowicie ich błąkania się,
ale zminimalizuje ich wolny czas i ograniczy szkody.
Przekazywanie wiedzy
Jeśli w zespole jest kilku doświadczonych programistów, codzienne spo-
tkania pozwalają skorzystać z ich wiedzy. Za każdym razem, gdy dzielą się
swoim rozwiązaniem, dowiaduje się o nim cały zespół. Z drugiej strony za
każdym razem, gdy młodszy pracownik opowiada o problemie, starsi dowia-
dują się o nim i mogą pomóc — jeśli nie wiesz o problemie, nie możesz
pomóc go rozwiązać.
Powiedzmy na przykład, że Jarek przychodzi na codzienne spotkanie
i mówi, że ma problem z parserem XML-a, który nie radzi sobie ze zna-
kami międzynarodowymi. Michał, który spotkał się z takim samym pro-
blemem rok temu, może powiedzieć dokładnie, jak go rozwiązać. Jarek
108
Sprzedaj swój program
dostaje szybką odpowiedź i nie musi spędzać wielu godzin, analizując ten
problem samodzielnie. Każdy pracownik może wykorzystać doświadcze-
nie całego zespołu w celu szybkiego rozwiązania problemów.
Komunikacja w zespole
Codzienne spotkania zmuszają wszystkich do rozmów bez wyróżniania ko-
gokolwiek. Spotykanie się każdego dnia na rozmowach oraz udzielanie sobie
nawzajem pomocy wytwarza w zespole niespotykaną więź. Ile znacie ze-
społów, w których każdy pracownik rozmawia z każdym innym pracowni-
kiem przynajmniej raz dziennie? Codzienne spotkania wiążą niejednorodną
grupę programistów w prawdziwy zespół.
Typem programisty, który korzysta najwięcej z codziennych spotkań, jest
człowiek nieśmiały, spędzający całe dnie na chowaniu się w swoim biurze.
Pewna osoba, z którą pracowaliśmy (powiedzmy, że był to Ryszard), była
modelowym przykładem takiej osobowości. Ryszard przychodził bezpo-
średnio do swojego pokoju, pracował do obiadu, który jadł sam, i wychodził
na koniec dnia. Przez większość dni nie zamienił z nikim nawet słowa.
Gdy rozpoczęto organizowanie codziennych spotkań, wszyscy członkowie
zespołu — nawet Ryszard — zaczęli się poznawać. Żarty opowiadano
przed spotkaniami, w ich trakcie i po nich. Programiści pomagali sobie
nawzajem w rozwiązywaniu problemów. Zawiązywały się przyjaźnie. Z tego,
co ostatnio słyszeliśmy, Ryszard całkowicie wyszedł ze swojej skorupy i miał
kontakty z prawie całym zespołem. Zapraszał innych na obiad, wpadał po-
gadać i utrzymywał kontakty na poziomie — wydawałoby się — wcześniej
niemożliwym.
Widzieliśmy ten efekt u wielu ludzi na różnych etapach i zawsze z pozy-
tywnymi wynikami.
Szeroki punkt widzenia
Spotkania z innymi pracownikami oraz wiedza na temat tego, nad czym oni
pracują, zapobiega „krótkowzroczności” w postrzeganiu funkcji projektu.
Jeśli ta przypadłość dotyka pracowników, wydaje im się, że ich praca jest
Rozdział 3. (cid:129) Pragmatyczne techniki projektowe
109
jedyna i najważniejsza. Prowadzi to do iluzji wielkości i powoduje, że pro-
gramiści przeceniają swoje miejsce w świecie. Często samo bycie w grupie,
która dyskutuje nad różnymi projektami i kierunkami prac, może uleczyć
taką osobę bez konieczności stosowania innych zabiegów.
Poza leczeniem „krótkowzroczności” cały zespół może odnieść korzyść z wie-
dzy o tym, czym zajmują się inni pracownicy. Jeśli jeden pracownik wie, że
inny zamierza zmienić komponent, który on wykorzystuje, wówczas może
zająć się innym o
Pobierz darmowy fragment (pdf)