6 Agile Software Development Part 2
R. Baskaran
SOFTWARE ENGINEERING
AGILE SOFTWARE DEVELOPMENT
Agile software development is a software methodology which comprises of methods and practices based on the values and principles, where solutions are developed by the collaboration between self-organizing teams and cross functional teams by employing appropriate methods and practices for software development.
LEARNING OBJECTIVES
- To ensure the delivery of high quality systems.
- To provide strong management controls.
- To maximize productivity.
EXTREME PROGRAMMING
One of the well know agile methods is extreme programming (XP). It was developed in 1990s. Extreme programming revolve around 4 different practices which include pair programming, test driven development, refactoring and simple design. The next phase includes collective ownership, coding standard, sustainable pace, metaphor and continuous integration. On the upper hand, it includes whole team, game planning, small releases and customer tests.
The figure shows concentric circle, where each circle focuses on different aspects of software development.
Extreme Programming PracticeExtreme programming practices include the following:
- On site customer: Customer is actively involved with development process. Customer gives “User Stories” which are short and informal stories describing the features. The stories are conveyed through story boards.
- Planning game: In this phase, the developers and customers come together and plan the project. The developers give a cost estimate to “stories” and they provide budget, by employing an abstract accounting mechanism. They later compare the actual cost to improve the estimate over time. The customers prioritize stories to fit within budget.
- Metaphor: A metaphor describes how the whole project will fit together. It projects the integration aspect, on how the project will fit together like a jigsaw puzzle. It provides a framework for discussing project in a team. Tools and materials often provide good metaphors.
- Small Releases: For every sprint or a short interval we have to release a version of the product, so that the customer can review the product and progress of the development. The time between the releases are drastically reduced to a few weeks or months. Multiple iteration of the product development is done. The product and the process are improvised at the end of the iteration to produce an effective product. It also accommodates intermediate iteration between bigger releases.
- Testing: XP methodology incorporates test first programming. Here unit testing is done frequently by the developers and acceptance testing is done by the customers.
- Simple Design: Agile practices focus on simple design where the design should be quick and not elaborate. The developers pick the simplest thing that could possibly work and they resist from adding modules that are not ready.
- Refactoring: During refactoring, the code gets worse with addition of features and bugs even though it is reviewed by the peer programmer. Small sections of code are rewritten regularly. The unit tests which are designed comprehensively and the tests are run repetitively to known that nothing gets broken.
- Pair Programming: Pair programming comprises of two programmer who share a single workstation where one is called the driver and the other is called the navigator or observer. They switch roles among themselves recurrently. The driver is the programmer who codes and is focused on the semantics, syntax and coding practices while the observer focuses on reviewing the code for effective implementation, the time elapsed, the overall workflow and strategies for improvising the product effectively. Pair programming eliminates the need for code reviews and allows better quality in code, knowledge sharing, team building and increase in productivity.
- Collective ownership: The customer and the developer are actively involved in the development process. Hence anyone can edit anything. The entire team is responsible for errors and faults that are occurred in the development cycle.
- Continuous integration: In continuous integration, the commit changes frequently (several times a day). The changes are verified against the entire test suite to achieve the necessary standards.
- Coding standards: Coding standards are achieved through lot of team work and effort.
- Sustainable pace: The entire quantum of work should run through a sustainable pace and the quality of the work must not be comprised. No overtime should be taken to complete the Good estimation skills for budgeting will ensure reasonable time frames. Plan time each day for administrative works and incorporate appropriate breaks. Sustainable pace allows effective time and resource management.
SCRUM
The idea first appeared in a journal in 1986 (applied to product development management). It is used in software development and presented in 1995 paper. The term is based on rugby team. Scrum focuses on small cross functional teams and team work.
The scrum methodology comprises of a product backlog which is a repository that comprises of all the user stories which are organized and prioritized. The user stories for each sprint (interval) are managed within the sprint backlog at equal intervals of time of the sustainable pace. Daily meetings are held to discuss the effective development of the product. After several iterative cycles, a potentially shippable product is developed.
SEQUENTIAL VS OVERLAPPING DEVELOPMENT
It projects the difference between the traditional and agile software development process. In traditional development, it does requirement gathering, design, coding and testing sequentially. In scrum development process, the scrums do a little of everything all the time rather than doing all of one thing at a time.
SCRUM FRAMEWORK
The scrum framework comprises of roles, ceremonies and artifacts
The roles that are involved in a scrum framework include product owner, scrum master and
Product owner
The product owner defines the features of the product. The product decides on the release date and the content of the product. The product owner is responsible for the profitability of the product (ROI). To get the maximum return he prioritizes the features according to market value. The product owner adjusts the features and prioritizes them every iteration. The product owner accepts or rejects work results for the effective development of the product.
Scrum master
Scrum master represents management to the project. The scrum master is responsible for enacting scrum values and practices. The scrum master removes impediments and ensures that team is fully functional and productive. He enables close cooperation across all roles and functions and shields the team from external interferences
Team
Team typically consists of 5-9 people. A team is cross functional and is composed of programmers, testers, user experience designers etc. The members of the team should be full time and must actively participate in the effective development of the product.
The team members work towards converting all the tasks into sprint goal and sprint backlog as shown in the figure. Here sprint planning meeting considers the business conditions, product backlog, current product, technology and the team, then plans the sprint accordingly.
The sprint planning meeting encompasses sprint prioritization and sprint planning. Sprint prioritization involves analysis and evaluation of product backlog to select sprint goal. Sprint planning focus ways to achieve sprint goals and creates sprint backlog from product backlog items (user stories/features). The sprint backlog is estimated in term of hours.
The ceremonies encompasses of sprint planning, sprint review, sprint retrospective and daily scrum meeting. The sprint is a one month period, after the time period the product is developed. The features are assigned from the product backlog to a sprint backlog. The feature list is fixed for sprint and the features are further divided into smaller tasks for sprint backlog.
Sprint planning
In a sprint planning meeting, the tasks are assigned to team members and they have an individual estimate of time taken per item. During sprint, work through features and burn down chart is kept for every sprint. During sprint planning, the team selects items from the backlog and they commit to the completion of the item. A sprint backlog is created where the tasks are identified and the time to complete the task is estimated. The tasks are planned collaboratively and are not done alone by the scrum master. During planning, high level design is considered.
Scrum meeting
Scrum is a 15 minute meeting that is conducted every day. All the team members show up and quickly mention what they did since the last scrum. They discuss the obstacles that are encountered and they ways to overcome the short comings. Some team member volunteers and is appointed as the scrum master who is responsible for ensuring that issues raised by the customers and developers are addressed and the management is encouraged to observe the meeting.
Sprint review
At the end of every sprint, a new functionality is produced and review meeting is conducted to evaluate the sprint. The team presents what it has accomplished during the sprint and typically projects a demo of the new features or the underlying architecture. It conducts an informal meet where only 2 hours is given as preparation time and no slides are required. The whole team participates and invites everybody including the product owner. The review meeting evaluates the outcomes and identifies way to improvise the product by engaging the customer and the developers.
Sprint retrospective
Sprint retrospective periodically takes a look at what is working and what is not working. It happens for 30-40 minutes after every sprint. The whole team participates including the scrum master, product owner, the team members and the customers. They decide on what they should start doing or stop doing or continue doing for the effective development of the product.
Artifacts include product backlog, sprint backlog and burn down charts.
Product and release backlog
Product and release backlog comprises of a list of features to be implemented in the project which are subdivided and ordered by priority. These are adjusted over time as needed and based on feedback. The product manager is responsible for the maintaining the product and its release.
In the figure, the product backlog prioritizes the tasks. The high priority based tasks are taken into sprint backlog and the sprint goes on for 4 weeks where the tasks are completed. Daily meetings and sprint burn charts are maintained for every sprint for the development of the product. Once the product is developed it reviewed and the product goes on for release.
Sprint backlog is set of tasks that are yet to be completed by the team at the end of every sprint. The following figure shows tasks that are to be completed and the time estimated for every task.
Burn down charts
Burn down charts makes best estimate of time to complete what is currently in the backlog. The time is estimated and plotted on a chart. By studying the chart, we can comprehend the functionalities of the team and time schedule of the team. It ensures burn down to 0 at completion date by adjusting what is in the backlog and by adjusting the completion date. The figure shows a burn down chart where the x-axis shows the months and the y axis projects the number of hours.
Agile scrum process is a software development cycle which involves iterative and incremental development of the product. The figure shows the agile scrum software development process. The agile scrum process encompasses the following activities:
- Sharing your vision: The vision of the product is conceived in the initial The vision can be abstract or it can be detailed. The team works with the goal to transform ideas into tangible set of features or user stories.
- Product backlog: The product backlog is a repository where all the user stories are ordered and prioritized. Based on the levels of priority the user stories are prioritized as low, medium and high.
- Keeping track: User stories are prioritized within the product backlog and you can add or remove these at any time.
- Organization is the key: The project is organized into a series of sprints. User stories for each sprint are managed within the sprint backlog at equal intervals of time of the sustainable pace.
- Planning the sprint: The user and the developer work together to plan each sprint present in the sprint backlog. Higher priority user stories are typically addressed first as these deliver the biggest bang for the buck.
- It is all in the detail: We break down each user story into smaller, more manageable blocks of The entire modules are broken down to uncover every details of the product. Once the details are uncovered, the product is ready to be built.
- Ready to build: Software is designed to built, documented and tested within each sprint cycle. Daily standard meetings are conducted to communicate and discuss the progress and drawbacks that are encountered in the product development.
- Sprint cycle: Sprint cycle helps to keep the team focused by hosting stand-up meetings at regular intervals. In each iterative cycle, the product development is improvised effectively and the team works in delivering the product.
- Software in two weeks: Completed software from each sprint is shipped and ready for to be tested.
- Testing: The intermediate deliveries are tested for effective improvisation of the product development
- Not working for the stakeholders and customers: If the product is not satisfactory, changes are made and the product is improved effectively. The customers and stakeholders cannot decide whether the product is according to their specifications unless they try the product. The changes are made to satisfy the requirements by repeating the entire process from the product backlog prioritization.
- Final delivery: When the completed software from the sprint cycle is satisfactory to the customers and stakeholders, the product is ready for final delivery
- Rinse and repeat: The sprint cycles are continued until all the user stories are delivered to the customer and stakeholders’ satisfaction.
Quadrant 4 – Learn More/ Web Resources / Supporting Materials
Web Links |
http://www.tutorialspoint.com/software_engineering/software_engineering_overview.htm |
http://www.practicalprocess.com/seyp/definition.html |
http://www.softwareengineerinsider.com/articles/what-is-software- engineering.html#.V44IRtJ97Dc |
Supporting & Reference Materials |
Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001. |
PankajJalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997. |
Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000. |
Glossary
Starting char | Term | Definition | Re late d Te rm |
S | Software Engineering | It is the building of software systems which are so large or so complex that they are built by a team or teams of engineers | Software Development |
C | Change Control | Change control is a systematic approach to managing all changes made to a product or system | Versioning |
R | Reliability | It is the probability of failure-free software operation for a specified period of time in a specified environment. | QoS, Software Quality |
C | Cost Estimation | It is the approximation of the cost of a program, project, or operation. | Estimate |
Points to Ponder
S.No | Points to Ponder |
1. | Good notations can clarify the relationships and interactions of interest. |
2. | The existence of standard practices is one of the distinguishing characteristics of a professional discipline. |
3. | Team communication, product complexity, facilities and resources, etc are some of the quality and productivity factors. |
4. | Functionality, reliability usability, efficiency, maintainability are some of the characteristics of software quality. |