Z jednej strony jest rada, która mówi „Zbuduj jednego, aby go wyrzucić”. Dopiero po skończeniu oprogramowania i zobaczeniu produktu końcowego zdajemy sobie sprawę, co poszło nie tak w fazie projektowania, i rozumiemy, jak naprawdę powinniśmy to zrobić.
Z drugiej strony istnieje „efekt drugiego systemu”, który mówi, że drugi zaprojektowany system tego samego rodzaju jest zwykle gorszy niż pierwszy; istnieje wiele funkcji, które nie pasowały do pierwszego projektu i zostały wepchnięte do drugiej wersji, co zwykle prowadzi do zbyt skomplikowanych i nadmiernie zaprojektowanych.
Czy nie ma tu sprzeczności między tymi zasadami? Jaki jest właściwy pogląd na problemy i gdzie jest granica między nimi?
Uważam, że te „dobre praktyki” zostały po raz pierwszy wypromowane w książce Freda Brooksa „ The Mythical Man-Month” .
Wiem, że niektóre z tych problemów rozwiązują metodologie Agile, ale w głębi duszy problem jest nadal zasadą; na przykład nie wprowadzilibyśmy istotnych zmian w projekcie 3 sprintów przed uruchomieniem.
Odpowiedzi:
Zbudowanie takiego, które można wyrzucić, polega na tym, że na początku „nie wiesz, czego nie wiesz”, dlatego na początku uczysz się tego, co powinieneś był zrobić na początku.
Efekt drugiego systemu pochodzi z „teraz wiedząc, czego nie wiedziałeś, ale nie wiedząc, czego wciąż nie wiesz”, tj. Efekt drugiego systemu pochodzi z próby zbudowania większego, bardziej błyszczącego, bardziej złożonego systemu niż pierwszy, bez wiedzy potrzebne na początku - brzmi bardzo podobnie do tego, co dzieje się z pierwszym systemem.
Dlatego efekt drugiego systemu nie jest sprzecznością. Zbudowanie drugiego systemu na taką samą funkcjonalność jak pierwszy nigdy (o ile wiem) nigdy nie zostało zrobione. Drugi system zawsze musi być „lepszy”, a zatem bardziej złożony, dlatego można się spodziewać zasadniczo podobnych problemów z pierwszym systemem - które należy wyrzucić.
Więc zbuduj jednego, który wyrzuci, rzucisz go i zbuduj ponownie bez powiększania zakresu, a nie będziesz miał drugiego problemu z systemem. (Zazwyczaj robi się to częściej na planetach o fioletowym niebie, różowym morzu i latających świniach.)
źródło
Problem, o którym mówisz, oznacza, że kilka rzeczy zostało pominiętych, dlatego powstały system nie działa. Pozwól mi opisać niektóre brakujące kroki:
Zarządzanie jakością - Zrób to dobrze za pierwszym razem! Nigdy nie używaj tymczasowych hacków ani tymczasowych kompromisów. Nie trzeba przerabiać. Wszystkie zasoby są wykorzystywane efektywnie, a wszystko, co robisz, stanowi odpowiedni wkład w projekt.
Analiza wykonalności - odkryj potrzeby biznesowe. Utwórz uzasadnienie biznesowe dla projektu.
Plan projektu - Jasno zdefiniuj początkowy zakres, zaplanuj sposób dostarczenia rozwiązania, utwórz linię bazową, trzymaj się planu. Nie marnuj czasu na nic, co nie jest na ścieżce krytycznej.
Inżynieria wymagań - Wywołaj wymagania biznesowe (tj. Przechwytuj procesy biznesowe i określ, jakie operacje biznesowe powinny być obsługiwane przez system komputerowy, przetłumacz operacje biznesowe 1: 1 na przypadki użycia systemu). Zatwierdź i zweryfikuj! (czy budujemy właściwą rzecz? Czy budujemy właściwą rzecz?) Wszystkie wymagania muszą być powiązane z pierwotną potrzebą biznesową.
Projektowanie oprogramowania - Przetłumacz przypadki użycia i model domeny na projektowanie komponentów i architekturę rozwiązań. Wszystkie elementy muszą być powiązane z wymaganiami RE.
Implementacja - Koduj oprogramowanie jak w projekcie. Cały kod musi być powiązany z komponentami z SD.
Walidacja - testy jednostkowe, testy integracyjne, wydajność, ... (wszystkie przypadki użycia z RE będą teraz musiały zostać przetestowane)
Oto niektóre kluczowe aspekty procesu tworzenia oprogramowania. Wspomniane działania są częścią inżynierii oprogramowania. W ten sposób budujesz odpowiednie oprogramowanie dla rzeczywistych potrzeb biznesowych i budujesz je na czas, zgodnie z budżetem i zgodnie ze specyfikacją.
Poszukaj tych warunków, aby zbudować lepsze oprogramowanie i zrobić to dobrze za pierwszym razem:
źródło