domov / Opomba za hosteso/ Kolektivni razvoj sistemov. Osnove razvoja ekipe

Skupni razvoj sistemov. Osnove razvoja ekipe

3. menu - meni. Izvedeno v obliki seznama, vsak element pa lahko vsebuje podmeni, ki je hkrati seznam. Vsak element seznama mora vsebovati besedilo (pogosto z vroča tipka) in lahko vsebuje ikono 32*32, kombinacijo »vročih tipk« za klic elementa brez vstopa v meni ali simbol 4. Kombinacija ikona+meni = Orodna plošča (Orodna vrstica)

4. kazalci – mehanizem za individualne uporabniške nastavitve. Označeno z majhno puščico v spodnjem levem kotu ikone. Uporabnik lahko konfigurira poljubno število kazalcev v kateri koli mapi in območju.

Razvijalec in arhitekt pri veliki programi- različni ljudje.

Naloga arhitekta je predstaviti vsebino z vidika uporabnika (uporabnost vmesnika). Arhitekt mora ugotoviti uporabnikov tezaver in zagotoviti jezikovno podporo projektu.

Opomba: nemogoče je upoštevati vse zahteve uporabnika, zato so zaželeni elementi Parametri, Storitev, Nastavitve, Konfiguracija - spreminjajo značilnosti programskega izdelka, ustvarjenega za določenega uporabnika. Na primer: barva ozadja, meni, prisotnost vrstice stanja. Na splošno velja, da boljši ko je uporabniški vmesnik, bolj konkurenčen je.

19. Zahteve za programerje. Oblikovanje ekipe programerjev.

Zahteve za programerje in njihovo ocenjevanje

Stopnja izobrazbe

Na zavodu ugotavljajo možnosti

Preverjanje znanja

Povzetek je predstavitev izkušenj programerjev, ki opisujejo njegovo možno uporabo.

Na delovanje vpliva:

Prisotnost človekovih ambicij (lastna ocena lastnih lastnosti in sebe v timu)
Stopnja aspiracije. Samozavest je lahko vir konfliktov v ekipi.
Komunikacijske sposobnosti! ob predaji projekta.

Po izbiri ekipe je naloga vodje, da organizira delo tako, da čim bolj izkoristi profesionalne in osebne podatke programerjev.

20. Organizacija delovnega procesa tima programerjev (osebna organizacija in timsko delo).

Izvaja vodja projekta.

Izkušen vodja vzporedno dela. Obstaja presečišče stopenj.

Za vsako stopnjo je rezultat jasno oblikovan. Če ni rezultata, stopnja ni zaključena.

Dokumentiranje delovnega procesa. Vse, kar je narejeno, je dokumentirano.

Dokumentacija se ustvarja od začetka projekta. Pripravljeno v skladu z GOST (ISO) ali standardi korporativne dokumentacije.

Primerno je uporabljati potni list.

Prednosti pristopa:

1. dokumentacijo ne potrebujejo samo tisti, ki pišejo program, ampak tudi tisti, ki delajo v bližini, tj. prisiljeni uporabiti vaše rezultate.

2. dokumentacija odraža trenutno stanje dela na projektu

3. ob zaključku projekta je potrebno minimalno truda pripraviti dokumentacijo za prenos na stranko.

Organizacija osebnega dela programerja

Vodja programerju načrtuje delo, oblikuje bistvo dela in roke. Dnevno samoporočanje o opravljenem delu omogoča vodji boljše načrtovanje delovni čas programer Pisanje samoporočila traja od 15 do 30 minut na dan, vendar disciplinira programerja in daje vodji možnost, da prerazporedi delo, da bi prišel pravočasno.

Večji kot je projekt, pomembnejše je delo vsakega programerja posebej in pomembnejša so vsa orodja, s katerimi lahko nadziramo potek in izvedbo dela.

Organizacija timskega dela

Usklajevanje timsko delo pomeni informacijsko interakcijo med vsemi udeleženci v procesu, tj. Vsaka oseba, ki sodeluje pri ustvarjanju sistema, bi morala imeti možnost prejemanja informacij o kakršnih koli oblikovalskih odločitvah.

