View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Time and Team Management

The Problem
At the beginning of the semester project the deadline looks like it is 2 months away. The sad fact is this is true and you should have started coding weeks ago. You may talk about it as much as you'd like but without prudent planning you will spend your last week in CS2340 cramming as many coding sessions as possible and cutting features left and right. Unless you are a strong programmer coming into this class, you will spent a vast majority of your time just learning Smalltalk and bending it to your will. For the two months we spent coding, the first 7 weeks were spent learning Smalltalk while the last week was spent actually coding useful code.

The Solution
From the start you should create some sort of deadline schedule and try to maintain this. The class is centered around one week milestones, I would highly suggest breaking these down to 3 day iterations. Meet with your group when the milestone is declared, plan how to tackle the milestone, and then meet 3 days later with results. Spend the next meeting hashing out errors and issues, and spend the remaining days implementing these days. Always reserve a day before a milestone is due for merging code and finishing up loose ends. If a milestone is due on Monday at noon, set your group deadline for Sunday at noon to give adequate time to merge code.

Towards the end of the semester your schedules will get quite packed and you may not all be able to work evenly through the milestones. Just remember that you should all at the end of the project have input equal amounts of effort, so if for the first half of the milestones you weren't able to make meetings to then make up this effort and perhaps shoulder extra burdens to ease the load on your teammates. Remember, at the end of the project your teammates fill evaluate you and nobody likes a slacker.

Extra Notes
Seeing how this is an academic experiment and not a commercial application, don't feel bad in practicing triage. You as a student typically have very limited coding experience, limited quantities of time, and therefore must make the best usage of that time. Towards the end of the project cutting one feature worth 5 points may be worth it to finish up three features worth a combined 15 points. Cutting a 10 point feature might be worth it if you implement a 1 point(on final grade) extra credit feature.

Talk to your TA and constantly keep that channel open. Your TA is your grader, if you maintain an open dialog with him/her and show that you are making progress on your code they may be a bit more lenient with deadlines and functionality tests. There is nothing worse than having a program that is 95% functional but bombs during a demo, if your TA already knows the code is functional you can still score major points and pass the milestone.

Don't be afraid of taking charge. It is better to have one or two leaders fight it out than to have no group leadership. In smaller groups it is possible to divvy up code but with more than 3 people you need somebody to help delegate and guide group meetings. A leader should facilitate discussion and try to guide it, don't try to wrestle with the entire team or you will waste yours and their time. Short and efficient meetings will make everyone happy, just make sure everything is covered. Using a room with a whiteboard is indispensable as a managing tool. With the whiteboard your team can write down a dynamic meeting schedule, scribble ideas for later consideration, and organize large amounts of data or diagrams.

Link to this Page