Witam.

Chciałbym prosić o poradę osoby, które już brały udział w realizacji jakichś większych projektów.

Okoliczności w jakich tworzony jest program:
- jeden główny programista, może dwóch takich mniejszych,
- jeden grafik odpowiedzialny za Layout,
- około dziesięciu osób (przyszłych użytkowników) definiujących wymogi systemu
- program ma powstać na początku w minimalnej formie, przeznaczony do testów i później ma być sukcesywnie ulepszany

Ja mam taki pomysł na to:
1. Pracę programistów i grafika "koordynować" za pomocą CVS'a
2. Stworzyć specyfikację wymagań i projektu w systemie Wiki i dać do niej dostęp wszystkim osobom definującym wymogi systemu.
3. Uruchomić jakiś system śledzenia bug'ów pomocny na etapie testowania systemu.

Jeśli chodzi o punkt 1 to niemam żadnych wątpliwości.

Punkt 2 to taki mój pomysł nie poparty doświadczeniem, ale z tego co się zorientowałem to dokumentacja w "systemie" Wiki będzie pozwalała w łatwy sposób wprowadzać zmiany lub propozycje zmian do już istniejących założeń i wymogów systemu. Myślę tutaj o projekcie PhpWiki - może polecicie coś wg was lepszego.

Punkt 3 to sprawa oczywista poza wyborem konkretnego rozwiązania stworzonego w php, myślę o Mantis ale też prosiłbym o polecenie czegoś wg was lepszego.

Przypominam, że poszczególni członkowie biorący udział w tworzeniu aplikacji nie mają ze sobą bezpośredniego kontaktu.

Planuje to wszystko po to, by maksymalnie jak się tylko da usprawnić pracę nad tym systemem. Wiadomo - czas to peniądz

Może wg was pominąłem jakieś ważne aspekty takiego przedsięwzięcia - z radością poczytam o dodatkowych etapach/rozwiązaniach, które jeszcze bardziej usprawnią tego typu pracę.[/b]

zamiast mantisa proponuje bugzille. Proponuje szczerze, od serca i uczciwie sam uzywam, i co kazdy moze potwierdzic zachwalam zawzdy i wszedzie Bo system to potezny i niezwykle sprytny, o czym sie przekonasz jak zaczniesz uzywac

Dzięki za dobrą radę, napewno skorzystam.

Odnoszę wrażenie, że mógłbyś się szerzej wypowiedzieć na temat tego wątku i nie ukrywam, że byłbym bardzo wdzięczny za to.

Ja dopiero będę tworzył pierwszy większy projekt i chciałbym to zrobić jak najlepiej już od samego początku dlatego staram się zaplanować nawet sposób pracy nad nim, ale niestety niemam doświadczenia a to co opisałem to tylko moje domysły. Przydały by się jednak jakieś słowapoparcia od człowieka, który ma w tej kwestii doświadczenie

Także, jakbyś miał chwilę i mógł udzielić jakichś ciekawych rad czy wskazówek to będę bardzo wdzięczny

pozdrawiam

edit...
http://www.softax.pl/prywatne/marcink/narz...rzedzia_bugewid - ciekawy art i ciekwa stronka, polecam

cytat z opisu Bz jaki podawalem na wewnetrznym forum dev:

Dzis zajme sie problemem pierwszym, bowiem do kolejnych potrzebuje waszej pomocy.

Bugzilla jest mocno robudowanym systemem zarzadzania zadaniami i bledami. Generalnie w wersji podstawowej (oczywiscie mozemy to modyfikowac) posiada brzydki layout i toporny, ale funkcjonalny interfejs.

spojrzcie na:

1) http://bugzilla.mozilla.org - wzrocowy przyklad. Ogromna baza, setki tysiecy bledow i zgloszen. Swietnie zarzadzana.
2) bugs.kde.org - ladniejsza, funkcjonalna
3) bugs.redhat.com
4) inne na bugzilli (setki!)
5) bugs.firefox.pl - moja Smile

I moze na tej ostatniej sie skupmy, bowiem jest poczatkujaca, malutka i latwiej bedzie pewne procesy tlumaczyc.

Nie musicie sie logowac.

Patrzac od prawej:

