An improvised prespective to agile methodology

6 downloads 0 Views 267KB Size Report
Abstract—In last few years, anecdotal evidence of mostly positive experiences with the implementation of agile development has emerged from various case ...
2013 IEEE 3rd International Conference on System Engineering and Technology, 19 - 20 Aug. 2013, Shah Alam, Malaysia

An Improvised Prespective To Agile Methodology Rakshith H P

Annapurna P Patil

Dept. of Computer Science and Engineering M S Ramaiah Institute of Technology Bangalore, India [email protected]

Dept. of computer Science and Engineering M S Ramaiah Institute of Technology Bangalore, India [email protected] approach. In Section 4, the paper talks about the new techniques and next section will compare it with present techniques. The last section summarizes the new proposed idea.

Abstract—In last few years, anecdotal evidence of mostly positive experiences with the implementation of agile development has emerged from various case studies. This enables data gathering from a larger sample of organizations, to learn about the factors driving the adoption and use of agile practices, and their benefits and challenges as perceived by early adopters of this software development methodology. From the studies it’s discovered that present agile methodologies have some unsuitable practices. These practices can be revisited and thus a new model for agile methodology is proposed in this paper, which increases the productivity

II.

In comparison to traditional software processes, agile development is less document-centric and more code-oriented. This, however, is not the key point but rather a symptom of two deeper differences between both [3]: • Agile methods are adaptive rather than predictive. With traditional methods, most of the software process is planned in detail for a large time frame. This works well if not much is changing (i.e. low requirements churn) and the application domain and software technologies are well understood by the development team. Agile methods were developed to adapt and thrive on frequent changes. • Agile methods are people-oriented rather than process oriented. They rely on people’s expertise, competency and direct collaboration rather than on rigorous, document centric processes to produce high-quality software. In this section, the most common agile methods are briefly discussed.

Keywords-Snoopers, agile, analyzers

I.

INTRODUCTION

The Agile Manifesto [1] stresses the importance of a) people and interactions over processes and tools, b) working software instead of detailed documentation, c) active customer participation and involvement rather than time and effort expended on negotiating contracts, and d) willingness and ability to take on changes over steadfast commitment to a static plan. Agile software development methods including eXtreme Programming (XP), Scrum, Adaptive Software Development and Feature-Driven Development are based on the principles of the Agile Manifesto and geared towards realizing its goals and objectives. In general, the feedback from organizations that have implemented agile development is positive. Some of the benefits attributed to agile development are increased productivity, expanded test coverage, improved quality/fewer defects, reduced time and costs, understandable, maintainable and extensible code, improved morale, better collaboration, and higher customer satisfaction. The adoption of agile development has also revealed some challenges such as slow participant buy-in, opposition to pair-programming, lack of detailed cost evaluation, scope creep, reduced focus on code base’s technical infrastructure and maintainability, difficulty evaluating and rewarding individual performance, and the need for significant on-site customer involvement, management support, competent managers and developers, and extensive training.

a.

Extreme Programming (XP) IT is based on values of simplicity, communication, feedback, and courage [4] [8]. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are. XP combines old, tried and tested techniques in such a way that they reinforce each other. Customers can review and test the functionality and design of the delivered program and discuss issues they want to be changed or added in the next release. b.

Agile Modelling (AM) The basic idea of AM [5] is to give developers a guideline of how to build models that resolve design problems but not ’over-build’ these models. Like XP, AM a point out that changes are normal in software development, AM does not explicitly refer to any Requirement Engineering (RE) techniques but some of the practices support several RE

The aim of this article is to find out these new techniques can be used within agile development and if this could result in improvements to agile approaches. The next section briefly gives an overview on current agile approaches. Section 3 discusses about the existing problems with the present agile

978-1-4799-1030-4/13/$31.00 ©2013 IEEE

PRESENT AGILE METHODOLOGY

381

2013 IEEE 3rd International Conference on System Engineering and Technology, 19 - 20 Aug. 2013, Shah Alam, Malaysia

Since, the pace of the planning meeting gets faster due to the time constraints, the knowledge transfer from the product owner/product engineer about the new stories/modules to the developers will be less. On the same day of meeting, the developers have to break down these stories into tasks and estimate these tasks using various methods like Poker method. Due to the less understanding of the requirement, developers end up estimating the tasks wrongly in turn resulting in missing the deadlines. For example: A company X is following present agile method, Its PO has N stories to for the sprint, and on the meeting day he was able to define the requirements of n-2 stories and he rushed through last 2 stories. Now the developers who has taken those two stories will not be very sure of the low level dependencies, still they will break them down into 3 tasks each and estimate it as 3, 3 and 4 hours respectively. Ideally they would have taken 6, 2 and 2 hours respectively.

techniques (e.g. tests and brainstorming). AM highlights the difference between informal models whose sole purpose is to support face-to-face communication and models that are preserved and maintained as part of the system documentation. c. Scrum SCRUM [8] is a method for managing the system development process by applying ideas on flexibility, adaptability and productivity from industrial process control theory. Scrum focuses on how a team should work together to produce quality work in a changing environment [6, 7]. The main Scrum techniques are the product backlog, sprints and daily scrums. It contains a prioritized list of all features, functions, enhancements, and bugs. For each sprint the highest priority tasks from the product backlog are moved to the sprint backlog. At the end of a Sprint a sprint review meeting is held that demonstrates the new functionality to the customer and solicits feedback.

