Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

ITECH3501/6501 W9

No description
by

Jackie Rong

on 19 September 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of ITECH3501/6501 W9

Methodology
ITECH3501/6501
S
ftware Engineering
Principle
of
Week 9 - Agile Methods
Jia Rong, jiarong@acm.org
huge effort during the planning phase
poor requirements conversion in a rapid changing environment
treatment of staff as a factor of production
Classical
Problems with classical methodology?
Agile
Current software development processes are too heavyweight or cumbersome
Too many things are done that are not directly related to software product being produced
Current software development is too rigid
Difficulty with incomplete or changing requirements
Short development cycles (Internet applications)
More active customer involvement needed
Capability Maturity Model (CMM) focuses on process
Agile Methodology is a new methodology that
Satisfy the Customer through early and continuous delivery of valuable software
Welcome changing requirements – harness change for competitive advantage
Deliver working software frequently
Business people and developers work together daily throughout the project
Build projects around motivated people
Face-to-face conversation is the most efficient and effective method of conveying information
Working software is the primary measure of progress
Sustainable development means that sponsors, developers and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhance agility
Manifesto
Individuals and interactions
over
processes and tools
Working software
over
comprehensive documentation
Customer collaboration
over
contract negotiation
Responding to change
over
following a plan

Crystal
Scrum
Extreme Programming (XP)
Agile Unified Process (AUP)
Feature Driven Development (FDD)
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)
Scrum
It allows us to focus on delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance for another iteration.
is an agile process
Crystal
is a family of agile methodologies
From 1991 to 1994, Alistair Cockburn interviewed 40 successful project teams to find out how to create a methodology.

The results showed:
People don’t do what their book says to do, nor do they do what they say they did.
They can’t keep the documentation in sync with the code.
People like working together.
People are not always disciplined.


Project Manger, Team Lead, Executive (2 of the 3 must be magical)
Communication and Community
Good people are everything
Team lead must know how to tweak the methodology for each specific project
People trump process, politics trumps people, people working together trumps working alone
Good people must also communicate
Citizenship and apprenticeship learning
Key Success Factors
Benefits of Crystal Methods
One methodology does not fit all. There is no one solution
Avoids the RUP marketing problem, that sells one solution to CEO’s
Crystal is made for high turbulent environments
Allows people to be people
Adequate software production is the goal
Not highly disciplined like XP and PSP. This is realistic.
Fewest set of rules possible
Advocates professional social scientists and facilitators to assist
Address communication in detail. Cold vs. hot for different situations
Absolute communication is impossible.
Bottom line: Crystal is realistic
When to
use
Crystal Methods?
Anytime you can use Orange, Clear, or Orange Web
Up to 60 or so developers
Essential, discretionary monies, or loss of comfort
Good people
The Crystal family of methodologies use different colors to denote the “weight” of which methodology to use.
When to
avoid
Crystal Methods?
Life critical systems
Developers are not co-located
More then 60 developers
When you can not use Orange, Clear, or Orange Web
If you’re a beginner with no real leadership - do XP
Challenges of Crystal Methods
Errors on the side of leaving things out that you must add
Effective communication is very difficult
In tuning the methodology it is common for project managers to believe they have come up with the one answer
Tuners tend to embellish methodologies with too many rules, practices, and ideas
You must be able to spend the time in the planning games and/or interviews to understand
Tuning a methodology to be intolerant of peoples individual styles
Not putting the right personalities in the right roles
Rewarding the wrong things and getting behavior you do not desire as a result
Using Crystal you must first have a planning game
Figure out the size of the project and the criticality
Taking the seven principles of methodologies into account copy and alter a Crystal Method
Create templates of work products and address each of the 13 elements of a methodology. Take personality, communication issues, location, and talents into account.
Make sure you have key success factors. Plan for weaknesses and bottlenecks.
Tuning the Methodology is a requirement in Crystal
Roles - take personality into account
Skills - training, practice, and natural talent
Teams - organize the team structure
Techniques - not a focus of Crystal
Activities - planning games, refactoring
Process - how the activities fit together
Work Products - create templates
Milestones - where are you on the road
Standards - coding standards
Quality - how people take pride in work
Team Values - how the team works together
Tools - not a focus of Crystal
Personality - effects everything
13 Elements
Face-to-face
Weight is costly
Heavier methodologies for larger teams
More ceremony for criticality
More feedback and communication
Fewer intermediate deliverables
Discipline, skills, documentation
7 Principles
Self-organizing teams
Product progresses in a series of month-long “sprints”
Requirements are captured as items in a list of “product backlog”
No specific engineering practices prescribed
Uses generative rules to create an agile environment for delivering projects
Characteristics of Scrum Methods
Scrum projects make progress in a series of “sprints”
Target duration is one month
+/- a week or two
But, a constant duration leads to a better rhythm
Product is designed, coded, and tested during the sprint
Plan sprint durations around how long you can commit to keeping change out of the sprint

Product Owners
Define the features of the product
Decide on release date and content
Be responsible for the profitability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed 
Accept or reject work results.
Scrum Master
Represents management to the project
Responsible for enacting Scrum values and practices
Removes impediments
Ensure that the team is fully functional and productive
Enable close cooperation across all roles and functions
Shield the team from external interferences
Scrum Team
Typically 5-10 people
Cross-functional
QA, Programmers, UI Designers, etc.
Members should be full-time
May be exceptions (e.g., System Admin, etc.)
Teams are self-organizing
What to do if a team self-organizes someone off the team??
Ideally, no titles but rarely a possibility
Membership can change only between sprints
Sprint Planning Meeting
1st part, creating product backlog & determining the sprint goal
2nd Part, creating sprint backlog
Daily Scrum
Is NOT a problem solving session
Is NOT a way to collect information about WHO is behind the schedule
Is a meeting in which team members make commitments to each other and to the Scrum Master
Is a good way for a Scrum Master to track the progress of the Team
Sprint Review Meeting
Team presents what it accomplished during the sprint
Typically takes the form of a demo of new features or underlying architecture
A list of all desired work on the project
Usually a combination of
story-based work (“let user search and replace”)
task-based work (“improve exception handling”)
Requirements for a system, expressed as a prioritized list of Backlog Items
Is managed and owned by a Product Owner
Usually is created during the Sprint Planning Meeting
Can be changed and re-prioritized before each PM
A subset of Product Backlog Items, which define the work for a Sprint
Is created ONLY by Team members
Each Item has it’s own status
Should be updated every day
Completely developed and tested features in short iterations
Simplicity of the process
Clearly defined rules
Increasing productivity
Self-organizing
each team member carries a lot of responsibility
Improved communication
Combination with Extreme Programming
Advantages:
“Undisciplined hacking” (no written documentation)
Violation of responsibility
Current mainly carried by the inventors
Disadvantages:
Full transcript