"Delovni zvezek". Vse oblikovalske odločitve so dokumentirane v delovnem zvezku. Včasih je velikost vseh delovnih zvezkov za projekt dosegla debelino 1 m.

Ideja delovni zvezek je podprt v obliki izdaje naslednje različice programskega izdelka, kjer dokumentacija in programska oprema sama odražata razvoj svojih sprememb.

Različica 0 je pripravljena za različico beta.

Koordinacija dela:

1. Paralelizacija dela

2. Načrtovanje omrežja

Programski izdelki, ki vam omogočajo načrtovanje dela in optimizacijo rokov:

MS Outlook
Upravljavec časa
MS Project – upravljanje virov, načrtovanje v korakih od ene ure do enega meseca. Oddaljenim uporabnikom omogoča delo na oddaljenem projektu.

21. Načrtovanje dela ekipe programerjev. Učinek drugega sistema.

Ko so začrtane vse faze in identificirani izvajalci (projektni viri in roki), je potrebno organizirati prejem informacij o trenutnem stanju projekta. Če želite to narediti, lahko organizirate računovodske kartice z naslednjo strukturo:

Šifra, številka delovnega mesta
Opis izvedbe
Končni čas
Rezultat, če je delo končano.

Vodja skupine spremlja te podatke.

Ocenjuje se, da programer v 28-33% primerov napiše program. Ostalo so sestanki, odobritve, iskanje literature, usposabljanje, usklajevanje s programerji, ki pišejo skupne module - 60%.

Naloga menedžerja je zmanjšati 60% na minimum in tako povečati programerjev čas dela na programu. Če je menedžer dober, potem bo lahko zmanjšal 60% na 50%.

Kritična situacija - projekt se ne drži rokov:

V tem primeru so možni naslednji koraki:

povečati število programerjev na projekt (pogosto samo poslabša situacijo);
prerazporediti delo na obstoječo količino, uvesti dodaten čas;

Učinek drugega sistema

Nekatera podjetja nameravajo razviti sistem za "vrženje", da bi dobili predstavo o težavah in napakah, preizkusili glavne ideje in nato razvili drugi sistem.

22. Sodelujte s stranko.

Posebna funkcija interakcije s potencialnim ali dejanskim uporabnikom programske opreme.

1 stranka, 1 razvijalec
Naročnik objavi razpis za razvoj. Zmagovalec je podjetje, ki bodisi zniža stroške razvoja bodisi ponudi več priložnosti za enak znesek. Podoba podjetja igra pomembno vlogo (sodelovanje in dokončanje podobnih razvojev, udeležba na seminarjih, srečanjih na temo, odprtost podjetja).

Prednosti:

Stranka je seznanjena z vsem delom

Testiranje vzporedno s pisanjem

Predavanje 2. Skupinski razvoj programske opreme.

Strukturna formula celoten mehanizem

Struktura skupin Assur

Stopnja gibanja mehanizma

Kinematični pari

Oznaka na blokovnem diagramu	Povezave, ki jih je treba povezati	Pogled	Vrsta para	Indeks parov
Narava stika	Stopnja mobilnosti

Število enojnih gibajočih se kinematičnih parov p 1 =7, število dveh gibljivih kinematičnih parov p 2 =0.

a).Zadnja skupina Assur

b).Predzadnja skupina Assur

c).Začetni mehanizem

7.Razred celotnega mehanizma II, ker najvišji razred Assur group, ki je del tega mehanizma II.

preučevanje sodelovalnih razvojnih orodij
proučevanje principov organizacije razvojnega procesa in vodenje ekipe razvijalcev

Definicije:

Nadzor vira (nadzor revizij, upravljanje izvorne kode (SCM)) - v ruščini se vse to običajno imenuje sistemi za nadzor različic. Z njimi lahko nadzoruješ marsikaj, seveda pa me zanimajo z vidika dela s kodo. Glavna ideja sistemov za nadzor različic je zapomniti vse spremembe, narejene s komentarji. . Jasno je, kdo je kaj spremenil, kdaj in zakaj. Glavna stvar je, da lahko vse te spremembe vrnete nazaj. No, poleg tega je sistem za nadzor različic mogoče obesiti z dodatnimi funkcijami in dodatki.

