Lecture Software process improvement: Lesson 31 provide students with knowledge about: agile software process; adaptive software development; extreme programming; feature-driven development; SCRUM; agile modeling; crystal; the agile manifesto;... Please refer to the detailed content of the lecture!
Agile Software Process Lecture # 31 1 Agile Software Process • Agile software engineering combines a philosophy and a set of development guidelines • The philosophy encourages customer satisfaction and early incremental delivery of software, small; highly motivated project teams; informal methods; minimal software engineering work products, and overall development simplicity 2 Agile Software Process • The development guidelines stress delivery over analysis and design (although these activities are not discouraged), and active and continuous communication between developers and customers 3 Agile Software Process • There are a number of agile process models – – – – – – Adaptive Software Development Extreme Programming FeatureDriven Development SCRUM Agile Modeling Crystal 4 Agile Software Process • Two key features of these development methods are – They accept that change will occur – changes in requirements and changes in technology; they therefore adopt a more ‘adaptive’ or iterative approach to planning – In suggesting how projects should be organized, they make a point of trying to work with human nature rather than ignoring it 5 Agile Software Process • One consequence of both of these is that they tend to create less documentation than conventional methods – it is not that they don’t value documentation – just that they actively avoid creating it for its own sake • Proponents of agile methods have published a ‘Manifesto for Agile Software Development’ 6 Following slide to be inserted The Agile Manifesto 7 The Agile Manifesto We are uncovering better ways of developing software by doing it and helping other do it Through this work we have come to value; individuals and interactions over process and tools working software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plan That is, while there is value in items on the right, we value the items on the left more The Agile Manifesto • Note that they do state that there is value in the items on the right • The Agile Manifesto is based on the following twelve principles: 9 Agile Principles 10 10 A Model of an Agile SPI Method Improving process as enacted SPI Coordination Provide infrastructure Synchronize SPI actions Analyze benefits of process innovations Improving individual competence Providing time to reflect on practice Encourage boundary scanning Justintime training Improving team competence Sharing knowledge/lessons from practice Facilitate informal discussion 41 41 • Improvement in process management is ‘a continuous effort to design an efficacious process by understanding the relationship between process configurations and process outcomes and embedding the knowledge in the process through routines and formal process definitions’ 42 42 Factors in Ensuring a Successful SPI Program – 1 • Changes must be aligned with business strategy and priorities should be based on the business context • Commitment to improve and investment required • Must come from top • SPI requires the consensus of all stakeholders and they need to have 43 ownership of the change 43 Factors in Ensuring a Successful SPI Program – 2 • Current processes must be understood • Change must be continuous • Improvement infrastructure is required to identify and manage the implementation of changes • The results of the SPI should be monitored 44 44 • Explicitly moving away from a software process philosophy of stability to one that is adaptive and flexible to local concerns will encourage a change in the actor’s intentions, as the norms of the organization will change from remaining consistent to finding the most appropriate means of undertaking a task 45 45 • This is not to suggest that methodologies or process lifecycles should be abandoned, rather the aim should be to produce a successful product rather than following a predefined methodology at all costs • The objective is not change for its own sake, as there is a need to balance between optimizing the current approaches and experimenting with new ideas 46 46 • The primary means for adjusting the process to suit the product development needs will be through learning from practice as individuals identify adjustments in the life cycle • To achieve this ongoing learning from practice we need to do more than just recognize that it is happens gradually, we need to encourage innovation in the process 47 47 • Encouragement to innovate, whether by bringing in new ideas from the software profession or developing approaches individually, requires a suitable mixture of experimentation, training, boundary scanning, and time to reflect on the current experience 48 48 • To support the learning and innovation activity, the SPI initiative can be supported through a suitable infrastructure • The SEI view of setting up process action teams under the software engineering process group (SEPG) is a model that can be adapted to suit this more emergent view of software process improvement 49 49 • Rather than the SEPG being the sole identifiers of process areas that need to be introduced, they could act as a facilitating group. By supporting through training, encouragement, resources, and progress management the SEPG can enable the introduction of significant changes to the defined process 50 50 • SEPG can also act as a research and development group, facilitating boundary scanning, thus helping an organization to be more aware of and ready to take on external innovations • It could also act as the control group for process actions, synchronizing SPI actions over time. New initiatives can be incorporated into the improvement action plan 51 51 • One way to improve the relevance of the SPI activity is to align it with the emergent business strategy • Both planned and improvised improvements could be coordinated to focus upon the areas that are expected to be important to the business to engender a sense of purpose over the longer term 52 52 • A final point: whilst good processes are fundamental to success in the software business, good people will bring their own processes with them, and can therefore produce good work in an ‘immature’ organization • Good processes without good people will achieve very little 53 53 Summary 54 54 References • “Agile process improvement?” by Keith Southwell, in TickIT 3Q02, pp. 314 • “Towards an Agile Approach to Software Process Improvement: Addressing the Changing Needs of Software Products” by Ian Allison, Communications of the IIMA, 2005 Volume 5 Issue 1, pp. 6776 55 55 ... Agile? ?Software? ?Process • There are a number of agile? ?process? ?models – – – – – – Adaptive? ?Software? ?Development Extreme Programming FeatureDriven Development SCRUM Agile Modeling Crystal 4 Agile? ?Software? ?Process. .. The SEI view of setting up? ?process? ?action teams under the? ?software? ?engineering process? ?group (SEPG) is a model that can be adapted to suit this more emergent view of? ?software? ?process? ?improvement... 18 demands • Software? ?process? ?improvement has been practiced for over two decades, but picked up after the introduction of CMMSW and later many model based methods for software? ?process? ?improvement were