In spite of diligent planning, documentation, and proper process adherence in software development, occurrences of defects are inevitable. In today’s cutting edge competition, it is important to make conscious efforts to control and minimize these defects by using techniques to allow in-process quality monitoring and control. Defect Prediction using Rayleigh’s distribution curve is one such method that helps us to understand the density of the defects and their distribution across project phases as a project progresses.
Most teams that I have had the chance to work with seem to go through the Group Formation Stages of “forming, storming, norming, and performing” identified by psychologist Bruce Tuckman. As a Scrum Master, it is necessary to help teams navigate through these stages so that they can become highly performing teams.
In my last blog entry, I looked at www.wavemaker.com as a possible replacement for Access databases that were built outside of the IT infrastructure. In this post, I will go over some of the steps necessary for IT to take ownership of these little unsupported applications that have become mission critical and re-platform them into the IT infrastructure.
Developer Operations or “DevOps” is a term used to describe the gap between operations and the development team. In the consulting world, operations could be an internal infrastructure team, the corporate IT department at a client site, or even a third party vendor. The key is that it’s typically a person or team that’s focussed more on the hardware aspect of IT. The role of a DevOps practitioner or team, therefore, is to bridge that gap. They will take code that’s checked into a repository somewhere and get it built, deployed and running for development teams, QA teams, and clients to use.
This is the final part of a four-part series on using Team Foundation Server and Team Build to set up a continuous deployment environment.
This is the third part of a four-part series on using Team Foundation Server and Team Build to set up a continuous deployment environment.
This is the second part of a four-part series on using Team Foundation Server and Team Build to set up a continuous deployment environment.
On a web application project recently, I wanted to work myself out of the job of release coordinator. It’s a mundane, error prone and thankless task that needs to get done, a perfect job for a machine.