收集CMM/CMMI的QA和Scrum Master的相同点和不同点
张克强
相同点
1，不直接评价员工个人绩效
2，关注于过程是否符合要求
3，并不在项目团队中直接做决策
不同点：
1，QA一般不是项目开发人员，QA一般同时参与多个项目，而Scrum Master可能只参加一个项目，并承担开发任务。
2，QA问题会有提升的途径，当QA问题不及时解决时，QA问题会提升到高级管理者，Scrum Master一般在团队内部解决问题，只有碰到实在必须解决又自身无法解决时，才会提升到管理层。
3，QA所依据的一般来自于组织既定的规程，一般来说内容覆盖方方面面，有规范的体系；Scrum Master所依据的一般来自于Scrum本身和团队达成的共识，一般来说更有针对性，但也许未必成规范的体系。
胖子
bao yangzhou
我觉得你把角色和岗位这些最基本的概念搞明白之后再来发言比较好，这种纯粹的扯淡的发言也会少很多。
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
Xu Yi
> 但事实上来看，两者的工作又有一部分的重合。我看过一个Ken
> Schwaber的视频，他也说了很多公司转型后，ScrumMaster很多都是由原来的QA担任的。所以，如果真的把两个角色的工作一个一个列出来，应该是会有一些是一样的。比如，像LZ列的几点。不过，不知道这样的比较有没有太大的意义。
o6z的语气看来还不够重，不够警醒大家。。。
你的疑问可以澄清一下，请大家把角色和具体的人分开。Ken的话是建立在一个基础上的，也既是在CMMI模式下QA角色的担当者，他们培养出一种质量意识的可能性比较大（相比其他角色），更能够发现问题，那么这个人成为“ScrumMaster很多都是由原来的QA担任的”中一员的优势在于，它会更关注团队所遇到的问题，以及组织的问题。回顾Scrum的三个角色，PO负责团队做什么，团队负责做，而Scrum
Master一定程度上可以（片面地）理解为负责不要做什么或者不要怎么做，这样的一个角色。
角色与角色之间基本上是没有比较意义的，因为其职权定义就不同，更不要说不同模式下的角色了。但是针对某个具体角色，担当角色的潜在人选之间是可以比较的，在无法全面了解候选人的情况下，对方前期担任过的职务就可以作为参考，因为不同的职位需求会一定程度上影响人的思维模式、关注的信息、工作的习惯。自然而然的，不同的人由于其不同的经历，对于某一个特定职位自然也就有是否匹配这一说法。
但是，用角色去匹配角色，这根本就是无稽之谈，根本就是犯了逻辑错误，这也是o6z说lz纯粹在扯淡的原因。
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
张克强
如果比较的路走不通，那么问问各位： QA如何做好Scrum Master？ 这里有两种情况，1是项目经理仍然存在 2是项目经理没有了
有没有较好的实例？
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--
张克强
blog:http://hi.baidu.com/hespr
通过高效过程追求卓越结果！无论是敏捷或CMMI或其它。
Steven Mak
只有一套 Scrum Master 的責任描述。
至於如何做好 Scrum Master？請 RTFM.
On May 28, 4:08 pm, 张克强 <zhangkeqi...@gmail.com> wrote:
> 看到了有些组织让QA来担当Scrum Master，试图通过比较QA和Scrum Master的差异来看看QA如何做好Scrum Master？
> 如果比较的路走不通，那么问问各位： QA如何做好Scrum Master？ 这里有两种情况，1是项目经理仍然存在 2是项目经理没有了
> 有没有较好的实例？
>
> 在 2010年5月28日 上午9:17，胖子 <ozzzzzz....@gmail.com>写道：
>
>
>
> > 我觉得你把角色和岗位这些最基本的概念搞明白之后再来发言比较好，这种纯粹的扯淡的发言也会少很多。
>
> > On 5月28日, 上午2时52分, 张克强 <zhangkeqi...@gmail.com> wrote:
> > > 收集CMM/CMMI的QA和Scrum Master的相同点和不同点，以下是当前看到的，请大家补充、修订。
>
> > > 相同点
> > > 1，不直接评价员工个人绩效
> > > 2，关注于过程是否符合要求
> > > 3，并不在项目团队中直接做决策
>
> > > 不同点：
> > > 1，QA一般不是项目开发人员，QA一般同时参与多个项目，而Scrum Master可能只参加一个项目，并承担开发任务。
> > > 2，QA问题会有提升的途径，当QA问题不及时解决时，QA问题会提升到高级管理者，Scrum
> > > Master一般在团队内部解决问题，只有碰到实在必须解决又自身无法解决时，才会提升到管理层。
> > > 3，QA所依据的一般来自于组织既定的规程，一般来说内容覆盖方方面面，有规范的体系；Scrum
> > > Master所依据的一般来自于Scrum本身和团队达成的共识，一般来说更有针对性，但也许未必成规范的体系。
>
> > --
> > 敏捷中国http://www.agilechina.net邮件列表
> > 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> > 如欲退订请发送邮件到 agilechina-...@googlegroups.com
> > 更多选项，请访问http://groups.google.com/group/agilechina
Andy Wang
Scrum Master存在的意义又是什么？她/他跟PO有什么不同？跟PM有什么不同？跟BA有什么不同？
PO能担当SM的工作吗？PM可以吗？BA可以吗？清洁工可以吗？
SM参与团队内部的技术争论吗？SM有最终的话语权吗？SM有什么权限吗？如果有的话是什么？
SM管理的是什么？
搞清楚这些问题，楼主你再回过头来看你比较得有意义没有吧。
> > 通过高效过程追求卓越结果！无论是敏捷或CMMI或其它。- Hide quoted text -
>
> - Show quoted text -
胖子
那戏剧来说，角色就是剧本里面的那个人物，并被演员所表现在舞台上。显然，一个角色可以由多个演员来表演，一个演员也可以扮演多个角色。角色之间不存在
什么互相扮演的问题，除非是戏剧中的戏剧。
所以我说你这个根本就是扯淡。
当然问题并不完全在你，而是本身scrum这个圈子就是垃圾堆，包括你说的那些老外，有多少是头脑清醒的？
现在的唯一明治做法，就是在敏捷圈子内部少说什么scrum。否则就是自取其辱。
其次我在给你说点具体的事情。
比如第一你说什么不直接评价员工个人绩效 ，这显然就是一种误解。因为绩效的评价方式有很多种，其中很多现代流行的（比如平衡积分卡），其实就是这个绩
效来自所有你周围的环境，包括你的QA和SCRUM团体成员。而又不仅仅是来自一个个人，因为是来自一个系统。所以你说的这个根本就是白说，除了显示你
对绩效考核的无知，其他根本就代表不了什么。
其次你又说，他们关注于过程是否符合要求。 这也是瞎说。因为SCRUM Master关注的和维护的是Scrum流程，而不是过程。过程要比较大很
多，也复杂很多。而QA也仅仅只能关注一小部分。这个是软件工程常识，你不知道或者你很混淆，只能说明你还差得远。
并不在项目团队中直接做决策，这依然很可疑。因为QA其实也是要作决策的，并且任何人只要在企业内部工作，都要作决策，否则这个人根本就没必要存在。这
里的问题是，你把不把这个QA纳入你的团队，这个是你的企业组织结构问题，我建议以你目前这个知识水准还是别讨论了。而明确的说凡是关于SCRUM流程
的决策，都是由SCRUM master作成的，否则还要这个角色干吗，除非你认为他本身就是一个饮水机卫士。
其次你下面说的不同点，问题就更多，基本上每一条都是筛子，禁不起推敲。
其实你已经很能代表国内国外目前SCRUM社区的情况，那就是什么都不懂，什么基本也没有，参加了一个培训，立马就声称敏捷了。动不动就把SCRUM跟
敏捷画等号。说实在的，SCRUM社区的还没有CMM社区的风气好，水准高。敏捷要不被你们搞跨，那就奇怪了。
On 5月28日, 下午4时08分, 张克强 <zhangkeqi...@gmail.com> wrote:
> 看到了有些组织让QA来担当Scrum Master，试图通过比较QA和Scrum Master的差异来看看QA如何做好Scrum Master？
> 如果比较的路走不通，那么问问各位： QA如何做好Scrum Master？ 这里有两种情况，1是项目经理仍然存在 2是项目经理没有了
> 有没有较好的实例？
>
> 在 2010年5月28日 上午9:17，胖子 <ozzzzzz....@gmail.com>写道：
>
>
>
> > 我觉得你把角色和岗位这些最基本的概念搞明白之后再来发言比较好，这种纯粹的扯淡的发言也会少很多。
>
> > On 5月28日, 上午2时52分, 张克强 <zhangkeqi...@gmail.com> wrote:
> > > 收集CMM/CMMI的QA和Scrum Master的相同点和不同点，以下是当前看到的，请大家补充、修订。
>
> > > 相同点
> > > 1，不直接评价员工个人绩效
> > > 2，关注于过程是否符合要求
> > > 3，并不在项目团队中直接做决策
>
> > > 不同点：
> > > 1，QA一般不是项目开发人员，QA一般同时参与多个项目，而Scrum Master可能只参加一个项目，并承担开发任务。
> > > 2，QA问题会有提升的途径，当QA问题不及时解决时，QA问题会提升到高级管理者，Scrum
> > > Master一般在团队内部解决问题，只有碰到实在必须解决又自身无法解决时，才会提升到管理层。
> > > 3，QA所依据的一般来自于组织既定的规程，一般来说内容覆盖方方面面，有规范的体系；Scrum
> > > Master所依据的一般来自于Scrum本身和团队达成的共识，一般来说更有针对性，但也许未必成规范的体系。
>
> > --
> > 敏捷中国http://www.agilechina.net邮件列表
> > 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> > 如欲退订请发送邮件到 agilechina-...@googlegroups.com
> > 更多选项，请访问http://groups.google.com/group/agilechina
Andy Wang
我同意现在Scrum社区，国内外都有比较混乱的现象，经常是一个组织或者一个pm声称采用了Scrum，但是细去推敲，他们的做法无非是批上了
Scrum术语的外皮，骨子里还是以前的那一套。我公司里一个才工作了两年就趾高气昂目空一切的小孩，竟然说SM由客户来担当…………然后GM还挺欣赏
他的…………看来离我跳槽也不远了。
不过不管怎样，Scrum作为入门起点比较低的一个敏捷框架，有它的优势。它本身比较容易兼容其它敏捷最佳实践，与其说它是方法或者流程，不如说它是一
种指导性思想，在其基础上可以参照团队和公司的状况裁剪出合适的框架出来。比较起XP这种几乎不能裁剪的框架，想要把敏捷思想推广开来，也许Scrum
的贡献会更大一些吧。
张克强
我在这里发起过多次实践、看法等的征集，几乎每一次都难以开展下去。
论坛发言一般要简短，不可能在发言前后加一个词汇表
简短的发言中所用词汇就未必能够表达原来的意思，不同的人就有不同的理解。
那么一般论坛的理解就采用最普通的理解
各位大虾充分利用批评的眼光，能在简短的发言中识别大量的不足，进而来判断发言者本身，实在是“诲“人不倦。
看看敏捷宣言：We are uncovering better ways of developing
software by doing it and helping others do it.
几位大虾，你们有理解宣言的第1句话吗？
最初，极限编程技术只提出了四条价值标准，而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准：
- 沟通
- 简单
- 回馈
- 勇气
- 尊重（最新添加的价值）
对于提出的问题，首要是真正设法去解决或帮助他人解决？ 还是对问题本身进行批评？
各位大虾，如果首先并不是真正帮助他人，而是通过批评来显得自己高明，请不要对我的帖子做任何回复
说到论坛风气，秉承敏捷宣言、XP的5条价值，就能让这个论坛的风气好起来！
目前只有很有勇气的人才敢于在这里发有实质内容的帖子，比如是我 :）
要让每个敏捷有疑问的人敢于在这里提问! 哪怕问题本身提得不对，哪怕是入门的问题
--
敏捷中国 http://www.agilechina.net 邮件列表
Jeff Xiong
说到底我不明白为什么需要“把敏捷思想推广开来”。
2010/5/30 Andy Wang <hrb...@gmail.com>:
> o6z说得很犀利，也很值得去思考。不过对于Scrum的批判还是偏激了。也许是爱之深恨之切吧。
>
> 我同意现在Scrum社区，国内外都有比较混乱的现象，经常是一个组织或者一个pm声称采用了Scrum，但是细去推敲，他们的做法无非是批上了
> Scrum术语的外皮，骨子里还是以前的那一套。我公司里一个才工作了两年就趾高气昂目空一切的小孩，竟然说SM由客户来担当…………然后GM还挺欣赏
> 他的…………看来离我跳槽也不远了。
>
> 不过不管怎样，Scrum作为入门起点比较低的一个敏捷框架，有它的优势。它本身比较容易兼容其它敏捷最佳实践，与其说它是方法或者流程，不如说它是一
> 种指导性思想，在其基础上可以参照团队和公司的状况裁剪出合适的框架出来。比较起XP这种几乎不能裁剪的框架，想要把敏捷思想推广开来，也许Scrum
> 的贡献会更大一些吧。
>
--
Jeff Xiong
Software Journeyman - http://gigix.agilechina.net
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
Jeff Xiong
比如说吧，是不是要“让每个敏捷有疑问的人敢于在这里提问”，特别是“入门的问题”，对此我真的非常怀疑。可以提入门问题的地方多了去了，比如CSDN我觉得就很合适。如果您真觉得入门问题那么重要，像我啦胖子啦这些上了年纪的人就不陪您了，您走好。
2010/5/30 张克强 <zhangk...@gmail.com>:
> 作为敏捷的爱好者、或实践者、或卫道士、或布道者，应当如何来维护这个论坛？
> 对于提出的问题，首要是真正设法去解决或帮助他人解决？ 还是对问题本身进行批评？
> 各位大虾，如果首先并不是真正帮助他人，而是通过批评来显得自己高明，请不要对我的帖子做任何回复
>
> 说到论坛风气，秉承敏捷宣言、XP的5条价值，就能让这个论坛的风气好起来！
> 目前只有很有勇气的人才敢于在这里发有实质内容的帖子，比如是我 :）
> 要让每个敏捷有疑问的人敢于在这里提问! 哪怕问题本身提得不对，哪怕是入门的问题
>
胖子
首先你说的很对SCRUM就是一层皮，并且如果你要是想搞得好，就只能让起仅仅起到一层皮的作用。就如同我在多个场合说的，SCRUM是一个永远的老二
方法，不是能是核心方法。他的好处就在于，几乎可以跟任何方法（老的方法新的方法以及未来的方法）结合使用。
为什么会这样呢？首先SCRUM的内核很小，其次内容简单，再次作用和副作用都小（也就是属于作用非常有限的方法）。本身如果你有知识基础，这个方法用
5分钟给你解释就够了。但是你偏偏要把其他一些东西向SCRUM这里装，那自然就会很混乱。而恰恰由于SCRUM方法的无侵害性，也造成你可以向里面放
任何东西。
而进一步，SCRUM必然是不能解决实际的开发核心流程问题，也就是如此才能保证其应用范围。其次由于其不具备开发的核心问题的关注性，也就无法作为入
门方法。这两点尤其重要。也就是如果你们那里本身是混乱的，那么你们的scrum搞的再好，依然会是混乱的。
那么是不是说这样的话scrum就没什么价值了，没必要去研究和应用了吗？恰恰相反，这样的方法价值巨大，而且你研究现有的方法，基本上没有其他方法具
备scrum的这种特征。而你去研究其他方法，你会发现这些方法都不能做大完全覆盖开发的所有方面，而你去具体实施的时候你也明白必然要涉及所有的方
面。那么用scrum填补这个空白就太合适了。其次其他方法，也往往仅仅是一种或者几种最佳实践的组合，那么用什么胶水来组合他们呢？用scrum。而
另外一个方面，你往往要涉及新方法和老方法的结合问题，这个时候用什么来调整呢？scrum。
这就好比我学的药学里面的附形剂，不具备任何药理作用，但是你作药必须用这个东西。
胖子
你们这些人无非就是觉得我们没有尊重你们，但是你们从来就不反思到底你们是不是尊重了我们。这就好比你要加入我们这个团伙，但是你跑进来第一不学我们说
话的方言，第二不跟我们一起作事情，第三不跟我们共同学习。我们自然不会接纳你。而你却说，你如何如何，比我们更懂我们的原则。你说我们对你不报以最大
的恶意，我们还有其他什么合理的选择。
另外还有一个问题是你们这些人水平实在是太低了，我们的知识水平不存在一个层面上交流起来自然很困难。而你们又脸皮太薄，根本就不去关注别人的具体内
容，而光光得只顺从了血气。而之所以你们这些人水平低其实原因很简单。要么是实际操作太少，要么是脑子动的太少，要么是脑筋用错了地方。
其次要论坛风气好起来，唯一的方法就是你这样的人赶快走路。
On 5月30日, 上午7时06分, 张克强 <zhangkeqi...@gmail.com> wrote:
> 在这里实在无法与胖子等各位大虾沟通，虽然我做过多次努力。
> 我在这里发起过多次实践、看法等的征集，几乎每一次都难以开展下去。
> 论坛发言一般要简短，不可能在发言前后加一个词汇表
> 简短的发言中所用词汇就未必能够表达原来的意思，不同的人就有不同的理解。
> 那么一般论坛的理解就采用最普通的理解
> 各位大虾充分利用批评的眼光，能在简短的发言中识别大量的不足，进而来判断发言者本身，实在是"诲"人不倦。
> 看看敏捷宣言：We are uncovering better ways of developing
> software by doing it and helping others do it.
> 几位大虾，你们有理解宣言的第1句话吗？
> 最初，极限编程技术只提出了四条价值标准，而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准：
>
> - 沟通
> - 简单
> - 回馈
> - 勇气
> - 尊重（最新添加的价值）
>
> 作为敏捷的爱好者、或实践者、或卫道士、或布道者，应当如何来维护这个论坛？
> 对于提出的问题，首要是真正设法去解决或帮助他人解决？ 还是对问题本身进行批评？
> 各位大虾，如果首先并不是真正帮助他人，而是通过批评来显得自己高明，请不要对我的帖子做任何回复
>
> 说到论坛风气，秉承敏捷宣言、XP的5条价值，就能让这个论坛的风气好起来！
> 目前只有很有勇气的人才敢于在这里发有实质内容的帖子，比如是我 :）
> 要让每个敏捷有疑问的人敢于在这里提问! 哪怕问题本身提得不对，哪怕是入门的问题
>
Liang Qiao
做的好, SCRUMMaster就应当消失. 只有想做却做的不好的, 才会有ScrumMaster存在.
也就是说: 如果是一个好的ScrumMaster, 在公司中就应该努力地自掘"坟墓".
ScrumMaster做得好就是自己没事做.
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--
乔梁（Qiao Liang）
Blog: http://blog.csdn.net/tony1130
Liang Qiao
LiHongxi
Steven Mak
Scrum 可能算是容易理解，但不能算是入門起點低，我相信有些公司多給它十年時間也做不好，還提出多多藉口嘗試去 "剪裁" 到合他們心意的狀態，
更嚴重的是他們其實在 "剪裁" 過程中無視了最深入的問題。
還有，Scrum 雖然沒有指定什麼工程實踐，好的團隊還是需要在這方面提高水準，Scrum Master 亦應當提倡使用好的實踐方法，用最好的方
法去交付高質量的產品。
On May 30, 5:30 am, Andy Wang <hrbe...@gmail.com> wrote:
> o6z说得很犀利，也很值得去思考。不过对于Scrum的批判还是偏激了。也许是爱之深恨之切吧。
>
> 我同意现在Scrum社区，国内外都有比较混乱的现象，经常是一个组织或者一个pm声称采用了Scrum，但是细去推敲，他们的做法无非是批上了
> Scrum术语的外皮，骨子里还是以前的那一套。我公司里一个才工作了两年就趾高气昂目空一切的小孩，竟然说SM由客户来担当............然后GM还挺欣赏
> 他的............看来离我跳槽也不远了。
Steven Mak
況下最能幫助別人的就是指出問題背後假設的問題。
這更不是如何去把自己抬高一點，只是基於自己對這問題的認知去回答。
不過我倒覺得奇怪的是關於入門問題，或許這裡應該貼著 "不歡迎初學者"，或者 "這裡只招待高級用家".... 再不是就索性封閉公開注冊，搞個
"By-Invitation Only" 的私人俱樂部。外國我沒有看到這情況，亦不理解為何在這裡有這需要.... (但不要告訴我這就是 "中國
國情")
On May 30, 7:06 am, 张克强 <zhangkeqi...@gmail.com> wrote:
> 对于提出的问题，首要是真正设法去解决或帮助他人解决？ 还是对问题本身进行批评？
> 各位大虾，如果首先并不是真正帮助他人，而是通过批评来显得自己高明，请不要对我的帖子做任何回复
>
>
Jeff Xiong
2010/5/30 Steven Mak <stev...@gmail.com>:
> Scrum 不是一套給人作裁剪的框架，裡面的東西已經很少了。
>
> Scrum 可能算是容易理解，但不能算是入門起點低，我相信有些公司多給它十年時間也做不好，還提出多多藉口嘗試去 "剪裁" 到合他們心意的狀態，
> 更嚴重的是他們其實在 "剪裁" 過程中無視了最深入的問題。
>
> 還有，Scrum 雖然沒有指定什麼工程實踐，好的團隊還是需要在這方面提高水準，Scrum Master 亦應當提倡使用好的實踐方法，用最好的方
> 法去交付高質量的產品。
>
--
胖子
牛，至少比绝大多数的人牛的多的多。我喜欢显摆自己，我就显摆了。你要是觉得自己也可以显摆你就拿出点真东西显摆一下。可是他们有没什么值得拿上台面的
东西值得显摆，每一次表演其实都是现场献丑。献丑结束之后，还不叫我们笑。
如果是一次两次也就罢了，结果十多年都是这么搞，换的只是不同的ID。联gigix这个小孩现在都成了青年后，中年前。我想这些人一再如此弱智的接二连
三的献丑，除了叫我更加骄傲和狂妄，别的什么作用也起不到。速成的人太多，我也不是不了解。我只是觉得自己是速成的，也该明白自己的短处，别出来到处显
眼。可是他们偏偏要显眼，那就别怕我发笑。
说实在的，我的哪些言论，都是说了再说，网上随便都可以看到。我也不会没事情就骂人，开始也总是点到为止。结果这些人自以为是什么人，偏偏不动脑子想我
给他们的指点，反而继续大放厥词。那我自然以为，他们是不害怕我出来放炮，而且我相信很多人可能还等着我放炮。所以我也不能辜负了大家的希望，自然进入
角色出来脱衣服，找鼓槌，然后表演一番。
Andy Wang
We are uncovering better ways of developing
software by doing it and helping others do it.
如果不需要把敏捷思想推广开来的话，那么不如把这个"helping others do it"去掉好了。不然啰嗦不啰嗦，虚伪不虚伪？！
还有，敏捷需要门槛吗？难道只有思维活跃、技术扎实、眼界开阔，并且与一群有团队意识的聪明人合作才有资格用敏捷吗？我做项目管理，遇到了太多愚蠢的、
不合作的、技术差又没有自知之明的技术人员，如果不拿一个起点低的、可裁剪的框架出来，根本敏捷就无法用起来。
但是你能因为你的团队成员愚蠢、不合作、技术差又没有自知之明，就判决他/她不配知道敏捷吗？不是每个公司都像Thoughworks一样拥有一批杰出
的工程师，但是如果因此就说那些公司没有资格玩敏捷的话，未免太傲慢了。
On May 29, 6:53 pm, Jeff Xiong <gigix1...@gmail.com> wrote:
> 我不明白为什么需要一个起点较低、可以裁剪的框架。
>
> 说到底我不明白为什么需要"把敏捷思想推广开来"。
>
> 2010/5/30 Andy Wang <hrbe...@gmail.com>:
>
> > o6z说得很犀利，也很值得去思考。不过对于Scrum的批判还是偏激了。也许是爱之深恨之切吧。
>
> > 我同意现在Scrum社区，国内外都有比较混乱的现象，经常是一个组织或者一个pm声称采用了Scrum，但是细去推敲，他们的做法无非是批上了
> > Scrum术语的外皮，骨子里还是以前的那一套。我公司里一个才工作了两年就趾高气昂目空一切的小孩，竟然说SM由客户来担当............然后GM还挺欣赏
> > 他的............看来离我跳槽也不远了。
Andy Wang
拿猛药直地灌下去。倘若真是良医，必须先用温和一些的药方使之恢复一些元气，再用针灸激活肌体的活力，然后才可以将本来的药方徐徐灌下。
否则的话，胡庸医的狼虎药，又怎会被宝玉叹息。
On May 30, 5:25 am, Jeff Xiong <gigix1...@gmail.com> wrote:
> 我一向认为，裁剪就是一种很扯淡的做法。别人设计了一套方法，照着这个方法去做就能把软件做好，那么这个方法里的各种元素肯定是彼此帮助彼此关联的。而你之所以 要采用这种方法，当然是因为你现在做得不够好，你需要这种方法来指导你改进。结果你拿起这套方法来，做得到的就做，做不到的就裁剪掉，那我请问了，如果你都是在 做你本来就做得到的事，你的改进又以什么方式发生呢？人家一个方法本来就是要你在做不到的那些地方改进，去把它做到，然后你的能力就提升了，软件就能做好了。你 来个裁剪，人家要你改进的东西你不改进，完了软件没做好就哭喊"啊啊敏捷不行啊～～"──敏捷叫你做的事你都没做，你有啥资格说敏捷行不行啊？
>
> 2010/5/30 Steven Mak <steven...@gmail.com>:
>
> > Scrum 不是一套給人作裁剪的框架，裡面的東西已經很少了。
>
> > Scrum 可能算是容易理解，但不能算是入門起點低，我相信有些公司多給它十年時間也做不好，還提出多多藉口嘗試去 "剪裁" 到合他們心意的狀態，
> > 更嚴重的是他們其實在 "剪裁" 過程中無視了最深入的問題。
>
> > 還有，Scrum 雖然沒有指定什麼工程實踐，好的團隊還是需要在這方面提高水準，Scrum Master 亦應當提倡使用好的實踐方法，用最好的方
> > 法去交付高質量的產品。
>
> --
> Jeff Xiong
胖子
其实很简单的，是叫你帮助别人，而不是叫你帮助所有的别人。一个方法必定有门槛，你也说所谓起点低，但是不能说就没起点。另外我所观察的结果，真正愚蠢
的往往是管理者，而不是技术人员。同时我们并不在乎别人知道不知道敏捷，因为这个事情前一个阶段我们已经解决了。现在这个阶段我们的主要目的是告诉大家
什么不是敏捷，哪些人搞的不是敏捷。我就不相信，一个昨天还在唱cmm赞歌的人，今天一变脸就成了敏捷的急先锋。而在中国其实就时刻在发生这种闹剧。这
其实才是一种傲慢，不仅仅侮辱了敏捷，也侮辱了cmm。
同时是否所有的组织都需要搞敏捷呢？进一步是不是所有的组织都能够实施敏捷呢？那肯定不是了。一个方面如果没有实施的必要条件，这个方法本身就不值得去
学习。
胖子
同时就如同你说的，重病的人受不了猛药，但是什么是温和的药呢？你那个scrum是温和的药吗？恰恰不是，scrum我前面就说了不是药，是药的附形
剂。而对于那些希望敏捷，但是还没有能力敏捷的人和组织来说，并不是急于去学习敏捷，实施敏捷，而是应该学习最基本的软件开发知识，从开动脑筋自主思考
开始。
Xu Yi
至于愚蠢的是who，我向来认为谁都逃不了干系，不管是管理者还是技术人员，都有。只不过我们从个体来考虑的话，一个技术人员能造成的印象止于其自身或者身边的一两人，而管理者的影响范围则至少是技术人员的5~6倍，多则10数倍以上。谁的愚蠢危害更大，我想不必多说了，更应该从哪里入手，我觉得也不必再说了。
徐辛波
bao yangzhou
胖子
学会如何尊重为好，别说别人。
其次我从来就没有想成为大师，大师都圈圈们喜欢的。你如果喜欢，你们去玩好了。别在这里玩你们的游戏。
真的，我特别真诚的劝你们这些人，别在这里找我骂人。就如同当初我在javaeye上规劝你们这类的人去csdn一样，现在我劝你们找跟你们臭味相投的
地方去玩吧。那里有对你们的尊重，你们愿意互相吹捧也可以尽情的互相吹捧。
On 5月30日, 下午11时35分, 徐辛波 <sinpo...@gmail.com> wrote:
> 也许你真的很牛，但为什么一定要攻击打压呢。。。
> 上面也提到国内的SCRUM环境还比较乱，况且来此论坛的都是出于共同的爱好，为什么不能从我做起多些尊重、多些谦卑、多谢帮扶，没有这些，牛人也只能是牛人，成不了大师。。。
>
Joseph Tseng
可为什么愚蠢的领导永远总比明智的领导多呢？ 按理说，危害那么大的领导，迟早要把组织搞垮，从而被市场淘汰， 为什么到哪儿都还是那么多愚蠢领导呢？ 这说明某种程度所谓愚蠢领导是适合*这个*市场生存的！换言之，某些环境因素是客观的，短期内不可改变的。
如果上面的结论是正确的，人们只能在存在各种限制条件（甚至包括一个愚蠢的领导）的环境来改进组织。 人们最迫切的需求恰恰是在这些限制条件上如何能够逐步改善组织的效率。如果这些限制条件都能自然解决了，“众人皆谓我自然”，还要来论坛提什么问题啊？
如若不然， 我倒好奇，有资格与大牛们讨论的人究竟是哪种类型？讨论的问题又是什么？
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--
Joseph Tseng
胖子
这个问题其实一再的被讨论，而且讨论了不下10年了。今天我明确的再说一边，从自己开始，从自己这里的实际动手开始。而对于具体的问题，则从问题所涉及
的人开始，从他们的屁股下的位置开始。
为什么这个张克强总是唧唧歪歪的，因为他本身是一个搞cmm的一个PIG，自然就习惯了那一套。为什么我要不断的批他，就因为他根本就不在敏捷的轨道
上。
解决的具体的问题其实也是。为什么领导往往是愚蠢的呢？难道是他们真的智商低？当然不是了。是因为他们得到的信息有问题，受到了蒙蔽。再加上没有技术根
基，自然就会糊涂。同时你也可以发现，很多即使是搞技术的人也是很傻的。比如考了个PMP，就到处拿着那个书上的理论来跟自己的实践套，结果自然是死的
很惨。为什么会失败呢？其实初中的马列上就说了，量变和质变的问题。也就是你应该明白，任何方法都有一个量的使用范围。PMP上的调调适用的范围跟你实
际作软件开发的应用范围不在一个数量级上，自然就是乱搞。
你觉得这些基本的作人作事情的问题，还需要拿出来到这里来讨论吗？我们有必要，有资格，作他们的小学老师，作他们的代理父母，从这个级别开始给他们解释
问题吗？反正我是没有到处给人当爹的瘾，谁有谁去当好了。
On 5月31日, 下午12时15分, Joseph Tseng <airl...@gmail.com> wrote:
> 从领导者入手，改变领导，或者选择一个不那么蠢的领导。 是这样吗？
>
> 可为什么愚蠢的领导永远总比明智的领导多呢？ 按理说，危害那么大的领导，迟早要把组织搞垮，从而被市场淘汰， 为什么到哪儿都还是那么多愚蠢领导呢？
> 这说明某种程度所谓愚蠢领导是适合*这个*市场生存的！换言之，某些环境因素是客观的，短期内不可改变的。
>
> 如果上面的结论是正确的，人们只能在存在各种限制条件（甚至包括一个愚蠢的领导）的环境来改进组织。
> 人们最迫切的需求恰恰是在这些限制条件上如何能够逐步改善组织的效率。如果这些限制条件都能自然解决了，“众人皆谓我自然”，还要来论坛提什么问题啊？
>
> 如若不然， 我倒好奇，有资格与大牛们讨论的人究竟是哪种类型？讨论的问题又是什么？
>
> 2010/5/31 Xu Yi <kaverj...@gmail.com>
Steven Mak
to rise to his level of incompetence."，簡單來說就是在目前崗位有能力的人就會被升職，升職升到一個他自己沒
有能力勝任的位置，由於他在那位置上的無能，所以沒法升職，亦就是留在該職位上。
On May 31, 12:15 pm, Joseph Tseng <airl...@gmail.com> wrote:
> 从领导者入手，改变领导，或者选择一个不那么蠢的领导。 是这样吗？
>
> 可为什么愚蠢的领导永远总比明智的领导多呢？ 按理说，危害那么大的领导，迟早要把组织搞垮，从而被市场淘汰， 为什么到哪儿都还是那么多愚蠢领导呢？
> 这说明某种程度所谓愚蠢领导是适合*这个*市场生存的！换言之，某些环境因素是客观的，短期内不可改变的。
>
> 如果上面的结论是正确的，人们只能在存在各种限制条件（甚至包括一个愚蠢的领导）的环境来改进组织。
> 人们最迫切的需求恰恰是在这些限制条件上如何能够逐步改善组织的效率。如果这些限制条件都能自然解决了，"众人皆谓我自然"，还要来论坛提什么问题啊？
>
> 如若不然， 我倒好奇，有资格与大牛们讨论的人究竟是哪种类型？讨论的问题又是什么？
>
> 2010/5/31 Xu Yi <kaverj...@gmail.com>
>
>
>
> > Scrum像是催化剂或者说药引子，没有治病的方，药引子也没用，甚至还是副作用。Ken也说过，SB也能用Scrum，只不过是持续产出米田共而已。
>
> > 至于愚蠢的是who，我向来认为谁都逃不了干系，不管是管理者还是技术人员，都有。只不过我们从个体来考虑的话，一个技术人员能造成的印象止于其自身或者身边的一两人，而管理者的影响范围则至少是技术人员的5~6倍，多则10数倍以上。谁的愚蠢危害更大，我想不必多说了，更应该从哪里入手，我觉得也不必再说了。
>
> > --
> > - - - - - - - - - -
> > Xu Yi, Kaverjody
> > Agile Coach.CSP
> > Test Automation Coach
> > Blog :http://damianji.spaces.live.com
> > - - - - - - - - - -
>
> > --
> > 敏捷中国http://www.agilechina.net邮件列表
> > 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> > 如欲退订请发送邮件到 agilechina-...@googlegroups.com
Jeff Xiong
>
> We are uncovering better ways of developing
> software by doing it and helping others do it.
>
> 如果不需要把敏捷思想推广开来的话，那么不如把这个"helping others do it"去掉好了。不然啰嗦不啰嗦，虚伪不虚伪？！
要帮助他人，就应该让需要帮助的人说他需要什么帮助。“QA和Scrum
Master的相同点和不同点”，恕我驽钝，我就看不出这个话题体现出一个多么迫切需要帮助的样子。你喜欢打医生病人的比方，很好，如果一家诊所成天都是些闲人在高谈阔论“当归和黄芪的药效”，我请问这诊所还怎么治病救人悬壶济世？如果这个医生真的想帮助病人，他就会先把这些没病唠嗑的闲人赶走。
> 还有，敏捷需要门槛吗？难道只有思维活跃、技术扎实、眼界开阔，并且与一群有团队意识的聪明人合作才有资格用敏捷吗？我做项目管理，遇到了太多愚蠢的、
> 不合作的、技术差又没有自知之明的技术人员，如果不拿一个起点低的、可裁剪的框架出来，根本敏捷就无法用起来。
>
> 但是你能因为你的团队成员愚蠢、不合作、技术差又没有自知之明，就判决他/她不配知道敏捷吗？不是每个公司都像Thoughworks一样拥有一批杰出
> 的工程师，但是如果因此就说那些公司没有资格玩敏捷的话，未免太傲慢了。
你说这些话，本身就体现出你对现在敏捷在国内是个什么行情根本就不了解。（这也就是为什么像胖子和我这种上了年纪的人一说起这些就缺乏耐性。）现在根本不是有法无法用起来的问题，而是这波潮流已经被无可逆转地发动起来了，你必须用起来。你可以选择借这个机会把自己的毛病治一治，也可以选择搞搞裁剪敷衍了事。那么这个邮件列表到底是希望帮助真想改进的人，还是帮助想跟风想敷衍的人？我心里有一个答案，并且我希望我的答案跟这个列表中大多数人一样。
--
Jeff Xiong
Andy Wang
下子把这么多的最佳实践拿去给一个从来没有使用过敏捷方法的团队（或者说，公司）的话，最开始阻力肯定非常大，许多人会不理解，不认同----作为普通的团
队成员的，阴奉阳违；作为领导的，不放心，乱插手，甚至还没有来得及看到敏捷带来的好处，就已经请你下课了......
在这样的组织中，也不是就不能实践敏捷了，只不过要一步步地来。譬如我现在刚刚接手一个新的团队，我所做的，就是先把backlog引入到团队中来，因
为这一步的变动的幅度，对于团队而言是能够接受的，而且也能够解决客户需求----客户时不时地想知道团队究竟处于哪里。我完全不认为这就敏捷了，但是毕竟
这是第一步；当团队认同backlog并没有引入更多的工作量之后，我会逐步地把更多的最佳实践加进来，直到最后把一个相对比较完整的敏捷方法完全地实
施开来。
我所谓的裁剪，就是如此：对于一个没有敏捷开发经验，并且成员的能力（无论从哪一方面来看）都是中等的团队，骤然施行敏捷方法，那是必死无疑----推行敏
捷的前几个月内一定是一片混乱，效率低下，问题多多。这样的话，项目经理必死，不同的只不过是看死在客户手里，还是死在公司高层手里，还是死在团队成员
手里。可是如果先拿几个最佳实践来解决团队中突出存在的矛盾/问题，让各方面都感觉到敏捷不是什么古怪的理论，而是实实在在解决问题的好东西，那么再逐
步加进去更多的最佳实践乃至最后形成一个体系，那是水到渠成的。
至于o6z你说的"应该学习最基本的软件开发知识，从开动脑筋自主思考开始"，毫无疑问这是金玉良言。对于渴望学习新知识、新实践的人而言，不是一下子
冲进去敏捷，而是要先有一定的知识基础。而我所希望的，我所谓的经过裁剪的框架，乃是把一些最佳实践引入到我的团队中来，哪怕这个团队中的人并不是那么
地乐意学习新的知识或者乐意接受改变。我享受这样的乐趣，最终改变那些抗拒改变的人...我认为这样很有意思，或许也很有意义。
Andy Wang
> Master的相同点和不同点"，恕我驽钝，我就看不出这个话题体现出一个多么迫切需要帮助的样子。
【AW】我不是张克强，我也不打算比较QA和SM的异同。我不过是说了一句Scrum还不错，o6z说得太偏激了。坦率地说，如果Jeff你是为了张克
强提出的议题而跟我争论，那你表现出了与你年龄不符的冲动。
> 你说这些话，本身就体现出你对现在敏捷在国内是个什么行情根本就不了解。（这也就是为什么像胖子和我这种上了年纪的人一说起这些就缺乏耐性。）现在根本不是有法 无法用起来的问题，而是这波潮流已经被无可逆转地发动起来了，你必须用起来。你可以选择借这个机会把自己的毛病治一治，也可以选择搞搞裁剪敷衍了事。
【AW】你明白为什么要剪裁吗？你认为剪裁后就一成不变了吗？一个团队已经运作了一年了，客户满意度还是可以的，如果不经过剪裁，一下子就把一个完整的
敏捷体系强加给这个团队，你认为是一切顺利，还是一场灾难？在客户/领导层/团队成员的耐心被用光之前，有可能让团队适应敏捷并且走上正轨吗？如果不能
的话，死得很惨的肯定不是客户、领导层或者团队成员！剪裁，是针对团队中存在的问题（尤其是比较突出的问题），首先引入可以立竿见影解决问题的最佳实
践。在这一点上你有什么异议吗？
我明白你理解的"剪裁"，是剪裁出一个东西来放在那里就不变了。问题是我所谓的剪裁不是那样。连确认一下的耐心都没有，这算是什么呢！
> 那么这个邮 件列表到底是希望帮助真想改进的人，还是帮助想跟风想敷衍的人？我心里有一个答案，并且我希望我的答案跟这个列表中大多数人一样。
【AW】谁是真想改进的人，谁又是跟风想敷衍的人呢？换句话说，在整个争论中，你分清敌我友了吗？在你和我的这个年龄上，"分清敌我友"这种事情应该琢
磨透了。
On May 31, 4:47 am, Jeff Xiong <gigix1...@gmail.com> wrote:
> > 敏捷宣言的第一句，请Jeff注意及重温：
>
> > We are uncovering better ways of developing
> > software by doing it and helping others do it.
>
> > 如果不需要把敏捷思想推广开来的话，那么不如把这个"helping others do it"去掉好了。不然啰嗦不啰嗦，虚伪不虚伪？！
>
> 要帮助他人，就应该让需要帮助的人说他需要什么帮助。"QA和Scrum
> Master的相同点和不同点"，恕我驽钝，我就看不出这个话题体现出一个多么迫切需要帮助的样子。你喜欢打医生病人的比方，很好，如果一家诊所成天都是些闲人 在高谈阔论"当归和黄芪的药效"，我请问这诊所还怎么治病救人悬壶济世？如果这个医生真的想帮助病人，他就会先把这些没病唠嗑的闲人赶走。
>
> > 还有，敏捷需要门槛吗？难道只有思维活跃、技术扎实、眼界开阔，并且与一群有团队意识的聪明人合作才有资格用敏捷吗？我做项目管理，遇到了太多愚蠢的、
> > 不合作的、技术差又没有自知之明的技术人员，如果不拿一个起点低的、可裁剪的框架出来，根本敏捷就无法用起来。
>
> > 但是你能因为你的团队成员愚蠢、不合作、技术差又没有自知之明，就判决他/她不配知道敏捷吗？不是每个公司都像Thoughworks一样拥有一批杰出
> > 的工程师，但是如果因此就说那些公司没有资格玩敏捷的话，未免太傲慢了。
>
> 你说这些话，本身就体现出你对现在敏捷在国内是个什么行情根本就不了解。（这也就是为什么像胖子和我这种上了年纪的人一说起这些就缺乏耐性。）现在根本不是有法 无法用起来的问题，而是这波潮流已经被无可逆转地发动起来了，你必须用起来。你可以选择借这个机会把自己的毛病治一治，也可以选择搞搞裁剪敷衍了事。那么这个邮 件列表到底是希望帮助真想改进的人，还是帮助想跟风想敷衍的人？我心里有一个答案，并且我希望我的答案跟这个列表中大多数人一样。
>
> --
> Jeff Xiong
sg552 sg552
胖子
来越承认其实我才是最中庸，并且最不偏激的一个人。之所以他们当初觉得我偏激，其实无非是觉得我有些不通时务，敢于说出某些人
没穿衣服。至于你说了什么，你自己去看你发的贴。也许你忘记了。但是你要明白，这不仅仅是一个mailist。为什么gigix会跟你争论，
其实也很简单，因为觉得你根本就没必要和我争论。张克强算什么东西，我们根本就不在乎。
至于说裁剪，你根本就没搞明白gigix和我都说了什么。
至于说敌我友，其实我们都很清除，不清除的其实不是我们。就我的本意来说我不想跟你争论，但是有些问题在于你的认识里面实在有些
问题。同时我也十分明白，你仅仅是跟张克强一样，还在抱着老一套的知识系统的残余不放手，并且实在是很少关注新的各种讨论而已。
张克强
何以短短的文字会有如此的反应？
何以会有“算什么东西”的用词？
这种用词是不会出现在一般的论坛，
而存在这种用词的这个group叫“敏捷中国”
为了“关注新的各种讨论”，我将继续试图在这里开展讨论。
（BTW 这里有管理员吗？ 如果不同意我发文，直接禁止我发文权限好了，如果我还有权限，我视为还有权发文）
看看谁“抱着老一套的知识系统的残余”？ 还是“抱着老一套的知识系统”的精华？
看看新一套的知识系统到底是什么样的？ 是符合了发展方向？还是过于超前而无法实践？
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
James.Tong(鼠标)
Qi Meng
LiHongxi
变大象
没有想调侃你的意思，发自内心的建议。
Kingfish (Wang Yu)
之前的帖子我没有仔细阅读，但是我希望大家能畅所欲言，跟往常一样。
Best
LiHongxi
Jacky Li
作为一名优秀的咨询师，难道不应该首先要做到对自己的实践和价值观抱有坚定的信念，不妥协，不退缩，嫉恶如仇么？
--
Jacky Li
Agile Consultant @ThoughtWorks
Editor @InfoQ China/Agile
Kaopubulity Evangelist
+86 138 1045 9095
Kingfish (Wang Yu)
在我们追求一些事情的时候，我们是不是思考到了我们已经放弃的内容？
我身边有太多太多的拥有坚定信念，不妥协，不退缩，嫉恶如仇的优秀咨询师了。我只是提醒在另一个方向上也需要我们的思考。
胖子
行的人呆着。真的，能到您这个地步实在是一件非常难得的事情。
----之前的帖子我没有仔细阅读，但是我希望大家能畅所欲言，跟往常一样。
On 6月9日, 下午10时48分, "Kingfish (Wang Yu)" <niuf...@gmail.com> wrote:
> 你说的没错，这就如同精益制造的两个力一样。一个是使流程能够更快的流转，一个是使流程能够快速的停下。但是在你抱有坚定信念的同时不是你的借口，更不是你可以放弃更好沟通方式的借口。
>
> 在我们追求一些事情的时候，我们是不是思考到了我们已经放弃的内容？
>
> 我身边有太多太多的拥有坚定信念，不妥协，不退缩，嫉恶如仇的优秀咨询师了。我只是提醒在另一个方向上也需要我们的思考。
>
> 2010/6/9 Jacky Li <veryfa...@gmail.com>
>
> > "如果你是敏捷的专家，你就更应该像个孩子倾听大人的言语一样。首先认为自己是错误的" 这样的话让我很恍惚。
>
> > 作为一名优秀的咨询师，难道不应该首先要做到对自己的实践和价值观抱有坚定的信念，不妥协，不退缩，嫉恶如仇么？
>
> > 2010/6/9 Kingfish (Wang Yu) <niuf...@gmail.com>
>
> >> 如果说有山头的话，这里是一千两百多敏捷爱好者的山头，而不是某些人的山头。敏捷之所以能够不停进化，主要原因一方面是挑战很多，另一方面是质疑很多。所以正因为是不同的声音诞生了进化中的敏捷。我个人非常讨厌家长式的言传，如果你是敏捷的专家，你就更应该像个孩子倾听大人的言语一样。首先认为自己是错误的，给别人的话一个空间。如果你听不进去别人的话，或者感觉没有耐心，或者要维护自己权威的话。我很高兴的告诉你，敏捷已经离你远了。
>
> >> 之前的帖子我没有仔细阅读，但是我希望大家能畅所欲言，跟往常一样。
>
> >> Best
>
> >> 2010/6/7 变大象 <findh...@gmail.com>
>
> >>> 潜水千万年了，说点自己的看法，现在都不是对错好坏的问题，你的调调这边的伙计不睬你，其实你没必要非得人家合着你的调调，毕竟这是人家的山头，你完全可以自立山头嘛。
> >>> 没有想调侃你的意思，发自内心的建议。
>
> >> 在 2010年6月6日 下午10:14，LiHongxi <lihxa2...@gmail.com>写道：
>
> >>> 我个人认为敏捷本身源自于实践，只是有高度。它是自下而上的。因为实践者本身的环境，风格有差别，自然认识也就有了差别。
>
> >>>> 在 2010年6月6日 下午3:11，张克强 <zhangkeqi...@gmail.com>写道：
>
> >>>> 我在想：我动了谁的奶酪？
> >>>>> 何以短短的文字会有如此的反应？
> >>>>> 何以会有"算什么东西"的用词？
> >>>>> 这种用词是不会出现在一般的论坛，
> >>>>> 而存在这种用词的这个group叫"敏捷中国"
>
> >>>>> 为了"关注新的各种讨论"，我将继续试图在这里开展讨论。
> >>>>> （BTW 这里有管理员吗？ 如果不同意我发文，直接禁止我发文权限好了，如果我还有权限，我视为还有权发文）
> >>>>> 看看谁"抱着老一套的知识系统的残余"？ 还是"抱着老一套的知识系统"的精华？
> >>>>> 看看新一套的知识系统到底是什么样的？ 是符合了发展方向？还是过于超前而无法实践？
>
> >>>>>> 更多选项，请访问http://groups.google.com/group/agilechina
>
> >>>>> --
> >>>>> 张克强
> >>>>> blog:http://hi.baidu.com/hespr
>
> ...
>
> 阅读更多 >>
胖子
On 6月9日, 下午10时16分, LiHongxi <lihxa2...@gmail.com> wrote:
> 现在，我个人认可这个观点, 有争论是可以的，但能做到倾听，是否是一种进步呢？
> 虽然，虽然说坛子里有很多敏捷方面的专家和领路人，但从另一个角度来看允许发问，或许也是一种进步。
> 我个人就从楼主的贴子里也学到敏捷方面的知识，开拓了视野。
>
> 在 2010年6月9日 下午12:21，Kingfish (Wang Yu) <niuf...@gmail.com>写道：
>
>
>
> > 如果说有山头的话，这里是一千两百多敏捷爱好者的山头，而不是某些人的山头。敏捷之所以能够不停进化，主要原因一方面是挑战很多，另一方面是质疑很多。所以正因为是不同的声音诞生了进化中的敏捷。我个人非常讨厌家长式的言传，如果你是敏捷的专家，你就更应该像个孩子倾听大人的言语一样。首先认为自己是错误的，给别人的话一个空间。如果你听不进去别人的话，或者感觉没有耐心，或者要维护自己权威的话。我很高兴的告诉你，敏捷已经离你远了。
>
> > 之前的帖子我没有仔细阅读，但是我希望大家能畅所欲言，跟往常一样。
>
> > Best
>
> > 2010/6/7 变大象 <findh...@gmail.com>
>
> >> 潜水千万年了，说点自己的看法，现在都不是对错好坏的问题，你的调调这边的伙计不睬你，其实你没必要非得人家合着你的调调，毕竟这是人家的山头，你完全可以自立山头嘛。
> >> 没有想调侃你的意思，发自内心的建议。
>
> > 在 2010年6月6日 下午10:14，LiHongxi <lihxa2...@gmail.com>写道：
>
> >> 我个人认为敏捷本身源自于实践，只是有高度。它是自下而上的。因为实践者本身的环境，风格有差别，自然认识也就有了差别。
>
> >>> 在 2010年6月6日 下午3:11，张克强 <zhangkeqi...@gmail.com>写道：
>
> >>> 我在想：我动了谁的奶酪？
> >>>> 何以短短的文字会有如此的反应？
> >>>> 何以会有"算什么东西"的用词？
> >>>> 这种用词是不会出现在一般的论坛，
> >>>> 而存在这种用词的这个group叫"敏捷中国"
>
> >>>> 为了"关注新的各种讨论"，我将继续试图在这里开展讨论。
> >>>> （BTW 这里有管理员吗？ 如果不同意我发文，直接禁止我发文权限好了，如果我还有权限，我视为还有权发文）
> >>>> 看看谁"抱着老一套的知识系统的残余"？ 还是"抱着老一套的知识系统"的精华？
> >>>> 看看新一套的知识系统到底是什么样的？ 是符合了发展方向？还是过于超前而无法实践？
>
> >>>>> 更多选项，请访问http://groups.google.com/group/agilechina
>
> >>>> --
> >>>> 张克强
> >>>> blog:http://hi.baidu.com/hespr
> >>>> 通过高效过程追求卓越结果！无论是敏捷或CMMI或其它。
>
> >>>> --
> >>>> 敏捷中国http://www.agilechina.net邮件列表
> >>>> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> >>>> 如欲退订请发送邮件到 agilechina-...@googlegroups.com
> >>>> 更多选项，请访问http://groups.google.com/group/agilechina
>
> >>> --
> >>> 敏捷中国http://www.agilechina.net邮件列表
> >>> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> >>> 如欲退订请发送邮件到 agilechina-...@googlegroups.com
> >>> 更多选项，请访问http://groups.google.com/group/agilechina
>
> >> --
> >> 敏捷中国
>
> ...
>
> 阅读更多 >>
胖子
自然角色之类的话就不说了，因为说了他也不懂，基础知识差，不是一
天两天能解决的。我只说点明显的，而且可以快速查到的事情。当然是
点到为止，不会铺开评论。因为我觉得多说一句都是浪费。
QA的职责是啥呢？SCRUM MASTER的职责又是啥呢？QA是流程的维
护者，而SCRUM master是scrum流程的防火墙。此流程非彼流程，是
其一。防火墙不是维护者，此其二。当然还有三四五，自己去想吧。不
想也行，能明白我说的前两点就够用了。
On 6月6日, 下午8时51分, Qi Meng <smit...@gmail.com> wrote:
> 期待o6z的精彩点评！
>
> 在 2010年6月6日 下午3:54，James.Tong <tj19...@gmail.com>写道：
>
> > 下集预告？蛮煽情的。
>
> > 2010/6/6 张克强 <zhangkeqi...@gmail.com>
>
> > 我在想：我动了谁的奶酪？
> >> 何以短短的文字会有如此的反应？
> >> 何以会有"算什么东西"的用词？
> >> 这种用词是不会出现在一般的论坛，
> >> 而存在这种用词的这个group叫"敏捷中国"
>
> >> 为了"关注新的各种讨论"，我将继续试图在这里开展讨论。
> >> （BTW 这里有管理员吗？ 如果不同意我发文，直接禁止我发文权限好了，如果我还有权限，我视为还有权发文）
> >> 看看谁"抱着老一套的知识系统的残余"？ 还是"抱着老一套的知识系统"的精华？
> >> 看看新一套的知识系统到底是什么样的？ 是符合了发展方向？还是过于超前而无法实践？
>
> >>> 更多选项，请访问http://groups.google.com/group/agilechina
>
> >> --
> >> 张克强
> >> blog:http://hi.baidu.com/hespr
> >> 通过高效过程追求卓越结果！无论是敏捷或CMMI或其它。
>
> >> --
> >> 敏捷中国http://www.agilechina.net邮件列表
> >> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> >> 如欲退订请发送邮件到 agilechina-...@googlegroups.com
> >> 更多选项，请访问http://groups.google.com/group/agilechina
>
> > --
> > best regards,
> > James
>
> > --
> > 敏捷中国http://www.agilechina.net邮件列表
Kingfish (Wang Yu)
我也很乱，或者大家能不能列一列 各个公司的QA在当前项目或者组织中的职责？
胖子
丑。
On 6月11日, 上午8时05分, "Kingfish (Wang Yu)" <niuf...@gmail.com> wrote:
> 在国内，很多企业的QA承担的职责各不相同，有的负责流程优化、有的负责发掘软件缺陷、有的和Scrum
> Master承担的责任大体相同。大家说的这些区别和我脑子里的区别还是有差别的。所以说非常混乱，角色虽然各不相同或者理解可能有所偏差，但软件项目中的那些职责需要有人负责。比如说前面说到的发掘缺陷、优化流程。
>
> 我也很乱，或者大家能不能列一列 各个公司的QA在当前项目或者组织中的职责？
>
> 2010/6/11 胖子 <ozzzzzz....@gmail.com>
Yin Wenyan
假设"优化流程"与写代码无关的话，窃以为这件事不必有专人负责，甚至可以不必有人负责。
对于许多开发团队来说，扎扎实实、认认真真把代码一行一行堆好、堆结实了----让我们暂且称之为"优化代码"吧----效果远比"优化流程"好。等到"优化代码"搞得差不多了，"优化流程"只不过是茶余饭后的小case罢了。
拙见，拙见，欢迎拍砖。
--
Best regards,
YIN Wenyan
2010/6/11 胖子 <ozzzz...@gmail.com>:
> --
> 敏捷中国 http://www.agilechina.net 邮件列表
周迪
所以我觉得还是跟人有关,如果有一帮积极上进和高水准的团队,我想采用更合理的管理和开发方法会更有效.
周迪
James.Tong(鼠标)
胖子
去踏踏实实的事情呢？其实原因很简单，那就是现在是一个机会，一个很难出现的机会，一个瞬间即逝的机会。
历史上是不是出现过这样的机会呢？有的，那就是cmm刚推行开来，在国内刚成气候的时候。那时候，虽然大家对cmm的理解不一样，但是都知道应该作点什
么，而且也必须作点什么，即便不懂业务的领导，也知道必须采取点措施。现在为什么scrum这么火爆，其实就是这样的机会又来了。但是就如同上次机会出
现的时间很段，也就是个半年，这次虽然可能会长一点，但是也不会长很久，最多一年。而上次究竟是些什么人取得了良好的效果呢？是哪些忽悠的顾问，还是哪
些实干的第一线呢？说实在的，在那个时候真正作成贡献，并且一直都对人对己大有好处的，就是一类人，也就是在上次作源代码管理普及的那些人和企业。而这
次在scm这块作事情就有点累了，应该从单元测试/重构这里入手，当然如果能够有领导的强力支持，作持续集成也会很见效。但是注意时间就这么些，你不赶
快采取行动，马上就没机会了。
而这种紧迫的情况下，一个最重要的点，就是绝对不能犯夸夸其谈，务虚不务实的毛病。比如套了个什么流程优化了，啥项目管理了，啥人员培养阿，啥绩效管理
了。我不是说这些不重要，这些当然重要，但是就目前这个节骨眼，这些事情可以先放一放，先从可以直接对写更好质量的代码这里入手。这个是一刻都不能耽误
的事情。其他事情，以后有的是时间和精力叫你们去做。
当然从另外一个方面来说，比如说我这样的，已经没有什么热情搞敏捷了，在转向新的方法探索了，那自然可以作与敏捷无关的研究了，为下一个的新浪潮的来临
作准备。但是就我看，这里有我这个水平和能力的人没有，所以你们也别来跟我一起扯淡，我也不会跟你们扯这个淡。但是你说，你就是不想抓住这个机会，就是
想仔细研究点敏捷的细节，我觉得也不是不行。但是你要拿出点细致研究的劲头和成果出来，别什么角色和岗位都不明了就来谈啥区别，也别根本就不知道
scrum master的主要职责就来谈什么谁谁谁是不是可以作什么什么的，更加不是随便看一个帖子就说：哎呀！我收获很大阿，又搞明白了很多知识。
真的你们要研究，可以研究研究为什么cmm会全线的溃败，当然除了我以前总结的内在的原因，必然还有外在的原因。而这些外在的原因，未必就是cmm自身
所独有的，敏捷也可能会有相关的问题。这就是很好的研究入手点吗？
就比如这个QA的问题，这个PIG的问题。难道CMM确实的说你公司里面必须要有一个QA的岗位吗？必须说你要有专职的测试人员吗？必须要有一群人的工
作牌上写这PIG吗？那为什么落实到实际，你看看那个实施cmm的企业不是委员会满天飞，QA纯扯淡，PIG是毕业研究生无能的代名词呢？而你可以联系
现在scrum实施的情况来说说阿。比如现在都是些什么人在热情推scrum，为什么这些人会出来说QA可以作SCRUM master，为什么到了很
多企业以为敏捷就是站立会议加每月一次的总结会呢？这些事情都是有联系的，都是不难想明白的。
说实在的，你们想扯淡，等过了今年我好好的给你们扯一下，就你们这个鸟水平还好意思跑我面前来扯这些牛皮，实在是班门弄斧。而且即便你们扯了，又能有什
么效果呢?最多也就是在这里多拉了几泡屎，叫这更加臭一些。其实你们没必要着急，在过个半年大家见面互相问候就该说，你敏捷了，你才敏捷呢，你一家都敏
捷了。不着急，你们在忍忍，敏捷成为臭狗屎的时候不远了。
On 6月11日, 下午2时09分, James.Tong(鼠标) <tj19...@gmail.com> wrote:
> 如果这事不做，那不等于说不找好工人还想把盖楼的速度提得很高。资本家喜欢这个，但这不现实。
>
> 2010/6/11 周迪 <zhoudi77...@gmail.com>
>
>
>
> > 不能同意你更多.其实这些都是建立在大家都把代码写的很规范,或者结构很好的基础上.起码相对来说好一些.在这样的基础上再做更高层次的规划.很多本身代码都写不好的就不要谈了.
>
> > 所以我觉得还是跟人有关,如果有一帮积极上进和高水准的团队,我想采用更合理的管理和开发方法会更有效.
>
> > 在 2010年6月11日 上午10:48，Yin Wenyan <yiw...@gmail.com>写道：
>
> > > 角色虽然各不相同或者理解可能有所偏差，但软件项目中的那些职责需要有人负责。比如说前面说到的发掘缺陷、优化流程
>
> >> 假设"优化流程"与写代码无关的话，窃以为这件事不必有专人负责，甚至可以不必有人负责。
>
> >> 对于许多开发团队来说，扎扎实实、认认真真把代码一行一行堆好、堆结实了----让我们暂且称之为"优化代码"吧----效果远比"优化流程"好。等到"优化代码"搞得差不多了，"优化流程"只不过是茶余饭后的小case罢了。
>
> >> 拙见，拙见，欢迎拍砖。
>
> >> --
> >> Best regards,
> >> YIN Wenyan
>
> >> 2010/6/11 胖子 <ozzzzzz....@gmail.com>:
> ...
>
> 阅读更多 >>
James.Tong(鼠标)
我是悲观了一点了。
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--
best regards,
James
Kingfish (Wang Yu)
人和动物最大的区别是能够发明和使用工具，但是当我们手里有锤子的时候就会到处寻找钉子。因为环境的复杂性，我们会不自觉的寻找捷径。虽然这是进化过程的先进成果，用以处理纷杂的信息和做出相对正确的选择，但我们渐渐的成为了工具的工具。不要以为占硬盘几个Gb启动需要半分钟的东西叫工具。身边的故事卡片、经常参加的会议、或者说那一堆一堆的测试代码，这些都是工具。
宇宙流更适合于取势，秀策流更适合于取地。高手们都这么说。但对我来说，走宇宙流也不一定取得了势，取得了势也不一定围成大肚皮，围成了肚皮也不一定够 大。其中的关键在于，我不是高手。 (此段摘抄)
所以把东西都尝试扔掉吧，看看你能不能写出好软件。然后再一个工具一个工具的加上。
一般很少看电视的我和媳妇打开电视，央视6，从头到尾看了一遍《智人》还有后面跟着的片子，名字忘掉了（央视还有点好片）。片子最后有一句话：我们不知道我们要走向何方，但我们知道我们从何而来。
对于敏捷来说我们也可能不知道它要走向何方，但是我们清楚它诞生的理由。
纵观发展，软件开发从 崇尚可预测性到 崇尚价值。这不正是一个进化过程吗？进化到现在的价值观：沟通、简单、反馈、勇气、尊重。敏捷所推崇的价值观难道和我们的生活没有联系吗？我们不光在软件领域需要这些，我们同样在生活中需要这些核心价值观。这样我们才能形成更好的共识，实现发展。
值得我们思考吗？
2010/6/11 James.Tong <tj1...@gmail.com>
Jacky Li
不懂生产就不知道哪里是现场，
即便知道哪里是现场可能也看不懂，
即便能看懂现场也未必看得到问题，
即便看得到问题也未必能知道问题的根源，
即便知道问题的根源也提不出解决方案。
这样的人跑到团队里边来指手画脚不就是一件令人愤怒的事情么。不仅仅是可惜而已。
--
Kingfish (Wang Yu)
如果有这样得人跑到团队指手画脚的话，我想你应该有除了愤怒以外的行动（千万别动手） 。
;)
Jeff Xiong
2010/6/12 Kingfish (Wang Yu) <niu...@gmail.com>:
> 一个人把着方向盘，一个看着地图
Xiao Li
张磊
我其实懒得把SCRUM的事情说太明白，免得断了别人的财路。但是你们一次一次挑战我的底线，于是我就挤牙膏一样一次一次向外压出一点我的真实看法。
首先你说的很对SCRUM就是一层皮，并且如果你要是想搞得好，就只能让起仅仅起到一层皮的作用。就如同我在多个场合说的，SCRUM是一个永远的老二
方法，不是能是核心方法。他的好处就在于，几乎可以跟任何方法（老的方法新的方法以及未来的方法）结合使用。
为什么会这样呢？首先SCRUM的内核很小，其次内容简单，再次作用和副作用都小（也就是属于作用非常有限的方法）。本身如果你有知识基础，这个方法用
5分钟给你解释就够了。但是你偏偏要把其他一些东西向SCRUM这里装，那自然就会很混乱。而恰恰由于SCRUM方法的无侵害性，也造成你可以向里面放
任何东西。
而进一步，SCRUM必然是不能解决实际的开发核心流程问题，也就是如此才能保证其应用范围。其次由于其不具备开发的核心问题的关注性，也就无法作为入
门方法。这两点尤其重要。也就是如果你们那里本身是混乱的，那么你们的scrum搞的再好，依然会是混乱的。
那么是不是说这样的话scrum就没什么价值了，没必要去研究和应用了吗？恰恰相反，这样的方法价值巨大，而且你研究现有的方法，基本上没有其他方法具
备scrum的这种特征。而你去研究其他方法，你会发现这些方法都不能做大完全覆盖开发的所有方面，而你去具体实施的时候你也明白必然要涉及所有的方
面。那么用scrum填补这个空白就太合适了。其次其他方法，也往往仅仅是一种或者几种最佳实践的组合，那么用什么胶水来组合他们呢？用scrum。而
另外一个方面，你往往要涉及新方法和老方法的结合问题，这个时候用什么来调整呢？scrum。
这就好比我学的药学里面的附形剂，不具备任何药理作用，但是你作药必须用这个东西。
On 5月30日, 上午5时30分, Andy Wang <hrbe...@gmail.com> wrote:
> o6z说得很犀利，也很值得去思考。不过对于Scrum的批判还是偏激了。也许是爱之深恨之切吧。
>
> 我同意现在Scrum社区，国内外都有比较混乱的现象，经常是一个组织或者一个pm声称采用了Scrum，但是细去推敲，他们的做法无非是批上了
> Scrum术语的外皮，骨子里还是以前的那一套。我公司里一个才工作了两年就趾高气昂目空一切的小孩，竟然说SM由客户来担当…………然后GM还挺欣赏
> 他的…………看来离我跳槽也不远了。
>
> 不过不管怎样，Scrum作为入门起点比较低的一个敏捷框架，有它的优势。它本身比较容易兼容其它敏捷最佳实践，与其说它是方法或者流程，不如说它是一
> 种指导性思想，在其基础上可以参照团队和公司的状况裁剪出合适的框架出来。比较起XP这种几乎不能裁剪的框架，想要把敏捷思想推广开来，也许Scrum
> 的贡献会更大一些吧。
>
> On 5月28日, 下午11时57分, 胖子 <ozzzzzz....@gmail.com> wrote:
>
> > 岗位是什么，角色是什么你还是没搞明白。
> > 那戏剧来说，角色就是剧本里面的那个人物，并被演员所表现在舞台上。显然，一个角色可以由多个演员来表演，一个演员也可以扮演多个角色。角色之间不存在
> > 什么互相扮演的问题，除非是戏剧中的戏剧。
> > 所以我说你这个根本就是扯淡。
> > 当然问题并不完全在你，而是本身scrum这个圈子就是垃圾堆，包括你说的那些老外，有多少是头脑清醒的？
> > 现在的唯一明治做法，就是在敏捷圈子内部少说什么scrum。否则就是自取其辱。
>
> > 其次我在给你说点具体的事情。
> > 比如第一你说什么不直接评价员工个人绩效 ，这显然就是一种误解。因为绩效的评价方式有很多种，其中很多现代流行的（比如平衡积分卡），其实就是这个绩
> > 效来自所有你周围的环境，包括你的QA和SCRUM团体成员。而又不仅仅是来自一个个人，因为是来自一个系统。所以你说的这个根本就是白说，除了显示你
> > 对绩效考核的无知，其他根本就代表不了什么。
> > 其次你又说，他们关注于过程是否符合要求。 这也是瞎说。因为SCRUM Master关注的和维护的是Scrum流程，而不是过程。过程要比较大很
> > 多，也复杂很多。而QA也仅仅只能关注一小部分。这个是软件工程常识，你不知道或者你很混淆，只能说明你还差得远。
> > 并不在项目团队中直接做决策，这依然很可疑。因为QA其实也是要作决策的，并且任何人只要在企业内部工作，都要作决策，否则这个人根本就没必要存在。这
> > 里的问题是，你把不把这个QA纳入你的团队，这个是你的企业组织结构问题，我建议以你目前这个知识水准还是别讨论了。而明确的说凡是关于SCRUM流程
> > 的决策，都是由SCRUM master作成的，否则还要这个角色干吗，除非你认为他本身就是一个饮水机卫士。
>
> > 其次你下面说的不同点，问题就更多，基本上每一条都是筛子，禁不起推敲。
>
> > 其实你已经很能代表国内国外目前SCRUM社区的情况，那就是什么都不懂，什么基本也没有，参加了一个培训，立马就声称敏捷了。动不动就把SCRUM跟
> > 敏捷画等号。说实在的，SCRUM社区的还没有CMM社区的风气好，水准高。敏捷要不被你们搞跨，那就奇怪了。
>
> > On 5月28日, 下午4时08分, 张克强 <zhangkeqi...@gmail.com> wrote:
>
> > > 看到了有些组织让QA来担当Scrum Master，试图通过比较QA和Scrum Master的差异来看看QA如何做好Scrum Master？
> > > 如果比较的路走不通，那么问问各位： QA如何做好Scrum Master？ 这里有两种情况，1是项目经理仍然存在 2是项目经理没有了
> > > 有没有较好的实例？
>
> > > 在 2010年5月28日 上午9:17，胖子 <ozzzzzz....@gmail.com>写道：
>
> > > > 我觉得你把角色和岗位这些最基本的概念搞明白之后再来发言比较好，这种纯粹的扯淡的发言也会少很多。
>
> > > > On 5月28日, 上午2时52分, 张克强 <zhangkeqi...@gmail.com> wrote:
> > > > > 收集CMM/CMMI的QA和Scrum Master的相同点和不同点，以下是当前看到的，请大家补充、修订。
>
> > > > > 相同点
> > > > > 1，不直接评价员工个人绩效
> > > > > 2，关注于过程是否符合要求
> > > > > 3，并不在项目团队中直接做决策
>
> > > > > 不同点：
> > > > > 1，QA一般不是项目开发人员，QA一般同时参与多个项目，而Scrum Master可能只参加一个项目，并承担开发任务。
> > > > > 2，QA问题会有提升的途径，当QA问题不及时解决时，QA问题会提升到高级管理者，Scrum
> > > > > Master一般在团队内部解决问题，只有碰到实在必须解决又自身无法解决时，才会提升到管理层。
> > > > > 3，QA所依据的一般来自于组织既定的规程，一般来说内容覆盖方方面面，有规范的体系；Scrum
> > > > > Master所依据的一般来自于Scrum本身和团队达成的共识，一般来说更有针对性，但也许未必成规范的体系。
>
> > > > --
> > > > 敏捷中国http://www.agilechina.net邮件列表
> > > > 更多选项，请访问http://groups.google.com/group/agilechina
>
> > > --
> > > 张克强
> > > blog:http://hi.baidu.com/hespr
> > > 通过高效过程追求卓越结果！无论是敏捷或CMMI或其它。
张磊
我一向认为，裁剪就是一种很扯淡的做法。别人设计了一套方法，照着这个方法去做就能把软件做好，那么这个方法里的各种元素肯定是彼此帮助彼此关联的。而你之所以要采用这种方法，当然是因为你现在做得不够好，你需要这种方法来指导你改进。结果你拿起这套方法来，做得到的就做，做不到的就裁剪掉，那我请问了，如果你都是在做你本来就做得到的事，你的改进又以什么方式发生呢？人家一个方法本来就是要你在做不到的那些地方改进，去把它做到，然后你的能力就提升了，软件就能做好了。你来个裁剪，人家要你改进的东西你不改进，完了软件没做好就哭喊“啊啊敏捷不行啊～～”──敏捷叫你做的事你都没做，你有啥资格说敏捷行不行啊？
2010/5/30 Steven Mak <stev...@gmail.com>:
> Scrum 不是一套給人作裁剪的框架，裡面的東西已經很少了。
>
> Scrum 可能算是容易理解，但不能算是入門起點低，我相信有些公司多給它十年時間也做不好，還提出多多藉口嘗試去 "剪裁" 到合他們心意的狀態，
> 更嚴重的是他們其實在 "剪裁" 過程中無視了最深入的問題。
>
> 還有，Scrum 雖然沒有指定什麼工程實踐，好的團隊還是需要在這方面提高水準，Scrum Master 亦應當提倡使用好的實踐方法，用最好的方
> 法去交付高質量的產品。
>
--
Jeff Xiong
Software Journeyman - http://gigix.agilechina.net
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
--
张磊
前几天去一个会议，中午吃饭的时候饭桌对面一位女士拿着筷子指着我说想我点问题。她说她是企业中的过程改进人员，敏捷的实践她们已经应用若干，问我还有没有别的实践。我尝试跟她说敏捷不光是一堆实践，关键是团队自身的具体问题还有是否正确或者合适的使用了敏捷实践。她说这些东西不用我操心，她就需要知道是不是又更新鲜的实践。尝试未果的我只好向她推荐了本关于实践的书，说书里列出了很多实践并且有在何种场景使用的说明。
Xu Yi
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -