WATS Linia 54

uncle bob label image
Tego ranka miałem interesującą rozmowę z Doc'iem Nortonem. Skłoniło mnie to do rozmyślań...
Wiesz co to jest numer 800. Niektórzy ludzie nazywają je "bezpłatna infolinia". Firma Telekomunikacyjna nazywa je liniami WATS. Wide Area Telephone Service.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


W roku 1976 podjąłem pracę w firmie na przedmieściach Chicago. Nazywała się Teradyne Central. Robiliśmy sprzęt testujący dla firmy telekomunikacyjnej. Nasz produkt nazywał się 4-Tel. Testował każdą linię telefoniczną, w jednym obszarze świadczenia usług, każdej nocy. Jeden obszar świadczenia usług telefonicznych mógł mieć 100'000 linii lub więcej.
System 4-Tel mógł mieć podłączonych do niego jednocześnie 21 terminali. Każdy terminal mógł był użyty przez testera do testowania linii telefonicznej gdziekolwiek w obszarze świadczenia usług. Test mógł wykryć i zdiagnozować dowolne problemy tych linii; i mógł określić czy dany problem jest po stronie centrali, samej linii czy telefonu klienta. To było ważne, ponieważ te trzy tematy były rozwiązywane przez oddzielne zespoły. Wysłanie odpowiedniego zespołu do odpowiedniego problemu pozwalało oszczędzić dużo pieniędzy.
4-Tel miał wiele innych fajnych funkcji. To był pokaźny system z wieloma przypadkami użycia. I był zainstalowany na obszarze całych Stanów Zjednoczonych.
Kiedy jeden z naszych klientów miał problem, mógł zadzwonić pod numer 800. To automatycznie przełączało go do jednej z dwóch naszych linii WATS. Jeżeli to było w czasie normalnych biznesowych godzin pracy, nasza recepcjonistka odebrałaby linię WATS. Gdy już upewniłaby się, że to klient dzwoni z prośbą obsługi serwisowej, prosiłaby o chwilę cierpliwości i mówiłaby przez nasz wewnętrzny system do powiadamiania:
Czy ktoś z oprogramowania mógłby odebrać WATS linię 54.
Kiedy to było już po godzinach, my, w laboratorium, mogliśmy tylko słyszeć dzwonek linii WATS.
Nie ważne, która to była godzina, zawsze odbieraliśmy.
Było nas około tuzin w zespole programistycznym. Szukalibyśmy najbliższego telefonu z migającą lampką oznaczoną "54". Ktokolwiek był najbliżej telefonu odebrałby telefon. Gdybym to był ja, powiedziałbym:
Teradyne Central Oprogramowanie: Mówi Bob Martin.
I wtedy zaczęlibyśmy procesować problem, i poradzilibyśmy klientowi, co robić.
Czasami, oczywiście, to był błąd pilota, który mogliśmy szybko naprawić. Czasami to był znany problem w naszym systemie, dla którego mogliśmy przedstawić obejście. I czasami to był nowy defekt lub problem, który musieliśmy zdiagnozować na miejscu.
Tak czy siak wisieliśmy na telefonie z klientem dopóki problem nie został rozwiązany.

Inżynierowie Odpowiedzialni

Może mógłbyś zapytać dlaczego nie mieliśmy działu obsługi klienta załatwiającego tego typu telefony; i wpisującego defekty w system śledzenia defektów. Odpowiedź do tego jest prosta. Czuliśmy się odpowiedzialni za system. Chcieliśmy wiedzieć czego doświadczają nasi klienci. Nie chcieliśmy mieć warstwy ludzi izolujących nas od problemów, które to my tworzyliśmy w terenie.
Mieliśmy taki termin w Teradyne: Inżynier Odpowiedzialny. To był podtytuł po linią podpisu na każdym Inżynieryjnym Zleceniu Zmiany. My podpisywaliśmy się pod zmianami, które robiliśmy. My byliśmy Inżynierami Odpowiedzialnymi.
Takie znaczenie miał właśnie dla nas ten termin. My czuliśmy się odpowiedzialni. I dlatego nie chcieliśmy czegokolwiek izolującego nas od rzeczywistych sytuacji naszych klientów.
W Teradyne prowadziliśmy nasz własny QA. Robiliśmy nasze własne DevOpsy. Robiliśmy naszą własną obsługę klienta. I często podróżowaliśmy do lokalizacji klienta żeby pracować z inżynierami Obsługi w Terenie.
W rzeczywistości, to była częsta praktyka dla każdego developera oprogramowania, żeby spędzić dzień lub dwa jeżdżąc z monterem telefonicznym; tylko po to, byśmy mogli zrozumieć, z czym ci goście musieli się mierzyć i jak oni naprawdę używali naszego systemu.

