[interfacekit] First whack at a schedule

Guys,

Below is my first attempt at a milestone-level schedule.  Please review 
it and tell me where I'm high on crack.  You'll notice I have nothing in 
place for app_server -- that would be because I'm woefully ignorant.  
DarkWyrm, since you've done the most work with app_server issues thus 
far, would you kindly fill in the milestone schedule for it, taking your 
que from what I've done for the other areas?  TIA!

As I sat laying this all out, I was struck yet again by the enormity of 
our task.  As somebody said on the lists a couple weeks back, you eat an 
elephant one spoonful at a time.  Well, this is the mother of all 
elephants, so we need to make sure we lay out our schedule so we can 
take it one spoonful at a time.  Once we're agreed on the ordering of 
the milestones (at least to start with), I'll go back and fill in the 
milestone tasks.  This will be a relatively brain-dead listing of each 
class method as a task (e.g., BView::StrokeLine() and 
BView::StrokeRect() will each be separate tasks).  Once I've done that, 
I'll post the schedule on sourceforge and we can review it again to make 
sure we got everything.

I know this is the "really not any fun at all" part, but the more 
quickly we get it done, the sooner we can get to coding and the better 
prepared we will be.

e

Interface Kit Team Schedule

Here's an attempt to create a schedule for the team.  To help facilitate 
this, I've broken the tasks before us into 4 general areas:

        * Interface Kit
        * Application Kit
        * app_server
        * Integration (where the previous 3 meet and work together)

Organizationally, I think it's best to consider these as 4 separate 
projects within the scope of the IK Team's charter.  As such, individual 
contributors should pick a project and stick with it -- it will make 
things a lot easier to keep track of, and losing track of stuff would be 
a bad thing. =)  I would like DarkWyrm to be the technical lead for the 
app_server; he has done an enormous amount of research and I think he is 
currently in the best position to lead the effort.  I will continue in 
my capacity as overall project lead, as well as being directly involved 
in Integration as technical lead.  We need tech leads for the Interface 
Kit and the Application Kit.

Let me head off the suggestion that we formally split into 3 or 4 
stand-alone projects: the Interface Kit, Application Kit and app_server 
are completely dependent on one another in a way that no other set of 
system components is.  Each without the other can accomplish almost 
*nothing*; I think the existence of Integration highlights this fact.

A word of warning:  this schedule will be downright huge because of the 
sheer number of items to be completed.  Each milestone listed below has 
a number of tasks associated with it; these need to be listed and the 
time for each estimated.  These tasks should be as fine grained as 
possible.  Taking BView as an example, I would expect each method on 
BView to have its own entry under milestones 1, 2, 3, 4 and 8 with 
entries added as necessary to milestones 18 to 22.  "Why so detailed?" 
you say.  I'm glad you asked. ;)

First off, the finer the schedule's granularity, the more realistic 
estimate you have for the project as a whole.  Asked to implement BView, 
one might be tempted to say "Oh, about 3 weeks," whereas an estimate of 
the time needed for each method might yield a total of two to three 
times that.  While the more realistic overall estimate may be more 
depressing
initially, being able to hit goals on or near the estimated date is much 
better for morale in the long run than constantly being behind because 
all the estimates were too low.  Trust me on this, I've worked on *way* 
too many projects that went south because of scheduling that was too 
broad -- usually because the project manager doesn't want to "distress" 
the client by making them pay for the time to schedule correctly.  Or 
design correctly, but that's a different rant. =)

Second, a fine-grained schedule helps to ensure that nothing gets 
missed.  You might think it would be hard to forget to implement a BView 
method, but if you didn't expressly schedule for that method, there are 
no interface/use case specifications or unit tests to fail because the 
method isn't doing anything.  In fact, we might not notice the missing
functionality until some app that uses it dies a horrible death and we 
have to figure out why.

Third, it helps us figure out what functionality is dependent on what -- 
which helps us schedule our tasks in a logical sequence.

Fourth, it makes it much easier for someone that doesn't have a lot of 
time available or much experience to pick something that they can tackle 
and know that they will be making a meaningful contribution.  It also 
makes it easier for us to keep track of who is doing what on large items 
like BView:  instead of saying "there's a bunch of stuff on BView
that needs doing," we can say "BView::StrokeEllipse() needs to be 
implemented" and know that a specific person is responsible for that 
deliverable.

Fifth, as daunting as a detailed schedule looks like out of the gate, 
tasks are getting completed *constantly* and it's very satisfying to see 
progress get made on a regular basis.  Ideally, one would like to be 
able to check on the progress each week and find several items completed 
since the last time it was checked.

Having said all that, here's a rough outline of milestones (keeping in 
mind that reordering, etc. is bound to happen right off the bat as well 
as during the course of development):

Interface Kit
-------------
M1:  Interface specs completed for all IK classes, functions, structs
M2:  Use cases completed for "
M3:  Unit tests completed for "
M4:  Design discussions completed for "
M5:  Group 1 supporting classes feature complete:
                BPoint, BRect, BPolygon, BRegion
M6:  Group 2 supporting classes feature complete:
                BPicture, BScreen
M7:  Group 3 supporting classes feature complete:
                BBitmap, BFont
M8:  BView feature complete
M9:  Control classes feature complete:
                BControl, BColorControl, BButton, BPictureButton,
                BRadioButton, BCheckBox
M10: "Simple" non-control widgets feature complete:
                BStringView, BBox, BStatusBar
M11: Scrolling classes feature complete:
                BScrollBar, BScrollView
M12: Menuing classes feature complete:
                BMenu, BPopUpMenu, BMenuBar, BMenuField, BMenuItem, 
BSeparatorItem
M13: ListView classes feature complete:
                BListView, BOutlineListView, BListItem, BStringItem
M14: TextView classes feature complete:
                BTextView, BTextControl
M15: Group 4 supporting classes feature complete:
                BPrintJob (belongs to print_server team?)
M16: Miscellaneous classes, structs and functions not already 
implemented:
                BAlert, etc.
M17: Replicant support classes feature complete:
                BDragger, BShelf
M18: Alpha
M19: Beta 1
M20: Beta 2
M21: Release Candidate 1
M22: 1.0!

Application Kit
---------------
M1:  Interface specs completed for all AK classes, functions, structs
M2:  Use cases completed for "
M3:  Unit tests completed for "
M4:  Design discussions completed for "
M5:  Messaging classes feature complete:
                BMessage, BMessenger, BMessageFilter, BMessageQueue, BInvoker
M6:  BHandler feature complete
M7:  BLooper feature complete
M8:  BRoster feature complete
M9:  BClipboard feature complete
M10: Alpha
M11: Beta 1
M12: Beta 2
M13: Release Candidate 1
M14: 1.0!

app_server
----------

Integration
-----------
M1:  Interface specs completed for all Integration classes, functions, 
structs
M2:  Use cases completed for "
M3:  Unit tests completed for "
M4:  Design discussions completed for "
M5:  BArchivable & associated functions feature complete
M6:  BApplication feature complete
M7:  BWindow feature complete
M8:  Alpha
M9:  Beta 1
M10: Beta 2
M11: Release Candidate 1
M12: 1.0!

Data is not information, and information is not knowledge: knowledge is not 
understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: