软件开发的边界（上）
这本书名为软件开发的边界--管理成功的项目（The software development edge:Essays on managing successful projects)大概算是本优秀的“飞行读物”。全书共六个部分，我算大略读完了前两个部分。
这里说摘录下我深有所感的话语，当然有自己的感悟在其中，语言与原文可能不同。
第一部分：综合管理
1.迭代式问题解决
“ 将它写下来”其实是这部分的核心，因为只有这样，每次的迭代才能减少不必要的工作。我们能够循序渐进地构造“最终文档”，而不是费时地不停修改，不停重新构建。
2.选择团队
我们似乎很容易忘记这一点，没有组建好的团队，成功十分困难。而这样的团队应该是身为队长的我们去自己寻找组建的，那种等待队员加入的行为似乎比较愚蠢。
3.监控与保留记录
这是为强调第一点，一只铅笔与一本笔记本，你应该知道要干什么吧。
4.成功的要素
“在需求大变化之前迅速完成开发”，要点是速度。
“了解什么时候应该大声站出来什么时候应该保存沉默”，要点是勇气。
“团队保存以一个清晰的目标为中心”，要点是清醒。
5.领导者鼓舞：管理者授权。同时成为两者则你需要愿景进行沟通并了解细节。
最佳的领导者应当向团队传达一个共同的使命--也即一个愿景，团队其他热受此感染并为之而持续努力。
管理者则是项目障碍的排除者与谈判代表。
第二部分：软件的差别
1.开始就着手于“简单问题”会占用更多时间，以至没时间解决风险更大的问题
如果搞定绝大多数风险，似乎我们会更有自信来申请更多时间，否则，你会站在不利的谈判位置。
2.迭代式项目收手时商业损失更小
关键在于投入人力更少，这是由于项目早期配置的是精英团队，由他们开发原型。
3.如何解释uml
使用几何图，电路图，确实比较专业，既显示了自己的深厚基础（初中知识），又比较好沟通有趣味（人就是爱回忆，尤其是自己辉煌的历史）。
4. 动物游戏
规则如下：
5.流程的严格
1.要有明确的发布标准，即完成标准，并且让每个成员都了解它。
2.找到在项目上坚定，技术上胜任的人，让他引导我们走出浅摊。
3.完美是优秀的大敌，你发布的判断关键是开始每个人都明确的发布标准。
4.注意脚本，他们可能缺少良好的设计。
好吧，先就这些，下次继续。
这里说摘录下我深有所感的话语，当然有自己的感悟在其中，语言与原文可能不同。
第一部分：综合管理
1.迭代式问题解决
“ 将它写下来”其实是这部分的核心，因为只有这样，每次的迭代才能减少不必要的工作。我们能够循序渐进地构造“最终文档”，而不是费时地不停修改，不停重新构建。
2.选择团队
我们似乎很容易忘记这一点，没有组建好的团队，成功十分困难。而这样的团队应该是身为队长的我们去自己寻找组建的，那种等待队员加入的行为似乎比较愚蠢。
3.监控与保留记录
这是为强调第一点，一只铅笔与一本笔记本，你应该知道要干什么吧。
4.成功的要素
“在需求大变化之前迅速完成开发”，要点是速度。
“了解什么时候应该大声站出来什么时候应该保存沉默”，要点是勇气。
“团队保存以一个清晰的目标为中心”，要点是清醒。
5.领导者鼓舞：管理者授权。同时成为两者则你需要愿景进行沟通并了解细节。
最佳的领导者应当向团队传达一个共同的使命--也即一个愿景，团队其他热受此感染并为之而持续努力。
管理者则是项目障碍的排除者与谈判代表。
第二部分：软件的差别
1.开始就着手于“简单问题”会占用更多时间，以至没时间解决风险更大的问题
如果搞定绝大多数风险，似乎我们会更有自信来申请更多时间，否则，你会站在不利的谈判位置。
2.迭代式项目收手时商业损失更小
关键在于投入人力更少，这是由于项目早期配置的是精英团队，由他们开发原型。
3.如何解释uml
使用几何图，电路图，确实比较专业，既显示了自己的深厚基础（初中知识），又比较好沟通有趣味（人就是爱回忆，尤其是自己辉煌的历史）。
4. 动物游戏
规则如下：
5.流程的严格
1.要有明确的发布标准，即完成标准，并且让每个成员都了解它。
2.找到在项目上坚定，技术上胜任的人，让他引导我们走出浅摊。
3.完美是优秀的大敌，你发布的判断关键是开始每个人都明确的发布标准。
4.注意脚本，他们可能缺少良好的设计。
好吧，先就这些，下次继续。
