Project Reflections
From Square Root
To add something your thoughts:
- Edit the page or section
- Add your thoughts to the bottom of the section in which you are writing (keep things roughly chronological)
- Sign your writing with ~~~~
- Don't edit other people's stuff.
Contents |
Iteration 5
Pair Programming
- In the first few days, it seems to be going extremely well. Everyone seems to be getting the hang of it quickly and becoming productive even faster. Since we all have laptops, a separate keyboard and mouse are essential. -- Michael 16:24, 23 May 2009 (UTC)
Iteration 4
Requirements
Michael's thoughts on prototyping
- Getting the team to write code was the right thing to do even though it resulted in mostly throwaway prototypes
- Using paper prototypes to try to help people learn requirements was a mistake. The designs were a mess and it didn't clarify anything. Though it's a lot of work, the UI design has to come from a single source (one person or two people working closely together). The resulting prototypes from this effort are useless because the designs are so varied.
- We should have put more emphasis on prototyping earlier so there would be something for Nancy to play with earlier. The problem is that I'm not sure where we would have found that time based on the constraints of the program.
Architecture
When finalizing the connectors between the components (in this case we were specifying the classes that would become shared objects at run time and the interfaces between architectural elements) we originally had split the task up among three different people. Each of these people were working independently. This is the same mistake that we made when working on the prototypes. The expression "too many cooks ruin the soup" comes to mind. Basically, each of us would have come up with a functionally acceptable interface design that when combined would result in an inconsistent and unusable architecture. Rather than make the same mistake we made with the UI prototypes, we shuffled tasking around and made sure that only two people would work on the design, and that those two people would work more closely together. The two we chose were the Chief Architect (obviously) and the Chief Scientist (from a technology perspective). The Requirements Manager may have also been a good choice since he knows the requirements and DB fairly well but he's busy working on the UI requirements so it was not realistic at this time. With a project this size, design really does need to be done with only one or two people (working closely together) so the artifact designed has a unified vision. It's tempting to split things up due to timing constraints but this is a mistake. With a unified vision the end artifact will exhibit consistent patterns -- good or bad. This is far, far superior than a mishmash of different ideas - vision stew. -- Michael 01:18, 23 April 2009 (UTC)
WHAT WENT WELL:
- Common understanding on the three perspectives
- Architecture review really helped - JAVA docs
WHAT DIDN'T GO WELL:
- Background knowledge - speed up architecture analysis
- Clean up docs on Sharepoint
- It took time for everyone to be updated
- Wiki - Architecture doc - synchronize or make one out-of-date
- Better way to track issues
Detailed Design
Implementation
Risks
- What is working
- We are able to change focus based on top risks. For example, we focused on experiments after that became a top risk.
- Risk prioritization is easier(at last).
- What can be improved
- Two risks got converted to problems. These were not priority risks. We should shrink our risk list and prioritize.
- Risks should have an input into milestone/task prioritization.
Planning and Tracking
Some advice I got at one of the first Team Leads' meetings was to "just use scrum." I wish I had listened to that advice and pushed for Scrum early during the fall semester. I think we would have gotten a lot more work done last semester, have been much better off, and would have come together as a team much sooner. - Mkeeling 15:59, 14 April 2009 (UTC)
The burn down chart has been working extremely well for getting a quick understanding of what's going on on the team. The newest chart that we saw today is the best that I've seen so far in that it realistically shows exactly what we need to see in a quick and easy to understand format. - Michael 04:20, 5 May 2009 (UTC)
- What is working
- Milestone priorities work. Most of the important work got done.
- We still had the flexibility to drop tasks, and add unplanned tasks. And we found a way to show that.
- What can be improved
- We had an average of 8 hours of unplanned tasks. Yikes!
- Provide more time for detailing tasks.
- Borrowing time is hard.
Tracking:
- What is working
- Simpler charts that show data quickly.
- We have lots of good data for EOSP.
- What can be improved
- Need more time for data analysis before status meeting.
- We should decide about earned value for summer.
