Czy pisanie oprogramowania przy braku wymagań jest umiejętnością lub sytuacją, której powinienem unikać?

44

Uważam, że niektórzy programiści są w tym bardzo biegli i często chwaleni są za możliwość dostarczenia działającej koncepcji o abstrakcyjnych wymaganiach. Szczerze mówiąc, doprowadza mnie to do szaleństwa i nie lubię „wymyślać” na bieżąco. Kiedyś myślałem, że to problematyczne, ale zacząłem wyczuwać zmianę i zastanawiam się, czy muszę dostosować mój proces myślowy (i programistyczny), gdy otrzymam bardzo mało wskazówek. Czy powinienem zacząć zdobywać tę umiejętność, czy też trzymać się idei, że zbieranie wymagań i reguły biznesowe są priorytetem?


źródło
2
Sytuacja, której należy unikać. Chodzi o to, że nie możesz. I o tym mówiłem kilka tygodni temu ...
yannis
64
Jest to coś w rodzaju gaśnicy.
Ben Brocka
3
Jeśli nie planujesz, planujesz ponieść porażkę. Te projekty zbudowane bez wymagań mogą, ale nie muszą spełniać oczekiwań klienta, gdy wychodzą ze sklepu, ale prawie na pewno ukrywają wiele grzechów, co oznacza, że ​​gdy zmieniają się wymagania (i zawsze tak robią), świat cierpienia czeka na osobę, która musi dokonać niezbędnych zmian. Programiści, którzy piszą bez formalnych wymagań, nie powinni być chwaleni, powinni zostać upomnieni za to, że nie byli przygotowani na długoterminowe utrzymanie projektu w przyszłości
GordonM,
10
Obowiązkowy Dilbert: dilbert.com/strips/comic/2006-01-01-
Dan Neely
5
Czasami klient nie wie, czego chce. Chcą, abyś przeprowadził „eksperymenty”, aby ustalić, czego chcą. Kiedyś napisałem system prowizji, w którym jedynym wymogiem było płacenie prowizji. Procent i pozycje do zapłaty prowizji miały zostać określone na podstawie doświadczenia z eksperymentalnym systemem prowizji.
Gilbert Le Blanc

Odpowiedzi:

80

Umiejętność nie polega na pisaniu oprogramowania bez wymagań. Zamiast tego należy wywołać wymagania od właściciela projektu, niezależnie od tego, czy istnieje dokumentacja wymagań formalnych, czy nie.

Zbieranie wymagań jest zdecydowanie Twoim pierwszym priorytetem, ale niekoniecznie musisz uprzedzić wszystkie potrzeby klienta. Ryzyko polega oczywiście na tym, że możesz przegapić jakąś istotną informację, która czyni architekturę systemu bezużyteczną, jeśli nie udało Ci się przeprowadzić odpowiedniego rodzaju rozmowy z klientem, jednak nie jest niczym niezwykłym zdefiniowanie produktu, a nawet uzyskanie znaczna część rozwoju została pominięta, jednocześnie odraczając najważniejsze decyzje dotyczące architektury systemu do ostatniej możliwej chwili. Jest to podejście oparte na szczupłym rozwoju, które ma na celu zagwarantowanie, że nie zaangażujesz się w potencjalnie niezgodną architekturę zbyt wcześnie w rozwoju produktu, dopóki nie uzyskasz bardziej wiarygodnych informacji. W sytuacjach, które OP opisał w swoim pytaniu:

Tak, czasami trzeba trochę popatrzeć na kryształową kulę, aby dotrzeć do sedna tego, o co tak naprawdę prosi klient, czyli tam, gdzie wymaga prototypowania i powolne - i tak czasami bolesne - stopniowe wyciąganie wymagań że naprawdę rozwijasz dobre umiejętności relacji z klientami, a także cierpliwość, aby zdać sobie sprawę, że przy każdym złożonym pomyśle na oprogramowanie, że na początku klient często nie wie dużo więcej o tym, co oprogramowanie musi zrobić. Najczęściej klient dzwoni wcześnie, aby polegać na wiedzy specjalistycznej w celu zdefiniowania swoich wymagań, ponieważ klient nie zawsze ma niezbędną wiedzę fachową lub wiedzę na temat procesu tworzenia oprogramowania.

