Scrum (Scrum) és Agilis fejlesztés

Tegyük fel, hogy menjen a házába, üljön a régi kanapén, ami kilóg a tavasz, nézd meg a régi, peeling a bútorok és azt mondod magadnak: „így nem mehet tovább!”. Azt erősen akarjuk cserélni az összes régi, elhasznált bútorok egy új, környezetbarát és praktikus, személyre szabott kifejezetten az Ön igényeinek. És az a lehetőség fogyasztási cikkek IKEA - nem vették figyelembe, ezért van, hogy a saját, pontosan tisztában konkrét követelményeket a hazai ...

Elmész egy nagyon cool mester, őszintén azt hiszik, hogy csak a pro képes arra, hogy a valóság a vágyakat. Kiderült, hogy a várakozás lesz szükség körülbelül egy hónap. Elsodorta a hullám száma a lelkesedés, de a döntés született. Igen, és nagyon kellemetlen, hogy visszatérjen a kopott varjútanya. Ön előre fizet, mondja el elképzeléseit a tervező, aki megszerzi az összes részlet, megkérdezi intelligens kérdéseket, aláírja a szerződést, és

Várj. Vársz egy hosszú hónap, amelyre ígéretet tettek, hogy tegyen meg mindent. És egész idő alatt - a régi, kényelmetlen bútorokat kap, hogy a szem és a láb, idegesítő. Várj. Valahol kapott az öröm spontán vásárlások? Egyik műhely van hívás nem különösebben aggódik, nem elszámoltatható, nem kérdéseket feltenni ... Várj.

És akkor várjon még két hétig. És te már a düh. A korábbi meghatározás ez nem sok - de megéri merészkednek minden mocskot? És akkor várj egy kicsit, és további három órán át, amit a bal munka elején. Tehát, hogy egy új készlet. Gyűjtse, rendezi, és az elméd már elég határozott elképzelés. Nem!

Ha nem használja Scrum

Ez nem az, amit elképzeltem. Erre van lehetőség, és megfelel annak, amit mondtál a tervező, de ez nem az, amit meg kell. A kárpitozás túl világos, és nem tetszik az új barátnője. Emellett azt találták ki, hogy a kutya - allergia toll párnák. A tábla túl nagy, és az ülések - túl terjedelmes. De ez mind egyetértettek a gyártó, és az aláírást. Semmi sem változik - vagy inkább, akkor, de ez fog kerülni az azonos mennyiségű pénzt, és úgy ugyanannyi időt. Körülbelül garancia az eredmény soha nem mondják.

Management szoftver fejlesztése - ez majdnem olyan, mint egy útmutató bútorgyár

By the way, tudod, hogy miért volt szükség olyan sokáig várni? Lehet, hogy örömmel úgy gondolja, hogy a mester dolgozott heteken fedélzeten minden a fülhallgató vagy hímző napon készült öltés által öltés, hogy ez az idő, hogy egy jó minőségű hímzés. Mit jelent mindez óránként csekket a design és minőség vezetője éberen vigyázott a termelés.

Először is, meg lehet rendelni egy szakaszos fejlesztése a bútorok, amelyek fejlesztését kell végezni a világos prioritásokat az Ön által beállított. Tegyük fel, hogy több kell, mint egy kanapé, mert a régi elég ahhoz, és a szék és asztal még egy kis türelem. Ennek megfelelően, a kanapén lesz az első a listán a prioritások, és a stúdió elkötelezett előállítani és szállítani, hogy az első helyen.

Mit tegyek? Először találkozik a legfontosabb igényeket először, és a rugót nem nyikorog éjjel. És másodszor, ha az új barátnője csak nem szeretem a kárpit és szín erősen akarja változtatni (a kárpit, nem a barátnőm) - a költségek csak a kanapén, anélkül, hogy változtatni a kárpit a székek (azaz a még nem kész .. ). Vagy még akkor egyáltalán nem költséghatékony megváltoztatni az összetételt a rend eltávolítja őt a székből és a hozzá törökök.

Másodszor, megkérdezheted a stúdióban minden nap, hogy meséljek a haladást. Csak három egyszerű kérdésre: mi történt tegnap, mik a terveid mára, hogy mik a problémák - és teljes ellenőrzése alatt a helyzetet. És ez jó!

SCRUM segítene egy olyan helyzetben, ahol ...

• Egy csomó pénzt és időt töltött a kidolgozásában TOR, de a projekt során megváltozott a koncepció, vagy üzleti folyamatokat. Ahhoz, hogy a projekt a gyümölcsét formában, ahogy az a TK - nincs értelme. Pénz TK dobott hiába. A fejlesztő nem hajlandó változtatni menet közben, utalva TK.
• Fejlesztő projekt azt mutatja, az utolsó előtti napon a dob. Azonban minden nem úgy, ahogy azt képzelni. Kell jelentős átdolgozást. A fejlesztő a maga módján értelmezi leírt követelményeknek a TOR és megtagadja, hogy bármilyen változás a projekt ezen az alapon.
• Meg kell futtatni a gerincét az internet projekt a legalacsonyabb lehetséges költségvetési és időrendben. További funkciók fejlesztése az indulás után, amikor a projekt kezd verni a kezdeti befektetés.

