Agile Model for Beginner’s Mohammad Nasir Uddin Developer Page 1 12/15/2016
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Agile Model for Beginner’s
Mohammad Nasir UddinDeveloper
Page 1 12/15/2016
What is Agile?
Page 2 12/15/2016
About Agile Agile is a Software Development Methodology It means ‘ability to move quickly and easily’ and responding swiftly to change It’s a time boxed, iterative approach Develop and deliver software incrementally from the start of the project, instead of
trying to deliver it all at once near the end.
Page 3 12/15/2016
About Agile (Cont.)
Iterations are typically 1 to 4 weeks so that the development is aligned with the changing business needs
It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations.
Page 4 12/15/2016
Agile Development Cycle
Page 5 12/15/2016
Agile Life Cycle
Page 6 12/15/2016
How does it work?
Page 7 12/15/2016
Make a list Sitting down with the customers make a list of features they would like to see in their
software. We call these things user stories and they become the To Do list for project.
Page 8 12/15/2016
User Stories
Page 9 12/15/2016
Size things up Size user stories using Agile estimation techniques Coming up with a guess as to how long each user story will take.
Page 10 12/15/2016
Time Estimations Don’t estimate things absolutely, as we are
not good at that. Try to estimate things relatively as we are
good at that
Page 11 12/15/2016
Time Estimations (Cont.)
Relatively sizing means – don’t worry about exactly how big a story is. Worry more how this story’s size compares to others.
Page 12 12/15/2016
Set some priorities
Like any other lists, there always seems to be more to do than time allows.
Ask the customer to prioritize their list Get the most important stuff done first, and save
the least important for last.
Page 13 12/15/2016
Start executing Start delivering some value. Start at the top. Work your way to the bottom. Building, iterating, and getting feedback from your customer as you go.
Page 14 12/15/2016
Update the plan as you go
Then, as you and your customer starting delivering, one of two things is going to happen. You'll discover: You're going fast enough. All is good. Or, You have too much to do and not enough time. At this point you have two choices. You can either a)
do less and cut scope (recommended). Or you can b) push out the date and ask for more money.
Page 15 12/15/2016
How is Agile different?
Page 16 12/15/2016
Continuous Activities Analysis, design, coding, and testing are
continuous activities You are never done analysis, design, coding
and testing on an Agile project. So long as there are features to build, and the
means to deliver them, these activities continue for the duration of the project.
Page 17 12/15/2016
Development is iterative Iterative development means starting with something really simple, and
adding to it incrementally over time. It means evolving the architecture, accepting that your requirements are going
to change, and continuously refining and tweaking your product as you go.
Page 18 12/15/2016
Planning is adaptive When reality disagrees with their plans, Agilists find it easier to change their
plans than reality. It is called adaptive planning. And while there are many ways to changes plans, the preferred way is to flex
on scope.
Page 19 12/15/2016
Scope can vary Agile deals with the age old problem of having too much to do and not enough
time by doing less. By fixing time, budget, and quality, and being flexing around scope, Agile
team's maintain the integrity of their plans, work within their means, and avoid the burn out, drama, and dysfunction traditionally associated with our industry.
Page 20 12/15/2016
Requirements can change Traditionally change has been avoided on software projects because of it's high
perceived cost late in the game. Agile challenges this notion and believes the cost of change can be relatively flat.
Through a combination of modern software engineering practices, and open and honest planning, Agilists accept and embrace change even late in delivery process.
Page 21 12/15/2016
Measure of success Working software is the primary measure of success In Agile productivity is measured in rate at which teams can turn their client’s
wishes into working software. Project plans, test plans, and analysis artifacts are all well and good but Agilists
understand they in themselves are of no value to the end customer.
Page 22 12/15/2016
Agile Manifesto
The Agile Manifesto, also called the Manifesto for Agile Software Development It is a formal announcement of four key values and 12 principles to guide
an iterative and people-centric approach to software development.
Page 23 12/15/2016
Agile Core Values The agile software development emphasizes on four core values.
1) Individual and team interactions over processes and tools2) Working software over comprehensive documentation3) Customer collaboration over contract negotiation4) Responding to change over following a plan
Page 24 12/15/2016
Twelve Principles1. Customer satisfaction through early and continuous software delivery –
Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
2. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
Page 25 12/15/2016
Twelve Principles (Cont.)
4. Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development teams are co-located.
Page 26 12/15/2016
Twelve Principles (Cont.)
7. Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
9. Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
10.Simplicity – Develop just enough to get the job done for right now.
Page 27 12/15/2016
Twelve Principles (Cont.)
11.Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
12.Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.
Page 28 12/15/2016
Agile vs Waterfall
Page 29 12/15/2016
Fundamental AssumptionsTraditional: Systems are fully specifiable, predictable, and can be built through thorough and extensive planning.Agile: High-quality, adaptive software can be developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change.
ControlTraditional: Process-centricAgile: People-centric
Management StyleTraditional: Command-and-controlAgile: Leadership-and-collaboration
Role AssignmentTraditional: Individual—favors specializationAgile: Self-organizing teams—encourages role interchangeability
Agile vs. Waterfall
Page 30 12/15/2016
Agile vs. Waterfall (Cont.)
CommunicationTraditional: FormalAgile: Informal
Customer’s RoleTraditional: ImportantAgile: Critical
Project CycleTraditional: Guided by tasks or activitiesAgile: Guided by product features
Development ModelTraditional: Life cycle model (Waterfall, Spiral, or some variation)Agile: The evolutionary-delivery model
TechnologyTraditional: No restrictionAgile: Favors object-oriented technology
Page 31 12/15/2016
Agile Methods
Page 32 12/15/2016
Questions?
Page 33 12/15/2016
Related Documents