Izolacja

Współczesne zespoły programistyczne są zwykle mocno odizolowane. Żyją w świecie wolnym od rozproszeń pochodzących od klientów i ich "drobnych" problemów. Istnieją całe grupy ludzi, które służą izolowaniu programistów od prawdziwego świata. Dział Obsługi Klienta. Dział Jakości. DevOps. Proszę bardzo, do wyboru do koloru. I dlaczego te grupy w ogóle istnieją? Istnieją, ponieważ we wszystkich z tych dziedzin developerzy oprogramowania zawiedli tak bardzo, że firmy musiały się bronić tworząc całe nowe departamenty i struktury zarządcze.
Myślę, że to jest wstyd. Jak możesz być rzemieślnikiem oprogramowania, jeśli nie porozumiewasz się ze swoim prawdziwym klientem? Jak możesz być rzemieślnikiem oprogramowania, jeśli nie doświadczasz bezpośrednio tych koszmarów, które tworzysz dla devopsów? Jak możesz być rzemieślnikiem oprogramowania, jeśli zostawiasz wszystkie swoje bugi do znalezienia dla działu QA?


Rzemiosło Oprogramowania

Wydaje mi się, że rzemieślnik oprogramowania jest Inżynierem Odpowiedzialnym. Rzemieślnik Oprogramowania nigdy nie będzie odizolowany od prawdziwego świata klienta, od devopsów, od QA, od czegokolwiek jeszcze. Do obowiązków zespołu rzemieślników oprogramowania powinno zaliczać się QA; powinno zaliczać się devops; powinno zaliczać się obsługę klienta. I każdy członek takiego zespołu powinien być zdolny zastąpić każdego innego członka zespołu.
Nie ma nic złego w specjalizacji. Jest wiele złego w izolacji.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


W Dużej Skali

