Új ubuntu.hu portál:Munkafolyamat

A Ubuwiki wikiből

A lap korábbi változatát látod, amilyen Udi (vitalap | szerkesztései) 2012. február 13., 16:08-kor történt szerkesztése után volt.

Új ubuntu.hu portál

A munkafolyamat a kidolgozás után legyen pontosan leírva, hogy az önkéntesek könnyen léphessenek ki, illetve könnyen csatlakozhassanak a projekthez.

Kommunikáció

Kommunikáció nyitottsága

  • Nyílt kommunikáció
  • előnyei: átlátható a felhasználók számára, közelebb kerül a fejlesztés hozzájuk, bele tudnak szólni.
  • hátrányai: biciklitároló festés veszélyei, sok a zaj, a helyreigazítások, magyarázatok időt vesznek el, szűréshez moderátor kell.
  • Zárt kommunikáció
  • előnyei: a szakmai körön belül gyorsabb és hatékonyabb a kommunikáció.
  • hátrányai: kívülről nem lehet követni az eseményeket, plusz erőforrás, hogy kívülre is kommunikáljuk a privátban megbeszélt dolgokat.

Lehetséges kommunikációs csatornák

  • Projektmenedzsment szoftver
  • előnyök: a kommunikáció jól le van bontva feladatokra, határidők, diagramok automatikusan látszanak
  • hátrányok: még nem volt beüzemelve ilyen, fel kell telepíteni és be kell állítani, az ubuntu.hu önkénteseknek lesz-e tapasztalata egy ilyen használatában?
  • Wiki:
  • előnyök: mindenki számára elérhető, a változások jól lekövethetőek
  • hátrányok: lehetséges-e automatizálni (feladatok lezárása, határidő figyelése), lehetséges-e zárttá tenni?
  • Levelezőlista:
  • előnyök: e-mail írás természetes és viszonylag gyors, a kommunikáció szálak szerint jól követhető
  • hátrányok: üzenet formázásához HTML levél kell, csatolmányok beágyazhatóak az üzenetbe?
  • IRC:
  • előnyök: a leggyorsabb, azonnali kommunikáció
  • hátrányok: sok résztvevő esetén nehéz időpontot találni, ami mindenkinek jó, archiváláshoz rögzíteni kell a logokat

Javaslatok

  • Udi 2012. február 13., 11:45 (CET): a kommunikáció legyen nyílt, és a fő csatorna maradjon a Wiki, szépen formázható, jól követhető, akár a dokumentációt is tudja pótolni. Viszont nézzünk utána, hogy a feladatok kezelését hogyan lehet automatizálni, vagy egyszerűsíteni: pl. feladatokat sablonosítani, határidőket kijelezni, figyelmeztetni ha csúszás van stb. Htibi és Wikista a sablonokban tudnak segíteni, de nem leterhelő-e ez nekik, hiszen a Wiki felfuttatása is folyamatban van. A gyors megbeszélésekhez használjuk a Freenode jól bevált ##ubuntu-jam-hu csatornáját, akár egy nyitó megbeszélést is tarthatunk ott, ahol gyorsan meg lehet vitatni a javaslatokat.

Feladatok kiosztása

A feladatok kiosztásának módjai

  • A projektvezető osztja ki őket:
  • előnyök: a projektvezető átlátja az egész projektet, ezért a határidőket és a feladatok prioritását szemmel tartva oszthatja ki a feladatokat
  • hátrányok: ismerni kell a fejlesztők képességeit, tapasztalatait, munkatempóját
  • A feladatokat a projektvezető csoportokba rendezi, és csak az egyes csoportokon belül lehet a feladatok közül szabadon válogatni:
  • előnyök: az irányítás továbbra is a projektvezető kezében marad, csoportokba rendezheti a fontos, sürgős vagy különös szakértelmet kívánó feladatokat
  • hátrányok: ha a csoporton belül nincs megfelelő feladat, akkor az egyes emberek üresjáratba kerülhetnek
  • A feladatokat mindenki szabadon választhatja:
  • előnyök: mindenki maga tudja eldönteni, hogy melyik feladathoz ért, melyiket csinálja a legszívesebben (legmotiváltabban)
  • hátrányok: a népszerűtlen feladatok (dokumentálás, kategorizálás) mindig utoljára maradnak, még akkor is, ha a fejlesztési menet nem ezt kívánja

