Metodologie cyklu życia oprogramowania dla zespołów One Man [zamknięte]

Buduję system oprogramowania dla mojego projektu magisterskiego i szukałem porady na temat konkretnych metod, które pasowałyby do „zespołu jednoosobowego” ...

Zarabiam na życie jako jednoosobowy „pistolet do oprogramowania”, który pracuje głównie z domu, dlatego umieram, słysząc, co inni o tym mówią.

Oto kilka rzeczy, które uznałem za ważne:

• Jak mówi Denis, kontrola źródła jest niezbędna - ale SVN nie jest jedyną opcją. Najczęściej używam Perforce, a git jest dobrą alternatywą. Podoba mi się model rozwoju „głównego”; pozwala mi to przeprowadzać eksperymenty w gałęziach kodu, łączyć je z linią główną, gdy działają, i śmieci, jeśli nie działają.
• Używam notatnika do notatek i programu do śledzenia zadań. Obecnie używam Redmine do tego drugiego; wcześniej użyłem Fogbugza. Lubię też Redmine, ponieważ ma naprawdę dobrą wbudowaną wiki, której mogę używać do przechowywania notatek i linków do ważnych stron.
• Bardzo ważne jest również śledzenie tego, co robię, i ustalanie sobie rozsądnych limitów, dzięki czemu wykonuję wystarczająco dużo bez wypalania się - patrz poniżej.

Moje inne techniki ewoluowały przez lata i dostosowuję je w zależności od projektu i klienta. Ludzie płacą mi za działający kod, a nie za wygłupianie się z procesem, dlatego staram się, aby proces był lekki i poza zasięgiem twarzy moich klientów. Ale uważam, że niektóre techniki Agile działają naprawdę dobrze:

• Jeden z moich obecnych klientów upuszcza na mnie duże funkcje do wdrożenia i nie wprowadza błędów, dopóki nie skończą. Uważam więc, że praca nad sprintami Scruma jest świetna. Domyślam się, że może to zadziałać dla projektu mistrza, chyba że twój doradca badawczy jest maniakiem kontroli.
• Mój drugi obecny klient ma zwykle więcej sytuacji awaryjnych typu „przestań nad tym pracować i naprawić ten”. Próbowałem to zrobić ze Scrumem i poddałem się po jednym sprincie. Robię to za pomocą Kanbana i działa o wiele lepiej.

Innym problemem związanym z pracą na własną rękę jest to, że nie masz nikogo, kto powiedziałby ci, co robić i kiedy, lub jeśli masz dość pracy, lub kiedy rzucić pracę, ponieważ zrobiłeś wystarczająco dużo - więc musisz to zrobić to dla ciebie. Osobiście wolę Scrum, ponieważ mogę śledzić, jak sobie radzę w stosunku do moich celów sprintu. W przypadku projektów Kanban mogę po prostu śledzić, ile czasu poświęcam, ale to mi się nie podoba, a także coś bardziej opartego na celach.

Niektórzy moi przyjaciele przysięgają Pomodoro jako sposób na skoncentrowanie się na zadaniach i śledzenie osobistej wydajności, a ja myślę o wypróbowaniu tego.

Mam również formalny proces wydawania kodu moim klientom, aby upewnić się, że otrzymywane informacje są „prawidłowe”, ale prawdopodobnie nie jest to objęte pytaniem.

Użyj SVN wyżej, zmień wersję na wszystko. W przypadku śledzenia notebook wykona prostsze projekty, w razie potrzeby masz wiele bezpłatnych aplikacji do śledzenia zadań / błędów (Redmine jest fajny). Zwinna / XP / Ciągła integracja / inne byłyby moim zdaniem trochę przesadą.

Oprócz Personal Software Process , nie znalazłem wiele na temat formalnych modeli procesów zaprojektowanych do użytku przez jednego programistę. PSP jest dość ciężkie w dokumentacji i dokumentacji (w każdym razie w formie surowej), nie ma wiele do powiedzenia na temat konkretnych technik wykonywania pracy (zamiast tego PSP skupia się na gromadzeniu danych w celu znalezienia obszarów do poprawy), ale jest to początek punkt do opracowania osobistego procesu, który można wykorzystać w małych i średnich projektach.

Myślę, że najlepszym rozwiązaniem byłoby po prostu postępowanie zgodnie z kilkoma odpowiednio dobranymi (w oparciu o twoje potrzeby i projekt) powszechnie przyjętymi najlepszymi praktykami z wielu modeli procesów. Rzuć okiem na metody śledzenia wykonanej pracy / pozostałej pracy, zarządzania wymaganiami, kontroli wersji, testowania (szczególnie testów jednostkowych i akceptacyjnych), ciągłej integracji, standardów kodowania, nie będziesz tego potrzebował i tak dalej. Jeśli nie, sugeruję przeczytanie Code Complete i The Pragmatic Programmer i przećwiczenie ich wskazówek.

Najważniejszą rzeczą w pracy indywidualnej jest to, że poza wszelkimi ograniczeniami nałożonymi na ciebie przez siły zewnętrzne, wszystko zależy od ciebie. Nie musisz pomieścić nikogo, kto pracuje obok ciebie, więc łatwiej jest wybrać techniki, które pozwolą ci pracować w najbardziej wydajny sposób. Przez lata prawdopodobnie zorientowałeś się, jak najlepiej pracować, więc byłby to dobry punkt wyjścia. Następnie zastosuj znane „najlepsze praktyki”, aby zwiększyć swoje umiejętności i techniki.

Facet pyta o konkretne metodologie, a ludzie odpowiadają „używaj oprogramowania X / Y”. NIE jest to kwestia narzędzi, w rzeczywistości istnieje wiele metodologii i wydaje się, że nie ma jeszcze dla nich raportu walidacyjnego: Zwinny, Iteracyjny, Spiralny, Wodospad, XP, Model V, TDD.