I hope that this 3-part series on how to move to continuous integration and how to evaluate if it’s worth moving to continuous integration on your program convinced you moving to continuous integration was worth it for programs. The reason continuous integration is an issue on programs, is because the lack of CI can delay […]
To continue our story from part 1 and part 2… The teams have determined their individual impediments to Continuous Integration. You, as the technical program manager, and the technical program team can take those impediments, with input from the teams can see the impediments to program-wide continuous integration. You have used a similar problem-solving approach,
Let’s set the context (which I did not do in my most recent post–sorry). Define a Program A program is composed of several feature teams, which may well be working on several projects or different feature sets. I assume they are. The goal of a program supersedes the goal of any of the projects, and
I like continuous integration. A lot. I started being an aficionado of continuous integration back in my senior year of university. It was my very first (and last) team project in my college career. There were three of us. The project manager waited until the night before the project was due to get us all
Contents: This month’s Feature Article: Discovering and Maintaining Your Project’s Heartbeat, Part 2 Announcements =-=-=-=-=- Feature Article: Discovering and Maintaining Your Project’s Heartbeat, Part 2 Last month, I discussed how you to generate and maintain a project’s heartbeat–a project’s rhythm. If you missed that issue, see https://www.jrothman.com/pragmaticmanager/heartbeatpart1.html. This month, you might want to consider some
Contents: This month’s Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 3 Announcements =-=-=-=-=- Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 3 In the previous two issues, I suggested some approaches for making a waterfall work for you. If you missed either of those issues, see Waterfall Part
Contents: This month’s Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 2 Announcements =-=-=-=-=- Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 2 Last month, I suggested some approaches for making a waterfall work for you. If you missed that issue, see <https://www.jrothman.com/pragmaticmanager/waterfallpart1.html>. Assuming you’re somewhere in the coding
Contents: This month’s Feature Article: Discovering and Maintaining Your Project’s Heartbeat, Part 1 Announcements =-=-=-=-=- Feature Article: Discovering and Maintaining Your Project’s Heartbeat Some projects zoom along, making progress regularly. Others feel as if they slog along, with barely any progress from week to week, or worse, month to month. Why? The zooming projects have
Normally, I’m huge fan of continuous integration. Continuous integration is when everyone integrates his or her code every day, preferably as each little tiny piece is built and tested (or in the case of test-driven development, tested and built). The developer checks his or her code in, does a local build, checks the build, and
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