Meet, vízben dulakodás esik!

ismeretség
Üdvözöljük a WaterScrumFall!
„Nem kétséges, hogy az agilis vált a fő iránya a mozgás, de a valóság az, hogy a legnagyobb csapatok szegmensben 40 százalék, nem nyelvművelő. [1] követi bármelyike előírt metodikával. Nincs egy tökéletes folyamat - a csodaszer, - vízesés, Agilis (Scrum), RUP, vagy más „- írta később a jelentésben.
Ebben Deyv Uest és kollégái azt írta, hogy a 10 év megfigyelései Agile bevezetése a cég Forrester szervezetek arra a következtetésre jutott: „Hogyan Agilis valósul meg a gyakorlatban, nagyon eltér az eredeti ötletek vázolt Manifesto és sok szempontból ez a megvalósítás hasonló az mi Forrester felhívja Víz-Scrum-ősz».
A szóban forgó jelenség ezekben a jelentésekben - Vízzel Scrum-őszi, - a hibrid módszertan a szoftverfejlesztés. Ez eredetileg egy válasz kísérletet alkalmazkodni Agile, hogy a valós körülmények között munkaszervezetek.
Egy tipikus rendszerben a víz-Scrum-ősz ábrán látható 1. Ez az ábra azt mutatja, a gyakori munkamegosztás szakaszosan Víz, Scrum és őszi.

1. ábra A víz-Scrum-ősz
Víz fut a színpadon követelmények fejlődése és tervezési rendszerek alapján őket, amit aztán a becsült költsége a teljes projekt és tervezés. A színpadon Scrum - iteratív szoftverfejlesztési és unit-tesztelés. És őszi szakaszban - a rendszer tesztelése kiadása által kiállított melynek eredményei vagy visszaküldik az ellenőrzéshez, vagy kap a „jó” a szállítás és a telepítés. Ha szükséges, ezt a lépést végzünk, és integrációs tesztelés. Ha sikeres termék kiadása végezzük.
Kezdetben úgy tűnt, hogy az agilis módszereket kell nyerni elég gyorsan a szoftverfejlesztési piacon, és a feltörekvő, itt-ott a hibrid módszerek látták ideiglenes, átmeneti jelenség az úton a klasszikustól a Agile. Azonban, ahogy telt az idő, és a hibrid módszereket nem haldoklik, minden erőfeszítés ellenére, hogy támogassák Agile. Ma már nagyon is életben van. És azt nem lehet figyelmen kívül hagyni, meg kell magyarázni vitalitását.
Az okok a vitalitás Víz-Scrum-ősz
- Sense az önfenntartás.
- Feltételek Investment Management.
- A termék életciklusa.
Nézzük őket részletesen.
A. A értelemben önvédelem
Ma, „do Agilis» divatos és egyet az innováció. De a vezetők a szervezet és a tulajdonosok óvatosak és hoznak Agile csak részben szórva a legjobb esetben, a szoftver fejlesztési csoport, míg a tervezési, release management, és még tesztelés összhangban vannak a megszokott, klasszikus munkamódszert. Az okok ezek a döntések több tényezővel magyarázható.
Először is, a hatása a vállalati kultúrát.
Kultúra eszik stratégia reggeli
- mondta a nagy Peter Drucker (Peter Drucker).
Más szavakkal, a kultúra a szervezet ellenállt az új stratégiák és módszerek, mert a fenyegetés, és ez a kultúra és a szervezet felépítése [29,40,41].
Másodszor, a bevezetése egy új módszert igényel beruházást változik a szervezeti struktúra, menedzsment, IT, képzés stb De ma nincs olyan módszer, amely lehetővé teszi, hogy kiszámítja a gazdasági bevezetésének hatása Agilis már dolgozik és a jövedelem termelés. Már csak összefoglaló adatokat valaki másnak a tapasztalata, bemutatott statisztikai jelentéseket. Azonban ezek összesen többször kitéve komoly kétségei vannak az Egyesült Államokban és Európában [36,37]. Technikájára vonatkozó statisztikai mintavétel és feldolgozás ezek a jelentések általában zárt, és ez nem lehet következtetéseket levonni a minőségi adatokat, sem a minősége a kapott eredmények nekik. A vita már folyamatban van egy második évtizedében, a kutatások azonban megtagadják, hogy hozzáférést biztosít az alkalmazott módszereket.
Ezt felismerve a szervezetek vezetőit mutatnak némi egészséges önfenntartás és nem siet, hogy megtörjön a munka vállalkozásfejlesztési agilis szoftverfejlesztés csoport.
B. Investment Management szabályzat
Az Egyesült Államokban a pénzügyi számviteli és beszámolási minden projekt végzik megfelelően a FASB (Financial Accounting Standards Board) és a FASAB (Federal Számviteli Standard Tanácsadó Testület) szabványok, az állami és magánvállalatok.
Szabályzat pénzügyi számviteli és jelentéstételi meghatározott SOP 98-1 szabványok [33], valamint az FASB SFFAS 10 [34] és a TR-16 [35] FASAB olyanok, hogy a használata Agilis módszertanok létrehozásakor szoftver belső projektek nem jelent problémát. És ez az egyik oka a bevezetése Agile siker a hazai IT projektek az Egyesült Államokban.
A külső projektek nagyon eltérő képet. Finanszírozásuk beleesik az Egyesült Államok mellett az elszámolási szabályok beruházási (CAPEX) - akkor lép hatályba, egyéb rendelkezések. Különösen a finanszírozók kliens szoftver, először meg kell számítani a projekt értéke és a becsült bevétel létrehozása és végrehajtása. Megtehetik, csak az alapján a kidolgozott követelmények szoftver termékek. A pontosság a számítás a projekt költség és a jövedelem annak értékesítése közvetlenül függ részletes követelményeket és minőségi.
A megoldás erre a problémára, és ezt tükrözi a kompromisszumos megoldás - egy hibrid módszer: ahhoz, hogy a szabályokat a szabályozó szervezetek eleget tesznek a fejlődés, majd költségeinek becslésére azok végrehajtását, és elvégzi a tervezés keretében a vizes fázisban. És továbbá, az eredmények ebben a szakaszban a fejlesztési táplált csoport, egy gyakorló, például SCRUM.
C. termék életciklus
Elég gyakran, a szoftver nem rendelkezik önálló értéke a fogyasztó számára. Például a létrehozását televíziós projektek, autók, műholdak stb Szoftver - ez csak egy összetevője ezeknek a termékeknek. Ebben az esetben a szoftver fejlesztési folyamat egyik szakaszában a termék létrehozásának folyamatát, és alkalmazkodik a környezetéhez.
Jellemzően az alkotás folyamatát ilyen termékek igényel részletes tervezés a teljes rendszer kezdete előtt a végrehajtás - a gyártás „vas” és a szoftver.
Erre azért van szükség, hogy:
- meghatározását rendszer architektúra - a készítmény az összetevők és azok kapcsolatát;
- kiosztási követelményeket egyes összetevőit kell megvalósítani;
- ellenőrzési követelményeket az eladott termékek;
- párhuzamosítását művek létrehozására a termékek egy részét;
- meghatározza a megvalósíthatóságát a meglévő termelési kapacitás vagy szorulnak felújításra;
- meghatározzák annak szükségességét, hogy az új technológiák létrehozására szoftver elemek;
- szinkronizálja a termék kínálat alkatrészek integrációs tesztelés.
Ezért kísérletet Agile végrehajtására életciklusában az ilyen termékek lokalizált szinten szoftverfejlesztés. Ugyanakkor a fejlődés szerint végezzük korábban kidolgozott követelményeknek. És a víz képződik a lépést, és Scrum (lásd. 2. ábra).

