Produkcja a rozwój oprogramowania [zamknięte]

Często mówi się, że przemysł oprogramowania jest niedojrzały w porównaniu do produkcji. Szczególnie w odniesieniu do napędzania procesami.

Pytanie : Czy my, programiści, możemy uczyć się na podstawie procesów przemysłu produkcyjnego? Czy przyjęcie ich procesów może zwiększyć wskaźnik sukcesu oprogramowania?

Moje zdanie : w produkcji tworzenie produktu jest silnie uzależnione od procesu. Możesz mieć fabrykę, w której każda osoba ma określony zestaw zadań, które wykonuje. Pracownik (lub robot) może dokręcać śrubę przez cały dzień. Następnie następne zadanie w tym procesie wykonuje następny specjalista. Pracownicy (i roboty) nie powstrzymują się od procesu ani nie wymyślają czegoś „w locie”. Części przechodzą przez cały proces, a wynikiem jest produkt gotowy. Działa dobrze, a firmy osiągają 99,99966% produktów wolnych od wad. Z czasem firmy eliminują nieefektywności. Jest to imponujące i bardzo dobrze może być znakiem dojrzałej branży.

W produkcji zdefiniowany proces może dosłownie stworzyć gotowy produkt. Nie sądzę, że tak jest w przypadku oprogramowania. Możemy mieć procesy kontroli źródła, przeglądu kodu, arkuszy odprawy, zbierania wymagań, SDLC itp. Jednak wykonanie tych procesów nie jest samo w sobie stworzeniem gotowego produktu. Procesy te mogą być korzystne, ale są prostopadłe do rzeczywistego stworzenia.

Załóżmy, że twoja firma jest zobowiązana do stworzenia oprogramowania, które będzie wyszukiwać miliony obrazów w celu znalezienia twarzy przestępców. Pomimo ciężkiego środowiska opartego na procesach, deweloper musi angażować się w tworzenie rzeczy „w locie”. Robienie rzeczy w locie jest sprzeczne z duchem produkcji. Dobry proces produkcyjny może zostać wykonany bez zastanowienia przez robota.

Do stworzenia skomplikowanych algorytmów, które należy jeszcze zgłębić w umyśle człowieka, konieczne jest tworzenie rzeczy w locie. Tworzenie oprogramowania nie jest następstwem procesu, ale tworzeniem procesów, które mają być wytłaczane przez komputer. To podstawowa różnica. Bez względu na to, ile procesów ortogonalnych zajmujemy się rozwojem, zawsze będziemy uciekać się do robienia tego „w locie”, jeśli chodzi o stworzenie.

Wydaje się, że wszyscy, z którymi rozmawiam, zgadzają się z myśleniem o produkcji. Czy jestem sam w swoich myślach?

Podstawowa różnica między opracowywaniem oprogramowania a produkcją polega na tym, że w przypadku oprogramowania faza projektowania jest praktycznie wszystkim. Rzeczywista produkcja (część linii montażowej w tradycyjnej produkcji) polega na skopiowaniu kilku plików dookoła. W oprogramowaniu projekt produktu jest produktem.

Tak, możemy uczyć się na podstawie procesów produkcyjnych, ale tylko wtedy, gdy pamiętamy, że musimy spojrzeć na fazę projektową, a nie fazę produkcyjną i że wiele procesów produkcyjnych jest zbudowanych tak, aby sprostać konkretnym ograniczeniom drogiego łańcucha produkcyjnego , który po prostu nie dotyczy oprogramowania.

Jednym z przykładów modelu procesu, który działa bardzo dobrze w oprogramowaniu, ale często strasznie zawodzi w projektowaniu produktu, jest projektowanie iteracyjne - zaczynasz od minimalnego prototypu i dodajesz funkcje z każdą iteracją. Zbudowanie prototypowego samochodu, aby zobaczyć, jak wygląda nowy wygląd gałki tylnej szyby, jest śmieszne, ale w oprogramowaniu ma sens (wystarczy nacisnąć F5 i poczekać kilka sekund - voilà, gotowy do jazdy testowej).

