Koraci za razvoj aplikacije i njeno instaliranje

poruka: 9
|
čitano: 4.059
|
moderatori: Lazarus Long, XXX-Man, vincimus
1
+/- sve poruke
ravni prikaz
starije poruke gore
13 godina
neaktivan
offline
Koraci za razvoj aplikacije i njeno instaliranje

znam da tu ima na bug forumu vrsnih programera, pa me zanima ak netko moze napisat korake koje trebaju radit 3-5 ljudi za razvoj aplikacije za predavanja i njenu instalaciju. to mi je za seminarski rad. hvala.

roko
 
0 0 hvala 0
11 godina
neaktivan
offline
Koraci za razvoj aplikacije i njeno instaliranje

Jedan od mogucih nacina, koji se pokazao odlican sa timovima koji ga pravilno koriste je agilno planiranje:

 

1. Ispisi user stories - kratke price od par redaka koje kompletno definiraju funkcionalnost aplikacije

2. Igraj planning poker sa developerima i oznaci te price sa bodovima tezine

3. Svaka dva tjedna uzmi story, razbij ga u minijaturne taskove, taskove oznaci potrebnim vremenom (ako task treba vise od 3 dana, razbij ga u manje dijelove) i podijeli taskove ljudima dok svatko nema 8 dana posla (2 tjedna * 5 radnih dana - dan planiranje - dan debugiranje)

4. Napisi testove za svoj task i pisi kod dok ne zadovoljis testove

5. Loop od 3-5

 

 

Ibanez RG1527 * Mesa Simulclass 2:90 * Mesa Triaxis (4th edition) * TC Electronics GMajor * Marshall JCM 1960 * Behringer FCB1010 + UNO mod * iPc + Ubuntu Studio * Van Den Hull D501 silver
 
0 0 hvala 0
13 godina
offline
RE: Koraci za razvoj aplikacije i njeno instaliran

To je kombinacija čega? Agilnog XP-a i TDD-a? Huh :|

Zvuči zgodno. Provjereno?

Jer, koliko god zgodno zvučalo, čini se nekako nestabilno.

Hrvatska je oligarhijska partitokracija s primjesama patokracije.
Poruka je uređivana zadnji put čet 11.6.2009 13:16 (naxeem).
11 godina
neaktivan
offline
Koraci za razvoj aplikacije i njeno instaliranje

Cisti XP. XP ne postoji bez TDD-a, koji je okosnica stvarne produkcije. Agilno planiranje (da se zadovolje suits je drugi dio).

Provjereno, radi vec preko 5 godina za mene, a manageri se ukljucuju koliko ih volja ili nije - ja pisem unit testove kao i svaki drugi kod i jednostavno to ni ne spominjem kao nesto posebno. Testovi su kod kao i svaki drugi.

 

Prakticno, moram priznat da su i manageri sretni jer napokon sa svojim prposnim debeljuskastim rucicama svaka dva tjedna mogu birati sto im je prioritetnije za izraditi, mogu na osnovu statistike bodovi/iteracije izracunati velocity i odrediti koliko-toliko tocan launch-window i sve ostale divotarije na koje su navikli putem industrijske revolucije, a nikako da shvate da programiranje nije egzaktna znanost kao gradnja mosta.

Ja zadovoljan, oni zadovoljni, ostali devovi zadovoljni... bilo bi mi dovoljno samo to sto napokon devovi odlucuju koliko ce trajat izrada nekog taska.

 

Objasnit  cu u vise detalja ako treba.

Ibanez RG1527 * Mesa Simulclass 2:90 * Mesa Triaxis (4th edition) * TC Electronics GMajor * Marshall JCM 1960 * Behringer FCB1010 + UNO mod * iPc + Ubuntu Studio * Van Den Hull D501 silver
Poruka je uređivana zadnji put čet 11.6.2009 14:44 (Deus ex machina).
 
0 0 hvala 0
13 godina
offline
RE: Koraci za razvoj aplikacije i njeno instaliran

Pa konkretno me zanima kako pretpostaviti trajanje izrade? Niti je svaki programer jednako brz niti je lako predvidjeti probleme i zastoje kojih uvijek ima bez obzira na iskustvo i znanje tima.

Hrvatska je oligarhijska partitokracija s primjesama patokracije.
11 godina
neaktivan
offline
Koraci za razvoj aplikacije i njeno instaliranje

Trajanje se odredjuje onda kad se story razbije u taskove, odnosno kad dodje vrijeme da team implementira storye. Sve se radi timski, pa tako i odluke o tome koliko nesto moze trajati. S obzirom da se ciljaju taskovi koje vise-manje svatko moze procjeniti da li ih moze rijesiti u dan ili dva, malo je mjesta za pogresku. Normalno, nepredvidjene situacije se adresiraju kao takve svako jutro, tako da se moze odluciti sto dalje... npr. isplati li se jos vremena odvojiti za task, da li je potrebno popricati s nekim drugim devovima, u timu ili u firmi, upariti dva deva u pair za taj task, proslijediti task nekome drugome. Ovako nalistano sve to zvuci dosta birokrativno, ali se u principu odvija dosta prirodno. Ja bi volio vise prirodnije, ali project director i project manager su, well, manageri, a oni dobro rade s rutinama pa eto... neki kompromis.

