Nie mogę zrozumieć określonego punktu w Zasadach Manifestu Zwinnego

24

Czytałem Zasady Manifestu Agile . Wszystko wydaje się jasne i rozsądne, z wyjątkiem jednego punktu:

Prostota - sztuka maksymalizacji ilości niewykonanej pracy - jest niezbędna.

Nie rozumiem tego. Czy to oznacza, że praca, która nie została wykonana, powinna być jakoś przesadzona? Jeśli tak, to naprawdę nie ma sensu.

agile management

— superM
źródło

2

+1, by przeciwstawić się głosowaniu w dół - masz tutaj zaskakująco interesujące pytanie.

1

Zobacz także Wu Wei i wyobraź sobie, jak można go ogólnie zastosować do tworzenia oprogramowania. Jest to naturalny postęp filozofii wyrażonej w twoim pytaniu.

30

Usuń komentarz w nawiasie. Pozostaje „Prostota jest niezbędna”, która, nawiasem mówiąc, jest zastosowaniem zasady do samego jej wyrażenia.

Prostota jest niezbędna, ponieważ destylujesz to, czego naprawdę potrzebujesz, usuwając to, co czyni zadanie pod ręką cięższym, mniej eleganckim: złożonym.

Zawsze interpretowałem w sensie zwięzłości Pascala : „ Napisałbym krótszy list, ale nie miałem czasu. ” Musisz unikać tego, co jest niepotrzebne (z listu, z kodu) i to jest aktywne zadanie , a nie łatwe. To nie dzieje się samo z siebie.

— Francesco
źródło

35

Chodzi o to, aby unikać wykonywania pracy, która nie jest konieczna, tj. „Maksymalizować ilość pracy, która nie została wykonana”.

Więc jeśli w tradycyjnym projekcie planujesz i zbudujesz świetny abstrakcyjny system bazowy, który zaspokoi wszystkie twoje ewentualne potrzeby, po prostu pomiń go i zbuduj najprostszą rzecz, która może pracować dla obecnych wymagań. Nie buduj rzeczy, których nie potrzebujesz.

YAGNI to pokrewna koncepcja.

— Joachim Sauer
źródło

5

Przypadkowo jest to prawdopodobnie zasada zwinności, z którą najmniej się zgadzam . W skrajności abstrakcyjna dalekowzroczność oddziela nas od innych zwierząt ... Mówię, że musimy z niej korzystać, kiedy tylko możemy. Oczywiście wiem, jakie okrucieństwa zasada musi być reakcja - ale trochę trochę przezorności nie zaszkodzi. Czasami jest to YAGNI, ale widziałem, jak niektórzy programiści są tak dogmatyczni, że nie przestaną myśleć nawet o kilka godzin do przodu (i zdają sobie sprawę, że prostota, którą teraz wdrażają, nie wystarczy nawet za 4-8 godzin).

— Maks.

2

@Max, myślę, że należy przewidzieć przyszłe możliwe zmiany. Tutaj foresight jest wielką pomocą. A twórcy, których opisujesz, bardziej przypominają strusie, które chowają się w piasku.

— superM

7

@Max klienci nie chcą płacić za to, co myślę , że może potrzebować w przyszłości, chcą za to, co oni teraz potrzebujemy jak najszybciej jak to możliwe . Każdego miesiąca są miliardy $$$ zmarnowanego wysiłku na dobre intencje „zaoszczędzi to dużo czasu później” i że „później” tak naprawdę nigdy nie nadejdzie, ale rzeczy są złożone, błędne i spóźnione z powodu całego tego „przewidywania”

15

@Max: YAGNI polega na opóźnianiu decyzji do ostatniej odpowiedzialnej chwili. To, o czym mówisz, opóźnia decyzję do ostatniej możliwej chwili, co jest w rzeczywistości Bad Idea ™. Chodzi o to, że nigdy nie będziesz mieć mniej informacji do podjęcia decyzji niż teraz. W najgorszym przypadku jutro będziesz mieć te same informacje. Ale zwykle do tego czasu się czegoś nauczysz. W przypadku, o którym mowa, wiesz, że to będzie to potrzebne, więc YAGNI po prostu nie ma zastosowania. W takim przypadku próba zastosowania go jest naprawdę głupia.

— Jörg W Mittag

2

@Max: To, co tu opisujesz, jest dokładnym przeciwieństwem maksymalizacji ilości niewykonanej pracy. Wykonuje dwa razy więcej pracy.

— pdr

5

Nazywaliśmy to „złoceniem”. Wymagane jest, aby młot mógł wbić gwóźdź w kawałek drewna. Nie robi to nic lepszego, ponieważ jest pozłacanym młotem.

Wiele razy programista sugerowałby użycie nowego fajnego frameworka lub dodanie funkcji, które choć fajne nie były konieczne. Zanotowalibyśmy ten pomysł w dół, ale dla tej wersji nie zrobimy tego. Zmaksymalizujemy pracę nie wykonaną. Dostarczenie oprogramowania jest wystarczająco trudne, więc nie dostarczaj więcej kodu, niż potrzebujesz. Jeśli trzeba to zrobić, ostatecznie znajdzie się w planie i zostanie wykonane we właściwym czasie.

— Stuart Woodward
źródło

4

Pomysł ten jest bardzo podobny do koncepcji z Toyota Production System (TPS) , która doprowadziła do bardziej ogólnego Lean Manufacturing, a następnie zastosowania tych technik do Lean Software Development . TPS znacznie wyprzedza zwinny ruch, którego korzenie sięgają produkcji pod koniec lat 50. XX wieku.

Koncepcja maksymalizacji ilości niewykonanej pracy jest podobna do eliminacji marnotrawstwa. W środowisku produkcyjnym odpady obejmują takie rzeczy, jak nadprodukcja towarów, oczekiwanie na zasoby, niepotrzebny przepływ ludzi lub produktów, zbyt dużo zapasów i wadliwe produkty. W Lean Software Development straty te zostały przełożone na niepotrzebną funkcjonalność, opóźnienia w procesie programowania, niejasne wymagania, które spowalniają produkcję oprogramowania, brak testów i opóźnienia w komunikacji.

Ogólna koncepcja obu koncepcji jest taka sama - rzeczy, które nie dodają wartości, są marnotrawstwem i należy je zminimalizować. Ostatecznym celem jest poprawa jakości przy jednoczesnym skróceniu czasu i kosztów produkcji.

— Thomas Owens
źródło