Repozitorij, shramba - prostor, kjer se shranjujejo in vzdržujejo kateri koli podatki. Najpogosteje so podatki v repozitoriju shranjeni v obliki datotek, ki so na voljo za nadaljnjo distribucijo po omrežju. Obstajajo repozitoriji za shranjevanje programov, napisanih v istem jeziku (na primer CPAN za Perl) ali namenjenih isti platformi. Veliko modernih operacijski sistemi, kot so OpenSolaris, FreeBSD in večina distribucij Linuxa, imajo uradne repozitorije, vendar omogočajo tudi namestitev paketov z drugih mest. Večina repozitorijev je brezplačnih, vendar nekatera podjetja nudijo dostop do lastnih repozitorijev za plačano naročnino. Repozitoriji se uporabljajo v sistemih za nadzor različic; shranjujejo vse dokumente skupaj z njihovo zgodovino sprememb in drugimi servisnimi informacijami. Skupnost Russian Subversion priporoča uporabo izraza repozitorij namesto izraza repozitorij, saj popolnoma ustreza tako neposrednemu prevodu besede "repozitorij" kot njenemu konceptu. Obstajajo različni avtomatizirani sistemi za ustvarjanje repozitorijev. Ena od vrst skladišč: shramba CD/DVD - namestitveni diski za pakete te ali one programske opreme.

Sistem za sledenje napakam - aplikacijski program, namenjen razvijalcem programske opreme (programerjem, preizkuševalcem itd.) pri upoštevanju in nadzoru napak (hroščev) najdenih v programih, željah uporabnikov ter spremljanju procesa odpravljanja teh napak ter uresničevanju ali neizpolnjevanju želja.

V poslovnem okolju se lahko sistem za sledenje napak uporabi za izdelavo poročil, ki prikazujejo produktivnost programerjev pri odpravljanju napak. Vendar ta pristop pogosto ne daje dovolj natančnih rezultatov, ker imajo različne napake različne stopnje resnosti in kompleksnosti. Vendar pa resnost problema ni neposredno povezana s težavnostjo odprave napake.

Primer, Redmine BUGS - Bug Genie Bugzilla eTraxis GNATS

Osnovna načela razvoj programske opreme v VCS

Postopek uporabe sistema za nadzor različic v vsakem posameznem primeru določajo tehnični predpisi in pravila, ki jih sprejme določeno podjetje ali organizacija, ki razvija projekt. Kljub temu, splošna načela pravilne uporabe VCS je malo in so enotne za vse sisteme za razvoj in nadzor različic.

Vse delovne, testne ali demo različice projekta se zbirajo samo iz sistemskega repozitorija. "Osebne" gradnje, ki vključujejo spremembe, ki še niso bile odobrene, lahko izvajajo samo razvijalci za namene vmesnega testiranja. To zagotavlja, da repozitorij vsebuje vse, kar je potrebno za ustvarjanje delovna verzija projekt.
Trenutna različica glavne veje je vedno pravilna. V glavno vejo ni dovoljeno vnesti sprememb, ki so nepopolne ali niso prestale vsaj predhodnega testiranja. Gradnja projekta iz trenutne različice bi morala biti kadar koli uspešna.
Vsako pomembno spremembo je treba dokumentirati kot ločeno vejo. V tej veji so zabeleženi vmesni rezultati dela razvijalca. Ko je sprememba končana, se veja združi z deblom. Izjeme so dovoljene le za manjše spremembe, delo na katerih izvaja en razvijalec v največ enem delovnem dnevu.
Različice projekta so označene z oznakami. Označena in označena različica se nikoli več ne spremeni.

Najbolj znani in največkrat omenjani so CVS, Subversion (SVN), Perforce. Vse sisteme, ki sem jih naštel druži dejstvo, da gre za sisteme z enim namenskim strežnikom, na katerem se nahaja repozitorij s kodo. Najverjetneje ste delali z enim od njih. Če še niste delali z nobenim od njih, toplo priporočam namestitev Subversion. Z lahkoto in enostavno ga lahko zaženete na enem lokalnem računalniku in dobite popolno razumevanje delovanja sistemov za nadzor različic.

