Scrum dla jednego programisty? [Zamknięte]

Jestem rozliczany jako „Ekspert systemu Windows” w mojej bardzo małej firmie, która składa się ze mnie, inżyniera mechanika zajmującego się sprzedażą i szkoleniem oraz prezesa firmy zajmującego się projektowaniem, rozwojem i wsparciem.

Moja rola jest równie ogólna, ale przede wszystkim projektuję i wdrażam wszystko, co trzeba zrobić, aby nasze produkty działały na dowolnych wersjach systemu Windows.

Właśnie skończyłem oglądać ogólny zarys paradygmatu Scrum podany w webcastie. Moje pytanie brzmi: czy warto poświęcić więcej czasu na zapoznanie się z tym podejściem do rozwoju produktu, biorąc pod uwagę, że moje elementy prac rozwojowych są zwykle podawane na bardzo wysokim poziomie, np. „Internacjonalizacja i lokalizacja produktu”.

Jeśli tak, to jak sugerowałbyś dostosowanie Scruma do użytku tylko jednego programisty? Jakie narzędzia, oparte na chmurze lub w inny sposób, byłyby przydatne do tego celu?

Jeśli tak nie jest, jakie podejście zaproponowałbyś jednemu programistowi, aby organizował swoje wysiłki z dnia na dzień? (Być może pytanie sprowadza się do tego prostego pytania).

Dowiedz się Scrum: tak. Jeśli tylko chcesz się o tym dowiedzieć, dodaj do swojego ogólnego zestawu umiejętności. (ale jego smak „Scrum-ban” jest prawdopodobnie tym, czego szukasz ...)

Scrum to fajna platforma, ale podstawową zasadą jest: „Iteracje (sprinty) powinny mieć ustalony czas trwania”. Nigdy nie widziałem tej pracy w bardzo małych zespołach, które są bardziej zaangażowane w przerwanie niż nie. Jeśli naprawdę możesz się zarejestrować i zobowiązać do pracy w określonym czasie (1 tydzień?), Scrum jest świetnym programem. Jeśli nie możesz ... Scrum jest przyjemny do nauki, ponieważ ma kilka dobrych koncepcji, które dobrze przekładają się na inne rzeczy ... jak ...

Backlog - Scrum lub nie, przechowuj listę rzeczy, które musisz zrobić w kolejności. Lubię Excela (lub Arkusz kalkulacyjny Google Doc ...) Może ci się spodobać coś innego. Trzymałbym bardzo małe narzędzie, jeśli jesteś bardzo małym zespołem. (Arkusz kalkulacyjny >> Edytor tekstu, ponieważ można łatwo sortować.)

Rozdzielenie planowania i zatwierdzenia - Zaplanuj w abstrakcyjnym zapisie (punkty) i zachowaj spójność (8 punktów to około 2 x 4-punktowa opowieść i 4 x 2-punktowa) Kiedy przyjdzie czas, aby „wykonać pracę”, ponownie przeanalizuj problem i naszkicuj go w godzinach. Nie zmieniaj punktów.

Zaangażowanie - bądź widoczny dla innych, kiedy popełniasz zobowiązania i wywiązuj się ze swoich zobowiązań

Retrospektywa - po dostarczeniu zastanów się, co można było zrobić lepiej.

itd itd.

Scrum jest wystarczająco łatwy do zrozumienia, że ​​może to być dobry punkt wyjścia. Jeśli ci się spodoba, rozważę użycie wariantu „Scrum-ban” - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Nic innego nie wydaje mi się „tak dobrze udokumentowane”, mając do dyspozycji dość aktywną społeczność.

Chciałbym również polecić metodologie Alistair Cockburn's Crystal (http://alistair.cockburn.us/Crystal+methodologies+main+foyer i http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Mały / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), ale wymaga znacznie więcej czytania i kopania.

Rzeczy takie jak XP zawierają więcej szczegółów na temat konkretnych praktyk, więc powiedziałbym również, aby przeczytać książkę: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= książki i ie = UTF8 i qid = 1304359834 i sr = 1-1

