Hogyan keltsünk életre egy Xiaomi asztali LED lámpát 5 perc alatt?

Otthonunkba került egy Xiaomi asztali LED lámpa, amiről kinézete alapján nem sokat vártam, de kellemesen csalódtam. Amikor kezembe kaptam a készüléket nem tudtam róla semmit, csak azt hogy okos lámpa.

De kezdjük az elején.

Design, csomagolás

Szép fehér dobozban érkezett a lámpa, de aki Apple és Nest termékek csomagoláshoz van szokva, kicsit csalódni fog. Semmi extra, de más az érzés.

A lámpa kapott egy fólia csomagolást is, illetve a doboz tartalmazott még egy kicsi adaptert, hogy itthoni hálózaton is lehessen használni.

A lámpa viszonylag súlyos darab (800g), de csak a talpa, így nagyon stabilan áll. A kábel elegendő hosszúságú, szép vékony fehér.

Csupán egy gomb található rajta (illetve az alján egy reset gomb, erre később visszatérek), így nem is értettem mitől lenne okos, használati útmutató nem volt a dobozban (frissítés: nekem hiányzott a dobozból, de amúgy van benne).

A külső kialakítás nekem nagyon tetszik, letisztult forma, kompakt méret, a világító rész teljesen lehajtható a tartó oszlop mellé. A zsanér a gyártói oldal szerint nagyon bonyolult szerkezet és tartósnak is tűnik, szépen mozog, nem akad, stabilan áll az adott helyzetben. A tartó oszlop magassága 45 cm és maga a fej és ugyanennyi. A talapzat 15 cm átmérőjű.

Beüzemelés

A termék gyártói oldalán kezdtem el keresgélni esetleges applikáció után, de a szép termék bemutató oldalon sehol nem volt app link.

Egy kis kutakodás után találtam két appot, az egyik a Yeelight a másik a Xiaomi cég saját alkalmazása a Mi Home. Ez utóbbi kínai nyelvű app ikon aláírással jelenik meg az appok között.

Feltelepítés után végig vezet a setup folyamaton, ahol:

1. első lépésként ki kell választani a terméket, amit használni szeretnénk

2. kapcsoljuk be a lámpát a rajta levő gomb megnyomásával (ezt jelzi az app)

3. adjuk meg a wifi hálózatunk belépési adatait, majd kicsit várni kell

4. lépjünk át a Settings-be és az elérhető wifi hálózatok között meg fog jelenni a lámpa saját hálózata

5. ezt válasszuk ki majd lépjünk vissza az appba és már ott lesz az elérhető készülékek között a lámpánk

Érdemes megjegyzeni, hogy 2.4 GHz-es hálózatra képes csatlakozni és jobb megoldás a wifi használata, mint a Bluetooth, hiszen így a lakás bármely pontjáról vezérelhetjük, nincs gond a hatótávolsággal.

Én először a kínai appal kezdtem, majd utána próbáltam ki a Yeelight appot. Viszont mivel a készülék már hozzá volt adva az első apphoz, így resetelni kellett a lámpát. Ezt a talpán található bemélyedésban lévő apró gomb 5 mp-ig tartó megnyomásával érhetjük el. Ezután újra végig kell menni a beállításon.

Nos, készen volt az okos LED lámpa a használatra.

Használat

A smart lámpán található oldschool gomb használatával be- és kikapcsolni tudjuk, illetve a fényerőt szabályozni.

Az appon keresztül ennél már jóval több lehetőségünk van, amivel elég sokat lehet játszani (a gyerekektől alig tudtam visszakérni a telefont...) :-).

- szabályozható a fényerősség

- szabályozható a színhőmérséklet

- választhatunk előre definiált mode-ok között (olvasás, gyertyaláng, számítógépezés) vagy létrehozhatunk mi is sajátokat

- elláthatjuk "gyerekzárral" (korlátozhatjuk a színhőmérsékletet)

Mi Home app - szín beállítás

Az alap funkciókon kívül lehetőség van külső szolgálattókhoz való csatlakozásra (Amazon Alexa, Google Home), illetve IFTTT parancsok (ha X esemény bekövetkezett, akkor Y lép életbe) tervezésére.

