Skąd wiesz, kiedy przestać dodawać funkcje?

Jakiś czas temu napisałem bardzo mały skrypt Pythona, który okresowo sprawdzał kanał XML pod kątem nowych wpisów i ostrzegał użytkownika o nowych wpisach, gdy są obecne. Napisałem to dla siebie, więc był to w zasadzie program konsolowy, z którego mógł korzystać każdy, kto dobrze zna interfejs konsoli.

Po chwili zdecydowałem, że może być bardziej użyteczny dla innych ludzi i zacząłem go porządkować, dezynfekować dane wejściowe, usuwać błędy. Przyszło mi do głowy, że ponieważ napisałem skrypt, wiedziałem, jak go używać skutecznie, dokładnie itp. Inni mogą nie, więc zacząłem dodawać GUI. Początkowo było to proste menu, a następnie rozszerzone do pełniejszego GUI z zarówno menu interfejsu, jak i menu opcji. Następnie dodałem zapisane preferencje użytkownika oraz pamięć dla wcześniej przeszukiwanych kanałów XML, aby przyspieszyć powtarzanie wyszukiwania.

Dodałem rejestrowanie, aby pomóc w debugowaniu aplikacji na wypadek, gdyby coś poszło nie tak, zaktualizowałem aplikację do najnowszej dostępnej stabilnej bazy kodu Pythona dla mojej wybranej platformy i poprawiłem funkcje dialogu.

Naprawiłem błąd i wyraźnie skomentowałem mój kod, a jednak wciąż mam rzeczy, które moim zdaniem można zrobić, aby ulepszyć aplikację, zanim udostępnię ją testerom alfa. Jest to dalekie od mojego oryginalnego skryptu 20-30 linii. To, czego się spodziewałem, zajęłoby mi godzinę lub dwie, aby przejść od weryfikacji koncepcji do programu akceptowalnego użytkowania, zajęło to 10–20 razy. (Nadal jestem noobem, a rzeczy zajmują mi dużo czasu, ale nadal ....)

Skąd wiesz, kiedy przestać dodawać / poprawiać / naprawiać rzeczy i pozwolić dziecku czołgać się na otwartej przestrzeni?

Kiedy dotrzesz do terminu.

Jeśli nie masz terminu, to jest twój problem ...

Oto jak pracuję:

1. Dodam nowe funkcje / błędy w moim rejestrze produktów.
2. Priorytet całego portfela produktów traktuję priorytetowo i oszacowuję (ostatni jest opcjonalny w przypadku osobistego projektu).
3. Przydzielam sobie czas pracy. Data premiery to koniec tego czasu.
4. Zaczynam od pierwszego na liście. Czasami pracuję nad funkcją. Aby zakończyć, funkcja musi być naprawdę kompletna, w tym dokumentacja (na końcu funkcji mogę potencjalnie wysłać produkt).
5. Zajmuję następny, dopóki mój przydzielony czas nie zostanie wykorzystany.
6. Jeśli czas jest zużywany podczas tworzenia funkcji, odrzucam ją tymczasowo.
7. Kiedy przydzielony czas zostanie wykorzystany, biorę najnowszą wersję i robię z nią wydanie.
8. Powtarzam proces od punktu 1.

Utwórz SRS, a następnie koduj zgodnie z wymaganiami. Po osiągnięciu wszystkich celów wymienionych w SRS nadszedł czas, aby zatrzymać i przetestować swój produkt.

W krótkim okresie, gdy masz coś, co działa niezawodnie i nie ulega awarii. Nawet jeśli nie zrobi wszystkiego, co mógł zrobić, jeśli pracowałbyś nad nim w nieskończoność. Wysyłka jak to się mówi to funkcja . Niezawodność i ograniczony zestaw funkcji daje możliwość przetestowania podstawowej funkcjonalności przez prawdziwych ludzi w prawdziwym świecie, którzy znajdą rzeczy, o których nigdy nie pomyślałeś, które łamią Twój kod w sposób, który nigdy nie przyszedłby ci do głowy. Im mniej funkcji masz w tym momencie, tym łatwiej będzie naprawić te wczesne problemy. Ponieważ podstawowa funkcjonalność działa bardziej niezawodnie, możesz rozpocząć wdrażanie innych rzeczy „miło mieć” ze świadomością, że Twój najważniejszy i centralny kod nadal działa dobrze.

W dłuższej perspektywie: po zakończeniu i udokumentowaniu systemu wtyczek, który pozwoli użytkownikom (i oczywiście tobie) szybko i łatwo wdrożyć nowe funkcje, jeśli ich potrzebujesz. To powinna być ostatnia funkcja, którą musisz dodać - po tym wszystkie wtyczki.

Gdy masz pewność co do stabilności oprogramowania, wybierz wersję, ale mogą być dostępne funkcje. Stabilność jest ważniejsza niż funkcje. Uzyskaj informacje zwrotne, uwzględnij istniejące funkcje i zdecyduj, co i kiedy ma zostać dostarczone!

Zawsze możesz pielęgnować projekt na zawsze.

Bardzo dobrą zasadą jest to, że nigdy nie należy dodawać rzeczy, które nie są w zatwierdzonym przypadku użycia. To gwarantuje, że nie skończysz z wieloma rzeczami, które byłyby fajne, ale których nikt nie używa. Zatwierdzenie zapewnia, że ​​inni niż Ty zgadzają się, że jest to potrzebne w Twoim projekcie.

To zależy od tego, dlaczego dodajesz funkcje. Czy właściciele projektów o to proszą? użytkownicy? QA? Programiści?

• Dodaj funkcje, które musisz.
• Przeszukuj ważne funkcje.
• Zignoruj ​​funkcje, które są miłe.

Skoncentruj się na celu programu i skoncentruj jego cel. Żądania nowych funkcji, które rozszerzają jego cel, powinny zostać dokładnie przesłuchane, zanim stanie się szwajcarskim scyzorykiem.

Nie przestaję już dodawać funkcji. Po prostu próbuję pobrać aplikację jak najszybciej i w razie potrzeby zapisywać pliki TXT. Wtedy mogę zdecydować, kiedy przestać, a kiedy popracować nad czymś innym

Pomaga to również, że lubię robić co najmniej możliwe, aby coś zrobić (bez uciekania się do hakowania).

Sugeruję, żebyś to timeboxował. Daj sobie tydzień do powiedzenia. Utwórz listę prac do wykonania w ciągu tego tygodnia i upewnij się, że jeśli masz funkcję, której nie możesz wykonać, możesz ją wycofać.

Pod koniec tygodnia wypuść go. Zwolnij wcześniej, zwolnij często.

Kiedy masz coś niezawodnego i przydatnego, zwolnij. Nie musisz przestać dodawać funkcji, ale jeśli ktoś korzysta z tego, co masz, uzyskasz o wiele lepszy pomysł na to, jakie funkcje są potrzebne. Obecnie zgadujesz.