Zwinny dla programisty Solo

133

Jak ktoś mógłby wdrożyć koncepcje procesu Agile jako samodzielny programista? Zwinne wydaje się przydatne do szybszego tworzenia aplikacji, ale wydaje się również bardzo zorientowane na zespół ...

kelleystar
źródło
77
Właśnie próbowałem zastosować programowanie w parach jako programista solo, co poprawiło jakość mojej pracy!
Wizard79

Odpowiedzi:

66
  • Wykonując programowanie oparte na testach
  • Rozwijając się w małych sprintach
  • Mając duży kontakt z klientem

Pamiętam, że czytałem tezę o Cowboy Development, która jest niezbędna zwinna dla programistów solo, ale nie pamiętam, gdzie ją znalazłem.

Federico klez Culloca
źródło
18
Zdecydowanie nie zgadzam się z twierdzeniem, że rozwój „Cowboy” jest zwinny, nawet dla solisty
Travisa Christiana
4
@TravisChristian - It's more Lone Ranger.
JeffO
9
Oto link do pracy , którą @ a.brookshollar próbował zostawić jako edycję.
Scott Whitlock,
6
Założę się, że ani Travis, ani 11 osób, które głosowały na jego komentarz, nie przeczytały omawianej tezy. Pełny tytuł brzmi „Cowboy: An Agile Methodology For a Solo Programmer” i choć nieco przestarzały, warto go przeczytać.
Brien Malone
2
Link do pracy jest martwy, ale archiwum ją zawiera: web.archive.org/web/20150914220334/http://…
Tobias Kienzler
39

W nawiązaniu do odpowiedzi od kleza (wszystkie dobre sugestie) zasugerowałbym następujące:

  • Prowadzenie rejestru produktu Rejestr
    produktu to zasadniczo lista wszystkich elementów, które zamierzasz uzupełnić na pewnym etapie dla tego produktu.
  • Utrzymanie podsumowania sprintu i wypalenia produktu Wypalenie
    sprintu rozpoczyna się od listy wszystkich zadań, które zdecydowałeś się ukończyć w tym sprincie (podzbiór zaległości produktu, który ma zostać zakończony w określonym czasie - np. 2 tygodnie) wraz z oszacowanie wymaganej pracy. Kiedy zaznaczasz rzeczy, oznaczasz je jako zrobione; tym samym zmniejszając (lub spalając) pozostałą pracę dla tego sprintu.
    Podobnie wypalenie produktu śledzi pozostałą pracę dla całego zaległości produktu
  • Przyjęcie koncepcji szacowania względnego i prędkości
    Oszacowanie względne to technika szacowania, która wykorzystuje inne zadania (lub historie) jako wskazówki. Na przykład, jeśli wiesz, że zadanie A jest łatwiejsze niż zadanie B i około dwa razy bardziej złożone niż zadanie C, upewnij się, że „punkty” dla zadania A były prawidłowe w stosunku do tych oczekiwań.
    Nacisk kładziony jest nie na prawidłowe odgadnięcie wymaganej pracy, ale na utrzymywanie spójnych szacunków.
    Prędkość jest miarą tego, ile „punktów” wykonasz w sprincie. Jeśli oszacowanie względne zapewnia spójność, prędkości tej można użyć do oszacowania zadań, które prawdopodobnie wykonasz w nadchodzących sprintach. Należy jednak pamiętać, że prędkość ta powinna być ciągle zmieniana.
Damovisa
źródło
Zaległości produktu, wypalanie, szacowanie względne (punkty fabularne) i szybkość to podstawowe zwinne praktyki. Żaden z nich nie jest specyficzny dla sytuacji solisty.
azheglov
4
... podobnie jak TDD, sprinty i kontakt z klientem ...
Damovisa,
5
byłoby dobrze, gdybyś powiedział także, co to wszystko oznacza. Jestem tak blady, jak przedtem, zanim przeczytałem tę odpowiedź.
Kliknij Upvote
2
@Damovisa: Nie potrzebuję twoich opisów ani wyszukiwania w sieci, dziękuję bardzo. Bardzo dokładnie opisujesz niektóre typowe praktyki Scruma. To jest dokładnie punkt wyjścia pytania PO. Tak, te praktyki istnieją, ale są zorientowane na zespół, jak zastosować je w mikroskali? W twoich opisach nie ma nic specyficznego dla mikroskali.
azheglov
4
@azheglov Wow, nie musiałem obrażać. Podkreśliłem, które części Scrum są najbardziej przydatne w scenariuszu dla programistów solo, a nie jak je zastosować. Żadna z tych technik nie powinna się w ogóle zmienić w pojedynku przeciwko drużynie, więc zostaną zastosowane dokładnie w ten sam sposób. Aby odzwierciedlić słowa - w tych technikach nie ma nic, co byłoby specyficzne dla mikroskali.
Damovisa,
21
  • Ogranicz prace w toku (oprócz boksowania czasu). Nawet jeśli użyjesz metody iteracyjnej (w przeciwieństwie do Kanbana), powiedzmy, że twoja prędkość wynosi 8 punktów na iterację. Nie zaczynaj pracy nad wszystkimi 8 naraz. Ograniczanie PWT przez liczbę opowieści lub punktów opowieści jest w porządku.
  • Przeprowadź automatyczne testy akceptacyjne dla wszystkich swoich historii użytkowników. Zautomatyzuj jak najwięcej.
  • Błąd polegający na tym, że historie użytkowników są zbyt małe. Z reguły stosuj stosunek największej do najmniejszej opowieści 3: 1 . Jeśli lekceważysz historię w Scrumie i okazuje się ona zbyt duża, wielu programistów może ją zalać, aby przywrócić ją na właściwe tory. Ale nie masz wystarczającej liczby ludzi.
  • Jeśli w kontekście zwykłych drużyn wahałbyś się, czy oddzielić skok od historii użytkownika - w pojedynku lub w małym zespole, wykonaj skok bez wahania. Pomaga to w utrzymaniu mniejszych opowieści i większej przewidywalności.
  • Retrospektywy są ogólnie ważne w agile, więc Kanban (to byłby osobisty Kanban) zdobywa tutaj dodatkowe punkty, ponieważ jego retrospektywny proces jest bardziej oparty na danych. Trudno grać w Triple Nickels, gdy nie ma wystarczającej liczby osób.

