[UPHPU] Software Development Scheduling advice

[Scott Hill]

On 1/30/07, jtaber <jtaber at johntaber.net> wrote:
>
> First, look thru some books on agile programming (Alastair Cochburn's
> blue crystal book is a good synopsis I think).  If the boss asks for a
> schedule, you better give one, BUT,  taking the above advice, break it
> down to milestones with deliverables even if it's just dialogs or
> reports or user stories, etc.  Milestones are preferably a week but
> definitely < 1 month.   Think "synch & build".  This way, every week you
> have a workable product no matter how little functionality is there.
> When changes occur (they always do), you can whip out the milestone
> chart and change it right there in front of everyone so there are no
> surprises.  After you make careful estimates, apply the fudge factor
> (I've found 3x works for us, another friend uses Pi (3.14x), another
> uses double and double again: 4x)   Honestly, you need to apply this
> factor and if the schedule looks too long, don't pretend you can do it
> faster, you probably can't - then rescope the priorities in the
> milestones.  Finally, try Rails :)


These are some really good steps to take.  You obviously have some
experience in scheduling.  If you use common sense and follow some of the
basic rules that have been mentioned so far and adapt them to your
situation, you should be pretty close.  Remember that many huge companies
with almost inexhaustible resources have a terrible time scheduling anything
and getting it right.  MS and IBM are two good examples of painful
experiences in scheduling.

My $.02

-- 
Scott Hill

"May you solve interesting problems" - Author Unknown
"A fanatic is one who can't change his mind and won't change the subject." -
Sir Winston Churchill