Improving Software Processes Through Agile Methodology and Role Changes
Explore the integration of agile methods with CMMI, focusing on changing process roles in small organizations while maintaining agility. Learn about early agile methodologies, case studies, and the values of the Agile Manifesto emphasizing individuals, working software, and customer collaboration.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Software Process Improvement by Changing Roles in Small Size Organizations David Cyphert CS 2310 Seminar Fall 2017
Overview Agile methodology has become more popular in small size software organizations. History and description of some early agile methods Agile and CMMI: How can we integrate these two methods? Changing process roles without affecting their own agility in small organizations. A brief overview of case studies demonstrating the effectiveness of these process changes.
Agile Software Development Manifesto for Agile Software Development (2001) Earlier methods collectively referred to as agile methods: Rapid application development (1991) Unified process/dynamic systems development method (DSDM) (1994) Scrum (1995) Extreme programming (XP) (1996) Agile methods focus on the challenges of unpredictability of the real world
Values of the Agile Manifesto 1. Individuals and Interactions Over Processes and Tools It s the people who respond to business needs and drive the development process. Tools/processes drive development = the team is less responsive to change and less likely to meet customer needs. Example: Communication between individuals. Happens when needed vs. using processes. Time for meetings needs scheduled and specific meeting content is required.
Values of the Agile Manifesto (cont.) 2. Working Software Over Comprehensive Documentation Historically, enormous amounts of time were spent on documenting the product. Technical specifications, technical requirements, interface design documents, test plans Agile does not eliminate documentation Documenting requirements as user stories, which are sufficient for a software developer to begin the task of building a new function. Example: "As a <role>, I want <capability> so that <receive benefit>"
Values of the Agile Manifesto (cont.) 3. Customer Collaboration Over Contract Negotiation Negotiation is the period when the customer and the product manager work out the details of a delivery. Example: Waterfall model: Customers negotiate the requirements for the product, often in great detail, prior to any work starting. Not during the process. Agile: Customers who are engaged and collaborates throughout the development process, making it easier for development to meet their needs of the customer.
Values of the Agile Manifesto (cont.) 4. Responding to Change Over Following a Plan Traditional approach: Change seen as an expense, so it was avoided. Develop detailed, elaborate plans. Usually a large number of dependencies in delivering what was promised. Agile: the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration.
Characteristics of Agile Methods Defined in 12 principles: 1. Satisfy customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. 3. Deliver working software frequently. 4. Collaboration between business stakeholders and developers
Characteristics of Agile Methods (cont.) 5. Support, trust, and motivate the people involved 6. Frequent face-to-face team conversations. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development.
Characteristics of Agile Methods (cont.) 9. Attention to technical detail and design enhances agility 10. Simplicity - Develop just enough to get the job done for right now 11. Self-organizing teams encourage great architectures, requirements, and designs 12. Regular reflections on how to become more effective
Capability Maturity Model Integration Capability Maturity Model Integration (CMMI CMMI) CMMI is a process improvement approach, focused on organizational improvement. CMMI provides a way to assess the state of an organization s ability to build software in a repeatable, predictable way. To reach a certain level, an organization has to fulfil all process areas of that level as well as those of lower levels.
Integrating Agile in CMMI Agile is a iterative software development methodology, focused on the product quality. Many organizations demand CMMI compliance of projects where agile methods are employed. How can we effectively combine the best of both without losing agility? (Specifically, XP and SCRUM)
Coverage of CMMI The 22 process areas in CMMI can be divided into 4 main categories 1. Project Management Process Area 2. Support Process Area 3. Engineering Process Area 4. Process Management Process Area
Conflicting (-) Not Addressed (0) Partially Supported (+) Supported (++) Largely Supported (+++)
Process Manager To get closer to achieving this organizational structure, we can assign a role called a Process Manager Carries out process management activities professionally. Measuring and analyzing current processes and identify their advantage and weakness. Planning and implementing process improvement programs. Selecting outcomes for analysis, analyzing causes, and recording causal analysis data. Guiding decision-and-analysis
Scrum Development Team We can restructure the development team into a Scrum Team
Scrum Master The Scrum Master is responsible for: Ensuring impediments are addressed. Monitoring progress. Facilitating planning, reviews, and retrospectives. Encouraging continual improvement. Helping stakeholders and teams communicate. Helps product owner understand and create the product
Product Owner The Product Owner is responsible for: Managing the return of investment (ROI) for the product. Establishing a shared vision for the product among the developers and customers. Knowing what to build and in what order. Creating release plans and establishing delivery dates. Supporting sprint planning and reviews Representing the customers within the company.
Development Team Delivers a set of features from the product backlog every sprint Self-organizing and self-managing; they determine how much work they can commit to at the start of each sprint.
In other words The scrum team can't: Help the organization to manage organizational-level processes through measuring and reporting the status of project. Help the organization to verify objectively, practically how organizational level processes affect project teams. Offer evidences for validity and effectiveness of organizational-level processes.
How do we address this? Add the role of Process Management Supporter to the organization. Responsible for performing quantitative measurement that is needed to manage and improve organizational-level processes. Should an existing team member (Scrum master or architect) take on responsibilities of a Process Management Supporter?
Case Study Selected 4 small size software organizations and applied their program for process improvement. 28-43 developers 4-5 management personnel 5-10 agile projects Combination of informal software development methods and ISO 9001
Case Study (cont.) Suggested that these organizations to adopt their proposal Observed over a period of 2 years A Process Manager and Process Management Supporters were appointed in each organization The Process Manager analyzed current processes of their own organization and did categorize them into the ones newly established and the ones complemented with our guides
Conclusions Presented an efficient organizational structure and roles for reaching higher level of CMMI in small size software organizations consisting of Scrum teams. Roles of Process Manager and Process Management Supporters responsible for implementing the organizational-level processes were specified. The case studies show that small software organizations can reach CMMI level 3 without hiring new process improvement specialists and damaging their agility.
References RYANG, G., & MUN, I. (2017). Software Process Improvement by Changing Roles in Small Size Organizations. International Journal of Software Engineering,10(2), 3-20. Retrieved October 10, 2017, from: http://ijse.org.eg/papers/software-process-improvement-by-changing-roles-in- small-size-organizations/ Hneif, M., & Ow, S. (2009). REVIEW OF AGILE METHODOLOGIES IN SOFTWARE DEVELOPMENT. International Journal of Research and Reviews in Applied Sciences,1(1). Retrieved October 10, 2017, from: http://www.arpapress.com/Volumes/Vol1/IJRRAS_1_01.pdf
