Kuali Financial Systems: Development Methodology

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


Remote Communications– Video Conferencing– Email lists– IM– VOIP (Skype)– Breeze (web conferencing)


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


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


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


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


Speaking of project plans, with developers, sometimes you have to dig a bit to get under the surface. A slightly exaggerated case …..


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?


• 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


• 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)

KFS Project Management

Questions?

Ask now or email

[email protected]

Kuali Financial Systems: Development Methodology

Business

Transcript of Kuali Financial Systems: Development Methodology