Once the sprinters/developers enter the coding phase of the new modules, life becomes more difficult. Sprinters at this phase encounter various challenges like low level dependencies or needs crystal clear clarifications from their technical guide. In case if the technical guide is aware of it, he will be able resolve it else it will be pushed to product owner and higher chairs for the detailed clarification. This process can be faster in midsized industries or if the fewer teams are involved. But with the bigger sized industries or projects involving many teams with or without various geographical locations, this process is really a time consuming one blocking the sprinter. This blockage can just be for a sprinter or can be for the entire team. These blockages results in failure of the sprint and hence increasing the backlogs of the team.

d. Working Principles of Agile Development In the Agile development, every product is developed and released to the customer step by step. Each release will have a demo either to internal team which acts as a virtual customer or to an external customer or to partner teams. Each release consists of 3 to 4 sprints of duration 3 to 4 weeks and productive working hours will usually be 5 to 6 hours per day. The planning meeting for that particular sprint happens on the first two days of the sprint and 60% of the planning has to be completed by day one. The main mottos of these meetings are: • The product owner/product engineer will introduce the developers to the stories/modules which they are supposed to develop. • The developers with the help of their technical guides and their understandings have to break down these stories/modules into smaller chunks called tasks, estimate the time required by them to complete these tasks and upload them in their tracking tools or boards. At the end of these meetings, the development team will be aware of the modules that will be developed and rest of the sprint days are dedicated for code design, development, testing, validation and demo III.

In addition to above problems, since the sprinter has to undergo investigation phase every sprint, as to design the code, the time available for the sprinter after meetings, investigations to develop in that will be minimal. At this point on time he will be loaded with loads or pressure of meeting the commitments in the defined deadlines. In this minimal amount of time he has to develop, test it and validate it. So in order to meet his commitment, he may compromise with the quality of testing. He might write seven test cases in place of ten or consider three use cases to test in place of five. Indirectly the quality of the product is compromised. Along with quality of the product, the quality of the testing is also compromised. As a result of this 70:20:9:1 defect ratio is imbalanced. This imbalance can cause a huge penalty to the company. The 70 percent of the defects found in the developer site demands less time and money to fix than 20 percent defects found in the testing, so with the 9 percent defects found in system testing site. The defects found in the partner site or customer site will demand more man power and will be very costly for a company to fix. So if this ratio is imbalance and the number of defects increase towards the right, the cost of fixing them increases drastically hindering the development and profit of the company.

PROBLEMS IN PRESENT METHODS

The present agile methodology has loads of flaws but still its one the best model which most of the multi-national companies are following. The first phase of this method is planning meeting. Planning meetings are supposed to last for two days which should cover complete planning or requirement of that particular sprint. But the problem is these meeting may not be effective as they have the time constraints. Most of the times the 60% mark is missed and hence the second day proceedings will be spilled over. In order to avoid this, the product owner/product engineer will have to rush through the proceeding leaving the developers ambiguous about their further work.

382

2013 IEEE 3rd International Conference on System Engineering and Technology, 19 - 20 Aug. 2013, Shah Alam, Malaysia

IV.

V.

PROPOSED TECHNIQUES

Agile method

Planning meetings will be more effective now when compared to old model. This is because; except the Sprinters team all the other teams will be clearly aware of the stories which will be taken in that sprint, as other teams are working ahead of that sprint. Sprinters will now have to understand only about what module they have to work on. Since the estimates would have already done by “Analyzers”, Sprinters will just have to validate them and have to re-estimate if necessary after understanding the requirements. This will save the time for developers during the planning meetings, required to do all other work except understanding the modules, even product owners can spend healthy time with Sprinters, hence, Sprinters will obtain clear knowledge about the module developed and ambiguity is resolved .

The proposed method consists of FOUR sub teams to name: Product Owners, Snoopers, Analysts and Sprinters/developers. These teams form the main components of the sprint and they work parallel but with different iteration numbers. All these teams work for different sprints simultaneously and the output of each will be the input for other teams starting from Product owners to sprinters. NOTE: All through this section 4, we have considered the ongoing sprint as “X”. a.

Product Owners The product owners occupies the high level chair in the sprint team hierarchy and acts as the virtual customer who is sole responsible for the accepting or rejecting the modules developed by the team.

This method helps in resolving the module dependencies. As every story is analyzed two sprints ahead of the actual implementation sprint by snoopers, they will take care of the module dependencies. For any clarifications needed they can go to their technical architect or product owners or even the partner teams located in various geographical locations, but the difference is no team will be blocked on this time consuming process, as all the other teams are working at different levels. So the velocity and productivity of the other teams will not slowed down, because, by the time they get these stories these dependencies will be removed.

The Product owners will be working X+2 sprints. This will provide the more bits of time for them to get the right understanding of the requirements and it will help them to frame the story definition with more clarity. The other team to work parallel to them are snoopers. b.

