大家有人在用SCRUM吗？（技术讨论，长贴慎入）

woodheadz

原帖由 coredump 于 3-6-2011 22:57 发表

                               
登录/注册后可看大图

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。 现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

哈哈，同感！
我觉得把很多精力花到过程里是件很恶心的事，尤其对小点的团队而言，大家遵循一些尽量简单的基本原则就好，出现问题再针对问题个别解决。
对于大团队嘛，最佳实践就是把它分成小团队

[ 本帖最后由 woodheadz 于 3-6-2011 23:04 编辑 ]

key

原帖由 coredump 于 3-6-2011 22:57 发表

                               
登录/注册后可看大图

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。 现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

这个事老core说过两次了，
但每次都只是点到即止，希望能多分享一下。

空山鸟语

在国内做项目的时候我一般也是用“混搭”的，介于瀑布模型、XP之间。我自己认为实际效果还不错，项目成员都很happy，客户很满意，项目的成本进度都控制的很好。其实一个项目管得好或者不好，多会有一种特殊的smell。不用讲太多理论模型，如果大家都觉得不爽那就肯定是有问题了。估计真正的Agile原教旨主义者也就是Thoughtworks这种公司吧，大部分公司都是以混搭为主的。
俱往矣，数澳洲IT民工，算我一个。来了这面带队做项目的机会估计比较渺茫了。

最近赋闲在家，每天富裕时间一大把，正好翻箱倒柜把自己不太熟的东西拿出来晒晒。通过大家的讨论，基本看清了，scrum真的是黔之驴啊。下次Interview的时候如果有人再提scrum就可以理直气壮地直接鄙视回去了。呵呵。

key

原帖由 空山鸟语 于 4-6-2011 14:42 发表

                               
登录/注册后可看大图

在国内做项目的时候我一般也是用“混搭”的，介于瀑布模型、XP之间。我自己认为实际效果还不错，项目成员都很happy，客户很满意，项目的成本进度都控制的很好。其实一个项目管得好或者不好，多会有一种特殊的smell。 ...

呵呵，还是小心点。
要知道全球目前大量软件公司转向Agile，
以你个人的观察和思考就下结论，未必有说服力。

yuba

支持“混搭”，但是不要说“混搭”，要说 customised scrum process，重音在scrum上

等过些年scrum不流行了，谈起这段经历，重音放在customised上

sliuhao

原帖由 yuba 于 8-6-2011 13:21 发表

                               
登录/注册后可看大图

支持“混搭”，但是不要说“混搭”，要说 customised scrum process，重音在scrum上

等过些年scrum不流行了，谈起这段经历，重音放在customised上

老油条

空山鸟语

This is really really a good idea!

black_zerg

agile 四个目标还是没什么问题的，其实说的就是不要瞎搞，总之要让客户高兴，结果后来那些方法我觉得都是反agile的

liluliang

scrum实在不适合业务逻辑相对复杂的系统
前几周公司内部推广了jira上的一个新组件GreenHopper，说是专门支持scrum模型的
刚开始花花绿绿的挺好看
后来上百个card一出来，我看了真想吐
现在已经没人用了。。。

空山鸟语

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能力了。在小纸片上写用例肯定表达能力不如UML里的用例那么强，而且数量还不能太多，那就只能适合很小的项目了。

woodheadz

原帖由 空山鸟语 于 8-6-2011 14:42 发表

                               
登录/注册后可看大图

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能 ...

我们现在的产品待实现的story上百个,还不是好端端的在用Backlog。 Backlog又不是用来描述需求的，里面的项目仅仅是一个周期里面要完成的内容，能有多少呢？你把所有的用例一股脑放到backlog里，还指望完全依赖Backlog帮你管理需求，当然用起来就很头疼。
一个方法提出来，具体应用时得根据实际情况确定应用方法，生搬硬套用起来当然就很别扭。
Scrum的确不大合适太大的项目， 但这个和用例数量是没有关系的。

Richard.G

原帖由 空山鸟语 于 8-6-2011 14:42 发表

                               
登录/注册后可看大图

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能 ...

我是真倒霉啊，从来没有碰到agile或者scrum的项目，看来waterfall和V－MODEL要用到老了。。。。  

空山鸟语

你家娃贵姓？看起来好口爱啊。

Richard.G

原帖由 空山鸟语 于 8-6-2011 15:53 发表

                               
登录/注册后可看大图

你家娃贵姓？看起来好口爱啊。

  谢谢！！ 俺家娃的确怪腔比较多。不过楼歪的太厉害了，哈哈

ginobilis