Majhen slovar za nadaljnje razumevanje. Ljudje se običajno ne obremenjujemo s prevodi :-).
Trunk - glavna kodna veja
Veja - veje (na primer za poskuse)
Checkin (Prijava (oddaj, potrditev)) - pošiljanje kode v repozitorij
Odjavi - pridobitev spremembe iz skladišča.
Konflikti - nastanejo, ko več ljudi ureja isto kodo, konflikte je mogoče rešiti
Popravek je del zabeleženih sprememb, ki jih je mogoče uporabiti v repozitoriju kode

Reference

Razvoj programske opreme ima poleg precej kompleksnega tehničnega vidika tudi kompleksen organizacijski ali celo psihološki vidik.

Znano je na primer, da je potrebe kupca v nekih začetnih trenutkih razvoja in tudi po anketi vedno precej težko v celoti določiti. To pomeni veliko število nenačrtovanih del, kar negativno vpliva na kakovost izdelka.

Vprašanje je, kako graditi model odnosa med stranko in razvijalcem ob upoštevanju interesov obeh strani in brez izgube kakovosti?

Vsaka stran je sestavljena iz funkcionalno neodvisnih vlog. Vsaka vloga lahko vključuje več ljudi. Vloge so združljive samo znotraj strank.

Torej, stran stranke ima naslednje ključne vloge: produktni vodja in poslovni analitik.

Produktni vodja- to je predstavnik razvijalca pri stranki, dolžan je zastopati interese stranke pri razvijalcu. To je glavni vir informacij tako za stranko kot za razvijalca; njen cilj je v celoti zadovoljiti potrebe stranke v okviru dodeljenih virov.

Poslovni analitik- To je predstavnik stranke, odgovoren za ustvarjanje sistema. Pozna poslovni proces do potankosti vašega podjetja in je dolžan posredovati popolne in točne podatke.

Stran razvijalca: vodja programa, analitik, programer, tester.

Vodja programa- to je glavni tehnični specialist projekta, je skrbnik specifikacije in ga zanima minimalne spremembe med razvojem.

analitik informacije, prejete od stranke, formalizira v obliki modelov, mora biti sposoben prepoznati vzorce in pravilno posplošiti, analizirati in oblikovati nabor med seboj povezanih programov za izvajanje funkcij predmetnega področja.

Programer— sam kodirnik.

Tester- strokovnjak za testiranje, odgovoren je za zagotavljanje, da sistem ustreza specifikacijam.

Kakovostna stran: poslovni analitik in tehnolog.

Poslovni analitik- strokovnjak za področje na splošno, ne glede na posamezno podjetje.

tehnolog- strokovnjak za tehnologijo, ki spremlja pravilno uporabo le-tega.

V resnici vsaka stran deluje v nasprotju z drugima dvema in je potrebna za ohranjanje splošnega ravnovesja.

Vsaka vloga lahko vključuje več ljudi. Upoštevati je treba, da pri delu na velik projekt nastane problem interakcije izvajalci med seboj. Interakcija izvajalcev med seboj zahteva čas, ki do določene mere zmanjšuje produktivnost dela. Poleg tega medsebojno nerazumevanje povzroči dodatne stroške v naslednjih fazah razvoja, na primer nesporazum med programerji povzroči dodatne stroške za testiranje.

Problem interakcije nastane, ko dela skupina štirih ali več ljudi. Za vodenje njihovega dela je potreben vodja.

Rešitev te težave bi lahko bila organiziranje brigade, Na primer glavna programska ekipa,če pogledamo primer programerjev.

Ekipa mora vključevati od 3 do 7 ljudi. Število 10 je zgornja meja velikosti brigade. To je posledica zahteve po največji možni vodljivosti ekipe.

Naslednji strokovnjaki so opredeljeni v ekipi glede na njihove kvalifikacije.

Vodja ekipe(npr. glavni programer) je odlično usposobljen, kreativno razmišljajoč strokovnjak, obdarjen z organizacijskimi sposobnostmi. Opravlja vrhunsko delo, vključno z razporeditvijo dela znotraj ekipe.

