Justin Wark

Search This Blog

MMMmmmm powder at Hotham

August 26, 2010

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Awesome powder day at Mt Hotham, a nice break from working the weekend before!

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Comments

Elephant Carpaccio - An Exercise in Extreme Story Slicing!

In the world of Agile Software Development, we are always trying to find ways of delivering valuable software to customers quicker and more efficiently. One way we try to achieve this is by delivering frequently to our Testers, Product Owners and End Users. This allows us to get feedback on our progress and either change direction or confirm the direction in which we are going. Back in March when I was in Melbourne (Australia) we were lucky enough to be joined by Alistair Cockburn , who lead a series of workshops with our product and engineering team members. One exercise which I found particularly interesting (and just plain fun!) was his Elephant Carpaccio Exercise . The premise behind this exercise is to help people recognise (and experience first hand) the benefits of small stories. I decided that while I was in Bangalore, I would attempt to run the exercise not only for our Aconex product and engineering teams, but also invite external participants! The general feedba

Gravity 12 Hour MTB race

Code/Peer Review Checklist

As developers it is really easy to get focussed on the detail of the code you are writing ro changing. This can be a problem when you get to the end of a feature and you forget to tidy up loose ends (dot those i's and cross those t's!). Here is a handy code/peer review checklist that I have set up in my team: -Click around in DEVINT to ensure the new feature/bugfix and existing functionality are working sufficiently -Does it match agreed acceptance criteria? -Does the change integrate well into the wider platform? -Is the code of high quality, easy to read, etc? -Is the code change consistent with similar pieces of functionality in Atlas? -Is there more refactoring required on old code to make it consistent with the newer (presumably better) code? -Are there any additional tech or functional cards that need to be raised? -Do the specs/Features cover enough scenarios and edge cases? - Bug cards – email the team explaining how the bug was missed through dev and peer

Powered by Blogger