So we now have tested software, yippee! Which means nothing if we don’t get it to actual customers, so let’s talk about shipping to production. Like everything we discussed until now, automation lowers the risk of manual errors, and saves time. But even deploying to production has to have some kind of method to it.
I’ve started a new series on Everyday Unit Testing, this time it’s on the strategic plan of rolling out unit testing implementation as a process in an organization. The first post is about defining the goals right. Check it out.
Last time, we’ve looked at how “regular” development practices have made sure that things worked at the development team level. It’s time to move on. Because, as we know, it’s not working software unless it’s tested. Let me tell you a story, sonny. When I was young, we built the software on my machine. Compiling, testing
Had great fun in Athens this year, and I really want to come back. You can check the slides and video on the “Everyday Unit Testing” site. and if you want to see it live I’m doing it in the QualiTech meetup next week.
For the record: I still don’t like the technical debt metaphor – I feel that it encourages taking on the debt. We don’t know what will happen, so it makes sense to do things now, even badly, and forget the price we’ll need to pay. Metaphors aside, the price we pay is real. It cannot be quantified
The agile manifesto says we value working software. What is working software anyway? We can talk about software working in different contexts. First are the non-tangible parts (more working than software): Idea – The ideas for the product we’re going to build need to make sense and solve the our customer problem Design – We
This series is about DevOps and how it fits into the agile world. I’ve given this as a workshop at Lean Agile Scotland (slides). Let’s start with what DevOps is. I went to the source of all knowledge, Wikipedia, and the definition goes like this: “A culture, movement or practice that emphasizes the collaboration and communication of both software
When I first took on product management, I started learning techniques, like understanding the market, strategy, SWOT analysis. While I didn’t write “proper” user stories, I prioritized requirements, and was there for the team to describe scenarios, answer questions, update on news, test the application and give feedback. My time was split between doing “product management”
Great fun, and it requires 2 hours, not 1.5 hours. Here are the slides.
The videos are up on the Everyday Unit Testing site – “TDD Patterns” and “Creating a unit testing strategy“. Check’em out!