Nagyon jó ötletnek tartom a Pomodoro módszer integrálását, vagyis beállítható, hogy pl. 45 perc után automatikusan lekapcsoljon a lámpa és 15 perc után kapcsol csak vissza, így kényszerítve minket egy kis szünet tartására, illetve segít beosztani az időnként, anélkül, hogy erre figyelnünk kéne.

Összeségében egy egyszerű, látványos, de mégis letisztult formavilágot felmutató okos lámpát kapunk, teljesen normális összegért. Maga az applikáció (Yeelight) is jól használható, így bátran ajánlom ezt a LED lámpát, nem csak kütyü bolondoknak.

Tapasztalat:
- masszív kialakítás, szép design

- nagyon jó erős fénye van a lámpának

- jól használhatóak az előre definiált beállítások

- nincs egyértelmű utalás, hogy milyen appal használható

- kicsit keszekusza az app navigációja

MVP a bútorgyártásban, avagy az agilis munkamódszer bemutatása egy hétköznapi példán keresztül

Környezetemben sokak számára néha nehéz elmagyarázni mit is csinálunk pontosan, mit jelent az agilis munkamódszer, amiben dolgozunk a fejlesztő csapattal. Alább egy hétköznapi példával szemléltetném, nagyjából mi a munka folyamat egy ilyen környezetben.

A legidősebb fiam szeptemberben iskolába fog ment, így már kirajzolódott a nyári események egy része: iskolatáska, füzetek, íróasztal vásárlás. Ezek közül a legutóbbi volt az egyik legfontosabb és a legnagyobb körültekintéssel kiválasztott dolog, hiszen sokkal könnyebb megfelelő környezetben alkotni.

Persze ennek az asztalnak helyet is kell találni, ami a jelenlegi gyerekszobában nem volt. Ennek egyik oka, hogy a fekvőhely és a ruhás/játékos szekrény az előző lakhelyünkről lett áthozva és nem passzolt a tetőtéri kialakításhoz. Így adta magát a feladat: új bútor kell a gyerekszobába. Az ágyat megvettük az IKEA-ba, pipa. De tetőtéri bútort nem nagyon árulnak, így vagy egy asztalost kérek meg vagy magam készítem el. A második mellett döntöttem, hiszen nem áll távol tőlem a barkácsolás.

A folyamat során próbáltam az agilis módszertanról tanultakat alkalmazni, nem lövöm le a poént, lássuk hogy sikerült.

1. Követelmény elemzés

Felmértük a szoba adottságait, hogyan lehetne a legoptimálisabban kihasználni a teret. Egy külső tényező, a megvásárolt ágy, amely kihúzható, korlátozta a szabad hely forrást. A jövőbeni külső tényezők növekedésével is számolnunk kellett, az íróasztalnak is kellett helyet találni, lehetőleg úgy, hogy természetes fény érje. Így a tetőtér beépítése mellett döntöttünk a szoba teljes hosszában.

Felmértük, hogy milyen célt szolgálna az új bútor: ruhák tárolása, játékok tárolása. Mivel a már meglévő ágy, főleg kihúzva, korlátozza a hozzáférhetőséget a szekrényhez, így olyan tárgyak tárolását is számba vettük, amihez ritkán kell hozzányúlni: pl. téli/nyári ágynemű, téli ruhák.

2. Tervezés

A követelmény elemzésből kiesett funkcionalitásoknak megfelelően megterveztem 3D-ben a szekrényt. IKEA-s kihúzható kosár és tároló dobozok, mint külső tényezők, szintén befolyásolták ezt a szakaszt, így az egyes fakkok, polcok méreteit ezekhez igazítottam. Elkészült a terv az elsődleges mérések alapján, amit jóváhagyott a stakeholder (kedves Feleségem).

3D model

A belső határoló elemeket úgy kellett megtervezni, hogy a polcok nagy része hozzáférhető legyen az ágytól.

3. MVP

Ezután meg kellett nézni, hogy az elképzelés megvalósítható-e, érdemes-e nagyobb beruházást eszközölni. Jelen esetben az MVP célja az volt, hogy ellenőrizzem a mérések alapján megvalósult tervet. Erre főleg a tető hajlásszöge miatt volt szükség, illetve lássuk, hogy értelmesen használható felület marad-e a szekrény teteje és a tető között. Erre létrehoztam a tervek alapján meghatározott méretek szerinti egyszerű váz szerkezetet meglévő léc darabokból:

MVP

Ezzel validáltam a tervet, hogy be fog férni a bútor a helyére, és a tetején is marad elegendő hely.

