Maven versions and feature branches

It doesn't seem that maven really supports feature branches. The version should be number.number.number-qualifier. If you want to use SNAPSHOT then the qualifier has to be exactly that.

All our artifacts are for a single webapp so we don't need to share articfacts. Given that the simplest thing seems to be to just use the version of the branch that the feature branch is tracking. e.g. if tracking master, and master is 1.2.3-SNAPSHOT, then that would be the version of the feature branch. Apart from SNAPSHOT working correctly it means that merging is less hassle.

If sharing artifacts within an organisation then something more elaborate like https://github.com/gary-rowe/MultiBitMerchant/wiki/Branching-Strategy might be needed.

Pipeline for web app development projects

One way that seems to work is to have a pipeline constructed as:

1. Requirements team go out to the customer/organisation to try and get decisions on what problems actually need to be solved and any fixed requirements/specification.
2. Once the requirements are firmed up the QA and developer join. The QA to understand the nature of the problem and record how to test if the problem is solved. The developer to understand the problem and start thinking about possible solutions.
3. QA/Dev can raise questions to requirements team to clarify specification (if required).
4. Once QA/Dev understood the requirements, QA then will write final acceptance criteria (to test if the problem is solved)
5. The problem can only enter a sprint when the QA and developer agree that it is ready to start.
6. Within the sprint the developer and QA negotiate an acceptable solution. The customer must be kept informed of changes.

At all stages any agreements with the customer must be record in the bug database.

monit

Saw lots of posts about horrible little shell scripts or full blown enterprise solutions but: http://mmonit.com/monit/ seems to work nicely for one or two boxes.

The good from latest agile project

• Sprint retrospectives are great in time boxing ongoing discussions and a good time to stop and think (as the name suggests).
• Good to limit fiddling with the process to once per sprint.

Some warnings:

• Users/customer will sit happily in sprint review meetings nodding BUT come the release they will really start thinking. The review meeting is no replacement for user testing. Really need to make the users use the app.

GWT RequestFactory network retry project

I've just been allowed to make a module from my day job FOSS.

https://github.com/salk31/gwt-rf-queue

With any luck it will get picked up by the community.

Big bang replacement of existing business system

1. Don't.
2. Almost certainly underestimated the complexity of the system you want to replace.
3. The users have learnt to live with the existing system.
4. The existing system includes endless Excel and Access things the users have knocked up and love.
5. The existing system will improve while you work on the shiny new replacement.
6. Building a new system from the ground up is exhausting.
7. Near impossible to manage user and management expectations of the new shiny system.

SCRUM/Agile

Great article here:
http://agile.dzone.com/articles/7-agile-best-practices-you

I've not enjoyed doing SCRUM on a greenfield project with a large set of fixed minimum requirements... Seems very unsuitable.

One great thing from SCRUM has been the sprint reviews where we decide things to try. Geeks are particularly bad at worrying to much.