Jak tworzysz oprogramowanie bez kryteriów akceptacji?

70

W jaki sposób wspólnie opracowujesz oprogramowanie w zespole 4-5 programistów bez kryteriów akceptacji, nie wiedząc, co testerzy będą testować dla wielu (2-3) osób działających jako właściciel produktu.

Wszystko, co mamy, to szkicowa „specyfikacja” z kilkoma zrzutami ekranu i kilkoma punktorami.

Powiedziano nam, że będzie to łatwe, więc te rzeczy nie są wymagane.

Nie wiem, jak postępować.

Dodatkowe informacje

Otrzymaliśmy trudny termin.

Klient jest klientem wewnętrznym, teoretycznie mamy właściciela produktu, ale co najmniej 3 osoby testujące oprogramowanie mogą zawieść element roboczy po prostu dlatego, że nie działa tak, jak ich zdaniem powinno działać, a przejrzystość tego, czego oczekują, jest niewielka lub żadna. do czego faktycznie testują, dopóki się nie powiedzie.

właściciele produktu nie są dostępni, aby odpowiedzieć na pytania lub wyrazić opinię. Nie ma z nimi regularnych zaplanowanych spotkań ani połączeń, a informacja zwrotna może potrwać kilka dni.

Rozumiem, że nie możemy mieć idealnej specyfikacji, ale pomyślałem, że normalne byłoby posiadanie kryteriów akceptacji dla rzeczy, nad którymi pracujemy w każdym sprincie.

użytkownik 1450877
źródło
33
Powiedziałbym, rozwijaj to, jak chcesz. Tak długo, jak czujesz się komfortowo, biorąc udział w spotkaniu i pokazując, jak twój produkt pasuje do szkicowej „specyfikacji” i zrzutów ekranu, myślę, że nic ci nie jest. Oczywiście zawsze możesz poprosić twórcę specyfikacji o dalsze szczegóły ...
FrustratedWithFormsDesigner
10
Zasadniczo jest to rozwój automatyczny lub „Cowboy Coding”. Programiści wypełniają szczegóły. Programiści mają kontrolę większościową. Zasadniczo nigdy nie będziesz mieć wymagań formalnych. Opracowuj, demonstruj dla posiadaczy stosów, zbieraj opinie, płucz i powtarzaj.
Jon Raynor
11
Czy właściciel produktu rozumie, że jest to doskonały sposób na zapewnienie coraz wyższych kosztów i spirali czasu? Naukowcy niebędący komputerami często nie rozumieją znaczenia dobrze napisanych jasnych specyfikacji. Na przykład rząd USA często napotyka podobne problemy, kiedy zmieniają oczekiwania dotyczące nowego sprzętu wojskowego. Jest to jeden z kilku powodów, dla których sprzęt wojskowy jest często przepełniony i opóźniony. joelonsoftware.com/2000/10/02/…
nickalh
35
„Powiedziano nam, że będzie to łatwe, więc te rzeczy nie są wymagane. ... Dostaliśmy trudny termin. ... właściciele produktu nie są dostępni, aby odpowiedzieć na pytania lub wyrazić opinię. brak regularnych spotkań lub rozmów z nimi, a informacja zwrotna może potrwać kilka dni. ” Masz moje współczucie. Są to cechy charakterystyczne: „Nie mam pojęcia, jak działa oprogramowanie do pisania. W ogóle”.
jpmc26
13
Zostałeś ustawiony na niepowodzenie. Tego rodzaju rzeczy należy eskalować do zarządzania. Jeśli nie miałeś trudnego terminu, możesz iterować, dopóki ci się nie uda. Jeśli zainteresowane strony byłyby dostępne na informacje zwrotne, możesz iterować wystarczająco szybko, aby (prawdopodobnie) dotrzymać terminu. To samo dotyczy posiadania właściwie dość szczegółowej specyfikacji. Ale coś musi dać . W tej części bardzo ładnie prosisz szefa o wyciągnięcie @ $$ z ognia.
Jared Smith,

