Términos a googlear
Kent Beck, modern agile, extreme programming, time value money, economía de escala, real options, technical debt, refactoring, scrum, kanban, waterfall, agile, risk assumption test, minimun viable product, cynefin, value stream, cuello de botella…
Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets accumulated technical debt becomes a major disincentive to work on a project.
Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The biggest cost of technical debt is the fact that it slows your ability to deliver future features
Risk of Introducing Bugs (not caught by testing) Cost and Risk of Refactoring tend to be low, as we have good UnitTests. Also the “size” of refactorings tends to be smaller Adding new features no longer corrupts the system’s structure Optimizing the maintenance process to minimize the visible changes to the source code must, as with any optimization, compromise something else Improves programmer’s understanding of the system Refactoring produces shorter simpler methods. It’s less work to understand the smaller amount of code that needs to be changed to implement any given function
Coding as team activity by Xavi Gost
- programar es una actividad de equipo. Una persona sola no puede hacer nada que tenga impacto
- se supone que me pagan para dejar allí conocimiento
- consenso es estar de acuerdo en este momento para hacer esto concreto
- pair programming extenuante. También hay que tener tareas solas
- en el panel apuntar concerns: “qué mierda me ha hecho angelito”. No le molesto en el momento. Los concerns no los voy a dejar pasar… pero los atacaré en la review. La decisión la toman todos los que tienen que vivir con la decisión
- los argumentos tienen que estar razonados
Scrum y la gestión del riesgo
ampliación descontrolada de características
captura de requisitos mal realizada
plazos optimistas impuestos
síndrome de desarrollo orientado a la investigación
fallos de los proveedores
fricción con los clientes
RAT: Riskiest Asumpting Test vs MVP Minimun Valuable Product
MVP is not a product. Developing a production-ready product is more than that.
[Agile Architecture, Risk-driven]
Identify and prioritize risks
Select and apply a set of techniques
Evaluate risk reduction
Designing early customer learning
How to test assumptions and reduce risk, quickly
Start by clarifying your learning goals, assumptions, and hypotheses
Prioritize assumptions on two dimensions: uncertainty and risk
Make your assumptions testable
Ask yourself: What is the smallest thing we can do to test this hypothesis?
Create the “learning vehicle”
Real agility is awesome at managing risk.
You cannot be agile if you don’t actively manage your risks.
A case for outside in development
From system to DDD: better risk management (architecture)
The Cost Center Trap (Poppendieck)
- every ‘full stack team’ working on a digital problem should have ‘full stack responsibility’ for results,
- very few of those agile teams are likely to focus on improving overall business performance. The incentives send a clear message: business performance is not the responsibility of a cost center.
- capitalization of development creates a hidden a bias toward large projects over incremental delivery, making it difficult to look favorably upon agile practices.
- customer obsession, a skeptical view of proxies
Cost accounting is a problem in the knowledge work
- Software is neither construction nor manufacturing. Software is learning, where we deliver learning as pieces of finished product. When we have finished learning enough for now, we stop working on the deliverable.
- That would reduce the cost per feature. Smaller features allows us to learn faster and see value faster.
- Cost accounting has a big problem. It does not account for Cost of Delay
- There are alternatives to cost accounting: throughput accounting and lean accounting.
Nat pryce y steve freeman sobre tech debt
The great thing about Ward’s original concept was making explicit that we can trade off short- vs long-term. Like making Refactoring a thing. And giving us a mechanism to do so with iterative development. It was never a licence for rushed hackery. Indeed. My understanding of Ward’s metaphor was that tech debt was what ENABLED iterative development, not something to be avoided. but the meaning changed over time, until it became as on the tech debt conf website. Along the way, a powerful tool was lost. I guess. I was put off by “…can make future changes more costly or impossible”. To me, tech debt is what allows future changes at all. And I’ve been using “tech underinvestment” for code becoming too costly to change.
About Technical Debt
- Coding Horror:paying-down-your-technical-debt
- Martin Fowler:TechnicalDebt
- Martin Fowler: Technical debt quadrant
- Henrik Kniberg on technical debt
- Artículo larguísimo de la InfoQ sobre tech debt
- Martin fowler refactoring example
- Smells of refactoring
- When refactor: prioritisation vs opportunistic
- Refactoring catalog <-- ¡me parece infumable! No te da pistas para razonar…
Coding as team activity by Xavi Gost
Architecture as risk management
Scrum and risk management:
Agile is not faster
- Speed in software development
- RAT: Riskiest Asumpting Test vs MVP Minimun Valuable Product.
- Agile Architecture, Risk-driven
- Designing early customer learning
- How to test assumptions and reduce risk, quickly
- Start by clarifying your learning goals, assumptions, and hypotheses
- Prioritize assumptions on two dimensions: uncertainty and risk
- Make your assumptions testable
- Ask yourself: What is the smallest thing we can do to test this hypothesis?
- Create the “learning vehicle”
- List of software risks
- Cynefin for Developers
- Modern risk management with kanban
- Evolutionary agility
- A case for outside in development
- From system to DDD <-- better risk management (architecture)
- Minimum Viable Investment
- Risks and reversebility
- Waltzing with Bears: Managing Risk on Software Projects
- Growning tech stack and risks
- Rainsberger: the economics of software design
- Rainsberger: 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development
- The eternal struggle between business and programmers
- Risk stormming
- Architecture as risk
- Modern Agile
- Extreme programming explained
- The economics of iterative software development
- Software by Numbers: Low-Risk, High-Return Development