我自己是certificated scrum master. certificated scrum product owner,certificated scrum developer但是我也不太喜欢用scrum
对于中小型项目来说  客户是挺喜欢scrum的。风险最小，每个sprint做出来的都是priority 最高 potential shipable product. 就算最后项目出现问题。最大价值的部分也都deliver了
但是对于程序员来说scrum那么繁多的ceremonies就感觉死板，甚至不Agile了。有些企业执行了scrum 但不agile，比如yahoo
像TDD，当然有很多好的方面，但是我也确实感觉到影响了我的开发效率，总之不爽
总体来说scrum太注重deliver，对于架构设计很忽视，我不认为能适用于大型项目
当然我觉得学学还是好的，比如学学scrum的CI 标配selenium + hudson + SVN+sonar 虽然我还没来澳洲，但scrum那些破证和一通吹牛搞不好哪天来澳洲找工作会有那么点用呢  呵呵

空山鸟语

楼上是专家了。
我只是自己简单分析了一下Scrum的特点，不知道说得对不对，见笑了。Scrum既然这么火，肯定也有它一定的道理的。真心希望楼上给多介绍介绍Scrum主要的优势和价值在哪里。
我的几个主要疑问1是感觉Scrum好像更侧重开发团队的内部管理，对于需求方面涉及的比较少，不知道是不是这样；2 是对于Scrum团队的管理模式比较疑惑，请问在一个标准的Scrum项目里项目经理处于什么位置呢？

ginobilis

原帖由 空山鸟语 于 14-6-2011 22:37 发表

                               
登录/注册后可看大图

楼上是专家了。
我只是自己简单分析了一下Scrum的特点，不知道说得对不对，见笑了。Scrum既然这么火，肯定也有它一定的道理的。真心希望楼上给多介绍介绍Scrum主要的优势和价值在哪里。
我的几个主要疑问1是感觉Scrum好像更侧重开发团队的内部管理，对于需求方面涉及的比较少，不知道是不是这样；2 是对于Scrum团队的管理模式比较疑惑，请问在一个标准的Scrum项目里项目经理处于什么位置呢？

我也是混混，Scrum只主要价值就是降低项目风险 最短时间交付最有价值部分。但是也正是因为太注重交付，我认为就有点不Agile了
以我个人的观点，Scrum对需求的要求可以概括成Adapter to client。所以很欢迎有任何需求变更，那scrum观点来讲，一开始就把需求考虑得很完善很详细，本来就不Agile了。还是做一步交付一步，随时让客户满意这种方式更好。甚至每个Sprint Review时候要交出来的product，也没有任何文档或PPT - 'Slides are lies'。 Review meeting上，让product owner玩交付的产品玩到满意，那就是scrum就最终目地达到。在Scrum实践中，需求最细化的文档很多就是细化的user story，比如里面对各个字段的要求进行说明。
Scrum项目里没有项目经理，只有scrum master，其实你前面也提到，scrum master没有起到管理作用，主要任务是对项目排除一切障碍。这种管理模式其实和scrum的起源也有关，scrum起源于橄榄球运动，这项运动本质上要求各个队员竭自己所能，没有明确的分工。“每个成员都可以干所有的事情，每个成员又都有选择权干自己最能干的事情。” PM的角色被基本弱化了。Master除了领导一些常规事务外，和其他开发人员也没啥区别。Scrum team 里只有三种role: Scrum master, team member, Product owner. PM这个角色是不存在的。

Scrum好处主要站在客户角度，确实对于中小型项目而言。如果很好实践，scrum客户满意度超高。一来TDD+CI等上去后  代码质量绝对有交代，二来每个礼拜都交付，客户风险很小。我们瀑布经常碰到的问题就是整个项目delay，客户恼火。但是以每个sprint交付的模式，而且还是所有user stories已经被prioritized的情况下。客户认为最有价值的东西以最短的时间进行交付，即使最后因为经济原因项目终止，大多数可用的价值已经被交付。因为Scrum对交付的要求很高，必须是potential shipable product。所以根据我的经验 中小型客户还是欢迎scrum的

[ 本帖最后由 ginobilis 于 15-6-2011 00:43 编辑 ]

空山鸟语

哦，那我估计Scrum项目在签合同的时候肯定不是固定总价合同，而是按照人月工时计价的。不知道是不是这样？

ginobilis

原帖由 空山鸟语 于 15-6-2011 07:52 发表

                               
登录/注册后可看大图

哦，那我估计Scrum项目在签合同的时候肯定不是固定总价合同，而是按照人月工时计价的。不知道是不是这样？

我做technical consulting的  确实是按工时计价，但是关于这个问题我跟scrum training讨论过。他认为即便是传统的固定合同，以TDD+每个sprint交付这种形式，风险也比传统方式小很多。因为传统瀑布容易把风险积累到最后不可收拾，scrum把风险分散了。而且就算合同是传统的，一般客户也愿意参加每个sprint的review来验收功能模块，客户还是希望早点看到能运行的功能的。

如有兴趣 可以参考下我公司里某个scrum 项目的现实进程   http://blogs.perficient.com/mult ... ficient-scrum-team/