Indusa's Agile methodology (Scrum Method)


Published on

Indusa's Agile Methodology using Scrum method..

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Indusa's Agile methodology (Scrum Method)

  1. 1. Agile Software Development Methodology<br />Indusa uses a number of techniques to deliver its Business Services. Our emphasis is on techniques that deliver rapid business value by taking a small, frequent, measurable actions; reviewing progress; then repeating until the planned goal is achieved. We follow the agile software development methodology to develop software applications. The model takes an iterative approach that encourages frequent inspection, self-organization and accountability that allow for rapid delivery of high-quality software and a business approach that aligns development with client needs and organization goals.<br />Indusa generally uses Scrum approach under agile methodology which concentrates on how the team members should function in order to produce the system flexibility in a constantly changing environment. Scrum process includes three phases: Pre-game, Development and Post-game.<br />The Pre-game Phase<br />It includes two sub phases – Planning and Architecture/High level design<br />Planning includes the definition of the system being developed. A Product Backlog list is created containing all the requirements that are currently known. The requirements can originate from the customer, sales and marketing division, customer support or software developers. The requirements are prioritized and the effort needed for their implementation is estimated. The Product Backlog list is constantly updated with new and more detailed items, as well as with more accurate estimations and new priority orders. Planning also includes the definition of the project team, tools and other resources, risk assessment and controlling issues, training needs and verification management approval. At every iteration, the updated Product Backlog is reviewed by the Scrum Team so as to gain their commitment for the next iteration.<br />In the architecture phase, the high level design of the system including the architecture is planned based on the current items in the Product Backlog. In case of an enhancement to an existing system, the changes needed for implementing the Backlog items are identified along with the problems they may cause. A design review meeting is held to go over the proposals for the implementation and decisions are made on the basis of this review. In addition, preliminary plans for the contents of releases are prepared.<br />The Development Phase<br />It is also called the Game Phase, is the agile part of the Scrum approach. This phase is treated as a “black box” where the unpredictable is expected. The different environmental and technical variables (such as timeframe, quality, requirements, resources, implementation technologies and tools, and even development methods) identified in Scrum, which may change during the process, are observed and controlled through various Scrum practices during the Sprints of the development phase. Rather than taking these matters into consideration only at the beginning of the software development project, Scrum aims at controlling them constantly in order to be able to flexibly adapt to the changes.<br />In the development phase the system is developed in Sprints. Sprints are iterative cycles where the functionality is developed or enhanced to produce new increments. Each Sprint includes the traditional phases of software development: requirements, analysis, design, evolution and delivery phases. The architecture and the design of the system evolve during the Sprint development. One Sprint is planned to last from one week to one month. There may be, for example, three to eight Sprints in one systems development process before the system is ready for distribution. Also there may be more than one team building the increment.<br />The Post-game Phase<br />This phase contains the closure of the release. This phase is entered when an agreement has been made that the environmental variables such as the requirements are completed. In this case, no more items and issues can be found nor can any new ones be invented. The system is now ready for the release and the preparation for this is done during the post-game phase, including the tasks such as the integration, system testing and documentation.<br />URL:<br />Contact:<br />