ALM Development Practices Part 1: An Introduction
As part of my many assignments, I’m compiling a bunch of Application Lifecycle Management practices into a set of development guidelines for bootstrapping our internal projects using Team Foundation Server. I’ve decided to share these with the community so that others may benefit from it as well. Beware that these practices are not new nor in any way invented by myself. I'm merely trying to get some good resources together in a nice compact format.
So what are my goals?
- To provide insight into the benefits of applying well known best practices on software development projects.
- To provide examples of applying those practices on new and ongoing projects and explain how to gain the most of out them.
- To help you jumpstart a new project or professionalize running projects.
And what do you gain?
The goal of these posts is to end up with a set of development practices that provide the following benefits:
- Allows you to more quickly and accurately assess the impact of new requirements.
- Promotes building well designed software that allows changing functionality with lesser risks (even during a running project).
- Promotes a consistent code-base that solves similar problems using similar solutions, everywhere.
- Strives for a functionally consistent software system. For instance, ensuring that date fields look the same all over the application).
- Attempts to prevent code duplication so that you never have to make changes at multiple locations if you change a particular piece of behavior or logic.
- Eases the effort for deploying a new release by removing as many human actions as possible.
- Provides traceability on where a particular piece of functionality has been realized technically.
- Improves the developer experience when working on an existing or shared code-base (e.g. readability, purpose and goal of a block of code).
- Provides a safety net that reduces and possible prevents the chance of running into regression problems.
- Attempts to prevent common mistakes or misinterpretations by introducing common rules and recommendations.
- Strives to a situation where each and every member of the team is aware of the project’s affairs.
- Promotes any endeavors that improve the self-education and self-organization of teams.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)