Czy Agile można osiągnąć bez udziału klienta?

23

Nie mogłem napisać książki o Agile. Pracowałem w kilku sklepach, które nazywają ten proces zwinnym. Jednym z głównych punktów rozwoju Agile jest regularne zaangażowanie klienta. Po sprincie praca może zostać pokazana klientowi w celu uzyskania opinii. Wypłukać i powtórzyć.

Problem, z którym się zetknąłem, polega na tym, że wielu klientów nie chce być tak zaangażowanych. Woleliby podejście do wodospadu. Zbierz wymagania z góry, a następnie wróć, gdy skończysz. Z mojego doświadczenia wynika, że ​​wodospad nie działa. Klienci nie wiedzą, czego chcą, dopóki tego nie zobaczą. Dylemat wodospadu jest szerzej propagowany przez dużą społeczność programistów, którzy chcą mieć wszystkie wymagania z góry. W ten sposób wiedzą, co budują, mogą odpowiednio zaprojektować i klient jest winny, ponieważ „podpisał się” na tych wymaganiach.

Czy jestem w błędzie? Czy Agile może działać bez udziału klienta? Jeśli tak, to jak i jak przezwyciężyć omówione przeze mnie problemy?

P.Brian.Mackey
źródło
12
Nie pozwól, aby „zwinny” stał się twoim młotem, aby wszystko inne wyglądało jak gwóźdź, który wymaga wbicia w ciebie.
Patrick Hughes,
1
Z mojego doświadczenia wynika, że ​​preferencje wobec podejść wodospadowych są na ogół spowodowane brakiem zrozumienia, jak działa oprogramowanie lub projekt. Dobra wiadomość jest taka, że ​​Agile nie jest dużym problemem, lecz nastawieniem / zrozumieniem klienta. Złą wiadomością jest postawa klienta.
Ben Brocka
@BenBrocka: To nie jest zaskakujące, biorąc pod uwagę, że właśnie po to został zaprojektowany Waterfall. Autor chciał napisać artykuł na temat tego, jak mógłby wyglądać proces programowania utworzony przez kogoś, kto nie rozumie tworzenia oprogramowania i dlaczego taki proces nie może działać. Tak więc specjalnie wymyślił Wodospad jako przykład procesu, który został zaprojektowany przez kogoś, kto nie rozumie rozwoju oprogramowania i który prawdopodobnie nie może działać. Oczywiście nie jest zaskoczeniem, że przemawia do ludzi, którzy nie rozumieją tworzenia oprogramowania, ani nie jest zaskoczeniem…
Jörg W Mittag
@BenBrocka:… że to nie działa. Co zaskakujące, to dlaczego ktoś jeszcze chce użyć procesu, który jest specjalnie zaprojektowany, aby nie działać. Chyba nikt nie zadaje sobie trudu, żeby przeczytać gazetę.
Jörg W Mittag
1
@ JörgWMittag Rzeczywiste przyjęcie wodospadu (niezależnie od tego, czy zdają sobie sprawę, że to wodospad, czy nie) wynika głównie z tego, że jest to standardowy model decyzji biznesowych; szef chce czegoś, rozumiesz, klient jest szczęśliwy, prawda? Oczywiście to nie działa, ale jest to ładny prosty model dla miłych, prostych umysłów :)
Ben Brocka

Odpowiedzi:

17

Jak to możliwe? Sama natura tej techniki narzuca pewien rodzaj sprzężenia zwrotnego między klientem a deweloperem.

Część twojego zespołu może jednak działać jako „zastępczy” klient (podobny proces do „jedzenia własnej psiej karmy”), dzięki czemu możesz „udawać”, że jesteś zwinny, chociaż nie będzie to tak satysfakcjonujące, jak uzyskanie faktycznego klienta sprzężenie zwrotne.

Czy ci się to podoba, czy nie, klient będzie zaangażowany w proces projektowania; to tylko kwestia tego, ile kosztują przeróbki (im dłuższe jest opóźnienie, tym jest ono droższe).

Ponieważ klient chce „Big Design Up Front”, pomóż mu zrozumieć, że przygotowanie projektu za pierwszym razem zajmie więcej czasu i wysiłku.

