At the most recent Boston SPIN meeting, I caught up with a fellow I hadn’t seen in a couple of years. He thanked me for the advice I’d given him on a tough project the last time I’d seen him. I had no idea what he was saying, so I asked him what the […]
Summary: Staged integration versus continuous integration–which does your team prefer? Can’t decide if one is better than the other? In this week’s column, Johanna Rothman explains that you can create the perfect blend of the two. Developers and testers benefit from frequent builds, but be careful with how much you build. Build too much or too
Matisse has an interesting post, Software is like Building Construction. He talks about iterative design and the interdependencies of people with deliverables as being common to construction and software. In my opinion, he’s not all wrong, but he’s not all right. I agree that there are plenty of design-build firms who wait until the
I’m a big fan of continuous integration. For me, that means that as developers implement small pieces, they check in the changes, verify the changes with a local build and smoke test, promote the code to the mainline, check again, and they’re done. I’ve been having a long discussion with one of my clients about
This is way cool: Roy‘s interview with me, “Hiring Techies and Nerds” is O’Reilly’s Pick of the Week. The first part of the interview is about hiring issues. But the last 20 minutes or so is about management and project management. If you haven’t heard it already, enjoy!
Just because I’ve been quiet doesn’t mean I haven’t been working. I’ve posted two project management templates, the project charter template and the project plan template at my Templates page. The AYE blog is up and running. I have more work to do on the template, but I hope you check it out. (If
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but
When it comes to projects, there are as many questions to answer as there are project teams, but “Where are we?” is by far the most popular. The key to understanding a project is to make regular measurements—both quantitative and qualitative—and display the measurements publicly. When project managers display these measurements as part of the
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but
One of the scheduling tips I discuss in my project management workshops is “Plan to refactor.” I explain that if you’re using a lifecycle other than Agile, where the integration and testing is built into every iteration, you’re going to have to refactor at the end, when you do integrate and test. At one