Snoopers This team will have three to four people and runs in X+2 sprint in parallel to product owners’ team. This team usually consists of technical leads/technical architects or senior most engineers who has complete knowledge of the product and of the technology.

The analyzers will consume snoopers’ output from X+2 sprint and will further break down the stories to tasks in X+1, and will do detailed analysis/investigation on those. This is the most important phase, where even the minor coding dependencies will be caught and more clarity on those dependencies will be obtained from their technical leads. This removes the huge blockers for the developers while implementing the stories, and they can completely concentrate on the product they are developing. And hence deadlines are met easily.

The main functionality of this team is to pick up the stories from sprint (X+2) in which snoopers and product owners are working and analyze these stories, do the first level of investigation and validate them by proof of concept (POC). c.

ADVANTAGES OF NEW SYSTEM

Analysers

Quality, being one of the major aspects, is taken care in this system. The probability of developers encountering a dependency or blocker will be very less as they are taken care by analyzers or snoopers. So sprinters will have enough time to invest in healthy development and testing. This model will enable every sprinter to test his code extensively and test all possible use cases. This phase will help him to trap most of the defects during development itself and hence ~70 percent of defects will now fall into development phase bucket. This will trigger the testing teams to start extensive testing as the most of defects are fixed in development phase itself. This extensive testing will get all possible test cases into testing, validating the entire product for its best and worst cases accounting for ~20 percent defects, followed by 9 and 1 percent in their phases respectively. Hence the equation 70:20:9:1 is balanced.

This is a sub team of a project team which consists of three to four developers. The Analyzers will work in X+1 sprint. They will pick up the stories from X+2 sprint, where the Snoopers have analyzed them. The main functionality of this team is to carry on the detailed investigation of the stories which they have picked up as a part of sprint. Based on their investigation, they will break down the stories into tasks and will estimate them. They will also work towards removing the coding dependencies and provide more clarity to the developers. d. Developers/ Sprinters This team works in X sprint and consists of people who are involved in actual coding or implementation of the module. They might re-estimate the estimates done by Analyzers or might follow the same.

The other major advantage is addressing the immediate requirement from the client. This new method demands “product owners” to conduct a regular meetings with the

383

2013 IEEE 3rd International Conference on System Engineering and Technology, 19 - 20 Aug. 2013, Shah Alam, Malaysia

customer/client in order to keep them posted with what requirement will be served in the coming sprint. The product owner will discuss with his customer/client in X+1 sprint about the deliveries of X sprint and thus will re-prioritize the present stories if the client insists to do so. In this way the client will also be aware of what he will be delivered in the coming days, and if any module is required in particular he can convey it to the PO, so that he can plan it a sprint ahead, avoiding the last minute changes in the sprint requirements. This prioritized requirement will be taken up by analyzers in X+1 sprint and then will be served by sprinters in X sprint. So this will be like any other story to sprinters with most of the dependencies resolved and hence these requirements will be served comfortably.

method brings a very well balanced professional and personal life, in turn adding life to the people’s lives. REFERENCES [1]

Agile Manifesto, “Manifesto for Agile Software Development,” http://agilemanifesto.org/, December 2007 [2] Frauke Paetsch, Dr. Armin Eberlein, Dr. Frank Maurer: Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’03) 1080-1383/03 © 2003 IEEE. [3] Martin Fowler: The new methodology, http://www.martinfowler.com/articles/newMethodology.html.K. Elissa, “Title of paper if known,” unpublished. [4] Kent BeckExtreme Programming explained, Addison-Wesley, 1999 [5] Scott W. Ambler: Agile Modeling, John Wiley & Sons, 2001 [6] Pekka Abrahamsson, Outi Salo, Jussi Rankainen & Juhani Warsta: Agile software development methods - Review and analysis, VTT Electronics, 2002. [7] Ken Schwaber, Mike Beedle: Agile Software Development with Scrum Prentice Hall, 2001.Kent BeckExtreme Programming explained, Addison-Wesley, 1999 [8] Sheetal Sharma, Darothi Sarkar, Divya Gupta Agile Processes and Methodologies: A Conceptual Study, International Journal on Computer Science and Engineering (IJCSE), ISSN: 0975-3397, Vol. 4 No. 05 May 2012Pekka Abrahamsson, Outi Salo, Jussi Rankainen & Juhani Warsta: Agile software development methods - Review and analysis, VTT Electronics, 2002. [9] Mike McCormick, MPCS, Inc. Revised Edition 8/9/2012 [10] Sabah Nouri Mohammed Hussain Department of Computer Science and Engineering, Göteborg, Sweden May 2012

With all the above advantages, along with quantity, the quality of the product is increased. VI.

CONCLUSION

“Agile methodologies”, Multi-National Companies’ one of the most favorite, has few open issues, which are directly or indirectly hurting the efficiency of the agile methodology. These open issues are addressed above in the new method which not only just increase the efficiency, but also the sprint velocity, product quality and companies productivity as one team works serving the other team and removing their blockers, giving birth to actual “Team Work”. This new

384