Robert Harvey
źródło
5
Część twojego zespołu może jednak działać jako klient „proxy” - z mojego doświadczenia wynika , że testerzy stworzyli całkiem skuteczne „proxy”, o których wspomniałeś. Kiedy sam byłem testerem, czasami udawałem, że tak powiem, noszę garnitur klienta . Taki prokurent ma jednak ograniczenia - np. Facet z działu jakości narzekający na to, ile czasu zajmuje instalacja produktu, może się tak czuć, ponieważ robi to codziennie, podczas gdy klient robi to raz w roku lub dwa
komnata
it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Dla kogo jest to jednak naprawdę droższe? Większość klientów nie postrzega tego jako zapłaty za poświęcony czas na przygotowanie obecnej wizji rozwiązania. Czasami mają po prostu problem i nie mogą wiedzieć, jakie powinno być rozwiązanie, dopóki nie powiesz im, co to będzie. W tym momencie, jeśli to, co im powiedziałeś, nie rozwiązuje ich problemu, to TWÓJ WAD nie należy do nich. Jak to ich wina, że ​​źle zrozumiałeś ich prawdziwe problemy? cd ...
wałek klonowy
cd ... dlaczego mieliby za to płacić? Aby zaoszczędzić twarzy klienta i nie przekreślić szansy na powtórzenie transakcji, musisz się odwrócić i wykonać przeróbkę za darmo, ponieważ w pierwszej kolejności zażądali oni umowy o stałej cenie. Jest to bardziej rozpowszechnione podejście i dokładnie to, czego doświadcza P.Brian.Mackey. Klienci mocno uzbrajają te negocjacje, a gdy jesteś tylko jednym ze 100 startupów próbujących zdobyć kontrakt, facet z realistyczną i uczciwą umową opartą na Agile będzie musiał czekać z tyłu linii. Obecnie jest to trudne.
wałek klonowy
@maple_shaft: Widocznie zostałeś przez to spalony. Ale, jak w przypadku wszystkich rzeczy, sprowadza się do wyborów. Zwinność istnieje, ponieważ wodospad ma swoje problemy, a ludzie nie są doskonali. Jeśli klient został poinformowany o ryzyku, a mimo to chce wodospadu, to jego wybór. To także wybór sklepu oprogramowania, aby zdecydować, czy warto ryzykować wodospad na kliencie, który nie rozumie ryzyka, lub zaprzecza jego ważności.
Robert Harvey
@RobertHarvey Nawet zły klient w złej gospodarce jest nadal klientem i nadal świeci przez kilka miesięcy. Ryzyko dla klienta w przypadku, o którym wspomniałem, jest minimalne i zależy od tego, czy otrzyma obiecane rozwiązanie na czas. W tym przypadku ryzyko dla sklepu z oprogramowaniem jest takie, że ten bolesny klient wyssie nas do sucha.
wałek klonowy
7

Krótka odpowiedź na twoje pytanie brzmi „nie”. Oto komentarze do niektórych części twojego pytania. Aby być dokładnym, większość odpowiedzi opiera się na moich osobistych doświadczeniach i spostrzeżeniach.

Z mojego doświadczenia wynika, że ​​wodospad nie działa.

Waterfall to solidna metodologia dostarczania systemów o różnym stopniu złożoności. Szkoda, że ​​nie jest dobrze przedstawiony ani zrozumiany. Jednym z powodów jest to, że nie zarabia wystarczająco dużo pieniędzy, konkurując z metodologią dnia, która ciągle się pojawia. Możesz być zaskoczony, wiedząc, że wiele systemów bankowych, ubezpieczeniowych i produkcyjnych zostało zbudowanych tylko przy użyciu metody Waterfall, a wiele z nich jest nadal w produkcji. To smutne, że branża oprogramowania opiera się na hype bardziej niż na nauce.

Klienci nie wiedzą, czego chcą, dopóki tego nie zobaczą.

To jest mit. Też duży. Może tak być w przypadku projektowania / układu strony internetowej, ale w przypadku przetwarzania danych biznesowych większość użytkowników chce czegoś, co działa. Niektórzy z tych użytkowników nadal używają ekranów AS / 400 i monitorów CICS 3270 z RGB i mogą wykonywać swoje zadania dzięki tym narzędziom. Ponadto ci sami użytkownicy akceptują systemy SAP i ORACLE ERP, nie mając wpływu na projekt interfejsu (a czasem także na funkcjonalność). Większość użytkowników biznesowych dostosuje nawet swoje nawyki i przepływy pracy, jeśli system zapewnia prawidłowe działanie. Nacisk jest tutaj na funkcję, a nie wygląda. Ludzie biznesu doskonale rozumieją, jak wykonują swoją pracę w 90% przypadków.

