Document, is also a text of documentation, "Agile Modeling", I feel very good.
I am afraid to lose all people and lead to excessive documents.
Many organizations are afraid to lose their software development team, because once the team is all or most of the people leave, it is very important and often there is no chance to leave with them. Common lost teams have:
Some competitors have taken the team from you to start their own project developers habitually jumped to jump, never stay in any company. After the team just completed the project, you intend to disband them.
In order to solve this problem, the common strategy of senior management is to require a lot of documentation. They believe that once the team has lost this team, it can make another team and give the document to the newly composed team. This approach sounds good, but it is often proven to have a role in actual work. First, although the documentation may help the current situation, the new team is unlikely to believe it, they would rather get a "terrain" of the system, then drill into the code to get details. In other words, they may use the detailed documentation to be just to include a small part of the overview document. Second, this strategy will often become a self-real prophecy, because they are afraid that they will leave, you can force developers write excess documents, but because of your bureaucracy, lack of concern for their trust and lack of software development They will really decide to leave.
In this case, I will work with people who ask for documents and try to discuss a more agile approach. My experience is that the high-quality source code supported by the concise overview document and the appropriate contract model can provide a sufficient system description for developers who need maintenance and enhanced systems in the future.
