HTML

Agilitás Blog - az agilitas.hu blogja

Agilis módszertani cikkek, újdonságok, vélemények, intejúk, szoftverek, eszközök és technikák - a gondolkodó, tapasztalt tanácsadók szemével.

Friss topikok

  • kulcsár bence: @Borbándy László: kezdem sejteni, van vagy 4 borbandy laszlo es vagy 6 kulcsar bence a facebookon.... (2013.03.11. 22:51) A UserStory feldarabolás 10 stratégiája
  • Janovszki Zsolt: időnként jó ezt újra meg újra végiggondolni, most pont egy prezentációhoz kellett, gondoltam gondo... (2013.03.04. 23:14) Agile Principles - magyarul
  • kulcsár bence: A cikk célja az volt, hogy a lehető legszélesebb áttekintését adja az agilis szerződéseknek. Jó öt... (2011.02.15. 11:08) Agilis szerződések
  • kulcsár bence: A kérdés jó. Először is tisztázni kell, hogy a csapat agilis csapat-e. A mi esetünkben igen, ami r... (2011.02.08. 23:26) Az önszervező csapat sikerfaktorai
  • Janovszki Zsolt: @sipos_zoli: ott a két pont. Kérlek járuljatok hozzá az átadás dokumentálásához, amire a mai napon... (2010.12.08. 13:01) Szerintem félreértelmezi

Linkblog

OpenAgile - Bevezetés az értékvezérelt rendszerbe

2010.11.30. 12:24  kulcsár bence

Az agilis módszertan térhódításának hatására egyre többen gondolkoztak azon, hogy miképpen lehet annak előnyeit nem szoftverfejlesztési projektekben kamatoztatni. Az OpenAgile egy gondolatkísérletként indult 2004-ben Mishkin Berteig jóvoltából aki agile coach-ként gyakorlati tapasztalataiból indult ki.

   Berteig nagyvállalati szoftverfejlesztési projektekben dolgozott különböző agilis metodológiákkal, jellemzően Extreme Programming-mal és Scrum-mal. Később egyre bizonyosabb lett benne, hogy megfelelő módosításokkal az agilis módszertant lehetséges szoftverejlesztésen kívüli területeken is alkalmazni, illetve annak értékteremtő képességét akár projekt menedzsment, üzemeltetési és kereskedelemi vonatkozásban is felhasználni. Ennek első lépéseként a csapatmunkára, a hatékony visszajelzési és visszacsatolási, illetve szervezet fejlesztési folyamatokra fókuszált. Nem sokkal később figyelme a tanulási folyamatok, illetve Cyclical Learning modellek felé fordult. Ennek adaptációja később eljárásgyűjteménye egyik alappillére lett, amit Learning Circle-nek nevezett el. Végül az Open Agile definitív módon is a tanulásban eredezteti egy szevezet vagy egy projekt értékteremtő képességét.

Az OpenAgile egy olyan gyors értékszállításra alkalmas módszer, amely az igazmondáson, a konzultatív döntéshozáson és a folyamatos tanuláson alapul.

Az OpenAgile egy "open source" metodika melyet gyakorló szakemberek támogató közössége épít, bárki számára felhasználhatóvá és hozzáférhetővé téve azt. A felhasználók a későbbiekben saját tapasztalataikkal is hozzájárulhatnak a további fejlesztéshez. Az OpenAgile.com foglalja össze a hivatalos OpenAgile verziót és a minősített képzési programot. Emellett létezik egy nem hivatalos open-source verzió is a wiki.openagile.org-on, melyen ugyanúgy az OpenAgile-on dolgozó közösség dolgozik.

Az OpenAgile alapkoncepcióját és gyakorlati tanácsait az OpenAgile Primer dokumentum foglalja össze. OpenAgilePrimer.pdf  Ez a dokumentum szolgál alapjául az OpenAgile Readiness vizsgának.

Szólj hozzá!

Címkék: manifesto agile openagile

Csúszunk a projekttel

2010.11.24. 09:49  kulcsár bence

Szólj hozzá!

Címkék: cartoon

Storypoint definíció a gyakorlatban

2010.11.18. 12:23  kulcsár bence

