首次敏捷项目开发实践

你是指人力成本吗？不会高的，你能连续8小时不停工作吗？一直都是高效工作？


当然成本不会高还不是它的主要优势，prai还有助于简单设计，风险控制等

pair方面没那么详细，讲了很多书中提到的东西

另外支持adamzhao:

呵呵，是的，一旦走出了第一步就很难回头了

实施敏捷是公司发展的需要，客户也比较青睐

公司以前也一直都提倡敏捷，但苦于找不到路

我们公司领导对实施敏捷也是大力支持的

给于了尽可能的硬件配置和环境布置

现在公司的开发方式处于转型期

我们小组是第一个采用敏捷的，接着第二个项目组也开始了

再接下来的项目的开发方式都会转到敏捷上来

关于如何让大家乐意接受，我想只要尝试过的人都再也不会拒绝了

TDD会给人一成就和满足感

pair编程会令人愉悦，虽然有点累，但是心里感觉比较快乐

lz在team里面是哪个?

我属于pair programing中的一个

有多少项目用这样的开发方式

不知道这个项目复杂度如何，也不清楚你们的人员水平，所以我想问楼主个问题，看看能不能讨论讨论。

1.楼主能否大致量化一下一到五这五点的重要程度吗，比如TDD带来多大好处，结对带来多大好处？如果砍掉TDD，砍掉结对编程，对项目会有什么影响呢。进一步说，如果只保留一个“充分沟通”，尤其是和客户的沟通是否就足够了呢。
我的经验里，做到有效的TDD和有效的结对是非常困难的，尤其在比较简单的项目里，太多TDD都是在走流程，闭着眼睛都能写，真正值得写的测试用例并不多。也有太多结对最后都在项目进度压力增大的时候流于形式。所以希望楼主也能举出例子，说明敏捷真的给你们带来了好处。

2.客户对1周一个release的看法如何？有不少客户时间都很宝贵，会不会一周一个release，客户会觉得开发人员太随意，没有仔细考虑。

3.“客户比较满意”这个感觉是怎么得来的？因为有太多客户在签终验报告之前都是“比较满意”了

以上

这个项目复杂度一般，技术本身没有什么复杂度，工程师水平还是不错滴。其实这个项目上个星期已经差不多结束了，预计的是12人月左右，其实大概只花费了8人月，由此可见效率还是比较高的（至少效率没有下降）。客户打算再继续投资扩展业务。

1.这五点其实在敏捷开发的流程中都算重要的，沟通应该是排在首位的，pair使沟通变的容易和快速（如果开发人员有七八个的话，pair在沟通方面就更重要了，可以每半天换个pair，保证项目的每个模块每个团队成员都是熟悉的，而不是某个模块只有某个开发人员熟悉），当然pair的好处还远不止在沟通方面，在提高开发人员的专业技能方面也是大有好处的，七八个人的团队每天互换着pair对于开发人员的成长也是非常快的，另外重要的有点是pair工作很开心，不会觉得累，基本不会走神，效率比较高。我不知道你说的“充分沟通”是怎么进行的？每天和客户沟通？开会讨论？另外想问一下你们在有效的TDD和有效的结对碰到的困难是什么？TDD带来的好处是显而易见的，保证程序都是可测的，bug极少，代码比较优美。其实很多业务逻辑不测到位是很危险的，只靠人手工测也是不容易测出来的。

2.客户对1周一个release还是非常配合的，其实我们这个系统开发到第二个月的时候客户已经投入试运行了，客户基本每天都登录测试，而且还有大量的使用人员（一万多个导游，几百家旅行社）都同时在测试使用，反馈也是非常快的，我们很早就在系统里面加入了反馈的功能，使用人员可以随时提出修改意见和bug报告。

3.客户比较满意是客户自己的感受，客户在使用过程中也提出了一些超出项目以外的要求，我们都尽量满足了，客户要继续加大投入也可以看出客户是满意的。

咱们还是就这3点讨论，你们做的相当不错呀，在任何一个公司里做创新都是相当困难的。

