Trzeba powiedzieć, że metodyki zwinne sprawdzają się w warunkach, w których wymagania są słabo zrozumiane lub w grę wchodzi znacząca nowość . Ale czy należy go stosować tam, gdzie wymagana jest bezwzględna innowacja? Jeśli tak to jak?
Jeśli to, co rozważasz, nie jest znane w branży, a nawet uważane za niemożliwe, wyobrażenie sobie historii użytkownika i powiązanych zadań może być trudne. Na przykład, czy skorzystałby Albert Einstein (lub hipotetyczny pracodawca, o którym donosi), aby opracował teorię ogólnej teorii względności, dzieląc ją na epopeję, sprinty i zadania? Jeśli odpowiedź brzmi „tak”, to jakie specjalne zakwaterowanie powinno zostać uwzględnione, aby sprawne podejście najlepiej działało w sposób rewolucyjny Einsteina?
Aby podać konkretny przykład oprogramowania, wyobraź sobie, że jest rok 2008 i chciałbyś użyć WCF, aby zapewnić funkcje typu COMET lub „ długiego odpytywania ”. Wszystkie twoje badania dotyczące „wcześniejszej pracy” nic nie pokazują, a nawet czytasz blogera MSDN, który mówi, że to niemożliwe.
Ponownie, jakie poprawki lub „smak” można wprowadzić w historie i zadania użytkownika, aby dostosować się do pomysłowości (lub śmiałości?) Tego twórcy? A może rzeczywiście lepiej byłoby stwierdzić, że wysiłek jest tak innowacyjny (w 2008 r.), Że najlepiej pozostawić go jako niekierowane ćwiczenie?
Innowator, który działa w ramach dwutygodniowych sprintów, z pewnością nie chce zostać zestrzelony za każdym razem, gdy porzuci zadanie ślepe zaułek i zacznie pracę nad nowo odkrytym zadaniem, którego nie przewidywano podczas definiowania sprintu. Podobnie, gdy skończy się sprint i nie zostanie dostarczony działający kod ani działające podejścia, innowator nie powinien być zestrzelony przez kierownictwo. Musi istnieć sposób, aby nazwać ten wysiłek „sukcesem”, nawet w takich okolicznościach. Być może w jednym lub trzech kolejnych sprintach tego rodzaju „ślepych zaułków” innowator może w końcu trafić na coś, co działa.
Skąd zwinny pozwala kierownictwu wiedzieć, że każdy sprint był „ok” pomimo innowacyjnych niepowodzeń? Jak to się zarządza, aby wykres wypalenia nie wyglądał niedorzecznie?
Odpowiedzi:
Pytanie tytułowe, w którym innowacje odnoszą się do mniejszych postępów twórczych w zespole, który już dobrze radzi sobie w Agile.
Najlepsza odpowiedź została streszczona w tym artykule na temat „dni złotej karty” .
Podsumowanie (sparafrazowane iz moimi własnymi interpretacjami, które mogą nie odzwierciedlać intencji autora) :
Istnieją inne punkty (nie w tym artykule) dotyczące stosowania „złotych kart”:
Zasadnicze pytanie, w którym innowacja odnosi się do badań (miesiące do lat makabrycznej pracy), które wiążą się z realnym ryzykiem nie znalezienia żadnego przydatnego rozwiązania.
To wcześniejsze pytanie, jakie techniki programowania ekstremalnego są odpowiednie do zastosowania w środowisku badawczym? obejmuje znaczną część tego pytania.
(Zastrzeżenie: Napisałem jedną z odpowiedzi na to pytanie, choć nie wybraną).
Podsumowując, prace badawcze nad oprogramowaniem można przyspieszyć; wymaga od swoich uczestników ustalania priorytetów w oparciu o nowe informacje (poprzez absorpcję odkrytych / wyuczonych pomysłów i syntezę nowych). Wygląda na „powolnego” tylko dlatego, że „wolno pokazuje owoce sukcesu i tylko wtedy, gdy się udaje”.
To pytanie dotyczące Project Management Beta - Jakie są zalety i wady włączenia kierownika projektu do zespołu badawczego? - obejmuje również te same podstawy.
W duchu tak.
Jak wskazano w odpowiedzi mouviciel , duch badań nad oprogramowaniem jest zgodny z duchem Agile Manifesto. Następnie będę argumentować, czy badania wysokiego ryzyka można dopasować do Agile jako metodologii organizacji lub zarządzania („Agile w praktyce”).
W praktyce musisz odpowiedzieć na kilka pytań.
Ta lista nie jest wyczerpująca ...
Musimy trochę prześledzić, jak powstała Agile Methodology.
Metodologia zwinna jest zwykle stosowana, gdy istnieje sponsor projektu. Ponadto gotowość sponsora do sfinansowania projektu jest ograniczona; Oczekuje, że po pewnym okresie czasu będzie regularnie dostarczane oprogramowanie o użytecznej (potencjalnie możliwej do wysyłki) jakości.
Rodzaj pracy badawczej w tym pytaniu odnosi się do „potencjalnie nierozwiązywalnych przedsięwzięć”. Innymi słowy, sama natura tego rodzaju pracy wiąże się z ryzykiem, że może ona ostatecznie zakończyć się niepowodzeniem, pomimo wszystkich intencji i staranności zaangażowanych osób.
To nie jest lista kontrolna w stylu ScrumButt.
To jest bardziej lista kontrolna przed lotem, która przewiduje, czy lepiej jest „Que Sera, Sera”
1. Przejrzystość z góry. Czy sponsorowi projektu powiedziano prawdę o ryzykownym charakterze projektu?
2. Gotowość sponsora. Czy sponsor jest świadomy ryzyka i chce kontynuować finansowanie?
Sponsor musi mieć akceptację ryzyka wyższą niż typowe projekty biznesowe lub typowe projekty Software / IT / Agile. Nie każdy sponsor spełnia te kryteria. Jeśli to nie pasuje, dobrze byłoby, gdyby profesjonalista wycofał się z projektu.
3. Przejrzystość w całym projekcie. Czy sponsor jest regularnie informowany o prawdziwym statusie projektu?
Ma to na celu udaremnienie prób ukrycia niepowodzeń lub zbliżających się niepowodzeń w projekcie poprzez niewłaściwe wykorzystanie upływu czasu między aktualizacjami statusu.
4. Aktywny udział sponsora. Czy sponsor jest zainteresowany poznaniem drobiazgowych szczegółów, wzlotów i upadków, obietnic i ograniczeń każdej próby?
Problem z badaniami oprogramowania polega na tym, że może istnieć wiele fałszywych tropów - zarówno fałszywie dodatnich (przekonanie, że podejście zadziałałoby, ale skończyło się to niepowodzeniem), jak i fałszywych negatywów (twierdzenie, że coś nie jest możliwe, a jedynie obalenie przez kogoś innego) .
Zwinne projekty pozwalają zespołowi (w tym sponsorom i interesariuszom) podjąć obliczone ryzyko. „Obliczony” oznacza, że osoby podejmujące ryzyko są w pełni poinformowane. Jeśli sponsor nie chce poznać drobiazgowych szczegółów projektu, wówczas sponsor nie będzie miał pełnych informacji do samodzielnego obliczenia (oceny) ryzyka.
Nawet jeśli sponsor jest skłonny do podjęcia ryzyka finansowego, jeśli nie chce również wziąć udziału w ryzyku decyzyjnym (i akceptuje konsekwencje swoich własnych wyborów), sponsor również nie jest odpowiedni do takich projektów badawczych o wysokim ryzyku.
5. Czy zespół badawczy może pokazywać (demonstrować) swoje postępy w postaci uruchamiania oprogramowania, w przeciwieństwie do slajdów prezentacji?
To pytanie jest odpowiednie w przypadku projektów badawczych, w których oczekuje się, że wynikiem końcowym będzie uruchomienie oprogramowania. Slajdy prezentacji mogą być przydatne do wyjaśnienia teorii CS, ale mogą być również niewłaściwie wykorzystane do ukrycia niepowodzeń w implementacji oprogramowania (lub całkowitego braku). Demo oprogramowania ma na celu udaremnienie takich nadużyć.
6. Czy zespół badawczy może dostarczyć częściowo wartościowy produkt programowy, nawet jeśli sponsor zdecyduje się zaprzestać finansowania w dowolnym momencie projektu?
To pytanie jest istotne tylko w poszczególnych przypadkach. Niektóre projekty badawcze mają charakter przyrostowy; mogą mieć wiele kamieni milowych i rezultatów. Wymaga od zespołu badawczego, aby priorytetowo potraktowali swoje podejścia, aby faworyzować „owoce o najniższych wiszących owocach” lub „podejście o najniższych kosztach w celu wykazania żywotności”.
Niektóre projekty badawcze nie mają charakteru przyrostowego: zapewnić jeden, bardzo konkretny przełom technologiczny. To trafienie lub chybienie. W przypadku tego rodzaju projektów jedynymi dodatkowymi wynikami są prace badawcze i prototypowanie, a być może publikacje akademickie. Te „nieużywalne” dodatkowe elementy są jednak cenne dla niektórych rodzajów sponsorów - mianowicie uniwersytetów, agencji finansujących badania i wielkich korporacji, które chcą zbudować dobrą wolę akademicką.
Jednak projekty badawcze o takich cechach mogą również faworyzować podejście „kodowania kowbojskiego”, jak omówiono poniżej. Są one trafnie nazywane „hackami” i mają miejsce w środowisku akademickim.
Ze względu na skalę czasową większości badań akademickich finansowanie badań w stylu akademickim jest zwykle zapewniane na okres jednego roku lub więcej lat; finansowanie badań medycznych (akademickich i komercyjnych) może być przyznawane na jeszcze dłuższe okresy. Z drugiej strony typowe badania finansowane ze środków komercyjnych mogą zostać zakończone bez uprzedzenia lub mogą zostać całkowicie przeniesione ich zasoby (siła robocza) na inne projekty.
7. Jak zespół badawczy mierzy skalę silosu w porównaniu z funkcjonalnością?
Niektóre typy zespołów badawczych są silnie wyciszone. Często zdarza się to w projektach „multidyscyplinarnych” - zaangażowany jest dokładnie jeden członek z każdej dyscypliny. W rezultacie żaden członek nie może przejąć zadania innego członka, nawet bardzo małego, ponieważ ich wiedza i umiejętności się nie pokrywają. Trudność dotyczyłaby także komunikacji i definicji zadań.
Niezwykle uciszone zespoły nadal będą korzystać z niektórych rytuałów Scruma, takich jak codzienne spotkanie stand-up, ale oprócz „rytuału” może nie być wiele interakcji. Potrzebny byłby bardzo zwinny, zwinny trener, aby zmusić zespół do rozmowy i budowania zaufania.
8. Jeśli obecny jest zwinny trener, czy trener przepisuje krótkie cykle iteracji, boks czasowy i podaje prognozy czasu?
Każda z tych zwinnych praktyk stwarza trudności dla niektórych rodzajów projektów badawczych. Niemniej jednak zgłoszono, że niektóre grupy ekspertów posiadające umiejętności wykwalifikowane były w stanie zastosować te praktyki w zaawansowanych badaniach . Ponieważ nie ma szczegółowych informacji na temat tego, jak sprawny coaching występuje w tych zespołach ekspertów, możemy nie być w stanie wiedzieć, w jaki sposób można pokonać każdą z tych trudności.
9. Czy zespół badawczy jednogłośnie głosuje za przyjęciem stylu rozwoju Solo zamiast jakiejkolwiek innej metodologii?
Edytowane: wcześniejsza wersja używa wyrażenia „kodowanie kowboja”, co sugeruje brak profesjonalizmu. Istnieje jednak różnica między rozwojem solo a kodowaniem kowboja, a okoliczności na tej liście kontrolnej mogą sprawić, że rozwój solo będzie uzasadnionym wyborem.
To pytanie pokazuje, że są programiści, którzy wolą posiadać dużą część oprogramowania. Jeśli zespół badawczy składa się głównie z tego rodzaju programistów, biorąc pod uwagę, że zestaw umiejętności członków zespołu jest niezastąpiony (w odniesieniu do poprzedniego punktu umiejętności), członkowie zespołu mogą w zamian otrzymać to, czego chcą, w zamian za swoje umiejętności i pracę.
Główną różnicą między programowaniem solo a programowaniem kowbojskim jest to, że w programowaniu solo można zastosować praktyki wymienione w teście Joela: 12 kroków do lepszego kodu , takie jak kontrola wersji, automatyzacja kompilacji i naprawianie błędów przed dodaniem nowych funkcji .
Niektóre okoliczności będą sprzyjać każdemu członkowi rozwijającemu solo, podczas gdy niektóre okoliczności będą sprzyjać kodowaniu kowbojów.
Kodowanie kowbojskie jest uprzywilejowane, jeśli celem końcowym jest „wskazanie”, pokazując, że coś jest technologicznie możliwe. Nie ma żadnych wymagań dotyczących dostawy - ani jakości - oprócz dobrej prezentacji na kolejnym DEF CON ® .
Ostatnie pytanie Jeśli okoliczności nie pozwalają zespołowi Agile na przełomowe badania, to w jaki sposób wykorzystują innowacyjną technologię?
Biznes jak zwykle. Pozwól innym firmom (lub naukowcom, osobom lub zespołom hakerów , startupom itp.) Najpierw rozwiązać trudny problem, a następnie kup / licencjonuj od nich technologię. Branża oprogramowania działa na tych zasadach od wielu dziesięcioleci.
Nacisk na pokazywanie wczesnych działających prototypów w metodologii Agile zmusza zespół do szukania najpierw istniejących rozwiązań, co jest dobre, ponieważ może uratować zespół przed zbędną pracą.
źródło
Powrót do Manifestu Agile :
Nic w tych wartościach nie zabrania innowacji. W rzeczywistości innowacje mają lepsze gniazdo w Agile niż w Waterfall.
Niemniej jednak może się zdarzyć, że zwykłe wdrożenia Agile nakładają pewne ograniczenia na projekt oprogramowania, które ograniczają innowacje, takie jak terminy (termin sprintu to termin) lub koszty. Ale to nie jest problem z Agile, to problem z obecnymi organizacjami pracy.
źródło
Nie sądzę, że tak. Agile polega na jedzeniu słoni czekoladowych - podejmowaniu dużego zadania i rozkładaniu go na porcje, które można nie tylko dostarczyć, ale także regularnie.
Projekty typu badawczego nie pasują do tego - nie, chyba że twój projekt można podzielić na małe fragmenty, które można wykazać co dwa tygodnie (lub dłużej - nigdzie nie mówi Agile, że 2 tygodnie to czas, w którym sprint musi zająć, najlepszy zwinny projekt, jaki kiedykolwiek pracowałem nad 6-tygodniowymi sprintami)
Jednak nie spróbowałbym tego. Wziąłbym kawałki zwinnych narzędzi, które według ciebie mogłyby dla ciebie zadziałać, i zignorowałem te, które nie działają. Zbyt wiele osób uważa, że zwinny oznacza „musisz zrobić wszystko, co mówi samouczek scrum, i nigdy nie jest dozwolona żadna dyskrecja”, takie podejście jest bardzo niestabilne.
źródło