Ismerős? Valószínűséggel alakul óta használják a „vízesés” modell, vagy az összes még ment a-borzalmas. Scrum - Ez egy alternatív, mentes a hátrányai a fent felsorolt. Ennek okai:

A szerelők a folyamat web-fejlesztés

Ok, menjünk tovább, hogy egy egyedi webdesign. Arról, hogy milyen kiadni szerződéses kapcsolatban elmondom a végén. És mégis - nézd meg, hogyan működik a folyamat kerül kialakításra. Feltételezem, hogy a fő szempont a boldogság az ügyfél - ez mikor lesz nem csak egy termék megfelel az eredetileg meghatározott feladatmeghatározás, de amit igazán akart. És ez lesz a termék a lehető leggyorsabban. Tegyük fel, hiányozni fog néhány funkció, és végrehajtja a pályán, de a projekt azonnal megkezdődik, hogy a pénz nem várta meg a teljes körű végrehajtása az összes kis belső részleteket.

Ezután csak azokat a programozási fázisban (az egyszerűség kedvéért), de ha szükséges, ez a megközelítés lehet terjeszteni más munkafázis. Megjegyezzük, hogy a legjobb Scrum manifesztálódik technikailag összetett projektek nagy mennyiségű programozás (bár is alkalmas tipikus helyek szerelvény egy adaptáció). Tehát munka Scrum következik.

Hátralék helyett műszaki előírások

Elmaradás - egy dokumentum, amely felsorolja az összes projekt követelményeinek (látás, a projekt egy listát, hogy mit kell végrehajtani). elemek listáját fontossági sorrendben. A projekt során, és a prioritások listáját változhat, attól függően, hogy az ügyfél igényeinek, az új ötletek, vagy változó körülmények között.

Igen, egy klasszikus Scrum értetődő, hogy a projekt tulajdonosa a változtatásokat közvetlenül a projekt során (de nem a jelenlegi fejlődési szakaszában). Azonban abban az esetben, webes fejlesztés, a költségvetés nagy része fix (kivéve - néhány startup-projektek). Ez azt jelenti, hogy az ügyfél és a lehetőséget, hogy befolyásolja a haladást - túl korlátozott.

Mindazonáltal úgy vélem, hogy annak szükségességét, hogy kiegészítse, vagy módosítsa a funkciók a projekt nagyon fontos az ügyfél számára. Ez segít, hogy dolgozzon ki egy projekt, amely valóban szükséges az ügyfél, ahelyett, amit formálisan leírt feladatmeghatározás. Ezért, mivel a hátralék-és hajlamosak vagyunk használni a feladatok listáját a műszaki előírásoknak vázolt és a szerződésben rögzített, valamint fix ext. Felülvizsgált megállapodás során felmerülő munka.

Sprint - a fejlődési szakaszban. Minden projektfejlesztés egy rövid szakasz (sprint). Funkciók, hogy végre kell hajtani minden sprint - fix (nem tudnak változtatni során a sprint). Ezek bontani feladatok és a feladatok már a becslések és prioritásokat.

A klasszikus Scrum feltételezhető, hogy az időtartama a sprint fix és általában a tartomány 2-4 hét, attól függően, hogy a parancs tapasztalat. Mivel nem minden helyen megkövetelik ilyen hosszú fejlesztési szakasz (különösen ha figyelembe vesszük, hogy a fejlődés 2-3 programozók párhuzamosan), úgy döntöttünk, hogy korlátozza csak a maximális időtartama sprint. Közelítettük a kéthetes gyorsul. Azonban, ha a csapat építeni a projekt 3 napig - azt értjük, amely egy 3 napos sprint.

Az eredmény minden sprint válik teljesen tesztelt projekt, amely megvalósítja az összes funkcióját előző sprint + alkalmassága az áram növekedése. Ez lehetővé teszi, hogy indítsa el a projekt legkorábbi szakaszaiban végrehajtási csak a szükséges minimális funkcionalitás, és már párhuzamosan a munkaterületen elvégzésére fejlesztés a következő legfontosabb része a projektnek.

Ez a megközelítés jó, például az online kiskereskedők, hogy lehet kezdeni eladási (start hozza nyereséget a vevő) az összes funkció fogant üzembe.

Xy a projekt

A fejlődő dulakodás a projekt van egy pár kulcsfontosságú szerepet. Product Owner - tulajdonosa a termék. Felelős érdekeit képviselő az ügyfél és a végfelhasználók számára a projekt. Ő nem tagja a fejlesztő csapat. Ideális esetben meg kell egy képviselője az ügyfél. Mivel azonban ez a szerep ró nagyon magas követelményeket támaszt a tapasztalat és kompetencia az egyén a tervezés és fejlesztés az internetes projektek, valamint szükség van folyamatos személyes részvétele a projektben (ami nem mindig lehetséges, hogy az ügyfél) - ebben az esetben ezt a szerepet a projekt vezetője.

És persze, a projekt egy csapat a fejlesztők :-) És: Scrum Master - tagja a csapatnak, amely figyeli a elveivel összhangban a Scrum és lebonyolítása napi tájékoztatók. A szerep nem jelent további hatásköröket a projekt, kivéve a Scrum-a.

Work szakaszosan és prioritások