EECS 481 - 1/16/07 |
please flag with care:
| |
| 2007-11-08 | No history |  | Add My version | |
download mind map 181184864.mm (mindmap file created by FreeMind)
| | |
| This is a lecture content from http://www.kylemulka.com/freemind/ | |
 | |
| outline | |
EECS 481 - 1/16/07
Agile
Manifesto for Agile Software Development
deliver working software frequently
2-3 weeks
less emphasis on analysis and design
earlier implementation
responsiveness to change
close collaboration with the client
see new version every 3 weeks
stories
pair programming
test cases for a task are drawn up first
timeboxing
instead of feature boxing
3 week sprints
descoping
take out features from release
standup meetings
short meeting every day
attendance required
do not sit
15 minutes
raise problems not solve them
pros
customer gets to see working software frequently
good feedback
features not rushed (sloppy code)
more time fixing problems
stories, features get prioritized
expectations are clear from both sides
see what people are doing
cons
design document almost non-existent
too much emphasis on time rather than features
lack of documentation
doesn't scale up
need quick feedback
Open Source
no one gets paid
great thing to have on your resume
mods
individual builds an initial version
if sufficient interest
users become co-developers
second phase
corrective maintenance
adding functionality
porting program
pros
will last forever
fosters creativity
free software
attracts top software engineers
cons
non-incremental changes
easily crushed by marketplace
changes hard to 'drive'
can become non-maintainable
how do you 'sell' free software
Teams
group structure
democratic
cheif programmer
task sharing
completely decoupled
completely non-separable
Brooks' Law
egoless programming
restructure social environment
encourage team to find faults in code
democratic teams
chief programmer team
secretary
maintaining program production library
test data
documentation of project
backup programmer
if you loose the chief programmer
black box test case planning
3 sub programmers
do nothing but program
chief programmer
good manager
highly skilled programmer
architectureal design
interfacing issues
allocates work
beyond CP and democratic
team manager
personel leader
team leader
technical leader
programmers
prof
"good analagy, thanks"
|
| |