Tag: architekt

Agile Prague Conference 2014

Jako každý rok je tady doporučení, co byste neměli minout, na konferenci Agile Prague. Těšit se můžete na Lindu Rising, která v Praze na Agile Prague byla před dvěma lety, a osobně její přednášky považuji bez ohledu na téma za vynikající. Ze známých tváří se dále můžete těšit na Andrea Provaglio, který se vrací do Prahy již popáté a tentokrát to bude na téma očekávání – The Expectation. Anebo Kevlin Henney, který kromě přednášek vede i jednodenní workshop na téma Agilní architektury – Architecture with Agility.

Kdo na druhou stranu bude v Praze poprvé a rozhodně stojí za zmínku je Vasco Duarte. Jeastli vás zajímá, o čem to bude, podívejte se na tweety #NoEstimates. Jak to s těmi odhady je vysvětlí v přednášce How to improve software project estimates – The #NoEstimates view.
Několik přednášek se také věnuje tomu, jak aplikovat Agile a Scrum pro více týmů – například keynote, kde Dean Leffingwell mluví o Scaled Agile Framework (SAFe).

Stejně jako předchozí roky se i letos věnujeme developerům i testerům, dáváme prostor i místním firmám, aby mohly prezentovat jak na tom vlastně jsou, v praktických case-studies.
Během konference vám své Agilní certifikace představí i ICAgile, která své certifikace zaměřuje na Agilní metody v širším kontextu než je jen Scrum proces.

Konference není jen o poslouchání talků. Možná nejdůležitější jsou diskuse s ostatními účastníky a speakery. Proto pořádáme první den networking party, kde se můžete seznámit s ostatními a společně prodiskutovat, jaké máte zkušenosti. Druhý den je pro tyto diskuse vyhrazen kromě přestávek a dlouhého oběda open jam session.

Doufám. že se vám program konference i letos bude líbit.

Agilní Architektura

Poslední dobou dostávám hodně otázek na to, jak má fungovat architektura v Agilních týmech. Čistý Scrum roli architekta nemá. Mluví o samoorganizujících se zastupitelných týmech. Když to škálujeme dál, tak se mluví o Scrum of Scrums. Ale architekti nikde. To ale neznamená, že nejsou potřeba.

Jak to tedy vypadá v jednoduchém případě jeden Product Owner, jeden produkt, jeden Scrum tým. Tam je architekt součástí týmu. Je to zkušený vývojář, který se dívá dopředu na celý produkt a pomáhá týmu zvolit takové řešení, které vyhovuje celkové vizi produktu. A protože Scrum má pravidlo, že tým pomáhá Product Ownerovi, pak takový architekt spolupracuje s Product Ownerem na tvorbě Backlogu. Pomáhá mu odstraňovat rizika, dodefinovává akceptační kriteria.

Když to škálujeme na větší produkty, kde je více týmů, pak obvykle máme dva typy architektů. Jednoho – ‘velkého‘ – který je na úrovni celého produktu a stanovuje pro týmy takzvanou runway, v rámci které by se měli držet. Takový architekt je součástí týmu Product Ownera a dívá se spolu s ním klidně i několik let dopředu. Zároveň v každém týmu je takový ‘menší‘ architekt, který týmu pomáhá porozumět dané architektonické runway a dělat v rámci ní každodenní drobná rozhodnutí. Všichni tito architekti jsou samozřejmě v častém kontaktu a společně definují architekturu produktu. Jedna z dobrých best practices je, že na takovýchto velkých projektech dělají týmy nejen review mezi sebou, ale věci zrevidované v rámci týmu posílají na takzvané architecture review ‘velkému‘ architektovi. Ten samozřejmě neprochází v detailu všechny změny, ale dává pozor, aby změny byly konzistentní a odpovídaly dané architektonické runway.

No a jestli chcete o Agilní architektuře vědět víc, přihlaste se na workshop “Architecture with Agility“ který vede Kevlin Henney před konferencí Agile Prague 2014, v pátek 12. září. Nebo na konferenci samotnou 15.-16. září, kde jedna z keynote, kterou přednese Peter Eeles, je na téma “Architecture, Agile and DevOps“.

A co o workshopu píše Kevlin?

  • I will be covering the following topics during the day:
  • Defining software architecture as a service to the business
  • The relationship between development process and software architecture
  • The relationship between architecture and development teams and practices
  • The importance of code habitability
  • Empirical processes and architectural decisions as hypotheses
  • The Worse Is Better approach versus the up-front approach to architecture
  • Dealing with uncertainty and change, and using uncertainty and change to define the architecture
  • Architectural properties and requirements
  • Different architectural styles and patterns and their trade-offs
  • Identifying and managing technical debt
  • Refactoring, rewriting and re-engineering
  • Decoupling and dependency management