Czy terminy są zwinne?

Dla jasności terminem jest:

Termin lub termin to wąskie pole czasu lub konkretny moment, w którym cel lub zadanie musi zostać zrealizowane.

^{Z wikipedii}

Przez całą moją karierę programistyczną robiłem „Agile”, co wszędzie wydawało się, że stosowano przynajmniej następujące praktyki:

• Cotygodniowe lub dwutygodniowe sprinty
• Retrospektywy Planowanie sprintu
• Właściciel produktu
• Scrum
• Historie użytkownika

Jednak każdy projekt, w którym kiedykolwiek byłem, nalegał na wyznaczenie terminu. Biorąc pod uwagę, że Agile próbuje skoncentrować się na planowaniu adaptacyjnym, elastyczności i zmianach; terminy są zwinne?

Uważam, że tak nie jest, ponieważ widzę terminy prowadzące do braku elastyczności i jakości. Zamiast tego uważam, że większa wartość pozwala skupić się na sprintach i wczesnych dostawach. Wydaje się jednak, że w każdym kręgu, w którym byłem, tak nie jest, a terminy są dostosowane do rozwoju Agile.

Terminy są rzeczywistością. Najczęściej musisz mieć coś do określonej daty. To nieuniknione. Bez terminów nawet zwinne projekty mogą ulec prawu Parkinsona :

Praca rozszerza się, aby wypełnić czas dostępny na jej zakończenie.

Innymi słowy, jeśli twój projekt będzie mógł trwać wiecznie, tak będzie.

W odniesieniu do terminów Agile próbuje zrobić kilka rzeczy:

• Upewnij się, że każdy zawsze może zobaczyć, ile pracy wykona w wyznaczonym terminie
• Najpierw upewnij się, że najważniejsze funkcje zostały zakończone
• Upewnij się, że ukończone funkcje są użyteczne w tym sensie, że nie zależą od funkcji, które nie zostały jeszcze ukończone
• Upewnij się, że rozwój będzie kontynuowany w zrównoważonym tempie

W ten sposób, gdy nadejdzie nieunikniony dzień, nie masz zbędnego stosu kodu, ale działający, przetestowany produkt z, miejmy nadzieję, tylko najmniej istotnymi niedokończonymi rzeczami. I nikt nie jest zaskoczony gotowym produktem.

Więc tak. „Zwinne” i „terminy” mogą być doskonale kompatybilne.

Terminy są faktem. Są rzeczy, które mają bardzo mocną datę.

Potrzebujemy oprogramowania Comdex

lub

Gry muszą być na półkach sklepowych do Czarnego Piątku

i tym podobne. Nie można odłożyć Comdexu ani Czarnego piątku - reszta świata nie działa w ten sposób.

Celem Agile jest to, aby rzeczy, które nie dotrzymają terminu, zawiodły szybciej (i to jest dobra rzecz), lub zakres może zostać ponownie zbadany wcześniej, aby zasoby mogły być skoncentrowane na poprawnym ROI w bardziej terminowy sposób.

Termin jest trudną datą, która jest ściśle określona. Zwinne to narzędzie, które pozwala uświadomić sobie wcześniej w cyklu, że opracowanie oprogramowania zajmie dwa razy więcej czasu, niż pierwotnie oczekiwano. Ważne jest, aby kierownicy projektów byli w stanie zdać sobie sprawę z tych problemów wcześniej niż później, aby można było dodać więcej zasobów, zmienić zakres, skorygować termin (w sytuacji, gdy jest to firma, a nie solidny termin) lub projekt anulowany.

Przejrzystość, której poszukuje Agile, polega na pokazywaniu problemów i postępów na wcześniejszym etapie cyklu. Klasyczna nieudana dostawa wodospadu to jedna z sytuacji, w której spędziłeś miesiące za zamkniętymi drzwiami i dostarczyłeś produkt na tydzień przed terminem, a powiedziano ci, że robisz wszystko źle i zmarnowałeś miesiące (a teraz całkowicie skróciłeś termin) . Inną klasyczną porażką wodospadu jest ustalenie na tydzień przed upływem terminu, który upłynął jeszcze miesiącami. Agile stara się ujawnić te problemy na wczesnym etapie procesu.