namestnik vodje ekipa (na primer višji programer) vzdržuje tesno komunikacijo z vodjo ekipe in dokončno ureja manjša vprašanja. Pri razpravi o projektu naj namestnik nastopa kot nasprotnik vodji ekipe.

Neposredni izvajalci(na primer mlajši programerji) - dva ali trije "manj izkušeni" (vendar ne "manj sposobni") strokovnjaki. Opravljajo dela na nižji ravni, ki jih določi vodja ekipe.

V velikem projektu lahko vsaka ali več skupin vključuje naslednje strokovnjake.

Administrator Odgovoren za razporeditev časa, izbor osebja, postavitev izvajalcev, financiranje in vzdrževanje komunikacije z višjim vodstvom.

Knjižničar Vzdržuje sistemsko knjižnico, na primer knjižnico modulov, ki se uporabljajo na spletu. Vse spremembe programskih modulov izvaja samo knjižničar. Vzdržuje tudi sistemsko dokumentacijo - sistemski dnevnik.

Tehnični vodja(dokumentist) se ukvarja s pisanjem projektne dokumentacije, ki bolj usposobljene strokovnjake razbremeni tega rutinskega dela.

sekretar opravlja redna tajniška dela.

Izkušnje z razvojem velike programske opreme kažejo, da je za povečanje učinkovitosti dela potrebno projekt razdelite na ločene podatkovno in funkcionalno šibko povezane podsisteme. Izvajanje podsistemov naj izvajajo ločene skupine strokovnjakov. V primeru uporabe orodij CASE to pomeni razdelitev funkcionalnega modela sistema (diagrami pretoka podatkov za strukturni pristop).

Zato po začetni opredelitvi funkcij, ki naj bi jih izvajala programska oprema, ki se razvija, projekt je razdeljen med različne razvojne ekipe(Slika 12.1).

riž. 12.1. Skupine strokovnjakov, ki se ukvarjajo z razvojem programske opreme

(n - število programskih funkcij)

Hkrati je treba zagotoviti usklajenost celotnega projekta in odpraviti podvajanje delovnih rezultatov posamezne projektne skupine, ki lahko nastane zaradi prisotnosti skupnih podatkov in funkcij.

Rezultat etape mora biti:

Splošni informacijski model sistema;

Globalni funkcionalni modeli sistema kot celote in podsistemov, ki jih izvajajo posamezne razvojne ekipe;

Natančno določeni vmesniki med avtonomno razvitimi podsistemi (podatki, ki se med njimi prenašajo);

Zgrajeni prototipi zaslonskih obrazcev, poročil, dialogov (določen mora biti standard uporabniškega vmesnika).

Po opravljenem delu vsake posamezne razvojne ekipe proizvedeno postopno vključevanje tega dela sistema z ostalimi, generira se celotna programska koda, testira se skupno delovanje tega dela aplikacije, nato pa se testira sistem kot celota.

Celoten nabor dogodkov, odvisno od števila udeležencev in vrste odnosov med njimi, je mogoče zmanjšati na triado razvoja, prikazano na sl. 3.21.

Rad imam samoto, tudi ko sem sam.
J. Renard

To načelo je bilo precej razširjeno v 70-80 letih 20. stoletja. Zdaj se redko uporablja.

Najbolj zanimivo načelo je avtorjev razvoj z vidika uporabe na področju znanja intenzivnih aplikacij. Za takšne aplikacije je značilna potreba po dolgoletnem študiju predmetnega področja, skoraj popolna odsotnost začetnega financiranja projekta in nizka donosnost, ki jo določa ozek krog uporabnikov.

izključitev medosebnih komunikacij, povezanih s potrebo po ustvarjanju in preučevanju velike količine tehnološke dokumentacije;
izključitev dela na razdelitvi projekta na komponente, razdelitvi le-teh med izvajalce, usklajevanju dejavnosti izvajalcev in spremljanju njihovega dela.

Obseg programskega izdelka, izdelanega z lastniško razvojno metodo, je 5-20-krat manjši v primerjavi z industrijskimi analogi.

Avtorjev razvoj vključuje samo doseganje poklicnega uspeha, slave in slave. To je povsem mogoče, le izbrati morate pravo poklicno "nišo", področje razvoja.

