Zbuduj jeden, aby go wyrzucić przeciwko efektowi drugiego systemu

15

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.

m3th0dman
źródło
3
Osobiście uważam, że potrzebujesz trzech - jednego, aby zrozumieć podstawy problemu, dwóch, aby zrozumieć zaawansowane rzeczy, i trzeciego, aby rozwiązać problem.
Wyatt Barnett
5
@Wyatt: W moim przypadku poprawna liczba, aby „zrobić to dobrze” to n + 1, n jest bieżącą iteracją
mattnz

Odpowiedzi:

23

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.)

mattnz
źródło
Czy „pierwszy system, który zostanie wyrzucony” nie jest prototypem? Jeśli jest to prawdą, o ile mi wiadomo, prototyp zwykle nie ma pełnej funkcjonalności produktu tendencji; lub przynajmniej w kontekście prototypu „wyrzucanego”.
m3th0dman
Właśnie dlatego powinieneś znacznie zreformować późniejsze sprinty, odrzucając swoje pierwsze próby rozwiązania problemu, gdy nowe wymagania zostaną odkryte w zaległościach produktu.
Joeri Sebrechts
@Jeri Sebrechts Refaktoryzacja nie oznacza wyrzucenia pierwszego systemu; nie można też refaktoryzować złych wymagań lub złej architektury ...
m3th0dman
Jedyną rzeczą, którą muszę dodać do tej odpowiedzi, tylko dla wyraźnej jasności, jest to, że drugi system odnosi się do drugiego systemu produkcyjnego.
Thomas Owens
0

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:

  • Analiza wykonalności (zwłaszcza jak zbudować uzasadnienie biznesowe)
  • Zarządzanie projektami (w szczególności Plan projektu i rejestr ryzyka z ograniczaniem ryzyka)
  • Inżynieria wymagań (pozyskiwanie, analiza, specyfikacja, walidacja)
  • Projektowanie oprogramowania (inżynieria oprogramowania w języku UML i komponentach)
  • Konstrukcja oprogramowania (wzorce projektowe, frameworki, programowanie obronne)
  • Walidacja oprogramowania (testy jednostkowe, UAT itp.)

źródło
1
Zawsze będą potrzebne poprawki, gdy zmienią się wymagania. Ale w dobrze zaprojektowanych systemach te przeróbki mogą być wykonywane przyrostowo i czysto bez wpływu na niezwiązane części.
JesperE
Marzyć o. Oczekujesz, że klient będzie z góry wiedział, czego chce / potrzebuje. Tak się nie dzieje; dlatego mamy zwinne metody.
Przywróć Monikę - M. Schröder
Innymi słowy, zmiana SW musi nastąpić tylko wtedy, gdy zmienia się proces biznesowy firmy, i to nie zdarza się tak często.