struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From netsql <net...@roomity.com>
Subject Re: [OT] Reasonable implementation time guesstimates
Date Sun, 14 Aug 2005 11:25:25 GMT
I guess some of this is ot, but you said any comments.

In my shop lead enginers are most productive coders ( I measure LC via 
CVS stats) and also get to... lead the project. (I have no project 
managers, who'd respect them?).

This is how I size my projects. Most similar is Scrum (minus scrum 
master) methodology to what I do.
Step 1: takes unlimited amount of time.
Mockups of every screen and report in HTML. (everyu field).
I can't possibly size it.  My clients, users managers, either know what 
they want or don't. This way I know # of screens. Only senior leads work 
w/ clients to extrack mock ups (newbies tend to say "I know" to client, 
when they should say "No, I have no idea what you want", lets write it 
down).
I call this mock up.

Step 2: I estimate that each prodcitve developr can do 3-6 modules per 
day iterative based on my 15 years + as lead. (Yes, I have a 
productivity goal. Also I have no meetings or LAN downtime). So that 
kind of means that seasoned guys can do "6" "screens/tiles" per day, vs 
less experienced guys can do "3". Since Sturts is MVC, there are like 3 
iterations. This is sizing. I do not make a Microsoft Project plan, 
becuase that artificialy limits prodtivity. (like ok, this iteration is 
not to be finished untill next week, so it eats my profit. I keep anyone 
who think MS Project = Project Managemnt away from my projects)

3. View layer iteration I do 1st. Something like ren *.html *.jsp plus 
clean up. Then I get them to make tiles, and link each jsp to be called 
by empty action that just forwards to "normal". Also emtpy formbeans or 
form maps, with some fake data in constructor. For displaytag, I use a 
collections, again fake data in contructos.  I don't do menu or 
naviagtion in this iteration. I do CSS here. Clients like to debate 
colors and images.
This I call prototype, it has emty action and tiles and css and it looks 
like it works, but no data. (3-6 per day). Clients love how quickly I go 
from 1 to 3, it shows listening ability and responsivnes.
Notice that you just wrap an emty struts sceleton arround clients screens.

4. By now, my DBA studied step 1 and has designed an E/R model. I get my 
  developers to write DAO's matching step 1 / 3 and unit test each DAO 
CRUD. (They are not tied to action or anything Struts). (3-6 per day).

5. Action was blank so far. Tie DAO to Action and View. (3-6 per day). 
Each developer worked on same vertical slice aka module.

6. Navigation and QA (3-6 per day). Since navigation is dynamic, users 
should be able to go from any page to any page at any time, I do it 
last. (story boarding is a waste, business process is dynamic and 
changing, data is static).

7. Interfaces. It takes at least several days per external interface if 
they are well defined in step 1. Write those, starting after 4.
Done!

For example, we did 1Up.com 104 screens (each screen had many tiles) for 
$760K w/ 30% margin over 4 months with 5.5 developers using above. (qa 
came in at end, to validate that mockups in 1 are just like #6. It was 
fixed bid. In hind sight, I think we would have had higher produtivity 
in PHP.

I guess you can see how I don't use top down or bottom up, uper case or 
UML. I just count screens.
Some modules are harder than others. But over life of project it averges 
out. So I allways say 3-6 per day no mater if easy or hard. I don't 
study process, it's a waging tail. I just split screens into modules and 
assign modules to developers. Moduels can be by type of user of you 
system. For example on your project you could have 1 developer write 
Admin MVC modules, another do Exibitior MVC modules and a 3rd do Manager 
MVC modules.
I do not think you sized # of screens/reports from you post at all. They 
can allways change their mind about you not understanding the process 
and making you change your design, just when you think you are done.
But lets say that there are 5 defined screens in each of the 3 modules.
After you have HTML mocups, you should be done in a week w/ 3 
developers. HTML mockups of each field on screen can take month or 2 to 
validate. ALso, if client wants 200 screens/reports but can only afford 
100, they have to pick the ones they want in version 1. And then 
external interfaces depend on if the external ones are defined and 
avilaalbe.
So my esitmates are not hard dates, they are:3 monhts from when we get 
all the hard copies of html mockups you want in version 1. (So if client 
wants a release in April, by Jan 31st they should pick the screens they 
want in version 1). Also, it can take a few weeks to mobilize developers 
(hire, etc.)
Stupid games you play are like client will say: It's 20 screens, start 
now, by the time you are 1/2 done, I'll show you the screens. I allways 
have my developers surf the web and go see a movie while client figures 
out what they want.

I had one developer do 18 modules in one day, no it was not me :-) ... 
it was a she. (She got to be the lead on my next project). A module is 
not one class, it's usualy a few classes.
But think of it, can you do a DAO per hour? and action per hour? why 
not! (and I do let guys go that can't keep up :-( ). It's not high 
stress, it's high job satisfaction from puting projects in production.

So short story is, see if you can sit down w/ the client and sketch out 
in html what they want to see. (and politley listen when they talk about 
process, but no need to write that down)

hth,
.V
http://roomity.com

Dave Newton wrote:
> Heya,
> 
> This is Struts-related because I'm using Struts, other than that it's 
> more of a project management thing. I am not a project manager; I pretty 
> much suck at anything smelling even slightly of management, and I hate 
> most everything about project management.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message