Javaslatok

  • Udi 2012. február 13., 13:56 (CET): A feladatokat a projektvezető határidő szerint rendezze csoportba, és abból szabadon lehessen válogatni. A "release early, release often" elvnek megfelelően a cél mindig egy-egy határkő (milestone) legyen, ami után meg lehet mutatni az eredményt, teszteltetni lehet, visszajelzést lehet kérni, esetleg egyesíteni lehet az éles rendszerrel (ha a végcélt nem is érjük el, de van olyan újítás, ami bekerül az éles rendszerbe, már eredményes a projekt).

Fejlesztés menete

A hozzáférés szempontjából

  • Minden fejlesztőnek van (korlátozott) hozzáférése a célrendszerhez (dev.ubuntu.hu):
  • előnyök: a változtatásokat azonnal lehet alkalmazni a célrendszerre
  • hátrányok: erős jogosultságrendszer kell a szerverre, gyakori biztonsági mentés, a hibák is azonnal felkerülnek a célrendszerre
  • Egyedül a projektvezetőnek van hozzáférése a célrendszerhez, a fejlesztők kizárólag egy verziókezelőhöz kapnak jogokat:
  • előnyök: a verziókezelő rendszeren jól lekövethető, hogy ki mikor mit változtatott, a változtatások egyszerűen visszaállíthatóak, a szerver nagyobb biztonságban van, ha csak a projektvezető fér hozzá
  • hátrányok: az egyes kiadásokat/élesítéseket csak a projektvezető tudja végrehajtani

Javaslatok

  • Udi 2012. február 13., 14:16 (CET): Egyedül a projektvezetőnek legyen hozzáférése, és legyen egy verziókezelő rendszer akár magán a szerveren, akár más szerveren, vagy akár egy szolgáltatónál (pl. Github). Egy verziókezelő a karbantarthatóságot rendkívüli mértékben megnöveli, máshogy nehéz megvalósítani a kooperációt: "Managing senior programmers is like herding cats." - Dave Platt

Tesztelés menete

Két részletre érdemes bontani. A fejlesztők a fejlesztés alatt álló kódot tesztelik, viszont a tesztelőktől nem várható el, hogy a fejlesztést kövessék és a tesztrendszert feltelepítsék, őket érdemes a kiadás/élesítés után bevonni.

Fejlesztők tesztelése

  • Informális tesztelés:
  • előnyök: a fejlesztés már le van bontva kicsi feladatokra, ahol ez alkalmazható; a fejlesztő megbizonyosodik arról, hogy a program működik
  • hátrányok: a külön-külön fejlesztett feladatok együttműködését nehéz így tesztelni
  • Unit testing:
  • előnyök: az egész rendszerre vonatkozóan végezhető gyors kódteszt, biztosítja, hogy az egyes változtatások ne törjék meg a rendszer többi részét, viszonylag automatikus
  • hátrányok: a teszteket meg kell írni, minél több a saját kód, annál több tesztet kell írni

Tesztelők tesztelése

  • Informális, nem irányított tesztelés:
  • előnyök: gyorsan megvan, az egyedi használatból adódó hibaforrásokra is fény derül
  • hátrányok: a tesztelőtől függ az alaposság, a dokumentálás
  • Irányított tesztelés:
  • előnyök: a tesztdokumentumban foglalt összes lépést pontosan végre lehet hajtani
  • hátrányok: a tesztdokumentumon kívüli esetek nem kerülnek tesztelésre

Kiadás/élesítés menete

Ez a szakasz egyelőre erősen hiányos, vagy még nem írtuk meg. Segíthetsz te is a kibővítésében.
Személyes eszközök