Inną częścią, którą Agile chce zrobić w kontekście terminu, jest to, że nawet jeśli tylko część uzgodnionych funkcji jest kompletna (z jakiegokolwiek powodu), obecna wersja oprogramowania jest użyteczna i możliwa do wdrożenia.

Ok, brakowało nam wszystkiego, co chcemy, aby oprogramowanie podatkowe zostało wdrożone 15 kwietnia, ale mamy 75%, a to, co robimy, działa i działa od początku naszej działalności w listopadzie ubiegłego roku. Wiemy, że nie będziemy w stanie wdrożyć pełnego zestawu funkcji od połowy grudnia i ponownie skoncentrowaliśmy nasze wysiłki na 80% bazy klientów.

Niektóre terminy muszą być dotrzymane. Zobowiązania umowne, konwencje, wymogi regulacyjne. Niektóre są narzucane przez menedżerów, którzy chcą umieć programowanie na tym samym wykresie, co produkcja w swoim arkuszu kalkulacyjnym. Bez względu na przyczynę większość ludzi nie może od nich uciec.

Jeśli pracujesz w funkcjonującym zespole, to komunikacja między programistami a kierownictwem / interesariuszami oznacza, że ​​ludzie, którzy muszą podjąć decyzję, są dobrze poinformowani, aby zdecydować, czy przekroczenie terminu lub kontynuacja rozwoju jest ważniejsza.

Nawet jeśli dostarczasz gotowe historie użytkowników raz w tygodniu lub dwa razy w miesiącu, prawdopodobnie nadal masz terminy. Kiedy ktoś się zbliża, upewnij się, że twoi interesariusze wiedzą, co według ciebie pasuje do terminu i ustalają oczekiwania.

Jeśli nieustannie budujesz najlepsze oprogramowanie, które spełniasz wymagania na każdym etapie, termin pod koniec każdego sprintu teoretycznie nie powinien stanowić problemu. Praktycznie nie jest to normalne, ale nie są to również terminy, które pojawiają się z braku powietrza. Najważniejsze terminy, które kiedykolwiek mi podano, zostały mi przekazane na długo przedtem, to właśnie oczekiwanie jakości i cech było problemem.

Arbitralne terminy, które nie pociągają za sobą konsekwencji, jeśli nie zostaną dotrzymane, nie są zbyt elastyczne, ale zdarzają się sytuacje, w których z przyczyn niezależnych od zespołu programistycznego należy ustalić i dotrzymać terminów. Na szczęście, jeśli terminy są rozsądne, istnieje wiele sposobów na odwrócenie równania i sprawne zarządzanie terminami.

Terminy nie zawsze są złe. Jak wszyscy dowiedzieliśmy się od Obi-Wana:

„Tylko Sithowie w absolutach”

Można śmiało powiedzieć, że w większości przypadków terminy są głupie, niepotrzebne, a na pewno nie zwinne, ale głupcem byłoby powiedzieć, że tak jest zawsze. Sprawa architypal jest oprogramowaniem potrzebnym do wykorzystania w czasie, takim jak oprogramowanie do śledzenia wyborów. Jeśli oprogramowanie nie jest gotowe na czas na wybory, odroczenie wyborów nie byłoby rozsądne ani praktyczne, i wydaje się, że nie jest zbytnio zorientowany na klienta, aby po prostu powiedzieć „Przepraszam, wygląda na to, że zajęliśmy zbyt dużo czasu. Wiem, że to oprogramowanie, za które płacisz, jest całkowicie bezwartościowe, ale terminy nie są zwinne, więc jak możesz naprawdę zarzucić nam, że ich nie dotrzymaliśmy?

Nie jest zbyt zwinne, aby mówić swoim klientom, aby wepchnęli to, ponieważ chcą czegoś, co jest wrażliwe na czas, a pod koniec dnia ktoś będzie musiał zbudować te rzeczy. Jak więc nadal sprawiać radość klientom i nadal dostarczać pozornie rozsądne rozwiązania dla rzeczy wrażliwych na czas? Cóż, jeśli tworzenie oprogramowania zajmuje niepewny czas, a termin nie jest zmienny, coś innego będzie musiało być zmienne, aby poradzić sobie z tą niepewnością ...

