Tak jak plan jest używany w budownictwie, a przepis jest przestrzegany podczas przygotowywania posiłku, istnieją zasady, których należy przestrzegać, aby skutecznie rozwijać oprogramowanie. Zasady te sprowadzają się do tego, co zwykle określa się mianem metodologii tworzenia oprogramowania. Metodologia rozwoju oprogramowania jest niezbędna, ponieważ zawiera procedury, które prowadzą do sukcesu projektu rozwoju oprogramowania.
Bez przestrzegania planu w budownictwie, wyniki oznaczają katastrofę, tak samo jak budowanie produktu oprogramowania bez przestrzegania właściwych zasad. Pominiesz wiele kluczowych kroków i w końcu będziesz miał niezliczoną ilość problemów z jakością oprogramowania. Jako kierownik projektu, ważne jest, aby wiedzieć, że istnieje wiele podejść do naśladowania dla projektu oprogramowania, w tym szczupłe podejście rozwoju i że po wybraniu prawidłowo, metodologia rozwoju oprogramowania zawsze będzie produkować wysokiej jakości produkt software.
Lean Software Development
Lean metodologia rozwoju jest typem zwinne podejście, które zostało założone na zasadach lean manufacturing. Lean manufacturing obejmuje bardzo skuteczne zasady, które zostały po raz pierwszy wykorzystane przez Toyota Production System jako praktyka zarządzania i optymalizacji procesu produkcji pojazdów w celu zwiększenia wartości dla klienta i zminimalizowania marnotrawstwa.
Więc, jeśli zasady lean mają związek z produkcją pojazdów silnikowych, to gdzie jest rozwój oprogramowania? Wiemy, że produkcja i rozwój oprogramowania są różne – produkcja obejmuje tworzenie produktów fizycznych, podczas gdy produkt rozwoju oprogramowania jest niematerialny, a jego wartość może być postrzegana i tworzona tylko w umysłach zespołu programistów.
Mapping między lean manufacturing i lean software development po raz pierwszy pojawił się w 2003 roku w książce zatytułowanej „Lean Software Development: An Agile Toolkit” autorstwa Mary i Toma Poppendieck. W książce tej Poppendieckowie wyjaśniają, w jaki sposób zasady lean manufacturing mogą być produktywnie zastosowane do rozwoju oprogramowania. Zarówno produkcja, jak i rozwój oprogramowania opierają się na powtarzalnych procedurach i wymagają precyzyjnych standardów jakości. Ich działanie opiera się również na pracy zespołowej. Tak więc, siedem zasad lean manufacturing może mieć zastosowanie i być wykorzystane w rozwoju oprogramowania.
Seven Lean Principles to Follow for Software Development
Z powodu umożliwienia szybszego sposobu rozwoju produktów oprogramowania, zwinne podejścia rozwojowe są popularne dla wielu firm rozwojowych. Takie firmy już wdrażają zasady szczupłego rozwoju. Oto 7 zasad lean, które możesz zastosować w swoich projektach rozwoju oprogramowania:
- Eliminuj marnotrawstwo
Pierwszą zasadą, której należy przestrzegać w lean development, jest eliminacja wszystkiego, co nie przynosi wartości użytkownikowi końcowemu. W rozwoju oprogramowania, zasada ta może być wdrożona poprzez zidentyfikowanie wartości produktu, który ma być zbudowany. Gdy to zostanie zrobione, łatwiejsze stanie się wykrycie „marnotrawstwa” – wszystkiego, co nie dodaje wartości do produktu i ostatecznie do użytkowników, w tym niepotrzebnego kodu, niejasnych wymagań, dodatkowych funkcji i procesów, itp. Inne fazy metodyki, które nie wnoszą żadnej wartości, również muszą zostać usunięte. Istnieją narzędzia pomagające w identyfikacji marnotrawstwa w rozwoju oprogramowania, w tym Mapowanie Strumienia Wartości.
- Twórz Wiedzę
Rozwój oprogramowania sam w sobie jest postępem generującym wiedzę. Zasada tworzenia wiedzy zachęca więc zespoły programistyczne do posiadania odpowiednich struktur umożliwiających prawidłowe uczenie się. Brzmi prosto, ale zasada ta wymaga całkowitego skupienia i zaangażowania. Można ją wdrożyć poprzez przeprowadzanie szkoleń, przeglądy kodu, odpowiednie komentarze do kodu, programowanie w parach, dokumentację projektu, sesje dzielenia się i inne.
- Buduj jakość w
Zespół lean development powinien zapewnić, że jego uwaga skupia się na rozwijaniu jakości w produkcie. Nie powinien zatem polegać na koncepcji zapewnienia bezbłędnego produktu końcowego. Odwrotnie, zespoły powinny kontynuować ulepszanie procesu rozwoju i zaprzestać rozpraszania defektów w produkcie od samego początku, aby uzyskać funkcjonalny produkt końcowy.
- Szybkie dostarczanie
Techniki rozwoju zwinnego koncentrują się na dostarczaniu oprogramowania tak szybko, jak to możliwe. Lean development będący zwinnym podejściem również kładzie nacisk na szybkie dostarczanie oprogramowania. Oznacza to, że zespół projektowy musi dostarczyć użytkownikom docelowy komponent w odpowiednim czasie. Dla swojego zespołu, stwórz równe i stabilne przepływy pracy, które pochodzą ze zrozumienia wartości procesu, aby ułatwić szybsze wyniki.
- Umocnij swój zespół
Umocnienie swojego zespołu projektowego wymaga, abyś szanował wszystkich – ludzie pracujący razem jako zespół powinni szanować się nawzajem. Kiedy coś pójdzie nie tak, a w większości przypadków tak będzie, nie obwiniaj ludzi. W zastępstwie sprawdź, czy w procesie nie ma luk, które mogłyby prowadzić do wyzwań i konfliktów. Stwórz korzystne środowisko pracy dla wszystkich i dawaj przykład. Dodatkowo, pozwól na innowacyjną swobodę członkom zespołu w wyborze i identyfikacji właściwych podejść i narzędzi dla każdego przydzielonego zadania.
- Opóźnienie w podejmowaniu decyzji
Wiem, że brzmi to kontrowersyjnie, ponieważ konwencjonalnie mamy tendencję do pracy z podejmowaniem decyzji tak szybko, jak to możliwe. Jako zasada Lean, późne podejmowanie decyzji nie oznacza nieodpowiedzialności w podejmowaniu decyzji. Zamiast tego, zachęca zespół projektowy do pozostawienia otwartych opcji na dłuższy okres czasu, aby zebrać więcej danych i informacji, które mogą pomóc w podjęciu kluczowych decyzji. Zwlekanie z podjęciem decyzji daje więcej czasu na naukę i zdobycie większej wiedzy, co skutkuje jeszcze lepszymi decyzjami. W konsekwencji Twój projekt nie ucierpi na negatywnych skutkach, które mogłyby wynikać ze złego podejmowania decyzji. Pomyśl o tym, czy wolałbyś podjąć pochopną decyzję i później jej żałować, czy poświęcić trochę czasu na zebranie informacji i podjąć właściwą decyzję?
- Optymalizacja całości
Zawsze dąż do optymalizacji całego procesu rozwoju, a nie tylko podprocesów. Jeśli dodasz wartość tylko do jednego lub tylko kilku procesów, będzie to miało wpływ na produkt końcowy, a Twoje wyniki będą niezoptymalizowane. Nie powinieneś wprowadzać na rynek gorszego produktu, ponieważ nie miałeś wystarczająco dużo czasu. Aby poradzić sobie z sub-optymalizacją, zasada optymalizacji jako całości zachęca do eliminacji błędnych cykli rozwoju i testowania, a zamiast tego do działania z dużo lepszymi możliwościami pracy. Optymalizacja całościowa pozwala na identyfikację przepływu wartości procesu dla całego zespołu, co umożliwia szybsze i wartościowe dostarczanie. Tak więc, skup się na całym strumieniu wartości od początku do końca, aby osiągnąć optymalizację.
.