@somekind Wiele rzeczy które opisałeś są prawdziwe, z wieloma się zgadzam, ale jest kilka rzeczy z którymi się gryzę.
Zacznę od najprostszych:
No to moim zdaniem, jak to czytam, to raczej to nie może być Agile :/ To jest jakaś kopia agile. Nie jesteś w stanie być agile, jeśli zadania są tak duże, po prostu.
W takim razie prawdopodobnie żaden biznes nie jest agile.
No niestety tak :/ Mało która firma która claimuje że jest agile, faktycznie jest :/
To co większość firm robi, to po prostu zaczyna używać niektórych nazw, takich jak "sprint", "user story", "story point", "retro", etc. ale nie zmieniają procesów, więc nie mają żadnych korzyści, ergo nie są agile. Przykre.
Chodzi o to żeby się skupić na tym co się aktualnie robi, i nie próbować przewidywać co będzie potem - nie ma ku temu potrzeby (z punktu widzenia wytwarzania oprogramowania).
Jak najbardziej jest potrzeba. Bo jeśli np. robię coś w jakimś starym API, o którym wiem, że jest przewidziane do wycofania za 3 miesiące, to nie będę się silił na jakąś refaktoryzację przy okazji. Jeśli implementuję nowy ficzer w jakiejś bibliotece, o której wiem w jakich API, i w jaki sposób jest używana, to implementuję go tak, aby zapewnić jak najłatwiejszą integrację z tymi API. Itd., itp.
Jak rozumiem - Twój argument brzmi: "chcę wiedzieć czy jakieś API ma być wycofane za jakiś czas, żeby wiedzieć czy mam go poprawiać".
Odpowiadam: jak najbardziej. Oczywiście, że możesz wiedzieć czy klient planuje usunięcie API czy nie, i jeśli dowiesz się że klient ma plan usunąć API, to jak najbardziej powinieneś wziąć to pod uwagę, podejmując decyzję, czy refaktorować to miejsce.
Zaznaczam: W agile chodzi o to żeby ufać ludziom. Ufać, również Tobie, jako programiście. To co powinieneś zrobić w takiej sytuacji:
- Klient mówi ze za trzy miesiące planuje wycofać jakieś API
- Ty akurat bierzesz zadanie które dotyka tego API
- Zastanawiasz się czy naklepać go na szybko na odwal się, czy zrefaktorować je tak żeby było dobrze.
- Tutaj wchodzi zaufanie do Ciebie jako programisty:
- Powinieneś mieć w głowie takie dwie rzeczy:
- Po pierwsze - wiesz że klient planuje usunięcie tego konkretnego API
- Po drugie - zakładasz że ten plan może się uda, może nie (czyli faktycznie może to API zostanie usunięte, może nie).
- I na podstawie tych dwóch rzeczy to Ty podejmujesz decyzję czy zrobić refaktor tego API czy nie:
- Bierzesz pod uwagę:
- Czas jaki musisz na to poświęcić
- Ryzyko jakie to za sobą niesie
- Potencjalny zyski jakie niesie ze sobą
- Oraz oczywiście bierzesz pod uwage plan klienta na usunięcie tego API
- Ale bierzesz też pod uwagę, że ten plan nie jest na 100%, że to może się udać, ale nie koniecznie. Sam musisz ocenić jak duże prawodpodobieństwo to niesie.
- I na tej podstawie Ty podejmujesz decyzję czy zrobić refaktor czy nie. Oczywiście inni programiści też mogą się dołożyć do tej decyzji, ale nie klient. Klient jedyne co Ci może powiedzieć, to jak bardzo pewny jest usunięcia tego API, albo na 10%, na 50% albo na 100%. Tylko uwaga - nawet jak klient Ci powie że na 100% usuwamy coś za trzy miesiące, to nie daj się zwieść - nie koniecznie to musi to oznaczać.
I wtedy Ty, jako programista, kierując się swoją wiedzą, decydujesz czy zrobić ten refaktor czy nie. Możesz uznać że nie, i to jest w porządku. Tylko chodzi o to żeby kierować się tym, że ten "plan" nie jest pewiankiem.
To miałem na myśli mówiąc że predicibility nie jest potrzebne. To czego potrzebujemy to informacje, feedback, wiedzę (o tym że klient chce usunąć API, oraz kiedy planuje to zrobic), ale nie możemy ślepo wierzyć że skoro klient mówi że za 3 miesiące tak będzie, to znaczy że tak będzie. To miałem na myśli mówiąc że predicibility jest nie potrzebne. Faktycznie pewnym tego usunięcia możesz być w momencie w którym weźmiesz storkę na usunięcie go. Także zgadzam się że programiści muszą mieć informacje, muszą mieć insight, muszą wiedzieć co klient chce zrobić - ale kiedy ja mówiłem że "predictibility jest niepotrzebne", miałem na myśli że nie jest potrzebne programować TERAZ z myślą tylko i wyłącznie o tym że jest jakieś ustalenie o dacie.
- Możesz programować z myślą o planach klienta (important)
- Możesz programować z myślą o tym co klient by chciał (important)
- Możesz programować z myślą, że jakaś rzecz zaraz będzie usunięta,
- Ale raczej nie warto programować z myślą o jakieś ustalonej dacie - bo to nie działa po prostu.
- Zaczynasz kolejne zadanie od (od punktu 1), które teraz ma najwyższy priorytet. Jak je skończysz to potem kolejne, i kolejne krokami 1.-4.
Dobrze, tylko w ten sposób zanim dostanę info zwrotne od klienta mogę tak zaimplementować np. 10 kolejnych tasków, zanim klient zobaczy wynik pierwszego i stwierdzi, że on jednak w ogóle tego nie potrzebuje. Czyli zmarnowałem bardzo dużo pracy, bo zamiast się dowiedzieć i zaplanować pracę, robiłem taski na pałę.
Okej, i to jest kolejna bardzo ważna rzecz na którą zwróciłeś uwagę.
Zgadzam się ze wstępem: Faktycznie, to jest bardzo ogromny problem, że robisz jakieś 10 tasków, i potem klient mówi że "nie o to mi chodziło". I wtedy zmarnowałeś bardzo dużo pracy. Tak, to jest prawda, i to jest bardzo duży problem.
I rozwiązania jakie to ma są takie:
- Albo, możesz zrobić "analizę" próbują wydedukować które feature'y są potrzebne a które nie (tylko że takie coś działa gorzej, i wygląda jak waterfall)
- Albo możesz zrobić małą rzecz, i (owszem) ryzykować że okaże się że jest niepotrzebna/zła/nie udana. I tutaj ludzie się boją tego ryzyka. Nie chcą marnować czasu na nieudany feature. Jaka jest na to rada? Bardzo prosta - trzeba robić małe kroki, tak małe że zajmą kilka godzin, maks jeden dzień. Wtedy, jeśli okaże się że robiłeś coś niepotrzebnego, to najwyżej stracisz te kilka godzin. Oczywiście wymaga to tego, żeby klient zerknął na aktualną zmiane.
Więc tak - Agile wymaga od klienta tego żeby patrzył na częste zmiany. Jeśli jest tak jak mówisz, że zrobiłeś 10 małch featuer'ów i klient nie raczy łaskawnie na nie popatrzeć, to niestety ale przez takiego klienta Agile jest utrudniony. To że klient nie patrzy często na aktualny stan, wydłuża feedback loop. A wiec ryzyko robienia czegoś, co się może okazać nieudane rośnie. Należy wtedy powiedzieć klientowi: "Potrzebujemy, żebyś częściej patrzył na aktualny stan projektu". Jeśli to jest nieakceptowalne, należy poprosić klienta czy mógłby oddelegować osobę odpowiedzialną za to. Jeśli nie ma kogoś takiego, to po prostu akceptujeym duży feedback loop, oraz ryzyko tego że będziemy robić czasem coś, co się okaże zmarnowane.
Pamiętaj że programiści to nie są debile, też się starają wytworzyć dobry produkt, i też chcą zrobić go dobrze tak jak należy. Nikt nie ma złej woli. To co daje nam ominięcie analizy, i zamiast tego zaczęćie robienia małych kroczków - to jest szansa żeby zebrać szybki feedback od klienta. Taki feedback od klienta na podstawie nawet jednodniowej pracy jest dużo bardziej wartościowy niż miesiące analiz.
Napiszę to jeszcze raz, żeby zaznaczyć istotę zdania: Ja, osobiście, dużo bardziej wolałbym zebrać feedback od klienta, po tym jak zobaczył moją ubogą, prymitywną wersję programu po jednym dniu; niż wynik miesięcznej analizy.
Poza tym, drugiego dnia dostanę drugi feedback, trzeciego dnia trzeci - każdy kolejny będzie dużo lepszy, bo będzie na podstawie ciągle rozwijanego programu. Żadna analiza nie zastąpi takiego feedbacku.
Ogólnie to zarządzanie priorytetami kilkugodzinnych tasków przez klienta brzmi jak jakiś cholerny mikromanagement. Albo już nawet pikomanagement.
Źle się zrozumieliśmy - ja nie próbuję populować żadnego zarządzania niczym. Chodzi o zebranie feedbacku.
Klient może priorytetyzować konkrent ficzery (czyli to, czego chce klient), nie zadania (czyli to, jak programiści dzielą sobie pracę).
No oczywiście że tak! Ty decydujesz kiedy piszesz testy, Ty decydujesz kiedy refaktorujesz kod, Ty decydujesz w jaki sposób deployujesz coś na produkcje, wszystkie decyzje związane z wytwarzaniem oprogramowania podejmujesz Ty - czyli programiści.
Ale to klient decyduje który feature jest najbardziej priorytetowy teraz.
Jeśli widzisz że aktualne priorytety klienta są: feature'y X, Y, Z. I zaczynasz robić X, planując że potem zrobić Y a potem Z; i nagle po zobaczeniu X, klient zmieni priorytet na: feature'y X, Z, Y, to on nie ingeruje w Twoją pracę, nie zarządza Tobą, nie robi mikromanagmentu. Klient Ci w ten sposób daje znać co jest ważniejszym feature'em do dodania, i powinieneś go posłuchać. Oczywiście możesz go nie posłuchać, i zrobić nadal X, Y, Z (czyli zrobić najpierw zadanie które teraz wiesz żę jest mniej priorytetowe), ale to nie jest Agile.
PS: Mówiąc X, Y, Z, mam na mysli funkcjonalności.
To dla mnie jest sygnał że ten "feature" to jest duży byt, którego wykonanie trwa długo - i mówiąć wykonanie mam na mysli analizowanie, designowanie, programowanie, testowanie, etc. Tak wnioskuję na podstawie tego, że mówisz że dużo osób musi przybić pieczątkę.
No mówimy o tym, co jest ważne dla klienta. Np. zamiast wchodzić na rynek sprzedaży warzyw w Nowej Zelandii, chcemy sprzedawać dżinsy w Indiach.
Trzeba w to zamieszać sporo ludzi od biznesu, architektów, liderów zespołów od rozliczeń, walut, koszyka, logistyki, dostawy, i wielu innych.
To jest wszystko prawda. Ale w pewnym momencie Ci ludzie powiedzą: okej, zaczynamy budować jakieś oprogramowanie. I jeśli wykonanie tego oprogramowania ma zająć 3 miesiące - to nie warto tego robić "na raz". Warto zrobić najuobższą wersję jak tylko się da, najszybciej jak się da, i spytać o feedback. To jest Agile.
Jeśli chodzi o wymagania użytkowe - jak coś powinno działać, to ustala je klient/biznes, nie programiści. Klient mówi "what it does", programiści mówią "how it does it".
Chodzi mi o wymagania odnośnie ficzerów, które mam zaimplementować. Jakie dane na wejściu, co na wyjściu, co się dzieje po drodze, gdzie logujemy, gdzie utrwalamy, z czym się integrujemy i w jaki sposób, itd, itp.
Mam sobie to wymyślać w trakcie robienia zadania? Skąd będę wiedział, czy skończyłem zadanie, skoro nie wiem, co miałem zrobić?
Okej, znowu - bardzo ważne pytania i bardzo ważna kwestia. Cieszę się że do tego doszliśmy.
Kilka tematów:
- skąd wiedzieć jakie dane wejścia/wyjścia
- co się dzieje po drodze
- gdzie logujemy, gdzie persystencja
- z czym się integrujemy i w jaki sposób
- czy mam to sobie wymyślać podczas robienia zadania
- skąd będę wiedział czy skończyłem zadanie
- nie wiem co miałem zrobić.
Okej sporo pytań, postaram się odpowiedzieć na nie.
"Nie wiem co miałem zrobić" - featur który bierzesz powinien być napisany z perspektywy użytkownika, np "jako użytkownik, kiedy odpowiadam na post, chciałbym żeby ten post był automatycznie obserwowany". To jest user story - czyli opowieść usera co chciałby zrobić. W user story nie ma słowa o bazie, stronie, urlach, http, restach, etc. User story ma opisać co użytkownik chce zrobić, i jaki ma być oczekiwany rezultat.
"Czy mam sam sobie wymyślać rozwiązania podczas robienia zadania" - w gruncie rzeczy tak. Klient tylko chce, żeby po dodaniu posta, ten post był obserwowany. Ty, jako programista, musisz sprawić że tak będzie - a to czy to obserwowanie będzie zapisane w bazie, w cache'u, w kolejce, w profilu czy gdzieś, to już jest Twoja odpowiedzialność jako programisty żeby wybrać najlepsze miejsce do tego celu. Niektóre rzeczy warto trzymać w bazie, inne w cache'u - klienta to nie obchodzi - Ty masz podjąć decyzję. Klient najwyżej Ci może powiedzieć czy te dane mają być trzymane pernamentnie, czy tymczasowo - a to w jaki sposób to osiągniesz, to znowu Twoja brocha.
"skąd mam wiedzieć jakie dane wejścia/wyjścia" - tutaj trzeba rozróżnić jakie dane - czy są to dane o których klient wie (nazwa użytkownika, kategoria, grupa), czy dane o których klient nie wie (jakieś idki, timestampy, etc.). Jeśli chodzi o dane o których klient wie, te dane powinny być zawarte w user story. Jeśli dane o których klient nie wie, to to jest Twoja decyzja żeby to ustalić.
"skąd będę wiedział czy skończyłem" - jeśli wytwarzasz oprogramowanie tak jak mówiłem, czyli robisz mały feature, najlepiej na kilka godzin, to pokazujesz go klientowi, i klient mówi czego jeszcze brakuje. Jesli klient powie "jest git", to skończyłeś. Jeśli klient nie pojawia się żeby dać feedback, to skończyłeś wtedy, kiedy dzieje się to co jest opisane w user story, tzn. jeśli dodajesz post, i jest on automatycznie obserwowany, to skończyłeś.
"gdzie logujemy, gdzie persystencja" - jeśli to nie jest zawarte w user story, to to jest Twoja odpowiedzialność, i Ty masz podjąć decyzję, albo jeszcze lepiej - jeśli masz możliwośc, odrocz podjęcie tej decyzji na później. Jeśli nie masz to trudno, podejmij ją teraz.
"z czym się integrujemy i w jaki sposób" - znowu - zależy czy klient ma wiedzieć o tej integracji czy nie. Jeśli ma wiedzieć, bo np chce dodać integracje płatności ze Stripe, to klient decyduje z kim i w jaki sposób. Jeśli to jest integracja, o której klient nie wie, bo nie jest client-facing, np integracja z redisem żeby zwiększyć performance, to Ty jako programista o tym decydujesz i nie mówisz klientowi ani słowa (chyba że w jakiś sposób ta integracja byłaby klient-facing).
"co się dzieje po drodze" - jeśli mówisz o implementacji, to to jest całkowicie Twoja działka, jako programisty.
Dwa ostatnie są dosyć podobne do siebie, więc odpowiem na nie zbiorczo:
To jest niestety konieczność, bo jak bardzo byśmy nie chcieli wiedzieć "co będzie później", to niestety nie wiemy. Na tym właśnie polega cały agile - na zrozumieniu że "nie wiem co będzie potem". Wszystkie metodyki dookoła agile, są po to żeby radzić sobie z wytwarzaniem oprogramowania w świetle tego że nie wiesz jak to będzie wyglądało później. To jest całe sedno.
To ja bym prosił o linka ze źródłem tej definicji agile.
Bo zawsze słyszałem o szybkim reagowaniu na zmiany, o współpracy międzyzespołowej, szybkim feedbacku - ale o tym, że agile polega na błądzeniu we mgle słyszę pierwszy raz.
Biznes może sobie planować co tylko chce - nie ma z tym problemu. Mi chodzi o to że nie powinniśmy wytwarzać oprogramowania z myślą o tym czy coś jest zaplanowane czy nie.
Czyli nigdy nie wiemy co i po co robimy... ja bym nie dał rady, to trzeba wyższe stany świadomości osiągać, żeby w takim chaosie wytrzymać.
Oczywiście w Agile nie chodzi o błądzenie we mgle, i nie chodzi o pracowanie w chaosie.
W Agile "po prostu" chodzi o to, żeby pracować w małych krokach (bardzo małych, mniejszych niż tydzień, idealnie jeden dzień), i po każdym kroku zbierać feedback od klienta, żeby mieć lepszy wgląd w to, w jaką stronę rozwój oprogramowania ma iść. Jeśli po tym jednym dniu, zbierzemy feedback od klienta, i się okaże że on inwaliduje nasz plan, to musimy go zmienić po prostu. To jest Agile.
Nie jesteś zatrudniony w firmie żeby wytworzyć Twoją wizję aplikacji, tylko wizję klienta. Jeśli Twoja wizja i wizja klienta się różnią, to wizja klienta bierze górę. Trzeba mu to umożliwić, a umożliwić mu to się da, jeśli robi się bardzo małe kroki, i po każdym kroku daje klientowi wgląd w aktualny stan, nawet jeśli to ma być prymitywna wersja.
Nie widzę tutaj chaosu i chodzenia we mgle.
Większość ludzi jak słyszy takie podejście; "Po co mam pokazywać klientowi samą autoryzację, skoro i tak będę musiał zrobić potem X, Y, Z". Albo pomyślą "Klient mnie wyśmieje że jeszcze nie jest skończone", albo "Klient chciał całą integrację, więć nie pokazę mu nieskończonego zadania". Takie podejście jest nie-agile'owe. Musisz pokazać klientowi to co się udało zrobić, na tym polega praca w małych krokach. Musisz umożliwić klientowi zobaczenie aktualnej planszy szachowej - w tym wypadku to że sama autoryzacja zwraca true/false i nic więcej, musisz tą autoryzację wrzucić na maszynę bliską produkcji, przepuszczać małe kroki faktycznym procesem zanim poświęcisz 3 miesiące na jego development.
Bo klienta nie obchodzi jakieś false wyświetlone w Postmanie. Klient chce API, w którym konfiguruje sobie szablony wiadomości email, oraz workera, który czyta z kafki i na podstawie eventu wysyła zgodny z odpowiednim szablonem email do klienta.
Klient na podstawie jakiegoś false nie podejmie decyzji czy ten pomysł ma sens, będzie o tym wiedział dopiero, gdy zobaczy maile w skrzynce.
Jeśli ja miałbym klienta, który chce żebym mu zbudował API, w którym można skonfigurować szablony maili, oraz skonfigurować jakiś proces który wysyła maile z kafki na podstawie tych szablonów, to podszedłbym do tego tak:
- Pogadałbym z klientem przez godzinę lub dwie, po co on to API potrzebuje, spytałbym jaki problem próbuje rozwiązać. Spytałbym go jakie ma wymagania odnośnie tego API, jakiego ruchu się spodziewa (możliwe że nie wie), jak bardzo bezpieczne ma być, czy ma działać z kafką czy innymi message brokerami, czy będzie schowane za API, czy ma jakieś inne techniczne uwagi.
- Jeśli wszystko ustalone, to zaproponowałbym wykonanie pierwszego, najdrobniejszego taska jaki się da. Musi to być bardzo mała rzecz, taką którą da się zrobić w jeden dzień, i jednak robi coś. Rzuciłem wcześniej że autoryzacja, bo ja od tego bym zaczął ale to może być cokolwiek.
- Dla przykładu - wiem że API ma puszczać eventy z kafki jako maile.
- Jak ja od tego bym zaczął? Napisałbym API, które wysyła maila tak po prostu, bez żadnego eventu, do klienta. Wpisałbym tam jakąś tymczasową treść, nawet bez żadnego formatowania
- To było szybkie, dzień się jeszcze nie skończył więc jadę dalej,
- Tworzę testową kafkę, na którą wrzucam jeden event, i piszę kod który łapie ten event i wysyła maila. Zależnie od skomplikowania systemu to może ale nie musi zająć całego dnia.
- Oczywiście piszę testy na wszystko
- Jeśli skończyłem, to proszę klienta o adres mailowy (prawdziwy albo testowy, zależy jak woli), i wysyłam mu maila z mojego programu.
- Pytam klienta czy taki mail jest okej - tutaj niespodzianka - pytam go czy jest okej, mimo że wiem że nie jest.
- Klient teraz mi opowiada o tym co jest nie tak:
- Nie ma szalbonów - to wiem, potwierdza się moje przekonanie
- Klient mówi że to powinno iśc do kilku maili - o, tego nie wiedziałem - zapisuję sobie
- Klient mówi że w mailu powinny być kolorki i obrazki - to się ma do szablonów, wiec tego też się spodziewałem
- Oczywiście mogłoby być tak, że ja pokażę maila klientowi i klient powie "jest spoko", albo powie tylko to co już wiedziałem - wtedy wiem że dobrze wykminiłem wszystko z pierwszego spotkania.
- Programuję od razu dalej:
- Piszę kod który przechwytuje jeden z kilku eventów, powiedzmy
create order, delete order, pay order, oraz dodaję prosty markup do emaila, nie jakiś skomplikowany
- Teraz wrzucam na testową kafkę te trzy eventy, i wysyłam maila z programu do klienta.
- To samo co wcześniej, klient patrzy na maila, i mówi że część rzeczy nadal nie działa, że część jest okej.
- Znowu robię to samo - pytam go czy wszystko jest okej, mimo że wiem że prawie wszystkiego brakuje:
- Klient mówi że nadal nie ma szablonów - to wiem
- Klient mówi że chce tylko
create order i delete order, że pay order nie chce. To mnie dziwi - zaczynam z nim rozmawiać, jak chciałby to rozróżnić, rozmawiamy o potencjalnym rozwiązaniu
- Ponieważ klient już któryś raz mówi o szablonach, to dla mnie znak że te szablony są ważne, więc to jest sygnał dla mnie że tym się powinienem zacząć dalej
- Teraz siadam do zrobienia szablonu. Na razie robię żeby nie był konfigurowalny, bo chcę szybko skończyć robienie go. Dodaję kolorki, listy, i obrazki w HTML. Znowu wrzucam fake event na kafkę, i wysyłam maila do klienta.
- Klient patrzy na maila na telefonie, i widzi że się rozjeżdżają - to dla mnie sygnał że szablony mają wspierać telefony też - tego się spodziewałem
- Klient patrzy na szablon i mówi że mu się podoba - to jest potwierdzenie dla mnie, że dobrze zgadłem co klient chce
- Ale klient mówi że nie chce obrazków w szablonie - to jest dla mnie pomocna informacja, bo nie będę musiał ich serwować.
- Klient mówi że chciałby skonfigurować maile.
- Słucham wszystkiego co mówi klient, i tworzę kolejną wersję. Tym razem wysyłam inny rodzaj szablonu dla
create order, inny dla delete order. Wrzucam te dwa eventy na kafkę, i program już sam wysyła dwa maile do klienta z nimi.
I tak w kółko.
To jest Agile. Nie ma tutaj miejsca na pracę we mgle, nie ma miejsca na chos. To co robię to:
- Spróbuj zgadnąć co klient chce, zbierz informacje, wyciągnij od niego wszystko co możesz - ale miej na uwadze, że klient, tak samo jak Ty - nie wie czego chce.
- Zrób najmniejszą, najprostszą wersję oprogramowania, która dla klientowi cokolwiek na co może popatrzeć i go użyć.
- Zbierz ponownie informacje od niego
- Powtórz 2. - 3. dopóki klient nie powie "okej, jest git".
Analizy powinny być, ale tylko i wyłącznie w momencie rozpoczęcia zadania - nie przed. Dokładniej mówiąc, w momencie w którym wykonanie tego 3rd party będzie najbardziej priorytetowym zadaniem, wtedy siadasz i to robisz, i wtedy, jeśli potrzeba rozpoczynasz analizę tego - chyba że ten task straci priorytet, wtedy musisz przestać i wziąć coś bardziej priorytetowego.
Świetnie, tylko klient chce wiedzieć ile czasu zajmie wytworzenie API, którego jedna z funkcji wymaga integracji z tym zewnętrznym API. Na jakiej zasadzie mam udzielić odpowiedzi, skoro nie znam tego zewnętrznego API?
Ale nie znasz tego zewnętrznego API, więc nie wiesz ile może zająć wytworzenie go.
Najszczerszy estimate jaki możesz powiedzieć klientowi to "nie wiem" - bo nie wiesz. Nie korzystałeś nigdy z niego, skąd masz wiedzieć ile to zajmie.
Są na to dwa wyjścia:
- Albo zrobić "analizę" żeby spróbować wydedukować ile czasu może zająć zaprogramowanie czegoś
- Albo po prostu zacząć robić to zadanie, i dostarczyć absolutne minimum. Teraz masz przynajmniej jeden krok. Można jechać dalej. To po prostu działa.
Klient chce wiedzieć ile czasu potrzeba na zbudowanie tej integracji, żeby wiedzieć czy opłaca mu się wydawać kase na pracę programistów, i musi wiedzieć czy coś będzie gotowe czy nie. Ale to samo możesz załatwić dostarczając absolutne minimum, żeby klient faktycznie zobaczył jak to działa. Klient nie chce daty, nie chce planów - klient chce wiedzieć, czy uda mu się dostarczyć to co on chce. I to samo można załatwić jednym albo dwoma krokami Agile, czy jak to nazwałeś "ogarnianiem w boju". Tylko że nie przez trzy miesiące, tylko w kilka dni. I tak - w kilka dni nie da się tego zrobić - ale nie musisz dostarczać całego rozwiązania, żeby klient zobaczył czy opłaca mu się w to wchodzić czy nie.
Zakończenie
Na koniec dodam jeszcze taką rzeczy: Taki sposób programowania nie jest łatwy do wprowadzenia. Wymaga zmiany przyzwyczajeń, zmiany sposobu w jaki działamy.
Robi też bardzo trudną rzecz dla niektórych, mianowicie zmusza nas do kontaktu z ludźmi. Jak dostaniesz task na 3 miesiące, to możesz się zakopować w pokoju z colą i słuchawkami, i po prostu kodzić przez 3 miesiące jakieś API. Sporo programistów lubi tak pracować. Tylko że po pierwsze to nie jest agile, a po drugie to przynosi gorsze rezultaty. Lepsze rezultaty przynosi stały kontakt z ludźmi. Programiści, wbrew pozorom nie lubią kontaktów z ludźmi, lubią sobie programować.
Tylko że siedzenie samemu w domu przez 3 miesiace z chipsami i colą, jest dobre i fajne jak piszesz coś dla siebie - jak jesteś jednoczesnie autorem i swoim klientem, że masz perfekcyjną wiedzę nt tego jak ten program ma wyglądać.
Ale jak pracuejsz dla kogoś innego, kogoś czyja wizja może być inna niż Twoja, to najlepszym sposobem na wytworzenie dobrego oprogramowania są częste interakcje z innymi ludźmi, z klientami, oraz częste możliwości zmiany planów. Programiści tego nie lubią - co wyjaśnia czemu w wielu firmach niestety nie ma Agile prawdziwego.
Finalne zakończenie
Jak czytam Twoje posty @somekind, to mi to wygląda jakbyś nie potrzebował predictibility. Ty potrzebujesz feedbacku od klienta - czyli dokładnie tego, co Agile się stara załatwić.
