

Ask YC: best development/project process? - modoc

Yes, I know there is no "best" process.<p>I'm in the position of needing to define the project life-cycle and development process for a new development practice being built within a medium-sized consulting company that has until recently focused on branding/marketing.  I've made pages and pages of notes, and have looked a number of development methodologies, but I was hoping to tap into the experience and intelligence here.<p>Here are the relevant guidelines:<p>The clients are all external companies, mostly large, paying for expensive projects (therefore scope, meeting dates, quality, etc...) are all critical.<p>Most of the projects will be ground-up implementations of large, complex, Java-based web applications.<p>The project teams are distributed across multiple states, and may include off-shore resources at times.<p>The project teams will typically have a mix of experienced architect/tech-lead individuals and inexperienced people fresh out of training.<p>My current thoughts:
Due to the external clients, it's important to document and lock down the scope, budget, timeframe, etc... as much as possible.  So start out with a waterfall-ish process, with a series of steps, with hard gates, sign-offs, etc...<p>Break down the development into small feature based iterations.  Have the architect design the approach for the first iteration (class skeletons, some commented psuedo-code, arch approach docs).<p>Do iteration based, scrum-style development, with daily time-boxed con-calls, using GreenHopper+Jira for task management, scrum cards, etc...<p>Formal test plans and test phases.<p>Anyhow, I'd LOVE to hear your thoughts, experiences, etc... about project process, development cycle process, tools to support it, etc....   Thanks!
======
ubudesign
one of the worst things about large projects is the number of
developers/teams. if you have too many people, things go wrong and if you
don't have enough, projects fall behind. so there is a art to this to create
that balance.

Also as a developer, I would apply some programming principles to project
management. for example design-by-contract where you create interfaces that
define interaction with a group of classes, etc. So you divide groups/people
by function, ie UI, back-end, integration, etc. then each group would define
what they need from the other groups and what they would be able to produce.
you can then develop some process based on those requirements. I think the
person doing integration with have the most input into this. he/she has to
deal with static pages and at the same time with server side code. so its
really an interface himself

Another thing I don't like about large groups is QA. I would not have them at
all. perhaps one person that would give demo of the on going project to the
clients. if he can give the demo without running to problem and the clients
are happy with what they see then you have a QA.

one other note, create a sub group of a select few that really understand and
have a good vision of the results. they should meet and review/audit
everything and catch design errors before it becomes too late.

and finally don't manage things employees in a company. think in terms of a
research project in a univercity. with lead developers as staff and everyone
else as students. you can use you imagination as to how this would effect
every aspect of your project.

PS: I've also worked on ATG in the past but now I'm working on tomcat and
other open source.

~~~
modoc
Thanks for your insight. We'd probably have one team per project, with
hopefully the right number of people on each team, staffed based on the LOEs
we build during the architecture design phase. Dev team size would probably be
3-6, plus creative, mgmt, qa, etc...

I like the idea of the research project paradigm, as long as we remember the
stricter timelines and higher consequences of failure:)

I have to disagree with the QA thing though. It's important to test every
flow, in every major browser, on every major OS. It's also important to see
what happens when you leave this field blank and submit the form, or put in
bad data here, or use the back button and try to do something again. When
you're delivering a multi-million dollar project, it can't go out the door and
break on IE6 or Firefox, or break whenever someone enters a zip code that
doesn't exist.

PS: there are TONS of really really high buck ATG contracts available all over
the US right now. If you're interested I know a ton of companies who are dying
to find an experienced ATG dev (back end or front end), so feel free to email
me.

~~~
ubudesign
Thanks but I quit my last job few months ago so that I could work full time on
my own project.

on the QA I guess what I was trying to get to was to not let your developers
rely too much on QA team to catch the errors.

------
edw519
"it's important to document and lock down the scope, budget, timeframe"

In order to do any of these, you must first lock down the "big fat what".
Analysis. Functional specification. Specs. Whatever you want to call it.
Putting any kind of rigorous or formal framework on a project with "fuzzy
specs" is a disaster waiting to happen.

Get really, really good at defining EXACTLY WHAT the end product will be.
Don't fall into the trap of saying, "That's close enough, after the next
prototype we'll know more." That kind of thinking works well in a product
business, but not in a service business.

"Give me six hours to chop down a tree and I will spend the first four
sharpening the axe." - Abraham Lincoln

~~~
modoc
I totally agree! Defining what the client wants and exactly how it will be
delivered is crucial.