Dylemat wodospadu jest szerzej propagowany przez dużą społeczność programistów, którzy chcą mieć wszystkie wymagania z góry. W ten sposób wiedzą, co budują, mogą odpowiednio zaprojektować i klient jest winny, ponieważ „podpisał się” na tych wymaganiach.

Nie można winić programistów za to, że chcą wiedzieć, co budują, ponieważ ci programiści chcą iść do domu, ugotować obiad i naciskać koszulki na kolejne ćwiczenia po spędzeniu około 3 godzin na nauce nowej technologii. które zastąpią ich obecny zestaw umiejętności! Ta wina nie czyni nikogo zwycięzcą. Pomyśl o rolach i obowiązkach każdej ze stron, a obraz będzie bardzo wyraźny.

Podsumowując, menedżerowie projektów, programiści i projektanci stron internetowych nie zastępują analityków biznesowych, którzy powinni wiedzieć, jak zbierać wymagania od użytkowników końcowych niezależnie od metodologii.

Bez szans
źródło
3
+1 - dla rywalizujących „klientów nie wiem”. To kwestia różnych domen i różnych typów klientów. Właśnie dlatego agileści nie rozumieją ludzi z wodospadu. Wierzą, że możesz powiedzieć tylko to, co chcesz, kiedy to zobaczysz. To nieprawda, ale to wszystko, co widzą od swoich klientów. Podczas gdy zwolennicy wodospadu nie mogą zrozumieć, dlaczego nie można uzyskać przytłaczającej większości wymagań z góry, aby projekt mógł uwzględnić wszystkie problemy. Jest tak prawdopodobnie dlatego, że ludzie z wodospadu nie mają zbyt wiele do czynienia z nie chcącymi klientów.
Dunk
1
@Dunk, dziękuję za komentarz. Podoba mi się twoje sformułowanie „” lubię klientów ”!
NoChance
2

Nie chcą tracić czasu, a jeśli mają wybór, wolą dostać oprogramowanie za darmo, ale nadal będziesz je ładować, prawda? Znika to, jeśli tworzysz oprogramowanie wewnętrznie dla swojej firmy. Uważają, że dział IT został zakupiony i opłacony (pracownicy najemni), więc równie dobrze mogliby uzyskać od ciebie jak najwięcej pracy.

Możesz być potencjalnie zwinny. Uzyskaj wszystkie specyfikacje i zacznij kodować. Gdy klient przerywa pracę, ponieważ pomyślał o soomettingu i musisz wprowadzić zmiany i poprawki, stałeś się trochę bardziej zwinny. Możesz również dokonać zatwierdzeń w swoim zespole. Poproś jednego z członków zespołu, aby włożył garnitur i krawat i udawał, że jest klientem.

Podjęcie dużego zobowiązania z góry może ich odstraszyć. Zaproponuj sprint, aby go wypróbować. Następnie daj im szansę zrezygnowania. Do końca projektu możesz zawsze przejść do wodospadu. Sugeruj także, aby różne osoby w ich zespole mogły dokonać przeglądu i zatwierdzić, czy czas jest ograniczeniem dla osoby wystawiającej czek.

W pewnym momencie musisz im powiedzieć, że nie uważasz, że wodospad zadziała. Zapytaj ich, czy są zadowoleni z tego podejścia, a jeśli tak, to dlaczego nie zlecili temu ostatniemu projektowi?

JeffO
źródło
2

Żadna metodologia nie może działać bez zaangażowania klienta. Wyrejestrowanie się z wymagań może być bez znaczenia, czego byłem świadkiem w projektach, w których uczestniczyłem. Twój problem wykracza poza zdolność Agile, musisz edukować swojego klienta i upewnić się, że rozumie, jak ważny jest dla niego udział.

Otávio Décio
źródło
2
Czy nie jest to kwestia ilości i częstotliwości uczestnictwa klienta, a nie kwestia wszystkiego, czy nic?
JeffO
3
Klient, który często odmawia uczestnictwa, jest moim zdaniem klientem wymagającym wykształcenia. Nie jest niczym niezwykłym, że eksperci biznesowi klienta zajmują pozycję, w której muszą wchodzić w interakcje z firmą zajmującą się tworzeniem oprogramowania i nadal wykonywać codzienne czynności, na co należy zwrócić uwagę, rozmawiając z ich przełożonymi.
Otávio Décio
2