Końcowa lektura: tak długo, jak wyrażasz zgodę na manifest Agile i przestrzegasz zasad: http://agilemanifesto.org/principles.html powinieneś być w dobrej formie.

Osobiste zalecenie: Przyjęcie TDD (niepodlegające negocjacjom, IMHO) Utrzymanie zaległości (zgodnie ze Scrumem) Zawsze utrzymuj rozmiar i sortuj według priorytetu Rozkładaj rzeczy „zbyt duże, aby robić między przerwami” w mniejszych kawałkach Poproś kogoś innego o ustawienie / sprawdzenie priorytetu (nie dwa elementy mają ten sam priorytet. kiedykolwiek.) Spraw, aby środowisko kompilacji było w stanie zbudować / przetestować / wdrożyć (w środowisku laboratoryjnym) w ciągu 5-10 minut Pokaż swoim klientom (wewnętrznym i zewnętrznym) wyniki ukończenia historii Historia nie zostanie ukończona twój klient się zgadza. Wyciągaj Historie ze szczytu stosu i pracuj nad nimi, gdy ukończysz bieżącą historię Nie otwieraj więcej niż 2 rzeczy naraz. Zakończ rozproszenie uwagi, zanim zaczniesz inne.

mam nadzieję że to pomoże

Możesz użyć niektórych praktyk stosowanych w Scrumie, takich jak zaległości w tworzeniu produktów, ustalanie priorytetów, szacowanie względne, dostarczanie przyrostowe, ale stosowanie całego Scruma jako procesu zarządzania rozwojem produktu przez zespół samoorganizujących się członków grupy funkcjonalnej prawdopodobnie nie jest dobrym wyborem .

Pytanie brzmi, czy jesteś w stanie rozbić swoje elementy pracy na małe części, które można dostarczać stopniowo? Jeśli nie stosuje większości praktyk, nie ma to sensu. Również Scrum dotyczy wysokiej współpracy z właścicielem / klientem produktu. Nie powinno to brzmieć: „Tutaj masz zadanie i wróć, gdy się to skończy”.

Chociaż nie powiem nic za lub przeciw 1-osobowemu Srumowi, powiem, że 1-osobowy system ściągania Kanban działa bardzo dobrze. Kanban w połączeniu ze zautomatyzowanym testowaniem jednostek sprawił, że jestem o wiele bardziej produktywny i „udokumentowany”. Chociaż żadna z nich nie jest tak naprawdę metodologiami, ale większą liczbą narzędzi (i to bardzo odmiennych), oba zmuszają mnie do rozbicia dużych projektów solo na kawałki wielkości kęsa, a także dają mi rodzaj rytuału, który zachęca mnie do zrobienia więcej rzeczy za każdym razem dzień. Nie ma nic bardziej satysfakcjonującego niż kliknięcie „uruchom wszystkie testy” i zobaczenie, jak każdy przedmiot zmienia kolor na zielony… nic poza zabraniem karty z kolumny „W toku” na mojej planszy Kanban do „In testowania” (lub całkowicie poza planszę) .

Myślę, że prawdziwym problemem związanym z pracą solo jest to, że wybierasz spośród wielu metod, które są naprawdę przeznaczone dla grup programistów, i dostosowujesz je do swoich potrzeb. Ostatecznym celem jest, abyś był odpowiedzialny, produktywny i szczęśliwy. Kto wie, jak to zrobić lepiej niż ty (z odrobiną wyciągniętą stąd i trochę stamtąd).

Próbowałem tego, kiedy w pewnym momencie pracowałem sam. Rzeczy, które działały dobrze to:

