Joel on Software

Joel on Software   Joel o programowaniu

 

Inne artykuły serwisu "Joel on Software" po polsku

Inne artykuły serwisu "Joel on Software" po angielsku

Napisz do autora (tylko po angielsku)

 

Bezbolesne Harmonogramy


Joel Spolsky
Przełożył Andrzej J. Woźniewicz
Korekta Andrzej Swędrzyński
29 marca, 2000

W październiku ubiegłego roku, północno-wschodnia część Stanów Zjednoczonych wręcz oblepiona była reklamami czegoś o nazwie Acela, czyli nowego, ekspresowego serwisu kolejowego między Bostonem a Waszyngtonem. Wydawało się, że wszechobecna w telewizji, na przydrożnych billboardach i plakatach reklama spowoduje chociaż śladowe zainteresowanie nową ofertą ekspresowej linii firmy kolejowej Amtrak.

Cóż, mogło być i tak. Amtrak jednak nigdy nie miał okazji się przekonać. Wprowadzenie serwisu Acela opóźniało się i opóźniało, aż kampania reklamowa dobiegła końca, zanim Acela została uruchomiona. Przypomina mi to anegdotę o pewnym szefie marketingu. Otóż, kiedy w prasie ukazała się pełna zachwytów recenzja jego produktu, a do wprowadzenia go na rynek był jeszcze cały miesiąc, rzekł on: „Świetna promocja! Szkoda tylko, że nie można tego draństwa jeszcze kupić.”

Zdopingowani testosteronem producenci gier hełpią się na swoich witrynach internetowych, że ich następna gra ukaże się „kiedy tylko będzie gotowa”. Plan? Po co komu plan! My — to wszak równa brać programistów wyspecjalizowanych w grach! Większość firm jednak nie ma takiego luksusu. Zapytaj o to firmę Lotus. Kiedy wdrażali wersję 3.0 swego arkusza kalkulacyjnego 1-2-3, wymagał on procesora 80286, który nie był wtedy jeszcze popularny. Wyprodukowanie ich produktu opóźniło się o 16 miesięcy, podczas których pracowali pilnie nad wciśnięciem go w ograniczoną do 640K pamięć procesora 8086. Kiedy w końcu dopięli swego, firma Microsoft miała 16-miesięczną przewagę w swych wysiłkach nad Excelem, a swoistą ironią losu było to, że 8086 stał się tymczasem przestarzały.

Kiedy piszę te słowa, wersja 5.0 przeglądarki internetowej firmy Netscape jest opóźniona o prawie dwa lata. Częściowo stało się to za sprawą ich samobójczej decyzji o odrzuceniu istniejącego kodu i rozpoczęcia wszystkiego od początku — podobnej do tych, które skazały firmy Ashton-Tate, Lotus i system operacyjny MacOS firmy Apple na śmietnik komputerowej historii. Netscape zapłaciła za swój błąd spadkiem penetracji rynku przez ich przeglądarkę z 80% do około 20%, nie będąc w tym czasie nawet w stanie zająć się aspektami rynkowymi swojego wiodącego produktu, który rozsypany był na czynniki pierwsze i nie był w stanie dojechać donikąd. To właśnie ta jedna fatalna decyzja, bardziej niż cokolwiek innego, była tą bombą atomową, przy pomocy której Netscape wysadziła się sama w powietrze. (Szczegóły można przeczytać w światowej już sławy wybuchu złości Jamie Zawinskiego).

A zatem, musisz przygotować harmonogram. Jest to coś, czego prawie żaden szanujący się programista nie ma ochoty robić. Z mojego doświadczenia wynika, że zdecydowana większość stara się w ogóle wymigać od ustalania jakiegokolwiek planu. Spośród tych, którzy, owszem, przygotowują harmonogramy, wiekszość robi to bez przekonania i tylko dlatego, że szef im kazał. Nikt zresztą nie wierzy w taki plan, za wyjątkiem wysoko postawionego kierownictwa, które także święcie wierzy w to, że „żaden projekt oprogramowania nie da się wdrożyć na czas” oraz w istnienie UFO.