Myślę, że jedną z głównych zalet Agile jest możliwość uzyskania bardziej szczegółowych wymagań dla każdej funkcji ogółem. Kiedy klient z góry podaje wszystkie swoje wymagania, każda funkcja jest zwykle niejasnym pomysłem, ze zdefiniowaną odrobiną funkcjonalności. Siły agile klientowi ponownie każdą funkcję i skupić się na dokładnie to, co chcą i jak funkcja pasuje do większego obrazu. Aby uzyskać tę samą ilość szczegółów (wystarczającą ilość szczegółów, aby zaimplementować funkcje) w specyfikacji, wodospad naprawdę wymaga wykonania jednej z dwóch czynności:

  1. Odgadnąć. Wdrażaj, dopóki nie natkniesz się na coś, co jest niejasne, a następnie osądzaj, jak według Ciebie najlepiej będzie zastosować tę funkcję. To oczywiście nie jest idealne, ponieważ prowadzi do „Czekaj, nie o to prosiłem!” scenariusz.

  2. Połóż znacznie większy nacisk na projektowanie z góry. Zasadniczo, gdy klient rzuci w ciebie swoją na wpół upieczoną specyfikacją pierwszego dnia, zaplanuj szczegółowo każdą minutę przed wdrożeniem czegokolwiek. Poproś klienta, aby wyjaśnił wszystko ad nauseum do punktu, w którym znasz każdy szczegół wdrożenia dla całego projektu. Chociaż nie jest to idealne, jest to lepsze niż opcja 1. Nadal możesz natknąć się na szczegóły, których nie spodziewałeś się, a nawet może wysłać klienta biegającego na wzgórza, ale jeśli naprawdę nie chcą komunikować się podczas programowania, a ty nie mają zdolności parapsychologicznych, to konieczność. Jest to w zasadzie wodospad i ma wszystkie związane z tym wady, w tym niezwykle trudne do prawidłowego wykonania.

  3. Weź na wpół upieczoną specyfikację, ale i tak poproś o wyjaśnienie. Pracuj, aż dotrzesz do niejasnej części specyfikacji, a następnie poproś klienta o wyjaśnienie. Oczywiście nie o to prosił klient, ale jeśli nie chce, aby aplikacja była tak mętna jak specyfikacja i nie chce z góry zdefiniować specyfikacji, pozostaje to jedyna opcja. Nie ma wszystkich zalet Agile (takich jak regularne zatwierdzanie przez klienta, aby upewnić się, że wszyscy są na tej samej stronie), jednak pozwala uzyskać informacje potrzebne do opracowania. Ponieważ opcja 1 prawdopodobnie pozostawi Ci produkt podrzędny, opcja 2 jest marnotrawstwem i frustruje klienta (prawdopodobnie będziesz musiał poświęcić co najmniej dwa razy więcej czasu na projektowanie i gromadzenie specyfikacji, jeśli zrobisz to całkowicie z góry), to naprawdę nie jest taka zła opcja. Kluczem tutaj jest staranne modyfikowanie linii czasu i ceny przy każdej nadchodzącej zmianie. Jeśli zrobisz to dobrze, może się okazać, że większość praktyk Agile jest zgodna z tym porozumieniem, nawet jeśli klient go nie zna. IMHO, to jest naprawdę zgodne z duchem Agile, ponieważ powinieneś dostosować metodologie do swojego konkretnego układu.

Jeśli klient naprawdę nie może żyć z konsekwencjami którejkolwiek z tych trzech opcji lub zwinnego Agile, trudno mi jest wyobrazić sobie, jak ten klient może być naprawdę wart twojej chwili.

