Agile Software Development: Practices and Values

undefined
A
 
l
i
t
t
l
e
 
S
o
f
t
w
a
r
e
 
E
n
g
i
n
e
e
r
i
n
g
:
A
g
i
l
e
 
S
o
f
t
w
a
r
e
 
D
e
v
e
l
o
p
m
e
n
t
,
P
r
a
c
t
i
c
e
s
 
t
h
r
o
u
g
h
 
V
a
l
u
e
s
C Sc 335
Rick Mercer
2
Goal and Outline
Main Goal:
Suggest practices, values, and some process for
completing a final project on time that is better than
any one person could do in four times the time
Outline
Distinguish Waterfall (plan driven) from Agile
Practices and Values of quality software
development
3
Waterfall Model
Waterfall was described by 1970
Understood as
finish each phase
don
t proceed
     till done
W. W. Royce
criticized this
proposed an
   iterative approach
4
Waterfall Became Popular
 
Management (usually software ignorant) like phases
to easily set deadlines
Customers provide all requirements
Analysts translate requirements into specification
Coders implement the specification
Testing is performed by testers (not the devs) (QA)
Maintenance means modifying as little as possible
old code is good code
Change is hard (and costly)
5
To waterfall or not
Waterfall became popular for few good reasons
But this process is still is used a lot
Craig Larman's book 
[1]
 provides proof that waterfall is
a terrible way to develop software
In his study, 87% of all projects failed
The waterfall process was the "single largest contributing
factor for failure, being cited in 81% of the projects as the
number one problem." 
[1]
 
 Agile and Iterative Development:
a Manager's Guide, Addison-Wesley Professional, 2003
6
A Spiral Approach
Dr. Barry Boehm proposed a spiral approach
7
Agile Software Development
 
Set of practices to produce high-quality software
Disciplined approach to software development
Successful because it emphasizes customer
involvement and promotes team work
Not a solution looking for a problem
59% of 2013 survey respondents use Agile
83% planned to use agile this year
The Agile Manifesto:
a statement of values
That is, while there is value in the items on the right, we
value the items on the left more.
9
   eXtreme Programming (XP)
an Agile Process
 
Values
Communication, Simplicity, Feedback, Courage
Principles
Provide feedback, assume simplicity, make incremental
changes, embrace change, quality work
Practices
Planning game, small releases, simple designs, automated
testing, continuous integration, refactoring, pair programming,
collective ownership, continuous integration, on-site
customer, coding standard
10
Cost of change
Cost
of 
change
time
Waterfall
Agile
11
Cost of the Project
Paraphrasing from software development companies
When we bid projects, we charge $X for doing it Waterfall
and  $X/2 for doing it Agile
12
Agile Practices:
The Planning Game
 
The planning game involves user stories
Short descriptions of desired features
Provide value to customer
Testable  (will we have that feature two weeks from now?)
Clients write requirements (user stories) and prioritize
In 335, this planning was done last week
Break up these requirements into tasks
Specific things to do: Design the, Write code to, Write test
plan, Meet with, Do a spike for shortest path, …
Match tasks to team member(s)
13
Values: Communication
 
Simply talking about the project
Determining who will do what
Understand Requirements
Write user stories to represent what the system will do
Analysis & Design sessions
Happening whenever the team is together
14
Values: Communication
 
Pair programming
A good thing.  You are doing code review!
Iteration planning
What to do in the next iteration. We have 2 iterations
Retrospectives, for example what should the team
Stop doing
Continue doing
Start doing
15
Values: Feedback
 
Small Iterations
Pair programming
Constant code review  (pair programming)
Continuous integration (add often to the build—
sync your code with the system)
Pull the project from GitHub, run all tests including
your new tests and code, if all pass, commit locally,
and push your project
Automated unit tests  (JUnit)
16
Values: Feedback
 
Compiler feedback: seconds
Pair programming feedback: half minutes
Complete all tasks completed in a pair programming mode.
Unit test feedback: few minutes
Acceptance testing: Each Iteration
Your PM has accepted Iteration 1 or told you what’s missing
For a better grade, first have your team ensure you have all
requirements working
17
Practices: Simple design
 