Sok helyen olvashatunk Storypoint definícókról, illetve különböző numerikus skálákról és koncepciókról, melyek a feladatok egymáshoz képesti viszonyitását hivatottak szolgálni. Értelemszerűen a Storypoint becslések közvetlenül kihatnak a csapat teljesítmény mérésére végső soron pedig folyamat javítási, értékelési rendszerre is. Ezért különösen fontos, hogy a projekt életciklusa alatt az egyes pontértékek egyet jelentsenek a feladat komplexitása szempontjából. Különösen igaz ez, ha több csapat dogozik egy projekten.

A csapataimnál egy a minerva-group által használt definíciós listát szoktam alkalmazni.

A numerikus skála a módosított fibonacci-t számsort alkalmazza, a planning poker kártyákon megszokott 1/2 -es érték kivételével, de igény esetén természetesen könnyen kiegészíthető.

Előnye, hogy a storypoint értékek mellett egyértelműen definiálja a fejlesztési ráfordítás mértékét a fejlesztői tevékenységek terminológiájával.

A definíciókban a pontosvessző (;) jelenti az és/vagy összefüggést a fejlesztési tevékenységek kapcsolatában.

0
 
Triviális (pl. egyszerű átnevezés)
 
1
 
Technikaliag nem komplex, egyszerű implementálni
 
2
 
Technikaliag nem komplex, nehézkesebb implementálni
 
3
 
Valamelyest komplex vagy alapos átgondolást igényel az implementálás
 
5
 
Valamelyest komplex, ismeretlenekkel vagy külső függőséggel; kiterjedt tesztelést igényel
 
8

 
Komplex vagy szövevényes (a rendszer különböző részeit érinti); nagymértékű külső függelmek; különböző ismeretlenek; többszintű tesztelést igényel
 
13

 
Nagyon komplex és szövevényes (az egész rendszert érinti); rengeteg különböző mértékű függelem; határozottan sok ismeretlen; kiterjedt tesztelést igényel.
 
20
 
Eposz (Herkules)
 
40
 
Óriás eposz (Illiász és Odüsszeia kombinálva)
 
100
 
Az összes Görög-római, Babiloni, Perzsa és Hettita hősi eposz kombinálva
 

 

 

 

 

 

 

 

 

 

 

 


Az utolsó három meghatározás (20, 40, 100) tréfás, ugyanakkor egyértelműen jelzi, hogy a 13-asnál nagyobb feladatokat érdemes kisebb user story-kra felbontani a könnyebb menedzselhetőség és a kockázatok minimalizálása miatt.

Szólj hozzá!

Címkék: agile scrum estimation storypoint

AgileHardware

2010.11.16. 13:34  kulcsár bence

Nemrég bukkantam rá a Belga székhelyű agilehardware.com cégre. A vállalkozás kifejezetten agilis fejlesztőcsapatokat kíván különböző nem szoftver alapú támogató eszközökkel kiszolgálni. Bár elég szűkös a kínálat, a planning poker kártya és timer mellett pár XP-t támogató eszköz is beszerezhető.

Szólj hozzá!

Címkék: tool

Minden péntek

2010.11.10. 19:30  kulcsár bence

Szólj hozzá!

Címkék: cartoon

5 dolog amire érdemes Stand-up után gondolni

2010.11.10. 10:00  kulcsár bence

A legutóbbi, 5 dolog, amit Stand-up előtt érdemes átgondolni című bejegyzéshez kapcsolódva most megvizsgáljuk, mi az az 5 dolog, amivel viszont a Stand-up után érdemes foglalkozni.
 

1. Problémák

Célszerű megszüntetni vagy kiiktatni minden olyasmit, ami szóba került, mint akadály, nehézség vagy megoldatlan ügy. Az Agile a munkafolyamatokat a “problémák szemszögéből” vizsgálja, hasonlóan Eli Goldratt “akadályelméletéhez”, amelyben a menedzser fő feladata, hogy megszüntesse az akadályokat. A menedzsernek tehát a Stand-up során megemlített akadályok vagy nehézségek alapján kell megterveznie saját elvégzendő feladatainak listáját, és törekednie kell, hogy a listán szereplő problémákat mielőbb megszüntesse.
 

2. Határidő-eltérések