S.Robins
źródło
22
„Umiejętność nie polega na pisaniu oprogramowania bez wymagań. Zamiast tego ma na celu uzyskanie wymagań od właściciela projektu, niezależnie od tego, czy istnieje formalna dokumentacja wymagań, czy nie.” O tym też dużo myślałem. To prawie jak bycie dobrym detektywem lub umiejętność przesłuchania kogoś i zadawania właściwych pytań. W tej sytuacji znajduję pytanie: „Czy możesz mi powiedzieć, co chcesz zrobić?” działa znacznie lepiej niż „Czy możesz mi powiedzieć, jak powinno to działać?”
5
@BrianReindel Czasami zaczynam od kombinacji mapy myśli / drzewa binarnego myśli klienta. Pytam „Jaki jest pomysł?”, A następnie używam skojarzenia słów, aby zobaczyć, co każdy pomysł przywołuje na myśl klienta. Stamtąd buduję obraz tego, co myśli klient i zaczynam od tego definiować wymagania. Każdy wymóg wywołuje pytania, które należy zadać. Zwykle pytania „dlaczego” dają mi lepszą odpowiedź niż pytania „co / jak”, ponieważ dają klientowi możliwość myślenia poza podstawami. Zasadniczo jest to sztuka wykorzystywania psychologii, aby ujawnić potrzeby klienta.
S.Robins
3
Częścią umiejętności jest znajomość kolejności robienia rzeczy i unikanie „doskonalenia” rzeczy, które i tak zostaną rozerwane. W ten sposób możesz spotkać się z klientem / menedżerem / kimkolwiek, pokazać im, co masz do tej pory i dostosowywać się w miarę postępów. Najpierw musisz wiedzieć, jak stawiać duże kroki we właściwym ogólnym kierunku.
David Schwartz
4
Jednym ze sposobów na uzyskanie wymagań jest przekazanie im czegoś podstawowego i sprawdzenie, na które części skarżą się. Na przykład stwórz prototyp papierowy ( amazon.co.uk/… ) i przejrzyj interakcje z nimi.
deworde
35

To bardzo dwuznaczne…

Dwie rzeczy, które mogę powiedzieć:

  1. Jest wielu utalentowanych ludzi technicznych, których kariera zostaje przerwana, ponieważ czekają na idealne wymagania. Lub grają: „Przepraszam, nie mogę tego zrobić, nie było to wymagane”. W rzeczywistości pisanie wymagań jest bardzo trudne. Precyzja wymagana dla dobrych wymagań jest niepodobna do niczego, co większość ludzi biznesu kiedykolwiek stworzyła. Pomiędzy technologią a biznesem istnieje pomost, a ludzie, którzy sprawiają, że inni przychodzą w 100% na spotkanie z nimi, zwykle przegrywają.

  2. Są ludzie oprogramowania, którzy uczą się domen tak dobrze lub lepiej niż ich klienci. Ci ludzie są na wagę złota, nawet jeśli nie są w 100% najlepszymi programistami. Widziałem, jak ludzie oprogramowania przewidują ilościowe potrzeby marketingowe najlepszych menedżerów marek w kraju. Nie byli najlepsi w kodowaniu wszystkich rozwiązań, ale byli bohaterami, ponieważ mogli przekroczyć most.

W życiu nie chodzi jednak o czerń i biel. Jeśli narysujesz wokół siebie wąskie pudełko, ograniczysz się. Z drugiej strony, organizacja, która odrzuca to, co jest potrzebne do tworzenia technologii, jest również ograniczona. Musisz zobaczyć, gdzie na szaro chcesz być.

MathAttack
źródło
12

Wymagania to kroki w podróży, wizja to kierunek

W przypadku wielu aplikacji bardzo szczegółowa specyfikacja techniczna jest zbyt przesadna, ponieważ szybka dyskusja może sprawić, że ich starannie skomponowany dokument nie będzie przydatny. Zamiast tego zacznij od wizji. Jeśli wszyscy rozumieją ogólny obraz, wymagania mogą zostać wypełnione podczas dyskusji.

Jako programista musisz nauczyć się korzystać z tych dyskusji, aby przeszukiwać wymagania . Oznacza to zadawanie wiodących pytań klientom, które skłaniają ich do zastanowienia się, jak dzisiejsza decyzja wpasowuje się w ogólną wizję. Im wcześniej te bardziej szczegółowe dyskusje będą miały miejsce, tym szybciej ogólna wizja utrwali się w spójny projekt.