Runs all tests
No code duplication, No code duplication, No
code duplication
Composed methods
More on this later when we talk about refactoring
18
Practices: Testing
 
Software should be tested, but it is often spotty
or overlooked
Automatic
 testing (JUnit, for example) helps us
know that a feature works and it will work after
refactoring, additional code, and other changes
Provides confidence in the program
19
Testing
 
Write tests at the same time as production code
Unit tests 
 
Feature/acceptance tests 
  

Don't need a test for every method
Testing can be used to drive development and
design of code
But it helps to have an overall architecture first (see your
UML class diagram, which is subject to change
Allows for regression testing
Did my change break previously working code?
 If well-tested, you see the red bar when you break your code
 
20
Regression Testing
 
Re-testing of a previously tested program following
modification to ensure that faults have not been
introduced or uncovered as a result of changes.
Regression tests are designed for repeatability, and
are often used when testing a second or later
version of the system under test
Regression testing can be carried out on any
applications, including
 
e-Commerce and web-based
systems
21
Testing
 
Strong emphasis on regression testing
Unit tests need to execute all the time
Unit tests pass 100%
Other testing frameworks include
SUnit (Smalltalk), HttpUnit (WebApps), AceUnit (C), CPPUnit
(C++), PyUnit (Python)
For a complete list, see
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
22
Can't unit test always
Won’
t have unit tests for
GUIs:  There are testing frameworks to simulate and
test user interaction, but not this course
Just added to WebCat
Network, use visual inspection while running
Views, animation, drawing: visually inspect
this is system verification too
Randomness: Some strategies might have some
randomness, which can be hard to work with
Use “tournaments” to see which AI wins, print results
23
Practices: On-site customer
 
Many software projects fail because they do not
deliver software that meets needs
A real client should be part of the team
Defines / decides the needs
Answers questions and resolves issues
Prioritizes features
Helps prevents devs from making decisions like:
"They probably wanted us to ....”
Consider your PM playing this role
24
Practices: Refactoring
 
Restructure code without changing the
functionality
Goal: Keep design simple
Change bad design when you find it
Remove “dead” code
Examples at Martin Fowler's Web site:
             
http://www.refactoring.com/
  
see online catalog
25
Practices: Pair programming
 
Write production code with 2 people on one machine
Person 1: Implements the method  (Driver)
Person 2: Thinks strategically about potential improvements,
test cases, issues  (a.k.a. observer or navigator)
Pairs change all the time. Has advantages such as
No single expert on any part of the system
Continuous code reviews, fewer defects
Cheaper in the long run, and more fun
Issues with Pair Programming:
Not all people like it, not everyone gets along
Need to find common time to work together (tough in college)
Requires tolerance, acceptance, showers, no bad breath
26
   Practices: Collective ownership
 
All code can be changed by anybody on the team
Everybody is required to improve any portion of bad
code s/he sees
Everyone has responsibility for the system
Individual code ownership tends to create "experts", the
"experts" tend to create difficult team situations
Every year in 335...
What would you do?
A team member does not like curly brace alignment
as the other 3 do.  Negotiate?
27
Practices: Coding standards
 
Coding Standard
Naming conventions and style
Least amount of work possible: Code should exist
once and only once
Everyone always use Java 7 always
Team has to adopt a coding standard
Makes it easier to understand other people
s code
Avoids code changes due to syntactic preferences
You get to fight over curly brace placement
Coding Standard with Eclipse
28
You may use the Eclipse Standard
29
  Practices: Continuous integration
Integration happens after a few hours of development
Checkout repo with your changes,
which may require handling conflicts of two people have
modified the same class or method– don’t do it!
Make sure all tests pass  (green bar)
In case of errors:
Do not put changes into the repo, fix them first
Check in the system to the common repository
Repeat
Your team should be using Git from command line
Recommended: do not use the EGit plugin
30
Continuous Integration
Find problems early
Can see if a change breaks the system more
quickly  -- while you remember the details
Add to the build on GitHub in small increments
Every few hours, or
after any new feature, or
When it feels right
Nice to have all 4 in the same room so everyone knows
Why Source Control?
Source control is the bedrock of software
development
“Without some sort of version control system in
place, you can't reasonably call yourself a software
engineer” Jeff Atwood
Why Git?
Need a place to store code when team size > 1
There are many Revision Control Systems
Could be proprietary: IBM and MS have their own
Could have used CVS, Subversion, Mercurial
We use Git because
It is very popular with more than 11.2 millions repos
offers free private repos for students on GitHub
Basic Git
Commands you’ll need to issue at the command
line while in your local repository
init
, 
clone
, 
status
, 
add
 (
track, stage, or
resolve)
, 
commit
, 
push
, 
merge
, 
pull
 (fetch &
merge)
.gitignore
 file lists what should be not pushed
   /bin
   .classpath
Git has a Shared Repository Model
Prevalent with small teams and organizations
collaborating on private projects
Everyone is granted push access to a single
shared repository
We are pulling from and pushing to GitHub
Git Startup
One person create a private repo on GitHub
Initialize this repository with a README
Add .gitignore Java
Select 
Settings
Select 
Collaborators 
and enter your password
Enter user names of all team members
You will need to get all GitHub account names
Also include your product managers’
Rick’s:  rhm12399
Everyone Clone it
At GitHub, copy and paste the 
HTTPS clone URL
See URL beginning with 
https://github
Issue this command while in the directory where
you want to store the local repo
git clone 
https://github.com/rhm12399/fall14.git
If using Eclipse
Open Eclipse and select
File > New > Java Project
Unclick 
Use default location
, browse, click 
finish
Edit README.md
In Eclipse, add your name to the file README.md
From the command line where README is, enter
git status
  Untracked files:
    
 
(use "git add <file>..." to include in …
git add .    
// “.” Means current folder
  Changes to be committed:
        new file:   .classpath
 
  new file:   .project
 
  modified:   README.md
git commit -m "Added name to README.md"
Push
You now have your local repo ready to push up to
the shared repo on GitHub
You will be asked for your username / password once
git push origin master
  Username for 'https://github.com': rhm12399
  Password for 'https://rhm12399@github.com':
  Counting objects: 11, done.
  Delta compression using up to 2 threads.
  Compressing objects: 100% (6/6), done.
  Writing objects: 100% (8/8), 955 bytes | …
 
Push
You now have your local repo ready to push up to
the shared repo on GitHub
git push origin master
  On branch master
  Your branch is ahead of 'origin/master' by 1 …
  (use "git push" to publish your local commits)
nothing to commit, working directory clean
Git Workflow
Use the Centralized Workflow Model
git pull
: update your local from remote in case
your teammates made changes
Make changes to code and perhaps add new files with
git add
git commit
: commit all changes to your local repo
git push
: push all changes to the remote repo
Try to be the only one to edit assigned files
Need to add new files to be tracked:  
git add .
Slide Note
Embed
Share

Agile software development emphasizes customer involvement, teamwork, and high-quality software production. Contrasting with the waterfall model, agile practices promote adaptability and iterative approaches to project completion, highlighting the importance of delivering value efficiently and effectively. This summary captures the essence of agile methodologies over traditional plan-driven processes.


Uploaded on Oct 10, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. A little Software Engineering: Agile Software Development, Practices through Values C Sc 335 Rick Mercer

  2. Goal and Outline Main Goal: Suggest practices, values, and some process for completing a final project on time that is better than any one person could do in four times the time Outline Distinguish Waterfall (plan driven) from Agile Practices and Values of quality software development 2

  3. Waterfall Model Waterfall was described by 1970 Understood as finish each phase don t proceed till done W. W. Royce criticized this proposed an iterative approach 3

  4. Waterfall Became Popular Management (usually software ignorant) like phases to easily set deadlines Customers provide all requirements Analysts translate requirements into specification Coders implement the specification Testing is performed by testers (not the devs) (QA) Maintenance means modifying as little as possible old code is good code Change is hard (and costly) 4

  5. To waterfall or not Waterfall became popular for few good reasons But this process is still is used a lot Craig Larman's book [1] provides proof that waterfall is a terrible way to develop software In his study, 87% of all projects failed The waterfall process was the "single largest contributing factor for failure, being cited in 81% of the projects as the number one problem." [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003 5

  6. A Spiral Approach Dr. Barry Boehm proposed a spiral approach 6

  7. Agile Software Development Set of practices to produce high-quality software Disciplined approach to software development Successful because it emphasizes customer involvement and promotes team work Not a solution looking for a problem 59% of 2013 survey respondents use Agile 83% planned to use agile this year 7

  8. The Agile Manifesto: a statement of values Individuals and interactions Process and tools over Comprehensive documentation Working software over Customer collaboration Contract negotiation over Responding to change Following a plan over That is, while there is value in the items on the right, we value the items on the left more.

  9. eXtreme Programming (XP) an Agile Process Values Communication, Simplicity, Feedback, Courage Principles Provide feedback, assume simplicity, make incremental changes, embrace change, quality work Practices Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, continuous integration, on-site customer, coding standard 9

  10. Cost of change Waterfall Cost of change Agile time 10

  11. Cost of the Project Paraphrasing from software development companies When we bid projects, we charge $X for doing it Waterfall and $X/2 for doing it Agile 11

  12. Agile Practices: The Planning Game The planning game involves user stories Short descriptions of desired features Provide value to customer Testable (will we have that feature two weeks from now?) Clients write requirements (user stories) and prioritize In 335, this planning was done last week Break up these requirements into tasks Specific things to do: Design the, Write code to, Write test plan, Meet with, Do a spike for shortest path, Match tasks to team member(s) 12

  13. Values: Communication Simply talking about the project Determining who will do what Understand Requirements Write user stories to represent what the system will do Analysis & Design sessions Happening whenever the team is together 13

  14. Values: Communication Pair programming A good thing. You are doing code review! Iteration planning What to do in the next iteration. We have 2 iterations Retrospectives, for example what should the team Stop doing Continue doing Start doing 14

  15. Values: Feedback Small Iterations Pair programming Constant code review (pair programming) Continuous integration (add often to the build sync your code with the system) Pull the project from GitHub, run all tests including your new tests and code, if all pass, commit locally, and push your project Automated unit tests (JUnit) 15

  16. Values: Feedback Compiler feedback: seconds Pair programming feedback: half minutes Complete all tasks completed in a pair programming mode. Unit test feedback: few minutes Acceptance testing: Each Iteration Your PM has accepted Iteration 1 or told you what s missing For a better grade, first have your team ensure you have all requirements working 16

  17. Practices: Simple design Runs all tests No code duplication, No code duplication, No code duplication Composed methods More on this later when we talk about refactoring 17

  18. Practices: Testing Software should be tested, but it is often spotty or overlooked Automatic testing (JUnit, for example) helps us know that a feature works and it will work after refactoring, additional code, and other changes Provides confidence in the program 18

  19. Testing Write tests at the same time as production code Unit tests developer Feature/acceptance tests grader in 335 Don't need a test for every method Testing can be used to drive development and design of code But it helps to have an overall architecture first (see your UML class diagram, which is subject to change Allows for regression testing Did my change break previously working code? If well-tested, you see the red bar when you break your code 19

  20. Regression Testing Re-testing of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of changes. Regression tests are designed for repeatability, and are often used when testing a second or later version of the system under test Regression testing can be carried out on any applications, includinge-Commerce and web-based systems 20

  21. Testing Strong emphasis on regression testing Unit tests need to execute all the time Unit tests pass 100% Other testing frameworks include SUnit (Smalltalk), HttpUnit (WebApps), AceUnit (C), CPPUnit (C++), PyUnit (Python) For a complete list, see http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks 21

  22. Can't unit test always Won t have unit tests for GUIs: There are testing frameworks to simulate and test user interaction, but not this course Just added to WebCat Network, use visual inspection while running Views, animation, drawing: visually inspect this is system verification too Randomness: Some strategies might have some randomness, which can be hard to work with Use tournaments to see which AI wins, print results 22

  23. Practices: On-site customer Many software projects fail because they do not deliver software that meets needs A real client should be part of the team Defines / decides the needs Answers questions and resolves issues Prioritizes features Helps prevents devs from making decisions like: "They probably wanted us to .... Consider your PM playing this role 23

  24. Practices: Refactoring Restructure code without changing the functionality Goal: Keep design simple Change bad design when you find it Remove dead code Examples at Martin Fowler's Web site: http://www.refactoring.com/see online catalog 24

  25. Practices: Pair programming Write production code with 2 people on one machine Person 1: Implements the method (Driver) Person 2: Thinks strategically about potential improvements, test cases, issues (a.k.a. observer or navigator) Pairs change all the time. Has advantages such as No single expert on any part of the system Continuous code reviews, fewer defects Cheaper in the long run, and more fun Issues with Pair Programming: Not all people like it, not everyone gets along Need to find common time to work together (tough in college) Requires tolerance, acceptance, showers, no bad breath 25

  26. Practices: Collective ownership All code can be changed by anybody on the team Everybody is required to improve any portion of bad code s/he sees Everyone has responsibility for the system Individual code ownership tends to create "experts", the "experts" tend to create difficult team situations Every year in 335... What would you do? A team member does not like curly brace alignment as the other 3 do. Negotiate? 26

  27. Practices: Coding standards Coding Standard Naming conventions and style Least amount of work possible: Code should exist once and only once Everyone always use Java 7 always Team has to adopt a coding standard Makes it easier to understand other people s code Avoids code changes due to syntactic preferences You get to fight over curly brace placement 27

  28. Coding Standard with Eclipse You may use the Eclipse Standard 28

  29. Practices: Continuous integration Integration happens after a few hours of development Checkout repo with your changes, which may require handling conflicts of two people have modified the same class or method don t do it! Make sure all tests pass (green bar) In case of errors: Do not put changes into the repo, fix them first Check in the system to the common repository Repeat Your team should be using Git from command line Recommended: do not use the EGit plugin 29

  30. Continuous Integration Find problems early Can see if a change breaks the system more quickly -- while you remember the details Add to the build on GitHub in small increments Every few hours, or after any new feature, or When it feels right Nice to have all 4 in the same room so everyone knows 30

  31. Why Source Control? Source control is the bedrock of software development Without some sort of version control system in place, you can't reasonably call yourself a software engineer Jeff Atwood

  32. Why Git? Need a place to store code when team size > 1 There are many Revision Control Systems Could be proprietary: IBM and MS have their own Could have used CVS, Subversion, Mercurial We use Git because It is very popular with more than 11.2 millions repos offers free private repos for students on GitHub

  33. Basic Git Commands you ll need to issue at the command line while in your local repository init, clone, status, add (track, stage, or resolve), commit, push, merge, pull (fetch & merge) .gitignore file lists what should be not pushed /bin .classpath

  34. Git has a Shared Repository Model Prevalent with small teams and organizations collaborating on private projects Everyone is granted push access to a single shared repository We are pulling from and pushing to GitHub

  35. Git Startup One person create a private repo on GitHub Initialize this repository with a README Add .gitignore Java Select Settings Select Collaborators and enter your password Enter user names of all team members You will need to get all GitHub account names Also include your product managers Rick s: rhm12399

  36. Everyone Clone it At GitHub, copy and paste the HTTPS clone URL See URL beginning with https://github Issue this command while in the directory where you want to store the local repo git clone https://github.com/rhm12399/fall14.git

  37. If using Eclipse Open Eclipse and select File > New > Java Project Unclick Use default location, browse, click finish

  38. Edit README.md In Eclipse, add your name to the file README.md From the command line where README is, enter git status Untracked files: (use "git add <file>..." to include in git add . // . Means current folder Changes to be committed: new file: .classpath new file: .project modified: README.md git commit -m "Added name to README.md"

  39. Push You now have your local repo ready to push up to the shared repo on GitHub You will be asked for your username / password once git push origin master Username for 'https://github.com': rhm12399 Password for 'https://rhm12399@github.com': Counting objects: 11, done. Delta compression using up to 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (8/8), 955 bytes |

  40. Push You now have your local repo ready to push up to the shared repo on GitHub git push origin master On branch master Your branch is ahead of 'origin/master' by 1 (use "git push" to publish your local commits) nothing to commit, working directory clean

  41. Git Workflow Use the Centralized Workflow Model git pull: update your local from remote in case your teammates made changes Make changes to code and perhaps add new files with git add git commit: commit all changes to your local repo git push: push all changes to the remote repo Try to be the only one to edit assigned files Need to add new files to be tracked: git add .

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#