Odpowiedzi:

130

Iteracyjny proces osiągnie to ładnie, bez szczegółowych specyfikacji.

Po prostu stwórz szkicowy prototyp, poproś klienta o opinię, dokonaj zmian w oparciu o opinię i powtarzaj ten proces, aż aplikacja zostanie zakończona.

To, czy klient jest wystarczająco cierpliwy, aby to zrobić, to inne pytanie. Niektórzy klienci i programiści wolą ten proces; ponieważ klient jest zawsze praktyczny, (ostatecznie) dostanie dokładnie to, czego chce.

Nie trzeba dodawać, że w ten sposób nie będziesz pracować na umowę na czas określony lub na czas określony.

Robert Harvey
źródło
114
Należy dodać: „upewnij się tylko, że płacisz za godzinę”, a nie „płacisz tylko wtedy, gdy klientowi brakuje pomysłów na to, czego brakuje”.
Doc Brown
22
Pamiętaj także o udokumentowaniu tego, co myśli klient, aby przynajmniej gdzieś zostało zapisane w notatkach. Może nie są to formalne kryteria akceptacji, ale warto je mieć, gdy próbujesz wykonać kolejne kroki.
enderland
4
@Doc Brown: OP edytowane w celu dodania „Klient jest wewnętrzny” - więc mam nadzieję, że płatność za godzinę nie stanowi problemu.
śleske,
8
+1 Postępowałem zgodnie z tym procesem w przypadku wielu wewnętrznych projektów i stwierdziłem, że działa on naprawdę dobrze, a ponadto ogólnie oszczędza czas. Jedną wskazówką jest, aby iteracje były krótkie: tydzień lub dwa.
Bob Tway,
13
Z mojego doświadczenia wynika, że ​​działa to dobrze, gdy powodem braku formalnych kryteriów akceptacji jest to, że nikt nie jest jeszcze pewien, czego naprawdę chcą. Prototypy pomagają im formułować opinie, a ty akceptujesz, że masz przed sobą duże, niepewne zadanie. Ale działa to dość źle, gdy powodem jest to, że interesariusze nie znajdują czasu, aby pomyśleć / porozmawiać / napisać o tym, czego chcą, lub gdy interesariusze mają sprzeczne wymagania, które z powodów politycznych nie uważają, że mogą to wyraźnie powiedzieć. Następnie prototyp po prostu kopie puszkę w dół drogi i nic się nie poprawia, dopóki nie znajdziesz mocnego kija.
Steve Jessop,
58

Jeśli to, co mówisz, jest prawdą, a specyfikacja nie jest wystarczająco dobra, abyś mógł zacząć (i jesteś szczery w tej ocenie), polecam to podejście:

  1. Przeczytaj szkice i „szkicowe” specyfikacje, które otrzymałeś.
  2. Napisz własną specyfikację do poziomu, który wystarczy, abyś mógł kodować. Być może będziesz musiał zrobić mnóstwo domysłów.
  3. Pokaż swoją specyfikację klientowi do sprawdzenia. Zwróć uwagę na części, które im się podobają, i uzyskaj więcej informacji na temat części, które według nich są błędne.
  4. Powtarzaj kroki 2 i 3, aż Ty i klient zsynchronizujecie się.
  5. Masz teraz odpowiednią specyfikację.

Jeśli Twój klient miał rację, gdy powiedział „będzie łatwo”, ćwiczenie to powinno być bułką z masłem.

Jeśli twój klient się mylił i faktycznie istnieją różne braki i luki w wymaganiach, twoja wersja specyfikacji szybko zilustruje problem i poinformuje go, że się mylili (bez konieczności wskazywania palcem lub argumentowania), ponieważ być tuż przed nimi i oczywiste. Twoja specyfikacja posłuży również jako doskonałe narzędzie do dyskusji w celu wyjaśnienia tych dwuznaczności i będzie służyć jako zapis kluczowych decyzji w miarę ich korygowania wraz z ich opiniami.