Jeśli przyjrzymy się procesom projektowania produktu, najlepsze branże, na które można spojrzeć, dzielą się na dwie kategorie:

• te, w których produkcja może być realizowana według stawek towarowych; np. przemysł muzyczny (1% lub mniej ceny płyty CD to pieczenie i drukowanie), media graficzne itp.
• te, w których ilości są tak niskie, że faza projektowania jest najbardziej znaczącym czynnikiem kosztowym (artykuły luksusowe, produkty wysoce dostosowane, rynki niszowe ...)

Podstawowym błędem jest próba zastosowania procesów od produkcji fizycznej do tworzenia oprogramowania: tworzenie oprogramowania nie jest powtarzalne (jeśli jest to praca, przejdź do innej pracy), jest tylko częściowo przewidywalne, istnieje tylko kilka ograniczeń fizycznych ( szybkość sprzętowa wynosi jeden), a zarówno przyjęte podejście, jak i wyniki mogą być bardzo osobiste. Zastosowanie filozofii linii montażowej do zasadniczo analitycznego i kreatywnego myślenia może (i często ma) niszczące skutki.

Jeśli chcesz ciągle pisać to samo oprogramowanie (w przeciwieństwie do zwykłego kopiowania), możesz to zrobić bardzo skutecznie za pośrednictwem linii montażowej.

Ale tworzenie oprogramowania nie jest powtarzalnym zadaniem, każdy moduł jest unikalny. Dlatego porównanie z produkcją jest nieprawidłowe.

Myślę, że odpowiedź, której szukasz, ma tutaj zastosowanie lub jest realistyczna. Czuję, że chcesz wiedzieć, w jaki sposób możemy sprawić, aby nasze procesy były bardziej podobne do branży produkcyjnej. Zamiast tego myślę, że prawdziwe pytanie brzmi: „Wiedząc, co robią producenci i inne branże, aby budować wysokiej jakości produkty, czego możemy się nauczyć?” lub „Co może zrobić przemysł oprogramowania, aby poprawić jakość?”

Niestety odpowiedź na to pytanie jest niejasna, ponieważ sama branża oprogramowania nadal nie zna odpowiedzi. Aby móc odpowiedzieć na to pytanie, przemysł oprogramowania musi przeprowadzić badania nad tym, co działa i dlaczego? Na przykład istnieją badania, które pokazują, że Test Drive Design (TDD) prowadzi do poprawy jakości. Chociaż kwestia produktywności nadal wydaje się pozostawiona bez odpowiedzi lub przynajmniej nie do końca jeszcze zrozumiana. O ile dotychczasowe dowody:

• Recenzje kodu są doskonałe i wykazano, że zawierają najwięcej błędów, ale skuteczność recenzji spada dość gwałtownie po pierwszej godzinie przeglądu. Biorąc pod uwagę, że przeciętny człowiek może odczytać tylko kilkaset wierszy kodu na godzinę, sugeruje to, że programiści powinni dzielić zmiany na mniejsze części.
• Im dłużej trzeba znaleźć błąd, tym droższe (czas i pieniądze) będzie go naprawić. Więc jeśli programista znajdzie go podczas pisania kodu, mówimy, że koszt wynosi 1. Jeśli unittest znajdzie go później, koszt to 10, jeśli EVT go znajdzie, koszt to 100 i tak dalej.
• Istnieją dowody, które sugerują, że im bardziej złożone są wymagania, tym bardziej złożone jest rozwiązanie, a im bardziej złożone jest rozwiązanie, tym większe prawdopodobieństwo wystąpienia błędów.

Jest człowiek o imieniu Greg Wilson, który kilka lat temu wspaniale o tym mówił. Oto link do rozmowy: Greg Wilson Talk

