Real life TDD: Building a Spaceship
I bet you've had enough of calculator examples. Let's do something important. Something that will change the world. We're going to TDD a... Spaceship!
In this tutorial we're going to:
• Collect requirements
• Analyze the requirements as we go
• Discuss design options
• Evaluate API
• Have fun
• Build a real (virtual) spaceship using test driven development.
If you ever thought of building a spaceship, this is your chance to do it the right way!
Attendees work in pairs, and need an IDE and a test framework. Language is irrelevant, along as the pairs can work together. We work in cycles, each cycle concentrates on a certain technique: naming, ping-pong, etc. Then we review and continue to the next round.
TDD For The Rest of Us
Any agile methodology today will tell you that you have to use TDD to support it. But as it’s considered a developer’s job, many people with other roles don't get into it.
Which is a shame.
TDD is a great tool, not just for creating a better design. From my experience, people outside programming that paired with developers came out with a better understanding of development. The communication level between the team members sky rocketed, and of course, quality benefited - both in terms of early success in finding bugs and implementing features correctly.
In this workshop, we'll do some mob programming. We'll write together as a group tests and code for solving a real Star Wars problem. And we'll discuss what we're doing, refine our specs, as well as see what changes in the design tell us.
No need to know how to code (but you can join in if you can). Star Wars knowledge is preferable. The key thing is to understand better what the other side lives. Neither of us is on the Dark Side.
May the Force be with us!
To Estimate Or #NoEstimate, That Is The Question
From the early days of agile, there were discussion on how to do estimations “right”. Although there’s no real mentioning them in the agile manifesto, scrum and other methodologies have put effort into this topic because there seems a need for estimations.
What makes an estimation method work? And what will happen one day if we stop estimating?
In this talk, I’m going to discuss where estimation works, what we do with estimations and if that’s the only way to do it. We’ll talk about how our experience and biases control them, and how the #NoEstimates discussion tries to change the way we make decisions.
The next time people ask us for estimations, let’s consider the process first. Then we’ll give them an answer. Maybe.
The Most Beautiful Code in the World
We don’t get many opportunities to make our code as beautiful as it can be. We try to do our best, but due to pressure, deadlines, or conflicting ideas of what beauty is, we stop.
Not this time. In this workshop, we’ll write the most beautiful code we can. Nothing is more important, and you have all the time to make it so. It’s about showing off!
We’ll start from a simple goal, and using TDD (or not, it’s your choice) will design the code. Once we identify a code smell, we’ll deodorize it. The code needs to work, (and you need to supply proof), but otherwise, it’s open season on simplicity and beauty.
This session is all about deliberate practice, and this time we’re focusing on form. Make it a classic!
We're going to do 4-6 Pomodoros, which take around 2-3 hours total (It's really flexible). The group is given a problem to code, with just 2 requirements:
1. Write the best code you can.
2. At each pomodoro's end prove that everything works (tests, logs, whatever).
Inside a pomodoro, people work in pairs. Programming language doesn't matter, but a pair should at least be able to work together. I walk around and identify code smells. The smell list is presented on the board at all time. When I identify a smell, I put a "break note" near the pair. They are then stuck until they fix that smell and show me.
The New Agile
We know that agile methodologies work at the team level, and there is now even an effort to scale into whole organizations.
There is a clear reason behind this: we found ways to improve performance, by analyzing situations better, and making better decision. Every organization wants to apply this in every level. Like in the late 90s, new ideas are coming out that challenge the way we think, and this time they don't just answer development. Ideas like Beyond Budgeting, Lean Startup, Cynefin, Real Options, Feature Injection, SAFe, Design Thinking, #NoEstimates, Cost of Delay and others are spreading out, and while we know not all will last, you never know which might fit your situation.
In this session, I'll give a summary of what's hot around the agile world, with some criticism and application in the real world. Almost two decades after the original manifesto, organizations start to experiment again. I always wished I was there when the first conversations took place. I encourage you to join in on current conversations. Let's start.
The Secrets of Effective Unit Testing
When we’re starting to look into unit testing, we get the simple examples that work in an ideal world. When we start working on actual code we bump into reality. While unit testing is no easy, it can be easier.
In this workshop, we’ll try our hands in different techniques of unit testing. We’ll discuss naming methods, practice refactoring and techniques of Test Driven Development that work in the real world.
This is mostly a hands-on session. As an attendee, get your favorite development environment and language (it doesn’t matter which). However, this workshop does not teach unit testing basics, and assumes at least basic experience in unit testing.
Although we think about unit testing as a “tool thing” it is really a set of skills that we can continue to develop over years. In this workshop will glimpse at how we can identify and improve those skills.
Rebooting ALM (Application lifecycle management)
Once the conference is over, you’ll be able to go back to the office and start making changes based on everything you’ve learned here.
Development processes are changing in front of our eyes, but apart from providing “templates” and “best practices”, ALM (Application lifecycle management) tool vendors are the true kings of methodology. They put the constraints on changes, and indeed on thinking of what is possible, and what “probably works in other companies”.
ALM requires a reboot.
In this session, we’re going to discuss how the product life cycle in the agile world, requires us to think differently on what the “management” part of ALM really is about. What we need to track and measure, and at what level. What kind of metrics we should put on experimentation and learning, feedback cycles and delays in the development system.
And how future processes and tools can actually support individuals and interactions.
Refactoring Without a Net
Refactoring is easy.
If you have tests, that is. Otherwise, it’s very risky.
Well, if you want to start testing your legacy code, you have to go on a limb, buddy. The only thing to understand is how to do this effectively, and minimize the risks.
This workshop is about hands-on refactoring. We’ll talk about patterns and when to use them, and actually use them.
What we can do when the code resists, what short cuts we can take, and what kind of risk we’re taking.
Oh, that code doesn’t have tests yet, but we’ll make it testable, and we’ll prove it.
Refactoring without a net is fun way to learn what to do (and not do) when you’ll get back to your code and modify it for the better.
The Empire Tests First (With BDD)
Obviously, we test after the code has been written. However, specifying requirements using tests, before the code is written has some advantages. Developers use Test Driven Development for better code, design and focus. There’s no reason why testers won’t use that as well.
Test-First is a great tool. It creates better understanding and productivity in the team. The result is high quality code - both in terms of early success in finding bugs and implementing features correctly. It just takes a little practice.
In this workshop, we’ll create our own Star Wars movie using Test First principles. We’ll start from requirements, identify pass/fail criteria, create the movie and refactor it. On the way, we’ll discuss what we’re doing, refine our specs, as well as see what changes in the design tell us.
No need to know how to code. Star Wars knowledge is preferable. The key thing is to understand better how the other side lives. Neither of us is on the Dark Side.
May the Force be with us!
Better Planning with (and without) #NoEstimates
You have probably heard of #NoEstimates by now. But what does it really stand for? And why does it raise so much opposition?
In this 1-day tutorial, we'll put things in order. Starting with why we want estimates in the first place and how we use them, we'll be moving towards different alternatives to cost estimation as a way to make better decisions.
We'll talk about value projection, and methods for quantifying value, like Cost of Delay, as a basis for improved planning. We'll talk about complexity and risk analysis. What information we need to start collecting for improved projection. We'll talk about agile planning, in a world full of uncertainty. We'll even talk about the next step mature organizations take - "Beyond Budgeting" - to run their business. And we won't forget to talk about the social aspects - how to "sell" these new methods, and how to tackle questions that usually come up, like: "Shouldn't we just get better at estimating?"
Estimates pros and cons
Cost of Delay
Evaluating complexity and risks
Metrics and KPIs
Planning in uncertainty
Driving the change in an organization