"Cześć, Amigo!"
"Cześć, Bilaabo!"
„Dzisiaj opowiem wam o tym, jak zazwyczaj rozwija się programy”.
„W XX wieku, kiedy nowoczesne technologie informatyczne były w powijakach, wszyscy myśleli, że programowanie jest jak budowanie lub produkcja”.
„Zwykle sprawy szły mniej więcej tak:”
„ Klient wyjaśniał, jakiego rodzaju programu potrzebuje — co powinien robić i jak powinien to robić”.
„ Analitycy biznesowi słuchali go i sporządzili pełną listę wymagań programowych na podstawie tego, co powiedział”.
„Wtedy kierownicy projektów podzieliliby te wymagania na zadania, a także ustaliliby, który programista wykona jakie zadanie iw jakiej kolejności”.
"Wtedy programiści brali się do pracy. Czasami pracowali kilka lat(!)."
„Kiedy skończyli, program został przekazany testerom”.
„ Testerzy przechodzili przez każde z wymagań programu, aby sprawdzić, czy zostały one zaimplementowane i czy program działał tak, jak powinien”.
„Jeśli coś poszło nie tak, testerzy rejestrowali błędy i wysyłali je do programistów”.
„Wtedy programiści naprawiali błędy i wysyłali naprawiony program z powrotem do testerów. I cykl się powtarzał”.
„Gdy główne błędy zostały naprawione, program został przekazany klientowi”.
– Naprawdę tak się sprawy potoczyły?
„Cóż, oczywiście, wiele uprościłem, ale jest to bardzo zbliżone do tego, jak to zrobiono”.
„A ukończenie projektu może zająć od półtora roku do dwóch lat?”
„Czasami, jeśli rozwój projektu był naprawdę długi, dzielili go na oddzielne wersje. Co 3-6 miesięcy programiści musieli stworzyć określoną część funkcjonalności programu, przetestować go, naprawić wszystkie błędy i pokazać to klient."
„Po pierwsze, żeby mógł podzielić się swoimi wrażeniami. A po drugie, co ważniejsze, żeby dalej płacił za rozwój programu”.
"Płać dalej?"
„Wtedy rozwój często trwał 2-3 razy dłużej niż planowano. A ponieważ programiści często otrzymywali wynagrodzenie godzinowe, program stał się 2-3 razy droższy. Co więcej, korzyści również zostały zmniejszone. W końcu to, czego klient chce dzisiaj za 100 000 USD może nie być potrzebny w ciągu 3 lat — zwłaszcza za trzykrotność ceny”.
„Czy klienci często odmawiali zapłaty?”
"Tak. Później zaczęli dodawać kary do kontraktu, ale to nie poprawiało sytuacji. Rozwój oprogramowania ciągnął się w nieskończoność. I nikt nie mógł nic z tym zrobić, nawet gdyby chciał."
"Ale dlaczego?"
„Cóż, po pierwsze, na etapie planowania wiadomo zbyt mało. Najczęściej na początku nikt nie był w stanie przewidzieć problemów, przed którymi staną programiści”.
„Ale doświadczeni programiści powinni byli być w stanie wszystko przewidzieć, prawda?”
„Widzisz, że programowanie to wyjątkowy zawód”.
„Zwykły pracownik często wykonuje w kółko tę samą pracę. Zegarmistrzowie robią zegarki, kucharze gotują, nauczyciele uczą, lekarze leczą itd.”
„Każdy z tych profesjonalistów robi w zasadzie to samo dzień w dzień. W rezultacie zaczynają stawać się coraz lepsi w swojej pracy”.
„W programowaniu podejście jest inne. Gdy tylko programista staje każdego dnia przed tym samym zadaniem, pisze funkcję, moduł lub program do jego wykonania i nigdy więcej do niego nie wraca”.
„Każdy programista zwykle rozwiązuje każde zadanie raz w życiu”.
„Coś w rodzaju naukowców lub inżynierów projektantów, którzy coś wymyślają”.
„Ach. Cóż, jaka jest najważniejsza rola w projekcie?”
„Hmm, jak mam na to odpowiedzieć. Łatwo powiedzieć, co jest najważniejsze, ale zidentyfikowanie najmniej ważnego jest trudne”.
„ Podstawowym zadaniem testera ( zapewnianie jakości , QA ) jest monitorowanie stanu programu i szybkie zgłaszanie błędów. Im więcej i wcześniej tester znajduje błędy, tym więcej można naprawić. Dobry tester ma większy wpływ na jakość produktu niż robi to dobry programista ”.
„Dlaczego programista nie może testować własnych programów. W końcu czy oni nie wiedzą lepiej niż testerzy, co działa, a co nie?”
„Dobry programista po prostu nie jest w stanie być dobrym testerem. Programista naprawdę dobrze wie, jak działa program, więc zawsze używa go w określony sposób. W przeciwieństwie do zwykłych użytkowników, którzy korzystają z programu tak, jak chcą. "
„Dodatkowo, testerzy nie testują tego, co jeszcze nie działa. Tester testuje funkcjonalność lub części programu, które zdaniem programisty już działają prawie idealnie”.
„A kiedy tester znajdzie mnóstwo błędów w tej funkcjonalności, a programista je naprawi, wtedy produkt faktycznie zbliża się do perfekcji”.
„ Podstawowym zadaniem programisty ( Software Developer Engineer , Developer , SDE ) jest wdrażanie nowych funkcjonalności. Lub mówiąc prościej, wykonywanie powierzonych mu zadań. Gdy programistom przydzielane są zadania z nowymi funkcjami , wykonują je. Kiedy przypisuje się im błędy, naprawiają je”.
„Czasami zdarzają się jednak bardziej wymagające zadania, na przykład wymyślenie architektury programu lub jego części. Im lepsza proponowana architektura, tym łatwiej będzie wykonywać zadania w przyszłości”.
„Problem polega na tym, że architekturę należy wybrać na samym początku, ale dopiero w trakcie opracowywania staje się jasne, czy wybrałeś właściwą architekturę”.
„Dodatkowo, jeśli architektura się powiedzie, a program okaże się świetny, to klient prawdopodobnie będzie chciał go wykorzystać jako podstawę do nowych wersji programu”.
„Oto, do czego zmierzam”.
„Jakąkolwiek architekturę wybierzesz, zawsze będzie mnóstwo zmian, dodatków i nowych funkcji, których architektura nie uwzględnia”.
„Oto dobry przykład”.
„Klient prosi cię o zbudowanie 5-piętrowego budynku, więc projektujesz architekturę i budujesz dom”.
„Następnie klient prosi o dodanie kolejnej historii, a potem kolejnej i tak dalej”.
„Ale ściany pierwszego piętra nie były zaprojektowane na taki ciężar, podobnie jak fundamenty. Więc wszystko trzeba przerobić”.
„Ale po ukończeniu 5-piętrowego budynku, co jeśli klient natychmiast zdecyduje, że chce 50-piętrowego budynku?”
„Łatwiej byłoby zburzyć istniejącą konstrukcję i odbudować wszystko od podstaw…”
„Ale mam dla ciebie jedną radę dotyczącą architektury”.
„Architektura aplikacji musi być przede wszystkim elastyczna, co oznacza, że nie będziesz musiał zaczynać od zera, jeśli zdecydujesz się przerobić połowę aplikacji. Ten typ architektury jest zwykle nazywany elastyczną i modułową ” .
„ Podstawowym zadaniem kierownika projektu jest podejmowanie decyzji. Kierownik projektu to ten, który widzi szerszy obraz i podejmuje decyzje w oparciu o tę perspektywę”.
„Załóżmy, że podczas opracowywania staje się jasne, że pewne zadanie nie zostanie ukończone zgodnie z planem. Kierownik projektu może wtedy:”
„ a) spróbuj wynegocjować z klientem modyfikację zadania”
„ b) przeznaczyć więcej czasu na zadanie”
„ c) sprowadzić bardziej doświadczonych programistów z innych projektów.”
– I jest wiele innych możliwości.
„Każda opcja wymaga poświęcenia czegoś, a zadaniem menedżera jest zminimalizowanie całkowitych strat wynikających z tych poświęceń ” .
„Załóżmy na przykład, że konkurenci kradną głównego programistę, oferując mu dwa razy więcej pieniędzy”.
„Kierownik projektu może:”
" a) nic nie robić. Programista odejdzie, a projekt prawdopodobnie zostanie opóźniony i poniesie kary."
„ b) podwoić jego pensję. Wtedy wszyscy inni w zespole też będą chcieli podwyżek. Jeśli dasz im wszystkim więcej pieniędzy, to koszty projektu wzrosną i może on stać się nieopłacalny.”
„ c) jakaś inna opcja, którą wymyślisz”.
"Widzę."
„Przy złym kierowniku projektu dobry zespół zwykle wydłuża projekt, ale nie zawsze”.
„Dobry menedżer z zespołem przeciętnych programistów prawie zawsze ukończy projekt szybciej niż zły menedżer z zespołem doskonałych programistów”.
"Widzę."
- Dobrze, zróbmy sobie krótką przerwę, a potem będziemy kontynuować.