Konstatování: Je velmi obtížné pro velkou organizaci uchopit "Definovat si, co agile znamená pro vaši organizaci/projekt" včetně provazby na release mng, governance…

Ano, s tím nelze než souhlasit :-). B. Zoubek

Je standardem/umíte ohodnotit maturity model (kvalitu) implementace Agilního vývoje v dané společnosti?

Profinit nerealizuje konzultační činnost jako firmy typu Construx, které se na toto zaměřují. Nicméně pokud bychom pracovali na projektu, který pracuje se suboptimální implementací agilního přístupu, dozajista bychom na to upozornili a navrhli kroky ke zlepšení. B. Zoubek

Daří se vám realizovat delivery při současném souběhu/dependency více projektů, kdy dochází k mixu projektů pod vodopádem a agilní dodávkou?

Vždy záleží na konkrétní situaci, nicméně pro tyto situace se používají přístupu často nazývané jako vícerychlostní IT, případně BI-modální IT. Zjednodušeně řečeno jsou například výstupy vodopádového přístupu používány jako vstupy pro agilní vývoj. Pokud vodopádový přístup podklady nedodá, musí s tím agilní tým pracovat a přizpůsobit se (shodně, jako při diskuzi s product-ownerem, atd.). Platí ale, že vše musí být smysluplně nastaveno. Vývoj core systému agilně s napojením na vodopádově vyvíjenou front-end vrstvou by byl bezesporu výzvou. B. Zoubek

V předpokladech pro plánování sprintů byl recent backlog, který by se měl skládat z epicu a storek. Jakou mate zkušenost s designem (ala POC) před 1.sprintem?

Zkušenost máme velmi dobrou. Pure Scrum definuje, že tým dostává problém a má nalézt řešení. My jsme zastánci toho, že minimálně rozmyšlení si, zda chceme jít vpravo nebo vlevo hned na začátku, je vždycky dobré. B. Zoubek

Je složitější dělat analýzu pro vodopád nebo pro agile?

Každý z přístupů jde na řešení problémů odlišně. Vodopád v ideálním případě požaduje 100% analýzu - což se téměř nikdy nepovede. Spousta věcí je ale známa dopředu. Agilní přístup naproti tomu může měnit produkt za pochodu, nicméně určitá míra detailu je vždy nutná. Analýza u vodopádu je bezesporu časově náročná, nicméně pokud posčítáme, kolik strávíme nad analýzou u agilního vývoje, bude číslo velmi podobné. Agilní vývoj nám problém nezjednoduší, pouze k němu přistupuje jinak. B. Zoubek

Není agile často krycím názvem pro zmatek? Co Vy na to?

Ano, velmi často je agilní vývoj zástěrkou pro absenci procesů, dokumentace, atd. To je rozhodně špatně. B. Zoubek

Jede se podle nějakých metodik viz FURPS, ...?

I v agilním světě máte možnost volby metodiky, například Scrum, Kanban, apod. Nečekejte ale takovou míru propracovanosti, jako například u FURPS. B. Zoubek

Když mám tu systém, který je tu léta a nemá automatické testy. Může se vývoj na tomto systému dělat agilně?

Určitě to lze, nicméně pak předpokládáme, že několik prvních sprintů bude věnováno stabilizaci právě této oblasti. B. Zoubek

Z jaké oblasti je vhodné, aby byl product owner? (IT, BUS)

Product Owner musí být primárně schopný (a mít pravomoc) přijímat rozhodnutí a tedy směrovat podobu cílového produktu. Pokud je takový člověk z oddělení IT, business nebo marketingu již není klíčové. B. Zoubek

Pokud na začátku nemám povědomí o všech budoucích funkčnostech, nemůže se stát, že budu muset později aplikaci "překopat", abych tam tyto funkce "narouboval"?

Jistě, toto se může stát a také stává jak u agilního vývoje tak i u vodopádem/iterativně řízených projektů. Agilní vývoj s tímto může pomoci, jelikož dělá menší iterace. Nicméně pokud začínáte vyvíjet aplikaci s myšlenkou web klienta a v polovině dospějete k názoru, že se má jednat o nativní mobilní aplikaci, situace bude u obou metodik podobná. B. Zoubek

Jaký je Váš pohled na dokumentaci v rámci Agilního vývoje, zejména technickou specifikaci?

Rozhodně neplatí, že agilní vývoj rovná se žádná dokumentace. Pokud má být systém udržovatelný, je dokumentace potřeba. Mělo by platit, že se dělá taková dokumentace, která je dostatečná - nic navíc. (dokumentaci, kterou nikdo nechce, nebude nikdo číst). Technická specifikace je samozřejmě základním kamenem takové dokumentace. B. Zoubek

Jsou oblasti, kdy se Agile vývoj nehodí?

Autoři Scrum metodiky by vám řekli, že se hodí všude. Dle našeho názoru existují výjimky. Například u silně regulovaného prostředí (life-critical systémy), kde je nezbytné nejdříve schválit kompletní analýzy včetně dopadů na bezpečnost, a pak teprve začít realizaci, je použití Scrum limitováno na PoC. Vlastní projekt ale musí postupovat dle požadovaného procesu. Diskuzi bychom také vedli v případě core systémů, které jsou v údržbě delší dobu, ale opravdu záleží na konkrétní situaci. Vždy je také potřeba zvažovat stav zralosti organizace z hlediska agilního vývoje. B. Zoubek

Co v případě přepisu stávající aplikace na novou? Kolik funkčnosti je dost?

U tohoto typu úloh je zásadní si vyjasnit otázku: proč přepisuji? Je to opravdu potřeba nebo lze refactorovat současnou aplikaci? Vždy musí existovat jasné požadavky na novou aplikaci - zadání ve smyslu "musí se chovat stejně, jen lépe vypadat" to rozhodně není. Jediný rozumný přístup je zvolit přírůstky s definovaným scope, které lze validovat. Tak lze určit, co už je "dost". B. Zoubek