Więc dlaczego nikt nie przygotowuje harmonogramów? Są po temu dwa główne powody. Pierwszy, to przekonanie, że to za dużo pracy. Drugi, że nikt nie wierzy, iż w ogóle warto to robić. Po co zadawać sobie tyle trudu pracując nad planem, skoro i tak nie będzie on zgodny z rzeczywistością? Istnieje przekonanie, że plany systematycznie rozmijają się z faktami, a sytuacja się tylko pogarsza w miarę upływu czasu, więc w jakim celu cierpieć na darmo?

A oto prosty, bezbolesny sposób przygotowywania harmonogramów, które jak najbardziej pokrywają się z rzeczywistością.

1) Używaj arkusza kalkulacyjnego Microsoft Excel. Nie potrzeba żadnych udziwnień w rodzaju Microsoft Project. Microsoft Project spowoduje, iż sen Ci z oczu będzie spędzała kwestia zależności. Zależność występuje pomiędzy dwoma zadaniami wtedy, kiedy jedno musi się zakończyć, zanim nastepne może się rozpocząć. Zaobserwowałem, że w dziedzinie programowania, zależności są tak oczywiste, że nie ma sensu ich formalnie śledzić.

MS Project ma jeszcze jeden problem. Zakłada on, iż będziesz chciał nacisnąć tylko jeden guzik aby „zrównoważyć” Twój plan. Nieodwołalnie oznacza to również, że zmieni on kolejność oraz inaczej poprzydziela zadania ludziom. W dziedzinie programowania to po prostu nie ma żadnego sensu. Programiści nie są dowolnie wymiennymi pionkami. Naprawienie błędu Rity zajmie jej siedem razy mniej niż Johnowi. A jeśli spróbujesz przydzielić swojemu specjaliście od okienek zadanie wymagające użycia biblioteki komunikacyjnej WinSock, zmarnuje on następny tydzień na dokształcanie się w zakresie programowania sieci. Krótko mówiąc, MS Project jest narzędziem przydatnym do prowadzenia budowy biurowców, a nie do programowania.

2) Nie komplikuj. Standardowy format arkusza, który sam używam do planowania, jest tak prosty, że możesz go się nauczyć na pamięć. Zacznij od zaledwie siedmiu kolumn:

Feature Funkcja
Task Zadanie
Priority Priorytet
Orig Est Oryginalny szacunek
Curr Est Bieżący szacunek
Elapsed Ilość godzin, która upłynęła do tej pory
Remain Pozostało do zakończenia

Jeśli masz do czynienia z większą liczbą programistów, to albo sporządź oddzielny arkusz dla każdego z osobna, albo utwórz kolumnę, w której zapiszesz imię programisty odpowiedzialnego za daną czynność.

3) Każda funkcja programu powinna odpowiadać kilku zadaniom. Funkcja, to na przykład korekta pisowni. Na zbudowanie korektora pisowni składa się kilka oddzielnych zadań, które programista musi wykonać. Najważniejszą częścią sporządzania planu jest właśnie spisanie tych czynności. Stąd następująca kardynalna reguła:

4) Tylko ten programista, który będzie pisał kod źródłowy programu, może zaplanować niezbędny do tego czas. Każdy inny sposób, w którym kierownictwo decyduje o harmonogramie wykonania i po prostu wręcza go programistom, jest z góry skazany na niepowodzenie. Tylko ten programista, który będzie nad zadaniem pracował, może poprawnie zdefiniować niezbędne kroki prowadzące do wykończenia zadanej czynności. I tylko ten programista może zaplanować, jak długo każdy z tych krokow zajmie.

5) Wypracuj bardzo szczegółową listę zadań. To jest najważniesze, aby Twój harmonogram w ogóle działał. Twoje wyszczególnione zadania powinny być mierzone w godzinach, a nie w dniach. (Kiedy widzę harmonogramy wyrażone w dniach, a nawet tygodniach, od razu wiem, że nie są one realne). Możesz myśleć, że jedyną przewagą harmonogramu wyrażonego w bardziej dokładnych jednostkach jest tylko jego lepsza precyzja. Błąd! Duży błąd! Jeśli zaczniesz od z grubsza określonego planu i zaczniesz go analizować, rozkładając na czynniki pierwsze, przekonasz się, że otrzymasz odpowiedź zupełnie inną, nie tylko bardziej precyzyjną. Będzie to zupełnie inna wartość. Dlaczego tak się dzieje?

