and

This is indeed the big picture and it represents Management's purpose behind the Product itself. If a sharp focus is not kept on a Product, it will not be consistent in look-and-feel, span of control, depth of complexity, or indeed almost anything else. Over time it will become more and more fragile (read that as un-maintainable and un-extensible) and more prone to defects at the production level. This defeats the purpose behind the Product.

Of course, if you do not concentrate on the day-to-day details, you will never get the Product to the point where you can release it at all. We call the implementation of these day-to-day details a Project. For the most part, there will be many Projects involved during a Product's life. Some of these Projects will focus on new or improved functionality, some will focus on internal architecture and some will focus on codebase cleanup, fix-up and re-architecting.

The focus of any Project is to implement the desired changes with a minimum cost, in a minimum amount of time and with a minimum number of resources. One of the things that often get overlooked is the long term costs of "not doing it right." This is especially true in today's Agile Development world where there is a tendency to "refine and replace" over time. To digress for a minute; Agile at its best is intended to use rapid prototyping to dynamically elicit both functional and UI requirements from end users. It then expands the agreed upon prototypes into a functional, deliverable Product. It pays the cost of rework in order to minimize missed expectations upon delivery. This is why I say that "refine and replace" occurs more and more in today's software development industry.

There need to be many points during a Product's development where "someone" steps back, takes a hard look at what is happening and make sure the UI is consistent and acceptable coding practices (styles, whatever) are used in the codebase construction and maintenance. The Product needs to be implemented so that it is inherently testable, of minimal internal complexity, modular in architecture, and so forth so that it will be both extensible and maintainable down the road.

Management takes, or should take, the responsibility for ensuring Product consistency, maintainability and extensibility. Quality Assurance (QA) takes, or should take, the responsibility for ensuring a Product is developed in such a way as to be inherently testable and of minimal internal complexity. Architecture takes, or should take, the responsibility for ensuring the framework, or scaffolding, of the Product follows acceptable design practices and meets the general case, not a series of special cases. Development takes, or should take, the responsibility for ensuring that best coding practices are followed, that all code is easily testable, that the codebase is modular and not pathologically connected, and that Unit Tests are provided for as much of the codebase as is practical.

So where does CM come into this mix? We have to set up an infrastructure for Version Control and Defect Tracking (at a minimum) prior to the start of a Product's first Project. The metrics and statistical controls that are needed at the Product level (to enable Project Status and Project-to-Project Trend Analysis) need to be defined and the data collection mechanisms put in place early on. Prior to the start of each Project, the metrics and statistical controls it requires need to be defined and the data collection mechanisms put in place. The data and metrics needed at the Project level should remain fairly consistent throughout all of the Projects (always allowing for process improvement), though the requirements for Project metrics will vary from Project to Project. This is one reason Product metrics are specified separately.

Other areas where CM plays a part are typically Build Management, Release Management and, to some extent, Requirements Management. CM-originated metrics are typically supplied to both Product and Project Management, Development and the various Quality teams. The biggest difference between CM's focus on Product and Project is the level of detail. Unlike other groups, CM must keep both viewpoints in mind at all time; otherwise we will not be able to provide the traceability and reproducibility required of us.

Summary
It turns out that, from a practical standpoint, two different "teams" are required to represent the Product and Project viewpoints. I put "teams" in quotes because some people are able to successfully wear both hats, especially in small teams. The idea is for "someone" to keep the Product in mind at all times and to ensure the various Projects are consistent with the Product's goals. Regardless of the viewpoint, however, CM must provide both the consistency and core technology to track and reproduce changes upon demand.

References
Easy Stereogram Builder, http://www.easystereogrambuilder.com/Default.aspx

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment