Agile Software Development in Practice:Experience, Tips and Tools from the Trenches of Higher Education
Valerie Puffet-Michel ([email protected])and Thomas Wood ([email protected])
Student Affairs Information TechnologyUniversity of Connecticut
NERCOMP 2012
1
Who are we?
Student Affairs Information Technology (SAIT)
Application development team- 4 developers- 1 team lead with several hats
2
• Center for Students with Disabilities
• Residential Life
• Office of Student Services and Advocacy
• Dining Services
• Career Services
Who are our customers?
3
Outline
• Why write custom software?
• Challenges of software development in higher education
• Our secret sauce!
• Walk through “The life of a feature”
• What worked for us and what didn’t ...
• Where do you start?
4
• When you can’t always get you want (from a vendor) ...• Quality• Features• Timeliness
• ... you can get what you need!• The features you need when you want them• Opportunity to design a system: software, business process, integration
Why write custom software for higher education?
5
So ... we want to develop software, but ...
6
• In typical software projects:• Scope, resources, planning determined at start of the project ...• ... when you know the LEAST
• We face:• Limited resources• Diverse demands• Everything is important
(no economy!)
It’s not that easy ...
7
Agile
8
What values are driving us?
Individuals and interactions
Working software
Customer collaboration
Responding to change
over processes and tools
over comprehensive documentation
over contract negotiation
over following a plan
while there is value in the items on the right,
we value the items on the left more.
Agile Manifesto
9
Values continued
10
• Scrum: Agile Project management
• Good development practices
Our secret sauce!
11
Let’s walk through the life of a feature
12
We want to hire a notetaker... It takes too much time now!
Can you help us?
Meeting with the customers
13
Mockup
14
Clarify the story
• Val & the team have a conversation, clarify the story.
15
Estimate the story
• The team estimates using a card game called planning poker!
16
Identify stories and commitment!
• Team commits to a group of stories that they will work on in the next 2 weeks.
17
Daily Standup
• Meeting every day... 15 minutes... standing up!
18
Development in progress...
19
Conversation leads to just enough design
• Story as conversation
• What does it mean for a story to be “done”?
• Design just enough to implement the feature
20
Source control and branching
• Central source code repository
• “Trunk”: always deliverable
• “Branch”: private copy of the trunk
21
Tests
• We believe strongly in tests. • 2x as much test code as application code• Tests make us fearless• Tests give us executable documentation• Our tests are automated and easy to run
22
Two types of tests
• Unit tests
• “When a notetaker is hired for a class, the notetaker should be added to the list of notetakers for the class.”
• Functional tests
• “Given I am viewing the schedule for a prospective notetaker, when I check the box next to a class, enter a cell phone numberand click the hire button, I should see the ‘notetaker hired’ message”
23
Test Coverage
• Goal is to make sure every line of code is tested.
• All of the individual tests are collected in a test suite
• Coverage measures which lines of code are executed while a test suite run.
24
Hire a notetaker screen
25
Tom is done!
• What does it mean to be “done”?
• Story is implemented
• Tests pass
• Coverage is good.
What’s next?
26
The team reviews the code
• Change is distributed to team members for review• Why code review?
• shared ownership • increase quality• follow standards• cross training for free
27
Jenkins helps test the feature automatically
• Jenkins is a continuous integration server.• How does it work?
• When new code is committed to trunk, Jenkins runs the tests automatically, measures the coverage, and deploys the application so Val can try it out.
• Goal: • Automated builds that verify quality: • Make sure we still have working software
Work smarter, not harder!
28
29
Development practices in a nutshell...
• Source code control
• Simple design
• Automated tests
• Code review
• Continuous integration
30
Val accepts or rejects a story
• Last quality check
31
Demo and customer feedback
32
Story is live!
33
Repeat as needed!
• multiple stories (bricks)
• multiple sprints (rooms)
34
Challenges we faced
• Customer collaboration• Getting regular time with customers. • Getting customers to test the software.• Not having the right users in the room (e.g. students, maintenance staff)
• Development practices & estimation• Deployment cost• Code review bottleneck• Difficulty estimating uncertain stories
35
What works for us?
• Customer collaboration and feedback• Customer prioritizes the work, team only works on most important features.• We make change happen, flexible• We continually improve our practices.• Deliver software as we go (one brick at a time!)
• Team works on one project at a time • Management support and clear priorities set by SAITOC (Student Affairs IT
Oversight Committee)
• We have fun and love what we do. Everyone is happy!
36
Another view on our practices
• show data!
37
Where do you start?
• One step at a time
• Make mistakes and learn from them
• Enjoy the journey ... patience.
• Make it fun!
38
Acknowledgements
• Our team:
• Matthew Coolbeth
• Matthew Desmarais
• Michael Keating
• SAIT
39
Learn more• the agile manifesto: http://agilemanifesto.org/
• scrum• Intro to scrum - http://www.mountaingoatsoftware.com/topics/new-to-agile-or-scrum• Agile Project Management with Scrum - Ken Schwaber• Jeff Sutherland's blog: http://scrum.jeffsutherland.com/
• development practices• Practices of an Agile Developer - Venkat Subramanian, Handy Hunt• Extreme Programming Explained - Kent Beck, Cynthia Andres• Continuous delivery - Jez Humble, David Farley
• estimation, planning and stories• Planning poker: http://www.mountaingoatsoftware.com/topics/planning-poker• User Stories Applied: for agile software development - Mike Cohn• Agile Estimation and Planning - Mike Cohn
• from traditional project management to agility• The software Project Manager's Bridge to Agility - Michelle Sliger, Stacia Broderick• Agile Project Management: creating Innovative Products - 2nd Edition - Jim Highsmith
• certifications: • Scrum Master and Product Owner - Scrum alliance - http://www.scrumalliance.org/• PMI- ACP - http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
41
Tools
• nose (www.readthedocs.org/docs/nose) - automated test framework
• Jenkins (www.jenkins-ci.org) - continuous integration server
• Pivotal Tracker (www.pivotaltracker.com) - agile project management
• Google Code Reviews (code.google.com/p/rietveld) - code review tool
• Subversion (subversion.apache.org) - version control system
42
Software stack
• Debian Linux (www.debian.org) - operating system
• Python (www.python.org) - programming language
• Pylons (www.pylonshq.org) - web framework
• SQLAlchemy (www.sqlalchemy.org) - object relational manager
• Microsoft SQL Server - relational database
43