Otóż, kiedy jesteś zmuszony do dokładnego wyszczególnienia czynności, zmuszasz się do faktycznego przeanalizowania kroków, które będziesz musiał podjąć. Napisać podprogram foo(). Skonstruować taki dialog. Wczytać plik wawa. Te kroki łatwo zaplanować, ponieważ już kiedyś pisałeś podprogramy, konstruowałeś dialogi i wczytywałeś pliki.

Jeśli to robisz od niechcenia i wybierasz duże, „grube” kroki („wdrożyć automatyczną korektę gramatyki”), to nie przemyślałeś, co tak naprawdę będziesz musiał zrobić. A jeśli nie przemyślałeś, co będziesz musiał zrobić, nie możesz mieć pojęcia ile czasu Ci to zajmie.

W ogólności, każde zadanie powinno mieścić się w zakresie od 2 do 16 godzin. Jeśli masz w swoim harmonogramie 40-godzinną1 czynność, nie zaplanowałeś jej wystarczająco szczegółowo.

A oto kolejny powód, dla którego powinieneś wyszczególniać zadania z drobiazgową dokładnością: otóż zmusza Cię to do zaprojektowania tych funkcji! Jeśli masz bliżej niesprecyzowane zadanie zatytułowane &bdqup;Integracja z Internetem” i zaplanowałeś na nie 3 tygodnie, jesteś stracony, Kolego! Jeśli natomiast zostajesz zmuszony wyszczególnić jakie podprogramy będziesz musiał napisać, przymusza Cię to poniekąd do precyzyjnego rozpracowania całej funkcjonalności. Będąc zmuszonym planować na przyszłość z taką precyzją, eliminujesz mnóstwo niepewności związanych z całym projektem.

6) Nie spuszczaj z oka ani oryginalnego planu, ani jego obecnego stanu. W momencie, kiedy dodajesz jakieś zadanie do harmonogramu po raz pierwszy, oszacuj ile godzin Ci zajmie jego wdrożenie i wpisz to zarówno w kolumnie Orig Est, jak i w kolumnie Curr Est. W miarę upływu czasu, jeśli czynność zajmuje więcej (albo mniej) czasu niż myślałeś, możesz wprowadzić poprawkę do kolumny Curr Est, tak często, jak tylko potrzeba. To jest najlepszy sposób na uczenie się na własnych błędach i dokształcanie samego siebie w sztuce planowania. Większość informatyków nie ma pojęcia, jak oszacować, ile czasu coś zajmie. To nic nie szkodzi. Pod warunkiem, że ciągle się uczysz i ciągle wprowadzasz poprawki do planu, w miarę uzupełniania swoich umiejętności, plan będzie działał. (Będziesz może musiał zrezygnować z niektórych funkcji albo opóźnić całkowite wdrożenie, ale harmonogram jako taki nadal będzie funkcjonował, jak należy, w tym sensie, że będzie cały czas mówił Ci, kiedy z jakiejś funkcji zrezygnować i kiedy opóźnić oddanie projektu). Z mojego doświadczenia wynika, że większość programistów zaczyna świetnie planować po około roku praktyki.

Kiedy zadanie jest zakończone, wartości w kolumnach Curr Est i Elapsed będą identyczne, a kolumna Remain będzie automatycznie wyzerowana.

7) Poprawiaj kolumnę Elapsed codziennie. Tak naprawdę, to nie musisz wcale posługiwać się stoperem, kiedy pracujesz. Po prostu, zanim wyjdziesz po pracy do domu albo zanim zaśniesz pod biurkiem (jeśli należysz do tej akurat kategorii maniaków) udaj, że pracowałeś 8 godzin (ha!), przypomnij sobie jakie zadania wykonywałeś i porozdzielaj w sumie około 8-miu godzin w kolumnie Elapsed jak trzeba. Kolumna Remain zostanie automatycznie podliczona przez Excela.

Przy okazji, skoryguj kolumnę Curr Est, aby te zadania odpowiadały rzeczywistości. Codzienna korekta całego harmonogramu nie powinna zajmować dłużej niż około dwóch minut. Dlatego właśnie moja metoda planowania jest „bezbolesna” — jest szybka i łatwa.