uncle bob label image
Od pierwszych chwil rewolucji Agile zastanawialiśmy się nad pytaniem o Agile w Dużej Skali. Jak możemy wziąć zasady lekkiego, częstego, przyrostowego, o wysokim poziomie informacji zwrotnej rozwoju oprogramowania i zastosować je do naprawdę ogromnych projektów?

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Pierwszymi odpowiedziami były takie rzeczy jak Scrum Scrumów. Pomysł był taki, żeby rekurencyjnie zastosować zasady rozwoju oprogramowania Agile na coraz wyższych poziomach skali. Projekt, który wymagał więcej niż jednego zespołu składającego się z 5-12 developerów mógłby być zbudowany z dwóch takich zespołów z zespołem wyższego poziomu do "doglądania?" ich.
Zauważ znak zapytania. Jak tylko zaczynamy rozważać większe projekty, nie udaje nam się uniknąć hierarchii; ale hierarchia wydaje się być herezją w Agile. Poza tym Agile jest o egalitaryźmie. Jest o odrzuceniu zarządzania i kontroli. Jest o odrzuceniu planów i harmonogramów i...
Ooo, co za bzdety! Nie jest!
Agile był rewolucją w sensie "obrotu koła". We wczesnych dniach pisaliśmy kod w zwinny sposób. Pisaliśmy małe kawałki, testowaliśmy je, łączyliśmy je w większe kawałki, testowaliśmy te kawałki w nigdy nie kończącym się cyklu. Jeżeli wróciłbyś do późnych lat 60-tych XX. wieku i popatrzył na kod, który był wówczas pisany, zauważyłbyś fragmenty Agile.
Oczywiście byliśmy ogromnie skrępowani technologią. Kompilacje zajmowały godziny. Edycja była robiona na dalekopisach. Większość programistów w tamtych czasach nie wiedziała, jak w ogóle używać klawiatury; mieli więc swoich operatorów dziurkarek, którzy wprowadzali ich kod za nich. W tego typu środowisku szybkie pętle odpowiedzi zwrotnej były trudne do osiągnięcia.
Nawet wtedy, robiliśmy wszystko, co tylko mogliśmy, żeby skrócić nasze pętle. Pisaliśmy w assemblerze, więc mogliśmy siedzieć przy konsoli i debuggować łatając nasz software przy użyciu liczb ósemkowych lub hexów. Testowaliśmy nasz kod uruchamiając go w debbugerze, lub nawet na jednokrokowym komputerze[1]. Byliśmy w tym całkiem dobrzy. To był jedyny sposób na zrobienie roboty w ciągu czegokolwiek bliskiego sensownemu przedziałowi czasu.
Ale koło kręciło się dalej. Zaczęliśmy używać języków, które nie były łatwe do debugowania w konsoli. Zaczęliśmy pisać coraz większe i większe programy. Żeby zrobić robotę w środowisku z tak długimi pętlami zwrotnymi potrzebowaliśmy planów.
To jest to środowisko, z którego wyłonił się waterfall. Kiedy ogarnięcie pętli wyedytuj/skompiluj/przetestuj zajmuje cały boży dzień, potrzeba wiele planowania i sprawdzania. Nie możesz robić TDD i Refaktoringu w 24 godzinnej pętli!
Ale koło kręciło się dalej. Prawo Moora wrzuciło nas na wykładniczą krzywą, o której większość dzisiejszych programistów nie ma bladego pojęcia. Poszliśmy od 24 godzinnych obrotów w 1970, do 60 minutowych obrotów w 1980, do dziesięciominutowych obrotów w 1990, do dziesięciosekundowych obrotów w 2000. I do 2005 roku czas obrotu dla większości programistów był poniżej sekundy.
To jest to środowisko, z którego wyłoniło się Agile. Agile było powrotem do szybkich obrotów, szybkiego feedbacku, strategii rozwoju oprogramowania z lat 60 XX. wieku, ale z o wiele potężniejszymi maszynami, o wiele lepszymi językami i narzędziami, i w większych projektach.
Ale Agile wyłoniło się także z płomieni. Waterfall, choć konieczny w latach 70-tych i 80-tych, był ekstremalnie bolesny. Dużo się nauczyliśmy przez te dziesięciolecia o tym czego nie robić. Więc, gdy Agile wyłonił się pod koniec lat 90-tych niósł ze sobą te lekcje, które odbyliśmy podczas tych ciemnych czasów.
Agile nie był tylko po prostu powrotem do krótkich cykli informacji zwrotnej. Agile wymusił dyscypliny na bazie tych krótkich cykli informacji zwrotnej. Dyscypliny takie jak testowanie, refaktoryzacja, programowanie w parach i intensywna automatyzacja. To prawda, że Agile był obrotem koła, ale gdy koła się obracają ciągną pojazd do przodu. Agile zdecydowanie popchnął nas do przodu w stosunku do strategii z lat 60-tych.
Ale do przodu z czym? Co było tym czymś ulepszonym przez rewolucję Agile?
Agile było rewolucją w tym, w jaki sposób stosunkowo małe zespoły mogą rozwijać stosunkowo małe projekty oprogramowania. Zauważ nacisk na słowo mały.
Zespół Agile jest świetny do stworzenia systemu oprogramowania o około 100'000 liniach kodu. I te 100'000 linii kodu może zrobić naprawdę wiele. Więc dla wielu przedsiębiorstw jeden lub dwa zespoły Agile są wystarczające do zrobienia czegokolwiek, co tylko te przedsiębiorstwa chcą zrobić.
Z drugiej strony, jeśli potrzebujesz stworzyć system na dziesięć milionów linii, jeden zespół Agile nie da rady. Potrzebujesz około setki zespołów żeby zbudować system z dziesięciu milionów linii kodu.
Ale jak zarządzisz setką zespołów agile'owych? W jaki sposób podasz im historyjki użytkownika. Jak skoordynujesz interfejsy pomiędzy nimi? Jak posegregujesz te dziesięć milionów linii kodu w sposób, w którym te zespoły będą mogły pracować niezależnie od siebie?
I jak (i to było prawdziwe pytanie) zrobisz to w sposób "Agile"?
Odpowiedź brzmi: nie zrobisz!
Sprawa jest taka. My, ludzie jesteśmy całkiem dobrzy w budowaniu wielkich projektów. Wiedzieliśmy jak to robić już od całkiem długiego okresu czasu.