4. Becslés

A 3D-s modellből készítettem egy 2D-s tervet, abból pedig bútorlaponként egy-egy méretezett rajzot, darabszámmal. Ennek a költségét és az elkészítéséi idejét bebecsültettem a helyi lapszabászattal.

Terv

A végleges ár túlmutatott az eredetileg erre szánt keret összegénél, mivel a vasalatok és a bútorlap költségét én kevesebbre becsültem. A scope-ból úgy tudtam vágni, hogy a hátsó takaró bútorlapot lehúztam a listáról, hiszen zárt állapotban nem látszik, nincs hozzáadott értéke és funkcionalitását átveszi a tető. A vasalatból nem szerettem volna minőségben lejjebb adni, illetve a tolóajtó mérete indokolta a több görgőt és így a magasabb összeget. Stakeholder jóváhagyta.

A költség további csökkentését és az MVP kihangsúlyozását eredményezte, hogy az IKEA-s kosarakat és dobozokat majd később fogjuk megvenni és beszerelni. Ezek nélkül is használható marad a bútor, és elkészültekor így is értéket fog teremteni az ügyfeleknek.

5. Összeszerelés (fejlesztés)

A bútorlapok legyártását követően jöhetett az összeszerelés a tervek szerint.

Fejlesztés

Az első sprint után jött a demo: valóban a tervezettnek megfelelően fér el a bútor a tetőtérben? És vajon használható lesz kihúzható ágy mellett is a szekrény egyik fele?

Demo

Igen! A demo sikeres volt, jöhetett a következő sprint. Elkészült a bútor másik oldala is és felszerelésre kerültek a felső lapok is. Itt dönteni kellett, hogy az összeillesztés rejtett lesz-e, vagy felülről csavarozva. Mivel időben nem szerettem volna többet rászánni, illetve hiba lehetőséget is tartalmazott volna a rejtett megoldás (fa tiplikkel), így a kevésbé esztétikus, de egyszerűbb és gyorsabb megoldást választottuk a stakeholder-rel egyeztetve. Ettől függetlenül ezt a részt még nagyobb odafigyeléssel végeztem el, hogy a végeredmény a lehetőségekhez képest esztétikus legyen.

A tolóajtók szerelése közben észrevettem, hogy túl sok az interrupt. A görgők esetében,a melyekből ajtónként 4 db kellett:

- be kellett jelölni a pontos helyüket

- majd apró mélyedést csinálni, hogy ne másszon el a csavarok helye

- aztán 3-as fúrófejjel előfúrni a csavarok helyét (görgőnként 4 darab)

- becsavarozni a facsavarokat

- felrögzíteni a tartóra a görgőket

Tolóajtó: interrupt hegyek

Ennél a folyamatnál nagyon sokszor kellett szerszámot cserélni, és a fúróban fejet váltani. Így a második ajtónál már minden lépést az összes görgőnél végigcsináltam, nem pedig görgőnként váltogatva a taskokat, így sokkal kevesebb idő alatt elkészült a második ajtó.

6. Átadás, ügyfél elégedettség mérés

Végül elkészült a szekrény 2 nap alatt, az ügyfelek nagy megelégedettségére és azóta is szívesen használják.

7. Retrospective

Ha igazán MVP-t szerettem volna, akkor a tolóajtó is lehetett volna másidk körös fejlesztés, beruházás. Költség csökkentési lehetőség lett volna, ha a belső polcok nem közepes, hanem alacsonyabb minőségű bútorlapokból lett volna megrendelve és legyártatva.

Valódi MVP

Remélem sikerült ezzel az egyszerű és hétköznapi példával érthetőbbé tenni az agilis működés egy szeletét. Vegyük sorra a lényeget, átültetve az IT iparba:

- követelményelemzés: a vevő igények felmérése, külső tényezők megismerése

- tervezés (story-k megírása)

- ötlet validálása (MVP)

- fejlesztési költségek (sprintek) becslése

- fejlesztés

- demozás ügyfeleknek

Fontos az ügyfelekkel való szoros együttműködés, változtatások, felmerült problémák kommunikációja és jóváhagyása. Lényeges, hogy próbáljunk a scope-on vágni, mérjük fel, hogy adott funkciókra valóban szükség van-e? A demo és a fejlesztési szakasz ciklikusan követik egymást, míg el nem készül a termék.

