aspose file tools*
The moose likes Agile and Other Processes and the fly likes Jared Richardson and Will Gwaltney - our process... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Jared Richardson and Will Gwaltney - our process..." Watch "Jared Richardson and Will Gwaltney - our process..." New topic
Author

Jared Richardson and Will Gwaltney - our process...

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Hi all,

How we are developing software is:



What is this process. How different other processes from this...

Please comment...

Thanks a lot.
Tony William
Ranch Hand

Joined: Jun 27, 2005
Posts: 54
Who will get involved in the "Review comments" task? users? or just the developers / team lead?

This information may be quite important if we try to map your current process to a well known process in the development world e.g. SDLC, RUP etc


MCP, MCP+I, MCSE(NT4), MCSE+I, MCSE(2000), MCDBA, MCSD(VS6)<br />SCJP 5.0, SCBCD 1.3<br />ICED(v5.0), ICSD (WSP5.0)
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Initially, review is done by our team meamber/team lead, later on it is done by client...

Tony William
Ranch Hand

Joined: Jun 27, 2005
Posts: 54
In this case, I think you (or your team) are already taking an iterative approach.

Besides, I believe during the review, there may be changes (though it may not be fundamental) to your design too.
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Thanks Tony but I think iterative developement is, you develop somthing concrete, release, get review comments, incorporate those and develope some more and then again release and so on.....

But in our case, when first time we give code (deliver) to client, it is complete in all sense from our side, if we get something (review comments) then only we change otherwise its done.

Anyway, How other process like XP, UP, RUP are different from iterative developement and/or *our* approach???

Thanks a lot.
Rudy Harianto
Ranch Hand

Joined: Dec 01, 2003
Posts: 94
is it necessary that the review process be done after all the feature have tested?
cos in my opinion, if the review result in even a little changes, the whole testing should be conducted again. it seems to be wasting time to me..


SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJA<br /> <br />blog: <a href="http://jroller.com/page/rharianto" target="_blank" rel="nofollow">http://jroller.com/page/rharianto</a>
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Yes, you are absolutely right, and we are facing such problems. But we can't give un-tested code to client...
Jared Richardson
author
Ranch Hand

Joined: Jun 22, 2005
Posts: 113
This looks like the classic (and hated) Waterfall methodology to me. Sorry!

You don't show the client ~anything~ until you are done. What happens if you don't get the original specifications right? What if the customer asked for one thing but meant something else?

You comment about not showing untested code to customers. Why not? Your customers aren't idiots (I hope!). Let them know it's a technology preview, a demo, or a beta. Give them (or at least a customer representative) a look at the product weekly or monthly. Give them a chance to point out the problems early, when it's still cheap to fix.

You should really check out Ship It! (or another book, there are lots of goods one) and read about a more Agile process. There are lots of ways to build a product that can be shown to customers as you go (like Tracer Bullet Development). It sounds like you are using a classic process that is known to have problems.


Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
Rudy Harianto
Ranch Hand

Joined: Dec 01, 2003
Posts: 94

You comment about not showing untested code to customers. Why not? Your customers aren't idiots (I hope!). Let them know it's a technology preview, a demo, or a beta. Give them (or at least a customer representative) a look at the product weekly or monthly. Give them a chance to point out the problems early, when it's still cheap to fix.


Jared,
some clients won't be happy if they see error on your applications, especially when they have existing software working on their system. I have experiences on this situation. They always comparing and complaining that their existing s/w is better (in the context of the smooth process and no error). It's really depresing cos they did it in a sarcastic way
[ August 03, 2005: Message edited by: Rudy Harianto ]
Rudy Harianto
Ranch Hand

Joined: Dec 01, 2003
Posts: 94

You should really check out Ship It! (or another book, there are lots of goods one) and read about a more Agile process. There are lots of ways to build a product that can be shown to customers as you go (like Tracer Bullet Development). It sounds like you are using a classic process that is known to have problems.


agree..
Isn't that the goal of your book too? To share your experience with people like us
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Jared Richardson:
This looks like the classic (and hated) Waterfall methodology to me. Sorry!

You don't show the client ~anything~ until you are done. What happens if you don't get the original specifications right? What if the customer asked for one thing but meant something else?

You comment about not showing untested code to customers. Why not? Your customers aren't idiots (I hope!). Let them know it's a technology preview, a demo, or a beta. Give them (or at least a customer representative) a look at the product weekly or monthly. Give them a chance to point out the problems early, when it's still cheap to fix.

You should really check out Ship It! (or another book, there are lots of goods one) and read about a more Agile process. There are lots of ways to build a product that can be shown to customers as you go (like Tracer Bullet Development). It sounds like you are using a classic process that is known to have problems.


Completely agreed .

But what if client himself/herself point out mistakes late. In that case no prcoces will work ...
Tony William
Ranch Hand

Joined: Jun 27, 2005
Posts: 54
rathi,

But what if client himself/herself point out mistakes late. In that case no prcoces will work


A good point that no process will work if nobody follow the rule of the game (i.e. the process).

Anyway, I think this is why we need to have rounds of reviews / comments / user feedback before the UAT (bear with me in using this term to refer to a situation where we only show to user the 'final' deliverables). If something goes wrong / gear towards a wrong direction, we can correct it earlier.
Rudy Harianto
Ranch Hand

Joined: Dec 01, 2003
Posts: 94

But what if client himself/herself point out mistakes late. In that case no prcoces will work


before the UAT, it is our responsibility to make sure that no error on our application. Usually testing is conducted by QA team. The "acceptance criteria" is based on QA assumtion from the requirement gathering, and usually has been approval from the client.
after that UAT kick in and on this phase, a team from user do the testing. If something goes wrong they can still charge the developer team to fix it.
This is done over and over until the client approve the UAT.

From the process above, the key thing is The "acceptance criteria" which should be agreed form both sides.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Jared Richardson and Will Gwaltney - our process...