John Wu
źródło
27
Czasami możesz oszukać klienta, nazywając swoją specyfikację „harmonogramem pracy” (który ich nieprogramiści rozumieją jako przyjazną i przydatną rzecz dla projektu) zamiast „specyfikacji” (która w przypadku klientów podobnie jak ci, którzy są wrogo nastawieni do wszystkich podstawowych zasad angażowania się w proces rozwoju, ich nieprogramowe mózgi uważają za żmudną pedantyczną papierkową robotę, którą programiści robią z nich bez powodu.
Steve Jessop,
Jeśli chodzi o drugą kwestię, sugeruję, abyś napisał jedynie specyfikację techniczną dla programisty. W przeciwnym razie programista nie byłby w stanie rozpocząć pracy. W ten sposób możesz równolegle współpracować z zespołem biznesowym nad charakterem pracy, która ma zostać opracowana. W ten sposób zarówno zespół programistów, jak i zespół biznesowy zostają zsynchronizowani ze sobą w zakresie wymagań.
Karan
3
your draft specification will quickly illustrate the problem and communicate to them that they were wrong (....) since it will be right in front of them and obvious- Chciałbym zauważyć, że klienci, którzy zdają sobie sprawę z tego, jak oczywiste jest to wszystko, są dokładnie tymi klientami, z którymi nigdy nie będziesz mieć tego problemu na początku. Lub, mówiąc bardziej zwięźle: rozwiązanie implikuje nieistnienie problemu (paradoks, który coraz częściej rozpoznaję we wszystkich dziedzinach życia) ...
Radu Murzea
1
Są ludzie, którzy nigdy tego nie „zrozumieją”, ale z mojego doświadczenia często pomaga im pokazać przykładowy poziom szczegółowości, którego potrzebujesz, i pokazać im rodzaj „złych” decyzji, które możesz podjąć, gdy wymagania są spełnione dwuznaczny.
John Wu,
18

Właściciel produktu wręczył ci prototyp; oddaj mu lepsze (dopóki nie skończysz)

Wygląda na to, że otrzymałeś papierowy prototyp na rozpoczęcie projektu. To nie jest straszny początek. Sugeruję, abyś skontaktował się z właścicielem firmy w tym samym języku , dostarczając prototypy o stopniowym rozwoju.

Twoje prototypy powinny zaczynać się od papieru, przechodzić na cyfrowe makiety, a następnie budować przy użyciu „prawdziwych” technologii.

Treehouse ma do tego doskonały przewodnik, który zawiera następujące wnioski:

Wspaniałą rzeczą w prototypowaniu za pomocą frameworka jest to, że prototyp często staje się prawdziwą witryną, ponieważ struktura i styl są już na miejscu. Nie ma potrzeby ponownego tworzenia strony od zera, jeśli będzie ona korzystała z tej samej platformy.

Możesz także podać formalną specyfikację, zwłaszcza jeśli martwisz się obwinianiem za zły wynik. Ale prawdopodobnie uzyskasz więcej informacji zwrotnych od prototypów.

Dotrzymaj terminu

Pamiętaj, że twoje późniejsze wysiłki nie będą klasycznymi „prototypami”, ponieważ nie będą one jednorazowe (lub ich części nie będą). Ostatnia, najzdolniejsza iteracja, którą wykonasz, zanim termin stanie się twoją dostawą.

Twój termin jest najlepiej zdefiniowanym wymaganiem. Mieć coś kompletnego i spójnego, co możesz dostarczyć na czas.

Współpracuj ze swoimi testerami

Jeśli ten luźny proces jest dla Twojej firmy czymś nowym, testerzy prawdopodobnie są jeszcze bardziej zagubieni niż Ty i mogą cię szukać . Musisz poświęcić trochę czasu na początku procesu. Poinformuj ich szefa, że ​​próbujesz pomóc im w przeprowadzeniu rzetelnego testu bez formalnych kryteriów akceptacji.

Dowiedz się, czy testerzy mają coś, czego potrzebują, na przykład dokumentację potwierdzającą testy, do której możesz „wrócić”.

Spróbuj przetestować pierwszy projekt

Ponieważ nie masz żadnych wymagań formalnych, zachęcanie do testowania przypadków testowych w celu zapewnienia pewnej struktury.

Zapoznaj się ze znajomością Test First Design i / lub programowaniem opartym na testach i przekaż testerom wskazówki dotyczące procesu w razie potrzeby. W przypadku takiego szybkiego projektu nie trzeba być ekspertem w tym procesie. Ale stosowanie sprawdzonej metodologii dobrze odbije się na tobie i twoich testerach.

Trzymaj się standardów, szczególnie w przypadku interfejsu użytkownika

Nie masz wymagań dotyczących wyglądu i stylu, ale masz termin. Użyj cudzych prac projektowych, aby zminimalizować pracę, którą musisz wykonać, aby stworzyć profesjonalnie wyglądający artefakt.

Wybierz standardowy interfejs użytkownika dla swojej witryny i nie dostosowuj go, chyba że / dopóki nie zostaniesz do niego skierowany. Nie wiem dla jakiej platformy się rozwijasz, ale Bootstrap lub Google Material Design to dwa przykłady.

Komunikuj się, ale nie dręcz się

Sugeruję wysyłanie jednego e-maila do właściciela produktu dziennie. Wysyłaj więcej niż tylko w nagłych przypadkach.

Jeśli masz pytania, opisz, jak postąpisz, jeśli nie otrzymasz wskazówek. Na przykład:

Czy użytkownicy tej aplikacji będą musieli uzyskać do niej dostęp za pomocą urządzeń mobilnych? W tej chwili zakładamy, że będzie to system wyłącznie do komputerów stacjonarnych / laptopów.

Nie panikuj

Brałem udział w wielu projektach dla ludzi, którzy nie znali terminu „wymaganie”. Większość zakończyła się sukcesem. Bezpośredni właściciele produktów dają swobodę tworzenia doskonałych rozwiązań.

Zauważ, że niektórzy właściciele projektów w tych projektach nie byli w stanie zadowolić i ukryli się za „Jestem zbyt zajęty, aby ...” usprawiedliwić ich niekompetencję. Ale większość była „zachwycona” wynikami końcowymi.

Tim Grant
źródło
Jedynym punktem, o którym nie wspomniano, jest Hard Deadline: ważne będzie, aby coś zostało dostarczone w tym dniu i aby działało (przechodzi przez ruchy), nawet jeśli brakuje dzwonków, gwizdków i szybszych pasków. Po wprowadzeniu tego ograniczenia wszystkie pozostałe punkty @Tim powinny pójść dobrze
Philip Oakley,
@PhilipOakley, dzięki za opinie. Dodałem uwagę, że iteracyjny proces prototypowania powinien dawać coraz bardziej akceptowalne „produkty”, aby zapobiec przekroczeniu terminu. Jeśli to pomoże, to daj mi znać.
Tim Grant,
to jest poprawa. Może nawet zmień „Spotkanie” na „Spotkanie”, aby było bardziej konieczne. Następnie może również dodać stwierdzenie, że jeśli podali datę bez innych elementów, staje się to kluczowym wymogiem, tak aby następująca „Notatka” miała kontekst. (często klienci martwią się tylko czasem i kosztami, reszta to kosmetyki i moda, jak jestem pewien ;-)
Philip Oakley,
10

Projekt polega na zmniejszaniu niepewności do momentu osiągnięcia pewności :

  • Na początku zawsze jest pewien stopień niepewności. Czasami jest trochę dwuznaczność wymagań. Czasami są bardzo szkicowe. Musisz ćwiczyć w ramach pracy.
  • Sztuką jest iteracyjne zmniejszenie tej niepewności (łączenie analizy, projektowania i wdrażania), udoskonalanie historii użytkowników i wdrażanie systemu.
  • Testy przypadków / scenariuszy i kryteria akceptacji będą musiały zostać wyjaśnione w ten sam sposób. Przyczynią się do zmniejszenia niepewności co do jakości i poprawności (między innymi).
  • Na koniec osiąga się wystarczającą pewność: klient otrzymuje przetestowany produkt, który odpowiada jego potrzebom i może być używany.

Taka jest zasada stopniowego opracowywania: wymagania, kryteria i wyniki będą opracowywane krok po kroku, podobnie jak zrozumienie przez klienta własnych oczekiwań i wymagań dzięki zaangażowaniu w proces rozwoju.

Czy to problem ?

Szkicownik początkowe wymagania, tym większa niepewność i dłuższy czas potrzebny do wykonania zadań. Więc to tylko kwestia, kto wykona dodatkową pracę i kto pokryje koszty.

Odpowiedź na te dwa pytania powinna znajdować się w umowie. Lub będzie przedmiotem negocjacji. I klient musi zaakceptować dodatkowe zaangażowanie (głównym argumentem będzie „śmieci, śmieci”, chociaż radzę zdecydowanie przedstawić je w bardziej dyplomatyczny sposób ;-))

