Pivotal tracker, mint eszköz a vízesés fejlesztésében, savepearlharbor
Az orosz outsourcing piacon nem sok vállalat használ rugalmas fejlesztési módszereket (Agile). Mindenki megszokta, hogy egy kaszkád modellen dolgozik (vízesés). Ugyanez vonatkozik a mobil fejlesztési szektorra is.
Az ügyfélnek szinte mindig van egy költségvetése, vagy elvárásai a költségre, valamint a végső feladat - egy bizonyos funkcióval rendelkező alkalmazás. Azonban a mobil mobil fejlesztés Agile alkalmazás indokolt.
Kihelyezzük a mobilalkalmazások fejlesztését, bár az Agile eszközt - a Pivotal Tracker (a továbbiakban: PT) - használjuk. Szeretném elmondani a tapasztalat felhasználásának ebben a cikkben.
Mi kell?
Amikor dolgozik a fejlesztő csapat - a projekt vezetője, több fejlesztő és tesztelő -, akkor az egyik lényege (a lényege ennek a feladat, a feladat, a felhasználó-történet, akár nem) lehet néhány állam, a felelős személy és előadóművész. Ezért sok klasszikus feladatkezelő nem alkalmas számviteli fejlesztési feladatokra.
Végül arra a következtetésre jutottunk, hogy a lényegnek a következő jelentéssel kell rendelkeznie:
Mit kérek?
A piac számos eszközt kínál a csapatmunka számára (mind az iroda, mind a távoli alkalmazottak számára). Csak a kezelő, a fejlesztő és a tesztelő interakciójának eszközeit tekintjük át. A kommunikációs menedzser az ügyféllel, a tervezővel és más kötegekkel rendelkező menedzser nem igényel speciálisan élesített eszközöket, de vannak érdekes gyakorlatok itt - egy másik cikkben.
Egyszerre azt fogom mondani, hogy munkafolyamatunkban nincs helye papírnak, minden eszköz csak a számítógépen van. Alapvetően most több szolgáltatás érhető el a SaaS modellen, de vannak olyan megoldások is, amelyek telepíthetők a kiszolgálón.
Valószínűleg ez a legelismertebb rendszer nyomon követési feladatok, viták, fájlok és hasonlók számára. Ezért egyszerű, megbízható és kényelmes. Nagyszerű a vezetői feladatokhoz - egyszerű ellenőrző listák, viták, közös szövegszerkesztés. De ez nem alkalmas fejlesztési feladatokra.
A feladat lehet egy bizonyos listán, előadó lehet, lehet, hogy van egy határidő. Tudom, akik, hogy készítsen egy feladat, hogy egy adott termék verziója (1.0 verzió) írta a helyes verzió (Taxco címe „Szavazz értékelése [3,4]), és felsorolja meghatározásához használt Egy feladat állapotának (” tervezett „” A folyamat során a "," Befejezve ").
Talán egyszerű projektek - egy menedzser és egy fejlesztő - a Basecamp felbukkanhat, de a rendszer összeomlik, ha 2-3 projektfejlesztő, tesztelő és projektmenedzser van a projektben.
Egy jól ismert platform, amelyet sok fejlesztő szeret. Telepítve van a szerveren, könnyen testre szabható, sok modulja van. A feladatoknál a kezelő-fejlesztő-tesztelő nehézkesnek tűnik. Az interfész aszketikus, és ha létezik egy "Apple agy" akkor egy ilyen eszköz használata gyászol =)
Egy szörnyeteg egy olyan cégtől, amely minden állatot evett a szoftverfejlesztő eszközökben. Testreszabott, skálázott - néha zavaros és drága, de sokan szeretik.
GitHub kérdések
Tudom, hogy bizonyos körökben a TFS népszerű, de bocsásson meg nekem - attól is félek, hogy ott nézek ki)
A Themed Media-tól származó srácok azt tanácsolták, hogy nézzék meg az Asanát, de valahogy nem is tapadtak.
Miért a Pivotal Tracker?
árképzés
A PT nem ingyenes termék, meglehetősen jó pénzhez jut, és működik a SaaS modellen.
Havi 100 dollárért lehetősége van korlátlan számú projekt és 25 résztvevő létrehozására.
A PT integrálható a Google Apps szolgáltatással, akkor könnyebb meghívni az alkalmazottakat a projektekbe, és közvetlenül a feladatokhoz csatolhatja a dokumentumokat a Google Drive-ból (például a leírt logikával).
A PT sok érdekes és rejtett funkcióval rendelkezik, szinte mindent leírtak egy hosszú segítségnyújtásban - www.pivotaltracker.com/help.
Általános szabályok
Nem használjuk a felhasználói történet fogalmát, ahogy az valójában. Számunkra egyszerű feladat / feladat.
A PT-ben négyféle feladat van: funkció, hiba, feladat és kiadás. Ezeket a típusokat az alábbiak szerint használjuk:
Feature - alapvető funkciók a funkciók megváltoztatásához vagy javításához
Bug - hiba száma Crashlyticsben, vagy a hiba rövid leírása
Release - a build verzió neve (alfa, béta és rc)
Chore - a fejlesztéshez vagy kiadáshoz közvetlenül kapcsolódó menedzser feladatok
A lila címke epikus - ezt verzióként használjuk, amelyre ez a funkció megy.
A zöld címke egy címke - azt használjuk, hogy meghatározzuk azokat a szakaszokat, amelyekre ez a funkció vonatkozik (például a blog nézet).
Minden feladat vezethet beszélgetés egy hivatkozást a másik csapat tagjai (érkeznek notifay), akkor add a fájl (leggyakrabban screenshotok, mint a UI-bug), lehetséges, hogy végezzen sabtaski (kényelmes pixel tökéletes kiegészítései).
Minden epikus (epikus) eredetileg külön lapon tárolódnak. Mindig megnyithat egy epikus versenyt az alkalmazás egy régi verziójával, és megtekintheti, mikor valósult meg egy adott szolgáltatás, valamint egyszerűen tervezzen ütemtervet a jövőbeli verziókhoz. Minden epikusnak saját egyedi száma van, éppúgy, mint a feladat - mindig közvetlen linket adhat.
A PT interfész egy panel: alap - lemaradás, jégkazetta, áram. Mi kizárólag a hűtőláda panel (tárolására ötletek és azok Taxco, amelyek nem szerepelnek semmilyen verzió még), és a lemaradás (szalag jóváhagyott feladat), valamint a panelek, amelyek miatt az epikus - tükrözik a feladatot csak a kiválasztott változat. Első pillantásra az a személy, aki nem használja ezt, nagyon furcsanak tűnik - de akkor olyan rendszeresen használod ezt a rendszert, hogy egyszerűen nem nézhetsz másra.
Közvetlenül munkafolyamat
A menedzser a kézben tartja a TK és az útiterv változat szerint. Megkezdődik a feladatok létrehozásának folyamata. Minden feladat feltétlenül csatolni Öpik (ha fejleszteni a semmiből, általában 1.0 verzió) és a címkét a listán (használjuk a címkén, mint a képernyő, vagyis a parancs „csapat” képernyőn a játék egy „match” képernyő). Minden feladat az Iceboxba esik.
Ezután a feladatok a Backlog-ba kerülnek. Ettől a pillanattól kezdve jóváhagyásra kerülnek, és minden előadónak telepítenie kell egy előadóművészt. Ha van egy fejlesztő a projekten, akkor ez nem szükséges. Ha több fejlesztő van, akkor a feladatok elosztását a projekt időjárása végzi.
Minden feladatnak összetettsége van - ez valamiféle absztrakt érték a pontokban (a sebesség kiszámítására használják, de nem használjuk). Az érték beállítása nélkül azonban a feladat nem indul el. Miután a fejlesztő elindítja a feladatot, megnyomja a Start gombot. A feladat végén a fejlesztő kattintson a Befejezés gombra. A feladat következő lehetséges állapota a Kézbesítve lesz. Ez akkor fordul elő, amikor a fejlesztő feladatot lát el a gyülekezetnek.
Pénteki gyűléseinket végezzük, már elvégezték a feladatokat. Az összeszerelés során a fejlesztő azokat a feladatokat jelöli meg, amelyek bekerülnek az összeszerelésbe, és amelyeket a projektmenedzser hozhat. A menedzser el tudja fogadni a feladatot, ha úgy gondolja, hogy a feladatot úgy kell végrehajtani, ahogyan kell és működik, vagy határozhat az ok indokolásával. A csökkentés után a feladat Elutasított állapota (a "Restart" gomb), és újraindíthatja.
Így bármikor megértheti, hogy egy adott fejlesztő mit csinál, milyen feladatokat hajtanak végre, és bekerülnek a közgyűlésbe, mi más a fagyasztóban stb. Nagyon kényelmes és nyilvánvaló, a feladatok sorrendje is könnyen megváltoztatható - pl. Egy kiadás keretében, vagy a következő kiadáshoz.
A pénteki összeállítás áttekintése után a menedzser is létrehozhatja a hibákkal kapcsolatos feladatokat. Béta és rc állapotú kiadások esetén egy tesztelő csatlakozik, ami hibás hibákat is létrehozhat. Akkor és ő felel azért, hogy elfogadja őket, vagy újratárgyal a fejlesztő rögzítése után.
Amikor a feladatot kézbesítik és elfogadják, zöld lesz, és a feladat lezárul.
A fejlesztők szeretnék megadni a feladat GitHub ID-ben történő elkövetését, majd a nyomógombbal a feladat automatikusan befejeződik.
Jellemzők
Nagy projektekben a feladatok száma akár ezer is lehet. Meg tudod oldani a saját alapelveidet a létrehozás és felhasználás során.
Automatikus felépítési kiszolgáló esetében a Delivered feladat állapotát módosítani kell, ha a változtatások elkötelezettek a repositóriumban, mert az összeszerelés automatikusan megtörténik. Nos, itt minden csapatnak megvan a saját vonása.
A Pivotal Tracker kitűnő iPhone / iPad alkalmazásokkal rendelkezik (míg az igazság az iOS7-hez való hozzáigazítás nélkül van), vannak harmadik féltől származó ügyfelek is az Android számára. Integrál minden külső szolgáltatással - a Github, a Campfire, a FlowDock, a HipChat, a Zendesk stb.
Nem biztosítunk hozzáférést a Pivotalhoz az ügyféllel, de ilyen esetben a trackerben lehetőség van "megfigyelő" meghívására a "csak olvasható" jogokkal.
következtetés
Az AviaSales-i barátaink is ezt a szerszámot használják mind a szerverfejlesztés, mind a mobil fejlesztés részlegében. A Bambk barátai a Pivotal szerverfejlesztést használják. Mindannyian nagyon örülünk, hogy egy ilyen eszköz létezik a piacon, és ténylegesen biztosítja a szükséges lehetőségeket. A Pivotal Tracker alkalmazásának megvalósítása lehet akár egy kis induló csapat vagy egy komoly csapat nagy termékprojekt vagy kiszervezési fejlesztés.