.

Kad odredjujes tezinu nekog user storya planning pokerom, onda devovi kratko razgovaraju o storyu (ali kratko), i onda svatko odabere kartu (alla fibbonaci niz od 1 do 24) i spusti je prema dolje. Kad svi okrenu karte, onda se vidi ili slicnost ili razlika, i obicno je odgovor negdje u sredini. Npr. ako od 5 devova njih 3 spuste 8icu, jedan spusti 3 a drugi 14icu, to najvjerojatnije znaci da ovaj koji je spustio 3 nije razmislio o nekom bitnom segmentu taska i da ovaj koji je spustio 14 ima u glavi nesto sto nitko nema ili nema pojma kako bi to napravio. Onda slijedi razgovor, objasnjava se zasto je tko odabrao te brojeve, objasnjavaju se praznine, neznanja, adresiraju problemi... to traje dok devovi ne spuste brojeve koji su jako bliski jedan drugima - odnosno, svakome je jasno o cemu se tu tocno radi i koliko je to otprilike posla. Bitno je napomenuti da broj ne odredjuje tocno koliko dana traje task, samo tezinu. S obzirom da je niz ogranicen, od 1-24, nekako treba u glavi rasporediti sto smatras jednostavnim taskom a sto epic taskom.

.

U iteracijskim sastancima, svaka dva tjedna, manageri odaberu storye (featureove) koje bi najradije vidjeli u igri, a devovi ih onda razbijaju u taskove i zajednicki dogovaraju tocan posao koji treba odraditi i njegovo trajanje. Nitko ne dobija odredjeni task, vec su svi na taskboardu i svatko uzme sto misli da moze odraditi. Ako je neki task 'mutan' i ne mozemo naci tocno rijesenje, zakaze se design meeting, gdje se igramo CRC karticama, piskaramo klase, procese, komponente, dok ne shvatimo koliko je tu tocno posla, pa onda ponovimo planiranje samo za taj task. Iako se to ne preporuca, obicno sredimo to planiranje odmah sutradan i ostavimo task u iteraciji jer rijetko neki task naraste da bude van dva tjedna posla, koliko god mutan bio. Ako ipak naraste, onda uzmemo storye koji su primarni ili temeljni, oni idu na plocu a ostali taskovi za slijedecu iteraciju.

.

Neki put ti treba vise vremena, neki put krace, neki put ubijes dvije muhe jednim udarcem pa se u nekoj statistici lagovi u taskovima izjednace. Bitno je da kroz nekoliko iteracija mozes odrediti koliko user storya tim moze odraditi u 2 tjedna, zbrojis one bodove tezine s pocetka price - to je brzina tima. Ako podijelis zbroj svih preostalih storya sa velocityem tima, dobit ces ugrubo launch window, ako si normalan uzet ces nekih 30ak% pogreske u plus i minus, ali i to je vec dovoljno precizno.

.

Onda, ako ti to ne odgovara, razmisljas sto ces dalje. Osnovno pravilo je 'cutting is shipping', pa neke storye ostavljas za kasnije, ali ako nisi na kraju projekta mozes pridruziti vise ljudi projektu.

.

Izmjene koje smo mi nekako prirodno pridodali sistemu je da na sastancima obicno odredjujemo best-case scenario za taskove, jer smo vec dovoljno duboko u projektu da neka design pogreska iz proslosti moze napraviti pravi mayhem, a refactoring moze biti i dugotrajan i bolan. Takodjer nekako prirodno je ispalo da cijeli story pripadne jednoj osobi - iako sam ja protiv toga, ispalo je kratkorocno da jedna osoba brze odradi sve taskove za story sama nego da dijeli taskove s ljudima. Normalno taskovi se dijele ako je netko usred iteracije ostao bez posla a druga osoba je na prvom tasku jos. Pokazalo se na kraju da sam u pravu oko ovoga, jer obavljanje cijelog storya neumitno zadrzava znanje cijelog featurea u jednoj osobi - evo jos uvijek se pilim sa client-side pathfindingom jer je dynamic loading sustav smece kakvo nisam vidio od svojih pocetaka u C++ i WinAPIu - napisano od strane jednog jedinog covjeka koji nije imao sanitycheck da ga zaustavi. Takodjer nam je velocity od pocetka pao drasticno jer smo izgubili jednog clana tima, taskovi su postali premutavi, a manageri nisu razumjeli zasto rijesavanje nekih taskova prije drugih trazi manje posla. Takodjer, dugo nismo imali refactoring iteraciju i neki spageti u kodu se vise ne mogu raspetljati ni za mjesec dana, kamoli za dva tjedna.

Sta ces, niti jedan sistem nije savrsen, ali ja trenutno krivim porazavajuci omjer (studenti, neznalice, lijencine) : (ljudi koji znaju sta rade, ljudi koji rade)

Makar ne crunchamo jer je netko polizao prst, digao ga u vjetar i rekao "We can do that in two years", pa onda imao projekt koji kasni dvije godine.