Oprócz tego powiedziałbym, aby spojrzeć wstecz na własną pracę i znaleźć tematy z rodzajami wprowadzanych błędów, a także z częściami, z którymi się zmagasz. Skompiluj te wyniki, a następnie utwórz listę kontrolną, aby wstawić do procesu w różnych miejscach, aby pomóc ci wykonać lepszą pracę. Osobiście spojrzałem na kilka ostatnich lat mojej pracy i odkryłem, że są pewne wspólne tematy problemów, które przedstawiam. W szczególności znalazłem to

• Nie zawsze pamiętam, żeby zbudować wszystkie warianty, co doprowadziło mnie do przerwania kompilacji.
• Wiele razy nie myślę o następujących dla każdej zmiany. Dobry przypadek, zły przypadek i wyjątkowe przypadki.
• Wszystkie możliwe scenariusze, które mogą się zdarzyć. Zauważ, że jest to naprawdę trudne, ponieważ jest ich wiele.

Ponieważ znalazłem kilka tematów do moich błędów, stworzyłem listy kontrolne, z których automatycznie korzystam, ponieważ wstawiam je do moich skryptów, które pomagają mi obejść te problemy. Na temat tego wezwania napisano „Manifest listy kontrolnej”, który szczegółowo opisuje, jak można je dobrze wykorzystać. Osobiście uważam to za bardzo wnikliwe.

Nie chodzi o przyjęcie „ich” procesów. Chodzi o przyjęcie „niektórych” procesów, które nie mają zwykłych i dobrze cenionych szkód w stosowaniu procesów linii montażowej do kreatywnych przedsięwzięć. Najważniejszą rzeczą, na którą należy tutaj zwrócić uwagę, jest to, że jakość procesów przekłada się bezpośrednio na jakość produktu.

Najlepsze procesy lub produkty w tym zakresie są takie, które pasują do zamierzonego scenariusza użytkowania, jak ręka w rękawicy. Rzeczą do przemyślenia jest to, że faktyczna część pisania kodu jest jedyną, która przynajmniej na poziomie makroskopowym nie jest powtarzalna. Wszystkie inne aspekty, takie jak kontrola wersji, śledzenie błędów, planowanie, szacunki, pomiary itp. Są, a użycie standardowego, dostosowanego i sprawdzonego procesu może ci pomóc przynajmniej w tych obszarach.

Tak więc nie, proces tworzenia oprogramowania nie może być przyrównywany do produkcji na linii montażowej i jako taki „ich procesy” nie są w porządku, ale faza projektowania / projektowania produktu w przemyśle wytwórczym może być tym, z którego można czerpać inspirację.

Pytanie: Czy my, programiści, możemy uczyć się na podstawie procesów przemysłu produkcyjnego? Czy przyjęcie ich procesów może zwiększyć wskaźnik sukcesu oprogramowania?

Odpowiedź: Tak, oczywiście. Istnieje wiele lekcji, których twórcy oprogramowania mogą się nauczyć z produkcji, mimo że tworzenie oprogramowania jest procesem twórczym. Samo tworzenie oprogramowania jest procesem i obejmuje wiele innych procesów. Im lepiej możesz zdefiniować i kontrolować te procesy, tym lepiej możesz ogólnie kontrolować proces tworzenia oprogramowania. Nie oznacza to, że powinieneś przepisywać każde naciśnięcie klawisza przez programistę; oznacza to po prostu, że jako programista naturalnie wykonujesz zadania w określonej kolejności, a tymi zadaniami często można zarządzać. Oto kilka przykładów:

• śledzenie defektów: co się stanie, gdy błąd zostanie zauważony lub zgłoszony? Czy zapisujesz go na skrawku papieru i przyklejasz na kolcu „śledczym”? Czy później usuwasz te skrawki pojedynczo, badasz je i ostatecznie przenosisz na „rozwiązany” skok? Jeśli zrobisz to bez przerwy za każdym razem, gdy otrzymujesz raport o błędzie, masz dobrze zdefiniowany, mierzalny proces i prawdopodobnie masz znacznie lepszą sytuację niż ktoś, kto ma wymyślny, zaawansowany technologicznie system śledzenia defektów, który jest tak uciążliwy że niektórzy członkowie zespołu śledzą błędy na inne sposoby lub wcale.

