Open kpalik opened 10 years ago
Jeśli chodzi o metodykę proponuję coś z Agile np. SCRUM, z małą poprawką ze stand-upy raz na tydzień bo będziemy to robić po pracy. Sprinty dwu lub trzy tygodniowe. Ktoś musiałby przyjąć rolę Product ownera i Scrum mastera. Debaty będą się działy na bieżąco by nie zakopać się w specyfikacji, architekturze i dyskusjach...
Powinniśmy skompletować team 100% samodzielny: Devs, Sysops, Designer, Tester by nie było blokerów, że ktoś nie może czegoś zrobić bo czeka na coś itp.
Ok to kto się zgłasza do zespołu i do ról Scrum Master i Product Owner? Szczegóły metodyki http://pl.wikipedia.org/wiki/Scrum
może byśmy robili jednak częstsze standupy (2x na tydzień wieczorami?)
Ja będę teraz 2 tygodnie nieobecny (4-19 sierpnia) ale przed i po postaram się spisać tyle 'historyjek' ile zdołam. Historyjki oznaczam póki co labelem "enchancement" chyba że na GH jest jakiś inny sposób na oznaczanie i powiązanie historyjek/tasków. Ciekaw jestem jak w GH są rozwiązane sprinty/iteracje - czy to są Milestones'y? Idę się doszkolić.
Jeśli nikt się nie nie zgłosi mogę być Product Ownerem i Testerem, mogę też pomóc w konfiguracji serwera TST/PRD i wrzucaniu kolejnych wersji
Zawsze ktoś będzie niedostępny. Standupy nie zadziałają bo przestaną działać po 3 tygodniach a sprinty się rozjadą bo team będzie miał zmienną ilość czasu więc trudno mu będzie wybrać zadania do sprintu które napewno w nim zrobi. Wg mnie jedyną opcją jest realizowanie prac tak jak to robią inne open source - że zadania po prostu wiszą i kto może ten przypisuje do siebie i robi a wszystko idzie przez kod itp.
Ale czy my nie mamy wcześniej do ustalenia rzeczy które sa ciągle nie ustalone? Skąd będą środki i kto będzie kontrolował co i jak itp? Bo na razie to wszystkie działania utykają zawsze na tym etapie.
siejesz defetyzm :)
Zgadzam się z tym, że pewnie nie uda się utrzymać 'momentum' na dłuższą metę. Jednak 'pobawić' się w scrum zawsze możemy choćby dla jaj :) przydzielenie ról ma też jakieś swoje zalety - będzie na kogo narzekać jeśli się zgłosi do zespołu a potem zawali swoją działkę :).
A co do ustalania - ja mam już dość. Ja nie będę miał czasu żeby działać w strukturach zarządczych więc. Wolę zacząć robić coś konkretnego już teraz. Ewentualne stowarzyszenie, kiedy już powstanie i kiedy pojawią się osoby decyzyjne, po prostu z tego skorzysta, sforkuje albo to oleje i zrobi lepsze. W najlepszym scenariuszu będziemy mieli gotowca zaraz po ustaleniu kwestii formalnych. W najgorszym - będziemy bogatsi o kilka doświadczeń plus nasza praca będzie inspiracją do czegoś lepszego.
Na każdym spotkaniu jest tak, że ktoś musi zacząć :)
Nie pracowałem nigdy z GitHub - czy jest gdzieś opis jak planować taki projekt jak budowa strony? Zakładam, że powinniśmy wybrać sobie jakiś schemat (metodykę) i np. zbudować sobie listę grubych tasków i ficzerów, nad którymi będziemy debatowali i (jeśli znajdzie się chętny dev) pracowali.
Postaram się opisać ogólnie jak sobie wyobrażam stronę i może potem porejestrować to jako osobne taski/ficzery, wraz z propozycjami jak to zrobić - nie bójcie się komentować, poprawiać etykiety, głosować (plusjedynkować), żeby było wiadomo co najbardziej Wam pasuje.
Myślę, że trzeba i tak się spotkać z kimś, kto ogarnia GitHub w obszarze zarządzania wymaganiami, iteracjami, milestone'ami itd, na jakimś Hangoucie. Kto chętny mnie oświecić?