Jeśli data dostawy jest utrzymywana na stałym poziomie, jakiś inny aspekt staje się zmienny.Jak wszyscy wiemy, w projektach oprogramowania może występować duża niepewność. Coś musi zostać zmienione w odpowiedzi na tę niepewność, jeśli chcesz osiągnąć sukces w swoim projekcie, a zazwyczaj jest to data dostawy. W każdym razie wydaje się to dość naturalne. Ale to nie jest twoja jedyna opcja. Jeśli utkniesz w trudnym terminie, rozwiązaniem tego jest zmiana dostarczanych funkcji. Określ priorytet funkcji na liście, wyraźnie komunikuj, że istnieje niepewność co do liczby funkcji, które mogą być dostarczone do tej daty. Współpracuj z klientem, aby nadać priorytet tym funkcjom, tak aby najważniejsze z nich miały większe prawdopodobieństwo wysyłki. Następnie jest to normalne, tylko gdy termin upłynie wokół twojego statku, co jest gotowe do wysyłki. W tym modelu

Jeśli ktoś chce ustalić termin, to jest w porządku, a termin można ustalić, ale musi zrozumieć, że jeśli termin jest ustalony, zakres musi pozostać elastyczny.

tl; dr

W idealnym świecie nie mielibyśmy terminów i dostarczalibyśmy rzeczy, gdy są gotowe. W rzeczywistości ludzie płacący za rzeczy zwykle chcą wiedzieć, kiedy są skończeni. Metodologie zwinne rozpoznają to, ale także rozpoznają, że nie wszystko można związać.

Zapewnia to utrzymanie jakości dostawy na poziomie odpowiednim dla produktu. Jeśli ustalisz termin i zakres (i budżet), wszystko się pospieszy i wrócisz do starego świata wodospadów z szalonym czasem załamania pod koniec projektu. Zwiększenie budżetu zwykle nie jest odpowiedzią, ponieważ dodanie większej liczby programistów i testerów nie rozwiązuje problemu szybciej. Jest to dobrze znany pogląd (i zgadzam się z nim z doświadczenia), że im więcej osób dodasz (każda z własną słabością), tym więcej czasu to zajmie.

Teraz, zazwyczaj (chyba że naprawdę rozumieją metody Agile) osoba płacąca za oprogramowanie nie lubi, gdy otrzymujemy informację, możemy dotrzymać terminu, ale nie możemy zrobić wszystkiego, co chcesz. Można temu zaradzić, ustalając priorytety funkcji tworzących oprogramowanie. Twoja dyskusja nad ustalaniem priorytetów może wyglądać następująco:

Zespół deweloperów (D): „Czy możesz ustawić priorytety funkcji, które chcesz dostarczyć, z najważniejszymi na początku?”

Klient (C): „Wszystko ma priorytet 1 - chcę, aby wszystkie zostały wykonane do końca przyszłego miesiąca”.

D : „Może to być możliwe, ale może nie być możliwe, jeśli zmienią się wymagania lub odkryjemy problemy, których nie oczekiwaliśmy podczas opracowywania”.

C: „A co, jeśli dam ci więcej pieniędzy?”

D: „ westchnij … nawet przy większej ilości zasobów zajmie im to miesiąc, aby naprawdę zacząć; więc jeśli nie jesteś pewien, jak ustalić priorytety funkcji, po prostu powiedz nam, które z nich chcesz zrobić jako pierwsze”.

C: „Ok, chcę duży przycisk, ale uczyń go naprawdę dużym, a potem ... itd.”

