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

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?

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.

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.

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?

Ż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ł.

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.

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

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.

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.

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.