1.你说的pair的好处，主要是保证每个成员都熟悉程序以及互相学习，但这个对项目未必有好处。我的感觉是这种规模的项目不pair，项目的工期不会受到影响，甚至可以缩短。当然说pair利于团队建设，从长远看来有好处，这个是肯定的，我也有切身体会。是不是你们领导很看重团队建设，所以允许你们进行pair。我们这边说pair就很困难，因为工期实在太紧，又拿不出来很好的证据说pair可以提高开发速度，没法量化评估。
往大了说，我觉得结对编程、同行评审与其说是为了项目质量有保证，不如说是对团队建设有好处，结对和评审都是加强团队内部沟通很好的手段。

TDD，你说TDD保证程序都是可测的，但这个测试有多大的意义呢，对于复杂度不高的程序，如果业务逻辑都是增删改查加点判断，用不用TDD都没区别。所以我还是说不知道你们的程序到底多复杂。我们这边有些东西确实很复杂，用TDD效果就很好，但是复杂的毕竟是极少数。
我不清楚你如何区分“确实应该用TDD”和“为了TDD而TDD”，或者说，如果你们不TDD，项目工期会延长多少，或者会缩短多少呢，你能否量化评估？这也是我说的我们试图进行有效TDD时遇到的困难。当然我不是想证明给领导说TDD是有效的，我只是希望自己做的事是有效的，时间没有浪费。

充分沟通在任何时候确实都是最重要的，包括团队内沟通和团队与客户的沟通。沟通的形式可能是开会，或者给客户发需求文档，当然这个形式不是很好。也可以用给客户看原型请客户提意见的方式沟通，或者你们一周一个release给客户用也是非常好的沟通。沟通的重要性我觉得远远大于其他几点之和，保证项目成功的大部分因素都是靠它。

2、3.这个我明白了，你们客户确实非常配合。不过这么大量的人员支持你们发布和测试，客户关系做的可够好的。客户那边的培训是怎么做的呢，1万多个导游，1周一个release，培训成本肯定是无法负担的。是否软件功能非常直接地面向业务，不用培训也会使用呢。我的经验里，频繁的release，对客户来说最大的困难就是培训成本无法负担。

我们现在做的产品3个月才有一个release，比较无奈，因为子系统太多了（十几个），又没有办法一次只发布一个子系统给客户使用。尤其是一个迭代周期的中晚期时间内出现了紧急需求，必须在该周期的release中实现的时候，更是雪上加霜。每个release前写培训文档也是个让人头大的活，单单是培训实施人员一周时间就不见了。如果你们将来用敏捷方法开发产品，希望到时候咱俩再讨论一下release这个事情，我现在也是无奈呀，3个月一个release，什么事情都敏捷不起来了。

我们公司领导比较重视团队建设，提倡敏捷开发，pair是必须进行的，pair短期内是不能提高开发速度的，但是不会降低开发速度，从长期来看，pair能更快的提高开发人员技能，从而自然也会提高开发效率。



测试的意义是很大的，测试是重构和功能修改和扩展的基础，没有测试或者是测试不充分，修改起来可以说是噩梦了，如果全部是增删查改的话先写测试跟先写功能再写测试的效果貌似差不多，但是有几个项目是这样的呢？我们这个项目用户角色有5种，以后还要加一种，角色之间的交互是比较强的，业务不难，但是还有很繁琐的，用TDD效果也是很好的，如果不TDD肯定会花更多时间才能比较完美的完成。
我不知道为什么你一直说“为了TDD而TDD”？既然TDD有那么多好处为什么不从心里接受，让它成为自然开发行为，成为习惯？如果不TDD，我不敢说工期会延长，但是工期肯定不会缩短，而且项目和代码质量上面肯定会大打折扣。我觉得仅仅为了“提高代码质量”这一条理由就应该TDD。



这个确实。



培训我们还没有专门做过，只针对最大客户给予指导，很多功能都是比较容易使用的，碰到他不能理解的，我们就向他们说明。每次的功能添加还有一个使用帮助文档。其实我们还提供了一个所有使用人员在线交流的模块，很多问题都是用户相互指导。当然不可能每次release都来一次培训，这样培训成本肯定太高。



系统比较大的话，培训肯定需要适当投入的，三个月一个release时间可能有点长，我们公司还有一个项目组是开发产品的，大概8个人，也是完全采用敏捷方法，貌似业务比较复杂，现在在尝试DDD。你们能否把release的周期减到一个月？三个月时间似乎有点漫长。