paging darsy

Happy birthday!

--
Adie
(replace spam with nickname to reply)

UKRM FAQ: http://www.ukrm.net/faq/

Triumph 955iSS / ZX9R E1 / GSF1200 bandit (for sale) / CG125
MRO#11 BOTAFOF#7 BOTAFOT#130 DIAABTCOD#17 MIB#24 YTC#16 BOB#15 ex-UKRMMA#22 BOMB#11

 

ta.

 

Is Adie our new Happy Birthday Fairy then?

 

" "

 

Veering way off topic, are you still using some scrum-like project
"methodology" at your place? We need to do something[1] here to bring
things under a bit more control. It's essentially chaos at the moment, and
I fear it's going to turn into chaos-with-a-big-fat-heavy-process-on-top if
we're not careful

[1] actually, anything

 

Of that there is no doubt.

 

I know about that shit - scrum, XP, agile methods generally.

Go on, gi'us a job.

 

we have two levels of project process. At a very high level, we have a
thing called the "IT Project LifeCycle", which is basically RUP with
the serial numbers filed off, and deals at a big old meta level how
projects are initiatived, initialized, executed, implemented and
supported. It also outlines which part of the org (ExCom, The Business,
Change Management and IT) does what and when.

Funnily enough, I'm currently heading a task force to re-hash this
process in light of the new IT organisation.

Within the various development teams, it's up to the PMs involved which
development methodologies are used, though in the two projects I've
been most closely involved with, a "Scrum-like" agile process has been
used. These have involved semi-iterative development and application
specifications, with initial wireframes being produced, getting buy-in
from business and change management stakeholders, then producing "real"
functionality which gets reviewed regularly, with specification and
feature documents being updated in "real time" as the project takes
place. Thanks to the fact I'm pretty good at doing estimates, and have
good staff, I've not missed a deadline[1] in the 2.5 years I've been
here.

Bear in mind that although the way we do things is very "Scrum like" I
don't thing Scrum's one-month review period is quick enough - I like to
have development meetings/"in development demos" at least every two
weeks, and ideally weekly. Getting this sort of buy-in from the
business throughout the project helps ensure that they get what they
need rather than what they asked for. It also gives the business a
better understanding in what's actually involved in turning their
aspirations into software, and doing this helps make it easier to get
them to understand why something takes as long as it does, or is just
plain impossible (or more usually, impractical, and why such and such
an alternative is more viable). An informed user is a happy user.

I'm also currently spearheading an initiative to start doing
test-driven-development, which I think will help cut down the currently
fairly large QA and UAT phases.

[1] I don't mean we haven't pushed deadlines[2] back to allow for the
addition of new requirements that crop up during development, just that
I've never had to disappoint the business.
[2] this is something else that's easier to get the business to swallow
if you involve them during each phase of the project.

 

Cool. A month might be overkill here, too, though it would vary widely from
project to project.

Exactly what I'm planning here. Unit tests written alongside code and wired
into the build process, which runs nightly, or at least "often". Mock
Objects to help expand the scope of your unit test tools.

We had quasi-continuous integration[1] at the last place, and it rocks.
nunit/junit, nant/ant, and CruiseControl are your friends

[1] it could have been continuous, if someone had created a daily cron job -
and not every part of the system had the tests wired-in

 

<snip>

That thing we talked about - you have mail at your sticky address. Or
should I use the gmail one nowadays?

 

Hmm. The job you'd most likely want, guessing at your skillset, is mine.
Maybe. You can always lob your CV over, I'm pretty sure we're hiring,
assuming the recently-announced 700 C&W redundancies are nothing to do with
us

 

need any technical mong-herds?

 

have a look at Framework for Integrated Test.

http://fit.c2.com/

 

"Replica Watches for Low Prices"? What subject did you use?

I almost never read the gmail one.

 

Maybe. We should do lunch

 

Give us an email addy then.

 

Subject is "My CV", and I sent it to sticky.net, sticky.co.uk

And got a delivery notification, too.

 

Part of the XP mantra is "write the test before you write the code".

Visual Studio Team System aka VS 2005 aka Whidbey has a lot of this
stuff built in, tho I've not actually used it myself.

 

simonkenyon <at> bulldogbroadband <dot> c0m

 

In the specific case of JUnit, you can't really write your JUnit tests in
advance, because you need to have the methods you're testing defined at
least to stub level.

But I agree that having your overall test approach, and your test specs and
expected results written down beforehand is A Good Thing.

The FIT thing that darsy posted a link to looks interesting, though -
bridges the gap between the test plan/documentation and the actual execution
of tests.