Cél, hogy fejlesztés közben minél kevesebb interrupt legyen, és nem szabad elhanyagolni a retrospective fontosságát, ahol fel kel mérni a hibákat és a pozitívumokat a fejlesztési szakaszokban, hogy tanuljunk belőlük és sprintről sprintre jobbak, hatékonyabbak legyünk.

A PO, az SM és a Csapat

Megbeszéléseken, emailekben, standupokon sokszor elhangzik a számból, hogy a csapat, vagy PO és a csapat. Egyéb kommunikációkban is gyakran úgy jön le ez a két megnevezés, mint két különálló dolog. És mindig furán érzem magam ettől.

Szakirodalomban is sokan úgy tartják, hogy van a fejlesztő csapat és van mellette külön álló szerepben a product owner. Lássuk az Agile manifesto egyik pontját:

"Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában."

Együtt dolgoznak, de vajon egy csapatként?

A Lean Startup könyvben is megtalálható az a felállás, amikor a megrendelő (customer) áll az egyik oldalon, a fejlesztő csapat (development team) a másik oldalon.

Tovább nehezíti a megfelelő definíció kialakítását az a kettősség is, hogy a product owner sok időt tölt az ügyféllel (stakeholder), az ő érdekeit is képviselnie kell, a csapat érdekei mellett.

Munkám során előfordult olyan szituáció is, amikor PO-ként több csapat irányítása is feladatom volt. Mondhatjuk, hogy egy csapat tagja sem voltam ebben az esetben. Vagy például a kezdeti időszakban, amikor technikailag még nem voltam olyan szinten, akkor kívülállónak éreztem magam sokszor a fejlesztői beszélgetések közben.

Illusztráció: Werner Nóri

De miért is foglalkozok ezzel?

Mert ezek ellenére én úgy gondolom, hogy PO-ként a csapat szerves része vagyok, amit létrehozunk az közös munka. Ugyanígy a felelősségben is osztozunk. Ha azt mondom scrum csapat, akkor abba PO-ként én is beletartozok. Ez a gyakorlatban annyit tesz, hogy

- részt veszek a csapatszabályok kialakításában

- részt veszek a retrospective-ken

- a csapatot megvédem az ügyféllel és a vezetőséggel szemben, ha szükséges

- a hibák következményeit együtt viseljük

- szorosabb együttműködést és gyorsabb visszacsatolást tesz lehetővé

Illusztráció: Werner Nóri

Ha kívülállóként, üzleti szakértőként viselkednék, akkor csak a stakeholderek érdekeit kellene néznem, és minden felelősség a fejlesztő csapaté lenne. Ettől nem gondolom, hogy könnyebb dolgom lenne, illetve nem hiszem azt, hogy produktívabb lenne a fejlesztés. A fejlesztő csapat szemében nem biztos hogy jól veszi ki magát, ha kívülállónak, csúnyán kifejezve,  felsőbbrendűnek gondolom magamat.

Az igazsághoz hozzá tartozik, hogy a jelenlegi projektem első egy-két retrospective-jén nem voltam jelen, de utána már behívott a csapat és együtt elemeztük ki mi volt a jó/rossz a sprintben és milyen területen tudnánk fejlődni. Sokkal tisztább és egyértelműbb volt így, mintha utána olvastam volna el a confluence-be felvitt jegyzőkönyvet és találgattam volna ki, hogy ki mire gondolt pontosan.

Akad persze ellenvélemény is:

"A potential risk is that with the presence of the PO the daily scrum can revert to a status meeting. Updating the PO rather than collaborating on getting another day closer to the sprint goal." - Duan

Jogos a felvetés, de a scrum master feladata megfelelő kordában tartani a standup eseményt.

Azt is látnunk kell, hogy ha a csapat úgy érzi, hogy a PO nem integrálódott teljesen a csapat napi működésébe, akkor egy idő után a csapat sem fog teljes odaadással részt venni ezen eseményeken, az érték teremtésben és kommunikációs gap jöhet létre.

Ha már szóba hoztuk, akkor beszéljünk kicsit a SM-ről. Neki sem csak az események szervezése, vagy a problémák megoldása, akadályok elhárítása a feladata. Hiszen bizonyos problémák feltárásához szoros kapcsolatban kell lennie a csapattagokkal (lásd 1on1). Nem tankönyvszerű, de az élet adta helyzethez idomulva már előfordult nálunk olyan is, hogy a a fejlesztők a scrum masternek tartottak sprint végi demot.
Kicsit olyan, mint egy család, ahol mindenkinek megvan a maga szerepe, de ha a szükség úgy hozza, akkor segítünk egymásnak, átveszünk feladatokat.