1. Posiadanie wszystkich elementów roboczych na tablicy. Bardzo szybko mogłem zobaczyć, jaka była znakomita praca; gdzie były zależności i blokady. Poza tym wiele osób zatrzymywało się przy mojej tablicy i czytało - i rozmawialiśmy o tym. Myślę, że pomogło im to zrozumieć, co „maniak” robił cały dzień ;-)
2. Wykres spalania również był świetny. Właśnie użyłem do tego Excela. Pozwoliło mi to na lepszą ocenę szacunków w tym środowisku. Dało mi to świetny przegląd tego, dokąd zmierzam z iteracją. Mój menedżer, który nie był osobą techniczną, również to uwielbiał, ponieważ widziała różne rzeczy związane z funkcją i to, gdzie one były.
3. Codzienne wstawki. Najlepiej jak potrafię. Każdego ranka aktualizowałem wszystkie elementy pracy i tabelę wypalenia oraz notowałem wszystkie przeszkody, które należało rozwiązać.
4. Zautomatyzowane testowanie i ciągła integracja (MSTest / TFS), najlepiej TDD, pomoże każdemu zespołowi programistów, wykorzystując dowolną metodologię - ale warto o tym wspomnieć.
5. Krótkie iteracje (1 tydzień) naprawdę pomogły mi skoncentrować się na dostarczeniu czegoś.
6. Utrzymywanie zaległości było świetne, ponieważ kiedy dostałem nową pracę, mogłem umieścić ją w kontekście całej innej pracy i poprosić właściciela produktu o zmianę priorytetów.

Co nie zadziałało to:

1. Pracując samemu, nigdy nie osiągniesz takiego efektu dzięki współpracy z podobnie myślącymi ludźmi; lub poczucie rywalizacji i skupienia, które pochodzi od zespołu o naprawdę wielkim morale i kulturze. Kiedy utkniesz, nie masz innych mózgów do wyboru, więc takich blokad nie może wyeliminować mistrz scrum w codziennym wstawaniu.
2. Nie ma mistrza scrum - więc nie ma nikogo, kto mógłby przerwać zakłócenia. Miałem dużo problemów z ludźmi, którzy ciągle zadawali pytania dotyczące innych rzeczy i przerywali mi przepływ. Pod dobrym mistrzem scrum takie rzeczy są przechwytywane i możesz zacząć. Nigdy nie chciałem być niegrzeczny wobec ludzi (może jestem miękki), więc to był problem. Ponadto, bez mistrza scrum, możesz łatwo zejść z procesu.

To było ciekawe ćwiczenie, ale po chwili przestałem to robić. Myślę, że korzyści płynące ze Scrum należy postrzegać w przeciwieństwie do tradycyjnych zespołów wodospadowych. Ale oba są trochę dyskusyjne, gdy jesteś sam. Nie ma problemów z komunikacją ani współpracą - po prostu wykonuj zaplanowaną pracę i gotowe.

Myślę, że każdy powinien mieć zaległości i robić TDD.

Elementy Agile / Scrum / Kanban, które moim zdaniem mają sens w jednym świecie programistów:

1. Miej tablicę, na której uporządkujesz swoje historie użytkowników / aktywne zaległości, na kartach indeksowych, takich jak kanban.

2. Zdobądź wpisowe od deweloperów na wartość tych zasad:

   • Daj mi czas na pracę bez zmiany moich priorytetów względem mnie lub mikromanowania (punkt sprintu). Daj mi czas, a postaram się z góry dowiedzieć, ile dokładnie mogę zrobić, i zrobię co w mojej mocy, aby zrobić tyle.

   • Jeśli czegoś potrzebuję (zostaję zablokowany) i przyjdę do ciebie, a ty nie możesz tego dla mnie uporządkować, to może być konieczne nienormalne anulowanie sprintu. (To tylko oznacza, że ​​potrzebujemy nowego planu.)

   • Nikt niczego nie zmienia w trakcie sprintu. Lub, jeśli to zrobimy, po prostu anulujemy sprint i tworzymy nowy. jeśli to się często zdarza, wydajność spada.

   • komunikacja między osobami, które są zainteresowanymi stronami, może odbywać się podczas regularnych codziennych spotkań stand-up, które komunikują większość tych samych rzeczy, co zwykły scrum, w tym osiągnięcia programistów na dany dzień. Zasadniczo możesz zgłaszać rzeczy, które trwały dłużej, niż ci się wydawało lub poszły dobrze, oraz wszelkie zmiany, które wprowadzasz w swoich planach wdrożenia. (Znalazłem cztery nowe błędy i zarejestrowałem je, myślę, że są one ważniejsze niż ta opcjonalna funkcja, więc myślę, że spędzę czas, naprawię je i wypchnę tę opcjonalną funkcję.)