• kontrola wersji: istnieje duża szansa, że ​​używasz kontroli wersji w miejscu pracy, a kontrola wersji jest oczywiście o wiele bardziej przydatna, gdy wszyscy używają jej w ten sam sposób.

• projekt produktu: Czy decydujesz, które funkcje zastosować, rzucając rzutkami w ścianę pokrytą karteczkami samoprzylepnymi? Jeśli tak, masz proces. Nie sądzę, by ktokolwiek twierdził, że to świetny proces, ale przynajmniej jest to punkt wyjścia. Jeśli zmienisz proces, skąd możesz mieć pewność, że zmiana była rzeczywiście poprawą, chyba że dokonujesz pomiaru przed i po? Nie możesz

• recenzje kodu: czy przegląd kodu byłby przydatny, gdyby proces przeglądu i kryteria kodowania zmieniały się dla każdej recenzji? Oczywiście nie.

• Cykl życia oprogramowania: Cała analiza -> projektowanie -> wdrożenie -> test -> cykl konserwacji to proces, który należy jasno zdefiniować.

W każdym z tych przypadków wdrożenie procesu pozwala zmierzyć nakłady i wyniki oraz ustalić, czy wprowadzone zmiany mają zamierzony efekt. Brak wdrożonych procesów oznacza, że ​​zgadujesz tylko, gdy próbujesz poprawić swój sposób pracy. Na tym właśnie polega produkcja i sensowne jest pożyczanie kolejnych narzędzi udoskonalania produkcji, gdy są odpowiednie.

Istnieje cała dziedzina poświęcona definiowaniu i ulepszaniu procesów wykorzystywanych do tworzenia i utrzymywania oprogramowania; nazywa się to inżynierią oprogramowania . Nic dziwnego, że masz pytania dotyczące procesu programowania podczas czytania o CMMI - CMMI jest produktem Instytutu Inżynierii Oprogramowania .

Rozwój oprogramowania przyjął już wiele koncepcji produkcji:

• Trudno nie dostrzec wpływu wymiennych części Eli Whitneya zarówno na OOP, jak i rozwój oparty na komponentach .

• Techniki zarządzania projektami stosowane w tworzeniu oprogramowania nie różnią się bardzo od tych opracowanych dla produkcji. Jako tylko dwa przykłady świat oprogramowania przyjął niedawno koncepcję Kanban, która została opracowana kilkadziesiąt lat temu w Toyocie, a wykresy Gantta zostały wykorzystane w produkcji na długo przed zbudowaniem pierwszego komputera elektronicznego.

• Metodologie zarządzania jakością, takie jak Six Sigma, które zostały opracowane dla produkcji, zostały dostosowane do rozwoju oprogramowania.

Pomimo ciężkiego środowiska opartego na procesach, deweloper musi angażować się w tworzenie rzeczy „w locie”.

Czy mówisz mi, że ktoś sam zdecyduje o dodaniu poprawki do pakietu rozpoznawania twarzy i że doda ją do wersji produkcyjnej bez wcześniejszego tworzenia problemu w systemie śledzenia, po sprawdzeniu projektu, sprawdzanie kodu w kontroli wersji, czy testowanie go przez ludzi testujących? Nasz proces wymaga tych rzeczy z bardzo dobrych powodów. Jeśli przez „w locie” masz na myśli „poza procesem”, jest to nie do przyjęcia.

Robienie rzeczy w locie jest sprzeczne z duchem produkcji.

Ponownie, jeśli „w locie” oznacza „poza procesem”, masz rację. Ale jeśli uważasz, że produkcja nie wymaga szybkiego myślenia i opracowywania kreatywnych rozwiązań problemów, jesteś w błędzie. W procesie produkcyjnym pojawiają się różnego rodzaju problemy - babeczki nie mają wystarczającej ilości kremu, pomalowane powierzchnie nagle przestają przechodzić test zarysowania QA, 20% gotowych części brakuje ważnego pierścienia ustalającego, system mieszania ciasta złamał część krytyczna...