GoldenLine
Zaloguj się
Marcin D.

Marcin D. frontend & backend
developer

Temat: Duże projekty

Jak radzicie sobie z pracą nad dużymi projektami - o ile do takich podchodzicie? Mam na tapecie projekt na który poświęciłem do dnia dzisiejszego ponad 500roboczo-godzin, a specyfikacja określa go na min. 1000! Przy projekcie pracują 2 osoby i raczej nie mam w planach angażowania kolejnych ze względu na koszty.
Link do wypowiedziLink

konto usunięte

Temat: Duże projekty

Z wiekszych, intensywnych projektow bralem udzial w jednym. Pracowalem z 2 chlopakami i bylo fajnie. Pisalismy pod przygotowana specyfikacje, wiec klient dzieki autorom specyfikacji mial ustalone co ma byc zrobione i jak ma wygladac (tak, screenshoty preparowali)

Na poczatku projektowalismy pare dni baze danych (masa gadania i ustalen), potem ustalalismy architekture w jakiej to zrobimy a potem ustalilismy harmonogram modulow do wykonania i kazdy sie za nie bral jak cos skonczyl. Moduly podzielone byly tak, zeby moc skonczyc wazniejsza czesc funkcjonalnosci wczesniej, a pozostale pozniej. Po to by klient mogl juz pracowac na tej gotowej czesci systemu. Wszystko szlo ok.

Wyjatkami byly sytuacje, w ktorych okazuje sie, ze "produkt w zaleznosci od wymiarow moze miec kilka cen a nie jedna" a umawialismy sie inaczej. W takich sytuacjach odchodzilo modyfikowanie baz danych i rozne takie gorace zmiany - malo fajne. Generalnie wygladalo to tak:

Klient -> Firma zleceniodawca (tu byl nazwijmy to program manager) -> 2 Firmy developerskie

Dzieki temu, ze PM byl dobrym stykiem miedzy nami a klientem to udawalo sie wszystko zrobic dobrze.

Link do wypowiedziLink

konto usunięte

Temat: Duże projekty

Jak radzicie sobie z pracą nad dużymi projektami - o ile do takich podchodzicie?


A pytasz o duże projekty w ogóle, czy duże projekty w PHP? :-)

Tak naprawdę prowadzenie dużych projektów w PHP raczej nie różni się od tych realizowanych w jakimkolwiek innymi języku. Może tylko trzeba trochę większą wagę przyłożyć do rozplanowania systemu na moduły/klasy/funkcjonalności/whatever, bo sam język tego nijak nie wspiera. I potem na kontrolę kodu, czy nikt nie uprawia jakiejś radosnej improwizacji - np. ładowania zbyt wielu rzeczy do sesji lub przesadnego wykorzystywania zmiennych globalnych. Ale to i tak trzeba robić zawsze - może tylko przy PHP bardziej.

Mam na tapecie projekt na który poświęciłem do dnia dzisiejszego ponad 500roboczo-godzin, a specyfikacja określa go na min. 1000!


Ja wolę liczyć w osobomiesiącach - myślę, że ok. 6 osobomiesięcy to raczej jeszcze nie jest duży projekt. Ale jest już wystarczający, żeby trzeba było zadbać o specyfikację wymagań, projekt, dokumentację, podział systemu na moduły, jakiś system kontroli wersji do kodu, testy i parę innych rzeczy...

Wyjatkami byly sytuacje, w ktorych okazuje sie, ze "produkt w zaleznosci od wymiarow moze miec kilka cen a nie jedna" a umawialismy sie inaczej.


Znane, znane... Ja myślę, że tutaj jest najważniejsze to, czy klient ma świadomość, że zmiana wymagań pociąga za sobą zmianę:
a/ kosztów
b/ czasu
Jeżeli ma taką świadomość - to jest OK. Jeżeli nie ma - bywa że dochodzi do bardzo nieprzyjemnych sytuacji...

Pozdrawiam, Stasio.
Link do wypowiedziLink
Mariusz Ż.

Mariusz Ż. Programista

Temat: Duże projekty

Na pewno zaczynamy od podpisania umowy z klientem z klauzulą, że za zmiany w specyfikacji dopłaca ;).

A tak poza tym to: tablica, pomysły, generalne rozpracowanie, specyfikacja, dokładniejsze rozpracowanie szczegółów, diagramy UML i projekt bazy, podział obowiązków z przypisaniem roboczo-godzin, ustalenie terminów, praca, testy, wykończenia, pokazanie klientowi, wykończenia, kasa
Link do wypowiedziLink
Andrzej Kozłowski

Andrzej Kozłowski Development Manager,
StepStone

Temat: Duże projekty

To ja może z drugiej strony, czyli jak nie należy podchodzić do dużych projektów. Jakiś czas temu jako programista pracowałem przy realizacji portalu b2b dla dużej firmy państwowej. Niestety kontakt klient-wykonawca oraz kwestia architektury zostały położony na całej linii, tzn.
1) brak sensownej specyfikacji wymagań,
2) zdecydowanie niekonkretna umowa z klientem,
3) polityka gumowego kręgosłupa ze strony wykonawcy, jeśli chodzi o zmianę wymagań przez klienta,
4) początkowy hurraoptymizm project managera,
5) olanie możliwości skorzystania z usług niezłego architekta, który był dostępny i raczej nie miał co robić.
itd, itp.
Finał był taki, że zespół programistów, pracujących przy realizacji, musiał w skrajnych przypadkach po kilka razy przerabiać moduły i cierpliwie znosić joby od pm-a.

Tak więc obiema rękami podpisuję się pod postem Mariusza :]

I jeszcze na deser, żeby nie było, że takie sytuacje są ewenementem - teraz pracuję jako programista dla firmy niemieckiej. Wygląda na to, że dla nich pojęcia "architektura aplikacji" czy też "spójny kod" to bajka o żelaznym wilku, a projekt jest na prawdę duży. I odnoszę wrażenie, że powody są podobne jak przytoczone w poprzednim przypadku.
Link do wypowiedziLink
Andrzej Zawadka

Andrzej Zawadka
Projektant/Programis
ta

Temat: Duże projekty

Ja myślę że radzenie sobie z dużym projektem zależy od tego jaką możemy zastosować metodykę prowadzenia projektu. Jeśli np. mamy bardzo dobrze opracowaną specyfikację wymagań to możemy zrobić dobry poprawny merytorycznie projekt, wiemy po prostu do czego dążymy czego klient oczekuje, wtedy możemy dużo łatwiej oszacować potrzebne zasoby, możemy stwierdzić jakie będą poszczególne etapy prac, oszacować czas ich twania itp. no i co według mnie równie ważne nie potrzebujemy wtedy aż tak dużego wsparcia merytorycznego od strony klienta, bo przecież wszystko już powinno być zawarte w dokumentacji, po prostu siadamy i klepiemy.
Ale jeśli klient sam nie bardzo wie czego potrzebuje to zostaje nam już tylko wtedy jakiś rodzaj programowania ekstremalnego lub prototypowania starając się aby kawałki kodu jakie wykonamy były możliwie często konsultowane z klientem co zaoszczędzi nam niepotrzebnej pracy jeśli się okaże że klientowi jednak chodziło o coś innego niż nam się wydawało. Lepiej żeby się to okazało po tygodniu pracy niz po pół roku. Jasne jest że przy takim sposobie prowadzenia projektu jeśli zawiedzie komunikacja z klientem projekt zostanie położony.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

nasze projekty




Wyślij zaproszenie do
Anuluj