Christophe
źródło
1
Uwielbiam pierwsze zdanie. Zasadą tego jest, że klient może: 1) nie być pewnym, czego chce, 2) zmieniać zdanie, 3) chcieć czegoś nieosiągalnego. Ale jeśli jest to właściwie prosty projekt, to ma duże szanse na sukces.
1
Ten jest złoty.
Bruno Guardia,
8

Nie ma regularnych zaplanowanych spotkań ”. Dlaczego więc nie zaczniesz od planowania regularnych spotkań ? Sam fakt, że masz wielu właścicieli produktów, gwarantuje, że Twój projekt NIE będzie łatwy, ponieważ każda z tych osób BĘDZIE mieć sprzeczne wymagania, które MUSZĄ być omówione osobiście ze wszystkimi obecnymi interesariuszami.

Ponadto naprawdę, naprawdę, naprawdę polecam prowadzenie szczegółowego dziennika decyzji . Przynajmniej zapisujesz wszystko, co ktoś postanowił, wraz z datą i listą osób obecnych przy podejmowaniu decyzji. Jeszcze lepiej, jeśli potrafisz zapisać DLACZEGO coś zostało ustalone tak, jak było. Nie ma znaczenia, czy jest to plik na komputerze, strona w intranetowej wiki, czy notatnik na biurku. Dziennik chroni ciebie i projekt: kiedy tester mówi, że jakiś element „zawodzi”, możesz wskazać, że tak postanowiono z tymi ludźmi i nie jest to twój problem, ale to między nimi a testerami. Jeśli prowadzi to do zmiany specyfikacji, to jest w porządku, ale w tym momencie nie mogą oczekiwać, że dotrzymają terminu, który mieli na myśli - albo muszą skrócić zakres w innym miejscu.