Dużo pracy wykonałem jako pojedynczy programista i mogę powiedzieć na pewno, że zaufanie między pojedynczym programistą a jego nie-programistycznymi przełożonymi / szefami oraz dobra komunikacja to klucze, a nie metodologia. Ale zawsze możesz być bardziej skuteczny, jeśli przestrzegasz dobrych zasad.

Przeczytałem o tym trochę bloga i myślę, że może ci pomóc z twoim pytaniem.

Pierwsza część: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Druga część: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Możesz znaleźć więcej informacji na tym blogu.

Nie jestem w żaden sposób połączony; tylko coś, co miałem w swoich ulubionych. Mam nadzieję, że może ci to pomóc.

Tak. I pamiętaj, że Scrum nie musi angażować wymyślnych narzędzi, może to być zwykłe 15-minutowe spotkanie stand-up, podczas którego wszyscy mówią o tym, nad czym pracują. Zaletą Scrum jest to, że wszyscy wiedzą, co się dzieje, a to ułatwia rozwiązywanie problemów, zanim się pojawią, i przewidywanie problemów w przyszłości.

W wielu z tych odpowiedzi brakuje ważnego punktu.

Zespół scrumowy nie musi składać się wyłącznie z programistów.

Jeden z twoich współpracowników zajmuje się „projektowaniem” / „rozwojem”, a drugi „sprzedażą”.

Być może Twój współpracownik ds. Sprzedaży może być właścicielem produktu (proxy). Jakie są oczekiwania klienta?

Projekt i rozwój twojego drugiego kolegi naprawdę brzmią dla mnie jak dyscypliny zespołu scrumowego. Rozwój Scruma nie jest etapowy, lecz pionowy (wymagania dotyczące rozwiązania, zaprojektowania i wdrożenia w jednym sprincie).

Możesz zrobić proces scrum z tobą trzema.

Co trzeba zrobić, aby zrobić to? Spotkania Scrumowe dotyczące planowania sprintu przybliżają pytanie, co to jest „to”. Czego oczekuje od właściciela produktu, aby uznać go za gotowy?

Podczas spotkania poświęconego planowaniu sprintu możesz przekazać innym kolegom kontekst, dlaczego „internacjonalizacja i lokalizacja produktu” może być technicznie trudna do wdrożenia.

Mnóstwo powodów, by używać Scrum Imho.

Sugerowałbym wypróbowanie Kanbana i rozpoczęcie od podstaw: wizualizacji i ograniczania produkcji w toku (WIP).

Nawet jeśli przerwiesz to później, zyskasz większą zwinność. I chociaż Kanban jest dobry do „normalnego” opracowywania oprogramowania, Kanban + oparty na przepływie proces (w przeciwieństwie do iteracji) przyćmiewa inne narzędzia procesowe, gdy pojawia się sytuacja zarówno z opracowywaniem nowych funkcji, jak i konserwacją.

Popieram zalecenie książki Kanban Davida Andersona, a także możesz obejrzeć moje slajdy z lokalnego spotkania na temat tego, dlaczego i jak zacząć od prostego Kanban , lub crisp.se/kanban na krótkie wprowadzenie.

W twoim kontekście mam kilka przemyśleń:

