Jak dobrze zdefiniowane powinno być oprogramowanie przed rozpoczęciem kodowania?

13

Chciałem wiedzieć, jak dobrze ludzie ogólnie definiują oprogramowanie, zanim zaczną kodować i jak dobrze dla nich zadziałało? Mam na myśli definiowanie przypadków użycia, analizę ryzyka, rysowanie diagramów klas itp.

Wiem, że dobrym pomysłem jest mieć wystarczająco dobry pomysł na to, jaki produkt końcowy będzie w stanie uniknąć ryzyka w przyszłości, ale ważne jest również, aby nie zdefiniować produktu tak dobrze, że trudno jest się do niego dostosować zmiana.

Inne bardziej szczegółowe pytania to prawdopodobnie:

  1. Jaki procent czasu projektu zwykle spędza się na etapach planowania przed opracowaniem?

  2. Czy masz jakieś wymierne kryteria, które starasz się spełnić, zanim zaczniesz kodować, czy jest to raczej odwaga?

  3. Czy wykreślasz wszystkie klasy przed rozpoczęciem kodowania, czy raczej próbuje od początku stworzyć dynamiczny projekt, oczekując, że wszystko się zmieni?

Każde doświadczenie, którym chcesz się podzielić, byłoby niesamowite!

Drawag
źródło

Odpowiedzi:

10

Dosłowna odpowiedź na pytanie „jak dobrze zdefiniowane?” jest

Dobrze zdefiniowane na tyle, że możesz zacząć.

Dobrze zdefiniowane na tyle, że można zidentyfikować początkowy zakres pracy (dla wstępnej koncepcji). To wystarczy, aby pomóc zidentyfikować zmiany, które nieuchronnie nastąpią.

Dobrze zdefiniowane na tyle, że możesz ustalać priorytety w sprintach.

Mam na myśli definiowanie przypadków użycia,

Zawsze pomocny. Ale nie wszystkie . Najpierw należy ustalić priorytety i uwzględnić ważne przypadki użycia. Inne przypadki użycia zostaną omówione w późniejszych wersjach. Niektóre przypadki użycia będą miały tak niski priorytet, że nigdy się nie zakończą.

analizowanie ryzyka,

Generalnie strata czasu.

rysowanie schematów klas itp.

Jeśli to pomoże.

Jaki procent czasu projektu zwykle spędza się na etapach planowania przed opracowaniem?

To się bardzo różni. Kup dobrą książkę, na przykład Software Engineering Economics, aby uzyskać „wiarygodne” liczby.

Czy masz jakieś wymierne kryteria, które starasz się spełnić, zanim zaczniesz kodować, czy jest to raczej odwaga?

"wymierny". To prawie niemożliwe do zdefiniowania.

"jelito". Zła polityka.

Problemem jest „czy rozumiesz, co robisz?”

To nie jest przeczucie. To pytanie Tak / Nie.

Nie jest to „mierzalne”, ponieważ jest to tylko pytanie tak / nie.

Ponadto musisz ustalić priorytety. Nie robisz wszystkiego Wystarczy, by poradzić sobie z pierwszymi kilkoma sprintami.

Czy wykreślasz wszystkie klasy przed rozpoczęciem kodowania, czy raczej próbuje od początku stworzyć dynamiczny projekt, oczekując, że wszystko się zmieni?

Nie możesz wiedzieć wszystkiego z góry.

Nie próbuj

S.Lott
źródło
osobiście uważam, że spędzanie zbyt dużo czasu na pisaniu diagramów klas jest stratą czasu, ponieważ model i kod wraz z nim zmieniają się po uruchomieniu.
AndersK
Zgadzam się, że nie możesz wiedzieć wszystkiego z wyprzedzeniem, ale dobry dokument projektowy przynajmniej pomoże ci zidentyfikować zakres i funkcje, kiedy to nastąpi.
Tim Post
@Tim Post: Dobra sugestia. Jest to sposób na zdefiniowanie „jak dobrze zdefiniowane” w pytaniu. Pomoże „zidentyfikować zakres i zakres funkcji”. Niewiele więcej, prawda?
S.Lott,
@Tim Post: „określenie zakresu” wprowadza w błąd. Oznacza to, że na początku projektu dostępna jest pewna wiedza na temat „zakresu”, co nie jest prawdą. Zakres będzie się zmieniać w trakcie cyklu życia projektu wraz ze zmianami potrzeb biznesowych, ponieważ żaden rynek nie jest statyczny.
Rein Henrichs,
@ Rein Henrichs: Poprawiłem nieco odpowiedź, aby uwzględnić Twój punkt widzenia. Wystarczająca definicja zakresu, aby rozpocząć. Kusi mnie, by dodać „i nie więcej”.
S.Lott,
2

Jeśli Twój klient aktywnie dołącza do projektu jako członek zespołu projektowego, który jest dostępny dla programistów w razie pytań i szybkich decyzji dotyczących funkcjonalności. Wtedy specyfikacja może być mniej szczegółowa.

