This discussion is focused on managing, assuring, and testing. An important yet challenging aspect of quality is its measurement. This challenge emanates from the fact that quality is elusive (not easily definable) and subjective (depends on the context). Despite its elusiveness, attempts to measure and improve quality are important. The very effort of setting the metrics and measuring quality has a positive effect on a project. Closely accompanying quality and testing metrics are other project management metrics associated with time, costs, and resources. Measuring these project parameters is equally important in estimating efforts and improving quality. Metrics provide information to the management on controlling and directing a project. Comparison among projects, within the organization, and across a collaborative cluster is also enabled through metrics and measurements. Metrics and measurements are also required to measure the quality of service (QoS) during the operation of a system. Pure Agile approaches eschew the traditional project management measures of time, budget, and resources. Instead, the focus in Agile is on values and quality. The challenges in measuring and understanding the subjective parameters of an Agile project are similar to those in measuring quality in traditional, planned projects. The Agile measures can change depending on the context; they are subjective. CAMS encourages metrics for the traditional (planned) as well as Agile parameters within a project. Metrics for the planned aspects in a project can use corresponding process maps of CAMS. For example, the measures associated with the planning of a project and modeling of requirements can use the project management and the requirements modeling process maps. Some Agile metrics, such as project velocity, are quite close to the aforementioned project management metrics. Measuring of Agile values, such as simplicity and honesty, and Agile practices, such as pair programming, is difficult in practice. This section discusses the challenges associated with measurements, suggests some CAMS metrics, and outlines the way in which a metrics program can be implemented (typically through a CoE in an organization).
Metrics provide a language for communication within the organization. Metrics can be used in projects and also in measuring the performance of an organization in its business-as-usual state. Metrics enable measurement of current work, estimation of future work, and comparison among work. Each work area in an organization has its own terminologies. Metrics enforce the use of a common terminology to explain that which is being measured. This, in turn, helps in not only the recording and storage of data but also in analyzing it to gain insights. Consider, for example, the terms used by developers as they undertake testing in an Agile project. Technical terms such as defect in data load, bugs in referencing, or garbage in the memory may not have much relevance to a user on the project. Business stakeholders (e.g., executives and customers) have their own interpretations of these words. Furthermore, they also have their own business terminologies usually derived from the business domain. Further ambiguities exist in terms such as maintainability, usability, performance, reliability, and user-friendliness. Putting together a suite of metrics agreed upon at the start of an initiative, and with provision for changing and improving those measures, is crucial for the success of a project.
The composite Agile approach to metrics and measurements is a very organic approach. Initially, the metrics are agreed upon tentatively by all the stakeholders. With the start of the project, these metrics are measured. The resultant primitive data is immediately analyzed in order to gain insights—such as the progress of the project or the number of errors being detected. On the basis of this feedback, metrics are fine-tuned to measure new data.
Taken from : The Art of Agile Practice: A Composite Approach for Projects and Organizations
No comments:
Post a Comment