Projekt zespołowy

Projekt Zespołowy

Ten przedmiot ma na celu zapoznanie studentów z faktycznym "życiem" projektu w czasie jego trwania. Zadanie jest jedno: należy wykonać pewien zaplanowany projekt, który może polegać na wytworzeniu oprogramowania lub metod informatycznych, lub, po uzgodnieniu, jeszcze na innym celu. Grupa studentów w liczbie od 2 do pięciu pracować nad takim projektem może przez okres jednego semestru, samodzielnie określając metody pracy i obserwując ich skuteczność. Na końcu dochodzi do podsumowania i oceny, którą sami zainteresowani wykonują w formie raportu końcowego. Poniżej opisane są moje wymagania co do treści tego końcowego raportu. Raport składa Project Manager wyłoniony z danej grupy podczas początkowych zajęć na starcie semestru.

Termin oddania projektu i raportu

Zalecam oddanie dokumentów w komplecie jeszcze w czasie trwania semestru. Jeżeli nie zdążycie, należy przysłać mi je w trakcie sesji, nie później, niż z do końca stycznia. Przysłanie dokumentów PO czasie, a więc w lutym, nie pomaga. Z chwilą gdy na kalendarzu pojawi się data 1 lutego, wasze oceny zostaną wpisane do protokołu i temat zostanie zamknięty. Jeżeli nie otrzymam raportów, ocena będzie oczywiście negatywna. W przypadku przesłania prawidłowo raportu, ocena zależy od tego, co w nim napiszecie.

Co podlega ocenie

Nie było mnie podczas powstawania waszych projektów. Nie szkodzi. To co mnie interesuje, to WASZE ZROZUMIENIE PROCESU, w jakim działaliście. Należy skupić się na JAKOŚCI pracy, PRZEBIEGU pracy, prawidłowym lub nieprawidłowym jej WYKONANIU, i na dotarciu do PRZYCZYN problemów. Interesuje mnie wasz POZIOM KONTROLI NAD PROJEKTEM, fachowość, ODPOWIEDNIOŚĆ ŚRODKÓW i reakcji w stosunku do wynikających z życia zmian i WASZA OGÓLNA EFEKTYWNOŚĆ. Rzetelne, szczere opisy działania sięgające głęboko do PRZYCZYN sytuacji, które was spotkały będą oceniane lepiej niż opisy zrobione na odwal i po łebkach. Ocenie podlega zatem tak złożony system, że nie ma tu prostej recepty na punkty lub procenty. Każdy zespół jest unikalny i przeszedł długą drogę, za każdym razem inną. Wasze opisy pomogą mi ustalić waszą wiarygodność, a dostarczona dokumentacja techniczna wraz z historią projektu potwierdzi to, co w ocenach napisaliście o samych sobie. Należy opisać wszystkie zauważone trudności i załamania, wykryć i przeanalizować ich przyczyny i udowodnić mi, że reagowaliście w możliwie najlepszy w danej sytuacji sposób. Mimo to moja ocena pozostanie w jakimś stopniu arbitralna i z tym trzeba się pogodzić.

Jak przygotować raport końcowy

Raport należy zrobić tylko w przypadku, gdy grupa pracowała samodzielnie nad projektem, i NIE była zaangażowana w projekty zlecane przez firmy zewnętrzne. W przypadku gdy studenci wykonywali prace projektowe dla firm w ramach stażu lub innej zaakceptowanej formy współpracy, należy postąpić inaczej. Zobacz ostatni rozdział w tym dokumencie. Postali piszą Raport Końcowy. Raport Końcowy jest tym rodzajem dokumentu (a raczej zestawu dokumentów), na podstawie których oceniona zostanie Wasza praca. Należy zatem solidnie przyłożyć się do przygotowania odpowiedniej dokumentacji, aby zasłużyć na dobrą ocenę. Część dokumentów przygotowuje każdy członek zespołu, a część może zrobić tylko zarządca projektu.

Składniki raportu

Wszystkie pliki i elementy projektu muszą być dostarczone w postaci pliku archiwum o nazwie pz2016-[nazwa-projektu].zip (lub tar.bz2 lub tar.gz). Projekt ma być spakowany w taki sposób, aby stanowić kompletne źródło nadające się do ponownego podjęcia pracy nad nim. Jeżeli w skład projektu wchodzą serwery takie jak np. apache lub inne powszechnie dostępne komponenty, nie trzeba ich dołączać, chyba, że jest to wymagane ze względu na kompatybilność z jakąś szczególną wersją, itp.