Requests: to nas na razie nie interesuje
Reports: to tez
Search: wyszukiwanie bledow. Mam swiadomosc, ze na pierwszy rzut oka wyglada na chaos. I troche w tym racji, jednak ma ogromne mozliwosci, a zruzmiecie gdy omowimy pojedynczy blad.
New: zglaszanie nowego bledu

Spojrzmy zatem na przykladowy blad aby omowic dzialanie systemu.
Najpierw sprawa organizacyjna.

Problem polegal na tym, ze po przetlumaczeniu aplikacji nalezalo podeslac autorom paczke z tlumaczeniem.
http://bugs.firefox.pl/show_bug.cgi?id=21

Sproboje po kolej opisac ten blad:

Bug ma swoje ID, i mozna mu przypisac alias. Stosuje sie w to w przypadku bledow "ciagnacych sie" i waznych. Kazdy blad jest przypisany do jakiegos produktu i komponentu tego produktu. Produkty i komponenty sa ustalane i tworzone przez administratora. Chodzi o jasny podzial obowiazkow.
Status i resolution opisuja aktualny stan bledu i rozdzaj rozwiazania zastosowowany przez opiekuna bledu.
Hardware, OS, Version i Priority opisuja blad, okolicznosc wystepowania i dokuczliwosc bledu.

Analogicznie oczywiscie te pola dotycza zadan. Okreslamy zakres wystepowania zadania, jego dotkliwosc (zmiana znaku w tekscie jest mniej wazna niz pad dysku). Version odnosi sie do produktu oczywiscie.

Target milestone okresla wlasciciel/opiekun bledu w momencie przyjecia na siebie obowiazku jego rozwiazania. Oznacza ono date prawdopdoobnego rozwiazania problemu.
Reporter, to oczywiscie zglaszajacy, ktory do konca pracy z bledem dostaje maile z informacjami o zmianach w nim zachodzacych, a inni uzytkownicy zainteresowani bledem dopisuja sie do listy CC.


Assigned To oznacza osobe bedaca tzw. wlascicielem bledu. Taki czlowiek ma swiety obowiazek doprowadzic blad do konca i bugzilla nie pozwoli mu o tym zapomniec. Smile
Q&A (Quality And Assurance) to osoba odpowiadajaca za konrole jakosci rozwiazania bledu. Jesli to patch, to Q&A go sprawdza, jesli zadanie, to Q&A sprawdza i tak dalej.
Ta wlasnie osoba nadaje status verified dla bledu.

Zalaczniki. To oczywiscie lista plikow dolaczanych do bledu. Moga to byc patche, diffy, obrazki, zipy, rary,teksty... wszystko. Nowy plik moze nakladac sie na stary (obsolete).

depends on i blocks. To lista bledow od ktorych dany blad zalezy (np. zadanie napisania klasy Postgresqla nie moze zostac zrealizowane poki nie zostanie zrealizowane zadania napisania abstrakcyjnego interfejsu bazy danych), i w druga strone. Lista bledow jakie ten blad blokuje.

Ponizej macie pole dodania wlasnego komentarza, i zalogowani maja mozliwosc zmiany ststusu bledu.
Generalnie jednak status powinien zmieniac wlasciciel lub qa. Ewentualnie zglaszajacy.

Na koncu macie liste komentarzy dotyczacych bledu.

Warto przeczytac: http://www.mozilla.org/bugs/

Generalnie jednak cykjl zycia jest taki:

(kiedy sami rozdajemy zadania)
- ktos zglasza problem i przypisuje go komus (lub jest on przypisywany domyslnemu wlascicielowi danego komponentu
- ow wlasciciel go przyjmuje lub nie, lub przenosi na innego
- docelowy wlasciciel w momencie zajecia sie praca zmienia status z NEW na ASSIGNED i potem zamyka jako RESOLVED, INVALID, WONTFIX, REMIND, WORKSFORME
- Q&A daje Verified lub Reopened

jesli zas zglasza uzytkownik z zewnatrz najpierw bug otrzymuje status UNCONFIRMED i zostaje potwierdzony po spelnieniu pewnych warunkow.

W tym co napisalem pominalem 4 wazne rzeczy:

1) Keywords. Kazdy blad/zadanie moze miec slowa kluczowe pomogace znalezc odpowiednie bledy odpowiednim osobom. Np., bledy w ktorych wymagana jest ingerencja grafika moga miec keyword [grafika]. Te ktore sa trudne moga dostac [helpwanted] itp. Liste slow ustalamy sami
2) status. Tutaj dopisujemy teksty, ktore nigdzie indziej nie pasuja, a sie przydadza Smile
3) Votes. Mozemy ludziom dac szanse glosowac na bledy, aby pomogli nam wybrac te najbardziej ich dreczace i ustawic im priorytet.
4) blad moze zostac uznany jako DUPLICATE innego, jesli powtarza go. Wowczas nalezy pobic tego kto wyslal duplikat (duplikaty to istna meczarnia w duzych projektach) i oznaczyc duplikat. Zglaszajascy zostanie dodany do cc orginalnego bledu i zycie toczy sie dalej.

