ablg123:
不错，真不错，我看到了中国软件行业的星星之火。
有人为了文档而文档，这算什么，我见过把系统分析和设计当作“用rose画图”这样简单的事。
我认为具体问题应该针对特定情况具体分析，微软的文档不要求写得很细，这样能充分发挥程序员的聪明才智，不过前提是“微软的程序员都是训练有数的绝顶高手”。
如果前提条件不一样，没钱聘请高水平的程序员或管理上不完善，没有能力留住高水平的程序员，或不能提供条件让高水平的程序员充分发挥才能，只有一些没有创造力的程序员或对开发软件的知识掌握得不是很好，不知道什么样的软件该怎么做的人，项目必然会一团糟。
对于类似于体力劳动的工作相对脑力劳动来说，必须加强监督，否则资本家的利益就会受影响。而脑力劳动除了监督之外，更多的则是调动员工的积极性，这是对待高级员工和象"coder"一样的人的区别。
“生活依旧像在如磐的黑夜中航行，所以，依旧俯身划浆”，让我们共同为中国软件行业的崛起而努力！！！
ckwangfg:
看了软件管理和软件开发文档的讨论茅舍顿开！！！
我们公司做开发的只有几个人，所做的项目基本上是比较小的,以前的管理全部是通过口头交流,所谓的软件管理只不过是开发人员随手将程序的一些要点做一些记录．一旦公司的核心开发人员离开以后，由于没有相关的开发文档，整个项目就将搁浅和延误。
我现在致力于建立公司的软件管理规范和各种技术文档规范，结合公司的实际情况，不可能完全采用某个标准。整个过程要充分考虑到规范的实用性和可操作性，我没有这个方面的实际工作经验，希望得到大家的帮助，和大家进行深入的交流。
MY Email:ckwangfg@21cn.com
mobbs:
不到万不得已，我是不要求团队成员写文档的，实在烦人。
但是
1. 在需求阶段，我要求有详细的use case和activity diagram。
2. 在设计阶段，我要求有详细的activity diagram，sequence diagram和class diagram。
3. 对测试（之所以不说测试阶段，是因为我要求Test和Code同步），要求有测试用例（足够了）。
4. 对Coding，多写注释。
其它的文档，不写也罢。人手不够，没办法。
taopi2001:
所谓文档可以说是将程序员心里的想法用文字表达出来，将抽象的思想具体化，其过程也是程序员本身对于自己所作工程的理解上的一个深入。要说这种工作其实不一定要专职的文秘来做，一般程序员也是可以胜任的。当然，作程序员的文科功底一般好像都不怎么样，不过其实经过一段时间的训练，是没有问题的。学写文档对于增强自身思维的条理性、逻辑性、整体把握能力等都很有帮助。
说到编程和写文档，就让我想到了在大学本科生中参加过的全国数学建模竞赛。我国的数模竞赛现在已经是大学生中规模最大的竞赛了。三人一个小组，标准的分工是一人负责总体思想，如模型的总体结构、算法、采用方案等，一人负责编程，第三人负责论文的写作。其宗旨在于创新和团队精神。但是光靠这两点是不可能获得全国大奖的。要评选靠的是论文的水平。有的论文其中的建模和算法其实一般（相比较其他论文），但是写作上很有特色，遣词造句非常得当，涉及专业的地方运用专业的术语及思维方式来阐述，让该领域的专家也认为有一定的专业深度，而另一方面，又要注重尽量避免用生硬、绕口的词句，凡是涉及专业的地方，都尽量用通俗易懂的话进行解释，这样即使是一般大学生不用很费劲也能看懂。另外还要从论文的整体架构上考虑，内容的选取，表达的方式、顺序，采用的口吻，行文的特色，格式的规范等。而精
确时，对于每一个词字都要斟酌好久，完全的从读者的角度考虑，来写好论文。
当然数模的关键还是在于创新，要有其闪光点的论文才能有机会被选出来，而与同等深度的论文比较时，就是看写作的功底了。不过这是题外话，:)。
我刚开始学习UML，也说不出什么专业的东西，只能就自己的一些经历谈谈。写这些的目的在于——写一篇好的文档并不是一件容易的事，需要一定的专业素质和文学修养，但我相信一般程序员经过正规的训练是完全可以办到的。
以上一点拙见，仅供参考。
文章来源于领测软件测试网 https://www.ltesting.net/
