4 mity produktywności

Chcesz poprawić produktywność wytwarzania oprogramowania u siebie, w swoim zespole lub organizacji? Czytaj dalej, a razem obalimy kilka mitów.

Szybkość a jakość

Mit: Każdy projekt w wytwarzaniu oprogramowania jest kompromisem między szybkością a jakością.

Prawda: W produktywności wytwarzania oprogramowania nie ma konfliktu między szybkością a jakością.

„Gdy jakość jest dobra, wytwarzanie jest łatwiejsze."

Wysoka jakość umożliwia wysoką prędkość. To jest wniosek z wielu popularnych metod agile, takich jak programowanie sterowane testami (TDD), ciągła integracja i DevOps. Jeśli przestaje się wystarczająco koncentrować na jakości, narastają coraz większe długi techniczne. Dość szybko cały budżet pochłania utrzymanie i nie pozostaje nic na inwestycje. Musisz utrzymywać swój system (lub środowisko systemowe) w stanie, w którym możesz faktycznie coś zmieniać lub ulepszać.

Jeśli chcesz dowiedzieć się więcej o jakości i o tym, jak ją osiągnąć, polecam Ci World Quality Report.

Umiejętności a ilość

Mit: Deweloperzy oprogramowania to tylko zasoby i można ich w razie potrzeby wymieniać.

Prawda: Jeśli chodzi o produktywność w wytwarzaniu oprogramowania, istnieją duże różnice między poszczególnymi deweloperami!

Istnieją indywidualne różnice między poszczególnymi deweloperami. Załóżmy po prostu, że przeciętny deweloper ma produktywność 1. Zły programista może mieć produktywność 0 lub nawet -1. Oznacza to, że wydajność złego i przeciętnego dewelopera mogą się faktycznie wzajemnie znosić. Superświetny programista może jednak mieć produktywność 10 lub nawet 30. Taki deweloper może zastąpić całe zespoły deweloperów. Tak więc tak, chodzi o posiadanie właściwych ludzi.

Zbudowanie wysokowydajnego zespołu w wytwarzaniu oprogramowania wymaga czasu. Jeśli nie skupiasz się wyraźnie na budowaniu tzw. transaktywnej pamięci (transactive memory) w zespole, minął rok, zanim ta poprawa nastąpi sama z siebie. Ludzie nie są doniczkowymi roślinami, które można po prostu przestawić z miejsca na miejsce na polecenie ogrodnika. Są drzewami z głębokimi korzeniami. Ich korzenie zostają uszkodzone i pozostawiają duże otwory, gdy są przesadzane.

Agile a kaskada

Mit: W innych branżach z powodzeniem stosuje się metodę kaskadową i dlatego my też powinniśmy to robić.

Prawda: Od lat 50. XX wieku wiele się zmieniło i nawet w budownictwie nie pracuje się już metodą kaskadową.

Istnieje fundamentalna różnica między produkcją masową (reprodukcją) a branżami z dużo większą niepewnością i pracą projektową, jak w wytwarzaniu oprogramowania czy nawet w branży budowlanej. Ale chwileczkę, czy budownictwo nie jest sztandarowym przykładem metody kaskadowej? Wszystko zaczyna się od architekta, potem przechodzi do inżynierów, budowy budynku i wreszcie jego użytkowania. Tak, tak było w latach 50., kiedy budowanie budynków odbywało się na niezagospodarowanym terenie. Ale to się zmieniło. W budownictwie chodzi dziś o renowację, odnowę i przebudowę istniejących budynków – a nikt nie wie, co kryje się w ścianie czy pod podłogą. Budownictwo też zmierza ku bardziej zwinnemu podejściu.

Oczywiście w Agile są pewne warunki wstępne, aby wszystko dobrze działało, ale nie można ich pozbyć się przez ich ignorowanie. Jeśli jeszcze nie pracujesz zwinnie, przejście na zwinność jest niezwykle ważne dla poprawy produktywności i rozwiązywania problemów.

Chmura a lokalna instalacja

Mit: Chmura to po prostu serwery w chmurze – nie może poprawić Twojej produktywności.

Prawda: Chmura jest jednym z najsilniejszych silników produktywności w wytwarzaniu oprogramowania.

… i to nawet jeśli postrzegasz chmurę jedynie jako sposób na wynajem serwerów (Infrastructure-as-a-Service), co samo w sobie ma wyraźne zalety dla produktywności w wytwarzaniu oprogramowania. Możliwość uzyskania zupełnie nowego środowiska w ciągu kilku sekund umożliwia na przykład ciągłą integrację i wdrożenie, a nawet DevOps, co może znacznie zwiększyć produktywność. Chmura to jednak coś więcej niż tylko infrastruktura. Dziś kwestią zaledwie kilku godzin jest rozpoczęcie sprzedaży pierwszych produktów w swoim sklepie internetowym po zakończeniu projektowania. I to wszystko dzięki Manufacturing-as-a-Service, Logistics-as-a-Service, a nawet eCommerce-as-a-Service. To samo dotyczy nie tylko produktów fizycznych, ale również wytwarzania oprogramowania.

Niniejszy tekst pochodzi z bloga Gregera Wikstranda i został przez nas przetłumaczony na język polski.