Opracowywanie przepisów to proces uczenia się metodą prób i błędów. Nie oczekujesz, że pierwsza próba nowego dania wykonana przez szefa kuchni będzie ostatnią. W rzeczywistości cała idea opracowywania przepisu polega na wypróbowaniu wielu wariacji na dany temat i odkryciu najlepszej wersji.
Rozwój jest czymś zupełnie innym niż produkcja. Pomyśl o rozwoju jako o tworzeniu przepisu, a o produkcji jako o przestrzeganiu przepisu.
Co ta metafora ma do wytwarzania oprogramowania?
Dwie szkoły myślenia
Istnieją dwie szkoły myślenia o tworzeniu softu. Pierwsza z nich zachęca programistów do upewnienia się, że każdy projekt i każdy segment kodu jest prawie doskonały (bezbłędny, podatny na przyszłe zmiany) za pierwszym razem.
W koncepcji drugiej szkoły lepiej jest mieć małe, szybkie cykle try-it, test-it, fix-it, niż upewniać się, że projekt i kod są doskonałe za pierwszym razem. To bardziej zwinne podejście zakłada, że pętla zwrotna służy, a nie szkodzi.
Natomiast tradycyjne podejście do zarządzania projektami często mówi o tym, że pętle sprzężenia zwrotnego stanowią zagrożenie, ponieważ istnieje obawa, że uczenie się związane ze sprzężeniem zwrotnym może zmodyfikować wcześniej ustalony plan.
Konwencjonalna mądrość w zarządzaniu projektami ceni sobie dyrygowanie zakresem, kosztami i harmonogramem zgodnie z pierwotnym planem. Nic dziwnego, przecież szczegółowy scenariusz daje (złudne) poczucie kontroli i bezpieczeństwa, przynajmniej na jakiś czas.
To podejście można nazwać modelem deterministycznym, ponieważ zakłada, że detale projektu są ustalone na początku.
Sekwencyjna produkcja
Często konsekwencją deterministycznego modelu (skierowanego na produkowanie zamiast na odkrywanie) jest sekwencyjne wytwarzanie usług. Czyli najpierw stwórzmy moduł (jeszcze gorzej: pełnoprawną mikrousługę) rejestracji i zarządzania użytkownikami, a następnie moduł sprzedaży.
Problem z rozwojem sekwencyjnym polega na tym, że zmusza projektantów czy programistów do przyjęcia podejścia dept-first zamiast breadth-first.
Depth-first wymusza podejmowanie niskopoziomowych, zależnych decyzji przed doświadczeniem konsekwencji decyzji wysokopoziomowych. Konsekwencje natomiast doświadczysz dopiero po implementacji.
Najbardziej kosztowne błędy popełniane są przez to, że zapomina się o rozważeniu czegoś ważnego na początku. Najłatwiejszym sposobem popełnienia takiego błędu jest właśnie zbyt szybkie wwiercanie się w szczegóły.
Efektywne rozwijanie
Kiedy doświadczonym projektantom przedstawia się źle zdefiniowane problemy, ich działania projektowe wcale nie są odgórne. Wielokrotnie przechodzą oni pomiędzy badaniem scenariusza, wyjaśnianiem wymagań, segmentacją rozwiązania na wysokim poziomie i projektowaniem trudnych szczegółów implementacyjnych.
Alternatywą dla modelu deterministycznego – zresztą w zgodzie z metodyką lean i prawidłami matki natury, która wszystko tworzy przez ewolucję, a nie na podstawie z góry określonego planu – jest rozwijanie, czyli odkrywanie nieznanego. Kluczem do efektywnej nauki i rozwoju jest często wiele krótkich cykli uczenia się.
Jeśli zamiast tego zapytasz: “Jak mogę zminimalizować liczbę cykli uczenia się?”, prawdopodobnie otrzymasz długie cykle, długie pętle sprzężenia zwrotnego, a w rezultacie nie efektywne uczenie się.
Podsumowanie
Różnica pomiędzy świadczeniem usługi a wytwarzaniem fizycznych produktów polega na tym, że w usłudze dynamicznie zmieniają się oczekiwania klienta, natomiast w produkcji zmienność jest wrogiem. Produkcja zakłada jednorodny, niezmienny zestaw oczekiwań, stawia na powtarzalność.
Idąc tym tropem, rozwoju oprogramowania nie należy nazywać produkcją. Tworzenie oprogramowania to ciągły proces uczenia się, eksperymentowania i wzajemnej oceny.
Oczywiście można polegać na szczegółowym planie opracowanym z wyprzedzeniem, jednak sterowanie deterministycznie nie pasuje do środowiska, w którym ciągle zmienia się teren.
Źródła
Udostępnij ten wpis
Dobrnąłeś do końca. Jeśli ten artykuł był dla Ciebie wartościowy i chcesz otrzymywać informacje o kolejnych, to zapraszam Cię do zapisania się do listy mailingowej. Gwarantuję zero spamu.
Radek.
Inne artykuły