Zero jeden
źródło
8

Projekt bez wyraźnych wymagań, luźne przywództwo, nie definicja gotowe (DoD), nikt nie chce być odpowiedzialny przed upewniając się, że masz potrzebne informacje, aby wykonywać swoją pracę w sposób terminowy i spełniają ich termin jest recepta dla projektu niepowodzenie.

Iteracyjny rozwój nie jest złą sugestią, ale wymaga ścisłej współpracy między właścicielami produktów i deweloperami. Spróbuj złapać kogoś na haczyku, mówiąc: „Wiemy, że będziemy mieć pytania. Kto może być regularnie dostępny, aby upewnić się, że otrzymają odpowiedzi, aby dostawa projektu nie została opóźniona?” Umów się z kimś regularnie, aby sprawdzić postępy i usunąć przeszkody. Jeśli się nie pokażą lub odmówią, skontaktują się z uprzejmą pisemną korespondencją i opóźnią lub nie odpowiedzą na dokumenty. Jeśli właściciele produktu nie mogą być dostępni, poproś ich o przedstawienie przedstawiciela, który może być.

Kolejną cechą charakterystyczną iteracyjnego rozwoju jest to, że zmiana wymagań wymaga zmiany osi czasu. Nie możesz zobowiązać się do dotrzymania terminu, jeśli nie możesz opracować osi czasu, i nie możesz opracować osi czasu, jeśli nie masz pojęcia, co należy zrobić. Zamiast dogmatycznie pytać o specyfikację, przejrzyj aktualną specyfikację, udokumentuj wszelkie pytania, które Ty lub zespół masz na temat tego, jak ma ona działać, umów się z właścicielami produktu na omówienie jej i udokumentuj odpowiedzi. Gdy skończysz, otrzymasz specyfikacje oparte na ich decyzjach, na które możesz następnie poprosić właścicieli produktów (na piśmie). Celem specyfikacji jest usunięcie niejednoznaczności i utworzenie DoD, co dokładnie może zapewnić sesja pytań i odpowiedzi. Jeśli istnieje sprzeciw wobec specyfikacji, nie nazywaj jej specyfikacją.

