Project Handover checklist

Yoi_Hanagata

A team of contractors working on MVC project are supposed to handover a project to me...they will complete the development and then I am supposed to work on the support or change requests issues. Other than handing over the code and going through the work flow of the project what I should be looking for? it was a scrum project so no actual documentation and I was not involved at the beginning of the project...

Any advice please?

ChRoMe

Yoi_Hanagata wrote: »

A team of contractors working on MVC project are supposed to handover a project to me...they will complete the development and then I am supposed to work on the support or change requests issues. Other than handing over the code and going through the work flow of the project what I should be looking for? it was a scrum project so no actual documentation and I was not involved at the beginning of the project...

Any advice please?

There should still be documentation, if there isint, get them writing it, now.

Yoi_Hanagata

ChRoMe wrote: »

There should still be documentation, if there isint, get them writing it, now.

What kind of documentation? we know the buisness case behind the project. this is supposed to be more of technical handover. The target would be a developer that is supposed to fix a bug or do a change request... any recommendations for technical doc, diagrams... I should be looking for?

ChRoMe

Yoi_Hanagata wrote: »

What kind of documentation? we know the buisness case behind the project. this is supposed to be more of technical handover. The target would be a developer that is supposed to fix a bug or do a change request... any recommendations for technical doc, diagrams... I should be looking for?

You should have a technical specification that describes the schema, the use cases, the staging/production environments etc.

I find it irritating that people belive that doing "agile" is an excuse for no documentation </rant>

Yoi_Hanagata

ChRoMe wrote: »

I find it irritating that people belive that doing "agile" is an excuse for no documentation </rant>

I agree...

I used to work using Waterfall metholgy and documentation was an important element

Feathers

A full test suite.

Mort5000

A "Known Issues" (and how to fix) list.
An "Oh yeah and we didn't quite finish that one minor feature because" list.

ChRoMe

Feathers wrote: »

A full test suite.

I'd take a technical specification over that as you never know when tests have not been updated. Having the specification signed off by the client is hard evidence on how the system should behave.

But yeah tests are nice

fergalr

Yoi_Hanagata wrote: »

A team of contractors working on MVC project are supposed to handover a project to me...they will complete the development and then I am supposed to work on the support or change requests issues. Other than handing over the code and going through the work flow of the project what I should be looking for? it was a scrum project so no actual documentation and I was not involved at the beginning of the project...

As Chrome says, you need at least some documentation.


More importantly, though, you want there to be a time period where you are doing your work on the project, during which the contractors have time budgeted to help you with the issues you run into.

So that when:
- you realise that module X is more complex than you thought, and
- the module X docs don't explain what you really need to know
then one of the contractors has time to write additional docs for module X.

Because you can't predict everything you need until you start.

If you think that isn't politically feasible, then, if the official handover is schedule for a particular time, just then ask for a 'preview' copy of all the software a while before that time, and start trying to do your work on it.

'Agile' isn't an excuse for having no docs; but it is about the product to the customer (you in this case) early, to allow issues be discovered and solved.

Feathers

ChRoMe wrote: »

I'd take a technical specification over that as you never know when tests have not been updated. Having the specification signed off by the client is hard evidence on how the system should behave.

But yeah tests are nice

Yep, didn't mean instead of docs. They go hand in hand - docs say what it should do, tests say what it does

As you said above, Agile isn't anti-documentation, but it says it values:

"working software over comprehensive documentation...That is, while there is value in the items on the right, we value the items on the left more. "

(My emphasis, though think that bit & the following sentence often gets missed by people)