开文

     今天工作中经过讨论做出决定——重构Platform。

问题

     怎么会导致重构Platform？

宣言和原则

     罗列出敏捷开发的宣言和原则，也许能说明遇到的问题。

宣言

1. 个体和交互胜过过程和工具。
2. 可以工作的软件胜过面面俱到的文档。
3. 客户合作胜过合同谈判
4. 响应变化胜过遵循计划

原则

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。负责人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——使未完成的工作最大化的艺术——是根本的。
11. 最好的构架、需求和设计出自于自组织的团队。
12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后对应地对自己的行为进行调整。

检查报告

　　首先，我们错过了第1条和第3条原则。尽管在开始，使用了一些集成工具，想以工具来指导持续的自动集成和交付，但该工具效果较差，有较多不满意的地方，包括稳定性，时常发现不能正常的从版本管理工具中获取代码。后来采用人工集成，收到效果，这样集成的周期能维持在周。
　　其次，我错过了宣言第2条。并不否定文档，而是文档数量应该得到控制，之前我试图完成完整的文档，并且试图维护这些文档，发现『编制众多的文档需要花费大量时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大、复杂的谎言，会造成重大的误导。』(摘自《Agile Software Development – Principles,Patterns, and Practices》)，最好的教训是在做Finance那块东西，我发现在做文档的时候，貌似在编写初级会计教程，最后不得不放弃。而在最近的开发体验中，发现原型图是很好的“初期文档”，而初期编写的项目计划可能就会成为“庞大的、复杂的谎言”。
　　最后，我们做的够好的地方。项目开发期间，我们和业务人员保持良好的沟通，天天都在一起工作；同时，我们获得了最大的信任和激励；我们采用传递信息的方式，是面对面的交谈，这是最具有效果并且富有效率的；几乎很少加班，为了保持一个长期的、恒定的开发速度，这条是很重要的   ；做简单的设计，这个是John最推崇，也是我比较欣赏的一点。

最后

　　相信之后的开发工作会有更多的实践体验，会有更多可以学的东西，包括很久一直想，但从未体验，近几个月来最大的收获:Be Professional