敏捷

对于敏捷开发，我前面其实已经有很多文章提到了，再次强调下敏捷的核心思想个人理解为三个重要的方面。其一是需求的条目化并以需求点进行的全程追踪和跟踪；其二是短周期迭代；其三是基于持续集成思想的进度和质量可视化。

 

对于敏捷开发本身，对于很多内容我仍然坚持自己的观点，具体如下：

 

对于大型全新系统的开发，如果是以底层数据为核心的业务系统，则不能单纯的应用敏捷开发。这类系统对全局业务建模和数据建模的要求会更高，以保证架构完整性和概念一致性。而不是任务已经并行分配下去，出现问题了再去做调整，敏捷的短周期迭代不是做这个用的。这类的总体设计个人理解主要包括了子系统或模块的划分，接口的识别，底层全局数据概念模型，这些必须一开始就要搞清楚。

 

对于新组建的团队，团队成员相互不了解或能力差异过大，团队没有历史项目实践的磨合和经验积累，没有比较成熟稳定的技术框架时候，建议慎用敏捷开发。敏捷开发是迭代计划和版本，但是当前的迭代版本仍然是需要我们能够做出合理的估算，而不是存在大量的不确定性。

 

敏捷开发里面有一个重要的实践，即CI持续集成，这里面会涉及到单元测试，但是这不是XP极限编程里面的TDD测试驱动开发。有人认为没有采用TDD就不是敏捷开发是相当教条型的错误。即使再CI持续集成和每日构建，冒烟里面我们仍然是多种做法。一种是只写能够冒烟测试通过的少量单元测试用例，一种是只对按界面展现和逻辑实现横向分工的团队要求对于技术组件接口的朝外提供要首先写单元测试代码。TDD测试驱动开发真正能够实践好能够坚持下来的多内基本很少，这个根本就不是熟悉了TDD就能降低工作量的问题，其次对于希望通过写测试代码来想清楚需求的方法不推荐，需求是需要可验证但是不代表必须测试代码能够写清楚需求才可验证；再次单元测试往往比较难到UI和展现层，即使有Junit自动跑了还是需要人工测试，这个工作量并没有省。

 

敏捷方法论本身的思想是重视沟通和协同，减少不必要的文档，因此敏捷并不是没有文档。当前还是很多人认为通过实施敏捷方法可以不写文档，认为文档没有用处这又是走到一个极端。那么什么叫不必要的文档？个人理解其一已经在项目团队里面形成规约性质的内容，则已经有历史规约可以追溯到；其二是各种日常沟通协调中形成的讨论，记录，白板等内容，不会太注重规范格式但是要能够记录下来；其三是对于他人看你的源代码就能够理解清楚的东西不必再文档化。

 

想到哪里就做到哪里，拿着需求点就马上去做，出现问题了不断的返工和修改还美其名曰重构，通过敏捷为幌子来逃避写文档，虽然第一个迭代快速能出来但是产品能够真正上线运行进度周期反而成倍增加，再者或强调我们是敏捷每周40小时工作时间。这些都是中敏捷的毒太深，还是那句话，传统的类似瀑布的软件生命周期模型都没有应用好，能够把敏捷应用好是不可能的。团队人员本身编程能力和经验就差距较大，对自我能力和生产率评估也很弱，相互也不了解情况下能够简单的通过敏捷来纠正这些问题也是不可能的。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密