What documentation for handoff?

A few things I can think of:

Get them to demo through the major features and go through the code - this is to show you it works but also talking through the code will often air any assumptions made etc
Ask about code coverage and what missing test cases there are
Ideas behind any architecture / design patterns that have been used
Known bugs - There will almost certainly be some
Recent bugs they have found and how they were fixed - It sounds odd but it gives you an idea of the kind of issues that were run into and how to fix them
Feature ideas - Sometimes when working on code you have an idea on a feature that will be easy to implement etc
Tech debt - If they are on a deadline they will cut some corners to get things finished. Get them to show you the bits they know isn't quite right
Improvements they would make - Slightly different from tech debt but important
Bottlenecks - Similar to tech debt but more specific, do you know of any spots (DB queries etc) that are slow

When asking all of these bits try and make it clear it's really not for blame and you understand there will be issues etc. You want the devs to be as open as possible as what's done is done and issues won't fix themselves. It's better to know about them.

Also if you can / want to work on the project yourself, get your own development environment setup and working before the handover. Make sure all the tests pass to prove it is working

Say something nice to micav…

2
A few things I can think of:
- Get them to demo through the major features and go through the code - this is to show you it works but also talking through the code will often air any assumptions made etc
- Ask about code coverage and what missing test cases there are
- Ideas behind any architecture / design patterns that have been used
- Known bugs - There will almost certainly be some
- Recent bugs they have found and how they were fixed - It sounds odd but it gives you an idea of the kind of issues that were run into and how to fix them
- Feature ideas - Sometimes when working on code you have an idea on a feature that will be easy to implement etc
- Tech debt - If they are on a deadline they will cut some corners to get things finished. Get them to show you the bits they know isn't quite right
- Improvements they would make - Slightly different from tech debt but important
- Bottlenecks - Similar to tech debt but more specific, do you know of any spots (DB queries etc) that are slow
When asking all of these bits try and make it clear it's really not for blame and you understand there will be issues etc. You want the devs to be as open as possible as what's done is done and issues won't fix themselves. It's better to know about them.

Also if you can / want to work on the project yourself, get your own development environment setup and working before the handover. Make sure all the tests pass to prove it is working
pyepye

·
6 years ago
·
1. 1
  
  thank you! thank you! .. that's really helpful feedback.
  
  micav
  
  ·
  6 years ago
  ·