Powinieneś śledzić wyniki tych dyskusji w jakimś narzędziu do śledzenia problemów, aby inni mogli je komentować, jeśli przegapią oryginalną dyskusję. Abyś miał dokumentację, do której ty lub inni członkowie zespołu możecie się odwołać w razie potrzeby wyjaśnienia.

Naucz się kodować zgodnie z wizją, ale przygotuj się na te wymagania, gdy przyjdzie czas.

Gary Rowe
źródło
+1 za „Wymagania to kroki w podróży, wizja to kierunek”
użytkownik
10

Steve Jobs uważał, że klienci nie mogą dokładnie opisać, jak mają wyglądać przyszłe produkty, więc Twoim zadaniem jest ich dostarczenie. Tak więc, chyba że cały czas dostarczasz niestandardowe oprogramowanie, zapomnij o formalnych specyfikacjach i zacznij od tworzenia prototypów, pozwalając klientom bawić się nimi i mówić, co myślą. Musisz postawić właściwą osobę wykonującą prototypowanie, a ona potrzebuje pomocy. Mówię to z doświadczenia - jestem prototypową małpą, która uwielbia tworzyć intuicyjne interfejsy i współpracuję z kimś w produkcie, który rozumie, czego chcą klienci i potrafią wyjaśnić wszystko na papierze lub w programie Excel.

Żadne z nas nie jest geniuszami, ale myślimy podobnie - można niemal powiedzieć, że mamy chemię i wywarliśmy ogromny wpływ na to, co się buduje i jak. Teraz tylko średni i duży zespół może sobie pozwolić na prototypowanie i niekodowanie, którzy opracowują wyłącznie produkty, ale jest tego warte. Prototypowanie jest najtańszym etapem w tworzeniu oprogramowania, więc sensowne jest jedynie poprawienie interfejsu użytkownika i pozornego zachowania. Nie przeczytałem Code Complete, ale myślę, że coś takiego napisano w tej książce.

Specyfikacje są miłe, ale nigdy nie są idealne. Istnieje na ten temat twierdzenie. Nie możesz udowodnić, że specyfikacja jest kompletna i nie możesz udowodnić, że narzędzie nie zawiera błędów lub że się zatrzyma :)

Jednak firmy produkujące oprogramowanie cały czas dostarczają oprogramowanie pomimo tych niedoskonałości procesu. Specyfikacja nigdy nie będzie idealna. Specyfikacja jest również NIESTANDARDOWA i nieaktualna. Specyfikacja prototypu przypomina tabelę logarytmiczną pojedynczego wykresu - specyfikacja jest w zasadzie nudną broszurą przeznaczoną do wydrukowania, podczas gdy zamiast niej można wchodzić w interakcję z narzędziem / wykresem. Sprawdź http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html inspiracji.

Teraz spec jest dobry, jeśli musisz mieć umowę na pokrycie tyłka. Ale specyfikacja powinna wciąż pojawiać się po prototypie, a nie wcześniej. Twoim zadaniem jest dowiedzieć się, jak zrobić tanie prototypy.

