Jak planować ogromne projekty programistyczne?
Rozpoczęliśmy ogromny projekt. Wiemy, jak to ma wyglądać, ale nie jak to wdrożyć. Zaczęliśmy od pisania prototypów do testowania różnych implementacji. Brakuje nam przeglądu ogólnego postępu w rozwoju. Nie wiemy, czy poświęcamy zbyt dużo czasu na szczegóły, czy też te szczegóły są na tyle ważne, aby je poświęcić.
Zacząłem od stworzenia listy zadań, które musimy wykonać, takich jak "implementacja funkcji X", "sprawdź, jak zaimplementować Y". Teraz mam ogromna mapa myśli z około 500 zadaniami. Następnym krokiem, jaki mogłem zrobić, jest zdefiniowanie zależności między zadaniami. W ten sposób wiedziałbym, co najpierw wdrożyć, a zadania, od których najbardziej zależy, są najbardziej krytyczne. Ale nie mogę zrobić tego rodzaju zamówienia za pomocą narzędzia mapy myśli. To bardzo frustrujące.
Jak planować wielkie projekty programistyczne?
7 answers
Istnieje wiele dobrych artykułów i książek na ten temat. Krótko mówiąc, ogranicz zależności, zachowaj prostotę, ale elastyczność i zacznij od szybkiego pisania kodowalnych komponentów-daje to o wiele lepsze "wyczucie" tego, jak będziesz musiał robić rzeczy. Przygotuj się na ewolucję swoich projektów i przygotuj się na przepisanie sporej części kodu.
Nie próbuj pisać idealnego systemu od zera. Ustaw , aby napisać uproszczony system, a przez przypadek możesz w końcu skończyć pisanie idealnego systemu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-21 23:49:59
Wykonuj swoją pracę w iteracjach. Skoncentruj się na tym, co jest niezbędne dla jednej konkretnej iteracji. jeśli skupisz się na wszystkich szczegółach w tym samym czasie, nie uda ci się.
Po pierwsze, zdecyduj, jakie ogólne funkcje chcesz mieć i zaprojektuj do tego.
W kolejnych krokach będziesz dodawał coraz więcej zaawansowanych funkcji.
Gdy masz stabilną strukturę szkieletową architektury, możesz podzielić projekt na moduły i podzielić je na kilka zespołów. Zespoły będą również pracować w iteracjach.
Nikt nie jest w stanie zaprojektować ogromnego projektu oprogramowania od samego początku. Ogromny projekt rośnie powoli, ze wszystkimi zwykłymi problemami z dzieciństwa.
Jeden kęs na raz.
Poważnie, patrzenie na całość jest dobre, o ile nie jesteś całkowicie skupiony. Musimy podzielić go na mniejsze i mniejsze projekty, dopóki nie będziemy mogli go objąć.
Jeśli jeszcze nie poszedłeś w tę stronę, każda z metod zwinnych działa najlepiej. Scrum is great, XP jest dobrze. Wykorzystują iteracje, co powoduje, że tak szybko jak możliwe.
Próba obejścia całej sprawy jest naprawdę, naprawdę trudna i uważam to za bardzo demotywujące. Ale dzięki zwinnej technice użytkownicy natychmiast widzą postępy, a nasz zespół jest podekscytowany, ponieważ ich kod jest używany w prawdziwym życiu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-09 11:40:29
Zacznij od 1 peice, rozwijaj go, doskonal i ucz się z niego. Gdy już to zrobisz, przejdź do następnego elementu. Jak robisz każdy kawałek, Dodaj do swojej biblioteki kodu wielokrotnego użytku. W miarę upływu czasu proces powinien być bardziej dopracowany, a czas rozwoju powinien się zmniejszać. Najgorsze, co możesz zrobić, to rozwinąć całość w podejściu opartym na wodospadie. Dostać coś działa i doskonalić go, to nie tylko pozwoli Ci pokazać szefów pracujących elementów, ale także pozwoli Ci znaleźć swoje naturalna równowaga między planowaniem a kodowaniem.
Jeśli chcesz formalny sposób planowania, polecam zwinny rozwój. To daje dobre wytyczne, jak planować swoje zadania i wykonywać je. Ale nadal myślę, że zespół programistów wpadnie w rytm, który najlepiej pasuje do niego i podejście przyrostowe na to pozwoli.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-09 11:46:33
To właśnie pomogło mi zacząć:
[1] Zacznij od dokumentu wymagań. Pisz z punktu widzenia klientów. Zapisz wszystko, co oprogramowanie powinno być w stanie zrobić. Unikaj podawania rozwiązań. Bądź szczery. Jeśli funkcja otrzyma dane wejściowe, określ, czego dokładnie może się spodziewać, ile powinna się spodziewać i jak powinna działać w sytuacjach błędów.
Nie zapomnij określić limitów. Wszystko ma swoje granice. Jeśli Twoje rozwiązanie ma zarządzać konta ile powinno być w stanie obsłużyć? 20 czy 10 milionów?
Twój dokument wymagań powinien zawierać wymagania funkcjonalne, a nie Wymagania funkcjonalne. Nie funkcjonalne wymagania to: wydajność, stabilność, wykorzystanie zasobów, Bezpieczeństwo i tak dalej.
[2] Kiedy skończysz określać wymagania, nadaj każdemu wymaganiu ocenę ważności: must have, important, optional.
[3] Teraz napisz dokument, w którym określisz, jak co wymagania zostaną wdrożone. Uważaj na szczegóły. Nie wchodź w głąb. Zasada 20/80. Określ 20% funkcjonalności, co wpłynie na 80% rozwiązania.
Prawdopodobnie zauważysz, że nie możesz opisać, w jaki sposób każde wymaganie zostanie wdrożone. Można napisać "nie mam pojęcia jak to wdrożyć". Ale ważne jest, abyś to zapisał! Ilość "Nie wiem" powie Ci, jak ryzykowny jest Twój projekt.
[4] Na następnym krokiem jest utworzenie listy zadań. Musisz wiedzieć, co właściwie musisz zrobić. Dla każdego wymogu będziesz miał kilka zadań do wykonania.
Jednym z tych zadań jest dowiedzieć się, jak wdrożyć wymagania "Nie wiem". Nie próbuj wyjaśniać KAŻDEGO "Nie wiem". Wybierz coś, co musisz mieć i to, co ważne. Wyjaśnienie niektórych z "Nie wiem" może być nawet mini projekt sub.
[5] Gdy masz swoje zadania oszacuj czas potrzebny do ich wykonania. Nie wstydź się oceniać. Nie jest możliwe dokładne oszacowanie, gdy jesteś na początku projektu. W miarę rozwoju projektu ponownie oszacujesz zadania, a szacunki staną się bardziej dokładne.
Bardzo mi pomogĺ ' o dokonaÄ ‡ tzw. trzech punktĂłw szacunkowych. Oszacuj czas, którego potrzebujesz, jeśli wszystko pójdzie dobrze. To jest Twój optymistyczny czas. Następnie oszacować, jak długo to zajmie, jeśli napotkasz problemy. To Twój pesymistyczny czas. Następnie oszacuj realistyczny czas. Rozpiętość między optymistycznym i pesymistycznym czasem powie Ci, jak niepewny jesteś co do realizacji.
[6] Teraz trzeba będzie przynieść zadania w kolejności będą one realizowane. Niektóre zadania będą miały zależności, które twoje zamówienie będzie musiało odzwierciedlać. Istnieje bardzo dobre narzędzie, które pomoże Ci zwizualizować to zamówienie: Twoja ściana biurowa. Napisz swoje zadania na post-its i umieść je na ścianie. Poważnie. Bardzo dobrze mi to wyszło.
[7] Teraz jesteś już w środku twojego projektu. Suma Twoich szacunków da ci dwie daty wydania (optymistyczną i pesymistyczną). Możesz ustawić kamienie milowe. Okresowo Aktualizuj szacunki dla swoich zadań. Zmiana obliczonej daty premiery powie Ci, jak ci idzie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-17 21:18:11
Wszystko to powinno pochodzić z dokumentu wymagania projektowe, to pozwoli Ci wiedzieć, które funkcje są rzeczywiście wymagania i które funkcje zostały dodane w Scope creep. Upewnij się, że wdrożysz to, czego chcą.
Moja rada zawsze rozmawiaj z osobą, której musisz dostarczyć projekt, wymyśl harmonogram, kiedy będziesz miał ważną funkcję x ukończoną przez. Aby dowiedzieć się, co należy zrobić, należy rozpocząć od dokumentu wymagań i dla dużych projektów (i małych) priorytetów Ustaw, na którym zadaniu powinno być dostarczone jako pierwsze.
Talk talk talk jest najlepszym sposobem, aby upewnić się, że wszyscy wiedzą, co się dzieje przez cały czas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-09 16:05:57
Oczywiście chcesz rozbić go na mniejsze kawałki, pamiętaj, wykonując WBS (Work Breakdown Structure), aby nie tylko rozbić go na mniejsze kawałki, ale także:
- Określ, nad którymi elementami będą pracować jako pierwsi (ustal priorytety najbardziej ważnych dla biznesu)
- plan na dostawę, wiele projektów dostarczyć kod, ale potem mają trudności w promowaniu, zaplanować, jak każda wersja zostanie dostarczona i potencjalnych skutków dla użytkowników
- Zrób coś wcześniej/szybko - nic nie buduje pewności siebie tak jak wczesna wygrana
- opracuj swój plan komunikacji-kto musi wiedzieć co i kiedy-Ex: dla każdego wydania iteracyjnego, kto musi być powiadamiany o zmianie/wpływie
- Określ, czy będziesz ponownie oceniać opinie podczas wydań, aby określić, czy kolejność dostawy lub funkcjonalność zostanie zmieniona
- zdaj sobie sprawę, że im szybciej wydasz na produkcję, tym szybciej będziesz musiał ją wesprzeć i kontynuować rozwój
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-11 18:01:59