Comments for Matts Ramblings http://www.mattdalby.com/blog Observations on life, and game development. Thu, 19 Aug 2010 03:51:13 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Comment on Changes by NR http://www.mattdalby.com/blog/?p=75&cpage=1#comment-18 NR Thu, 19 Aug 2010 03:51:13 +0000 http://www.mattdalby.com/blog/?p=75#comment-18 How are things at work? Going to be sending out my CV, along with a lot of ppl... How are things at work? Going to be sending out my CV, along with a lot of ppl…

]]> Comment on Changes by NR http://www.mattdalby.com/blog/?p=75&cpage=1#comment-17 NR Mon, 02 Aug 2010 06:59:22 +0000 http://www.mattdalby.com/blog/?p=75#comment-17 Thinking of you- busy working on the nifty rule based system. Hows things going? Whens gym? Thinking of you- busy working on the nifty rule based system.

Hows things going? Whens gym?

]]> Comment on Changes by Dan Treble http://www.mattdalby.com/blog/?p=75&cpage=1#comment-16 Dan Treble Sun, 11 Jul 2010 22:48:32 +0000 http://www.mattdalby.com/blog/?p=75#comment-16 Good luck fella, exciting times indeed :-) Good luck fella, exciting times indeed :-)

]]> Comment on Changes by OJ http://www.mattdalby.com/blog/?p=75&cpage=1#comment-12 OJ Sat, 19 Jun 2010 09:30:06 +0000 http://www.mattdalby.com/blog/?p=75#comment-12 Congrats mate. I hope it's a fantastic experience. Congrats mate. I hope it’s a fantastic experience.

]]> Comment on This week’s bat-sh*t crazy game idea : Dwarven Mining Leauge by adrian http://www.mattdalby.com/blog/?p=54&cpage=1#comment-10 adrian Fri, 21 May 2010 19:43:27 +0000 http://www.mattdalby.com/blog/?p=54#comment-10 Right. I'm amking it NOW. Adrian Right. I’m amking it NOW.

Adrian

]]> Comment on Getting Agile by Carol L http://www.mattdalby.com/blog/?p=15&cpage=1#comment-9 Carol L Sun, 02 May 2010 03:35:21 +0000 http://www.mattdalby.com/blog/?p=15#comment-9 Do you know that RTFM also stands for Roll on the floor moaning? Apt, isn't it? Do you know that RTFM also stands for Roll on the floor moaning? Apt, isn’t it?

]]> Comment on Developers developers developers by Alex http://www.mattdalby.com/blog/?p=40&cpage=1#comment-6 Alex Sat, 10 Apr 2010 09:46:43 +0000 http://www.mattdalby.com/blog/?p=40#comment-6 Microsoft have learned how to make devs happier... They still aren't there yet :) But apple are going in the opposite direction now. Not like they care, the masses will still buy their stuff and non-caring devs will still pump out crappy apps that get approved and will be consumed. Microsoft have learned how to make devs happier… They still aren’t there yet :)

But apple are going in the opposite direction now. Not like they care, the masses will still buy their stuff and non-caring devs will still pump out crappy apps that get approved and will be consumed.

]]> Comment on Developers developers developers by Katy http://www.mattdalby.com/blog/?p=40&cpage=1#comment-5 Katy Fri, 09 Apr 2010 04:03:16 +0000 http://www.mattdalby.com/blog/?p=40#comment-5 A TRC would be lovely when one rejected with little more than a screen shot of the offending screen and a page number in the HIG to a guess at what had angered the reviewer. Locking developers into one way of solving a problem with their software is too time consuming (and expensive) for subsequent refactoring. It's very risky for companies pinning their processes to the whimsical impulse of the publisher. A TRC would be lovely when one rejected with little more than a screen shot of the offending screen and a page number in the HIG to a guess at what had angered the reviewer.

Locking developers into one way of solving a problem with their software is too time consuming (and expensive) for subsequent refactoring.

It’s very risky for companies pinning their processes to the whimsical impulse of the publisher.

]]> Comment on Getting Agile by Hamish Graham http://www.mattdalby.com/blog/?p=15&cpage=1#comment-4 Hamish Graham Tue, 23 Feb 2010 03:19:31 +0000 http://www.mattdalby.com/blog/?p=15#comment-4 I think both of these books are considered the original core scrum bibles in a lot of ways: - Agile Project Management with Scrum (http://www.amazon.com/exec/obidos/ASIN/073561993X/hamnet-20) - Agile Estimating and Planning (http://www.amazon.com/exec/obidos/ASIN/0131479415/hamnet-20) Now - in terms of your question, you might be able to derive something from a combination of these :) http://www.agilekiwi.com/charting_change.htm and http://jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html I think both of these books are considered the original core scrum bibles in a lot of ways:
– Agile Project Management with Scrum (http://www.amazon.com/exec/obidos/ASIN/073561993X/hamnet-20)
– Agile Estimating and Planning (http://www.amazon.com/exec/obidos/ASIN/0131479415/hamnet-20)

Now – in terms of your question, you might be able to derive something from a combination of these :)

http://www.agilekiwi.com/charting_change.htm and
http://jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

]]> Comment on Getting Agile by OJ http://www.mattdalby.com/blog/?p=15&cpage=1#comment-3 OJ Mon, 22 Feb 2010 23:19:04 +0000 http://www.mattdalby.com/blog/?p=15#comment-3 It is relatively simple to get an answer, but you can't do it up front. You need to run for N iterations first so you can figure out velocity, and have estimates of points on remaining stories. Use the velocity to get an approximate time for remaining points and use that to figure out the cost. Simple. The hard bit is finding N which keeps the managers happy and actually gives good results. Oh, and don't forget that the agile tenet is about managing change. So if the managers don't want time and budget to slip, then changes can't come in. If they want change, they have to expect a blowout of points. The issue of quality is a whole other kettle of fish. But this is part of the reason why long term valuation and estimation of costs/time in agile projects is generaly considered a stupid idea to try and determine up front. It is relatively simple to get an answer, but you can’t do it up front. You need to run for N iterations first so you can figure out velocity, and have estimates of points on remaining stories.

Use the velocity to get an approximate time for remaining points and use that to figure out the cost. Simple.

The hard bit is finding N which keeps the managers happy and actually gives good results.

Oh, and don’t forget that the agile tenet is about managing change. So if the managers don’t want time and budget to slip, then changes can’t come in. If they want change, they have to expect a blowout of points.

The issue of quality is a whole other kettle of fish. But this is part of the reason why long term valuation and estimation of costs/time in agile projects is generaly considered a stupid idea to try and determine up front.

]]>