Morgan Herlocker
źródło
Pominąłeś opcję 4. Bierzesz specyfikację przeważającą większością wymagań. Wykonaj projekt (prawdopodobnie iteracyjny) z recenzjami klientów. Zaimplementuj i przetestuj kod (prawdopodobnie iteracyjny). Przeprowadzaj okresowe przeglądy programu informujące klienta o postępach i decyzjach. Przekazują informacje zwrotne, włączasz ich komentarze i kontynuujesz.
Dunk
Opisane powyżej sytuacje miałyby miejsce tylko w przypadku zespołów, które nie wiedzą, jak zrobić wodospad. Tak, wykonanie jest trudne. Zwinne jest również trudne do prawidłowego wykonania. Za każdym razem, gdy ktoś traci zwinność, jakiś agilista rzuca nową zasadę, której nie przestrzegano i twierdzi, że jest to przyczyną niepowodzenia. To nigdy nie jest wina zwinna. Przynajmniej zwolennicy wodospadu przyznają, że potrzeba dobrych ludzi o dobrych umiejętnościach, aby wodospad działał.
Dunk
Twoja opcja 4 jest dokładnie tym, co zamierzałem opisać w opcji 3.
Morgan Herlocker
Jak mogę poprawić swoją odpowiedź? Nie mogę powiedzieć, czy zgadzasz się, czy nie, z tym, co mówię.
Morgan Herlocker
Możesz to poprawić, wybierając słowo na wpół upieczone na początek. Usunięcie części o tym nie jest tym, czego chciał klient. Usuń mętną część specyfikacji itp. W wodospadzie ważną częścią spełnienia wymagań jest zdobycie znaczących elementów architektonicznych i tych, które system absolutnie musi zrobić, aby były użyteczne z przodu. Potem zmiany zwykle nie są tak duże. Wierzcie lub nie, istnieją i zawsze były iteracje, zarówno formalne, jak i nieformalne w rozwoju wodospadu. Na długo przed pojawieniem się zwinności.
Dunk
1

Myślę, że to trudne, ale wciąż możliwe. Myślę, że pomysł proxy Roberta działa, ale konieczne jest, aby proxy spędził jak najwięcej czasu z „prawdziwym” klientem, aby mogli zobaczyć rzeczy z ich punktu widzenia. W ten sposób serwer proxy może ustalić, które funkcje są naprawdę ważne i poznać wrażenia użytkownika, których klient oczekuje / pragnie.

Ale w pewnym momencie będziesz musiał pokazać oprogramowanie „prawdziwemu” klientowi ...

John Shaft
źródło
0

Możliwe jest uniknięcie prawdziwych klientów, w rzeczywistości czasami jest to potrzebne dla przepisów. Zwykle klienci oprogramowania medycznego nie są zaangażowani. W takich przypadkach inne podmioty mogą zastąpić rolę klienta, na przykład zespół marketingowy można uznać za klientów.

dashy
źródło
0

Zwinność wymaga ciasnej pętli, aby zastąpić dużą przednią konstrukcję, która jest twarda - dość trudna, ale w rzeczywistości można to zrobić, zwinność to nie jedyny sposób.

Być może zechcesz znaleźć jedną z modyfikacji Agile - istnieje wiele i jedna prawdopodobnie rozwiązuje ten konkretny problem, ale jeśli nie, wymyśl własny, jeśli uważasz, że możesz.

Wszystkie te procesy zostały wykonane przez inteligentnych ludzi - a inteligentni ludzie mogą sprawić, by każdy proces działał. Nie sądzisz, że wodospad został wymyślony, ponieważ nigdy nie działał dla nikogo? Ewoluowało, ponieważ niektórzy ludzie mogli sprawić, by działało, a inni patrzyli i powiedzieli: „Muszę to udoskonalić i nakarmić MOIM zespołem, który nie wydaje się produkować tak skutecznie” - w tym momencie prawdopodobnie działało to lepiej niż to, co oni robili, ale jeśli nie zdajesz sobie sprawy, że nie każdy programista może rozwiązać każdy problem, naprawdę może cię zaskoczyć, dlaczego dwa zespoły stosujące ten sam proces mogą mieć różne wyniki.

Problem polega na tym, że wiele procesów wymaga talentu do ich wdrożenia - mówimy o talentach tak rzadkich jak profesjonalni gracze sportowi z puli wszystkich, którzy kiedykolwiek uprawiali sport - są szanse, że większość z nas nigdy nie spotkała kogoś, kto byłby w stanie gówniane procesy jak wodospad i dlatego tak wielu ludzi myśli, że to się nie uda - nigdy nie widzieli, żeby działało.

