Project Planning
Stuart Brown
I wonder if anyone could help me with a question? As a recent computer
science graduate employed to develop some software (along with a co-worker),
we need to make a estimate of how long each phase of the SE process will
take. Since I have had no prior experience in doing this kind of thing, and
previous versions of software at this company have been developed with
virtually NO s.e. methodologies, how can we estimate the project time??
Also having had no practical experience in SE (except for a few team
projects at uni), should I follow SE methodologies (in books such as
Pressman) as closely as possible, or be a bit more flexible?
Thanx
Stuart Brown
Jonathan Allan
>
> Hi there,
>
> I wonder if anyone could help me with a question? As a recent computer
> science graduate employed to develop some software (along with a co-worker),
> we need to make a estimate of how long each phase of the SE process will
> take. Since I have had no prior experience in doing this kind of thing, and
> previous versions of software at this company have been developed with
> virtually NO s.e. methodologies, how can we estimate the project time??
Find the leader of any of the prior projects. Ask them for when
the project really started (not when the bosses said the project
started). Find the ship date for that project - whatever the ship
date of software that more or less actually worked was.
Subtract to find the number of days/weeks/months. Ask this prior
leader how big that project was. Compare to your project. Reach
a new idea of how big your project actually is. Decide how long
that is in days/weeks/months. Apply a fudge factor. Given that
you're new, I'd suggest doubling the amount of time, adding thirty,
then moving the units up one notch: days to weeks, weeks to months,
etc.
After you get good at this game, you can sometimes skip moving up
the units... ;-)
--
Jonathan Allan
Neither Mayo Clinic nor I speak for each other unless we explicitly
say so. You should assume I am speaking only for myself.
Please remove the antispam ".6809" to reply direct to me. Thanks!
Daniel T.
>Hi there,
>
>I wonder if anyone could help me with a question? As a recent computer
>science graduate employed to develop some software (along with a co-worker),
>we need to make a estimate of how long each phase of the SE process will
>take. Since I have had no prior experience in doing this kind of thing, and
>previous versions of software at this company have been developed with
>virtually NO s.e. methodologies, how can we estimate the project time??
>
>Also having had no practical experience in SE (except for a few team
>projects at uni), should I follow SE methodologies (in books such as
>Pressman) as closely as possible, or be a bit more flexible?
Would your company be willing to higher a mentor? Ask about it. Otherwise,
I would be inclined to follow the book as close a possible the first time
out. Be more flexible as you gain experience.
John Duncan
Read some material on extreme programming. A good place to look is at
http://www.xprogramming.com/ where you can download the beta version of
Ron's book, _XP Installed_.
I use a points system of one point = one perfect engineering day, and I
estimate that two points can be done in a week. Therefore, since there are
two of you, four points can be done in a week.
A perfect engineering day is when you're "on". You have a good feeling
about the day and you accomplish a lot. It's believed that you have one of
these every two or three days, or that in any three-day period you'd
probably accomplish about the same amount as on a perfect day. Don't worry
about the fudge factor. It's a fact of life, and you can't pressure
yourself into making it any better.
So, then, break down the requirements into "stories" that you think you
could accomplish in about four to six points. Then, break those stories
into tasks that you can do in between half a point to two points. You and
your partner will be doing five or six stories in an iteration period of
three weeks.
Pair up at the machine, with only one of you "driving". Switch off when you
get bored driving and want to concentrate differently.
After a couple of iterations, you'll start to understand your estimation
abilities and the load factor for the project. Perhaps you'll find that the
two of you can effortlessly do eight or nine stories. On the other hand,
you might find that you can accomplish an average of four stories. The
speed isn't so important, but the schedule is. If they don't like the
speed, they can do one of two things:
1. Fire you both, and watch the project fail.
2. Bring in an additional pair of people for the next iteration. You guys
can then rotate partners task by task.
Rule: Don't say to yourself, "I can definitely do that in a week, but I'll
try to do it in three days." It won't work. It's tempting to do, but
you're setting yourself up for disaster.
Rule: Don't let yourself be convinced that you can do the same job in less
time. You only have control over the schedule, and you don't even have
control over that--it's decided by external control over resources and
scope. If they want things done sooner, make them make the tradeoff in
scope.
Rule: Don't commit to doing something you don't understand. Understand it
first, then estimate the time.
The book I mentioned above is really, really good, although it's still beta.
Read it.
-John
Stuart Brown <stu...@abs.karoo.co.uk> wrote in message
news:8frh03$an5$1...@supernews.com...
> Hi there,
>
> I wonder if anyone could help me with a question? As a recent computer
> science graduate employed to develop some software (along with a
co-worker),
> we need to make a estimate of how long each phase of the SE process will
> take. Since I have had no prior experience in doing this kind of thing,
and
> previous versions of software at this company have been developed with
> virtually NO s.e. methodologies, how can we estimate the project time??
>
> Also having had no practical experience in SE (except for a few team
> projects at uni), should I follow SE methodologies (in books such as
> Pressman) as closely as possible, or be a bit more flexible?
>
> Thanx
>
> Stuart Brown
>
>
Stuart Brown
Thanx for all the feedback, it's been useful. However, I'd only briefly
heard of this Extreme Programming before. It sounds interesting, but I'm
not sure whether we'd want to adopt it. I guess it's because at uni I was
taught about the "traditional" approach to software engineering. Basically
the setup here is that there's two of us working on this project, I have to
"lead the way" as it were and I seriously doubt whether we'd be fired for
the project taking longer than it should, then again we won't be able to
hire any more people due to financial constraints (we're a 6-person company,
us two guys are IT - that is software development AND support and all the
other IT crap). This product needs to be out as quickly as is FEASIBLE.
However there is no way I'm gonna rush this, especially after seeing the
previous version which was frankly crap and seriously bug-ridden. We also
intend to release this product incrementally i.e. basic functionality first,
then adding extra stuff later on.
Is this Extreme Programming stuff viable for us, considering there are only
2 of us, we don't have our own in-house customer and we lack experience?
Thanx
Stuart Brown
Eamonn J. Casey
I have been reading about XP and I come from the traditional software
engineering background also. I think that pair programming and having one big
room with all the software development team working hard is not such a good
idea. New projects do not have rules so XP will work there, but existing
projects do have rules and so you must carefully choose which parts of XP you
wll implement.
I like the following techniques:
1. Short stages
2. For each feature, understand it, make tests, build it and integrate it.
Here is a manifesto that I have been working on :
"Once the software development has began, the Software Development Team
responsible for developing the software will take full responsibility for the
development of the software. The team will make all decisions regarding the
software – with the obvious advisory roles coming from outside the team.
To help others to interact with the project in an orderly manner, here are the
rules:
Staged Delivery
The development cycle will be based on true RAD development and as such will be
broken into stages where each stage has the following deliverables:
1. User Guide documentation,
2. The software itself where all features for the stage have been added and
function correctly, and,
3. Installation program.
4. Development status
Timeframe
Each stage will last between 1-2 weeks depending on the feature that will be
integrated.
Stages
The first few stages will not be ‘functional’ in the sense that the software
does anything. They will simply provide the framework. Later stages will fill in
the framework. For example, Stage 5 may be to copy the Document (the DLDB) into
the Set and Attribute model (in the Archive).
It is possible that some stages do not produce a new feature but instead
concentrate on optimising (refactoring) the software ot removing defects
reported.
As each stage begins, the feature set for that stage is locked and nothing can
change it. It will not be the case where during a stage some new requirements
that ‘must be implement’ interfer with the currently running stage.
Nearing the end of development the project will become more and more useful. The
staged delivery nature of the project and the complete set of deliverables after
every stage will allow deployment of the software prior to completion. These
deployments are treated as ‘Beta’.
Managing Feature Bloat
Defects will be fixed before continuing with feature development. Essential
functionality (defined by the nature of the sotware) will be dealt with before
‘Must have’ features. ‘Nice to have’ features will be scheduled later and
finally ‘Cool’ features will be considered although no specific effort will be
made to integrate them.
Project termination
After each stage there will be an evaluation to determine if the software
development is ‘done’. This allows termination and final delivery to be made
within 1-2 weeks.
Effects of RAD on Development
Internal architecture will be developed on-the-fly instead of up-front which is
the more traditional method.
John Duncan
Eamonn J. Casey <eamonn...@hotmail.com> wrote in message
news:3922CD15...@hotmail.com...
> I think that pair programming and having one big
> room with all the software development team working hard is not such a
good
> idea.
Well, have you tried it? To be honest, I just finished a project with five
people, all working in the same room with three machines. One guy didn't
code at all, he worked on the ancillary crap required for the project. The
other four of us did the pair programming. Whenever we had a question, we
raised it and discussed it immediately. Whenever we didn't know how to do
something, we could brainstorm ideas for "spikes", as Kent Beck calls them.
That was the most productive any of the four of us has felt.
> I like the following techniques:
> 1. Short stages
> 2. For each feature, understand it, make tests, build it and integrate it.
>
Yes, I appreciate both too.
[snipped manifesto]
Going back to the original topic, I think that XP would be a great choice
for this project. The members of the team are not experienced enough to do
cost estimation. I mean, do you guys have metrics?
With XP, you can start with gut feelings and move on to making better and
better estimates.
-John
Andy Dingley
>Read some material on extreme programming.
Depends on the co-worker, and their level of experience. If they're
good, they might make a good mentor. If they're really good, and you
both have the right attitudes for it, then you might work as an XP
team.
OTOH, XP applied wrongly to people who aren't both up to it, turns
into the blind leading the blind. You code like crazy, producing large
volumes of badly written crap with no design, no documentation and
probably no tests either.
BTW - If you aren't doing the testing bit, then that's called "two
geeks hacking", not "Extreme Programming". Sometimes that can work
too, but usually not.
Project management and estimation always goes very badly wrong. Don't
expect that you will fare any better, on your first project. The
worst mistake you can make is to refuse to admit reality (it's all
going pear-shaped) or to stick to some mythical delivery date, right
until 5 minutes before.
You won't get the answers right, but it;s a lot better to be honest
and admit this, rather than to fool yourself. If you want to try and
get it as right as possible, Steve McConnell's "black book" (Rapid
Development, MS press) is about as good as it gets.
http://www.amazon.co.uk/exec/obidos/ASIN/1556159005/codesmiths/
You won't believe much of this book until you've actually been there
and watched the piles of burning money on a project that's really
going crazy, but it's a great source of real, small-scale things you
can do to stop it going quite so wrong. It's also thick enough to
hide behind 8-)
--
Smert' Spamionam
Adrian Fresco
>However there is no way I'm gonna rush this, especially after seeing the
>previous version which was frankly crap and seriously bug-ridden.
So you had the answer to your query all along!
Cheers
Adrian.
John Duncan
> Depends on the co-worker, and their level of experience. If they're
> good, they might make a good mentor. If they're really good, and you
> both have the right attitudes for it, then you might work as an XP
> team.
>
Any statistics or anecdotes you have on this? Sounds interesting.
> OTOH, XP applied wrongly to people who aren't both up to it, turns
> into the blind leading the blind. You code like crazy, producing large
> volumes of badly written crap with no design, no documentation and
> probably no tests either.
>
I never thought that anything should be "applied" to people who actually
want to get work done. They apply themselves :)
>
> BTW - If you aren't doing the testing bit, then that's called "two
> geeks hacking", not "Extreme Programming". Sometimes that can work
> too, but usually not.
>
Well, if you don't refactor, then it's not XP either, but it can still be
pair programming, which I think is one of XP's more important tenets.
> You won't believe much of this book until you've actually been there
> and watched the piles of burning money on a project that's really
> going crazy, but it's a great source of real, small-scale things you
> can do to stop it going quite so wrong. It's also thick enough to
> hide behind
Hey, I'll take a project with piles of money, burning or not ;)
-John
Eamonn J. Casey
development and two other (who were doing two seperated pieces) were
implementing. We had a witeboard for everything. We were out of university maybe
1 year but it worked because everybody was following me. When in trouble we
brainstormed.
Pair programming depends on both programmers being at the same level. While one
is programming the other is thinking and vice versa. If the one not programming
does not see the solution then they may as well be somewhere!
Where the competence level differs I would not pair program unless the focus of
the pairing is to teach (and not to program).
Eamonn J.
John Duncan wrote:
> Eamonn J. Casey <eamonn...@hotmail.com> wrote in message
> news:3922CD15...@hotmail.com...
> > I think that pair programming and having one big
> > room with all the software development team working hard is not such a
> good
> > idea.
>
> Well, have you tried it? To be honest, I just finished a project with five
> people, all working in the same room with three machines. One guy didn't
> code at all, he worked on the ancillary crap required for the project. The
> other four of us did the pair programming. Whenever we had a question, we
> raised it and discussed it immediately. Whenever we didn't know how to do
> something, we could brainstorm ideas for "spikes", as Kent Beck calls them.
>
> That was the most productive any of the four of us has felt.
>
> > I like the following techniques:
> > 1. Short stages
> > 2. For each feature, understand it, make tests, build it and integrate it.
> >
>
John Duncan
> Where the competence level differs I would not pair program unless the
focus of
> the pairing is to teach (and not to program).
>
Well, what's the point of having less competent people around if not to
teach them something? But another thing: the more competent person should
probably be sitting there figuring out the strategy while the less competent
person is driving. That way, the less competent person can worry about the
syntax and stuff, and the more competent one can be teaching the less
competent about better algorithms, styles, etc.
Or, you could say, "I don't want anyone less competent than me working on
this project." That's a viable option, if you have the budget. But
Smalltalk houses seem to be having trouble staffing on this policy, because
the experienced ones already have jobs, or are self-employed.
-John
Andy Dingley
>> Depends on the co-worker, and their level of experience. If they're
>> good, they might make a good mentor. If they're really good, and you
>> both have the right attitudes for it, then you might work as an XP
>> team.
>>
>Any statistics or anecdotes you have on this? Sounds interesting.
I think it's tricky to mentor, but it's even harder to work as a pair
when there's a big difference in skill level between you. It's too
easy to dominate by simply doing everything, or by taking on the air
of an unapproachably Olympian expert. You need to be sufficiently
expert to be worth learning from, yet somehow never let this be too
obvious. Your partner must always think that both of you are rolling
back the boundaries together, and if you get it right, you both will
be.
When I was a freshly-graduated wee spod, my mentor was a chap called
Dr Russell Mulcahy, at BT in Newcastle. Although qualified as a medic,
he'd moved into software development. One of the nicest and most
genuine people I've ever met, let alone worked with -- just think of
the embodiment of Alan Alda's doctor in M*A*S*H.
I learned a huge amount from Russell, yet he always managed to make me
feel that I was the real expert who was inventing everything for
myself. Only 15 years later do I really realise just how mundane much
of my "innovation" must have been to the truly experienced, yet I
always felt that I was really contributing. Usually I was too - one of
the most productive bits of work I've ever done was at that time.
Only once did he "slip up". We needed to redesign something on my
project, and came up with an idea for it in the late afternoon. Over
the evening, he coded it up on his PC at home (I didn't have one then)
and produced it the next morning. I was somewhat disheartened by this,
as I took it as rather an implication that I wasn't capable of doing
it, not just that he was even more enthusiastic about the fun of doing
it than I was. He realised this immediately, realised that he'd made a
mistake and apologised. Lots of people could have coded that project,
but there's very few who could have encouraged a raw graduate to do
it, given them the technical assistance to do it right and
simultaneously mentored them in a way that they never even realised
they were being guided.
It's a skill I wish I was better at myself.
--
Smert' Spamionam
Ronald E Jeffries
wrote:
>Or, you could say, "I don't want anyone less competent than me working on
>this project." That's a viable option, if you have the budget. But
>Smalltalk houses seem to be having trouble staffing on this policy, because
>the experienced ones already have jobs, or are self-employed.
Of course, if you really don't allow anyone less competent than you on
the project, you're the dumbest guy on the project. No good can come
of that ... ;->
Ron Jeffries
http://www.XProgramming.com
Ronald E Jeffries
<eamonn...@hotmail.com> wrote:
>Pair programming depends on both programmers being at the same level.
I frequently pair with programmers who aren't at my level. It works
quite well ...
>While one
>is programming the other is thinking and vice versa. If the one not programming
>does not see the solution then they may as well be somewhere [else]!
If the partner doesn't see the solution, (a) it's the driver's fault
and (b) the first one who notices should fix it.
Ron Jeffries
http://www.XProgramming.com
John Duncan
weren't being very smart, but you do show potential!
(lol) Thanks, anyway, for introducing me to XP. I now do about half my
projects XP and half of them on paper.
-John
Ronald E Jeffries <ronje...@acm.org> wrote in message
news:B3D8CDC9D03159E1.CEC98881...@lp.airnews.net...
John Duncan
mentoring, it's simply whether or not the two of you are more productive
together than alone. (though there is a mentoring effect)
-John
Andy Dingley <din...@codesmiths.com> wrote in message
news:3jf6isk9317h2sho3...@4ax.com...
Stuart Brown
using XP?
Thanx
Stu Brown
John Duncan
> So, could you guys give me examples of some projects you've implemented
> using XP?
A group of five in my class implemented a four-thousand-line Java program
that handled order entry and temperature estimation for pre-fab aluminum.
(Our instructor works at Alcoa.) Altogether, it had like twenty-five
function points and we finished it in six days, three programmers and two on
the ISO-style documentation requirement. (We also had two days of
prototyping earlier on.) It lent itself well to XP because the requirements
changed partway through in a way that the new functionality looked a lot
like the old, only slightly different. Using XP we were able to throw out
all of our prototype code and rewrite the whole thing from scratch. In all,
we had more functionality and less chaff than other teams' products,
excepting one team that bent the requirements and used ASP instead of Java,
a decision that made sense in one respect but which probably wouldn't have
floated in the business world.
-John
redfisher
I am a graduate mechanical engineer ex general and technical manager of
companies
concerned with industrial plant construction. To day I am developing. how to
shortly
evaluate, with a proper Visual Basic program for properties calculation and
designing
of each component and relevant weight of industrial items as for: buildings,
industrial
hut, high chimneys, cranes, roller-belt conveyors, powder exhausting plants
for
belt-conveyors, silos, hoppers, etc. These programs don't evaluate only
static and
dynamic general and local stresses, deformations and sways but, even more,
stability
and safety, and on all this basis, the proper shapes and plates are chosen,
on
respecting imposed deformations either. Material database is automatically
written down. In other
words these programs put down a list of each component of relevant steel
structure or plant,
specifying , for example :
for a column - WF (HEA) ; area....; weight/ft....; Depht of section....;
I... , S..., r...., for axis 1 and
2
for a beam- CBL (IPE) ; area....; etc
for a plate: dimensions... ; thickn......
for a crane: any detail for total structure; plate girders if any;
wheels; reduction motor-gears ; rails for a belt- conveyor: number and
type of rollers; drums; cntw, belt size , curves radius vertical and
horizontal; automatic choice of one or two drive-units specifying power and
details for each component ( motor; gear, brake ) and so on. At present any
technical information is only according to EU specifications.
No calculation awareness required for programs use.
I 'm looking for whom could help me enhancing and perfecting this work, for
a future exploitation and trading..
For further information, please read
http://www.tiscalinet.it/borgio/index1.html or
http://digilander.iol.it/redfisher/index.html
conctat.
e-mail redf...@libero.it redf...@katamail.com
redfisher
--