Jak až moc dobře může fungovat agilní vývoj v integračním prostředí, kde změny jsou velmi závislé na integraci a okolních systémech

Agilní vývoj neznamená chaos, čili by měla platit shodná pravidla jako jinde. V takovém prostředí bude synchronizace obtížná při jakémkoliv přístupu a bude hodně záležet na koordinaci mezi týmy. Výhodou agilního přístupu tady však bude rychlá iterace. Pokud totiž nebude nějaká služba dostupná, může na to konzument rychle reagovat (mock, zaslepení, ...). B. Zoubek

Nevzniká z praxe agilního vývoje větší chaos v kódu? Tj. těžší údržba kódu, komplikovanější vazby mezi systémy, více workarounds, apod.

Agilní vývoj neznamená rezignaci na základy SWENG. Naopak je s tímto přístupem spojena automatizace testů, DevOps, code reviews, atd. Pokud vývojáři produkují špatný kód, architekturu, apod., nikdy to není problém použité metodiky, ale její implementace. B. Zoubek

Jaké jsou reálné šance přechodu velkého systému, zavislého na mnoha BE a při dodávkách velkého množství různých změn do plánu 4 releasu ročně, na agilní vývoj?

Existuje například tzv. Strangler pattern, který z velkého systému dělá menší - podoba microservices. Šance je vždy. Nemáme rádi konzultantské odpovědi typu "to záleží", ale v tomto případě bez analýzy konkrétní situace nelze jednoznačně odpovědět. B. Zoubek

Jak se agilní vývoj vypořádá s tím, že požadavky, které se analyzují a zařazují do dalších sprintů nekorespondují s předchozím řešením

Jak již bylo řečeno dříve, základní analýza je nutná. Na druhou stranu agilní vývoj je o reakci na změnu, proto také krátké iterace, apod. Počítá se tedy s větším počtem změn a je na týmu (včetně product ownera), aby zadaný problém řešil. B. Zoubek

Agilní vývoj: Rychlé dodávání malých změn, ale neznamená to, že celek bude k hotov dřív v porovnání s jiným postupem. Jen máme větší šanci, že trefíme cíl.

Ano, souhlasíme. B. Zoubek

Platí že se agilní vývoj se hodí spíše pro FE?

Spíše je tam více využíván, protože FE se typicky častěji mění. Agilní vývoj je ale obecná metodika a jak bylo řečeno dříve, není omezena na specifické použití. B. Zoubek

Jak se stavíte k situaci kdy chcete dělat agilně na větších projektech kdy máte vazby na systémy které agilně nefunguje / nemůže fungovat? Typicky backendy.

Shodné s odpovědí na otázku 3. B. Zoubek

Jakou podobu (podrobnost) odhadů poskytujete zákazníkovi?

Velmi často je struktura odhadu definována přímo zákazníkem (pro možnost porovnání více nabídek). Obecně jsme na vyžádání poskytnout libovolný detail. Je však nutné si uvědomit minimálně dva velmi časté aspekty: 1/ Nad detailním odhadem bude muset i zákazník trávit netriviální množství času (tedy poměr cena/výkon z pohledu informace a úsilí vynaloženého na průchod odhadu). Otázkou pak je, zda je zákazník v tomto detailu odhad vůbec analyzovat. 2/ Debaty nad detailními odhady se pak typicky stáčí na diskuze o jedné konkrétní položce s dodací 1 hodina, která by možná mohla být 30 minut. Toto se s železnou pravidelností děje i na projektech v řádu stovek MDs. Díky detailu pak uniká celek a opět je k diskuzi, zda vynaložené úsilí za tento přístup stojí. M. Petřík

Checklisty slouží jen k zamyšlení nebo mají i konkrétní doporučení (koeficient/částku) pro úpravu ceny?

Platí obojí. Checklist primárně upozorňuje na oblasti, které by mohly být opomenuty. Pokud se však daná položka v odhadu uvažuje, typicky se pak projeví i v pracnosti. M. Petřík

Jak si ověřit podezření, že je odhad ceny mimo realitu?

První věc: pracnost a cena jsou dvě odlišné věci. Cenu můžete obchodně ovlivnit, pracnost by měla být ideálně reálná a na finální ceně nezávislá. Ověřit lze typicky více nezávislými odhady, například i s použitím odlišných metodik odhadu. M. Petřík

Můžete prosím víc vysvětlit kužel nejistoty? Osa y představuje co?

Osa X představuje fázi projektu (čím více vpravo, tím více se blížíme ke konci projektu), osa Y představuje rozptyl přesnosti odhadu. Hezky znázorněno zde: http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ M. Petřík

Je možné nahradit RFI sérií workshopů potenciálních dodavatelů, kde dodavatel prezentuje vlastní řešení a služby?

V rámci RFI je možné realizovat Workshop. Nicméně zákazník si musí uvědomit, že "série" již znamená nemalé vynaložené úsilí ze strany dodavatele, a to navíc ve fázi RFI, kdy typicky nemusí být jasno o dalším postupu projektu (a z pohledu dodavatele se typicky jedná o čistý pre-sale). Série workshopů tedy pak může být nákladná pro všechny strany (finančně i časově). Tento přístup bychom spíše doporučili až v dalších fázích s redukovanou množinou potencionálních dodavatelů). M. Petřík

Jak správně porovnat/vyhodnotit nabídky hotového/balíkového řešení vs. vývoj na zakázku.