És miért fontos nekem ennyire ez?

Mert az alá/fölé rendelt viszonyban ott van a hibázási lehetőség. Ha pl. a PO az SM-en keresztül kap csak visszajelzést a csapattól.

Összegezve, úgy gondolom, hogy amikor egy projekt kapcsán csapatról beszélünk, abba beletartozik a PO és az SM is, ez az ökoszisztéma adja a teljességet. Az egymástól való függés határozza meg a csapat sebességét, a lefejlesztett funkciók értékét, használhatóságát és végül az ügyfél elégedettséget.

Apró finomságok sprint közben: ábrázolás

Már írtam arról, hogy milyen technikák vannak arra, hogy jobban kontroll alatt tudjunk tartani egy két hetes sprintet, és most pár apró finomságot szeretnék megosztani. Szinte alapvető dolgoknak tűnnek talán az olvasók egy részének triviális, mégis úgy gondolom hasznos lehet megosztani.

Sprint forduló napján az első esemény a demo. Bármennyire is volt tesztelve a lefejlesztett funkció, megírva a user story, mindig akad olyan hiba, ami demon jön elő, olyan funkció, amit a PO rosszul vagy nem egyértelműen fogalmazott meg. Ezeket az észrevételeket a vezető fejlesztő és én is, mint product owner fel szoktam jegyzetelni közben, hogy ne a demo folytonosságát akasszuk meg vele.

Sokszor olyan apróságokról van szó, amiért felesleges a Jira-ba storyt felvinni, így egy flipcahrtra vagy a mágnes táblára írom fel, hogy milyen apró észrevételeket tettünk a review során. Valahogy így:

Azt tudjuk, hogy aminek nincs gazdája, az elég lassan készül el, így még ott helyben felelősöket is rendel a csapat a feladatokhoz. Ami olyan nagyságú feladat, arról hozunk létre új storyt és csak planning után foglalkozunk vele, de amik szükségesek a megfelelő ügyfél demohoz, azokat még aznap el kell végezni. Erre általában a retro és a planning után kerül sor.

Ugyanezt az ábrázoló technikát alkalmazzuk a milestone napján is. Reggel a standup közben felírjuk az adott taskokat, amik nyitva vannak még és a milestone részét képezik. Majd az adott task mellé odaírjuk, hogy ki a felelőse, ad egy becslést a hátralevő időre, illetve megjegyzést is tehetünk oda, ha szükséges. Bár erre ott van a jira is, de az emberi agy mégis jobban befogadja, ha valamiről beszélünk és közben ábrázoljuk is.

Csapaton belüli kommunikáció: hipchat Vs. slack

A csapat legfőbb erőssége abban rejlik, hogy milyen módon képesek a tagok egymással kommunikálni. Ha ez nem megy gördülékenyen, akkor az a teljesítményre is hatással van. Ellenkező esetben viszont olyan rejtett tartalékokra bukkanhatunk, amelyet érdemes kiaknázni.

Kép forrása: themasters.io

Céges gyakorlat nálunk a hipchat használata. Minden csapat létrehoz magának egy szobát és oda kerül bekötésre a jira, a bamboo, selenium pluginek. Mindenről kapunk percre pontos értesítést. Mindenki happy.

A retrokon mégis hétről hétre előjött, hogy nem megfelelő a kommunikáció, elvesznek információk, feltett kérdésekre nem érkezik válasz. Beláttuk, hogy hiába használjuk a hipchatet, a sok értesítő között elveszik a csapat kommunikáció. Scrum masterem ajánlotta, hogy próbáljuk ki a slacket és mire kettőt pislogtam a csapat már használta. A régi hipchat szobát meghagytuk a különböző értesítéseknek, az új slack szobát pedig a kommunikációnak.

Elég volt egy sprint, hogy érezzük a hatását. A retron mindenki dicsérte és pozitívumként jött elő a kommunikáció! Mindenki minden kérdésre választ kapott, mindenki tudta időben, hogy hol van esetleg gond. Ehhez persze szükség volt arra is, hogy a slack értesítő rendszere sokkal jobb (pl. mobilon), mint a hipchat-é, de a plugin értesítők hiánya is jótékony hatással volt.