8) Wprowadź do harmonogramu indywidualne elementy odpowiadające urlopom, dniom świątecznym itp. Jeśli cały plan zajmuje około roku, każdy programista weźmie około 10 do 15 dni urlopu2. Powinieneś mieć w swoim harmonogramie funkcje: urlopy, święta oraz inne, które odzwierciedlają wszystko, co zabiera pracownikom czas. Cała zabawa polega na tym, że datę ukończenia projektu można obliczyć poprzez zsumowanie kolumny Remain i podzielenie rezultatu przez 40. To jest właśnie liczba tygodni pracy pozostałych do zakończenia.

9) Włącz czas odpluskwiania (debugging) do harmonogramu! Odpluskwianie jest najtrudniejsze do zaplanowania. Przypomnij sobie poprzedni projekt, nad którym pracowałeś. Jest wielce prawdopodobne, że odpluskiwanie zajęło od 100%-200% czasu, który poświęcono na napisanie kodu w pierwszym rzędzie. To musi być samodzielna pozycja w harmonogramie — prawdopodobnie najbardziej znacząca pozycja.

Oto, jak to działa. Załóżmy, że programista pracuje nad funkcją wawa. Orig Est wyszedł na 16 godzin, ale do tej pory poświęconych zostało już na pracę nad tą funkcją 20 godzin i wygląda na to, że będzie potrzebnych jeszcze dalszych 10. Programista wpisuje więc 30 w kolumnie Curr Est oraz 20 pod Elapsed.

Na końcu całego etapu, prawdopodobnie wszystkie te poślizgi łącznie dają całkiem pokaźną sumę. Teoretycznie, aby dostosować się do tych poślizgów, musielibyśmy obciąć niektóre funkcje, aby zdążyć na czas. Na szczęście, pierwszą funkcją, którą możemy obciąć, jest wielkie zadanie zwane Buforem, na które przeznaczone było mnóstwo godzin.

Generalnie, wszyscy powinni odpluskwiać swój kod, kiedy nad nim pracują. Programista nie powinien nigdy, przenigdy zaczynać pracy nad nowym kodem, jeśli w starym są jeszcze błędy. Liczba błędów powinna być cały czas utrzymywana na jak najniższym poziomie, z dwóch powodów:

1) O wiele łatwiej jest odpluskwić program tego samego dnia, kiedy napisało się jego kod źródłowy. Odpluskwianie w miesiąc później może być bardzo kosztowne i pracochłonne. Zapomniało się już wówczas jak właściwie dany fragment kodu żródłowego działa.

2) Odpluskwianie działa tak, jak prowadzenie badań naukowych. Nie ma sposobu na to, aby przewidzieć kiedy się dokona „odkrycia” i wyeliminuje błąd. Jeżeli cały czas ma się na liście nie więcej niż jeden, dwa błędy, łatwo jest przewidzieć kiedy produkt będzie ukończony, ponieważ nie ma się wtedy do czynienia ze zbyt wielką ilością niewiadomych. Z drugiej strony, jeśli ma się na liście setki albo tysiące błędów, niemożliwością jest przewidzenie kiedy wszystkie będą naprawione.

Jeżeli programiści zawsze naprawiają swoje błędy w miarę postępu prac, to po co w ogóle wyszczególniać odpluskwianie jako oddzielne zadanie w harmonogramie? Cóż, nawet jeśli będziesz próbował naprawić wszystkie błędy tak szybko, jak tylko się pojawiły, zawsze znajdzie się mnóstwo błędów do naprawiania wówczas, kiedy testerzy (zarówno wewnętrzni, jak i betatesterzy) znajdą te naprawdę trudne do naprawienia.