Sprawne działanie Agile wymaga znacznie mniej talentu, ale wymaga pewnych bardzo konkretnych inwestycji, takich jak ciągłe sprawdzanie przez klienta tego, co robisz, aby błędy nie mogły się rozprzestrzeniać, a także bezwzględne refaktoryzowanie, abyś nie narastał dług techniczny, którego zespół nie jest w stanie rozwiązać kilka miesięcy później.

Bill K.
źródło
0

Zdefiniuj klienta.

Czy to inna firma? Inna osoba?

Czy to inny zespół w Twojej firmie?

Czy to mistrz produktu w Twojej firmie?

Czy to ty?

Wszystkie powyższe są możliwe i całkiem rozsądne w zależności od okoliczności. Nie chcesz patrzeć w dół tunelu na to, co ma być zwinne, więc powiedzenie, że ostateczne NIE byłoby nieprawidłowe. Z drugiej strony TAK wymaga nieco myślenia bocznego.

Pomyśl przez chwilę o słowie Agile . Bardzo sprytna grupa ludzi, którzy wymyślili ten termin, nie mogła wybrać lepszej metafory koncepcji, którą próbowali opisać. Kiedy mówisz Zwinność , co przychodzi Ci do głowy? Jesteś flotą pieszych? Być może szybko zareagować? Szybko się przystosowuje?

Pomyśl teraz o wszystkich powszechnie przyjętych praktykach zwinnych i zadaj sobie pytanie, co tak naprawdę przynoszą do metod programowania, które są uważane za zwinne .

Jestem klientem do wszystkich celów i celów moich indywidualnych projektów. Czasem nawet noszę prawdziwy kapelusz, kiedy naprawdę chcę dokonać wyraźnej zmiany mentalnej w roli mojego klienta . To sprawia, że ​​jestem nie mniej zwinny niż ja, kiedy jestem w pracy. Zależy mi, mój kot może być menedżerem. Upewnia się, że co jakiś czas robię sobie przerwę na odpoczynek, i przypomina mi, abym unikał zbytniej obsesji na punkcie jednego zadania. Może wolisz użyć swojej wymyślnej „techniki Pomadoro”, ale wolę Timer „Rascal” !! Chodzi o to, że pracuję w ściśle zwinnym procesie za każdym razem, gdy piszę kod dla siebie. Nie jestem typem hakera-kowboja, który żyje w nieskończonych skokach rozwojowych i niczego nie osiąga. Lubię tworzyć własne oprogramowanie, planować rozwój wokół mojego życia zawodowego i osobistego oraz ukończyć go w sposób, którego oczekiwałbym, gdybym pracował dla prawdziwego klienta. Kiedy wszystko zakłóca mój harmonogram, dostosowuję i priorytetowo pracuję nad projektem. Używam wszystkich standardowych praktyk i technik zwinnych, które mogę zastosować solo, i „dostarczam” działający kod do siebie (lub przyjaciela lub kolegi do testowania) tak często, jak to możliwe. Jeśli to wszystko nie jest zwinne, pytam cię, co to jest?

Więc moja odpowiedź brzmi: tak , możesz być programistą Agile Software i możesz zastosować metodologię Agile i niekoniecznie potrzebujesz klienta, a nawet kierownika. Możesz samodzielnie pracować nad projektem i nosić wiele czapek. Jednak niekoniecznie Idealne może być pozbycie się tych innych ról, ponieważ bardzo pomocna jest współpraca z innymi, aby osiągnąć cel. Działają one jako płyta rezonansowa dla twoich pomysłów i spełniają wymagania, które w innym przypadku mogłyby być trudne do wygenerowania samodzielnie. Inną bardzo ważną rolą, jaką spełnia klient i menedżer, jest utrzymywanie koncentracji na swoich celach, bez ciągłego dodawania funkcji i dopracowywania kodu poza to, co może być absolutnie konieczne.

Mimo to, jeśli pracujesz w sposób zdyscyplinowany, ściśle przestrzegając wybranej metodologii i stosujesz zwinne praktyki, a także, jeśli zostaniesz śledzony z boku lub zmienisz zdanie (nosząc kapelusz klienta) oraz projekt lub kierunek produktu zmienia się, jeśli możesz dostosować swój harmonogram i dostosować swoje priorytety tak, jak sobie wyobrażasz, że Twój klient tego oczekuje, to jesteś zwinny.

S.Robins
źródło