Jak uniknąć pełzania funkcji w projekcie solo?

Mam więc program, nad którym pracowałem w 2011 roku i przez cały 2012 rok, ale ostatnie wydanie było w grudniu 2011 roku . Aktywnie nad tym pracuję, ale funkcja pełzania zwabiła jego brzydką głowę, a teraz jest pełna ton niedokończonych funkcji.

Złą stroną jest to, że kiedy wdrażam funkcję, wkrada się nowa. Co mogę zrobić, aby uniknąć pełzania funkcji w przyszłości, dzięki czemu mogę uzyskać wydanie w ciągu ponad roku ?

Projekt opiera się na systemie iOS i zawierał wydania dotyczące każdej aktualizacji wersji systemu iOS, ale ostatnia wróciła z wersją 5.1 (2011). Chciałbym móc odzyskać ten cykl stałego uwalniania, ale okazało się to zbyt trudne.

Z mojego doświadczenia wynika, że ​​najłatwiej jest mieć kadencję rozwoju i wydawania, która nie przeszkadza w tym, co chcesz zrobić. Oto jak to zrobiłem:

1. Zapisz funkcje i nadaj im ocenę odzwierciedlającą, ile chcesz nad tym popracować i ile według ciebie przyniesie to korzyść użytkownikowi (może być możliwe zaangażowanie w to rzeczywistych użytkowników). Następnie napisz je w tej kolejności.
2. Przed wpisaniem / wypchnięciem funkcji upewnij się, że masz stabilną, możliwą do wdrożenia kompilację (zdecydowanie rozważ system CI, aby to ułatwić).

W ten sposób możesz po prostu wypchnąć wersję po każdej funkcji, jeśli chcesz ... lub poczekać na pakiet, który oferuje wartość, którą chcesz mieć w wersji.

Uwaga:

• Funkcja nigdy nie może mieć wyższego priorytetu niż ta, nad którą pracujesz (lub może, ale nie może przerwać tej, nad którą pracujesz). Może przyjść później, ale nigdy teraz . Oznacza to, że jeśli przejdziesz od teraz do następnego, będziesz mieć możliwość wycięcia wersji wydania, jeśli chcesz.

Odpowiedź jest banalna i często niemożliwa: odmów dodania dodatkowych funkcji.

Mówiąc bardziej szczegółowo, odpowiedź sprowadza się do tego, co sprawia, że ​​nowa funkcja wpada do kosza pełzania funkcji? Jeśli założymy, że funkcje pełzające to te, które są dodawane do projektu, mimo że ich funkcjonalność jest tylko styczna do zamierzonego wykorzystania projektu i że funkcje pełzające są użyteczne, a nie zbędne, odpowiedzią jest przeniesienie ich w celu oddzielenia , ale powiązane narzędzia. Wykorzystaj uniksową filozofię budowania ortogonalnych narzędzi i ich sklejania.

Z punktu widzenia zarządzania projektami odpowiedź jest porównywalna. Zdecyduj, ile czasu chcesz poświęcić na kolejne wydanie i ustal ostateczny termin. Oszacuj cechy i wytnij wystarczająco, aby dotrzymać terminu. Jeśli są zaangażowani interesariusze inni niż Ty, spraw, aby wybrali to, co dla nich najważniejsze.

Dobry przegląd planowania można znaleźć w Joel on Software:

http://www.joelonsoftware.com/articles/fog0000000245.html

Jedną z najważniejszych lekcji w rozwoju jest wiedza, kiedy nadszedł czas, aby się zatrzymać.

Zazwyczaj programista dodaje funkcje. To z kolei inspiruje więcej pomysłów. Dodano więcej funkcji. Jest to, jak powiedziałeś, jeden ze sposobów, w jaki projekt staje się vaporware. Deweloper nigdy nie postrzega projektu jako „ukończonego”, więc nigdy nie zostaje wydany.

Nawyk, w który chcesz wejść, to przestać myśleć o wydaniu / wersji jako o „ukończonym” projekcie. Spójrz raczej na rozwój jako proces długoterminowy. Pomyśl o wydaniach jako kamieni milowych na drodze do tego, co pewnego dnia masz nadzieję, że program będzie. Tak więc wydanie / wersja jest tylko migawką tego, gdzie jesteś w dłuższym okresie czasu ... migawką, która została dobrze zaokrąglona i przetestowana.

Z praktycznego punktu widzenia możesz usiąść i przygotować kolejną wersję. To nie musi być strasznie dokładne. Zapisz 3-5 nowych głównych funkcji, które Twoim zdaniem są niezbędne w następnej wersji. ( rzeczywista liczba funkcji może się różnić w zależności od rodzaju aplikacji, nie licząc poprawek błędów lub drobnych zmian w GUI ) Pracuj nad nimi. Jeśli wpadniesz na inne pomysły, to dobrze ... po prostu zanotuj i zaimplementuj je w następnej wersji. Po wykonaniu tych 3-5 elementów Twoja wersja jest gotowa do wersji beta.

Kiedy uruchamiam nową aplikację, zwykle myślę o ostatecznej „wizji” aplikacji. Dla mnie tego właśnie chcę w wersji 3 aplikacji. Dzięki temu testowi mam pomysł, co sprawi, że solidna wersja 1 - tylko podstawy.

Podsumowanie:

Każde wydanie nie musi być ukończoną „wizją” projektu. To tylko kamień milowy w realizacji tej wizji.

Użyj systemu kontroli wersji, w którym tanie jest stworzenie gałęzi dla jakiegoś pomysłu i trzymaj ją z dala od ścieżki wydania. Na przykład gitmożesz „wpaść” na jakiś pomysł, a potem git stashodejść. Później możesz przejrzeć te skrytki i wybrać je w dowolnej kolejności, która wydaje się interesująca.

W przypadku większych funkcji utwórz prawdziwy oddział (aby można było wykonać wiele zatwierdzeń). Przykład: kiedy chciałem dodać obsługę generacyjną do modułu wyrzucania elementów bezużytecznych, utworzyłem oddział. Skrytki bardzo dobrze wychwytują rozpraszające drobiazgi. Duże funkcje mogą zaczynać się jako skrytki, a następnie zamieniać się w gałęzie, a następnie łączyć, gdy są gotowe.

Za pomocą skrytek i gałęzi możesz podsumować swoje pomysły, nadać im priorytety i ustalić zakres wydań swojego projektu solo, podobnie jak projekt zespołu zarządzanego.

Spójrz, kiedy wpadniesz na pomysł, musi gdzieś pójść , a najlepiej gdzieś jest kod : repo. Funkcje pełzania są lepsze niż zapominanie o dobrych pomysłach. Ale oczywiście, jeśli wkradniesz wszystkie swoje funkcje do tej samej linii głównej, będzie to opóźniało wydanie, chyba że wycinasz niechciane wydania pełne niedokończonych rzeczy, których użytkownicy powinni ostrzec, aby nie używali.