Néha felül kell vizsgálni az általunk használt eszközöket, hogy valóban a munkát, az érdekeinket szolgálják, vagy éppen gátolják a csapat előre jutását. Merni kell változtatni, újdonságokat kipróbálni, és persze megrertrozni! :-)

És azért persze a slackbe is bekerült egy értesítés. :-)

Nem érünk oda

Az aktuális projektem közepe felé (5-7. sprint) a mérőszámok alapján már láttuk, hogy nem fogunk odaérni az aktuális velocityvel, ahova terveztük, időben. A csapat egy része számára ez nagy teher volt, a másik fele próbálta behozni, de csak kudarc lett belőle a sprintek végére. Az egész csapat stresszben volt, velem együtt, a demot nem ünnepnek éltük meg, a hétvégék is ennek a rossz érzésnek a hatalmába kerültek. Mit tehet ilyenkor egy PO vagy a csapat?

Kép forrása: stressz-m

A becslések nem voltak mindig pontosak, és a 2 hetes sprint nem adott elegendő kontrollt., tehát nem tudtunk időben beavatkozni, hogy sikeres legyen a sprint. A csapat mindig úgy látta, érezte, hogy a sprint végére össze fognak érni a szálak, be fogják hozni a storykat, de valahogy sosem sikerült. Egy-két story kihagyása végülis nem a világvége, de a sprintek számának növekedésével a le nem hozott storyk összege is emelkedett.

A másik probléma, hogy görcsösen ragaszkodtunk minden story elkezdéséhez. Így ha például 12 story volt betervezve a sprintbe, akkor a végén lett 10 darab 90%-ban kész story és két darab el sem kezdett story. De ha arra koncentráltunk volna inkább, hogy befejezett storykat hozzunk le, akkor lett volna 9 darab 100%-osan befejezett story, ami az ügyfél számára is nagyobb értékkel bír, mint több, de itt-ott sántikáló funkció.

Fontos volt valami akció tervet hozni, különben nagy baj lesz a végén. Két eszközt használtunk a sprint közbeni ellenőrzésre.

Meghatároztunk sprint közbenre egy milestone-t, ami a planningen definiált, és az előzetes becslés alapján addigra lehozható storykat tartalmazta. Ezeknek a storyknak a milestone-ra el kell készülnie, ha más külső akadályozó tényező nincsen.

A másik módosítás a feature freeze volt, ami arra irányult, hogy a sprint forduló előtt 1 nappal nincs több új task fejlesztés, hanem a meglévő bugok javítása, az addig elkészült storyk jobbítása volt a cél. Mivel a tesztelő 1 nappal a sprint forduló előtt kapja meg az összes storyt (vegyük figyelembe, hogy jelen esteben komoly függések voltak a storyk között), így kevés idő maradt a funkciók összefüggésében való tesztelésére és a feltárt hibák javítására, sajnos sokszor előfordult, hogy a demo előtt 10 percel még volt merge request.

A milestone beiktatása technikailag annyit jelentett, hogy kedd délután már csak bug javítás volt, új task fejlesztése nem, és szerda reggel tartott egy mini demot a tesztelő nekem.

Ugyan a milestone felfogható pótcselekvésnek a burndown chart helyett, de amíg nem működik jól egy csapat, addig nem ez nem ad pontos visszajelzést, és segít a csapatbak fokúszálni arra, hogy hol tratanak és valóban oda tudunk-e érni a sprint végére, a projekt végére.

A bevezetett intézkedések több kontrollt adtak a kezünkben és az elmúlt 3 sprint tapasztalata alapján elmondható, hogy pozitív hatással volt a csapat teljesítményére, az ügyfélnek szállított értékre.

És hogy ez mennyire agilis? Miért nem álltunk át inkább 1 hetes sprintekre?

A csapat félt attól, hogy a plusz agilis események annyi időt vesznek el, amit jelen szituációban a csapat nem vállalt be.

Mindenképpen szerencsésebb az a fajta hozzáállás, hogy kevesebb, de teljesen jól működő storykat hozzunk le egy sprintben, mint folyamatosan magunk előtt görgetünk minden storyt sprintről-sprintre.

Lehetne olcsóbb?

via GIPHY