Agile a DevOps: přátelé nebo nepřátelé?

DevOps je princip Agile přesahující rámec softwarového týmu. Otázkou však je, který z nich v zápase vyhraje?

Ian Buchanan Ian Buchanan

V prvním rohu máme certifikovaného scrum mistra, jemuž přátelé přezdívají Extrémní programátor a děti Nebezpečný táta… Agile!

V opačném rohu máme šampiona štíhlé kultury, který kontinuálně dodává svou infrastrukturu jako kód. Jeho levou rukou je dev, jeho pravou rukou je ops… DevOps!

Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.

Agile je víc než jen Scrum

V některých týmech Scrum představuje rozdíl mezi neustálým frustrujícím bojem a produktivní a obohacující týmovou prací. V jiných Scrum nahrazuje politikaření a puntičkářství objetivitou a soustředěním. Občas je také brán za jakési dogma. V případě, že firemní omezení nebo samotná práce vyžadují něco jiného, může tým agile využít základních principů Scrumu, prozkoumat své postupy a přizpůsobit se za účelem zvýšení efektivity. Je to obzvláště důležité v případě, že se Scrum používá mimo kontext vývoje softwaru.

Plánování neplánované práce

In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).

In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviewsautomated acceptance tests, and continuous integration.

Další procesy Agile, jako je Extrémní programování mají silný názor ohledně toho, jak technické postupy podporují schopnost týmu zachovat udržitelné tempo a poskytovat managementu a zúčastněným stranám dostatečnou transparentnost a viditelnost. Některé týmy Scrum se uchylují k přidávání technických úkolů do backlogu. I když je to v souladu s pokyny scrumu, nastává často praktický problém se zaujatostí vlastníka produktu ve prospěch funkcí. Pokud není vlastník produktu spíše technický typ, mohou mu chybět schopnosti vyhodnocení nákladů a přínosů technických praktik. Pro vlastníka produktu je to ještě těžší kvůli tomu, že se technické úkoly prolínají s provozními operacemi, které podporují spolehlivost, výkon a bezpečnost.

Vlastníci produktů a vlastníci služeb

V Atlassianu jsme poznali, že je dobré mít dvě různé role pro produkty, které provozujeme. Naši vlastníci produktů dobře chápou, které funkce uživatelé potřebují, ale nejsou tak dobří ve vyvažování těchto funkcí s mimofunkčními požadavky, jako je výkon, spolehlivost a bezpečnost. Některé produkty SaaS v Atlassianu proto mají také vlastníka služby, který zodpovídá za prioritizování těchto mimofunkčních požadavků. Čas od času tito dva vlastníci musí trochu „handlovat“, většinou však vedle sebe mohou pracovat nezávislé týmy. Nejedná se o jediný způsob, jak „zesílit zpětnou vazbu“ z provozu, ale pomáhá to překonat známou zaujatost, kterou vlastníci produktů projevují ve prospěch funkcí. Tento přístup „dvou vlastníků“ není jedinou cestou k DevOps. Důležité je začít pohlížet na tyto mimofunkční charakteristiky jako na „funkce“ a být schopní je plánovat a prioritizovat stejně jako jiné funkční uživatelské příběhy.

V konečném důsledku žádná z těchto kritik Scrumu nepatří neodmyslitelně k samotnému Scrumu. Stejně jako všechny metody Agile má i Scrum zabudovaný mechanismus zlepšení procesu, kterému se říká „retrospektivy“. Je proto rozumné domnívat se, že některé týmy Scrum budou z DevOps těžit jako ze zdroje inspirace a využijí retrospektivy Scrumu k vyladění a posunu na cestě DevOps. Prakticky však zjistíme, že většina týmů potřebuje infuzi nápadů zvenčí. Dokud nebude DevOps mainstreamem (snad i vyučovaným ve školách), nebude organickým výsledkem scrumu. Zda tým angažuje instruktora Agile, nebo DevOps pravděpodobně není tak důležité, hlavní je, aby dotyčný přinesl zkušenosti s automatizací při vytváření, testování a nasazování softwaru.

DevOps je víc než jen kontinuální dodávání

When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.

The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).

The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.

Tři způsoby

DevOps není jen o automatizaci kanálu nasazení. Podle Johna Allspawa je DevOps o tom, že „provoz přemýšlí jako vývojáři a vývojáři přemýšlí jako provoz.“ Na základě této myšlenky vystavěl Gene Kim tři způsoby (principy) DevOps:

První způsob Systémové myšlení emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.
Druhý způsob Zesílení smyček zpětné vazby vytváří smyčky zpětné vazby zprava doleva. Cílem téměř každé iniciativy zlepšení procesu je zkrátit a zesílit smyčky zpětné vazby, aby bylo možné kontinuálně provádět potřebné opravy.
Třetí způsob Kultura kontinuálního experimentování a učení vytváří kulturu, která podporuje dvě věci: 1. kontinuální experimentování, riskování a poučení z nezdarů, 2. pochopení, že opakování a procvičování je předpokladem k mistrovství.

 

Kontinuální dodávání se soustředí na první způsob: automatizaci toku mezi vývojem a provozem. Automatizace hraje ve zrychlování systému nasazování zřejmou roli. Systémové uvažování však nespočívá jen v automatizaci.

The Second Way is characterized by the practice, "Devs wear pagers too."  Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.

The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.

Ve Scrumu je každá retrospektiva příležitostí ke zlepšení postupů a nástrojů. Pokud však tým těchto příležitostí nevyužívá k řešení krátkodobých i dlouhodobých technických problémů, bude jen čekat, až vlastník produktu tyto úkoly kontinuálního dodávání vloží do backlogu – což se nikdy nestane.

DevOps je princip Agile přesahující rámec softwarového týmu

Scrum je založen hlavně na následujícím principu Agile: „Vítejte měnící se požadavky – i v pozdní fázi vývoje. Procesy Agile využívají změny k získání konkurenční zákaznické výhody.“

Kontinuální dodávání je založeno hlavně na následujícím principu Agile: „Naší nejvyšší prioritou je uspokojit přání zákazníka díky včasnému a kontinuálnímu dodávání hodnotného softwaru.“

To znamená, že Agile je více o přijímání přicházejících a odcházejících změn než o ceremoniálech, jako jsou standupy a plánování sprintů. Jistě, v manifestu Agile je 10 dalších principů. Mezi těmito principy byste se však neměli snažit vybrat jediný – měli byste je brát jako jeden celek. Tyto principy společně představují přístup vítající změnu, který je společný pro Agile i DevOps.

Tito lidé se zasekli ve snahách udržet v provozu křehké systémy, které jsou také nejdůležitější pro obchod. Vzhledem k tomu, že jsou pro obchod nejdůležitější, je v nich potřeba provádět ty neujrgentnější změny. V tomto případě myšlenka přijímání změn Agile rozhodně není „změnou pro změnu“. Myšlenka spočívá v tom, aby vývojáři zodpovídali za kvalitu svých změn a zároveň zvyšovali celkovou kapacitu dodávání obchodní hodnoty. Toto zaměření na obchodní hodnotu je dalším aspektem, který principy Agile a DevOps sdílí

Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.