Welcome back to Not So Random Software, this week’s links are dedicated to Agile! Have you ever taken a step back and spent some time reflecting on why you use Agile methods every day? In what context is this the perfect choice? Is there a case for not using Agile methods? Not exactly your everyday questions, hope you enjoy this random walk!
A random article or paper
A Risk-Driven methodology for Agile Software Engineering
This article introduces a risk-driven model for architectural design. Its essential idea is that the effort you spend on designing your software architecture should be commensurate with the risks faced by your project.
A random video or podcast
Why good leaders make you feel safe.
In this podcast, Robert C. Martin (Uncle Bob) talks about the Agile Manifesto, how the methodology came about, and how it applies today; a good summary for what you might find in his latest book Clean Agile.
A random book
Balancing Agility and Discipline: A Guide for the Perplexed.
The authors identify five critical factors — personnel, criticality, size, culture, and dynamism — for creating the right balance of flexibility and structure. Their analysis will help developers who must sort through the agile-disciplined debate, giving them guidance to create the right mix for their projects.
A random tool
Agile Monte Carlo Estimation, in your browser.
Story points are so volatile that sometimes it feels impossible to estimate your sprint capacity, but that’s not the point. Shift your perspective to risk management and suddenly all you have is risk mitigation and a communication problem; do not try to solve the knapsack problem every sprint.
A random line of code
Little things in Ruby make all the difference, here is one!
|
1 2 3 4 5 6 7 |
h = { "a" => 100, "b" => 200 } # the lazy Rubyist way h.keys.each {|key| puts key } # the eloquent Rubyist way h.each_key {|key| puts key } |
A random quote
We all make latency/throughput tradeoffs every day […] By emphasizing latency we get feedback sooner. Learning and adapting to external changes lead to less waste and therefore greater efficiency. Each piece is inefficient (compared to some theoretical maximum), but the whole is efficient. In my world, latency dominates. Mostly. But it depends.Kent Beck