10) Wlicz czas integracji do harmonogramu. Jeśli masz do czynienia z więcej niż jednym programistą, nieodwołalnie okaże się, że pomiędzy tym, co wyprodukuje jeden, a tym, co wymyśli drugi, powstaną niezgodności, które trzeba będzie rozwiązać. Mogą, na przykład, obaj stworzyć okienka dialogów w tym samym celu, które się jednak niepotrzebnie będą różniły od siebie szczegółami. Ktoś będzie musiał przejrzeć wszystkie menu, skróty klawiatury, paski narzędzi, itp., porządkując i organizując wszystkie nowe opcje w menu, które to każdy dodawał jak popadnie. Okaże się, że pojawią się błędy w kompilacji programu w momencie, kiedy tylko dwoje ludzi wprowadzi swój kod źródłowy do repozytorium. To będzie musiało być naprawione, więc powinno figurować jako oddzielna pozycja w harmonogramie.

11) Dodaj margines czasowy do harmonogramu. Praca ma tendencję do poślizgu. Są dwa rodzaje marginesu, które powinieneś wziąć pod uwagę. Pierwszy, to bufor, który zneutralizuje zadania, które zabrały więcej czasu, niż planowano. Drugi, to margines, który przyda się na zadania, o których nie wiedziałeś, że będziesz musiał wykonać. Zwykle jest tak, że szefostwo zadecydowało, iż na przykład zaimplementowanie wawa jest BARDZO WAŻNE i nie może być odroczone do następnej wersji.

Być może zdziwi Cię, kiedy się przekonasz, że urlopy, święta, odpluskwianie, integracja i czas buforowy zabierają łącznie dłużej niż właściwe zadania. Jeśli Cię to zaskakuje, to podejrzewam, że nie zajmowałeś się oprogramowaniem zbyt długo, nieprawdaż? Możesz zignorować te moje wskazówki na swoją własną odpowiedzialność.

12) Nigdy, przenigdy nie pozwól szefom zmuszać programistów do zredukowania szacunkowej ilości godzin. Wielu początkujących szefów myśli, że może „pobudzić” swoich ludzi do szybszej pracy zadając im gruntownie zredukowane (niemożliwe do zrealizowania) harmonogramy. Uważam, że tego typu „pobudzanie” graniczy z obłędem. Kiedy nie nadążam za swoim harmonogramem, czuję się źle, jestem w depresji i brak mi motywacji. Kiedy wyprzedzam mój plan, jest mi wesoło i jestem produktywny. Harmonogram to nie jest miejsce na gry i zabawy psychologiczne.

Jeśli Twój szef zmusza Cię do zredukowania Twojego szacunkowego planu, oto co powinieneś zrobić. Stwórz nową kolumnę w Twoim arkuszu do planowania zatytułowaną „Plan według Ryśka” (zakładając, że masz na imię Rysiek, oczywiście). Pozwól szefowi robić, co tylko chce, z kolumną Curr Est. Nie zwracaj uwagi na oszacowanie szefa. Pod koniec projektu okaże się, kto był bliżej rzeczywistości. Z własnego doświadczenia wiem, że świetne wyniki daje nawet tylko sugestia, że się to zrobi. Zwłaszcza, kiedy szef zda sobie sprawę, że własnie ogłosił konkurs na to, jak najwolniej będziesz umiał pracować!

Dlaczego nieudolni szefowie próbują zmusić programistów do zaniżania ich oszacowań?

Na początku projektu, szefowie techniczni spotykają się z personelem nietechnicznym i wymyślają listę funkcji, które łącznie mają ponoć zająć 3 miesiące do wdrożenia, a tak naprawdę zabiorą 9. Kiedy próbujesz wymyśleć, jak coś zaprogramować, bez dokładnego rozeznania we wszystkich krokach jakie muszą być podjęte, zawsze wydaje Ci się, że się to da zrobić w czasie n, kiedy w rzeczywistości będziesz potrzebował czasu 3n. Jeśli natomiast sporządzasz prawdziwy harmonogram, sumujesz wszystkie zadania i odkrywasz, że projekt zabierze znacznie dłużej, niż się początkowo spodziewano. Prawda wychodzi na wierzch.

Nieudolni szefowie próbują się z tym problemem uporać myśląc, jak by tu zmusić ludzi, aby pracowali szybciej. To nie jest zbyt rzeczowe podejście. Możesz zatrudnić więcej ludzi, ale oni też będą potrzebowali czasu na to, aby się włączyć i będą pracowali na 50% swojej wydajności przez pierwsze kilka miesięcy (obniżajac przy tym wydajność tych, którym przyszło im pomagać). Chcąc nie chcąc, w obecnej sytuacji na rynku pracy3, zatrudnienie nowego programisty zabierze 6 miesięcy.