A feladatokhoz kapcsolódó időbecslések alapján célszerű utánanézni, mi lehet az oka, ha például egy feladatra két napot szántunk, ám már négy napja dolgoznak rajta, és még mindig messze van a befejezés. Ha időnk engedi, érdemes lehet a Stand-up során rákérdezni, hogy van-e valami probléma. Másik megoldás lehet, ha a Stand-up után foglalkozunk a kérdéssel, és igyekszünk feltárni az okokat. Vajon rossz volt a határidő-becslés, vagy túl makacs a probléma, vagy be kellene vonni valaki mást? Hasonló esetek alkalmanként gyakran előfordulnak. Ám ha bizonyos feladatok vagy munkatársak esetében mindez állandó határidő-túllépéshez vezet, az esetleg komolyabb okokat vagy problémákat jelezhet. Ugyanígy gond lehet, ha túlságosan gyorsan halad a munka a kitűzött határidőhöz képest (pl. minden négynapos munkát egy nap alatt sikerül befejezni). Ez azt jelezheti, hogy érdemes átgondolnunk az iterációs célkitűzéseinket. A lényeg az, hogy az “elvégzett munka” tényleg el legyen végezve, és minden része megfeleljen a minőségellenőrzés (QA) követelményeinek és a felhasználók elvárásainak, mielőtt elhamarkodottan egy hónappal korábbra hoznánk a projektzáró buli időpontját.
 

3. Érzelmek

Gondoljuk át, mi hangzott el, és mi lehet az, amit esetleg senki nem mondott ki. Lehetséges, hogy valaki ideges vagy dühös volt, netán feszültségek vannak a csapaton belül, vagy épp egy mindig beszédes kolléga ez alkalommal mélyen hallgatott? Ha igen, az annak a jele, hogy itt az ideje egy gyors beszélgetésnek. Az elhallgatott ügyek éppúgy akadályozzák a haladást, mint a kimondott problémák. Lehet, hogy ezek némelyikét nem fogjuk tudni megoldani, ám valószínű, hogy az érdeklődés és a kollégák figyelmes meghallgatása önmagában is jelentős lépés a megoldás felé.
 

4. Kérdések

Előfordulhat, hogy a Stand-up során megbeszélt eredményeket vagy problémákat nem értettük meg teljesen. Ha a rövid meeting során nem sikerült a homályos pontokat tisztáznunk, célszerű lehet később részletesebb kérdéseket feltenni. (Amikor fejlesztőként dolgoztam, félszavakból is megértettem a technikai részleteket. Ám most, hogy projekt menedzser vagyok, néha azt kell kérnem, hogy beszéljenek hozzám lassabban. Ha ez sem segít, elmagyarázom, hogy valójában PMP certified projekt menedzser vagyok, úgyhogy fontos, hogy tény-leg las-san beszéljenek.) Nem oldhatok meg olyan problémákat, amiket nem értek. Így aztán – miközben a dolgok egy része továbbra is a technikai csapat szakterülete marad – ami az eredményesség növelését és az akadályok elhárítását (vagyis magát a munkámat) illeti, nélkülözhetetlen, hogy tökéletesen megértsem a probléma részleteit ahhoz, hogy megtaláljam rá a lehető legjobb megoldást.
 

5. Elismerések

Ha szüntelenül csak hajtunk és egy pillanatra sem állunk meg, az egyenes út a monoton és unalmas hetek, hónapok, projektek felé. Érdemes alkalmat találni arra, hogy megünnepeljük az apróbb-nagyobb hétköznapi sikereket. Fent kell tudnunk tartani az emberek motivációját, hogy legyen energiájuk átrobogni az akadályokon, és ne fulladjanak ki az első emelkedőnél. Ennek egyik legjobb módja, ha gyakran elismerjük az elért sikereket és az egyéni teljesítményeket. A köszönetmondás történhet szóban, de akár elmehetünk a csapattal egy közös ebédre, vagy adhatunk kisebb jutalom-ajándékokat. Ilyen és hasonló apróságokon múlhat, hogy a kollégák a munkát erőltett menetként vagy hatékony csapatmunkaként érzékelik-e.

Forrás

Szólj hozzá!

Címkék: stand up scrum

OpenAgile - Learning Manifesto

2010.10.26. 16:37  kulcsár bence

 

 

Az OpenAgile célját egy Learning Manifesto-nak nevezett nyilatkozatban deklarálja.

Olyan környezet megteremtése amelyben az emberek a őszintén kifejthetik véleményüket és a legtöbbet hozhatják ki magukból miközben hozzájárulnak a szervezetük fejlődéséhez.

