首次采用敏捷方式进行开发，我想把我们的做法与大家分享下，同时希望大家指出我们的不足和需要改进的地方，让我们的项目进行的更顺利，目前项目已过三分之一，客户比较满意，还算顺利。
项目简介：一个DMS小项目，预计时间14人月.客户需求不是很明确，想一边做一边提，适合引入敏捷开发（实际上用户的需求也一直在变，当他们看到每次的small release时都会有新的想法）。
Team主要成员：一个team leader（兼BA职责），两个工程师，一个UI设计师。
成员主要职责：team leader主要负责召开会议，明确每天的开发任务以及项目的总体大概进程，保持团队成员清楚的知道项目目前的状态，保持团队沟通顺畅让团队保持高昂的士气。还有个作用是敢于对项目的成败负责（当然团队每个成员都有责任）。工程师的主要职责是开发，设计师主要职责是UI设计。
开发环境配备：硬件：两个PC机两个显示器两套鼠标键盘（工作的时候切换到一个PC机上pair编程，共享一个主机，用转换器使一个主机上面接两个显示器，两套鼠标键盘，这样就不用挤在一个显示器前抢一套鼠标键盘pair了），一个测试服务器，上装svn服务器和cruisecontrol来管理代码和实现定时自动化测试（测试一定要自动化，这样可以让机器来干它喜欢并擅长干的事情，让工程师专注自己的业务；我们使用yahoo的一个模拟熔岩灯来监视测试结果。），一个发布服务器，客户可以远程及时试用后给出反馈意见和建议。
开发简介：
一、迭代（Iteration）和发布（release）计划
由于项目开发人员比较少，我们决定采用最短的迭代周期（一周），每个迭代前由BA评估story需求风险，开发人员评估story技术风险和cost，选出能在本轮迭代周期中完成的任务；每个迭代结束来一次small release
二、我们对实现XP价值观所做的努力
1、 沟通（communication）
再怎么强调沟通的重要性都不为过，尤其是在软件行业。所以在XP中communication被放在首位也不为奇。
我们项目组每天早上开一次Standup Meeting，通报彼此昨天做了哪些工作，以便让开发小组所有人了解各自的工作情况，然后确定今天要做的task，目前公司地牌儿还不够辽阔，我们小组还没有足够的地儿挂白板，就把story和task写在Excel表里面；每个星期一的早上（迭代开始前）会有一个IPM（迭代计划会议），主要内容是大概确定本次迭代周期开发需开发的story，工程师评估每个story完成所需的时间开；每个周五下午（迭代结束前）会有一个Retrospective（迭代结束前会议），会议主要内容是对本次迭代做的好的方面以及待改进的地方进行总结；工程师pari编程。
2、 简单（simplicity）
3、 反馈（feedback）
没有持续的反馈，敏捷将无从谈起。customer、accompanier、team以及test result的反馈给我们向用户交付真正需要的系统提供了保证。我们的BA每天和客户沟通，掌握用户真正、迫切需要的功能和需求。由于我们的系统是一周发布一次，所以客户也能在很短的时间内知道完成的新功能，并及时提出改进意见和建议（其实客户的需求也是一直不停地在变的）。
4、 勇气（courage）
为了使代码更加清晰、质量更好，对工作代码进行大范围的修改和重构需要勇气，把某些代码彻底抛弃需要勇气，告诉客户无法再添加新功能需要勇气。我和accompanier目前都还有这样的勇气，希望系统越来越大、代码越来越多的时候还有这样的勇气。
三、测试驱动开发（TDD）
关于TDD我们一直在尝试寻找更爽的方法，目前采用的是webwork、spring、hibernate的组合框架，在大脑里无意识的已经存在了三层结构，我觉得采用TDD，这三层结构应该是最后被驱动出来产生的，而不是一开始就定好三层，然后再TDD编码。
我们目前是分别对每层进行TDD，还是觉得service层驱动最有成就感，看到green bar 就令人兴奋，action层老是mock来mock去的走流程实在属没啥意思。
最近又看到了
使用Selenium和Castle进行测试驱动开发 ，本想采纳，但是使用Selenium进行至顶向下的驱动的话通过一个测试所需的时间太长了，我是对
green bar有点上瘾了的人，不能忍受那么长时间的red bar，怀疑它会对偶的身心健康造成影响，所以就作罢，还是由底至上的方法使测试通过的实践最短，不知道各位对这样的三层结构是怎么TDD的？
Robert C. Martin大叔的TDD三条军规如下：
1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。
2.只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
3.只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必须停下来开始编写产品代码；但是到了原则3，你就只能编写产品代码，直到让测试编译成功或通过断言为准。
这三条军规我觉得太经典了，完全做到了才算TDD做到位了。
前几个迭代周期我们没有采用TDD,功能代码写了然后写测试，两个月后对系统进行了一次比较大的重构时，所有的测试都通过了，但是发布上去了还是由bug，所以这种干法是不行的，测试不能达到令人满意的覆盖度。TDD完全可以使测试达到令人满意的覆盖度。基本上只要测试通过了，就能确定重构没有对系统造成影响。
四、验收测试（acceptance test）/客户测试(customer test)
验收测试我们是放在最后做的，由BA代客户写验收测试，工程师使用selenium 进行验收测试的实现，我们发现selenium对frame支持的不是很好，有这儿我想到采用至顶向下如：
使用Selenium和Castle进行测试驱动开发 进行TDD的话是最合理的，不知道大家是不是这么做的？
五、pair 编程
pair的好处我就不说了，试过了就知道了。
分享到：
相关推荐
总的来说，《SCRUM敏捷项目管理》这本书是学习敏捷开发和实践SCRUM框架的重要参考资料，无论是对于初次接触敏捷的新人，还是寻求进阶提升的专业人士，都能从中受益匪浅。通过阅读这本书，你可以深入了解敏捷开发的...
《敏捷软件开发：原则模式与实践》一书的出版，填补了当时该领域书籍的空白，首次将敏捷方法、模式和当代软件开发的基础知识融为一体。本书的出版，为软件开发人员和管理人员提供了一本全面的参考指南，它不仅仅是...
总的来说，这个压缩包提供了丰富的敏捷开发学习资源，涵盖了从理论到实践的多个层面，无论是对于初次接触敏捷的新人，还是希望深入理解和提升敏捷技能的从业者，都是非常有价值的参考资料。通过研读这些材料，你将...
在项目开发过程中，对于初次接触这一领域的朋友们来说，可能会...初次开发者应当逐步掌握这些技能，不断实践，才能在项目开发中游刃有余。希望这份"项目开发指南"能成为你宝贵的参考资料，陪伴你在开发道路上稳步前行。
### 敏捷过程实践 #### 知识点一：敏捷实践背景与挑战 - **背景**：本资料来源于2017年阿里巴巴举办的在线技术峰会——首届阿里巴巴研发效能嘉年华。会议由阿里巴巴研发协同RDC与阿里云云栖社区共同主办。 - **...
9. 适应性规划：敏捷项目通常采用迭代和增量的方式进行规划，每个迭代都有明确的目标。随着项目的推进和新信息的出现，计划可以灵活调整，以适应变化。 10. 自组织团队：敏捷团队是高度自组织的，成员共同决策，...
这本指南主要关注敏捷项目管理方法，如Scrum、XP（极限编程）、Kanban等。敏捷方法强调灵活性、迭代开发和持续改进，以应对快速变化的需求和市场环境。它包括敏捷价值观、原则、实践和框架的详细解释，对于希望采用...
《CodeIgniter1.7敏捷框架开发》一书由Jose Argudo Blanco与David Upton共同撰写，由Packt Publishing在2009年11月首次出版。这本书旨在帮助PHP开发者提升编码效率，通过免费、紧凑且开源的MVC框架——CodeIgniter...
Scrum作为敏捷开发模型中的一种，由于其灵活性和高效率，被广泛应用于软件开发项目中。然而，Scrum实施过程中也会遇到失败的情况，这通常由于团队对Scrum原则理解不足、缺乏适当的培训、文化和组织结构的不适应等...
### 敏捷软件开发模型——Scrum概览 #### Scrum 的起源与发展 Scrum作为敏捷软件开发模型的一种，其历史可追溯至1986年。这一年，竹内弘高和野中郁次郎提出了一种全新的整体方法，并将其与橄榄球运动中的“Scrum”...
Scrum的作用在于让开发实践的相对效能得以显现，以便持续改进，同时为复杂产品的开发提供一个可预测且风险可控的框架。 ### Scrum的核心原则：透明性、检验与适应性 Scrum建立在经验主义过程控制理论之上，通过...
- **概念提出**：1986年，竹内弘高和野中郁次郎首次提出了一种新型的整体性开发方法，因其与橄榄球运动中的“Scrum”动作相似而得名。 - **理论成型**：1991年，DeGrace和Stahl在其著作《Wicked Problems, Righteous...
在2007年ThoughtWorks举办的敏捷大会上，Pramod Sadalage分享了关于敏捷数据库开发的相关理念和技术实践。这一讲义不仅为当时的软件开发者提供了宝贵的指导，而且至今仍对现代软件开发流程具有重要的参考价值。 ###...
通过深入学习这个框架，你可以了解如何更有效地规划和管理敏捷项目，如何更好地与利益相关者沟通，以及如何利用敏捷实践来适应不断变化的市场需求。无论你是初次接触敏捷，还是希望深化对敏捷方法的理解，这个资源都...
首次有超过半数的营销人员自认为是敏捷营销的实践者。在营销行业中，常常存在着长时间工作、不切实际的期望和无名英雄主义，敏捷框架的逐渐采纳，强调可持续的节奏和团队授权，成为了一种美好的转变。 报告建议，...