Źródła i zasoby
Należy spakować źródła projektu, pliki graficzne, dokumenty tekstowe, i wszystkie inne zasoby, jeżeli takie zostały wygenerowane. Ma to być kopia z ostatniego dnia pracy nad Waszym projektem. Możliwe jest także dołączenie wersji typu 'release' lub innych, zależnie od tego, co uznanie za stosowne. Źródła powinny być opisane w taki sposób, aby było jasne gdzie się znajdują, i którą wersję projektu reprezentują. Opis ten musi umożliwiać przejęcie pracy przez inny zespół. Tak samo w przypadku testów lub przykładów stosowania: należy przygotować je w taki sposób, aby było jasne, jak i co testują testy, oraz jakich wyników należy się spodziewać. Format plików: zależny od projektu; w przypadku projektów webowych warto spakować drzewo wprost z serwera, dorzuć dumpy baz danych i nie zapominać o opisie procesu stawiania oraz instalacji serwisu.
Historia projektu i harmonogram
Należy przygotować jednolity dokument z podsumowaną i opisaną historią projektu i harmonogramem pracy. Jeżeli jest to log z repozytorium, należy uzupełnić go o dokładniejsze opisy najważniejszych operacji na źródłach, uwzględniające harmonogram lub odstępstwa od niego. Wskazane jest także dołączenie historii spotkań, wszystkich raportów cząstkowych (jeżeli były wysyłane) lub notatek i wewnętrznej korespondencji, w taki sposób, aby można było zorientować się w przebiegu pracy nad projektem. Kreatywna księgowość zostanie wykryta i obniży wiarygodność całego raportu (i w efekcie wasze oceny). W historii projektu należy napisać tylko to, co było planowane i co faktycznie się wydarzyło lub czego nie udało się zrobić. Ocenę tego typu osiągnięć trzeba zrobić w innym dokumencie. Format plików: dokument ODF, PDF lub HTML, może być także zwykły tekst, kodowanie utf8.
Krzyżowa ocena zespołu
Każda osoba w zespole robi ocenę i opis wszystkich osób w zespole (włącznie ze sobą, co zwykle jest najtrudniejsze). Chodzi o analizę pracy, spostrzeżenia dotyczące obowiązkowości, sumienności, jakości pracy i terminowości realizacji zadań. Możecie przeanalizować sposób działania swój oraz innych, i spróbować wyciągnąć wnioski z dostrzeżonych mocnych i słabych stron. Tego typu opis powinien być napisany w formie podsumowania plusów i minusów, który NIE MA celu podniesienia oceny, tylko dogłębną analizę stanu faktycznego. Interesuje mnie w tym raporcie jak bystro i dogłębnie rozumiecie procesy, które działy się podczas pracy nad projektem. Rzetelność tej analizy zależy od tego, ile uda się Wam zobaczyć i zrozumieć. I to podlega ocenie. W raportach należy jednakże unikać spraw osobistych, których nie chcielibyście wywlekać na światło dzienne. Formaty plików takie same, jak dla harmonogramu i historii.
Podsumowanie PMa
Project Manager, jako 'szef' zespołu powinien przygotować od siebie jeszcze jeden krótki dokument, w którym podsumowuje pracę całego zespołu w trakcie semestru. Chodzi o krótki tekst zawierający najważniejsze spostrzeżenia, wnioski i opinie na temat wykonanej pracy, oraz subiektywną ocenę osiągnięć zespołu. Czy było fajnie, ciekawie, trudno, lub do bani. Co można by zmienić. Takie 'ostatnie słowo', w którym można dodać wszystko to, co może jest ważne, a czego nie zawiera raport. Jest to też dobre miejsce na abstrakt, streszczenie, podsumowanie całości. Także ten dokument jest ważny i należy o nim pamiętać. Format: TXT z utf8. W zależności od uznania PM może zlecić swoim ludziom w zespole przygotowanie i opracowanie dodatkowych dokumentów, nie wymienionych w moich wymaganiach.

W przypadku pracy w firmie

Osoba koordynująca prace zespołu jest przeze mnie proszona o dostarczenie następujących informacji na piśmie - może być mailowo z adresu firmowego pracownika (część z nich mogą uzupełnić sami studenci, np. numery albumu):