chcel by som požiadať o váš názor, skúsenosti a radu ohľadom riadenia vývoja.
Máme dve produktové línie (každá z nich predstavuje sadu aplikácií, ktoré tvoria riešenia pre určité skupiny ľudí). Dlhé roky sme mali tieto dve línie viac menej oddelené.
Áno vývojári si zdieľali vedomosti, skúsenosti, spoločné knižnice, …
Ale produktovo aj riadením to boli oddelené svety. Teraz prechádzame k tomu, že chceme stavať “platformu”. Z pohľadu klienta jeden online systém z ktorého si dokáže vyskladať riešenie, ktoré mu pokryje jeho potreby.
Narážame však na niekoľko problémov.
Priorita
Priorita jednotlivých Product ownerov a vlastne aj tímov je stále na ich projekte. A to potom naráža na to, keď sa má robiť nejaká integrácia, … Ale toto beriem ako vec, ktorú viac menej vieme vyriešiť.
Ale ak máte nejaké skúsenosti tak budem rád.
Organizácia
Dosť nám viaznu veci ohľadom organizácie. Plánovanie spoločných veci. Komunikácia a odovzdávanie informácií.
Budem rád za akýkoľvek postreh, nápad, radu. Či už v rámci diskusie sem, osobne, alebo online call.
Na to som pocuval zaujimavy podcast CZ Podcast 234 - Engineering praktiky by CZPodcast | Free Listening on SoundCloud
Tam odporucaju spravit aspon jeden team na vyvoj tej platformy, ked uz nie kompletny, aspon taky, co ma na to napevno priradeny cas na vyvoj, povedzme 50%. Taky team by mal robit aj research, aby sa predislo technologickemu dlhu.
Nemam skusnosti s riadenim, ale mozno len maly postreh.
Casto na forach vidim ako pri produktoch/projektoch, ktore robia podobnu vec ale su pre roznych zakaznikov odporucaju to vyvjat stylom co zakaznik to branch v gite, ale podla mna je to sialenost, lebo codebase sa zachvilku rozide a fixovanie bugov bude cim dalej narocnejsie.
Mne sa na jednom dlhodobom produkte podarilo presadit to, ze sa vyvja produkt a pre zakaznnikov a integracie sa dont tvoria pluginy.
Co sa taky technickej stranky este v .Net Core 1.0 to bol boj a doslova hekovanie frameworku, teraz to uz ide lahko. Toto rozhodnutie naozaj nelutujem, lebo vdaka IoC ide vymenit akukolvek cast produktu (funkcionalitu a cez ine mechanizmy aj pohlady a staticky obsah) a za tie roky sa uz nazbierali desiatkych integracii. A umoznuje to sa hlavne zamerat na vyvoj produktu ako takeho, bezproblemovo fixovat bugy a pluginy preziju update bez zmeny kodu.
Samozrejme ma to (aspon v ASP.NET Core) aj iste nevyhody, napriklad obcasny DLL version hell a clovek musel riesit nejake kompromisy.
Co urcite neodporucam, je snazit sa teamy spajat, co najviac ich integrovat, alebo nutit ich pouzivat tie iste nastroje, robit kompromisy atd. To bude viest len k tomu, ze oba teamy budu tazkopadnejsie a clenovia budu demotivovani.
Mam taky napad, ale nemam ho este vyskusany - co tak na jeden sprint skusit vymenit jedneho
programatora medzi teamami? Ak to zafunguje tak dalsieho…
Co sa tyka priority a organizacie, Scrum of Scrum mi tu celkom pasuje. V backlogu top level scrumu by boli polozky, ktore sa tykaju oboch teamov. Vystupy zo Sprint Planningu by boli pre oba teamy zavazne. Workitemy by sa potom priradovali teamom - analogicky k jednoduchemu Scrumu. Dobry napad je mat aj pravidelny meeting - obdobu k Daily meetingu, samozrejme frekvenciu si urcite podla potreby. Dolezita je pravidelnost, aby si na to vyhradili zastupcovia oboch teamov cas.
Co sa tyka zlozenia, tak su dve moznosti:
Kazdy tym vyslal product ownera a technickeho cloveka
Top level scrum bude mat vlastneho product ownera, ktory bude istym sposobom nadradeny jednodlivym produktom. Toto sa ale odporuca iba vtedy, ked to nejak kopiruje hierarchiu v organizacii.
EDIT: Ked citam povodnu otazku este raz, mozno by stalo za zvazenie mat zvlast team pre platformu (ako hovori vlko) a v scrum of scrum 3 teamy. To uz naozaj zalezi od detailov, ktore my nepozname
Diki za podnet.
Bolo to však trochu viac na to riadenie zamerané.
Čo sa týka toho čo ty popisuješ tak kvôli inému projektu som sa s tým tiež hral a narazil som na celkom prekvapivé správenie, ktoré som nazval EvilController.
Toto sme začali používať zhruba pred rokom. Je to super. Všetkú novú vec čo vyvíjame “schovávame za feature flags”, nebojíme sa vďaka tomu releasovať a postupne zverejňujeme celky podľa toho ako sa dokončujú.
Co urcite neodporucam, je snazit sa teamy spajat, co najviac ich integrovat, alebo nutit ich pouzivat tie iste nastroje, robit kompromisy atd. To bude viest len k tomu, ze oba teamy budu tazkopadnejsie a clenovia budu demotivovani.
Toto u nás nevnímam teraz ako problém. Máme síce viac menej jednotný stack, ale keďže nové systémy vyvíjame ako mikroslužby tak ľudia majú dosť voľnú ruku. Tímy sú dosť autonómne a majú možnosť si upravovať veci podľa seba (aj technické aj organizačné). Čo máme zjednotené tak to sú sprinty (začiatok a koniec), kvôli releasovaniu. Ale dik za tip, budeme na to dávať pozor.
Mam taky napad, ale nemam ho este vyskusany - co tak na jeden sprint skusit vymenit jedneho
programatora medzi teamami? Ak to zafunguje tak dalsieho…
Toto sme skúšali, respektíve občas skúšame. Ja som toho priaznivec, má to viacero výhod.
Co sa tyka priority a organizacie, Scrum of Scrum mi tu celkom pasuje. V backlogu top level scrumu by boli polozky, ktore sa tykaju oboch teamov. Vystupy zo Sprint Planningu by boli pre oba teamy zavazne. Workitemy by sa potom priradovali teamom - analogicky k jednoduchemu Scrumu. Dobry napad je mat aj pravidelny meeting - obdobu k Daily meetingu, samozrejme frekvenciu si urcite podla potreby. Dolezita je pravidelnost, aby si na to vyhradili zastupcovia oboch teamov cas.
U nás je to trochu komplikvanejšie. Tých tímov je celkovo 9. 3 na jednej produktovej línii a 6 na druhej Scrum of scrum skúšame, asi mi zatiaľ tiež sedí najviac. Ale pozdáva sa mi tá myšlienka, že by ta samotná “platforma” mala vlastného product ownera a ideálne aj tím.
Je to určite debata na dlhšie. Ideálne niekde pri pive
Scrum of scrum skúšame, asi mi zatiaľ tiež sedí najviac. Ale pozdáva sa mi tá myšlienka, že by ta samotná “platforma” mala vlastného product ownera a ideálne aj tím.