2. Sodelovalni razvoj

Lahko je zbrati čredo ovc, težko pa je zbrati čredo mačk.
S. P. Kapitsa

Eno glavnih vprašanj kolektivnega razvoja je delitev dela - od enakih soizvajalcev do organizacije v obliki toge hierarhije (na primer ekipa glavnega programerja).

O prvih izkušnjah kolektivnega razvoja
Znano je, da je prvi skupni razvoj programov potekal približno tako. Šef je izpeljal delitev velik projekt na manjše dele in ga posredoval nižje po hierarhiji. Čez nekaj časa, zdaj od spodaj navzgor, se je program sestavljal iz zapisanih fragmentov. Ni bilo vedno mogoče sestaviti delujočega programskega izdelka.

2.1. Vloge tehnične ekipe

Enakopravni soizvajalci

Ekipo enakopravnih soizvajalcev običajno sestavljajo strokovnjaki, ki se v okviru enega projekta ukvarjajo s približno podobnimi nalogami. Seveda je lahko znotraj ene ekipe več specializacij:

razvojni inženirji (programski inženirji in programerji);
tehnični pisci;
inženirji za testiranje;
inženirji kakovosti;
strokovnjaki za podporo produktom;
strokovnjaki za prodajo izdelkov.

Vrsta dela določa vsebino in naravo dela, ki ga opravlja. Tukaj je seznam vrst dela in področij specializacije na podlagi Congerjeve klasifikacije.

Razvoj aplikacij.

Programer.
Specialist za programski inženiring.
Specialist za inženiring znanja.

Delo z aplikacijami.

Strokovnjak za aplikacije.
Skrbnik podatkov.
Skrbnik baze podatkov.

Tehnična podpora.

Sistemski skrbnik.
Skrbnik omrežja.
Administrator komunikacij,

Zagotavljanje kakovosti izdelkov.

Tehnični pisec.
Testni inženir.
Inženir kakovosti.

Trženje.

Strokovnjak za podporo izdelkom.
Specialist za prodajo izdelkov.

Sistemska integracija.

Sistemski integrator.

Od naštetih specializacij je zelo zanimiva specializacija sistemski integrator. Glavne naloge sistemskega integratorja so, da stranki ponudi rešitev za njen problem, pri čemer izbere cenovno in tehnološko najbolj sprejemljivo rešitev ter jo izvede. Tako sistemski integrator prodaja rešitve in je odgovoren za njihovo implementacijo. Sistemski integrator kot strokovnjak mora imeti znanja iz številnih področij – aplikativnega in sistemskega programsko opremo, sistemska administracija, strojna oprema, omrežja, ekonomija itd.

Vodja programerske ekipe

- Zakaj ekipo NMP sestavljata dva zdravnika?
- Eden ve, kje dati klistir, drugi pa ve, zakaj!
Anekdota o specializaciji v ekipi

Harlan Mills [Brooks 1999] je predlagal organiziranje ekip glavnih programerjev, podobnih kirurškim ekipam. Pri glavnem delu je angažiran le en član ekipe, ostali mu nudijo vso možno podporo. Ekipo glavnega programerja sestavlja deset ljudi, ki v ekipi opravljajo specializirane vloge (slika 3.22).

Bistveni člani ekipe opravljajo spodaj navedene funkcije.

Glavni programer. Osebno izvaja analize in načrtovanje, ustvarjanje in razhroščevanje kode, pisanje dokumentacije. Imeti mora talent, bogate delovne izkušnje in pomembno znanje.
Podštudij. Lahko opravlja katero koli delo glavnega programerja, vendar je manj izkušen. Zagotavlja podporo glavnemu programerju, lahko piše kodo, vendar ni odgovoren za projekt.
Administrator, je tudi upravnik. Pod njegovim nadzorom so denar, ljudje, prostori, strojni viri, stiki z drugimi skupinami in vodstvo.
Urednik. Pravzaprav je to tehnični pisec. Njegova naloga je kritično pregledati osnutke dokumentacije (ki jih izdela glavni programer), jih opremiti z referencami in bibliografijo ter zagotoviti objavo ali objavo na internetu.
Jezikoslovec. Strokovnjak za zapletenosti programskih jezikov. Lahko najde učinkovite načine uporaba jezika za reševanje kompleksnih problemov. Ponavadi dela z več ekipami.
Orodjar. Razvijalec specializiranih orodij - pripomočkov in skript. Vzdržuje osnovna orodja in nudi svetovanja o njih. Po potrebi lahko upravlja operacijski sistem.
Odpravljalnik napak. Razvijalec testov in organizator testiranja programskih izdelkov.
Uradnik. Odgovoren za registracijo vseh tehničnih podatkov ekipe v knjižnici programskih izdelkov. Zahvaljujoč referentu so bili aktivni programerji osvobojeni rutinskega dela. Upoštevajte, da so trenutno funkcije referenta avtomatizirane in prenesene v repozitorij projektov.