Nie wierz nikomu, kiedy ci powiedzą, że będzie łatwo . Czasami to naprawdę jest tak proste, jak się wydaje, i mogę w to uwierzyć, jeśli (i tylko wtedy ) znam właścicieli produktów wystarczająco dobrze, aby w pełni ufać, że wymagania są tak proste, jak im się podoba, i specyfikacje, w których byłem pod warunkiem, że są zrozumiałe (jeśli nie, planuję sesję pytań i odpowiedzi i dokumentuję ją). Byłem w zbyt wielu sytuacjach, w których łatwość z punktu widzenia operacji jest niezwykle trudnaz punktu widzenia rozwoju lub myślisz, że jesteś całkowicie skończony i słyszysz słowa rozpaczy („A tak przy okazji, zapomnieliśmy o…”). Przykład ... „Wszystko, co musisz zrobić, to odczytać te pliki PDF z repozytorium dokumentów”, które podczas testów akceptacyjnych zamieniają się w „Och, zapomnieliśmy, że niektóre z nich zostały odczytane na boki w całkowicie niespójny sposób, i niektóre mają zdefiniowany niewłaściwy rozmiar strony, a niektóre wymagają dołączenia tych trzech stron i potrzebujemy ich wszystkich, aby wyświetlały się tak samo. Naprawdę łatwo to naprawić, prawda? ".

Chodzi o to, że może być naprawdę łatwe, a szybkie spotkanie może to potwierdzić, umożliwiając udokumentowanie wszystkich założeń i uzyskanie potwierdzenia, że ​​są one dokładne i prawidłowe. Polecam wstać, aby usunąć przeszkody, które musisz napisać działającemu kodowi, który spełnia ich oczekiwania, ponieważ niezależnie od tego, czy stąpasz na palcach, ktoś i tak prawdopodobnie będzie niezadowolony. Jeśli jesteś wytrwały w uzyskiwaniu odpowiedzi na pytania i irytujesz kogoś, zapomni o tym, gdy dostarczysz świetny produkt na czas, który spełnia wymagania. Jeśli nie dostaniesz wyjaśnienia i nie dostarczysz, nikt nie będzie pamiętać, że powiedzieli ci, żebyś ich nie robił.

DVK
źródło
3

Bez specyfikacji masz pracę zespołową. Idź zwinny.

Usiądź przy PO i przygotuj kilka krótkich początkowych historii. „Dostarczymy tylko ten ekran, z tym przyciskiem, który zmienia się w„ bing! ””. Postaw na niektóre AC. Dostarcz historię. Zademonstruj historię. Okazuje się, że przyciski powinny być czerwone. Podnieś błąd lub nową historię. Dostarcz przyciski, które zaczynają bong i huk I tak dalej.