Generalnie polowa z tych rzeczy przyda sie dopiero gdy bedziemy mieli jakis produkti i uzytkownikow do obslugi, ale kilka juz chyba mamy: forum, strone itd...

Sa jeszcze tak zwane meta bugi, czyli bledy nie rozwiazujace nic, ale pomagajace sie odnalezc. Np. meta blad "sprawy prawne" nie ma wlasnego rozwiazania, ale doczepia sie do jego depends on bledy konkretne, a prawnicy moga latwo sprawdzic co juz jest zalatwione, a co nie i gdzie pomoc.

W skladni komentarza kluczowe sa "Comment XX" oznacza komentarz XX w tym bledzie i linkuje do niego. "bug YY" oznacza blad YY i linkuje do niego.

Wielkie dzięki, pomocny tekst ale.......... ja chcę więcej więcej więcej

A co byś powiedział na temat punktu 2 z mojego pierwszego posta ?
Pytam o sam pomysł, czy podobnie się to robi czy sa może jakieś lepsze sposoby organizacji wspólnej pracy nad specyfikacją ?

Odczułem poważną potrzebę dostępu do działu dev

luka: mysmy to robili online na spotkaniu w ten weekend i powiem Ci szczerze, ze nie widze zadnej mozliwosci zrobienia tego przez net.
To by trwalo latami, a tak zajelo tylko dwa dni i troche piwa.

hmm, szkoda, będę musiał spróbować tego tak jak to sobie wymyśliłem, zobaczymy jak to wyjdzie - innego wyjścia niemam

Niestety - pewnych rzeczy przeskoczyć się nie da.
Jednym z takich progów jest właśnie kontakt osobowy, przynajmniej z gronem klientów.
Prawdę mówiąc nie wierzę w to, by osoby nie będące programistami/informatykami były wstanie samodzielnie (bez osobistej pomocy jakiejś osoby z branży) przygotować specyfikację swoich oczekiwań. Nawet w sytuacjach gdy dochodzi do wielu spotkań - nie jest to łatwe, bo ludzie mają niesamowitą skłonnośc do zapominania o 'takich nieistotnych dla programisty elementach' typu: normalnie vat jest 21%, ale..... może być i 7 i zero i .... To się zdaża zawsze - a w przypadku gdy pozostawisz ich samych sobie, i powiesz: 'proszę spisać specyfikację', (zauważ, że przy 10 osobach pojawią się problemy typu: kto jest za co odpowiedzialny) nie będąc ich w stanie nawet osobiście do tego zmotywować (wiadomo - ładne uśmiechnięcie się do pani Marysi potrafi zdziałąć znacznie więcej niż nawet najbardziej elkowenty mail...) tych problemów będzie znacznie więcej.

Dlatego na tym poziomie, o ile to tylko możliwe - nie należy oszczędzać. Jest to znacznie ekonomiczniejsze, niż ostatecznie niezadowolony klient.
Bo tak jak napisał Gandalf - nic nie zastąpi "burzy mózgów"
Natomiast nie powinno być większych problemów na poziomie programowania - z uwagi na to, ze tym ma zajmować się jedna, góra 2 osoby - jak napisałeś. Ważne jest jednak bardzo dokładne przydzielenie zadań, oraz skuteczny system rozliczania.

