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

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!

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

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.

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! =)

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

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.

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.