Kuali Financial Systems:
Development Methodology & Project Management
Jim ThomasKFS Project [email protected]
Introduction
• Interactive session
• Brainstorming session
• Maybe even have some fun!
…..Well, as much fun as we can have talking about “Project Management”.
Introduction
Imagine what it might be like managing a higher ed community source project…..
At first, I imagined something like this…..
Introduction
Perhaps surprisingly to some, KFS hasn’t been like that. Rather, we have seen…
• Decisions getting made• Deadlines and commitments being honored• Collaboration for the good of higher education• Sacrificing local needs for the overall good of the project
This does not mean to imply it has been EASY.
Clearly defined principles, goals, org structure, and processes have helped.
KFS Project Management
• Overall Project structure
• Communications
• Productivity Tools
• Development Methodology
• Project Timeline
• Lessons Learned
• Q&A
Organization
KFS Org Chart
KFS Board
KFS Functional Council
KFS ProjectManager
SMESubcommittees *
DevelopmentTeams by Module *
Kuali TechnicalCouncil
* multiple teams
KFS Org Chart - Functional
KFS FunctionalCouncil
SMESubcommittees*
QA ManagerTesting
Coordinator
Lead SMEBusinessAnalyst
SMEs Testing Teams
Module Testers* multiple teams
KFS Org Chart - Development
KFS ProjectManager
Development Teams *
QA ManagerTesting
Coordinator
DevelopmentManagers *
Lead Developer
Developers
Testing Teams *
Module Testers
* multiple teams
KFS Org Chart – Technical Council
Kuali Technical Council(KTC)
- Establish and maintain development standards and methodology
- Establish and maintain technical architecture
- Resolve technical issues- KTC is not involved in day-to-day
operational decisions
KFS Org Chart
We are a community
Question?
Another Question?
How about these guys?
Guiding Principles
Guiding Principles
• KFS is based on existing FIS functionality and design
• Changes are approved by KFS Functional Council and/or Kuali Technical Council
• Maximize commonality of business practices• Make configurable as much as possible given time
and resource constraints• Burden of proof falls on advocates for change to
show benefits exceed costs• Changes subject to “The Reality Triangle”
The Reality Triangle
Scope(KFSFunctionalCouncil) Time
(Project Mgr)
Resources(KFS Board)
Communications
KFS Communication Challenges
Time zones! Including varied observance of DST!
KFS Communication Challenges
• Physical location of staff. In many cases, miles away from each other
• Numbers of people working on the project
• Different ways of doing things
• Different communication styles
• Various levels of experience on the KFS project
KFS Communications
• Bi-weekly Board Meeting (used to be weekly)• Weekly Functional Council Meeting• Weekly Development Managers Meeting• Weekly Lead Developers Meeting• Weekly SME Subcommittee Meetings (or as
needed)• Bi-weekly Technical Council Meeting• Quarterly face-to-face meetings of Board, FC, and
development teams (most important!)
KFS Meeting Protocol
• Meetings have agendas in advance• Only meet when necessary• Meeting minutes posted • Decisions and action items from meetings
documented and tracked (important! Otherwise, decisions get lost or forgotten!)
• Set deadlines for decision-making AND follow up
KFS Communications Tools
Reports and documents– Weekly PM Status Reports– Weekly SME Subcommittee Status Reports– Meeting Minutes– Specification Documents– Scope Document– Technical documentation – configuration, tools,
frameworks, etc
KFS Communications Tools
Remote Communications– Video Conferencing– Email lists– IM– VOIP (Skype)– Breeze (web conferencing)
KFS Communications Tools
Project Organization and Coordination – Confluence from Atlassian (wiki pages for
documentation, collaboration, etc)– JIRA from Atlassian (task tracking)– Sakai (document sharing, email archive, etc)– MS Excel and Project for project plans and
Gantt charts
KFS Communications Tools
Most obvious statement of the day: Communication is key
A formally defined communications plan helps
Effective communications evolve over time• Team learns what works and what doesn’t with
experience• Needs change as stage of the project changes
Development Methodology
KFS Development Methodology(in a nutshell)
Development Teams• 1 Development Manager• 1 Lead Developer• Small, cohesive teams of 3 to 7 developers• Work with Lead SME and Business Analyst to get
specifications• Work with Testing Coordinator to review reported
bugs• Work with module subcommittee to prioritize
bugs
KFS Development Methodology(in a nutshell)
Development Environments• CVS Repository for source control• Regularly scheduled and published builds of test
environments– Unit testing (daily)
– CNV, early functional testing (daily)
– REG, stable functional testing (weekly)
– Kuali Test Drive, production demo site (at each release)
• Continuous Integration Environment
KFS Development Methodology(in a nutshell)
Development in Practice• Frequent and ongoing communication with module SMEs,
business analyst, and testers• Work from a documented specification (or in a pinch, refer
to the FIS code)• Adhere to development standards defined by KTC• Make use of the core infrastructure components (KNS)
whenever possible for code reuse and productivity gains• Quarterly face-to-face meetings/focused development
effort• Regularly update project plans
KFS Development Methodology(in a nutshell)
Speaking of project plans, with developers, sometimes you have to dig a bit to get under the surface. A slightly exaggerated case …..
KFS Development Methodology(in a nutshell)
Standard set of supported development tools• Java IDE – Eclipse• Source Code Management – CVS• Continuous Integration – Anthill Pro• Application Server – Tomcat 5.5.x, Sun
JDK 1.5.x• Web Server – Apache 2• Database – Oracle, MySQL• Build and Deployment – Ant
KFS Development Methodology
How are we doing? How will we measure “success”?
My criteria:
• Are we delivering working code that provides functionality our SMEs expect?
• Are we meeting our deadlines?
• Do we have successful implementers?
Rate the Quality of a Software Team
using “The Joel Test (by Joel Spolsky)” http://www.joelonsoftware.com
• “Do you use source control?” Yes +1• “Can you make a build in one step?” Yes +1• “Do you make daily builds?” Yes +1 • “Do you have a bug database?” Yes +1• “Do you fix bugs before writing new code?” Most of the time but not a written rule +0.5
The Joel Test (continued..)http://www.joelonsoftware.com
• “Do you have an up-to-date schedule?” Yes +1• “Do you have a spec?” Yes +1• “Do programmers have quiet working
conditions?” Some do, some don’t +0.5• “Do you use the best tools money can buy?” Yes +1• “Do you have testers?” Yes +1
The Joel Test (continued..)http://www.joelonsoftware.com
• “Do new candidates write code during the interview?”
Some do, some don’t +0.5
• “Do you do hallway usability testing?”
Sometimes but we also make use of usability consultants +1
The Joel Test (continued..) http://www.joelonsoftware.com
A score of 12 is perfect. Microsoft runs at 12. (OK, they aren’t “perfect” but they do develop some pretty good software including that which is running this presentation )
KFS “Joel Test” score is about 10.5! That’s not too bad!
(According to Joel, most software companies are much lower……)
Project Timeline
KFS Project Timeline
Lessons Learned
KFS Lessons Learned(so far….many more to come)
• Regular face-to-face meetings are a MUST• Do not “squeeze” the QA cycle• Keep things simple• Have a deadline for making decisions. If
consensus cannot be achieved in a timely manner, vote on it
• Monitor productivity closely – Are specs going to be ready when developers are ready? Are developers making reasonable progress?
KFS Lessons Learned(so far….many more to come)
• It is a challenge keeping technical documentation up to date
• Avoid going “tool crazy” – use what you’ve got and only introduce new tools when VERY compelling evidence suggests that you should.
• Provide numerous opportunities for communication across development teams
• Code reviews and Infoshares are valuable tools for teaching new developers and keeping things consistent across teams
KFS Lessons Learned(so far….many more to come)
• Automated unit testing has been a challenge but is paying off. We’ve learned a lot along the way.
• Pure TDD is difficult to implement and sustain• Centrally manage core infrastructure development• Recognize and avoid “perfectionist” tendencies
that come from knowing code will be shared with world
• Functional staff are extremely valuable and typically the most scarce resource. They still have their “day” jobs and have years of expertise that can’t easily be taught to new staff.
Sound like fun?
Want to get more involved in the Kuali Financials Community?
Do you have experienced Java Web Developers? We need them and there is no better way to learn the software
orJoin the Kuali Partners Program (details at
http://www.kuali.org/about/partners.shtml)