A tanulás jelenti a kulcsot az emberi képességek fejlesztéséhez. A tanulás segítségével válik lehetségessé továbbfejleszteni termékeinket, szolgáltatásainkat, folyamatainkat és eszközeinket illetve kommunikációnkat.

Az OpenAgile által kívánatosnak tartott tanulás jellemzői:

Rendszeres vs. Ad Hoc

Mély vs. Sekélyes

Folyamatos vs. Időleges

Alkalmazott vs. Elméleti

Megosztott vs. Védett

Ha ezekkel a kvalitásokkal történik a tanulás, akkor megállapítható, hogy az őszinteség és az igazmondás az alapja az előrehaladásnak és a sikernek.

Szólj hozzá!

Címkék: agile learning manifesto

5 dolog amire érdemes Stand-up előtt gondolni

2010.09.23. 16:45  kulcsár bence

A Stand-up meetingek ismerősek az agilis csapatok számára. Azonban könnyen válhatnak napi gyakorlattá akár anélkül is, hogy az előnyeiket kihasználnánk. Ez felveti azt a kérdést, hogy mi is az 5 legfontosabb dolog amire scrum master-ként gondolhatunk a Stand-up előtt?
 

1. Work In Progress

A riportok értelmezése kritikus a pillanatnyi és befejezetlen munka megítélése szempontjából. A tisztánlátás segít feltérképezni a szükséges plusz munkákat, felismerni az elmaradásokat vagy rámutatni az éppen segítségre szoruló feladatokra.
 

2. Tegnapi problémák

Mit riportoltak problémaként tegnap vagy azelőtt az emberek? Megoldódtak ezek a problémák vagy legalább létezik terv ezek feloldására? Kevéssé tud lelkesítő lenni, ha napról napra akadályokról számolnak be a csapattagok és nem történik semmi a megoldásokkal. Van valami sürgős tennivaló?


3. A csapat

A projektek nem csak feladatokból és határidőkből állnak, hanem együttműködő egyének hálózatából. Ahhoz hogy a csapat céljait el tudjuk érni meg kell tudni érteni a csapatot alkotó embereket. Fontos a személyes kapcsolat, a születésnapok, a közelgő esküvő vagy nyaralás időpontjának ismerete. Minél inkább integráltak az csapattagok a csapatba annál finomabban lehet hangolni a teljesítményt.

 
4. Időtúllépés

Nem minden akadályt gondol a csapat valóban akadálynak. Néhány akadály egészen szövevényes is lehet, és inkább csak csak lelassítja a tempót, mint blokkolná a továbbhaladást. Vannak olyan feladatok, amelyek lassabban haladtak, mint ahogy reméltük? Vannak olyan feladatok, amelyek új feladatokat vontak maguk maguk után? Ezekre a jelenségekre különös figyelemmel kell lenni stand-up alatt. Ha a problémák rövid idő feloldódnak, nincs gond, ellenkező esetben micro-menedzsmenttel lehet segíteni a fókuszáltságot. Tény, hogy bármelyik projekt során előfordulhat, hogy valamely feladat tovább tart a tervezettnél. Ha a csapattagok hosszabb időre lehorgonyoznak egy feladatnál, vagy ingadoznak az egyes döntések között, sürgősen érdemes külső nézőpontokat és véleményeket meghallgatni, vagy szakértőket bevonni az akadály mielőbbi feloldása érdekében.
 

5. Mit fogunk mondani

A csapattagoktól elvárjuk, hogy rendelkezzenek elvégzett feladat-, tervezett feladat- és akadálylistával rendelkezzenek, nekünk pedig képesnek kell lennünk ugyanezekről beszélni, vagy éppen összefoglalni őket a többiek számára. Ha a scrum-master elhárított egy akadályt, természetesen informálnia kell a csapatot róla, továbbá érdemes az egész sprint státuszáról is áttekintést adni. A jó információáramlás elősegítése céljából érinteni lehet költségvetési, hr vagy menedzsment témákat is.


Kétségtelenül sok más egyéb dolog is szóba jöhet (közös vállalás, vízió, energizálás, stb.) de talán érdemes ezzel az 5 ponttal kezdeni.

Forrás

Szólj hozzá!

Címkék: stand up scrum