Jeśli Twój klient jest daleko i nie ma możliwości uzyskania opinii przez długi czas, specyfikacja powinna być bardzo szczegółowa.

W naszej firmie tworzymy historie użytkowników i gramy w Planning Poker z programistami projektu. To daje nam rzetelne wskazanie godzin spędzonych na historii użytkownika.

pderaaij
źródło
„Przedstawiciel klienta” (rola, którą sugerujesz klientowi) jest najważniejszą rolą w całym zespole. Jeśli Twój zespół nie może uzyskać odpowiedzi na pytania dotyczące produktu i biznesu, jak mają podjąć właściwą decyzję?
Rein Henrichs,
To świetna uwaga, dziękuję! Nie zastanawiałem się, w jaki sposób zaangażowanie klienta może tak drastycznie zmienić to, co najlepiej pasuje do danego projektu. Zdecydowanie o czym powinienem pamiętać. Poza tym nigdy nie słyszałem o „Planning Poker” i wygląda na to, że byłoby to naprawdę cenne.
drewag
2

Jak dobrze zdefiniowany musi być projekt, wystarczy, aby zacząć i wiedzieć, dokąd zmierzasz w ciągu najbliższych dwóch tygodni.

Jako Scrum Master chciałbym po prostu powiedzieć, że musisz zdefiniować cechy brutto swojego produktu w arkuszu Excela lub gdziekolwiek indziej, tylko po to, aby śledzić twoje funkcje. Stworzenie ich Historie użytkowników pomagają dużo zastanowić się, jakiej funkcji potrzebujesz później. Następnie uszereguj je według priorytetów: Najważniejsza lub najważniejsza cecha na górze, a najmniej na dole.

Po tym, jak wymienisz niektóre z najważniejszych funkcji, wybierz funkcje, które Twoim zdaniem możesz opracować, aby przejść do stanu Gotowe po upływie dwóch tygodni lub okresu miesiąca, jeśli wolisz. Następnie eksploduj wybraną funkcję, aby zacząć kodowanie za kilka.

Podczas kodowania z pewnością pomyślisz o innych elementach, które należy opracować, aby doprowadzić wybrane funkcje do stanu Gotowe. Gotowe oznacza, że ​​nie masz już nic do roboty, czyli testowanie, kodowanie, składanie, dokumentacja jest gotowa!

W dowolnym momencie lista wybranych funkcji może się rozwinąć, o ile osiągniesz cel, to znaczy będziesz w stanie opracować wszystko, co powiedziałeś, że byłeś w danym okresie.

Krótko mówiąc, nic nie musi być idealne. Wrzuć kilka pomysłów, podziel się ze swoimi towarzyszami i sprawdź, czy to, co jest napisane, ma sens, aby spełnić wymagane wymagania dotyczące produktu. Jeśli tak, to jesteś w! Aby to wyjaśnić, wybiorę prosty produkt do zarządzania klientami. Co jest potrzebne?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

Twój pierwszy szkic może być tak prosty! Widzimy zatem, że bezpieczeństwo jest ważną częścią naszego systemu, czy jest wystarczająco ważne, aby nadać najwyższy priorytet (T / N)? Będzie to zależeć od wymagań, które musisz spełnić. Powiedzmy, że tutaj najważniejsza jest obsługa klienta. Tak więc w kolejnym Sprint musimy móc zarządzać klientami w prosty, ale akceptowalny sposób. Co to jest zarządzanie klientami?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

To już ilustruje wystarczającą liczbę funkcji, aby móc rozpocząć tworzenie aplikacji. Jeśli twoi programiści potrzebują dalszych instrukcji, być może jeden programista, który jest zaznajomiony z diagramami klas, może zaprojektować klasę klienta oraz jej właściwości i metody! Ale o ile mi chodzi, z tymi kilkoma, które napisałem, miałbym dość, aby zacząć. Niektóre funkcje mogą być dodawane lub zmieniane po drodze. Ważne jest, aby skupić się na tym, co powiedziałeś, że będzie Gotowe. W naszym przykładzie jest to kwestia zarządzania klientami. Od tej chwili nie musimy się przejmować uwierzytelnieniem użytkownika. Nadejdzie później w następnym Sprint.

Mam nadzieję, że to pomoże! =)

Will Marcouiller
źródło
Dzięki wielkie! Wspaniale było zobaczyć to w tak konkretnym scenariuszu. Wydaje mi się, że jest to dobre ramy do posiadania czegoś, co jest co najmniej w pewnym stopniu mierzalne w odniesieniu do tego, co definiujesz w ogólnym produkcie, ale podkreślając subgoale i podejście zorientowane na funkcje. Takie podejście z pewnością będzie ważne, ponieważ rozpoczynam nowe projekty w przyszłości!
drewag
Nie ma za co! Cieszę się, że moje ziarno soli może ci pomóc! =) Ważne jest, aby nie definiować zbyt dogłębnych funkcji, ponieważ wymagania dotyczące produktu mogą się zmieniać po drodze, ponieważ klient, gdy zobaczy to, co zrobiłeś do tej pory, może mieć inne pomysły lub zmiany, aby wprowadzić to, co masz Gotowy. Konieczne będzie odpowiednie dostosowanie produktu, aby spełniał nowe wymagania. Jeśli więc wszystko ustaliłeś na początku projektu, wyobraź sobie, że może to spowodować utratę pracy! Być może przepracujesz godziny, aby go wyrzucić i zacząć od nowa od zera. Niech ewoluuje =)
Will Marcouiller,
1

