methodology
有高手出来讲解比较一下各种编程的methodology吧，比如agile, waterfall等等。看到oursteps上有人讨论，这里很多人都可以出来讲讲吧。 http://en.wikipedia.org/wiki/Software_development_methodologies#Waterfall_Approach
学校学过的，我们基本上都是waterfall和agile。 原帖由 GPS 于 8-10-2010 23:29 发表 http://www.freeoz.org/ibbs/images/common/back.gif
有高手出来讲解比较一下各种编程的methodology吧，比如agile, waterfall等等。
看到oursteps上有人讨论，这里很多人都可以出来讲讲吧。
这题目有点大。说实在的，如果不是专门在这方面研究，并在强大的机构里实践数年到十数年，
这东西还真不好说。如果要辩论各种SDLC methodologies，最后只会成为一个空谈的吹水贴。
倒不如分享一下自己经历和喜欢的开发流程，提出自己认可的观点以及自己有疑问的地方。
我个人喜欢实实际际的做事情，相信的基本教条是simple is the best。同时，在programming paradigms
方面，我比较喜欢采用简单、教条化的语言和设计模式，比如我对OOP、强类型、静态语言、编译语言很有好感。
我喜欢unit test，但反对test driven development。我喜欢所有的自动化工具，让它尽可能地参与整个开发流程。
我信奉版本管理和配置管理。我对pair programming很没好感，觉得是浪费时间和精力。我不喜欢群组式的code review，
我更偏向于精英参与的code review，因为一个junior去看senior的代码一样的不顺眼，照样一大堆问题，而这种
review全无意义。我喜欢小规模开发，扩展，然后幅射成大系统。但我说的这个不是原型开发，也不是迭代开发，
打个比喻，如果我来做一个雕塑，我有可能先做一个手指头，然后从手指头出发，做出整个雕塑。简单来说，
我会选择一个resource最多，dependencies最小的子系统来建立，以测试当前的技术路线与开发模式。
但如果是一个超过四个人的团队，我会应用很接近agile的快速交付模型来做，虽然我对这种快速度付模型不是太有
好感，只是我没有更好的办法。
比如我最近做的kindle-tools开源项目，我选择的手指头是一个txt文件转换器。我以测试的方式来开发，
让自己进入状态，让项目进入状态，最后快速幅射出整套系统。这是我个人单干时最喜欢的模式。事实上，我一个人
做POC的时候就基本上这样做，而一个人做PoC是很常有的事。
在小组开发时，我会选择快速交付模型。第一个交付版本一般会在一个半月左右，这是我可以控制的工作量，
也是老板可以等待的耐性范围内的时间，但这个时间比典型的快速交付时间多了一倍。第一个模型通常是一个什么功能
也没有的空框框。如果我有足够的man power，我会按排他或他们去做一两个基本独立的模块。快速交付模型是
应付老板的最好方法，也是让团队获得初期信心的最好的方法。我的手指模型虽然是我的最爱，但在团队开发上用不上。
而事实上第一个交付版本一般都会在顶住老板压力的情况下拖上两周以内的时间，然后交付测试。
接下来开始做具体的功能。对了，我这个方法是应对j2se server开发的，对于j2ee的开发可能不合适。
由于老板的耐性通常会在前面的两个月的开发时间里消耗得差不多，接下来就是超快速功能交付，
大概一个月左右，老板会很开心地看到他的希望。
这个时候进入第三阶段的开发，一些比较难的功能会在这个时候补上去，一些没有信心实现的功能在这个时候
就要报告老板做删除工作。我一般会在这个时候加重unit test。所以我的unit test绝对不是典型的TDD。
而且，因为各种原因，unit test cases未必全部通过。
大概又过了一个月，产品基本上可以freeze成alpha/beta，最后进入收官和发布。
这套方法有一定waterfall的缺点。因为第一个交付系统很可能是整个系统的框架。我自己会直接参与
这个框架的设计和实现，必要时，我会扮演一个独裁的角色灭掉所有的异见人士，以减少风险的可能性。
我现在正在学习如何在可预见风险的条件下接受异见人士，因为独裁角色太伤人品，没有必要这样做。
这套方法的另一个缺点是不规范，不合乎“标准”，有点连哄带骗的味道。
这也是我自己实用主义带来的坏处。
第三个缺点就是这套方法没有太具体的计划。Agile也没有太具体的计划，但别人有教条教义可循，
我自己吹水要让老板信服，同事信任，这个难度不小。所以，要不就是大家都真的信任我，
或者就是连哄带骗的办下去。所以我现在在正努力往这套东西里混入计划的元素，尽可能地靠近常人
可以接受的道德规范。
好处嘛，很简单，就是实用，我对这套东西太有信心了。这些年来，我拖着各色人士，有senior, junior,
middle level，干着各种有deadline, high pressure的项目，未尝失败过。
澳洲的中小型IT公司
在澳洲的IT公司或者公司IT部门工作了一段时间，还没有机会深入接触五十人以上规模的开发团队的公司；感觉好像使用Agile methodology的公司居多。Agile 方法中，每天10几分钟的review,talking,interactive 对工作和技能提升以及英语表达还是有正面促进作用的。
也接触过pair programming, 这种方法比较适合水平和文化背景比较接近的程序员，成本较高但是对打破思维局限性弥补程序员个别短板有很大帮助。
使用过原型开发，在开发需求不明确但是整体开发投入比较大的情况下适用。
曾经花了2个月帮助公司开发一个原型，项目经理、架构师、business analyzer和我共同参与；架构师和项目经理前期参与一些，主要还是我和business analyzer参与。
原型开发完成后，对厘清真实需求有很大帮助。
使用过Junit和其它一些测试框架，对软件质量提升确实有帮助；一直想尝试hudson,还没有找到机会。
有些公司使用 test driven model，可能适用对质量要求极其苛刻而又不缺钱的项目吧，本人没有尝试过。
有些公司使用feature driven model,产品通过独立的较小模块的feature来进行产品开发、完善和功能扩展；这个我相信，大多开发人员可能都接触过，但是以此作为一个
开发模式用于整个产品的研发可能就不多了。
也做过一些项目，只求完成功能，做好表面文章就行，架构、算法、优化、质量等不是考虑重点；这里面好像就没有什么methodology.
希望有机会跟更多的IT朋友交流。 我们的产品是以UI为主的，但现在系统的很多关键模块还是使用了TDD.
我自己的经验的话，只要是逻辑关系比较复杂，涉及UI不多的东西，我都倾向于用TDD开发。总体感觉下来，我认为TDD是处理这类问题的最佳methodology :lol
TDD奉行的其实是一种实用为王的哲学。
在设计水平达到一定程度，掌握大量的比如设计模式之类的设计技巧后， 程序员面临的问题就会从“如何设计”向“如何避免过度设计”转变。 TDD是我知道的能够最大程度降低“过度设计”风险的方法。
严格遵循TDD得出的设计结果几乎一定是简洁、优雅的。但TDD的过程要求你必须掌握足够的设计技巧，否则很多逻辑你都不知道怎么才能用测试代码去描述它们。然后TDD通常比较耗费精力，因为你必须不断的同自己的设计欲望做斗争。但只要你认真尝试几次，你会发现你的付出都是值得的:lol 看来大家的看法是不太一样阿。期待更多TX来谈谈自己的经验。 原帖由 woodheadz 于 11-10-2010 15:34 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我们的产品是以UI为主的，但现在系统的很多关键模块还是使用了TDD.
我自己的经验的话，只要是逻辑关系比较复杂，涉及UI不多的东西，我都倾向于用TDD开发。总体感觉下来，我认为TDD是处理这类问题的最佳methodology ...
请教下面的这些问题：
1. 你们是以Test来drive开发，还是以Test来检验开发？
2. 无论 1 的回答是与否，你们的测试覆盖率达到多少？如何检测测试的覆盖率？
3. 如何推行测试用例的开发？也就是说，如果有某些开发人员不自觉开发测试用例，
如何监管？还是全靠自觉。
4. 你们的测试用例除了单元测试，还有哪些？
5. 是否应用自动工具来定期自动运行单试用例，并生成报告？
6. 是否结合其他的SCM工具来管理测试以及bug fixing？大致的流程是什么？谁来监控？
谢谢。 原帖由 key 于 11-10-2010 19:53 发表 http://www.freeoz.org/ibbs/images/common/back.gif
请教下面的这些问题：
1. 你们是以Test来drive开发，还是以Test来检验开发？
2. 无论 1 的回答是与否，你们的测试覆盖率达到多少？如何检测测试的覆盖率？
3. 如何推行测试用例的开发？也就是说，如果有某些开 ...
挺能呼悠的。感觉都是在开发超大型项目。 原帖由 dover 于 11-10-2010 20:13 发表 http://www.freeoz.org/ibbs/images/common/back.gif
挺能呼悠的。感觉都是在开发超大型项目。
这个不是忽悠。都是很实实在在的问题来的。测试的作用是驱动开发还是检验开发，是非常不同的做法。
而测试覆盖率则是现在质量监控中非常重要的一环，我手上目前还没有有效的工具来检测测试的覆盖率，
所以想请教一下别人的经验。
而自动测试和自动测试报告的生成和发送是现在continuous integration的重要一环。
也是实实在在的东西。我自己是用脚本自己写的，基本上是土方法，现在正在转向成熟的第三方工具，
比如Hudson和Bamboo。我群里有同学是用CC，口碑也不错。因为木头同学重点分享他在TDD方面的
经验，所以想请教他用了哪些工具，以及如何schedule这些工具。
Unit Test是一个概念。很多人直接把什么东西都集中写成unit test。而typical unit test是
不需要set up runtime environment的，但有不少人并不用typical unit test。我自己也是一胡脑
的把integration test写到unit test中用同一个测试引擎来驱动。接下来我想把有关环境搭建的测试
分割出来，做到continuous integration test中去。我想知道木头同学他们有没有做这样的分割，
向他学习相关的经验。
至于SCM也不是什么忽悠的东西。建立issue，跟踪，提交，关闭，
这样的工作流程在很多公司已经建立起来了。这些概念说起来不难，但在真正实施，并实施得很流畅则
需要一定的工作规范。所以我想向木头其他同学请教他们的实施经验。
所以说，以上任何一个问题都是实实在在的问题，没有忽悠的成分。 看来有必要再开个测试的帖子。请各位深入浅出的讲解一下阿。 原帖由 key 于 11-10-2010 19:53 发表 http://www.freeoz.org/ibbs/images/common/back.gif
请教下面的这些问题：
1. 你们是以Test来drive开发，还是以Test来检验开发？
2. 无论 1 的回答是与否，你们的测试覆盖率达到多少？如何检测测试的覆盖率？
3. 如何推行测试用例的开发？也就是说，如果有某些开发人员不自觉开发测试用例，
如何监管？还是全靠自觉。
4. 你们的测试用例除了单元测试，还有哪些？
5. 是否应用自动工具来定期自动运行单试用例，并生成报告？
6. 是否结合其他的SCM工具来管理测试以及bug fixing？大致的流程是什么？谁来监控？
1，2.我想应该算是Test来drive开发吧。
其实这里我们的观念上有个本质的区别，我的观念里，TDD更多的算是一种设计-编码的方法，不太应该理解为是一种单纯的测试方法。
当然TDD的结果包含自动化测试，对于最终回归测试很有帮助。但这个只是TDD所产生的附带好处之一。TDD代替不了严格的测试，或者说TDD本质上就不能算是“测试”。
3.没办法强制推行。TDD是一种需要技巧的编程方法，并不对所有人适用，也不对所有场合适用。
4、5、6.我前面说过了，TDD不能代替测试。在我自己的经验中，根据项目、公司管理制度等等的不同，有很多不同的方式来回答你提的问题。相信你对这些问题也会有多个答案吧 :lol
[ 本帖最后由 woodheadz 于 11-10-2010 22:40 编辑 ] 说到测试，我觉得日本式的软件测试感觉还不错，最终的测试质量可以通过BUG曲线来进行检验，算是我经历过的比较好的测试方法啦
不过不管哪种方法，使用方法的人是最关键的。尤其在中小项目中。
我们现在的产品测试方面并没有做很专门的流程进行控制，但最终质量还是很好。这和我们老板有关系，他是我见过的做测试最牛的人，从我手上出来的东西以前从来没人一下子抓出那么多问题 :L
[ 本帖最后由 woodheadz 于 11-10-2010 22:47 编辑 ] 原帖由 key 于 11-10-2010 21:22 发表 http://www.freeoz.org/ibbs/images/common/back.gif
这个不是忽悠。都是很实实在在的问题来的。测试的作用是驱动开发还是检验开发，是非常不同的做法。
而测试覆盖率则是现在质量监控中非常重要的一环，我手上目前还没有有效的工具来检测测试的覆盖率，
所以想请 ...
这些方法，工具，概念确实都是实实在在的，有用的。关键是什么时候用，怎么用。现在对于复杂系统开发，无论是传统的结构化，面向对像，还是agile或其它的，他们的长处和不足都非常明显。就像结构化流程和Agile，它们本身就是相抵触的方法。在实际开发中都很难全面的套用。不要太迷信那些华丽的框架和名词。就像所谓什么驱动开发还是检验开发，这些本身根本不重要，重要的是你的具体应用适合什么模式。 原帖由 dover 于 12-10-2010 08:32 发表 http://www.freeoz.org/ibbs/images/common/back.gif
现在对于复杂系统开发，无论是传统的结构化，面向对像，还是agile或其它的，他们的长处和不足都非常明显。
有兴趣分享一下你在这方面的经验吗？
就像结构化流程和Agile，它们本身就是相抵触的方法。
能举例说明结构化流程和Agile相抵触在哪些方面？
不要太迷信那些华丽的框架和名词。就像所谓什么驱动开发还是检验开发，这些本身根本不重要，重要的是你的具体应用适合什么模式。
对于驱动开发还是检验开发，我之所以认为需要区分，是因为TDD与非TDD的重要区别。
也是我们如何看待什么时候、什么方式、什么覆盖度来引入测试用例的一个重要理据。
比如我自己是以测试来检验开发的，所以我的测试是基本后置，不强制要求，覆盖度大概在30%以下，
只覆盖我们认为关键或已经有可能出错的地方，对于变化太大的模块，有些测试可能出错，而我们只会disable
或保留出错，并不急于改动。
但对于测试驱动开发，我在一些自己玩的小项目中也在尝试这种做法。以测试用例来驱动模块的定型、进化，
对于重要的接口基本上覆盖好，在代码形成之前就编写好测试用例，追求快速实现测试想要的结果。
由于两种模式的基本思路和开发流程是根本区别的，在我看来，需要有比较清楚的区分。
当然，正如你所说，需要具体应用，这个是有道理的。不过我不认为这些是华丽的名词，
而是实实在在的概念，并有相应的实践方法来与之对应。 原帖由 woodheadz 于 11-10-2010 22:44 发表 http://www.freeoz.org/ibbs/images/common/back.gif
说到测试，我觉得日本式的软件测试感觉还不错，最终的测试质量可以通过BUG曲线来进行检验，算是我经历过的比较好的测试方法啦
不过不管哪种方法，使用方法的人是最关键的。尤其在中小项目中。
我们现在的产品测试方 ...
如果有时间，能不能分享一下你见到的日本式的软件测试？ 原帖由 woodheadz 于 11-10-2010 22:38 发表 http://www.freeoz.org/ibbs/images/common/back.gif
1，2.我想应该算是Test来drive开发吧。
其实这里我们的观念上有个本质的区别，我的观念里，TDD更多的算是一种设计-编码的方法，不太应该理解为是一种单纯的测试方法。
当然TDD的结果包含自动化测试，对于最终回 ...
对的，是回归测试。不知道哪些同学能分享一下你们在回归测试上的实施细节。谢谢。 原帖由 dover 于 12-10-2010 08:32 发表 http://www.freeoz.org/ibbs/images/common/back.gif
这些方法，工具，概念确实都是实实在在的，有用的。关键是什么时候用，怎么用。现在对于复杂系统开发，无论是传统的结构化，面向对像，还是agile或其它的，他们的长处和不足都非常明显。就像结构化流程和Agile， ...
你说的不错啊，无论什么方法，没有万灵丹。都要根据人的情况，项目的情况选择实施。
问题是软件开发的很多方法不亲身实践很难体会到它的特点和好处，这时候看看别人的经验还挺有帮助 原帖由 key 于 12-10-2010 10:04 发表 http://www.freeoz.org/ibbs/images/common/back.gif
如果有时间，能不能分享一下你见到的日本式的软件测试？
其实也没什么特别的。
首先他们的测试一般分成内部测试，外部测试，结合测试和系统测试几个步骤。 每个步骤上根据代码行数有个参考的测试case数。
在结合测试之后每天都要做bug分析报告，得出bug变化曲线，一般要趋近参考曲线才能说明系统的测试已经达到要求质量。
日本人严重依赖于Excel，整个过程的所有文档可以完全基于Excel完成。
感觉这种做法在类似外包之类的场景中确实比较有效。但我自己感觉，如果只是几个人十来个人的非外包研发小团队中就不是很适应了。
中小项目中我宁愿相信人的经验。 原帖由 woodheadz 于 12-10-2010 10:39 发表 http://www.freeoz.org/ibbs/images/common/back.gif
每个步骤上根据代码行数有个参考的测试case数。
在结合测试之后每天都要做bug分析报告，得出bug变化曲线，一般要趋近参考曲线才能说明系统的测试已经达到要求质量。
日本人严重依赖于Excel，整个过程的所有文档可以完全基于Excel完成。
看来重点在这里。
1. 与代码行数相关的参考测试曲线
2. Excel文档
有没有可能知道他们这个参考测试曲线的参考模型是什么？
Excel文档有哪些项目？ 原帖由 black_zerg 于 12-10-2010 14:29 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我认为IT界不吹水是不行的，个人也有这个志向不断努力提高自己的吹水水平，不过要是我说真话我就会说牛程序员和渣程序员区别就和老鹰跟小鸡一样，你跟老鹰讲怎么飞，那没必要，跟小鸡讲，那也没必要。好多做程序做了 ...
不管是老鹰还是小鸡，都需要个成长的环境。 小鸡变飞机是不可能啦，但如果能多点思考，最少是比较容易变个大公鸡，甚至变老鹰也不是没有可能。
:lol 原帖由 key 于 12-10-2010 14:17 发表 http://www.freeoz.org/ibbs/images/common/back.gif
看来重点在这里。
1. 与代码行数相关的参考测试曲线
2. Excel文档
有没有可能知道他们这个参考测试曲线的参考模型是什么？
Excel文档有哪些项目？
参考的曲线和case参考数各家公司有自己的标准。bug曲线模型基本上和标准的bug曲线模型近似。
Excel文档里的项目和一般bug traker系统差不多。
我觉得他们能行之有效的关键是在于企业文化和执行的人。脱离了这些东西，可能就成为花架子了。 原帖由 black_zerg 于 12-10-2010 14:29 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我认为IT界不吹水是不行的，个人也有这个志向不断努力提高自己的吹水水平，不过要是我说真话我就会说牛程序员和渣程序员区别就和老鹰跟小鸡一样，你跟老鹰讲怎么飞，那没必要，跟小鸡讲，那也没必要。好多做程序做了 ...
没听说过Agile是宗教派别吗？
信则灵，不信则不灵嘛，:D ;P 原帖由 black_zerg 于 12-10-2010 15:56 发表 http://www.freeoz.org/ibbs/images/common/back.gif
问题就在于很多渣程序员压根不会写程序，但是要说吹水谁不会吹，空口说白话，你说TDD不好，我马上能说TDD可以实现50%的效率提高，是世界领先潮流，这些还不是随说的？你要他实现个什么东西顿时就歇菜。我是没怎么见过 ...
呵呵，是有不少你说的情况。当年CMM疯狂的时候，这种人我也是见了不少。
但这个不代表讨论“methodology”没有用。和别人讨论和思考的过程不就是你说的“个人修行”的过程吗？:lol 原帖由 woodheadz 于 12-10-2010 16:27 发表 http://www.freeoz.org/ibbs/images/common/back.gif
呵呵，是有不少你说的情况。当年CMM疯狂的时候，这种人我也是见了不少。
但这个不代表讨论“methodology”没有用。和别人讨论和思考的过程不就是你说的“个人修行”的过程吗？:lol
个人修行不是PSP吗？哈哈 原帖由 key 于 12-10-2010 16:32 发表 http://www.freeoz.org/ibbs/images/common/back.gif
个人修行不是PSP吗？哈哈
唉，说起PSP和TSP，我们很多年前还真搞过一年多，始终没有很理想的效果。后来接触敏捷后我才开始放弃被CMM培养出来的“度量一切”的思路。
页:
[1]