2.2. Vloge psihološkega tima

Rob Thomsett je predlagal osem ključnih vlog v projektu (slika 3.23).

predsednik. Izbere pot za napredovanje ekipe k skupnim ciljem. Sposoben zaznati močne in slabosti ekipo in zagotoviti največji izkoristek potenciala vsakega člana ekipe.
Arhitekt. Je tudi oblikovalec. Daje popolno obliko dejanjem ekipe. Ima jasno razumevanje problemov in njihovih možnih rešitev.
Generator idej. Ponuja radikalno nove ideje in strategije, nove pristope k reševanju problemov, s katerimi se sooča skupina. Posebno pozornost namenja glavnim težavam.
Kritik. Je tudi skeptik, ki probleme ocenjuje s pragmatičnega vidika. Išče pomanjkljivosti, napake in nepopolnosti. Kompenzira optimizem generatorja idej.
Izvršitelj. Zaposleni, ki dejansko piše kodo. Praviloma nima širokega pogleda.
Končno. Podpira vztrajnost ekipe pri doseganju ciljev. Ima dominantno vlogo v končnih fazah razvoja.
Diplomat. Ohranja trdnost pri udeležencih projekta. Pomaga jim v težkih situacijah. Poskuša izboljšati odnose v ekipi.
Organizator. Odkriva in sporoča nove ideje, razvoj in vire. V svoji organizaciji ima veliko prijateljev in zvez, s pomočjo katerih lahko prosi ali si izposodi potrebna sredstva.

V resničnih programerskih skupinah ni mogoče dodeliti vseh teh vlog. Vlogo izvajalca pogosto prevzame več članov ekipe hkrati.

2.3. Vrste skupnih dejavnosti

Sodelovalni razvoj vključuje veliko število različnih dejavnosti, stopnja skupne dejavnosti pa se lahko od dejavnosti do dejavnosti zelo razlikuje. Ločimo lahko štiri vrste skupnih dejavnosti.

Obvezne dejavnosti, ki jih običajno predstavljajo redni uradni sestanki. Običajno so sestanki načrtovani vnaprej in udeležba je obvezna. Statistika kaže, da programerji na sestankih preživijo približno 4 % svojega delovnega časa.
Sklicana dejavnost, do katere pride, ko se dva ali več programerjev odloči, da se zbereta, da bi rešila neko težavo tehnična težava. Takšni sestanki običajno niso vnaprej načrtovani in se jih udeležujejo le programerji, ki jih resnično zanima rešitev problema. Ta dejavnost traja približno 14 % delovnega časa.
Naravno skupne dejavnosti se zgodi, ko vsaj dva programerja delata na isti nalogi hkrati in si izmenjujeta informacije o opravljenem delu. Ta dejavnost zavzame približno 41 % delovnega časa.
Individualne dejavnosti se zgodi, ko programer dela na nalogi, ki je hkrati ne izvaja noben drug programer in je zato malo verjetno, da bo o zadevi komuniciral s katerim koli drugim programerjem v skupini. Tudi ta dejavnost zavzame približno 41 % delovnega časa.

3. Model razvoja skupnosti

Odličnost v projektu ni dosežena, če ni več kaj dodati,
in takrat, ko ni ničesar za odstraniti.
Antoine de Saint-Exupéry

Ideologija razvojnega modela skupnosti (»bazarja«) je oblikovana v političnem članku Erica Raymonda »Katedrala in bazar«. Skupnostni model zaznamujejo trije glavni dejavniki.

