By jaiprakash gogineni

! ! ! ! ! ! ! ! ! ! ! ! ! !

! !

WHY AGILE
! !
In my previous software development (Ex:waterfall model) what I have experienced is , when project middle when we want changing requirements, or evolving!requirements in traditional software development strategies changing requirements are problem & difficult.
In agile we consider changing requirements to be a good thing Changing requirements indicate us:

The plan-driven m

! !
! !

-driv

Wa!r fa" or #e plan-driven Me$od Real-world software projects change, not every requirement can be gathered up front, things get missed, and the business is always learning and guring out better ways to do things. We want the software to outlive the business ! not the ! business requirements;

oromethod

! !

! !

! !

! !

! ! !! ! !!

Agile focuses on small, featuredriven iterations that strive to solve change requirements in business problems. These iterations usually occupy a time box of a xed two to four weeks

duration.!

stakeholders are interested in what we are working on stakeholders are thinking about what we are producing There are feedback mechanisms(Ex :Retrospective meetings) in place that enable us stakeholders to change their requirements It is easy for stakeholders to change their requirements as their understanding of their needs evolve As a result of this focus organisations are capable of significantly reducing the overall risk. agile development delivers increased value, visibility, and adaptability much earlier in the project life cycle, significantly reducing project risk a project is a software system that much better addresses the business and customer needs.

! ! !! ! ! ! ! ! ! ! !! ! ! ! ! !! ! ! ! ! ! !! ! ! ! !! ! ! !
! !

! !

! !

! !

Agile Methodologies for Software Development!


Agile-Scrum
Scrum Artefacts Product Backlog User Stories Acceptance Criteria Sprint Backlog BurndownCharts KanBan board

Scrum is an iterative Approach such called as Sprints typically 2 - 4 weeks

Scrum Method (Value Driven)! Small time blocks called Sprints.! Small features! Small Teams.

Scrum Roles( Pigs) Scrum Master Product Owner Delivery Team

Scrum Activities Sprint Planing Planning Poker Daily StandUps Sprint Review Sprint retrospective

Auser user story story is is a a card card that that describes describes an an increment increment of of value value to to the the customer. customer. The The user user story story is is written written for for the the developer developer in in order order to to express express the the A increment of of value. value.!! increment The he product product backlog backlog is is nothing nothing more more that that a a prioritised prioritised list list of of user user stories stories!! T Acceptance criteria criteria is is essentially essentially a a clarication clarication of of the the story. story. It It gives gives the the developer developer a a set set of of steps steps that that must must be be completed completed before before the the story story can can Acceptance be considered considered done. done. The The acceptance acceptance criteria criteria are are created created by by the the product product owner owner with with the the help help of of the the customer. customer. It It sets sets the the expectation expectation of of the the user user be story.!! story. The ScrumMaster ScrumMaster is is responsible responsible for for ensuring ensuring that that the the Scrum Scrum process process is is understood understood and and followed. followed.A AScrumMaster ScrumMaster facilitates facilitates the the team team The meetings and and removes removes any any blockages blockages that that the the team team may may have have in in the the course course of of the the doing doing their their work. work. He He ensures ensures that that there there are are no no obstacles obstacles meetings keeping the the team team from from achieving achieving their their goals goals and and also also isolates isolates the the team team from from outside outside distractions, distractions, all all of of which which ensures ensures focus focus is is kept kept on on the the job job keeping at hand. hand.!! at Aproduct product (or (or project) project) owner owner represents represents the the customer customer and and is is responsible responsible for for maximising maximising the the value value of of the the work work that that the the team team produces. produces. The The A product owner owner meets meets with with the the customers customers to to determine determine their their wants wants and and needs, needs, and and prioritises prioritises those those items items so so that that the the team team is is always always working working on on product the items items of of highest highest customer customer value. value.A Aproduct product owner owner manages manages the the product product backlog backlog and and is is the the only only person person who who can can proritize proritize the the user user stories stories the for a a sprint. sprint.!! for Sprint Planning Before the start of each sprint, a planning meeting is held to determine which features will be included in the sprint. Features come from the product backlog, which is prioritised by the product owner.! We use to have Planning Poker game to asses the team members to give their honest assessment of the complexity of a user story in relation to other stories where ! ! ! ! ! ! 1 - means that the team member is very doubtful of the proposal! ! ! ! 5-means the team member is extremely condent in the proposal! !
PARTICIPANTS Product Owner Scrum master Developers QA- Members