Hej,
no więc....
ja tak tylko co do negocjowania prac itp...
otóż
po pierwsze, zawsze starajcie się ograniczać kontakty z firmą klienta do dwóch, góra trzech osób , czyli prezes (NUMBER ONE ) , osoba odpowiedzialna za realizacje projektu w tej firmie (NUMBER TWO ) i sekretarka ()
a to dlaczego.... wspomniana juz burza mózgów ma jedynie wtedy głębszy sens (moim zdaniem) gdy prowadzona jest przez osoby znające główne założenia do projektu i osoby znające choć trochę tematykę rozwiązania. Często zdarza się (głównie w polsce, chociarz zmienia się to bardzo szybko), że w firmie dla której wykonujecie swoją pracę znajduje się wiele chętnych rąk do pomocy albo nie ma żadnych. Tych wiele chętnych rąk pojawia się wtedy gdy zadanie to w firmie jest premiowane a ich brak gdy nie jest i dlatego zawsze starajcie sie odnależć dwie pary rąk (prezes i osoba odpowiedzialna za projekt, ewentualnie spec IT) i trzecią (sekretarka ). Zdarzało mi się (i ciągle się zdarza ) że w firmie jest menadżer od wszystkiego (mam klienta gdzie jest menadżer nawet od zasobów BHP i higieny itp) i wtedy jest istna paranoja i zachowanie odpowiedniego stosunku osób uczestniczących z tej firmy w projekcie do ich wiedzy i zaangażowania moim zdaniem bywa kluczowy.
Po drugie, team własny team . To jest bardzo ważny element całości, to wyrabia się latami, i nie można stwierdzić po 2,3 pracach że sie ma team , można po 20 tak, wtedy się zgadzam , jeżeli wypracowaliście 20 prac razem to jesteście teamem
ale na podstawie swoich doświadczeń jestem pewien że wskazówki niżej spisane mogą Ci coś pomóc:
- środek komunikacji - osobiście obecnie używamy serwera IRC-owego i forum i jest to środek na obecnym etapie wystarczający (no i zjazdy dev),
- środek pracy nad projektem - dla mnie odpowiednio rozbudowany CRM i CVS(czy jakkolwiek to nazwać) daje ogromne korzyści w późniejszym czasie (wyciąganie wniosków z prac, zbieranie raportów -> kto się opierd... a kto nie
- umiejętny podział obowiązków i zasada jawności wszelkich rozmów między członkami projektu - kluczowa sprawa, trudno mi jednoznacznie coś w tym temacie doradzić ale jestem przekonany że elementy takie jak umiejętny podział prac nad projektem, brak rozmów "na boku" i temu podobne są kluczowymi elementami w tym temacie.
Po trzecie, pamiętaj że ty jesteś wodzem . To jest bardzo ważne, w teamie musi być wyraźny przywódca, można go nie lubić, można się z nim kłócić, można go ubustwiać za premie ale podstawą jest to że ten człowiek jest wyrazisty, że ma siłę przebicia, że potrafi dosadnie wyrazić swoje zdanie, dosadnie kogoś "wyprostować" itp, w tym temacie sądze że najlepszym elementem będzie polecenie ci odpowiednich książek o sztuce negocjacji, sztuce budowy własnego teamu, sztuce prowadzenia wojen z konkurencją, dla mnie podstawowym autorem w tej tematyce jest prof. Krzysztof Obłój którego autorstwa książki szczerze polecam, ostatnio zaczytałem się również w książce "Sztuka wojny" (w tytule były też jakieś chińskie słowa, za brak ich przepraszam w którą zaczytałem się ostatnio w trafficu (taka z biało -czarno okładką) .
Po czwarte praktyka nie ma skutecznego środka, widzisz, przytocze przykład osoby która w temacie negocjacji jest khmm... jakby to określić, powiem tyle że jej klienci to największe S.A. w polsce i jest ich bardzo dużo, człowiek ten od nie pamiętnych czasów (pewnie z ponad 20 lat -nigdy się nie pytałem) uczy się tematyki negocjacji w każdej chwili, na targu, z inkwizytorami (hihi kiedyś jednego męczył z godzine, on juz ucieszony że coś sprzeda a mój znajomy zadał jedno pytanie i było po sprawie , z policjantami jak go zatrzymają (bardzo dużo porusza sie po polsce) każdą okazje wykorzystuje, i to mi kiedyś uświadomiło że w tym temacie dopiero za kilkanaście lat będe mógł coś więcej doradzić
Pozdrawiam patS.