Decentraliziran razvoj. Zgornje omejitve števila ljudi, ki sodelujejo v projektu, ni. Praviloma se tovrstni razvoj izvaja na podlagi interneta in lahko vključuje katerega koli zainteresiranega internetnega razvijalca.
Razvoj poteka na podlagi odprtokodnih besedil. Z njihovo uporabo lahko razumete bistvo problema in se kadar koli povežete z razvojem.
Veliko število zunanjih preizkuševalcev (beta preizkuševalcev), ki vam omogočajo hitro odkrivanje napak in težav v programu.

Eric Raymond je orisal več lekcij, ki nudijo vpogled v razvoj skupnosti.

Vsak dober program začne se z navdušenjem razvijalca.
Dobri programerji vedo, kaj je mogoče napisati, odlični programerji pa vedo, kaj je mogoče prepisati.
S pravim odnosom vas bo zanimiv problem našel sam.
Ko izgubite zanimanje za program, je vaša zadnja odgovornost, da ga predate kompetentnemu nasledniku.
Programsko opremo izdajajte zgodaj in pogosto.
Različni ljudje lahko najdejo težavo in jo odpravijo.
Včasih je uporaba idej uporabnikov boljša od uporabe lastnih idej.

Obstajajo sistemske opombe.

Prevladujoča metoda kolektivnega razvoja je organizacija timov. Metoda predmetnih povezav se redkeje uporablja, kadar organizacija, ki ga bo upravljala, razvija izdelek, ki se ne ponavlja.

Z upravnega vidika je brigada strukturna proizvodna enota, ki se lahko oblikuje v okviru obstoječe strukturne enote za opravljanje določenega dela, ki ima določen rezultat.

Pri določanju rezultata dela ekipe se lahko oblikuje delna tehnična specifikacija.

Obstajata dve možnosti brigade:

predmetno področje je definirano programersko, to pomeni, da je naloga rezultat dela, povezanega s programiranjem;

predmetno področje je opredeljeno z jezikom, ki se na predmetnem področju uporablja (funkcionalno in matematično usmerjeni programski izdelki);

V prvem primeru je vsebina programerju videti znana in razumljiva, delo pa vključuje tehnično zasnovo, ki jo lahko izvaja programer. Ekipa se lahko sestavi iz strokovnjakov istega profila (predvsem programerjev).

V drugem primeru lahko delo tehničnega projektiranja opravi predmetni strokovnjak. Oblikovalsko rešitev, ki jo je sprejel, vse do tehnične zasnove, se naknadno pripelje do strojne izvedbe s strani specialista, vzporedno pa se vodi dokumentacija, ki jo po možnosti razvija strokovnjak s področja. Delovanje programskega izdelka med implementacijo preveri tudi strokovnjak s predmetnega področja.

Oblikovanje specializiranih timov (iz strokovnjakov istega profila). Rezultat dela posamezne ekipe ne predstavlja vedno končnega rezultata razvoja.

Težje je obvladovati razvoj, potrebna je stroga formalizacija dela vsake ekipe. Vklopljeno poznejše faze rezultati razvoja lahko odstopajo od specifikacij.

Če je zaradi kompleksnosti in obsega razvoja to potrebno veliko število izvajalcev in organizacijo več ekip, priporočamo:

Razmislite o vprašanju specializacije ekip glede na funkcionalne značilnosti;

Priporočljivo je določiti vodilno, glavno ekipo. Ta brigada opravlja najnujnejšo nalogo in v kar največji meri sodeluje pri življenjski cikel. Brigadi so dodeljene druge brigade kot soizvajalci (ki imajo lahko svoje tehnične specifikacije).

Identificirane so upravljavske funkcije, ki so predmet avtomatizacije, oziroma tiste, za katere so revidirane predhodno obstoječe rešitve. Težave se rešujejo z metodami hierarhične dekompozicije: delitev kompleksnega problema krmilne funkcije na več njegovih posameznih komponent (podproblemov), dokler niso podrobno določeni informacijski vhodi in izhodi za vsako komponento, pridobljeno v naslednjem koraku.