Zwinny dla programisty Solo

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ół ...

• 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.

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.

• 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

• 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”.

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.

Ł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.