2. ábra Tipikus termék kiadása rendszer Víz-Scrum-ősz
Továbbá, a végső tesztelése a szoftver kell várni szállítás a „vas”, hogy valós körülmények között teszteli a szoftver funkcióit. Így az egész folyamat befejeződött integrálásával összetett termék tesztelése általában - őszi szakaszban.
Az összes fenti nemcsak a projektek létrehozására szellemi technológia, hanem a komplex információs rendszerek - anélkül párhuzamosítást működik szállítása ilyen rendszerek elfogadhatatlan lenne, és a párhuzamos munka nélkül lehetetlen az előzetes tervezés a teljes rendszer [39]. Végső összeszerelés és tesztelés, és szükséges lépés az életciklus rendszerek.
következtetés
Így az oka a kialakulásának és fennmaradása Víz-Scrum-őszi objektív, és ma nincs bizonyíték, amely arra utalna a közelgő eltűnése ezt a jelenséget.
üzletviteli szabályok, a pénzügyi számviteli és beszámolási gyártása az Egyesült Államokban változatlan marad. Változtathatatlan, a függőség a folyamat a szoftverfejlesztés folyamatát, a létrehozása a termékek általában. A vállalati kultúra még mindig ellenállást változtatni a kialakult és nyereséges folyamatokat és megakadályozza, hogy a bevezetése „tiszta» Agilis [42,43].
És a paradoxon ez a jelenség abban rejlik, hogy a több szervezet próbál bevezetni az Agile, minél több közös hibrid módszert.
[1] purista-harcosa a tisztaság erkölcsi, vallási