Praca
źródło
+1 za specyfikację nigdy nie jest idealną, ale -1 za specyfikację nienaturalną i nieaktualną. Potraktuj wymagania jako listę funkcji, których chce klient, a specyfikację jako listę zachowań, które określają to, czego potrzebuje klient. Zasadniczo rodzaj umowy określającej sposób działania systemu, a nie jego system. Duży projekt i specyfikacja są problematyczne, ale podobnie jak wszystkie duże problemy, łatwiej jest zrobić, gdy zostaną podzielone na części. Prototypowanie jest również rzadko opłacalne, jeśli nie masz pojęcia CO do prototypowania. Tutaj specyfikacje oferują punkt początkowy ...
S.Robins,
... jednak specyfikacje niekoniecznie muszą być napisane w kamieniu. Prototypowanie (w zasadzie problemy z wyostrzaniem) są najbardziej cenne, gdy dostarczają nowe informacje z powrotem do specyfikacji i gdzie specyfikacja może się zmieniać, aby uwzględnić rzeczy, których nauczyłeś się z prototypu. Bez specyfikacji ryzykujesz po prostu wymyślanie rzeczy na bieżąco, co nie zawsze leży w najlepszym interesie klienta. Klienci oczekują, że spełnisz ich potrzeby, a Ty ryzykujesz mniej tarcia, gdy możesz przedstawić dowód, że zgodziłeś się na coś, nawet jeśli tylko wstępnie.
S.Robins
@S. Robins, lekarz (klient), może powiedzieć coś tak prostego, jak: „Chcę zobaczyć drzewo genealogiczne z odpowiadającym mu szacowanym ryzykiem raka dla każdego członka rodziny”. Ponieważ istnieje wiele różnych sposobów prezentowania tych informacji i martwienia się o duże rodziny, które obejmują wiele stron, myślę, że absurdem byłoby rozpoczęcie dokumentowania tego jako specyfikacji od razu. Zrozumieliśmy, co powiedział lekarz, ale chcemy być bardziej precyzyjni. Interaktywny prototyp, który wyświetla losowe liczby i nazwy, które doktor może powiedzieć yay lub no, jest bardziej naturalny niż niekompletna 30-stronicowa specyfikacja, która próbuje to samo opisać.
Job
1
Rozumiem, skąd pochodzisz, jednak to, co sugerujesz, jest zwykle drogie. Oczywiście nie sugeruję, że prototyp jest kompletnym produktem, ale wszystko, co zbudujesz w miejscu, w którym występuje interaktywność, będzie wymagało czasu. Mniej kosztowną opcją jest stanie na tablicy, naszkicowanie kilku pomysłów i zadawanie ukierunkowanych pytań, które pomogą ci zawęzić kryteria. Nie jestem też zwolennikiem tworzenia dużej specyfikacji. Dokumenty konturowe, a nawet szablony kodów testowych, tworzone iteracyjnie i w razie potrzeby, są zwykle prostsze i tańsze niż pierwsze prototypowanie.
S.Robins
3

Ja często, że w niektórych sytuacjach trzeba działać jako analityka biznesowego, odkrywając dokładnie jak obecnie firma działa, jak ludzie myślą to działa (często bardzo różne rzeczy), i jak oni lubią go do pracy.

Odniosłem sukces, zawsze mając jasność co do decyzji, które muszę podejmować, aby zbudować oprogramowanie. Wyjaśniam swoje rozumowanie, piszę dokumentację na temat tego, co odkryłem, tworzę wykresy i rozpowszechniam je wśród wszystkich itp.

Prawdopodobnie nie zrobisz dobrego wrażenia, odmawiając wykonania jakiejkolwiek pracy, dopóki nie zostaną przekazane pełne wymagania. Ale samemu gromadząc wymagania dotyczące jakości (niekoniecznie zwracając uwagę na ten fakt), osiągniesz ten sam cel, jakim jest oprogramowanie wysokiej jakości.

I tak, jak powiedzieli inni komentatorzy, zawsze buduj oprogramowanie, zakładając, że się zmieni. Zmiana jest jedyną stałą, na której można polegać. Zawsze buduj oprogramowanie na tyle elastyczne i modułowe, aby aktualizacja nie była bolesna, gdy nagle pojawią się nowe wymagania.

Will Sheppard
źródło
3

Jeśli chcesz pracować jako programista przy starcie, jest to umiejętność do opanowania.

Jeśli chcesz pracować w firmie konsultingowej, jest to sytuacja, której należy unikać za wszelką cenę. Wynika to z faktu, że Twoja firma otrzymuje wynagrodzenie w zależności od tego, jak dobrze wdrażasz specyfikację / wymagania, a nie od tego, jak dobrze rozwiązałeś problem klienta.

Jeśli kodujesz dla zabawy w wolnym czasie, to twoja rozmowa. Jeśli nie czujesz się wykwalifikowany, aby zadzwonić do swoich projektów w wolnym czasie, wypróbuj kilka sposobów i sprawdź, co działa. Poza tym nie jest to jedna rzecz uniwersalna, niektóre projekty wymagają takiego lub innego podejścia. Zwykle, jeśli wybierzesz niewłaściwy w jednym z tych projektów, szybko się zorientujesz.

Jan
źródło
2

Trochę obu. Musisz zadowolić swoich klientów, co oznacza, że ​​musisz wiedzieć, czego chcą. Z drugiej strony klienci są bardzo słabi w komunikowaniu tego, czego naprawdę chcą.