.

A da, zaboravio sam ti odgovorit na najsladje pitanje sa pocetka :-)

Imali smo i mi diskusija gdje tupis manageru "NEMAM POJMA KOLIKO TO MOZE TRAJATI JER NEMAM POJMA O TOME!" a on ti odgovori "Ma, kako nemas nista, moras imati makar neki feeling koliko to moze trajati". Ima situacija kad nitko nema pojma sto bi trebalo napraviti, ali tu je dobrodosla ta nasa izmjena da se odmah slijedeci dan dva u iteraciji napravi istrazivanje - normalno doda se research task sa svojim vremenom. Ako uspijes u dan dva researcha skuziti sta treba napraviti, onda ide opet brzinsko planiranje za te taskove. Ako ne, ili ako taskovi eksplodiraju odjednom u neke epice, onda to ide za slijedecu iteraciju.

Ibanez RG1527 * Mesa Simulclass 2:90 * Mesa Triaxis (4th edition) * TC Electronics GMajor * Marshall JCM 1960 * Behringer FCB1010 + UNO mod * iPc + Ubuntu Studio * Van Den Hull D501 silver
Poruka je uređivana zadnji put čet 11.6.2009 16:46 (Deus ex machina).
 
0 0 hvala 0
13 godina
offline
RE: Koraci za razvoj aplikacije i njeno instaliran

Vrlo interesantno. Pretpostavljam da imate i sistem dokumentiranja i katalogizacije dokumentacije, s obzirom da se nešto takvo što si opisao teško kontrolira i vodi ako nemaš osobu koja ima big picture u glavu, dok istovremeno držanje jednog storya u glavi jednog programera, ne može završiti uvijek dobro.

Hrvatska je oligarhijska partitokracija s primjesama patokracije.
13 godina
neaktivan
offline
Koraci za razvoj aplikacije i njeno instaliranje

I zaboravio si još navesti refactoring :)

 

A za kvalitetan refactoring ti trebaju i kvalitetniji ljudi. Što ponekad zna predstavljati veliki problem...

 

 

 

 
0 0 hvala 0
11 godina
neaktivan
offline
RE: Koraci za razvoj aplikacije i njeno instaliran
naxeem kaže...

Vrlo interesantno. Pretpostavljam da imate i sistem dokumentiranja i katalogizacije dokumentacije, s obzirom da se nešto takvo što si opisao teško kontrolira i vodi ako nemaš osobu koja ima big picture u glavu, dok istovremeno držanje jednog storya u glavi jednog programera, ne može završiti uvijek dobro.

To je stvar koja mene najvise osobno zivcira - nitko od devova nema big picture u glavi, nego manageri. Malo je demotivirajuci raditi na necemu i ne znati u kojem smjeru ide. Recimo nas projekt je od Diablo-like casual igre (za koju bi dao srcu i dusu) postao kiddie-friendly mmo. Citaj 'retardirani' mmo. Nismo ni skuzili kada se tocno tranzicijia dogodila, jednostavno implementiras featureove, radis gui, paf jedno paf drugo i onda vidis gdje si. Vodeci ljudi su malo istrazili trziste, pomamili se za lovom koju generira Disneyev Club Penguin (koji po meni ulazi u Top 1 najretardiranijih produkta ikad), i malo po malo promjenili projekt.
Uglavnom, imamo dvoje manager-type person: jedna je scrum master - vodi iteracije, iteracijske sastanke, jutarnje sastanke, kalkulira team velocity, kalkulira preostali posao, etc etc etc... drugi manager brije na ruckove sa shefovima, informira ih o stanju projekta, usmjerava projekt...
.
Dokumentacija? Sto je to 'dokumentacija'? :-D
Zaozbiljno, stories i taskovi ti postaju log kako budu zavrseni, a sto se tice devova mi drzimo dokumentaciju po kodu. Tu ideju sam razvio u bivsoj firmi s jednim kolegom, pocelo je od README fileova u source tree pored klasa - sturo objasnjenje cemu komponenta sluzi i kako je zamisljena da se koristi, pa su poceli razni .txt fileovi, screenshotovi UML dijagrama, profiler podaci, etc... imas svu dokumentaciju tocno tamo gdje ti i treba. Dosta prakticna solucija.
.
Programer u glavi ne drzi story - drzi dva tjedna posla. To moze biti jedan story, dva storya, nebitno... bitno je da ukupan zbroj vremena na taskovima koje ima ne prelazi 8 radnih dana (dva tjedna - iteracijski meeting - debug)
Osam dana posla nije puno za zapamtiti, a uvijek imas ostale ljude za konzultaciju.
Ibanez RG1527 * Mesa Simulclass 2:90 * Mesa Triaxis (4th edition) * TC Electronics GMajor * Marshall JCM 1960 * Behringer FCB1010 + UNO mod * iPc + Ubuntu Studio * Van Den Hull D501 silver
Poruka je uređivana zadnji put pet 12.6.2009 8:56 (Deus ex machina).
1
Nova poruka
E-mail:
Lozinka:
 
vrh stranice