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) :
- Programiści mogą zidentyfikować interesujące (stymulujące intelektualnie) cele rozciągania związane z pracą, nad którymi chcieliby pracować.
- Te rozciągnięte cele, po zatwierdzeniu przez zespół (w tym właściciela produktu), stają się „złotymi kartami”.
- Zespół jest zachęcany do poświęcenia dnia na pracę nad tymi „złotymi kartami”.
- Zwykle dzieje się tak w piątki, więc staje się „dniem złotej karty”.
- W odniesieniu do Scruma, złote karty są planowane i śledzone, tak jak wszystkie inne elementy zaległości; zespół będzie musiał wykazać swoje wyniki.
Istnieją inne punkty (nie w tym artykule) dotyczące stosowania „złotych kart”:
- Nie pozwól jednemu członkowi zespołu czerpać radość. Każdy członek zespołu powinien być zachęcany do poświęcenia trochę czasu na „złotą kartę”.
- Na tej samej linii staraj się, aby „złota karta” była wysiłkiem zespołu (w przeciwieństwie do zadania solo) i wykorzystaj to zadanie jako moment towarzyski (budowanie zespołu).
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ą.