RAW POWER
Ross Beamish, Adam Mitchell
UPS-Shipping Agent for Infusionsoft
Post Mortem
Version 1.0
Shipping Agent / Version: 1.0Post Mortem / Date: 4/28/08
RAWPOWER_PostMortem.doc
Document History
Date / Version / Description / Author04/28/2008 / 1.0 / Initial document / F. Ross Beamish (CA)
Table of Contents
1.Introduction
1.1Scope
1.2Overview
2.Project Summary
2.1Status Report Dashboard Summary
2.2CVS Summary
2.3Survey Results
2.4Earned Value Analysis
2.5Code Quality Analysis
2.6Team Debriefing
2.7Lessons Learned
2.7.1Estimation is hard to get right, but even poor estimates are better than no estimates.
2.7.2Keep in touch with the customer at all times, they will come to your aid when problems arise.
2.7.3Start taking care of external risks as soon as possible.
2.7.4Assumptions are bad.
2.7.5Good configuration management is crucial part to maintain good team cohesion.
2.7.6Define coding standards in the beginning and adhere to them.
2.7.7Keep all team members in the loop at all times.
2.7.8Use common tools to avoid problems.
2.7.9Use Skype for phone/internet meetings when real life gets in the way of the project.
2.7.10Don’t Procrastinate.
2.7.11Test Before A Commit.
Post Mortem
1.Introduction
The purpose of this document is to review the last four iterations of the RAW Power team.
1.1Scope
This document is the final document the RAW Power team will produce.
1.2Overview
This document is designed to summarize and review the RAW Power Shipping Agent project for the spring semester in 2008.
2.Project Summary
The RAW Power Shipping Agent team completed a successful project in conjunction with Infusionsoft. In total, six out of eight requirements were fully satisfied.
2.1Status Report Dashboard Summary
Number of Weeks in Status / Green / Yellow / RedScope / 12
Cost / 10 / 1 / 1
Quality / 10 / 2
Time / 4 / 5 / 3
Risks / 1 / 8 / 3
Expectations / 4 / 8
This is a summary of the dashboard that was on the weekly status reports that were submitted. The biggest issues the team faced were time, or lack thereof, and risks. There were multiple points in the semester were the team had new risks introduced and they didn’t always get handled right away or in the best manner.
2.2CVS Summary
This is the lines of code summary from the RAW Power CVS repository. This graph shows very little work done until the final week of the second iteration right before spring break, where more than half of the requirements were due according to the overall project plan. Right after spring break, the team ran into some configuration management problems and the team’s code vanished. According to the CVS log for commit #72 which was done by Dan Fairbank, the change he made also deleted all of the code in the CVS repository. This is about the point when he was trying to create a branch for refactoring. Adam Mitchell had the latest copy of the code and so he was tasked with restoring it. According to the developer summary, Adam had a large percentage of lines of code committed compared to the remainder of the team. After some research into this, it has been determined there are 4 major contributors to the huge number of changed lines of code. Re-importing the project after accidental deletion by Dan(2200+ lines), using a Base64.java library class(1900+ lines), uploading the XML documentation for reference, and lastly for being responsible for the Driver.java class(1000+ lines).
2.3Survey Results
Survey Results / TEAM PERCENTAGE DISAGREE / TEAM PERCENTAGE NEUTRAL / TEAM PERCENTAGE AGREE / CLASS PERCENTAGE DISAGREE / CLASS PERCENTAGE NEUTRAL / CLASS PERCENTAGE AGREE1. The project management team was well prepared. / 0% / 40% / 60% / 16% / 21% / 63%
2. The management team was on time to meetings and responsive to communications. / 0% / 60% / 40% / 5% / 30% / 65%
3. Team meetings were well organized. / 0% / 20% / 80% / 5% / 20% / 75%
4. The customers requirements for this project were well communicated. / 0% / 20% / 80% / 10% / 25% / 65%
5. I knew who the responsible party was for the role of Project Manager. / 0% / 20% / 80% / 0% / 5% / 95%
6. I knew who the responsible party was for the role of Chief Architect. / 0% / 0% / 100% / 5% / 10% / 85%
7. I knew who the responsible party was for the role of Quality Manager. / 0% / 0% / 100% / 0% / 5% / 95%
8. The milestones were well defined for each iteration / 0% / 20% / 80% / 5% / 25% / 70%
9. The deliverables were well defined for each iteration / 0% / 0% / 100% / 5% / 26% / 68%
10. There was sufficient opportunity to apply the quality techniques discussed in class. / 20% / 60% / 20% / 5% / 37% / 58%
11. The project management was accessible when help was needed. / 0% / 20% / 80% / 20% / 5% / 75%
12. There was adequate time to complete the tasks assigned by the project management team. / 0% / 0% / 100% / 10% / 10% / 80%
13. There were too many team meetings / 20% / 40% / 40% / 20% / 25% / 55%
14. There were too few team meetings / 40% / 40% / 20% / 40% / 35% / 25%
15. I was included in customer meetings/communications(when appropriate) / 0% / 20% / 80% / 20% / 10% / 70%
16. My input was taken into account during project decision-making process. / 0% / 0% / 100% / 20% / 15% / 65%
17. Task assignments were made with reasonable understanding of my skills. / 0% / 0% / 100% / 0% / 25% / 75%
18. The design architecture was appropriate for this project solution. / 0% / 20% / 80% / 0% / 25% / 75%
19. The coding standards were set and clearly communicated for this project. / 0% / 20% / 80% / 5% / 35% / 60%
20. The configuration management process was clearly defined. / 20% / 60% / 20% / 15% / 45% / 40%
21. I had adequate control in how I completed my assigned tasks. / 0% / 20% / 80% / 10% / 15% / 75%
22. The configuration management was appropriate for this project. / 40% / 20% / 40% / 20% / 30% / 50%
23. The quality of our final product is appropriate for release to the customer. / 0% / 40% / 60% / 5% / 35% / 60%
24. Our test execution provided a high level of confidence in the quality of our product. / 0% / 40% / 60% / 5% / 40% / 55%
25. Documentation standards were set and followed for this project. / 0% / 40% / 60% / 11% / 47% / 42%
26. Developers created sufficient inline source code documentation / 0% / 80% / 20% / 15% / 65% / 20%
27. The documents pertaining to issues you were working on were easily found and accessible. / 0% / 40% / 60% / 0% / 45% / 55%
28. The project was successful. / 0% / 40% / 60% / 5% / 29% / 67%
29. I participated I this project to the full level of my abilities / 20% / 20% / 60% / 5% / 30% / 65%
30. My effort and work lead to the completion of milestones in this project / 0% / 40% / 60% / 0% / 35% / 65%
A council of students from all of the project teams got together and developed a survey to give to each team to compare results as a team, as well as a class as a whole. The results show that the RAW Power team exceeded the class average in most of the areas surveyed. In some areas the team lacked a little bit, but it was made up for in other areas.
2.4Earned Value Analysis
The above graph shows the RAW Power team’s earned value. During the project the team always trended in a positive direction. The first iteration put the team behind in work performed as well as work completed. Through long hours and hard work the team was able to make up lost ground. By the end of the second iteration the team was on track and remained that way for the most part, for the remainder of the semester.
2.5Code Quality Analysis
The RAW Power team used two different tools for measuring code coverage on the project. Cobertura, a Maven plug-in, said the coverage was about 73% for the packages that included project source code. The reason the base package is factored out is that contains the driver and no project code. Emma, an Eclipse plug-in, said the team’s code coverage was 82% when omitting the driver. Although the team would have liked to have seen a higher percentage of test coverage 73% to 82% is still a respectable amount of test coverage.
2.6Team Debriefing
The RAW Power team held two debriefing sessions. The first was a Skype meeting, and the second was after the customer meeting with Infusionsoft with the team’s sponsor present. Overall, the team felt the project was a success and was glad they could contribute to its success. Some commonly brought up issues were, not planning out the entire process from the beginning, not minimizing risks as soon as possible, and CVS problems. The team’s customer seemed very pleased with the final product and anxious to implement it into their system.
2.7Lessons Learned
2.7.1Estimation is hard to get right, but even poor estimates are better than no estimates.
As a team very little estimation was completed. The Project Management team did most of the estimation and then tried to pass down the estimates as best as the management team could. The team came up with a consensus between the members of management and then multiplied by a fudge factor that varied on the developer and problem.
2.7.2Keep in touch with the customer at all times, they will come to your aid when problems arise.
Infusionsoft was the team’s biggest ally in this project even though they were the customer; they were willing to complete tasks for the RAW Power team, such as early morning conference calls with UPS.
2.7.3Start taking care of external risks as soon as possible.
This was probably the biggest downfall of the team. The research into the UPS API was not complete therefore when the team needed a new section of the API problems arose and so did the panic level.
2.7.4Assumptions are bad.
Never assume anything, always complete the research and necessary steps.
2.7.5Good configuration management is crucial part to maintain good team cohesion.
RAW Power did not take full advantage of the CVS repository available to the team. As a result the team had issues along the way and even lost all of the code once.
2.7.6Define coding standards in the beginning and adhere to them.
One of the first assignments for the configuration managers of the team was to define the team’s coding standards. Doing this early on eliminated the need to refactor the code into a proper format.
2.7.7Keep all team members in the loop at all times.
At a few key points during the semester some team members were out of the loop or MIA. This made it very difficult to complete all the necessary team tasks on time.
2.7.8Use common tools to avoid problems.
In the beginning of the semester the team had a disagreement over which IDE would be the IDE of choice for the project and this lead to some issues early on regarding version control.
2.7.9Use Skype for phone/internet meetings when real life gets in the way of the project.
Information travels at the speed of light and just because a member or two cannot be present for a meeting does not mean it can’t still happen in a virtual form. Using online tools allows team members to communicate on their schedule.
2.7.10Don’t Procrastinate.
Waiting till the last minute always ends in disaster.
2.7.11Test Before A Commit.
If the entire team followed this policy from the beginning it would have spared us a humiliating customer meeting where the demo failed.
Confidential / RAW Power 2008 / Page 1