Tylko pomyśl o naprawdę dużych projektach, które, my ludzie, ukończyliśmy.
  • Apollo: wrzuciliśmy człowieka na księżyc!
  • D-Day: Zaatakowaliśmy Normandię z 156'000 żołnierzy w poprzek 50 milowej, ciężko ufortyfikowanej granicy.
  • Mamy światową ekonomię utrzymującą 8 miliardów ludzi.
  • Świat jest pokryty ogromną cyfrową siecią pozwalającą czytać Ci ten tekst na telefonie w chwili, kiedy łazisz po lesie!
  • Potrzebujesz wihajster? Będziesz go miał dostarczony jutro, albo nawet dziś, po kilku dotknięciach palca na Twoim telefonie.
Nie potrzebuję iść dalej. My, ludzie, jesteśmy całkiem dobrzy w robieniu wielkich rzeczy. To jest to kim jesteśmy. To jest to co robimy. Wrzucamy czerwone, sportowe samochody na orbitę heliocentryczną. My robimy duże rzeczy.
Więc po co w ogóle przejmujemy się wielkim oprogramowaniem? My już dawno wiemy jak budować wielkie oprogramowanie. Robimy to już od 50 lat lub więcej. "Wielka" część nigdy właściwie nie była problemem. Problem, który rozwiązaliśmy dzięki "Agile" to była mała część. To, czego nie widzieliśmy jak robić dobrze, to było prowadzenie małych projektów.
Zawsze wiedzieliśmy jak robić wielkie projekty. Prowadzisz wielkie projekty w taki sposób, że dzielisz je na kilka małych projektów. Agile załatwiło tę "małą" część. Agile tak naprawdę nie ma nic wspólnego z tą dużą częścią.
Ale, ale, ale, ale... Egalitaryzm! Odrzucenie planów i Zarządzania i Kontroli! Agile!
Byzydury!
Agile nigdy nie był o egalitaryźmie. Agile nigdy nie był o odrzuceniu planów, albo o odrzuceniu zarządzania i kontroli. W rzeczy samej, Agile było wcieleniem komórki najmniejszego poziomu zarządzania i kontroli: Zespołu.
Tak, w pewnym momencie na drodze w dół hierarchii, zarządzanie i kontrola przestaje być efektywna. Mały zespół osób może pracować razem w krótkich cyklach z dużym poziomem informacji zwrotnej i intensywnym porozumiewaniem się, aby osiągnąć cel. To jest zespół Agile. Na tym poziomie ostre zarządzanie i kontrola są bardzo szkodliwe. Ale powyżej tego poziomu kontrola i zarządzania zaczynają być niezbędne. Im wyżej idziesz, tym bardziej konkretne i oczywiste to się staje. Nie projektujesz, budujesz, produkujesz i sprzedajesz setek milionów iPhone'ów bez straszliwej ilości zarządzania i kontroli.
Jest całkiem sporo strategii Agile W Dużej Skali tu i tam. Były na ten temat pisane książki i blogi. Całe przedsiębiorstwa doradcze były tworzone, aby wprowadzać podejście Agile W Dużej Skali do innych przedsiębiorstw. Nie ma w tym nic złego.
Nie ma nic złego w tych strategiach i technikach opisanych przez te podejścia Agile W Dużej Skali. Oprócz jednej rzeczy. Nie są Agile. Nie mają nic wspólnego z Agile. Raczej, one są odmianą strategii i technik "w klimacie" Agile, których ludzie używali przez tysiąclecia do tworzenia wielkich rzeczy.
Ten klimat wynika z użycia słownictwa i pomysłów z Agile. Nie ma nic złego w tym klimacie - jest w porządku. Jeżeli uważasz, że używanie słów i pomysłów Agile coś daje, idź w ten klimat. Ale nadmiernie nie przejmuj się rzeczywistą "Agile-nością" tego. W momencie, gdy robisz coś dużego, opuszczasz krainę Agile. Zapewne Twoje zespoły programistyczne używają dyscyplin Agile; ale całościowy projekt nie jest już Agile.
Bo Agile jest o małych rzeczach.

[1] W tych dniach, komputery miały przełączniki na przednim panelu, co pozwalało Ci zatrzymać wykonywanie, i wtedy mogłeś uruchamiać poszczególne instrukcje programu krok po kroku. Panel przedni miał światełka, które pokazywały zawartości różnych rejestrów. To pozwalało Ci obserwować, co się działo podczas wykonywania Twojego programu.
Spójrz na przełączniki po prawej na dole na obrazku poniżej. Zobaczysz przełączniki Sing Step i Sing Inst. Sing Step - jeden krok to był jeden cykl zegara. Instrukcja zawsze trwała kilka cykli zegara. Mogłeś więc obserwować jak uruchomienie instrukcji działa od wewnątrz.



Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.