摘要:
!@计划!@#初始探索在项目开始时,开发人员和客户会尽量确定出所有真正重要的用户素材。然而,他们不会试图去确定所有的用户素材。随着项目的进展,客户会不断编写新的用户素材。素材的编写会一直持续到项目完成。(这一点我赞成,不可能一开始什么都确定下来,会慢慢完善)大素材要分解比如用户能够安全地进行存款、取款、转账。这是一个大的素材。分解之得到:(思维导图)用户可以登录用户可以退出用户可以向其账户存款用户可以向其账户取款用户可以从其账户向其他账户转账随着项目的进展,由于可以度量每次迭代中已经完成的用户素材点数,所以对于速度的度量会越来越准确。(这一点对于做事和读书同样有效。)!@#发布计划如果知道了开 阅读全文
posted @ 2013-10-11 23:24
TBHacker
阅读(388)
评论(0)
推荐(0)
摘要:
!@极限编程1.客户作为团队成员2.用户素材为了进行项目计划,必须要知道和项目需求有关的内容,但是无需知道得太多。看到新系统的问世是关注需求的最好时刻。3.短交付周期每两周交付一次可以工作的软件。每次迭代结束时,会给涉众演示迭代生成的系统,以得到他们的反馈。4.验收测试5.结对编程所有产品代码都是由结对的程序猿使用同一台电脑共同完成的。结对人员的一位控制键盘并输入代码,另一位观察输入的代码并寻找代码中的错误和可以改进的地方。(这,有点难,就自己写完改吧。或者写完了,让别人来评价)6.持续集成svn的使用7.可持续的开发速度8.开放的工作空间程序猿们处在适于激烈讨论的位置上。这一点我们公司做的比 阅读全文
posted @ 2013-10-11 23:05
TBHacker
阅读(243)
评论(0)
推荐(0)
摘要:
!@敏捷开发!@#敏捷开发引入许多人都经历过由于没有实践的指导而导致的项目噩梦。缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。一个由平均水平程序猿组成的团队,如果具有良好的沟通能力,将要比那些虽然拥有一批高水平程序猿,但是成员之间却不能进行交流的团队更有可能获得成功。过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言。客户合作胜过合同谈判。告诉开发团队想要的东西,然后期望开发团队消失一段时间后就能 阅读全文
posted @ 2013-10-11 22:23
TBHacker
阅读(361)
评论(0)
推荐(0)