Teraz możesz rozpocząć pracę z funkcjami w kolejności priorytetowej. Pomaga to również patrzeć z wyprzedzeniem w stronę zespołu na przedmioty znajdujące się niżej w kolejności priorytetów i dokonać pewnych wczesnych szacunków, wiedząc, że możesz je zmienić, gdy dojdziesz do rozwoju, gdy będziesz mieć więcej informacji. Można go użyć do przedefiniowania lub stworzenia mapy drogowej, jeśli jeszcze jej nie masz. To następnie stanowi podstawę twojego planu wydania. Mapę drogową można omówić z klientem, potwierdzając, że zakres może ulec zmianie, ale istnieje kolejność dostarczania rzeczy.

Jedną z wielkich zalet Agile jest to, że zdaje sobie sprawę, że rzeczy zmieniają się wraz z rozwojem i dostosowujesz się wraz z nimi. W przeciwieństwie do bardziej tradycyjnych podejść, ta zasada, w połączeniu z regularnymi wynikami sprintu i ciągłą komunikacją z klientem, oznacza, że ​​naturalnie musisz być bardziej przejrzysty w kwestii postępów, co jest dobrą rzeczą.

Czasami klientowi nie podoba się to, że nie otrzyma tego, czego chce do określonej daty, ALE zrozumie, dlaczego i co dostanie, będzie dobrej jakości. A 6 miesięcy po dostarczeniu funkcji klient nie będzie dbał ani nie zapamięta, że ​​dostarczyłeś go w określonym terminie, zapamięta jakość produktu, którego nadal używa.

Terminy są tradycyjnie oparte na cyklu życia firmy. Oprogramowanie podatkowe musi zostać wprowadzone do 15 kwietnia. Raportowanie na następny rok obrotowy może wymagać sporządzenia do lipca.

W Agile Manifesto stany:

Osoby i interakcje dotyczące procesów i narzędzi

Działające oprogramowanie w stosunku do kompleksowej dokumentacji

Współpraca z klientem przy negocjowaniu umowy

Reagowanie na zmianę Zgodnie z planem

Terminy są umową. Oni są planem. Nie reagują na prędkość twojego zespołu. Nie zmieniają się, jeśli stracisz trzech najlepszych programistów.

Terminy nie są zwinne, ale zwinny może przekazać nam informacje zwrotne na temat terminów. Zwinny, daj nam znać, jeśli nasza prędkość nie pozwoli nam ustalić terminu bez odcięcia funkcji. Daje nam również znać, jeśli musimy zatrudnić, aby dotrzymać terminu. W niektórych przypadkach informuje nas, że termin jest niemożliwy, gdy nie ma już żadnych elementów do wycięcia.

Najlepszą rzeczą, jaką może zrobić zespół Agile, jest to, by prędkość i zaległe priorytety wyznaczały termin. Podane zostaną przybliżone daty dostawy. Jeśli te przekroczą termin, to czas na poważną rozmowę z klientem i ustal, czy termin jest w ogóle wykonalny.

Powiedziałbym, że dostawa każdego sprintu nie podlega negocjacji. Oceniasz pracę, nakładasz na nią rozmiary kart i ładujesz wystarczająco dużo, aby utrzymać swój zespół zajęty do końca sprintu (a sprint powinien być mały - od tygodnia do miesiąca). „Terminy dostaw” powinny opierać się na historycznym trendzie ukończonych prac w stosunku do prac przewidywanych. Zwinne nic nie dodaje / nie usuwa ze starej koncepcji ograniczenia „koszt / czas / zakres”, po prostu wykorzystuje zakres jako preferowaną metodę zarządzania poślizgiem na podstawie tego, że lepsze ustalanie priorytetów względem zakresu jest generalnie lepsze niż wydawanie większej ilości pieniędzy lub czasu.