Důležité je vytvořit srovnatelné podmínky a ano, toto není triviální. Příklad může být, kdy u balíkového řešení bude bezesporu nutné integrovat se na stávající řešení. Toto je potřeba nechat si nacenit a následně lze porovnávat s vývojem na zakázku, atd. B. Zoubek

Platí prezentované postupy pro waterfall i agile?

(pozn. Oblast metodiky odhadů) Odhad činnosti musí uvažovat všechny uvedené fáze (analýza, design, …) ať už se jedná o agilní, iterativní nebo jiný přístup k vývoji. Je možné, že některé oblasti by doznaly úprav (například dodávky, atd.), nicméně princip je lze aplikovat všude (checklisty, oblasti, rozpad na úlohy, ...). M. Petřík

Nemá být součástí RFP předpokládaná max. cena a návrh smlouvy?

Záleží na požadavcích zadavatele. Někdy chce zadavatel získat návrh smlouvy od dodavatelů (vlastní nemá nebo nechce sdílet, jelikož i tato oblast je součástí hodnotícího procesu). Shodné platí i pro maximální cenu, jelikož z ní je někdy možné odvodit očekávanou cenu. Návrh smlouvy a maximální ceny se typicky vyskytuje u zakázek ze státní správy. M. Petřík

Jak jsou úspěšné odhady pracnosti?

