BossTalks.com Tag: books

peet on "How many projects which you put to backlog were actually taken out of there?"

peet — Wed, 14 Mar 2007 16:14:40 +0000

Unlikely, the most of my recent ideas are backlogged, because after a night sleeping with them I am getting concerned about some parts of every idea and decide to pass on it until the good time comes. This time never comes. But I have some ideas which worked out in a good business and bring enough profit now. They were started when I was too young to worry about problems.

(read more)

abresko on "How many projects which you put to backlog were actually taken out of there?"

abresko — Wed, 14 Mar 2007 13:43:48 +0000

Didn't have backlog at all. At some point I decided that it would be neat to have product, and then I just nursed it in my head, and then started doing it. That's it. It's not released yet even in beta (I have full time job and family!, so cannot work 24/7 on it) but it will be soon. But no backlogs, just straight ahead.

(read more)

johnw on "Review of two books which I call " Risks and Agile""

johnw — Tue, 13 Mar 2007 06:37:08 +0000

Thanks, I am getting "Practices of an Agile Developer" for myself ;-)

(read more)

green on "Review of two books which I call " Risks and Agile""

green — Sat, 03 Mar 2007 21:54:08 +0000

Thinking recently about risks management for software projects, I came across few books, which I read, and truth to be told - enjoyed them:
"Practices of an Agile Developer: Working in the Real World" by Venkat Subramaniam and Andy Hunt
and
"Skills for Managing Rapidly Changing IT Projects" by Fabrizio Fioravanti

Although they are not answering straight to the question "what to do with all these risks", they are very helpful in organizing your own thoughts on what can help. Frankly speaking, I really strongly believe that there are a big amount of cases when agile methodologies can be helpful with some risks management. The biggest advantage at the moment I see in numerous and highly-frequent iterative milestones and builds. Unit tests are very helpful as well. And last but not least is a simple and small design. With all the cases I had before, I found these to be the biggest helpers in all situations. I also very much believe that proper requirements gathering is the second key to success. We want customer to be satisfied, so this need to be done to satisfy him, not you. However, that goes without saying that in such case we will get into permanently changing requirements but applying proper iterative development can give us the way out. Remember I mentioned small and simple design? There is just no universal architecture, there is no silver bullet in building software. So let's stay simple and not to create headaches for ourself before we really need it.
One of the biggest problem for many managers and customers is the lack of architectural and software development skills. They do not need to be _professional_ and _best of the best_ architects and/or developers, but they really need to know how to do things on a very low level. When noticing this, you have to get everything in your hands and control it. There are bunch of stupid cases (actually mentioned in the books above) when customer by requesting some idiotic things can screw up the success of the project. Keep in mind, that you, as a project manager/team lead need to be right here next to him to prevent this to happen, to protect him even from his own utopia. Not always possible, but you can and have to influence many things by operating easy facts. This will definately help.

Overall, it's an enjoyable reading. I liked it. Would recommend!

(read more)

green on "My review of "Mastering the Requirements Process" book"

green — Sat, 03 Mar 2007 21:11:40 +0000

I decided to share here my review of "Mastering the Requirements Process" book by Suzanne Robertson and James Robertson.
The book is not about Java development (which I am primary into), but about software development process - requirements gathering. The first thing I noticed in it is that it contains pretty much of quotes from other books. From Agile-about books. And I really liked the way how authors pointed out pros and cons. That's awesome - there is no silver bullet, and agile processes should not be used blindly like it happens too often nowadays!
I also liked that this book has some example of specifications template, which can be followed when preparing your own requirements. Also, every section of the process is clearly stated and given with different examples, and detailed explanation. May be even too detailed, but this goes next :-)
What I don't like is that there are few diagrams which looks funny and easy, but not strictly clear and official. Sometimes I wish things to be more standard. I.e. they showed formal SDLC process in too funny way. Don't like that. It's not that hard, and diagrams of SDLC are sooo well known, so doing it "funny" isn't nice. And I didn't like that it's too big. I mean the whole book. Well, you can minimize given material at least 1.5 times. But may be it's only my preference?

As for the overall picture - one thumb up, and half thumb up. So, I can say - it is 4 of 5 stars. I think this is the best book covering requirements gathering topic I ever read till date. I would recommend this book.

(read more)

white on "How many projects which you put to backlog were actually taken out of there?"

white — Sat, 03 Mar 2007 20:51:10 +0000

While I am spending time reading Peopleware, I am getting pretty interesting things from it. A lot of them fits my current theory and match my practice. And now I'd like to point out one great myths demystified by the book. It's so close to the current project, I'm working with, which is balances between live and backlog, so I couldn't miss this out.

Because of the backlog, you need to double productivity immediately.

It's one of the common myths, which are entirely wrong. Why entirely? Because there is no backlog. You do not trash your house, your car, your life. Why should you trash your work? An every project costs much more, when missed the deadline. When you put it to backlog you're killing it without any chance to recover. And what's the worst thing, is that you don't take a lesson from it. Sometimes it's easier to think that you've got a perspective project in the backlog, you're just waiting for its time to run. You loose. There is no backlog, it's a reject pile (c). Its time will never come again, and you've got to learn how to throw away without sorry. So find an inner power in yourself to make the judgement to either let the project live, here and now, or rip it this single moment. No backlog, no excuses.

Personally, I didn't recover any single project from my backlog.

(read more)