Niektórzy ludzie zdają się mylić zwinność z „dzikim zachodem”. Zwinne nic nie znaczy. Zwinność oznacza, że ​​przestajemy okłamywać siebie, jak dobrze rozsądna osoba może to oszacować. Zasadniczo możemy oszacować rozwój oprogramowania za około 2–4 tygodnie w przyszłości. Poza tym wszystko różni się w swagach i domysłach. Co gorsza, koszt dostarczenia szacunków dotyczących rzeczy w przyszłości i zbliża się do kosztu samej pracy. Z jakiegokolwiek powodu kierownicy projektów historycznie nie chcieli przyznać klientom tych absolutnych prawd. Agile po prostu dostosowuje to myślenie, stwierdzając, że istnieje granica tego, jak dobrze możemy przewidzieć przyszłość w inżynierii oprogramowania, i subtelnie zmienia „szacowanie oparte na dowodach” w celu prognozowania długoterminowego.jesteśmy w stanie oszacować, a my możemy przedstawić dość rozsądne szacunki długoterminowej przyszłej dostawy na podstawie tego, co dostarczaliśmy do tej pory.

TL; DR

Czy terminy [a] gile? ... [D] eadlines są postrzegane jako idące w parze z rozwojem [a] gile.

Wiele odpowiedzi tutaj prawdopodobnie skupia się na technicznych aspektach pytania. Zamiast tego zajmę się tym z punktu widzenia zarządzania projektami.

Termin oznacza dużo planowania z góry, co jest niezgodne z zasadami zwinności. Zamiast tego iteracyjne modele programistyczne opierają się na przedziałach czasowych, rytmie i cyklach wydawniczych, które obejmują planowanie dokładnie na czas, ale nie „duże, wstępne planowanie”, które generalnie wiąże się z tradycyjnymi terminami zarządzania projektami.

Nadal możliwe jest planowanie wydań przy użyciu zwinnych metodologii, ale plany są zasadniczo oparte na szacunkowej liczbie iteracji wymaganych do osiągnięcia celu, a nie na celach zarządzania określonych przez fiat. Nie oznacza to, że nie można ustalić dat wysyłki ani że nie można osiągnąć celów, ale sposób , w jaki są one definiowane i osiągane, jest zupełnie inny niż w tradycyjnych metodach zarządzania projektami.

Pomyśl o terminach, a nie o terminach

Jednak każdy projekt, w którym kiedykolwiek byłem, nalegał na wyznaczenie terminu. Biorąc pod uwagę, że Agile próbuje skoncentrować się na planowaniu adaptacyjnym, elastyczności i zmianach; terminy są zwinne?

Jest to powszechne nieporozumienie dotyczące zwinnych zasad. Zwinne frameworki, takie jak Scrum i Kanban, nie koncentrują się na terminach, ale raczej na boksowaniu czasu i zrównoważonej kadencji dostaw.

Na przykład w Scrumie Sprint nie jest „terminem”. Jest to przedział czasowy, który jest wypełniony ilością pracy, którą szacuje zespół zmieści się w tym przedziale czasowym bez przepełnienia go, a następnie jest „wykonywany” lub „nie wykonywany” po upływie tego przedziału czasowego. Po zniknięciu przedział czasowy przepadł na zawsze; wszelkie prace, które nie zostaną wykonane, muszą zostać ponownie zaplanowane i ponownie oszacowane w nowym, równie efemerycznym przedziale czasowym, w oparciu o aktualne (raczej niż historyczne) potrzeby projektu.

Ważność tego przedziału czasowego polega na tym, że zapewnia on zarówno zainteresowanym stronom przewidywalną kadencję do przeglądu postępów, jak i zrównoważone tempo dla zespołu, w którym możliwe jest dostarczenie potencjalnie możliwych do zwiększenia przyrostów wartości . Praca ma charakter przyrostowy i podąża za kadencją; koncepcja dużego, z góry ustalonego terminu nie jest zatem zgodna z zasadami zwinności.

Planowanie wydania na podstawie przedziałów czasowych

Być może jedynym obszarem, w którym ludzie mają największe trudności z mapowaniem sprawnych procesów do tradycyjnych ram, jest planowanie wersji. Planowanie wersji często obejmuje produkty o ustalonym zakresie lub o ustalonej dacie. W zwinnych ramach planowanie wydania zwykle odbywa się poprzez proces szacowania, w którym zakres jest jawnie zdefiniowany jako zmienna zmienna, a daty wydania są szacowane w iteracjach.

