<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workflow on Osmar Petry</title><link>https://osmarpetry.dev/tags/workflow/</link><description>Recent content in Workflow on Osmar Petry</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 15 Jan 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://osmarpetry.dev/tags/workflow/rss.xml" rel="self" type="application/rss+xml"/><item><title>ADR — Architecture Decision Records</title><link>https://osmarpetry.dev/blog/adr/</link><pubDate>Wed, 15 Jan 2025 00:00:00 +0000</pubDate><guid>https://osmarpetry.dev/blog/adr/</guid><description>&lt;p&gt;ADRs (Architecture Decision Records) are essential documents in software engineering that capture important architectural choices and the context behind them. In an Obsidian vault, ADRs integrate naturally into project documentation.&lt;/p&gt;&#10;&lt;h2 id="why-use-adrs"&gt;Why use ADRs?&lt;/h2&gt;&#10;&lt;p&gt;In long-running projects — such as framework migrations or service changes in Go or Java — decisions change constantly. Without recording &lt;em&gt;why&lt;/em&gt; a tool was chosen over another, the team (or even yourself) may forget the reasoning months later, losing the context that justified the choice.&lt;/p&gt;</description></item><item><title>Agile Software Development</title><link>https://osmarpetry.dev/blog/agile/</link><pubDate>Wed, 15 Jan 2025 00:00:00 +0000</pubDate><guid>https://osmarpetry.dev/blog/agile/</guid><description>&lt;p&gt;Agile is a set of values and principles for software development that emphasizes flexibility, collaboration, and iterative delivery. Rather than following a rigid plan, Agile teams adapt to changing requirements and deliver working software frequently.&lt;/p&gt;&#10;&lt;h2 id="what-is-agile"&gt;What is Agile?&lt;/h2&gt;&#10;&lt;p&gt;Agile is not a single methodology but rather a philosophy that encompasses various frameworks and practices. The core idea is to break down large projects into smaller, manageable pieces that can be delivered incrementally.&lt;/p&gt;</description></item><item><title>Shape Up: Stop Running in Circles and Ship Work that Matters</title><link>https://osmarpetry.dev/blog/shape-up-2020/</link><pubDate>Wed, 15 Jan 2025 00:00:00 +0000</pubDate><guid>https://osmarpetry.dev/blog/shape-up-2020/</guid><description>&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;&#10;&lt;p&gt;In December 2020 I read several books and papers: &lt;strong&gt;The Mythical Man-Month&lt;/strong&gt;, &lt;strong&gt;Design by Contract&lt;/strong&gt;, &lt;strong&gt;Programming with Abstract Data Types&lt;/strong&gt;, &lt;strong&gt;Shape Up&lt;/strong&gt;, and &lt;strong&gt;Domain-Driven Design&lt;/strong&gt;. Their ideas map directly to problems and solutions I encountered building apps in recent years.&#10;The largest recurring gap in real projects is the &lt;strong&gt;beginning&lt;/strong&gt;—how we &lt;strong&gt;shape&lt;/strong&gt; and refine the work—more than the middle or the end. &lt;strong&gt;Shape Up&lt;/strong&gt; gives a concrete way to close that gap in modern teams.&lt;/p&gt;</description></item></channel></rss>