• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Ship it

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In todays world of - we need to get to the market soon, we only have X number of developers due to attrition etc, yet we have to make the deadlines, code reviews and quality seems to be suffering. I would love to read this book to see what the authors advise on how to get over such issues.
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In addition, the most common and I think the biggest problems on the software development project are requirement changes (mostly from the client) during development phase. I wanna know how to deal with it?
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shifting requirements during the development phase are a fact of life, so the best approach is figuring out how to best incorporate them in your project lifecycle. It would indeed be interesting to see what Ship It has to say about this. On a general level I would say this:

(1) You have to have clilent buy-in: they can't expect to give you reams of change requests and not get involved on a daily basis, giving considered feedback, testing, and so on.
(2) Iterative development is the way to go. Code and test a bit, seek feedback, move on
(3) You need strong project management, someone with the confidence & authority to draw a line in the sand as required
(4) Related to (1), regular communication with the client will help get the message across that at some point they will have to decide between new features, delivery time, cost, etc.
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What will happen if the project is managed under SDLC? We may not be able to do it in an iterative way (I mean doing a little development, test it and get user feedback).
 
Rudy Harianto
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ben,


(4) Related to (1), regular communication with the client will help get the message across that at some point they will have to decide between new features, delivery time, cost, etc.



case no.1:
Most of the time, the client itself don't know what they wanted or expected exactly by the time the requirement gathering conducted. after the application developed and tested (UAT), they feel that it doesn't met their expectation. This can be a disaster for developers if the mistakes is the fundamental things. Often we have to revise the application from the scratch.

Case no.2:
Or they know but they didn't tell us unless we ask them.

I'm also curious how this problems was discussed in the book!
Jared or Will, could you give us a sneak peek on this?
 
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In todays world of - we need to get to the market soon, we only have X number of developers due to attrition etc, yet we have to make the deadlines, code reviews and quality seems to be suffering. I would love to read this book to see what the authors advise on how to get over such issues.



I'd love for you to!

Seriously, I can't begin to address your quesiton in this forum... it's the entire book. The practices we've gathered work very well in the cirucmstances you're describing. We did come through two startups that had some very tight times.

In addition, the most common and I think the biggest problems on the software development project are requirement changes (mostly from the client) during development phase. I wanna know how to deal with it?



Dealing with changing requirements means your process allows for change. (Simple, huh?) We use Tracer Bullet Development because it makes allowances for change. We use The List because it helps your customer make informed decisions about change.
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What will happen if the project is managed under SDLC? We may not be able to do it in an iterative way (I mean doing a little development, test it and get user feedback).



I can honestly say I've never seen SDLC referenced as much as I do on Java Ranch. Why is it so emphasized here and what's your frame of reference?
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

case no.1:
Most of the time, the client itself don't know what they wanted or expected exactly by the time the requirement gathering conducted. after the application developed and tested (UAT), they feel that it doesn't met their expectation. This can be a disaster for developers if the mistakes is the fundamental things. Often we have to revise the application from the scratch.



Excellent example. Use Tracer Bullet Development to get a shell of the product up and running ~very~ early in the cycle. You've only implemented a shell of your product, but it ~looks~ like it's working. You take this hollow product to your customer and get their feedback. They will always have changes, but you've invested so little work that's it's still easy to make changes.

We used this technique extensively at a startup with biotech applications. We sometimes turned out a different version of the front end GUI daily.

The great part here is that the back-end code doesn't change much, so those developers keep working, even while the front end is being rewritten.

Or they know but they didn't tell us unless we ask them.



Same answer. Get Tracer Bullets in place and ~show~ them the product.

Even if they do tell you what they want, it may not really be what they want. It's not intentional, but it still happens everyday. You've got to show them what you're delivering so they can use it and see if it's what they want.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jared Richardson:

I can honestly say I've never seen SDLC referenced as much as I do on Java Ranch. Why is it so emphasized here and what's your frame of reference?



This is a new phenomenon this week. I don't know what's behind it. It's not a Ranch thing in general.
 
And when my army is complete, I will rule the world! But, for now, I'm going to be happy with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic