我的推文讲的很乱.故改PO文来回 ><
※ 引述《abadcafe (abadcafe)》之铭言：
: 首先, 这个世界上并没有一个"大陆版快速迭代waterfall".
: 全世界只要讲到"快速迭代模式", 基本上就都是指的我所描述的那种快速迭代模式. 无论
: 是在北美还是在欧洲都一样. 这并不是大陆的特产. 欧美业界提出并实行这个模式很多年
: 了. 详见: https://en.wikipedia.org/wiki/Iterative_and_incremental_development
: 而快速迭代与waterfall的分别, 你需要注意其前提: 分而治之. 如果没有需求的分解, 不
: 管你怎样爆肝, 也不可能把waterfall压缩到很短的周期.
: 传统的waterfall并没有这个步骤, 他们会在整个系统设计完成之后才开始coding, 整个系
: 统coding完成之后才开始testing. 这才是waterfall被诟病的地方.
: 这里我要再强调一次, 在快速迭代模式中, 每一个迭代过程你既可以使用waterfall, 也可
: 以使用TDD或者别的什么, 这并不冲突. CI也是一样.
: 另外, 关于敏捷我要多说一句, 敏捷不是银弹. 真的在大项目中实行一遍TDD, 你就知道
: TDD的问题在哪里了: 1. 工作量暴增. 2. 面对频繁变化的需求, 你会很快厌倦编写那么多
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
: 测试代码然后又看着这些代码作废. 这都是人力的浪费. 你看看前几年TDD有多火, 近几年
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
不好意思.以下恕删 @@
(以下敏捷性开发 以SCRUM来论)
首先 TDD(测试先行) 绝对会让工作增加(以产品周期初期来看的话)
(如果以都是会写TEST的角度来看的话.其实工作量差异应该很有限才对)
但其所带来的品质有办法对应其工作量增加的"成本" (人力/时间/钱/资源 等等)
再者.敏捷性开发的需求不是可以无限量改的.
因为敏捷性开发强调"成本固定".
在成本固定的情况下.在每次哩程碑会议验收完成后可以提出需求变更.
但需求变更也是要算成本的.例如:
原本总成本是 N 然后消费完成会变成 K 个功能.
而假设提出需求变更的对象内容需要成本是 N/10 那相对的
就需要进行舍弃未完成功能的 K/10..换句话说 总成本是固定的.
(这也我认为RD/QA推广敏捷性开发的主要好处之一)
简单来说.无限凹RD/QA加班.这种做法就已经失去敏捷性开发的主要意义之一.
另外回到TDD. 这部份除了可以应用在工程师自身的开发流程外.
如果团队使用敏捷性开发.那TDD就可以应用在整个产品/专案.
(因为在会议上就会进行功能规格定义所以 RD/QA 可以同时作业...)
而大量使用TDD的好处.在 专案/产品 部份可以提高 哩程/全部 的验收品质外.
更可以减少因为RD无限压线.而造成凹QA无限加班的情况 =_= (毕竟不能产出尸体)
而在RD 个人/团队 大量使用TDD的好处.除了可以提高程式品质外.
还可以训练RD的设计品质 (因为设计完成才能写TEST 换句话说 不能边写CODE边想设计)
而且如果再搭配自动化的协助(EX: CI)
也可以降低因为 TDD或UNITTEST 所增加的开发成本.
因此不管是TDD还是敏捷性开发对开发 产品/专案 应该都有一定的助力才是 ~_~a
以上是我所理解的推广型Scrum和TDD...也是我推文所要讲的东西 Orz...