Może Ci się nawet udać przez pewien czas wydobyć 10% więcej surowego kodu z ludzi, ale za cenę 100-procentowego ich wykończenia w przeciągu roku. Niezbyt wielki sukces i trochę wygląda tak, jak zjadanie własnego ziarna siewnego.

Może Ci się udać wyżyłować 20% więcej surowego kodu z ludzi poprzez nakłanianie ich do ekstra-wydajnej pracy, bez względu na to, jak są zmęczeni. Bum! Czas odpluskwiania w konsekwencji podwaja się. Idiotyczne posunięcie, które odwzajemnia się we wspaniale ironiczny sposób.

W każdym razie nigdy, przenigdy nie uzyskasz 3n z jednego n, a jeśli Ci się wydaje, że to potrafisz, proszę Cię, wyślij mi symbol giełdowy Twojej firmy, abym mógł się jej zawczasu wyzbyć.

13) Harmonogram działa trochę tak, jak pudełko z drewnianymi klockami. Jeśli masz sporo klocków i nie możesz ich zmieścić do pudełka, masz dwa wyjścia: znaleźć większe pudełko, albo wyzbyć się niektórych klocków. Jeśli Ci się wydawało, że ukończysz w ciągu 6-ciu miesięcy, a plan mówi 12 miesięcy, to albo będziesz musiał opóźnić ukończenie, albo znaleźć jakieś funkcje do obcięcia. Nie da się zmniejszyć klocków, a jeśli będziesz udawał, że możesz to zrobić, to zwyczajnie pozbawiasz się niepowtarzalnej okazji, aby naprawdę móc przewidywać przyszłość, gdyż kłamiesz sobie samemu na temat tego, co tam tak naprawde widać.

I wiesz co? Drugą zaletą planowania z prawdziwego zdarzenia jest to, że zmusza Cię ono do obcinania opcji. Dlaczego to jest zaleta? Wyobraź sobie, że masz dwie funkcje do wdrożenia: jedna jest naprawdę użyteczna i ulepszy Twój produkt znacząco (przykład: tabele w Netscape 2.0) i druga, która jest wyjątkowo łatwa, i którą programiści bardzo chcieliby wdrożyć (przykład: znacznik BLINK), ale która niczemu nie służy ani nie przyczynia się do uzyskania przewagi na rynku.

Jeśli nie opracujesz harmonogramu, programiści będą najpierw pracować nad łatwą i przyjemną funkcją. Potem zabraknie im czasu i nie będziesz miał wyboru, tylko będziesz musiał opóźnić ukończenie projektu, aby móc dokończyć tę ważną i użyteczną funkcję.

Jeśli sporządzisz harmonogram, już zanim zabierzesz się do właściwej pracy, zorientujesz się, że coś trzeba będzie obciąć. A zatem wyeliminujesz łatwą i przyjemną funkcję, a pozostawisz tylko użyteczną i ważną. Zmuszając się do usunięcia niektórych funkcji, przekonasz się, że w krótszym czasie zbudujesz stabilniejszy, bardziej spójny produkt.

Pamiętam, kiedy pracowałem nad Excelem 5. Nasza oryginalna lista zadań była ogromnie długa i spowodowałaby straszny poślizg w harmonogramie. O rany! — myśleliśmy. To wszystko są bardzo ważne funkcje. Jak można przeżyc bez automatycznego edytora makr?

Jak się okazało, nie mieliśmy wyjścia, i okroiliśmy — jak się nam wydawało „do kości” — wszystkie możliwe funkcje, aby tylko zdążyć na czas. Nikt z powodu tych cięć nie był zadowolony. Aby się pocieszyć, po prostu powiedzieliśmy sobie, że tak naprawdę nie eliminujemy tych opcji, tylko je odraczamy do czasu Excela 6, ponieważ nie są aż tak priorytetowe.