Dlatego chcesz uniknąć scenariuszy, w których nie wiesz, czego oczekują klienci, ale nieuchronnie napotkasz scenariusz, w którym wymagania są co najmniej „miękkie”, aw najgorszym - zwodnicze. Dobry programista w świecie rzeczywistym wymaga adaptacji.

Telastyn
źródło
2

Nie można napisać programu bez wymagań. Nawet „Hello World” ma wymóg: produkować dane wyjściowe. Więc myślę, że pytasz o wymagania formalne, w postaci jakiegoś dużego stosu czegoś podobnego do UML. Jeśli chodzi o nich, poznałem 2 rodzaje ludzi:

1) Ludzie, którzy potrzebują wymogów formalnych. Trzeba im dokładnie powiedzieć, co robić, a co najwyżej jak to zrobić. Uwielbiają zdania takie jak Procedura A, biorąc argument B , wygeneruje C i nienawidzą tych: Program powinien usprawnić pracę naszego oddziału . Zazwyczaj są to zwierzęta korporacyjne.

2) Ludzie, którzy są przeciwni do 1. Nie lubią mówić, co robić i jak to robić, lubią mówić, co należy osiągnąć. Lubią rozmawiać z klientem, analizować, co mówią, a następnie opracować własne rozwiązanie. Zazwyczaj są freelancerami i nie pasują dobrze do korporacji.

Nie powiem, który z nich jest lepszy. Oba mają swoje zalety i zalety. Są proste odpowiednie dla innych warunków.

Żeglarz dunajski
źródło
0

NIE możesz tworzyć oprogramowania operacyjnego bez znajomości wymagań; ale możesz mieć świetny zastrzyk w rozwijaniu tego, co mówi twoje doświadczenie, że wymagania są prawdopodobnebyć. Zwinne projektowanie wykorzystuje kombinację „intuicyjnych” technik, w tym reguły 80:20 i „odkrywania” wymagań poprzez prototypowanie. Innymi słowy, doświadczony zespół programistów najlepiej zgaduje, co jest potrzebne i tworzy prototyp oprogramowania. Reguła 80:20 mówi, że będą w 80% poprawne. Następnie interesariusze projektu dokonają przeglądu namacalnego prototypu. Ich opinie zaczynają wypełniać lukę 20% w naszym rozumieniu wymagań. W efekcie, Agile nie polega na pisaniu oprogramowania bez żadnych wymagań, a raczej na wykorzystaniu wcześniejszego doświadczenia i powiedzenia „chcesz czegoś takiego?” Który, w 80% przypadków, pozwoli ci przeskoczyć do przodu i potwierdzić, co naprawdę jest potrzebne, szybciej niż plodowanie w tradycyjnych procesach wymagań.

Richard Seddon
źródło
Zwinność nie polega na intuicji, lecz na komunikacji. Częste dostarczanie działającego oprogramowania w celu często otrzymywania informacji zwrotnych zachęca do komunikacji i docenia dostarczanie rzeczy, których potrzebuje klient. Tak, doświadczenie wchodzi w grę, ale istnieje większe prawdopodobieństwo, że opracujesz to, czego potrzebuje klient, jeśli najpierw zapytasz, czego wymaga klient. Tak zwana zasada 80:20 tak naprawdę nie ma zastosowania, chyba że dobrze znasz domenę biznesową klienta, a nawet wtedy wziąłbym tę „statystykę” dużą łyżką soli.
S.Robins
-2

Kto powiedział, że Agile pisze kod przy braku wymagań? Wiem, że Manifest został przez niektórych zinterpretowany w ten sposób ... ale to nie jest poprawne.

Trent
źródło
1
Cześć Trent, chociaż zgadzam się z twoim komentarzem w zasadzie (i jestem też zmęczony widzeniem, jak ludzie używają Agile jako pretekstu, by przekręcić proces rozwoju i nazwać go „byciem zwinnym”), ta odpowiedź tak naprawdę nie odnosi się do OP pytanie, które nie dotyczy Agile, ale pytanie, czy pisanie oprogramowania bez wymagań jest umiejętnością do rozwijania. Być może chciałeś dodać to jako komentarz do odpowiedzi innej osoby?
S.Robins