File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Recommend a book for Project Management Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Recommend a book for Project Management " Watch "Recommend a book for Project Management " New topic
Author

Recommend a book for Project Management

Chetan Parekh
Ranch Hand

Joined: Sep 16, 2004
Posts: 3636
I am looking for a good book(s) that include following topics
(1)Complete SDLC Steps with in-depth discussion
(2)What reports will be generated at each stage of SDLC (with sample reports)
(3)How to do effort estimation
(4)How to add various kind of buffers

Please suggest me.


My blood is tested +ve for Java.
Manish Hatwalne
Ranch Hand

Joined: Sep 22, 2001
Posts: 2578

Two good books I can suggest on management (generic, not necessarily covering what you want) -

(1) Mythical Man Month, old classic
(2) Everyone needs a mentor

So Chetan, you're a manager now?? Wow!!

- Manish
[ September 14, 2006: Message edited by: Manish Hatwalne ]
Masure Nilade
Greenhorn

Joined: Sep 08, 2006
Posts: 27
Originally posted by Chetan Parekh:
(3)How to do effort estimation

  • Any project can be estimated accurately (once it's completed).
  • The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.
  • To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.


  • <b>Que sera, sera</b>
    Chetan Parekh
    Ranch Hand

    Joined: Sep 16, 2004
    Posts: 3636
    Thnaks Manish. I will search them in book stores here.
    Chetan Parekh
    Ranch Hand

    Joined: Sep 16, 2004
    Posts: 3636
    Originally posted by Masure Niladi:

  • Any project can be estimated accurately (once it's completed).
  • The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.
  • To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.


  • Can you tell me in which book you read this?
    Devesh H Rao
    Ranch Hand

    Joined: Feb 09, 2002
    Posts: 687

    Book called Personal Experience
    Chetan Parekh
    Ranch Hand

    Joined: Sep 16, 2004
    Posts: 3636
    Originally posted by Manish Hatwalne:
    Two good books I can suggest on management (generic, not necessarily covering what you want) -
    (1) Mythical Man Month, old classic
    (2) Everyone needs a mentor


    Thanks Manish !!

    Originally posted by Manish Hatwalne:

    So Chetan, you're a manager now?? Wow!!

    I have got new assignment. I jump one step ahead in this hierarchy.
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by Chetan Parekh:

    Can you tell me in which book you read this?


    I somehow suspect that the truth buried behind those somewhat exaggerated (for effect) statements is probably found in texts like:

    Facts and Fallacies of Software Engineering by Robert L. Glass
    amazonUS
    Addison Wesley Professional
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Peer Reynders:

    Facts and Fallacies of Software Engineering by Robert L. Glass
    amazonUS
    Addison Wesley Professional


    Didn't like that book very much - contains a lot of critique, but near to zero constructive advice.


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Chetan Parekh:
    (1)Complete SDLC Steps with in-depth discussion


    This will heavily depend on the process you want to use. I like Agile approaches very much. "Sam's Teach Yourself Extreme Programming in 24 Hours" is a good introductory title for managers to one of the most prominent of them.

    Another good title about the less tangible aspects of management is "Managing Agile Projects".

    (2)What reports will be generated at each stage of SDLC (with sample reports)


    The most important report, in my opinion, is a burn chart. See http://www.xprogramming.com/xpmag/jatRtsMetric.htm for a good introduction.

    Another kind of "report" that is very valuable is the Daily Standup Meeting: http://www.mayford.ca/xp/standup_meeting.shtml

    All other reports should be totally driven by the needs of your stakeholders.


    (3)How to do effort estimation


    I like the XP Planning Game for that. "Planning Extreme Programming" is a very good book on that topic.

    I've also heard a lot of good things about "Agile Estimating and Planning", but haven't read it yet.


    (4)How to add various kind of buffers


    What do you think you need buffers for? Serious question.
    Chetan Parekh
    Ranch Hand

    Joined: Sep 16, 2004
    Posts: 3636
    Thanks Ilja for valuable inputs.

    Originally posted by Ilja Preuss:


    What do you think you need buffers for? Serious question.


    Will reply soon.
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    Goldratt (The Goal, etc) talks about two forms of buffers that I liked.

    In Theory of Constraints, Drum Buffer Rope has buffer holding the output of one step to be used as input to the next step. The buffer ensures that if the second station gets going a little faster than the first it won't go idle for lack of input. Overly large buffers (inventory) have huge expense and responsiveness problems so you want to keep them as small as possible, just barely big enough to avoid starving. For example our business analysts act as customer proxies. They try to stay ahead of the developer's need for "customer interaction" but not get so far ahead that their knowledge goes stale or that priority shifts make it worthless. It's not easy (understatement.)

    In estimating, buffers are a bit of padding. When asked to give an estimate developers have two conflicting goals. One is to give the "best" estimate possible. An estimate is a statistical likelihood; given enough repetitions the average of your actuals ought to converge on your estimates. The other goal is to give an estimate you can safely make. Around here I hear "Give me a date you can commit to." Since there is always some uncertainty in a statistical likelihood, you add a buffer. This puts the poor developer in a classic Goldratt conflict - give my best estimate or my safe estimate?

    Agile methods give you the freedom to give your best estimate at all times and adjust the plan based on actual performance. A largish project should have enough stories for the actuals to converge on the estimates - velocity levels out.

    If you're not agile and you have to commit to a date then you can't afford your best estimate and you have to give yourself a buffer. A best estimate assumes each station or step in a process runs perfectly. If you have a sequence of steps with dependencies, any late step makes subsequent steps later, but any early step just piles up inventory in front of the next step. It's almost impossible for the whole project to finish early, but very likely it will finish late.


    A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Stan James:
    In Theory of Constraints, Drum Buffer Rope has buffer holding the output of one step to be used as input to the next step. The buffer ensures that if the second station gets going a little faster than the first it won't go idle for lack of input. Overly large buffers (inventory) have huge expense and responsiveness problems so you want to keep them as small as possible, just barely big enough to avoid starving. For example our business analysts act as customer proxies. They try to stay ahead of the developer's need for "customer interaction" but not get so far ahead that their knowledge goes stale or that priority shifts make it worthless. It's not easy (understatement.)


    The root problem I see here is that you are trying to optimize utilization. Lean Software Development (which adopted it from Lean Manufacturing) teaches us that that's not the best thing to do. What you should optimize instead is throughput - how long does it take for a single item to get from "a request from the customer" to "something that the customer can use".

    And the way to optimize throughput is not by introducing buffers between stations - in fact buffers, as a form of inventory, reduce throughput. The way to optimize throughput is by having generalizing specialists - that way the team can shift man power around between activities (I hesitate to call it "stations") on an as-needed basis. No buffers needed.

    Around here I hear "Give me a date you can commit to." Since there is always some uncertainty in a statistical likelihood, you add a buffer.


    I'm not sure I'd call that a buffer. If I think I can commit to something that can be done with a likelihood of 90%, I'll give an estimate that has a likelihood of being met by 90%.

    This puts the poor developer in a classic Goldratt conflict - give my best estimate or my safe estimate?


    Where does the conflict come from? Isn't it totally *obvious* that I need to give the safe estimate in such a situation?

    A largish project should have enough stories for the actuals to converge on the estimates - velocity levels out.

    If you're not agile and you have to commit to a date then you can't afford your best estimate and you have to give yourself a buffer.


    Why wouldn't the estimates level out on a non-Agile project in the same way they do on an Agile project?

    A best estimate assumes each station or step in a process runs perfectly. If you have a sequence of steps with dependencies, any late step makes subsequent steps later, but any early step just piles up inventory in front of the next step. It's almost impossible for the whole project to finish early, but very likely it will finish late.


    Ah, so the trick of an Agile project is to not have those dependencies allow to become bottlenecks?
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    The root problem I see here is that you are trying to optimize utilization.


    Yeah, I didn't make clear that it's not optimizing utilization of all stations but primarily the bottleneck. One aspect is a buffer to assure it never goes idle because that time directly affects throughput. If a non-bottleneck goes idle it really doesn't matter much. I've read that scheduling thought workers over about 80% utilization doesn't pay. Except for the poor SOB at the bottleneck.

    The way to optimize throughput is by having generalizing specialists - that way the team can shift man power around between activities (I hesitate to call it "stations") on an as-needed basis.


    Yes, something to that effect distinguishes software from machine based manufacturing if you can pull it off. Our culture is still specialists, period, and getting worse instead of better. Work is passed from one subteam to another, so the manufacturing metaphors fit pretty well. But in the best world it still takes non-zero time to pull someone from one task to another. Small tasks (stories)and small batches (iterations) really help.

    Isn't it totally *obvious* that I need to give the safe estimate in such a situation?


    No, because over time management will realize your safe estimates are padded and stop believing them. Of course it's management's fault for asking for solid commitments, but they won't remember that. I suppose you could finish early and surf the web the rest of your time but you want to be known as a good estimator AND a good deliverer.

    Why wouldn't the estimates level out on a non-Agile project in the same way they do on an Agile project?


    Part of the beauty of agile stuff is realizing that change happens, the original estimate is probably not going to be the actual, and everybody cooperates in planning the changes together. Accurate estimates and stable velocity are good. Non agile management tends to hand out a date, scope and budget and grade on making all three. Estimating long and always making the date are rewarded.

    Ah, so the trick of an Agile project is to not have those dependencies allow to become bottlenecks?


    Yes, I think that works out nicely. A pair of generalizing specialists can take a small task from beginning to end with minimal dependencies and hand-offs.

    I'd guess we're very close on visions of the ideal. I'm just a lot further from it than you are these days. I was trying to suggest some places the OP might run into buffers, not a perfect state.

    [ September 20, 2006: Message edited by: Stan James ]
    [ September 20, 2006: Message edited by: Stan James ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Stan James:
    Yes, something to that effect distinguishes software from machine based manufacturing if you can pull it off. Our culture is still specialists, period, and getting worse instead of better. Work is passed from one subteam to another, so the manufacturing metaphors fit pretty well.


    Well, you know, even top manufacturing teams aren't doing that any longer.

    Seriously, Lean Manufacturing teams, such as at Toyota, are crossfunctional teams that produce a whole car together, from beginning to end.



    --------------------------------------------------------------------------------
    Isn't it totally *obvious* that I need to give the safe estimate in such a situation?
    --------------------------------------------------------------------------------

    No, because over time management will realize your safe estimates are padded and stop believing them. Of course it's management's fault for asking for solid commitments, but they won't remember that. I suppose you could finish early and surf the web the rest of your time but you want to be known as a good estimator AND a good deliverer.


    I'm certainly not suggesting the latter, but I also don't accept that it's totally managements fault. I'd also rather have the realize what a safe estimate means earlier than later. In fact, if I don't make sure that they understand it from the very beginning, and seriously commit to it, it's no surprise that they don't feel good about it.

    Hell, why don't provide them with both estimates? "I can commit to do this in no more than three weeks. If all goes well, I expect to be already finished in two, though."

    --------------------------------------------------------------------------------
    Why wouldn't the estimates level out on a non-Agile project in the same way they do on an Agile project?
    --------------------------------------------------------------------------------

    Part of the beauty of agile stuff is realizing that change happens, the original estimate is probably not going to be the actual, and everybody cooperates in planning the changes together. Accurate estimates and stable velocity are good. Non agile management tends to hand out a date, scope and budget and grade on making all three.


    Well, of course we all know what happens in those cases: either one of those three things later is discovered to be not fixed at all, or we deliver shit.

    Estimating long and always making the date are rewarded.


    I've never been at a place where that was true. But anyway, I don't understand how this is related to estimates not leveling out. Could you please elaborate?


    I was trying to suggest some places the OP might run into buffers, not a perfect state.


    Ah, I understood you to propose places where you'd *want* to have buffers. Thanks for the clarification!
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    Well, you know, even top manufacturing teams aren't doing that any longer. Seriously, Lean Manufacturing teams, such as at Toyota, are crossfunctional teams that produce a whole car together, from beginning to end.


    Yes, I remember reading as long as 20 years ago that 9 people built a Saab from start to finish. Fantastic concept. The Goal was more about machine shop kind of operations - though he never said exactly what was being made. You have a milling machine and a milling guy, a lathe and a lathe guy. It's absolutely a good thing for knowledge workers to get away from that and work something end to end, but some folks have the idea that the way to CMMI is specialist subteams, often under different management so you have to negotiate priorities with them as external partners, have sign-off and hand-off ceremonies. Painful.

    David Anderson's "Agile Management for Software Engineering" promises to show how he used DBR and other Goldratt ideas, but the opening chapters put me to sleep. Maybe I should try again.

    Hell, why don't provide them with both estimates? "I can commit to do this in no more than three weeks. If all goes well, I expect to be already finished in two, though."


    There exist command-control hierarchies that aren't interested in what might happen, only what they can promise up the line. When promises are missed, yelling ensues. You wouldn't have an opening there would you?

    But anyway, I don't understand how this is related to estimates not leveling out. Could you please elaborate?


    I was guessing that velocity will be consistent and reliable only if everyone is giving "best" estimates, which I suggested is defined as actuals converging on the estimate or staying within acceptable variances over enough cases. I wouldn't expect the longer "safe" estimates to do that as well. They might be consistent, tho.

    Sort of on topic ... I'm intrigued by folks who say their mix of small, medium, large stories is near enough the same over time that they can plan releases and iterations just by the number of stories and not even sum up the story point estimates.
    Michael Farinha
    Greenhorn

    Joined: Jun 16, 2006
    Posts: 26
    I'm anxiously awaiting this book:
    http://www.amazon.com/Head-First-Pmp/dp/0596102348/sr=8-1/qid=1159285597/ref=pd_bbs_1/102-9712155-5368966?ie=UTF8&s=books
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    It's been a few days, but here is a WhitePaper that happens to cover the ToC buffering ideas nicely. It may well be that they don't apply to a small agile team with few handoffs.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Stan James:
    It may well be that they don't apply to a small agile team with few handoffs.


    I just started reading the paper, but the phrase "the ability to execute to plan" catched my attention. That's exactly *not* what Agility is about!
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Stan James:
    It's been a few days, but here is a WhitePaper that happens to cover the ToC buffering ideas nicely.


    It seems I stopped reading before I got to the buffering point. Perhaps it's just me, or the late hour, but somehow the whole paper sounds way too much like "resource management" and "dealing with politics" to me, where it should instead talk about true collaboration and honest, respectful communication. :shrug:
    Paul Santa Maria
    Ranch Hand

    Joined: Feb 24, 2004
    Posts: 236
    I would strongly recommend taking a look at this book:
    Effective Project Management, 3rd Edition
    Robert K. Wysocki, Rudd McGary
    [ September 30, 2006: Message edited by: Paul Santa Maria ]

    Paul M. Santa Maria, SCJP
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Recommend a book for Project Management