[quote=piachoo]Pytam nie ze złośliwości, ale z ciekawości. Sam jestem zainteresowany tematyką Agile(w praktyce i teorii) od dłuższego czasu. Według mnie najtrudniejszą rzeczą w pełni rozumianym Agile jest konieczność nakłonienia klienta do wejścia w projekt, którego budżet nie jest określony(klient płaci za czas a nie za rezultaty). Dlatego też najlepsze miejsce dla Agile to według mnie projekty wewnętrzne, gdzie przeważnie klient(tu pracodawca, lub przełożony) i tak płaci na za czas(pensja miesięczna). Dodatkowo praca z takim klientem jest łatwiejsza, bo bariera porozumienia z pomiędzy klientem a programistą jest mniejsza.
Zastrzegam, że sam osobiście nie mam doświadczenia w komercyjnym zastosowaniu pełnego agile. Brałem udział w dwóch niekomercyjnych 2-tygodniowych projektach XP.
Ciekawy jestem jakie Ty miałeś doświadczenia w powyższych zagadnieniach?[/quote]
Ok 
Formułujesz całkiem inteligentne i dotykające istoty rzeczy, czyli realnych problemów pytania.
Ponieważ zasadniczo unikam mówienia o problemach, słowo “problem” wyrzuciłem ze słownika i zastąpiłem terminem “wyzwanie”. Brzmi lepiej 
We challenge you to shape our world.
Najtrudniejszą rzeczą w scrumie jest przekonanie klienta, że brak deadline’ów i brak ustalonej ceny tak naprawdę są dla niego dobre.
Sprzedaż polega na zadawaniu inteligentnych pytań. “Sprzedaż” scruma, co tutaj jest akurat równoznaczne ze “sprzedażą” agile, także.
Po pierwsze należy zapytać klienta, czy zgadza sie ze stwierdzeniem, że czas to pieniądz. Po drugie: zapytać ile czasu zajmie mu napisanie specyfikacji oraz negocjowanie warunków umowy. Po trzecie: czy planuje change requesty i czy zdaje sobie sprawę jaki to będzie miało wpływ na czas, jakość i komfort tworzenia systemu. Co stanie się z budżetem? Co z harmonogramem prac? Czy jest pewny, że efekt końcowy będzie spełniał jego oczekiwania? Że to, co powstanie będzie tym co chciał ujrzeć?
Klient płaci za wartości biznesowe, które generuje każdy sprint. Są one określane na podstawie jego priorytetów. Każdy przyrost funkcjonalności to produkt gotowy do implementacji. Product owner jest integralnym partnerem i uczestnikiem procesu tworzenia oprgramowania. Widzi jak produkt się rodzi, rośnie i rozwija. Widzi jaki wpływ na niego mają jego wytyczne, uwagi i zmiany koncepcji. Widzi, że nic nie trwa zero czasu, a jakość kosztuje. Product owner decyduje o zakresie ingerencji, jaką chce wywierać, o ilości zaimplementowanych features’ów, będąc jednocześnie świadomym, że jego ingerencja przekłada się na czas tworzenia softu, a to na pieniądze. Decyduje, czy bardziej zależy mu na szybszym uruchomieniu aplikacji w warunkach produkcyjnych, czy w dalszym ciągu szlifujemy kod aż będzie błyszczał, czy w danym kształcie może ujrzeć światło dzienne, czy wymaga jeszcze dopracowania. Zatem to klient decyduje o cenie. Tempo, cena, i jakość są determinowane przez klienta. Wszystko jest “under control”.
To będzie uzasadnienie biznesowe. 2w1. Dla klienta i potencjalnego partnera/inwestora.
przytaczam swoje słowa:
Ruby (już nie tylko “on Rails” ) - innowacyjna technologia i lekkie zarządzanie agile stanowią wyśmienity model biznesowy. RoR znacząco skraca czas tworzenia aplikacji (realna korzyść biznesowa - zwracam uwagę na aspekt ekonomiczny), ułatwia dbałość o jakość kodu i przywraca developerom radość z programowania. Innowacyjna technologia + sprawny management - to dwie uzupełniające się strony medalu. Jest to również świetne ujęcie marketingowe. Agile odciąża managerów i przeciwdziała robieniu z programistów “coding monkeys”. Korzyści występują na wszystkich polach: project management, finanse, marketing, HR.
Dlatego się w to bawię. I zapraszam do współpracy.
wypowiedziane na http://www.goldenline.pl/forum/agile/80138