Cóż, dla mnie najlepsze jest określenie funkcji „dość dobrze”, a architektura oprogramowania jest bardzo luźna.

Aby rozpocząć pracę, muszę wiedzieć, nad czym pracuję. Nie działa dla mnie, gdy tylko rozumiem potrzeby klienta. Nawet jeśli piszę narzędzie na własny użytek, rysuję ekrany, opisuję funkcjonalność, co robi każdy przycisk, wszystko. W przeciwnym razie nie mogę zacząć.

Z drugiej strony zrezygnowałem z tego, żeby naprawdę dokładnie opracować kod. Może to najgorsza praktyka, ale działa dla mnie. Mogę zdefiniować zestaw tabel bazy danych, które utworzę, ale nie to, jakie kolumny są w każdej z nich. Mogę pomyśleć o tym, jakich przedmiotów i klas potrzebuję, ale zdecydowanie nie rysuję schematów.

Do diabła, czasami nawet nie wiem, jak to zrobić dobrze, dopóki nie zrobię tego źle. Buduję go raz, burzę i robię to jeszcze raz, teraz, kiedy wiem, jak to zrobić. W tym momencie mogę narysować dość szczegółową mapę drogową i ponownie uruchomić.

Ćwiek
źródło
Dziękujemy za podzielenie się swoimi doświadczeniami. Wydaje się, że zgadza się z tym konsensus, że ważne jest, abyś jako deweloper czuł się wystarczająco dobrze, aby zacząć. Oczywiście odkryjesz rzeczy, które zmieniłbyś, gdybyś zrobił to ponownie, w przeciwnym razie spędziłeś zbyt dużo czasu na planowaniu. Wiem, że mam ochotę dokonać pełnego przepisywania od razu po skończeniu produktu, i tego właśnie staram się unikać;) (przynajmniej w rozsądnym stopniu).
drewag
1

Jakiego języka i metodologii używasz?

Niektóre języki, takie jak Java i C ++, wymagają większej początkowej struktury niż języki takie jak Common Lisp lub Python (C ++ więcej niż Java, ponieważ refaktoryzacja jest łatwiejsza w Javie). Leo Brodie (myślę w „Thinking Forth”) udzielił dwóch rad na temat tego, kiedy zacząć kodować: wcześniej niż czujesz się komfortowo w Forth, później niż chcesz w innym języku.

Metodologia wodospadu (szczególnie, gdy wczesne projektowanie jest możliwe do dostarczenia) będzie wymagała więcej pracy z góry niż zwinności (chociaż nie chcesz również zaniedbywać wczesnego planowania metod zwinnych). Posiadanie dobrego zestawu zautomatyzowanych testów sprawia, że ​​bezpieczniej jest zmieniać większe rzeczy, a tym samym pozwala na radzenie sobie z mniejszą wstępną pracą.

Zależy to również od osób i ich znajomości rodzaju tworzonego oprogramowania. W pewnym momencie, robiąc przede wszystkim aplikacje CRUD, mogłem napisać cały program, zaczynając od kilku specyfikacji i kawałka czystego papieru notatkowego 3 x 5 cali. Nie mogę pisać rzeczy, które teraz piszę w ten sposób.

David Thornley
źródło
Dzięki za perspektywę. Nie zastanawiałem się, w jaki sposób język i platforma mogą wpływać na najlepsze praktyki zarządzania projektami. Mówię głównie o Objective-C, UIKit i AppKit. Jednak pracuję również w wielu innych językach (C, C ++, C #, Java, Python itp.). Oznacza to, że powinienem uważać, aby nie zakładać, że określona metoda będzie najlepsza dla wszystkich projektów, powinienem dostosować swoją bazę metodologiczną do platformy docelowej i języka (i może wybrać język oparty na tym, jeśli mam wybór).
drewag
1

Dwa przydatne terminy to MVP (minimalny możliwy do uzyskania produkt) i MMF (minimalna funkcja rynkowa). FRP to najmniejsza wersja funkcji zapewniającej wartość biznesową. MVP to najmniej FRP, które są rentowne jako produkt. Rozpoczynając projekt, najlepiej jest zidentyfikować FRP i MVP i zacząć od tego momentu.

Zwolnij swój produkt, gdy tylko będzie to wykonalne, a następnie stopniowo go ulepszaj.

Rein Henrichs
źródło
To naprawdę świetna terminologia, dzięki! To zdecydowanie najlepsza rzecz do wymyślenia czegoś wymiernego. Oczywiście nie jest idealny, ale wydaje się, że dość łatwo będzie zdecydować, czy dana funkcja jest dostępna na rynku i / lub stanowi wartość dodaną dla produktu.
drewag