12 December, 2006 - 21:08 — GeoffGlasson
This page is dedicated to Software Process Improvement.
Articles
Title | Author(s) | Notes |
|---|---|---|
| A simple model of agile software processes -- or -- extreme programming annealed | Glenn Vanderburg | This article discusses interdependencies among the different practices and how they are grouped. It gives clues to how individual XP practices could be replaced with others. |
| Development Practices for Small Software Applications | Capers Jones | This article compares the use of Agile methods with CMM/CMMI on small projects. The author shows that there are some advantages to using Agile methods in small projects; but also shows that CMM/CMMI can be used to deliver effective results but at a (typically) greater cost. He recommends using CMM/CMMI for larger projects. He also shows that some organisations have had success integrating Agile methods into formal methods such as Six Sigma. |
| Heroes: Carrying a Double-Edged Sword | Paul Kimmerly | This article talks about the impact that "heroes" have on projects and an organisation. A "hero" in this context is the person(s) who know most about a particular system, and without whom the system cannot operate properly. A system in this case is a software system, but the principle applies to other areas too. Heroes often have knowledge learned through experience that is not written down, and is applied implicitly by the hero in their day to day work. People without this knowledge are not able to perform the tasks of the hero, increasing the dependence upon the hero. Having heroes is a risk to an organisation because they can become choke points to getting work done. Organisations that rely on heroes are often severely impacted when the hero is unable to work (for whatever reason). The article cites examples where heroes have actually caused significant problems for an organisation. The article then discusses options for reducing the dependence upon heroes by leveraging their knowledge to implement appropriate processes. Capturing the hero's implicit knowledge and teaching it to others, allows the heroes to focus on things that they are good at, and allows others to take over some of their responsibilities. |
| Optimizing Software Process Based On Risk Assessment and Control | XU Ru-Zhi, NIE Pei-Yao, SAI Ying, QU Le-Hong, LEE Yun-Ting, | This article presents a technique for utilising risk management to help improve software development. By analysing the risk of individual tasks, the project manager can make informed decisions how and where to spend money to reduce the risk of project failure. |
| Respect the processes you put into place | Ramon Padilla | This blog discusses the importance of respecting the processes that are put in place in order to prevent them becoming a millstone around the necks of the people who have to use them. Padilla talks about managers (in particular) who define specific processes but who then either ignore the process or make it impossible for people to use the process. An interesting read and food for thought. |
| Software Project and Process Measurement | Christof Ebert | This article discusses measuring project processes to improve performance on the current and future projects. The article suggests asking questions such as:
Asking questions along those lines will help focus investigations and identify where measurements can be made. This is an interesting article and well worth reading. |
| Software process improvement: it's a journey, not a destination | Bill C. Hardgrave, Deborah J. Armstrong | This case study is about a company that set an unrealistic deadline of achieving CMM level 2, and how they continued to try until they got there several years later. It discusses the lessons that the company learned, and it seems to me that the lessons are applicable to a number of organistations. |
| Two views on software process | Larry Lumsden, Wolfgang Strigel | These two articles present two points of view on whether the same software processes are appropriate for both small and large software organistions. I tend to agree in principle that they should be the same, however practice is an entirely different matter. The act of designing, writing, and testing code will be similar but due to size differences in the teams involved, the process will naturally be different between small and large organisations. I don't believe that this subject has a right or wrong answer - I think both points of view are at the same time right and wrong. I tend towards the nay case because having worked in small and large teams I can say from experience that the same process does not work for both types of teams. The failure is primarily driven by the size of the team and the number of people involved - all with different abilities and perceptions of software development. Regardless the two articles offer up food for thought - and that in itself is a good thing. |
Case Studies