Na przykład projekt może być zaangażowany w wydanie wersji 1.0 projektu pod koniec 20 iteracji; zakres tego, co jest wydawane, może się zmieniać w trakcie trwania projektu (ponieważ zakres, funkcje i priorytety mogą się zmieniać na początku każdego Sprintu), ale daty docelowe każdego wydania są ustalone w planie projektu. Zespół dąży do zapewnienia potencjalnie możliwego do wysyłki przyrostu każdego Sprintu, a Definicja Wykonania obejmuje kontrole jakości, takie jak ciągła integracja, aby upewnić się, że projekt jest w stanie możliwym do zwolnienia na końcu każdego Sprintu.

Czasami zobaczysz zwinne projekty, w których zakres jest stały, ale ponieważ zakres jest zmienną zmienną w zwinnych projektach, data wydania może się zmieniać w czasie, gdy zakres każdej iteracji dostosowuje się, zmienia lub dostosowuje do zmieniających się potrzeb projektu . Z pewnością nie polecam podejścia o zwartym zasięgu zespołom zwinnym, zwłaszcza niedoświadczonym, ale są chwile, kiedy jest to właściwe podejście.

Zobacz też

• Jak wykonać zwinne planowanie wydania

Traktuj terminy jako zobowiązanie. Fakt, że projekt jest sprawny, nie oznacza, że ​​nie powinieneś zobowiązać się do dostarczania określonych funkcji na określony dzień.

Zwinność przynosi to, co dzieje się pomiędzy. Zamiast mieć dokument specyfikacji ścisłych wymagań dotyczących oprogramowania, który określa, że ​​należy dostarczyć cechę A złożoną z funkcji podrzędnych B, C, D i E na dany dzień, zobowiązujesz się do dostarczenia funkcji A na określony dzień, biorąc pod uwagę, że na na wczesnym etapie, ani ty, ani twój klient nie wiecie, jak będzie wyglądać ta funkcja, ani nie mieliby podfunkcji B, C, D i E, a może B i C lub kilkunastu innych podfunkcji.

Wyobraź sobie firmę, która wcześniej dostarczała towary tylko małym firmom i właśnie podpisała umowę z dużą korporacją. Ta duża korporacja korzysta z EDIFACT i wydaje się, że obecne oprogramowanie księgowe używane przez twoją firmę nie obsługuje EDIFACT. Jesteś o stworzenie wtyczki, która robi to, biorąc pod uwagę, że w umowie, firma powinna być gotowa do 15 kwietnia ^TH .

Zwinność oznaczałaby, że kroki pośrednie będą realizowane stopniowo i będą oparte na regularnych informacjach zwrotnych. Zasadniczo pokażesz swoje postępy księgowym, a oni powiedzą ci, co myślą na ten temat, jakie są możliwe problemy itp. Oznacza to również, że być może pierwotnie księgowi mieli świetny pomysł, który według nich mógłby poprawić zasadniczo doświadczenie użytkownika. Trzy tygodnie później okazało się, że nie tylko nie poprawia go to tak bardzo, ale spowoduje również dodatkowy miesiąc rozwoju. Dzięki Agile możesz przekierować swoje wysiłki z tej funkcji na coś innego, upewniając się, że dotrzymasz terminów.

Należy również zrozumieć punkt widzenia klienta:

• Często firmy potrzebują określonej daty dostawy. Na przykład nie można świadczyć usługi przesyłania strumieniowego gier olimpijskich online po zakończeniu igrzysk olimpijskich. Z biznesowego punktu widzenia jest to po prostu porażka z ogromnymi negatywnymi konsekwencjami.

• Bez zaangażowania kuszące jest, aby deweloper lub podwykonawca był perfekcjonistą lub sprawił, że projekt miał niski priorytet. Chociaż regularność sprintu pomaga, nie całkowicie zapobiega temu ryzyku.

  Nie przepadam za terminami, zwłaszcza że terminy są bardzo łatwe, ale nadal rozumiem, dlaczego wiele firm to robi. Nie zawsze łatwo jest zauważyć, że projekt jest opóźniony, patrząc tylko na sprinty: w tym kontekście spóźniony termin może być wyraźnym przypomnieniem, że coś wymyka się spod kontroli i należy się nim zająć właśnie teraz.

Program eXtreme Programming mówi o planowaniu wydań:

Podstawową filozofią planowania wydania jest to, że projekt można skwantyfikować za pomocą czterech zmiennych: zakresu, zasobów, czasu i jakości.

Co wydaje się sprawiedliwe. Stwierdza to również

Nikt nie może kontrolować wszystkich 4 zmiennych. Kiedy zmieniasz jedną, nieumyślnie powoduje to zmianę drugiej w odpowiedzi. Należy zauważyć, że obniżenie jakości do mniej niż doskonałej ma nieprzewidziany wpływ na pozostałe 3 zmienne

Jak już zauważył br3w5 , zwiększenie zasobów jest rozwiązaniem ograniczonym. Prawdopodobnie możesz dodać kilka osób, które były już częścią zespołu, jeśli zostały wysłane na coś innego. Nie można jednak po prostu szybko i bez końca zwiększać liczebności zespołu, przynajmniej nie bez reorganizacji zespołu, która zajmuje wiele razy.

Zatem przy nieredukowalnej jakości i stałych zasobach: termin jest ograniczeniem czasowym, oznacza to, że musisz dostosować zakres. A dzięki zwinności możesz dotrzymać terminu w najbardziej produktywnym zakresie. Zazwyczaj jednak można zagwarantować, że pewna część zakresu zostanie wykonana na czas. Jest to część, którą możesz z szacunkiem oszacować, aby upłynął jej termin. Zazwyczaj jest to coś, co jest naprawdę bliskie temu, co zrobiłeś kilka razy i ma mało nieznane.

Poprawne zrozumienie metod tworzenia oprogramowania ma na celu zwiększenie produktywności poprzez skupienie myśli i zapewnienie wspólnego języka w typowych sytuacjach. Chodzi o inspirację i umożliwienie, a nie kontrolę umysłu i poczucie winy.

Postępowanie zgodnie z metodą tworzenia oprogramowania dosłownie bez żadnych kompromisów odpowiada tak zwanemu radykalizmowi lub fundamentalizmowi w innych kontekstach. Czysta forma tej aberracji jest rzadko spotykana w praktyce, ponieważ zazwyczaj prowadzi do szybkiej awarii na rynku. Ale oczywiście, gdy programiści rywalizują w trudnym zadaniu implementacji określonej metody, przekroczenie znaku jest zjawiskiem naturalnym.

Problem pogłębia fakt, że misjonarze i ewangeliści kierują swoją ofertę przede wszystkim do tych, którzy nadal potrzebują przekonania do korzystania z tej metody; i nawet jeśli głoszą umiarkowanie, natura ludzka zapewnia, że ​​przyciąga ona mniej uwagi.

Terminy nie są elastyczne, są to:

1) Wodospad i 2) Źle.

Oprogramowanie i terminy nie działają dobrze razem i nigdy ich nie ma. Pod wieloma względami metodyki zwinne są reakcją na ogromny problem przekroczenia terminów lub oprogramowania, które zostały porzucone, gdy stało się jasne, że termin nie może być dotrzymany (a także kwestie budżetowe).

Zwinne próby wprowadzenia rzeczywistości w sytuację, mówiąc: „Wiesz, że termin lub funkcje będą się ślizgać i / lub zmieniać, wiemy o tym, więc chodźmy na właściwej stopie i nawet nie udawajmy”.

Kluczem jest to, że termin staje się po prostu datą premiery pierwszej wersji oprogramowania. To może być nadal napisane w kamieniu - powiedzmy, oprogramowanie jest do użytku akademickiego i MUSI być użyteczne na początku semestru - ale to, co dostarczysz, nie jest. Masz minimalny opłacalny produkt, który wszyscy są pewni, że do tego czasu zostanie dostarczony, i masz mnóstwo „chciałbym mieć”. Zamiast wszystkich podrzucających ręce, gdy okaże się, że cała lista nie zostanie dostarczona przed „terminem”, upewnij się, że dostaniesz MVP za drzwi i tyle osób „chciałoby mieć” możliwe, a następnie oceń koszt / korzyść pozostałej części w tym momencie.

Każdy, kto grał w gry komputerowe przez długi czas, dokładnie wie, jak to działa! Jeśli pierwsza wersja jest zgodna ze standardami beta, wielu graczy jest zadowolonych, tak niskie są oczekiwania co do tego, co oznaczają „twarde, prawdziwe terminy” w prawdziwym życiu.

Tak więc terminy nie są elastyczne, są one reliktami z czasów, kiedy ludzie myśleli, że oprogramowanie można traktować jak inżynierię sprzętu i stali. Dowiedzieliśmy się, że nie jest to ani możliwe, ani pożądane, ponieważ odrzuca największą przewagę oprogramowania nad sprzętem: jest miękkie.

Agile próbuje wykorzystać tę miękkość, umożliwiając rozwój i zmianę celów w trakcie projektu w sposób, w jaki projekt mostu nigdy nie byłby w stanie.

Odpowiedz „prawdopodobnie nie”

Project_management_triangle stwierdza, że koszt, czas i zakres (a także jakość) są od siebie zależne. („wybierz dwa i zdobądź trzeci”)

Sprint scrum wybiera ustalony czas (tj. 7 dni = długość sprintu) i koszt (tj. Budżet dla 7 członków zespołu) i szacuje zakres (liczbę historii, które należy wykonać w sprincie)

Jeśli kierownictwo lub dział sprzedaży próbuje zdefiniować wszystkie trzy (koszt, czas i zakres), to nie jest zwinny w sensie scrum, ponieważ zespół nie może obiecać osiągnięcia celu (bez naruszenia jakości = definicja-wykonania)

Profesjonalne kierownictwo stara się zdefiniować koszt i czas, a jeśli to konieczne, ograniczyć zakres, jeśli trzeba ustalić określoną datę.

Czy nie można odpowiedzieć w prosty i bezpośredni sposób?

Żadne terminy nie są zwinne.

Chodzi o to, aby zbudować to, co możesz, w sposób iteracyjny, ucząc się i dostosowując się podczas podróży.

Ostatecznym terminem jest „musisz dostarczyć x do y”, co nie udaje się z obu powodów, ponieważ obiecujesz stały doręczenie w ustalonym czasie (w przypadku zwinności mówi się, że nie jesteśmy pewni, co próbujemy dostarczyć, i uczenie się od zwinnego uczy nas, że nawet jeśli wiemy, że bardzo trudno jest mieć pewność co do skal czasowych - lub jest to rozwiązany problem i nie powinniśmy tego robić).

Po ustaleniu, że odpowiedź na pytanie brzmi „Nie, terminy nie są zwinne” - wtedy jesteśmy w stanie przeprowadzić interesującą rozmowę, która dotyczy pytania „jak radzimy sobie z terminami w zwinnym kontekście” i jest wiele dobrych myśląc o tym w innych odpowiedziach.

Moim zdaniem rozsądną odpowiedzią na to drugie jest to, że będziemy dostarczać przyrosty wartości wcześnie i często i zobaczymy, gdzie jesteśmy we właściwym czasie - ale nie ma jednego rozmiaru dla wszystkich.

Stopień zwinności wymagany w pracy jest odwrotnie proporcjonalny do tego, jak wysoko zajmuje jej miejsce na schemacie organizacyjnym.

„Agile” jest dobre, jak na to jest. „Zwinne” oznacza „otwarty umysł w połączeniu z wystarczającymi kompetencjami”. Chrząknięcia na dole muszą być najbardziej zwinne.

Jeśli na poziomie zarządzania sprytny szef był wystarczająco zwinny, aby zrozumieć, że przesunięcie terminu o tydzień w tygodniu zapewni lepszy produkt lub sprawi, że kod będzie bardziej przejrzysty, wolny od błędów i łatwiejszy do wykorzystania, dzięki czemu firma ( lub dywizja) oszczędza dwa tygodnie w przyszłości, to zwinny termin.

Ale tak jak oświecony interes własny, tak naprawdę nie istnieje.