• widoczność jest kluczowa, więc raczej użyj fizycznej tablicy niż narzędzia cyfrowego, jeśli nie możesz jej trwale wyświetlić na (dużym) ekranie (jeśli jesteś w tej samej lokalizacji)
• zacznij od bieżącego procesu
• zacznij od swojej strefy wpływów, w tym w fazach przekazywania i wycofywania klientów (stając się w kolejce dla Ciebie, np. zaprojektowane funkcje gotowe do opracowania lub w kolejce od Ciebie, np. gotowe funkcje, gotowe do sprzedaży)
• jeśli Twoi koledzy są zainteresowani rozszerzeniem wizualizacji w górę lub w dół, tym lepiej. Może skończysz wizualizując cały strumień wartości (lub sieć) dla swojej firmy, tj. Sposób, w jaki wartość przepływa od koncepcji do gotówki
• zminimalizuj wielozadaniowość (!), ograniczając WIP. Jeśli koledzy z pracy są widoczni, powinni zrozumieć, dlaczego i łatwo zobaczyć, co jest na talerzu
• być może przydatne będzie podzielenie pracy na 3 lub 4 typy pracy (klasy usług), które mają wobec nich różne wymagania: np. błędy, problemy krytyczne, praca z ciężkimi terminami, praca bez terminów
• obserwuj, jak płynie twoja praca, np. jeśli gdzieś masz wąskie gardła, praca jest zablokowana lub „głodujesz” pracy w sposób przewidywalny. Jest to łatwiejsze na dłuższą metę, jeśli używasz narzędzia cyfrowego, zapoznaj się z kilkoma moimi ostatnimi slajdami.
• usprawnij przepływ pracy krok po kroku

Jeśli chcesz wypróbować coś teraz, dziś, kiedy podejmujesz decyzję, polecam wypróbowanie osobistego kanban na ścianie, oknie lub szafce obok ciebie, tak jak zrobiłem w zeszłym tygodniu ...

Po przeczytaniu wszystkich innych odpowiedzi tutaj wydaje mi się, że prosta pragmatyczna odpowiedź brzmi:

Wykorzystaj procesy, techniki lub metody, które są w użyciu, aby UCZYĆ się czegoś, co pomoże ci lepiej wykonywać swoją pracę.

Może to oznaczać priorytetowe traktowanie twoich zadań - każdego dnia - religijnie.

Może to oznaczać wypracowanie zaległości.

Może to oznaczać zgłaszanie postępów - swojemu szefowi (nawet jeśli go to nie obchodzi ... robienie tego dobrze jest mentalnie pozwolić Tobie na podsumowanie tego, gdzie jesteś).

Możesz użyć różnego rodzaju metod i technik, ponieważ ostatecznie pozwalają ci pracować lepiej, co oznacza lepsze spanie w nocy.

Rób rzeczy, które działają (dla ciebie, w obecnych okolicznościach), odrzucaj rzeczy, które nie działają.

Chyba że masz na miejscu następujące elementy

• Środki do organizowania i ustalania priorytetów nadchodzących wymagań.

• Aby dokładnie oszacować wysiłek, który zostanie podjęty, abyś wiedział, co możesz zrobić w iteracji

• Iteracje i ciągłe doskonalenie - koncepcja iteracji, w których osoba stale się sprawdza i dostosowuje, jest nieoceniona. Ta praktyka zachęca do eksperymentowania i opiera się na ciągłym uczeniu się. Scrum in Church, strona 4

• Cóż, nie możesz robić codziennych spotkań z Scrumem, ale przynajmniej możesz sobie przypomnieć o zadaniu, które dziś podejmiesz. Codzienne spotkanie scrum jest używane, aby zespoły mogły zsynchronizować się ze sobą na temat tego, co robią.

• Refleksja po sprincie - w scrumie nazywa się to Sprint Retrospective, pod koniec każdej iteracji możesz zastanowić się, co się stało po iteracji, i pomyśleć o tym, co poszło nie tak i jak możesz to poprawić, jakie są najlepsze praktyki, aby je zachować robić

Sugeruję przyjęcie minimalistycznego podejścia, a dzięki ciągłemu doskonaleniu możesz uzyskać scrum, który dobrze pasuje do twoich potrzeb.

Scrum nie jest scrumem, jeśli nie możesz go dopasować do swoich potrzeb i dostosować do obecnej sytuacji.