Wspólnie określ i dostarcz małe pionowe plastry, które są często demonstrowane.

Jeśli klient nie będzie z tobą współpracował w ten sposób, poszukaj wyjścia.

Grimm Opiner
źródło
-1

Spędziłem kilka prac, wykonując projekty zgodnie z twoimi planami. Tak długo, jak organizacja producentów wie, jakie decyzje projektowe podejmujesz i dlaczego musisz je podejmować, powinieneś czuć się dobrze. Z drugiej strony, jeśli nie rozumieją decyzji projektowych, należy je nacisnąć dla przynajmniej pisemnego dokumentu testu akceptacji użytkownika.

Robert Baron
źródło
-2

Potrzebujesz szczegółowej, weryfikowalnej specyfikacji, zanim zaczniesz pisać kod. To fakt i nie można tego obejść.

Jeśli nikt inny nie chce napisać tej specyfikacji, to programiści muszą ją napisać. Otrzymujesz więc niepełną specyfikację. Przekształcasz go w pełną specyfikację (co oznacza, że ​​„to właśnie zamierzam wdrożyć, chyba że ktoś inny powie mi, żeby tego nie robić”). Przekazujesz tę specyfikację interesariuszom i dajesz im szansę na modyfikację specyfikacji. Tylko szansa na zmodyfikowanie specyfikacji - nie cofanie jej, na przykład mówiąc „Nie lubię tego w ten sposób”. W tym momencie jest to Twoja specyfikacja lub mogą podać inną specyfikację, ale nie mogą jej usunąć.

Dobrym pomysłem może być szybki przegląd od kolegów, którzy mogą ulepszyć specyfikację. Ale i tak masz specyfikację, piszesz odpowiednio kod, testerzy odpowiednio testują. I wykonałeś swoją pracę: miałeś specyfikację i ją wdrożyłeś. Jeśli specyfikacja nie jest tym, czego chce klient, jest to po prostu odpowiedzialność właściciela produktu lub klienta, któremu nie przeszkadzało napisanie dobrej specyfikacji.

gnasher729
źródło
6
„Potrzebujesz szczegółowej, weryfikowalnej specyfikacji, zanim zaczniesz pisać kod. To fakt i nie da się tego obejść.” Moi współpracownicy i ja zrobiliśmy to w wielu projektach i odnieśliśmy wiele sukcesów i bardzo mało porażek. Twoje roszczenie nie jest absolutne.
whatsisname
1
@whatsisname zgodził się. Ja też napisałem kod w ten sposób. Dzieje się tak, gdy zadanie ma aspekt eksploracyjny. Teraz istnieją wady kodowania bez specyfikacji, ale czasami są one bardziej akceptowalne niż stwierdzenie, że nie można osiągnąć celu.
Cort Ammon
1
@whatsisname, frazowanie można poprawić, ale podstawową prawdą jest to, że nie można spełnić żądania bez zrozumienia, co to jest. Jeśli powiem „Napisz mi program w Javie”, nie możesz napisać tego programu. Możesz wymyślić swój własny pomysł na to, co program powinien zrobić - innymi słowy, wymyślić swój własny cel, a następnie go zrealizować - ale jest to czysta niemożność osiągnięcia celu, który nigdy nie został określony przez nikogo, w tym ciebie. Dotyczy to wszelkich wniosków, dużych lub małych; potrzeby i pragnienia należy zrozumieć, zanim będzie można je wykonać, wyprodukować i / lub przedstawić.
Wildcard
To powiedziawszy ... poziom szczegółowości, którego faktycznie wymaga żądanie, aby zostać zrozumiany i spełniony, można drastycznie przecenić. To może być również pod oszacowane. Jedynym rozwiązaniem tego jest komunikacja.
Wildcard
@Wildcard: tak, myślę, że sformułowanie może być bardzo zatwierdzone. To, co próbujesz powiedzieć, przypomina paradoks Zenona, ale mniej przekonujące.
whatsisname