Te rzeczy dotyczą prawdopodobnie zarówno solo, jak i małej drużyny (2 lub 3 programistów).

DODANO: jakiś czas po napisaniu tej odpowiedzi znalazłem tę konferencję i byłem pod wielkim wrażeniem: Personal Kanban: Optymalizacja indywidualnego kodera

azheglov
źródło
9
  • Albo pracuj nad dobrze zdefiniowanymi sprintami, albo celowo wybierz podejście Kanban. Nie przypadkowo ląduj w Kanban
  • Najpierw błędy, a następnie drugie.
  • Nadal skupiaj się na wzdęciach Value vs. Feature. (YAGNI nad złoceniem)
  • Retrospektywy są równie cenne. I równie ważne jest wprowadzanie zmian w procesach w małych porcjach. Nie decyduj, że dzisiaj zaczniesz korzystać z TDD, Mock i IoC za jednym strzałem, chyba że naprawdę nie masz żadnych zewnętrznych funkcji do dostarczania bankomatu. Przyprowadź pojedynczo.

Ostatecznie zdefiniowałem Agile jako „robienie tego, co ma sens dla zespołu i klienta, i nie stosowanie się do starych praktyk, ponieważ wyglądali, jakby działali w przeszłości”.

MIA
źródło
3

Zwinność działa tak samo dobrze dla jednostek, jak i dla zespołów. Chodzi o znalezienie procesu, który będzie dla ciebie odpowiedni, i umożliwienie ci dostosowania się do zmieniających się okoliczności, gdy projekt już się rozpocznie. Chodzi również o regularne dostarczanie wartości dla klienta, niezależnie od tego, czy oprogramowanie jest rzeczywiście „gotowe”.

Zwinne procesy są wysoce iteracyjne. Praca odbywa się w krótkich TimeBoxach / sprintach / cyklach / iteracjach. Niektóre prace projektowe mogą być wymagane z góry, ale można je zrewidować, gdy dowiesz się więcej o tym, czego potrzebujesz do zrobienia. Testy jednostkowe są podstawą prawie wszystkich metod programowania zwinnego, dając ci wskazanie, czy twoje oprogramowanie działa, i czy dodatki / zmiany w oprogramowaniu złamią istniejącą bazę kodu.

Jeśli zastosujesz się do BDD / TDD, pozwól, aby Twoje wymagania zmieniły się wraz z wiatrem i odpowiednio dostosuj priorytety funkcji, jeśli zbudujesz cały system i często uruchamiasz wszystkie testy, i jeśli dostarczysz działający kod na końcu każdego sprintu , jesteś już zwinny.

S.Robins
źródło
0

Łał. Starałem się trzymać przyjaciela na haku, do którego mógłbym zadzwonić, gdy miałem kłopoty - i rozmawiać o problemie z kodowaniem. Wiesz, co mam na myśli ... sam fakt wyjaśniania problemu na głos przynosi mi 90% czasu na rozwiązanie.

codeyoung
źródło
8
To NAJBARDZIEJ wartość, którą otrzymuję skądś, na przykład w stosie. Nie potrafię powiedzieć, ile pytań napisałem, a potem nie przesłałem dalej.
Dan Ray
5
Powiązane: c2.com/cgi/wiki?RubberDucking
Jo Liss
2
Gumowe kaczuszki to świetna koncepcja (omówiona w odpowiednich pytaniach tutaj), ale jak to odpowiada na zadane pytanie? „Jak ktoś mógłby wdrożyć koncepcje procesu Agile jako samodzielny programista?”
komar