Ucieczka z Wyspy Gilligana

Oryginalny post: Escaping From Gilligan’s Island

Autor: Jeff Atwood

Uważam, że warto odświeżyć listę klasycznych błędów procesu tworzenia aplikacji stworzoną przez Steve’a McConnella, oraz towarzyszące jej studium przypadku, przynajmniej raz do roku. Zastopujcie mnie, jeżeli słyszeliście to już wczesniej:

“Spójrz Mike” powiedział Tomas. “Mogę przekazać mój kod dzisiaj i nazwać go ukończonym, ale prawdopodobnie będę potrzebował jeszcze trzech tygodni na uporządkowanie go, jeśli go teraz oddam.” Mike zapytał, co Tomas miał na myśli przez „uporządkowanie”. „Nie dostałem logo firmy żeby umieścić na każdej stronie i nie dostałem nazwiska i numeru telefonu agenta do umieszczenia w stopce każdej strony. Drobiazgi w tym stylu. Wszystkie ważne funkcje działają dobrze. Praca jest ukończona w 99 procentach.”

Jak głosi stare przysłowie programistów, pierwsze dziewięćdziesiąt procent zadania zajmuje dziewięćdziesiąt procent czasu, a ostatnie dziesięć procent zadania zajmuje kolejne dziewięćdziesiąt procent czasu.

Klasyczne Studium przypadku błędu czyta się z pewnym niepokojem. Być może przesadzone, ale jest to dziwnie dokładne streszczenie wszystkich patologicznych projektów programistycznych, w których brałem udział, czyli w praktyce prawie wszystkich, z jakimi miałem do czynienia.

To zjawisko McConnell przyrównuje do mechanizmu znanego z Wyspy Gilligana. Co tydzień pojawia się tam jakiś nowy, szalony plan ucieczki z wyspy, ale na koniec odcinka rozbitkowie zawsze zostają uziemieni na wyspie co najmniej na kolejny tydzień.

Jeżeli na pierwszy rzut oka nie widzisz powiązań z procesem tworzeniem oprogramowania, pozwól mi przypomnieć długą i ponurą historię błędów w projektach programistycznych. Klasyczne błędy są klasycznymi, ponieważ są tak kuszące. Musisz aktywnie rozpoznawać kiedy wpadasz w jedną z tych pułapek. Jak powiedział kiedyś Steve w jednym z wywiadów:

Właściwie to sukces w tworzeniu oprogramowania zależy nie tyle od niepopełniania kilku błędów, co od dążenia do robienia większości rzeczy prawidłowo.

Oczywiście niezbędne do tego jest doświadczenie zdobyte w poprzednich projektach oraz wiedza zdobywana poprzez odpowiednie szkolenia. Zarządzanie projektem programistycznym jest procesem w pewnym zakresie powtarzalnym. Właśnie dlatego powinniście od teraz mieć w pamięci każdy z poniższych 36 klasycznych błędów podkreślonych w książce McConnela Rapid Development:

Błędy ludzkie	Błędy procesu	Błędy produktu	Błędy technologiczne
Podważona motywacja Słabi ludzie Niekontrolowani problematyczni pracownicy Bohaterstwo Dodawanie ludzi do spóźnionego projektu Głośne, zatłoczone biura Tarcia pomiędzy twórcami a klientami Nierealistyczne oczekiwania Brak efektywnego sponsoringu projektów Brak zainteresowanych stron Brak zdania użytkownika Polityka ponad istotą sprawy Pobożne życzenia	Zbyt optymistyczne planowanie czasu Niedostateczne zarządzanie ryzykiem Błędy wykonawców Niewystarczające planowanie Rezygnacja z planowania pod presją Strata czasu na rozmyty początek Niewystarczające aktywności początkowe Nieodpowiednie projektowanie Niewystarczające zapewnianie jakości Niewystarczająca kontrola zarządzania Przedwczesna lub zbyt częsta zbieżność Planowanie nadrobienia później Tworzenie kodu rodem z piekła	Zbytnie precyzowanie wymagań Zbytnie dodawanie funkcjonalności Zbytni perfekcjonizm programistów Przepychanki w negocjacjach Programowanie sterowane badaniami	Szybkie rozwiązywanie kłopotliwych spraw Przeszacowane oszczędności z tytułu użycia nowych narzędzi lub metod Zmiana narzędzi podczas trwania projektu Brak automatycznej kontroli wersji

Zacząłem coraz mocnej wierzyć, że jedyną różnicą pomiędzy doświadczonymi, a niedoświadczonymi programistami jest to, że ci doświadczeni mają świadomość popełnianych błędów. Ta sama reguła odnosi się do projektów programistycznych i menadżerów projektów. Jeżeli nie przeglądasz aktywnie Klasycznych Błędów Rozwoju Programowania podczas prac nad projektem, nie masz nawet pojęcia, jak duże jest prawdopodobieństwo, że właśnie robisz jeden z tych błędów.

Popełnianie błędów jest nieuchronne, ale powtarzanie tych samych w kółko już niekoniecznie. Powinieneś postarać się, by popełniać całkowicie nowe, spektakularne, nigdy nie widziane przedtem błędy. Na koniec, Steve McConnell podkreślił kilka nowych klasycznych błędów na swoim blogu, które chce dodać do kanonu 10 lat później:

• Mylenie oszacowań z celami
• Nadmierna wielozadaniowość
• Założenie, że całościowy development ma niewielki wpływ na łączne wysiłki
• Niejasna wizja projektu
• Zaufanie do mapy większe niż do terenu
• Outsourcing jako zmniejszenie kosztów
• Pozwolenie by ludzie pracowali w oddzieleniu od siebie (zastępując poprzednie “braki w zarządzaniu”)

Steve szuka też naszej opinii. Wydał Ankietę odnośnie Klasycznych Błędów i zaprosił każdego do udziału. Jeżeli macie jakiekolwiek doświadczenie w tworzeniu oprogramowania, proszę, przyłączcie się.

To prawda, wszystko przemawia przeciwko wam. Ale to dobry pomysł, by okresowo przypominać sobie, że może, tylko może – jeżeli będziecie w stanie unikać popełniania tych samych klasycznych błędów, które popełniono w tak wielu poprzednich projektach przed Tobą - moglibyście któregoś dnia wydostać się z wyspy.

Data publikacji oryginału: 18 czerwca 2007