Obecně moc úspěšné nejsou - například dle Standish group a jejich CAHOS reportu (https://www.infoq.com/articles/standish-chaos-2015). V Profinitu je úspěšný odhad takový, kdy se výsledná pracnost projektu liší do max. 15%. M. Petřík

Jak vybrat těch 5 vyvolených dodavatelů?

Typicky má společnost své portfolio dodavatelů, se kterými má zkušenosti a zná oblasti, ve kterých fungují. Vždy je samozřejmě možnost přidat někoho neznámého. Nicméně volba výhradně 5 neznámých společností do oblasti, kde působí 2 ověření dodavatelé, může být riskantní. B. Zoubek

Když RFP je poptávka na konkrétní zadání, lze se takto poptávat na dodávku, která bude dělána pomocí Agilního vývoje?

Samozřejmě to lze, nicméně musí být specifikována metoda vývoje. Poptávka na fixní cenu, čas i rozsah, avšak formou agilního vývoje, je antiteze. B. Zoubek

Umíte se v rámci RFI/RFP zeptat zadavatele i na potenciální RIZIKA stability zadání a jejich kvantifikace? Jak se správně ptát a získat použitelné odpovědi?

V rámci RFI/RFP je typicky prostor pro dotazy, často také workshop. Z otázek nebo diskuzí lze velmi dobře identifikovat kvalitu a potencionální stabilitu zadání. Správné otázky vedoucí na použitelné odpovědi jsou pak věda sama o sobě a neexistuje jednoznačný návod. B. Zoubek

Je pro vás běžné/výjimečné, že v rámci closing reportu projektu upravujete i metriky pro výpočet odhadů (tzn. kalibrace teorie vs. reality)?

Toto je nedílná součást celého procesu. Právě z tohoto důvodu se provádí měření a uchovávání historie. Po letech jsou tato data reálně to nejceněnější, co organizace má. M. Petřík

Jako dodavatelé je pro vás běžné, že při publikování výše odhadů zmiňujete i cestu jak jste k odhadům do iterovali (jsou zde plusy/mínusy publikace odhadů)?

Lehce souvisí s otázkou 1. Běžné to není, nicméně pokud se v dalších fázích výběrových řízení řeší cena/pracnost, je toto jeden ze způsobů, jak odhad obhájit (nebo minimálně prezentovat). Metoda odhadu se pak typicky částečně objevuje i v okrajových podmínkách, které jsou nedílnou součástí každého odhadu (například: proběhne maximálně 5 workshopů v dotaci 1 MD per workshop, apod.). M. Petřík

Jak se díváte na metodu odhadů přes use case pointy?

Je to jedna z možností, nicméně je nutné mít na paměti její míru přesnosti. Záleží na definici, co se považuje za use case point, co má obsahovat, atd. Z našeho pohledu vhodné pro křížovou kontrolu, nicméně by mělo být použito i s jinou metodikou, například Top-down, atd. M. Petřík

Můj PM říká: Vlci vyjí, ale karavana táhne dál.

Co k tomu dodat. Kéž karavana dojede šťastně do cíle… M. Petřík

Technická: Kromě pozvání lidí na status projektu je důležité i od-pozvat lidi, kteří jsou tam historicky. Nikdo to moc nedělá a pak jsou statusy se 40 pozvánkami.

Tady je otázka, proč jsou účastníci pozváni i historicky. Plánování nikoliv na rok dopředu, ale s rozumným předstihem a dle aktuální situace a potřeby může dané efektivně eliminovat. M. Petřík

Na kolika projektech by měl projekťák nejvíce simultánně pracovat?

Nelze říci obecně. Vždy záleží na konkrétních parametrech konkrétních projektů a také schopnostech PM a jeho týmů (počet řízených lidí, počty statusů, reportů, problémová doména, ...). Rozhodně by ale mělo platit, že je PM schopen se všem projektům adekvátně věnovat. Pokud dané neplatí, je to špatně. M. Petřík

Může být analytik na jednom projektu zároveň PM?

Opět záleží na parametrech konkrétního projektu. Nicméně dané až na výjimky nedoporučujeme. Většinou pak jedna z rolí "trpí". M. Petřík

Jak se má k v situaci, kdy má neschopného/alibistického manažera, zachovat člen týmu?

Zde neexistuje "jediná pravda", nicméně pokud má člen týmu takový pocit, je nejhorším řešením nedělat nic (a pouze si potvrzovat pocit s kolegy, ale to je vše). Na problém je potřeba upozornit a probrat ho přímo s PM. Diskuze by měla být o podkladech/faktech, na základě kterých má daný člen pocit, že situace je taková, jakou ji vnímá. Zde samozřejmě může dojít i k několika výsledkům - PM dané uzná a změní se, daný člen týmu se mýlil (bylo to pouze jeho vnímání), PM chybu neuzná, atd. S daným je nutné počítat, nicméně ať už bude výsledek jakýkoliv, dojde k posunu, a tedy kýžené změně. Pokud diskuze s přímým nadřízeným nefungují, je potřeba eskalovat dál - nicméně toto by nikdy nemělo předcházet schůzce s PM, kde se minimálně člověk pokusí pojmenovat problém a společně vymyslet řešení. M. Petřík

Existuje statistika, kolik sw projektů je úspěšných?

Zde je důležité specifikovat, co znamená úspěšný projekt. Nicméně dle Standish group a velmi populárního CHAOS Report není situace dobrá (https://www.infoq.com/articles/standish-chaos-2015). Za úspěšné je považována pouze jedna třetina projektů. M. Petřík

Rozlišujeme mezi projektovým manažerem a delivery manažerem v rámci jednoho projektu?

Zde záleží na definici v rámci organizace a rozdělení pravomocí. Například v Profinitu je na některých projektech pozice DM shodná s pozicí PM, někdy pod DM spadá více PM. Z pohledu nároků na znalosti projektového řízení jsou si obě role ale velmi podobné. M. Petřík

Jak se pozná dobrý projektový manager?

Doufáme, že na to odpoví tato přednáška (například sekce Desatero dobrého PM). Nejlepší PM je ale ten, který se tak chová, všichni ho tak vnímají, respektují a on sám to nemusí pokaždé zdůrazňovat a opakovat. M. Petřík

Sli.do je váš interně vyvinutý SW?

Nikoliv. Pouze tuto službu považujeme za velmi vhodnou pro náš účel. M. Petřík

Kolik je tady PM? ;)

Svým způsobem je PM každý (v nějakém ohledu a v nějaké situaci). M. Petřík

Jak reagovat na problematické situace na slide 38?

(pozn.: jedná se o reálná vyjádření protistrany v rámci schůzek) První věcí je udržení se v profesionální (neosobní) rovině. Pokud je projektové řízení exekuovanou dobře od počátku projektu, nejspíš existují archivované zápisy, evidence dohod, atd. V takovém případě se lze vždy odkázat na patřičnou dohodu a na tom doložit, jaké z toho plynou dopady (příklad podepsané smlouvy, i změněné dohody). Některá vyjádření (například "jste profesionál") jsou pak tzv. "startovací", kdy protistrana možná stojí o konflikt, a tímto způsobem se jej snaží vyvolat. Zde opět platí - zhluboka se nadechnout a slušně odpovědět. M. Petřík

Project management vs. Delivery management. Kde je hrana?

Obdobné s otázkou 7. Záleží na konkrétním nastavení kompetencí. Sada dovedností a požadavků z pohledu projektového řízení se však bude velmi podobat. M. Petřík

Je/jsou některé metodiky standardizované?

Bezesporu některé z metodik uvedené na slajdech 15 a 16. Standardizace v rámci organizací je pak jiná otázka. Standardizace metodiky PM v rámci organizace není triviální záležitost a typicky znamená, že se organizace spíše podřizuje metodice (v některých oborech je to samozřejmě žádoucí - příklad armádních zakázek v USA, atd.). Toto ale někdy (dle naší zkušenosti) vede na výsledek, kdy organizace využívá pouze část metodiky (šablony, názvy rolí, ...), ale pracuje stále shodně. Jako i u jiných oblastí by si měla organizace nejdříve zjistit aktuální situaci a teprve následně přijmout příslušná opatření - nikoliv naopak. M. Petřík

Delegování je výborná věc, ale co dělat, když už všichni mají práce nad hlavu? Přetížit členy týmu také nevede k úspěchu.

To je samozřejmě pravda a jednou z hlavních úloh PM je, aby "její/jeho" lidé přetíženi nebyli. Pokud mají práce nad hlavu, tak se samozřejmě delegovat nedá. M. Petřík

Potkávám se s koexistencí rolí project a delivery managera. V jakém vztahu mají správně být? Přebírá delivery manager některé odpovědnosti od projekťáka?

Zde je důležité zmínit, že obě role řeší projektový management, tedy mají mnoho společného. Konkrétní rozdělení odpovědností ale záleží na nastavení v rámci organizace. Rozhodně by ale nemělo nastat, že jsou odpovědnosti nejasné nebo překrývající se (a není jasné, kdo má jakou pravomoc). M. Petřík

Co si myslíte o testování dokumentace?Např. mezinár. schéma ISTQB pro testy popisuje metody testů dokumentace (walkthrough, inspekce...).V ČR se s tím nesetkává

"Téma patří spíš do bloku Testování a QA a s touto metodikou konkrétně jsem se nesetkal. Obecně je tvorba a údržba testovací dokumentace často podceňovaná, resp. nedoceněná, takže snaha o lepší organizaci a standardizaci je ke prospěchu věci, pokud je vedená skutečnou potřebou projektu a ne ""metodikou pro metodiku""." R. Michalský

Doporučujete nějakou metodiku pro sběr/klasifikaci požadavků, kterou považujete za "užitečnou" a ověřil jste si ji Vy sám v praxi (viz FURPS, RUP, atd.)?

"V praxi se (mně subjektivně) nejvíce osvědčuje sběr pomocí ""user stories"" zmiňovaných na přednášce (detaily v kterémkoliv podrobnějším textu o agilních metodikách), což je vlastně návrat ke kořenům use-cases, než je konzultanti zesložitili k nepoužitelnosti :-). Pro specifikaci pak část UML diagramů z přednášky, detaily např. ve Fowlerově Distilled UML. Z ""velkých"" metodik je má okrajová zkušenost s RUP spíše negativní - RUP klade velké nároky na znalost metodiky i na čtenáře a metodika se musí aplikovat ve své úplnosti, což je pro dnešní rychlost vývoje neefektivní a drahé." R. Michalský

Můžete doporučit nějakou metodiku pro sběr požadavků, aby se na nic nezapomnělo?

Viz předchozí odpověď. R. Michalský

Jaké vyjadřovací prostředky doporučujete používat (seznam RQ, mindmap, activity/sekvenční diagramy, atd.). Považujete některé vyjadřovací prostředky za základ?

Viz předchozí odpověď a diagramy z přednášky. R. Michalský

Dovedete zdůvodnit, proč relativně hodně analytiků píše business požadavky jako román na pokračování tzn. je problém se odkazovat na konkrétní část RQ?

"Pokud budu mluvit z vlastní analytické praxe, ""román"" vzniká typicky při psaní scénářů do přílišného detailu místo udržení scénáře krátkého a použití vhodnějších vyjadřovacích prostředků (např. diagramů) pro větší detail. Navíc jednoduchý a přehledný diagram dá často více práce než totéž popsat spoustou nestrukturovaného textu." R. Michalský

Jak vy sám jste spokojen s kvalitou analýz (výstupů) na kterých pracujete? Umíte si říct, že pod nějakou kvalitu nejdete?

Za minimální kvalitu výstupu analýzy SW považuji takovou, podle které lze řešení akceptovat, vyvinout, otestovat a dodat. Ostatních požadavků na požadavky (např. modifikovatelnosti, apod.) se lze krátkodobě vzdát (a vytvořit si tak jistý "analytický dluh"). R. Michalský

Jaké jsou požadované vlastnosti/schopnosti analytika ?

Vyčerpávající seznam potřebných vlastností analytika je velmi dlouhý a dobře zpracovaný např. v BABOK-u. R. Michalský

Jakou máte zkušenost z definicí business požadavků "nezabarvených" návrhem řešení? Daří se Vám?

"V rané fázi analýzy je definice požadavků (nebo spíš potřeb) záměrně bez předjímání řešení užitečné myšlenkové cvičení. Často se tak přijde na myšlenkový ""krok stranou"", který vede k novému a neotřelému řešení problému. Důležité je nezůstat u takovéto na řešení nezávislé formulace požadavků příliš dlouho. Jinak vznikají business analytická zadání odtržená od možností a výhod technické realizace, která je pak zbytečně drahá, dlouhá a občas i nemožná." R. Michalský

Faktická poznámka - V případě, že analytik řeší i technický detail, vlastní vývoj, ... tak už nejde o roli analytika.

"Je to pravda, otázkou je, co s z tohoto faktu vzít? Jedním z hlavních cílů tohoto cyklu přednášek je rozšířit znalosti a chápání ""své"" role a domény i na ostatní role v SW procesu a chápat ho jako jeden celek. " R. Michalský

Kompetence BA (aneb má 4 různé názory) dle waterfall a agile. Je v kompetenci mít jeden názor rozdíl?

Otázka není zcela jasná R. Michalský

Jak řešíte v rámci projektu uzavření scope dodávky. V BU analýze je aktuální problém že zadavatel má tendenci do scope kecat a měnit dlouho po uzavření BRD.

"Jak zaznělo na následující přednášce o architektuře, rychlost a pružnost změn hlavně v IT je pro úspěch organizace zcela zásadní. Z tohoto pohledu není ""kecání"" do scope po termínech principiálně špatné (např. celé agile hnutí říká, že se dá kecat do všeho, co je dál než jeden sprint, typicky max. 2 týdny dopředu), ale zadavatel si musí být vědom všech důsledků, které to má a je zcela v kompetenci analytika je zadavateli říkat. Tj. podle fáze projektu může dojít k vyřazení jiných požadavků, zpoždění, zahození již dodaných funkčností, riziku zavlečení chyb, atd. Tj. se scope dodávky lze pracovat, ale vždy se znalostí a odsouhlasením důsledků a zodpovědností zadavatele změny. Znalost důsledků změn scope je další z důvodů, proč se analytik stejně jako ostatní členové týmu nemá spokojit ""jen"" se znalostí své domény, ale měl by mít přehled o celém projektu a SW cyklu." R. Michalský

Jak řídit/měřit kvalitu sběru požadavků?

Podobně jako můj kolega v přednášce o konstrukci uváděl jedinou platnou metriku kvality kódu "WTF per minute", je nejlepší metrika kvality požadavků a specifikace počet dotazů při realizaci a počet chyb způsobených nejasností analýzy. R. Michalský

Jak přistoupit k požadavku, který je spíše legislativního typu, kde přímo není uživatelský požadavek, spíš dopad (GDPR?)

"Problém formulace legislativních (ale i jiných) požadavků z pohledu analýzy je, přesně jak tazatel píše, absence konkrétního uživatele a jeho interakce. Přesto (nebo právě proto) je pro vhled do analyzovaného problému užitečné prohlédnout skrz právnické formulace a popsat požadavky třeba jako user stories. Např. místo ""správce musí zavést funkční systém řízení a vyhodnocování rizik"" popsat konkrétní scénáře incidentů a jejich detekce, user story auditu, atd." R. Michalský

Myslím si, že chybí zdůraznit základní definice co vlastně je business požadavek (např. neměl by obsahovat jména konkrétních systémů, ale očekávání, ...)

Jak na přednášce zaznělo, pojmu "business požadavek" se záměrně vyhýbáme, protože má v různých metodikách a kontextech různý význam. Místo toho se v přednášce držíme terminologie BABOK-u, který místo toho rozlišuje "business potřebu", tj. cíl nebo důvod změny a uživatelské, bezpečnostní, systémové a další požadavky, které už konkretizují dopad i na jednotlivé systémy, funkčnosti, apod. R. Michalský

A to si nakreslíte graf a do toho jména lidí a hlídáte to na projektu?

Otázka směřuje na matici zájmu a vlivu na projekt uvedenou v přednášce - nejde o to formálně matici mít v nějakém dokumentu namalovanou, ale o mentální model, jak kategorizovat zúčastněné (stakeholders) na projektu a jak se k nim chovat. R. Michalský

Má analytik řešit architekturu?

"Ano, protože obě role jsou si velmi blízké a v mnoha oblastech se překrývají. Stejně jako architekt musí znát uživatelské požadavky při návrhu architektury (viz 4+1 model a prakticky každý arch. framework) musí analytik znát jak obecné architektonické principy, tak architektonická rozhodnutí přijímaná v jeho organizaci. Aby mohl ve své práci prakticky fungovat, musí na základě těchto znalostí přijímat při tvorbě specifikace ""v malém"" i spoustu architekturních rozhodnutí, tj. řešit architekturu. Opět směřuje k ""celostnímu"" pohledu na SW proces , kdy mají mít všichni členové projektového týmu velkou znalost rolí a práce ostatních, aby dokázali efektivně spolupracovat. Což je zároveň jednou z hlavních motivací tohoto cyklu přednášek." R. Michalský

Má být Business analytik na straně zákazníka ideálně z IT nebo z Business?

Je mnoho velmi dobrých analytiků vzešlých jak z businessu, tak z IT. Většinou se liší ve svých silných a slabých stránkách, důležité je velké porozumění a ochota učit se a naslouchat i "druhému" světu, který jim není vlastní. R. Michalský

Školicí prostředí - kam do BA patří požadavky na úpravy školicího prostředí tak, aby bylo možné proškolit vybrané scénáře z daného požadavku?

"Formálně to je požadavek na rozhraní, v tomto případě hardwarové a dá se opět specifikovat pomocí požadovaných user stories popisujících průběh školení, jaká data tam školenci uvidí, jak budou probíhat ""mockované"", tj. simulované business procesy ve školícím prostředí, atd. Na školící prostředí je pak potřeba mít i sadu nefunkčních požadavků, tj. dostupnost, bezpečnost, výkon, odezvu, atd." R. Michalský

Zkušenosti se statickým testováním (např. formální verifikací diagramů) v i mimo ČS.

"Formální verifikace hlavně diagramů chování je popsaná např. ve Fowlerově UML Distilled, v praxi jsem se s ní nesetkal. Velmi dobrou a praktickou verifikací diagramů a celé specifikace je tvorba testovací dokumentace z ní." R. Michalský

Co jsou ty swim lanes? Můžete to blíž vysvětlit?

Swim lanes (doslova "plavecké dráhy") jsou svislé nebo vodorovné čáry rozdělující diagram na pojmenované sekce příslušící např. různým systémům, firmám, procesům, atd. Ukázka např. http://bit.ly/2GmxkeO R. Michalský

Jak lze zajistit, aby měl architekt reálný kontakt s realizací svých návrhů (... a vzniklými problémy) a nenavrhoval pouze tzv. "od stolu" (což se může stát)?

"Jednou z praktických možností je spoluzodpovědnost architekta za úspěch projektu nebo jiným přidáním zájmu EA na výsledné realizaci (např. v rámci projektu se zároveň narovná nějaký technologický dluh, atd.). Jde o přesun role architekta v matici zájmu a vlivu z kvadrantu ""má vliv-nemá zájem"" do ""má vliv-má zájem"". Dobrý architekt samozřejmě i bez výše uvedeného přirozeně usiluje o upřímnou zpětnou vazbu z realizace svých rozhodnutí minimálně kvůli svému vlastnímu zlepšování." R. Michalský

Může existovat v architektuře jak monolit tak i microservices?

Ano, dokonce bývá uváděno, že ve velkých firmách je proces zavádění microservices postupným vydělováním z původního monolitu úspěšnější než tvorba microservices na zelené louce. Na webu uváděno pod názvem "Monolith First" přístup. R. Michalský

Jak poznám správnou velikost microservice?

Jak je v architektuře časté, neexistuje jediná správná a univerzální rada. Možná nejlepším vodítkem je princip "high-cohesion, low-coupling" (vysoká soudržnost, malá provázanost) rozebíraný v přednášce o konstrukci. Tj. microservice má poskytovat "jasně ohraničenou službu" úplně a to s minimálními závislostmi na okolí. Definice "jasně ohraničenou služby" je pak naprosto kontextově závislá. R. Michalský

Musí být ODS real time a nebo stačí data aktualizovat třeba 2x denně?

Závisí na požadavku na aktuálnost dat v Operational Data Store. Dnešní uživatelé jsou zvyklí na data prakticky online, tj. čím dál častěji se volí real-time úložiště, ale nutné to není. R. Michalský

Není sdílená databáze příliš úzké hrdlo?

Ano, jedna z nevýhod sdílené DB jako integračního návrhového vzoru je úzké hrdlo DB přístupu. Tam kde je požadovaná vysoká propustnost dat je třeba zvolit jiný přístup. Výhodou DB je zase datová integrita a hlavně transakčnost. R. Michalský

Může uvést příklad příliš abstraktní architektury?

"Správná míra abstrakce závisí na situaci. Např. pokud mám firmu s e-shopem, CRM a skladem, které veselé fungují nad společnou databází, je pro mne integrační vrstva nebo master data management příliš abstraktní architektura. Naopak ve velké organizaci s desítkami komunikujících systému a DB je to nutnost. Obecně abstrakce a přidávání jejích úrovní je, jak zaznělo na přednášce, základním nástrojem architekta. Má sloužit k řešení problémů, které jsou na nižší úrovni abstrakce nepřehledné nebo obtížně řešitelné. Pokud abstrakce problém nezpřehlední, ale zatemní, je nadbytečná." R. Michalský

Doporučíte literaturu?

Viz slidy z přednášek R. Michalský

Kdy nasadit ESB a kdy BPM?

Viz odpověď č. 6, závisí na situaci. ESB specificky prakticky vždy, pokud mám více než malé jednotky systémů, které spolu komunikují v rámci větších business procesů. R. Michalský

Musí být ODS v režimu real time? JE to potřeba? Děkuji

Viz otázka č. 4 R. Michalský

Proč mezi integračními koncepty nejsou webové služby?

Webové služby jsou zahrnuty, stejně jako např. REST služby, pod koncept "Remote Procedure Call", tj. synchronního volání dvou systémů na dálku, obvykle přes síť. Webová služba (SOAP protokol) je jeden ze standardů takové komunikace. R. Michalský

Jak lze bojovat s technickým dluhem v rámci kontinuálního rozvoje systému, kdy mají nové funkce jednoznačnou přednost před časem na údržbu?

Práce s technickým dluhem a prioritizace činností jsou z podstaty manažerská rozhodnutí. Je však potřeba zajistit, aby příslušní lidé věděli o technickém dluhu, jeho rozsahu a nákladech ("výši úroků"). Hodně ale také může pomoci drobné dluhy řešit kdykoliv je objevím v rámci jiného úkolu ("fix broken windows") nebo se jim věnovat třeba pět minut denně. J. Toušek

Můžete říct konkrétní příklad rozhraní, tedy definice kontraktu?

V Javě např. rozhraní Set. Definuje kontrakt množiny (každý prvek nejvýše jednou), aniž by se zavazoval k tomu, jak toto bude hlídat. Zároveň se vymezuje negativně - např. explicitně uvádí, že při iteraci nezaručuje pořadí prvků. J. Toušek

Jaké jsou nevýhody Rich domain modelu?

Použití Rich Domain Modelu je závislé na konkrétní situaci, tedy pokud je v cílovém řešení množství domén, které od sebe mohou dědit své vlastnosti je použití tohoto konceptu vhodné. Nevýhodou je větší složitost tohoto konceptu z pohledu abstrakce jednotlivých domén. V. Jinoch

Co když musíme vyvíjet na aplikaci, kde je DRY princip již porušen?

Ano, to je velmi časté. Nicméně i zde lze postupným zlepšováním a refactoringem situaci řešit. Ne vždy se povede zajistit dedikovaný čas na refactoring, pokud ale každý vývojář věnuje zlepšení alespoň 5 minut (a nebude problém přehlížet), stav se začne měnit k lepšímu. J. Toušek

Nehrozí u pře-použití návrhů spory o autorství?

Návrhové vzory nepodléhají ochraně osobního vlastnictví, uvedené plyne ze způsobu, jakým vznikají. Shodné platí například o nemožnosti patentování kruhu. V. Jinoch

Jak přistupovat k dodržovaní metriky severit, kdy tester nalezne chybu, která neblokuje další průchod, ale z pohledu banky je fatal. Např. záporný úrok, smlouva

Severita má hodnotit závažnost chyby z pohledu businessu, priorita z pohledu testování a potřeby rychlosti opravy. V tomto případě tedy nastavíme severitu jako nejvyšší a prioritu nejnižší. O. Ertl

Jak zvolit vhodné pokrytí, např. i Servisu 24? Děkuji

Pokrytí requirementů testy se řídí jednoduchými pravidly. Nejlépe pokryté chceme mít takové requirementy/ funkcionality které buď používá velké množství lidí tedy hrozí ztráta reputace či přetížení call centra a nebo hrozí velká finanční ztráta, například odchod významného klienta s portfoliem v miliardách. O. Ertl

Co jsou to regresní testy?

Regresní testy jsou testy stávající funkcionality které se provádí v dalším releasu po přidání nové funkcionality s cílem ověřit že nová funkcionalita nerozbila funkcionalitu z minulého releasu. O. Ertl

Jak tedy hodnotit a motivovat testery prosím?

Teste je vhodné motivovat úplně stejně jako vývojáře, tedy mají být zapojeni do teamu s cílem včas a kvalitně dodat sw. Hodnocení tedy nemá být na základě počtu nalezených chyb, ale na základě včas a kvalitně napsané testovací dokumentace, včas a kvalitně provedených testů a retestů defektů a v celku tedy na včas dodaném kvalitním SW. Jde o to aby tester byl motivován být efektivní. O. Ertl

A jak se lze bránit defektům přímo v testech (chyba scénáře, chyba programu, co testuje, ...)?

Chybám v testech se lze bránit důslednou revizí testovacích scénářů a to jednak jiným testerem nebo i analytikem či vývojářem. O. Ertl

Jak zajistíte, že jsou checklisty stále aktuální? Co když je pak checklist na checklisty, apod.?

Aktuálnost všech listů je zajištěna pravidelným review checklistu které obvykle vychází z požadavků ISO. O. Ertl

Jakou doporučujete praxi pro code review? Každý den a všichni, vybraní lidé...? Má to být nedílná součást vývoje? Je to efektivní?

Code review doporučujeme vždy u juniorních pracovníků a složitých funkcionalit. U seniorních pracovníků či jednoduchých funkcionalit je review neefektivní a záleží na posouzení konkrétního vývojáře. O. Ertl

Kdo má být odpovědný či schvalovat testovací scénáře?

Záleží na typu testovacích scénářů, například u UAT testů je za toto zodpovědný business, neboli ten kdo bude finálně SW používat. O. Ertl

Prostředí spořitelny - mělo by TCOE kromě SIT testů řešit u UAT testy Robert Černý

TCOE zajišťuje podporu UAT testů, vlastní tvorba testů jejich svalování či exekuce je na businessu nedohodne-li se jinak. O. Ertl

Jak tedy motivovat/hodnotit testery?

Teste je vhodné motivovat úplně stejně jako vývojáře, tedy mají být zapojeni do teamu s cílem včas a kvalitně dodat sw. Hodnocení tedy nemá být na základě počtu nalezených chyb, ale na základě včas a kvalitně napsané testovací dokumentace, včas a kvalitně provedených testů a retestů defektů a v celku tedy na včas dodaném kvalitním SW. Jde o to aby tester byl motivován být efektivní. O. Ertl

Jak je to s FAT testy mají být prováděny vývojáři nebo testery?

U FAT testů záleží na konkrétním projektu, u jednoduchých stačí provézt testy vývojáři, u složitějších již je vhodné zapojit testery - takto to vnímám v kontextu ČS. Obecně ovšem jedná-li se o dodávku SW na klíč/ krabici zákazníkovi tak samozřejmě FAT testy dělají testeři. O. Ertl

Platí to samé pro agilní vývoj (detail dokumentace)? Je rozdíl v dokumentaci u waterfall/agile přístupu?

"Z našeho pohledu není vzhledem k metodice přístupu základní rozdíl. Agilní vývoj rozhodně neznamená, že žádná dokumentace nevznikne nebo není potřeba. Zákazník bude bezesporu vyžadovat uživatelské příručky, popis stávající podoby systému, administrátorskou příručku, atd. Tyto dokumenty musí vzniknout (a je správné, aby vznikly) nehledě na metodiku. Je možné, že například průběžná dokumentace nebude u agilního vývoje tak detailní, nicméně na konci projektu by tak jako tak měla být k dispozici." B. Zoubek

Vybral byste pro nový projekt SVN a nebo GIT?

Obecně by mělo platit, že vybírám takový nástroj, který nejvíce pomůže v konkrétní situaci. Uvedené systémy jsou příkladem dvou nejoblíbenějších řešení, jeden je centralizovaný, druhý distribuovaný. Nedovolíme si preferovat ani jeden, nicméně naše zkušenost říká, že pokud nemá tým (zákazník) žádnou dosavadní zkušenost s verzovacími systémy, je SVN pro začátek lepší (jednodušší flow, lepší práce s binárními soubory, lepší podpora v prostředí Windows). M. Petřík

Jak se díváte na dokumentaci v agilním světě?

Obdobné s první otázkou. B. Zoubek

Není lepší udržovat textové dokumenty v GoogleDoc namísto verzování v SVN?

Ano, proč ne, pokud to projektu vyhovuje. Konfigurační řízení však není pouze o dokumentech, ale i o zdrojových kódech, tedy o všech s projektem souvisejících SW položkách. Otázka tedy zní: jak je možné svázat danou verzi dokumentu na GoogleDoc s danou verzí systému? Pokud je to vyřešeno, rozhodně nevidíme problém. Pokud to vyřešeno není (přiřazení není jednoznačné), není konfigurační řízení dotaženo. M. Petřík

U Google disku je ještě jeden aspekt verzování. Někdo nahrává stále stejný název a soubor verzuje. Jiný povyšuje verzi v názvu souboru a starší verze zůstávají.

Tohle bohužel ukazuje na ne zcela ideálně nastavené konfigurační řízení. U tohoto typu služby lze využít její funkce pro verzování, případně zvolit svůj proces, nicméně vždy by daný přístup měl být využíván všemi. V opačném případě hrozí, že dojde k záměně položek nebo jednoduše chybě. M. Petřík

Jakou máte zkušenost s verzováním databází?

Nástroje pro verzování DB jsou již bez problémů k dispozici, jako příklad lze zmínit řešení Liquibase nebo Flyway. V této oblasti často narážíme na otázku, jako verzování realizovat u systému, který je již delší dobu provozován. Existují dva možné přístupy: 1/ Vše postavit nanovo, 2/ Od jisté chvíle nastavit proces tak, jako by verzování existovalo od začátku. Jednoznačně doporučujeme variantu 2, kterou velmi často praktikujeme na našich projektech. U nových projektů je samozřejmě logická varianta 1. Velmi pěkný článek pojednávající o této problematice je k nalezení zde: http://www.liquibase.org/documentation/existing_project.html M. Petřík

Opravdu DevOps někde funguje?

Nejdůležitější věcí, kterou je nutné mít při zavádění automatizace (DevOps) v hlavě, je důvod, proč dané děláme. Velmi často se setkáváme s cílem: být jako Google, Amazon, … Ale opravdu budeme pracovat se stovkami/tisíci instancí naší aplikace? Opravdu budeme zpracovávat petabajty dat? Většinou toto není cílový stav, a tedy stačí postupné zlepšování, které dle naší zkušenosti funguje nejlépe. U nových projektů se vyplatí začít s kompletní sadou nástrojů, nicméně u běžících projektů (u kterých se nachází obvykle nejčastěji) je zavedení X nových nástrojů často cestou ke zkáze. DevOps jsou mimo jiné o neustálém zlepšování -> proces, kdy kontinuálně zlepšujeme a optimalizujeme. Zda dané nastavení funguje, či nikoliv musí zhodnotit každý sám. Základní indikací ale je, že zavedením nového nástroje/vylepšení došlo ke zlepšení -> rychlosti, kvality, spolehlivosti, ... M. Petřík