!! ! !! !! !! ! ! !
!

Agile-eXtreme
Progrraming

Respect: ! Respect is a two-way street: it needs to be given to fellow teammates so that everyone feels respected as a valued team member; and it is also required from management so that the team owns and is responsible for what they have committed to. ! Communication: In order to develop quality software efciently, clear and frequent communication is required between the customer and team members. If possible, sit down with the customer and ush out ideas, point to things, make communication highly visible and interactive, and avoid "pie in the sky" types of conversations. ! Simplicity:! Feedback:! Courage: ! Keeping the code simple means doing what is required and nothing more, rather than over-complicating things that may never be needed! Feedback is an essential part of XP programming and it can come in various avours. Feedback is important when working with the code base to ensure that it is not broken when making a modication. This is achieved through TDD/BDD and a continuous integration process! Last, but certainly not least, courage is a must. The XP methodology empowers developers to self-organize and estimate their work, hus they are able to embrace new ideas and come up with the simplest design for the project they are working on, rather than (for instance) trying to reuse a design that is familiar from a previous project.!

! estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, iterations 1 - 3
weeks.!
eXtreme Progrraming Core K E values N Respect T Communication B Simplicity E Feedback C Courage
K

In XP , the Customer works very closely with the development team to define and prioritise in small units of functionality referred to as "User Stories". The development team

The twelve practices that make beutiful XP Planning Game System Image Simple Design On-Site Customer Team Sitting Together Pair Programming

The planning game captures the features of the system as user stories, and denes the releases of the project When communicating with the business, it helps to have a ubiquitous language so that complex systems can be explained easily. High-level system design occurs at the start and during an iteration. On-Site Customer: During an iteration, it is ideal for the customer to be on-site to aid in quickly answering details of a user story Its important for all of the team committed to the project to be within shouting distance of each other. This improves communication and understanding Pair programming is a development practice that pairs developers so that they can work on a problem together. A pair will share a development machine, and while one codes, the other will assist with design decisions and look ahead to the next feature ! The driver is the one sitting at the keyboard typing in code ! while the navigator is the one reviewing the code being written, thinking about how to code Through sitting together and pair programming, the entire team shares a collective ownership of the code base. All developers are allowed to x and work To help with collective ownership, best practices are used to keep a simple design and ensure all code is created in a consistent manner. This ensures that source code can be understood quickly when working on any part of the system and with any other developer. ! To ensure quality is delivered to the customer, emphasis is placed on testing through the XP process. Testing starts by identifying acceptance criteria from user stories. These acceptance criteria are used to write unit tests and start development in TDD/BDD style. User acceptance testing also derives from the acceptance criteria and will be automated as much as possible. ! To ensure that all of the code that the team is collectively developing actually works, the team integrates often and early. A continuous integration (CI) server will pull the code base from a source control repository, build it, and run all the automated tests to ensure the build is not broken. The publicly published output of the CI server can be notied instantly to developers, customers, and project managers. This report includes the number of tests that are pass/fail Because of the short release cycles and the iterative nature of XP, requirements gathering, design, development, testing, and deploying all happen often. This means that issues found after review and testing can be incorporated into the next iteration. This quick feedback model ensures that developers can work at a sustainable pace. Thus, they save long weeks compared to more traditional development methodologies that have clearly dened stages for the development life-cycle, leaving feedback and testing until the end ! XP is all about customer satisfaction and delivering business value through quality software. As far as the business is concerned, the more often this can happen, the better. XP promotes frequent releases, which may be relatively small, but highlights the features prioritised by the business. XP does not allow the development team to go into hiding for months on end, hoping that the project completes on time. This transparency of frequent releases encourages customers by showing them the team is adding value to the project all along the way.

! !

! ! ! ! ! !

Collective Code Ownership Coding Standards Testing( Key Success) Continuous Integration Sustainable Pace

Small Releases

Getting Into the Project using Scrum/eXtreme Progrraming Development

Generating The Product Backlog