Kiedy Excel 5 był już bliski ukończenia, zacząłem z kolegą Erykiem Michelmanem pracować nad specyfikacją Excela 6. Zasiedliśmy do listy owych domniemanych funkcji Excela 6, które zostały wcześniej usunięte z planu Excela 5. Byliśmy kompletnie zaskoczeni, kiedy się okazało, że jest to najbardziej beznadziejna lista funkcji, jaką można sobie było wyobrazić. Żadna z tych funkcji nie była warta pracy. Nie sądzę, aby chociaż jedna z nich kiedykolwiek została wdrożona w jakiejkolwiek z trzech następnych wersji programu. Proces eliminacji funkcji, aby zmieścić się w harmonogramie, był najlepszą rzeczą, jaką mogliśmy zrobić. Gdybyśmy tego nie zrobili, Excel 5 byłby nam zajął dwa razy więcej czasu i zawierał 50% nikomu niepotrzebnych śmieci. (Nie mam najmniejszych wątpliwości, że ten właśnie los spotkał Netscape 5/Mozillę: nie mają harmonogramu, nie mają skonkretyzowanej listy funkcji, nikt nie miał ochoty wyeliminować żadnych funkcji i po prostu nigdy nie ukończyli projektu. Kiedy wreszcie ukończą, będą mieli mnóstwo zbędnych funkcji, jak na przykład klient IRC4 , nad którymi nie powinni byli spędzać w ogóle czasu.)

Dodatek: To, co powinieneś wiedzieć o Excelu

Excel jest takim świetnym narzędziem do pracy nad harmonogramowaniem oprogramowania, ponieważ do tego wykorzystywali go jego twórcy. (Niewielu z nich prowadzi interesy, w których potrzebowaliby jego analitycznych funkcji... rozmawiamy tu o programistach!)

Wspólne listy. Komenda Pliki/Wspólne listy (File/Shared Lists) umożliwia wszystkim dostęp do tego samego pliku w tym samym czasie i jednoczesne wprowadzanie zmian. To jest naprawdę pomocne, ponieważ cała Twoja grupa powinna bezustannie wprowadzać poprawki do harmonogramu.

Automatyczny filtr. To jest świetny sposób na przesiewanie elementów planu tak, aby na przykład, widzieć tylko swoje własne zadania. Dodaj do tego jeszcze automatyczne sortowanie (Auto Sort) i masz listę Twoich osobistych zadań, według ich priorytetu, czyli swoją własną listę „Do Zrobienia”. Suuuuuper!

Tabele przestawne. To jest świetny sposób na oglądanie podsumowań i tabel wzajemnych zależności. Na przykład, możesz sporządzić wykres pokazujący liczbę godzin, która pozostała każdemu z programistów, posortowaną według priorytetu zadań. Tabele przestawne to jak mleko z miodem. Musisz się ich nauczyć, ponieważ ich zastosowanie powiększa możliwości Excela milion razy.

Funkcja WORKDAY (dzień pracy) z dodatkowego zestawu analitycznego (Analysis Toolpack) Excela jest świetnym sposobem na dobranie się do dat kalendarzowych w Bezbolesnym Harmonogramie.

[1] Chodzi o zadanie, które zaplanowane jest na cały tydzień. 40 godzin to standardowy tydzień pracy w USA.(przyp. tłum.)

[2] W USA programista ma zwykle około 1-2 tygodni urlopu w roku. (przyp. tłum.) W Polsce może to być nawet 26 dni (przyp. redaktora).

[3] Artykuł był napisany w marcu 2000, tuż przed wielkim krachem firm internetowych na giełdzie w USA, w okresie szczytu zatrudnienia w informatyce. (przyp. tłum.)

[4] IRC to skrót od Internet Relay Chat, czyli Internetowy Czat. (przyp. tłum.)



Oryginał ukazał się w wersji angielskiej pod nazwą Painless Software Schedules  

Joel Spolsky jest założycielem Fog Creek Software, małej firmy programistycznej w Nowym Jorku. Ukończył Uniwersytet Yale i  pracował jako programista i menedżer w Microsofcie, Viacom i Juno.


Zawartość tych stron wyraża opinie jednej osoby.
Cała zawartość prawnie chroniona. Copyright ©1999-2005 by Joel Spolsky. Wszelkie prawa zastrzeżone.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky