c***d
发帖数: 996 | 1 mitbbs programming board 内部交流， 谢绝转载。
第二个game更长。 这个game是把26个人分成两个组，每组都要用一摞木板在地板上搭
成一个pattern. pattern的图纸画的很简单， 就是几个box在一起。这个game是计时的
， 记录是20.5秒。
只有一套木板，两个组有点互相compete的意思。一个组可以先拿图纸planning, 另外
一个组可以拿木板practice。 每个组都有三次planning和practice的机会， 每个
planning/practice的session是十分钟。
我们组挑的是先practice, 大家拿到木板才发现， 木板不但长短不一样， 每块木板的
开口也不一样。 开始大家试图拼起来， 但是过了八分钟也没有拼好， 于是决定记住
了总共有几种木板长短， 就开始了第一个planning session。
第一个planning session是试图把每块木板在图纸上编号， 然后把图纸和木板对应起
来。我们记住了一共有五种木板长度， 第一种最短， 第五种最长， 五种长度的木板
个数是3 3 2 4 2。 我们试图把这个对应到图纸上。 但因为图纸画的很简略， 当木板
长度差别不明显的时候， 就不好判断。我们知道了第一种和第五种， 第二三四种从图
纸上看不出来。 不过可以从图纸上判断的是每个木板上面有几个开槽。
第二个practice session, 我们把第五种和第一种先按图纸摆好， 然后把剩下的九块
木板按图纸拼出来。 大概在不到五分钟的时候， 我们第一次拼好了这个pattern. 拼
好了以后， 我们决定按顺序一个一个的把pattern 拆掉， 每个人按顺序拿一块木板，
最后一个人拿两块。 每个人记住自己拿的木板。拆的时候有点混乱争论， 到十分钟
的时候才拆完。
第二个planning session， 我们team很有意思的自发分成了三组， 一组人试图在图纸
上重现拆的顺序， 另外一组人试图把木板在图纸上编号， 然后assign给每个人。 最
后一组人在纸上按拆的顺序写下每个人的名字。 每个人不确定自己拿的木板拆的时候
到底是在什么位置， 但是都知道两件事： 1） 自己拆的时候拿的是哪种长短的木板，
上面有几个开槽， 大概是怎么放的。2）在前面拆的人是谁， 后面的人大概是谁。大
家写完名字就排成了一队， 每个人都知道上面这两件事情。这个时候十分钟到了。大
家已经开始兴奋的估计到底会用多少时间了， 三分钟？ 两分钟？ 一分钟？ 还是打破
记录？
第三个practice session， 大家一进去就每个人找好自己的木板， 然后开始开始合练
。 合练一开始是按顺序叫的，第一个人先来， 然后第二个。 有时候会发生下一个人
想不起来自己的木板到底怎么放的情况， 但是因为有上下家和图纸， 很快就能得到纠
正。 合练成功两次以后大家觉得不需要明确的叫顺序了， 就是从一个人开始， 大家
见缝插针的就把木板放上了。 大家抓紧时间，总共合练了四次。最后两次合练相当顺
畅。
第三个planning session， 大家都觉得问题不大了。 有的人在兴奋的讨论可能发生的
问题， 有的人在手机查信， 有的人上厕所。更多的是安静的等待最后的计时赛。大家
意识到一个可能的问题是计时赛开始的时候， 木板是按长短顺序叠成一摞， 要把木板
全部摊开，每个人能在第一时间找到自己的木板， 并不是一件很简单的事情。
在最后计时赛之前我们还有五分钟的练习时间， 我们合练了两编， 但觉得怎么很快把
叠起来的木板摊开找到自己的木板并不容易， 也出现过拿错木板的事情。
最后的计时赛， 我们进行的反而很顺畅， 每个人都在第一时间找到了自己的木板，
这个搭的过程不象十几个人按顺序作一件事情， 而是象一个人有了十几双手， 我们自
己还没有反映过来， pattern瞬间就搭好了， 也打破了记录。大家都极其兴奋。 纷纷
击掌开啤酒庆祝。
要说明的是这个team的人并不很熟， 我这个team有三四个我能叫出名字， 剩下的平时
连点头的机会都不多。
这个game我实在是不太明白怎么会结果这么成功， 我总觉得team最重要的是team
member的quality和team work spirit， 这两点， 说实话都比较差。 大家互相都不怎
么认识， 经常有四五个人同时想lead discussion，所有的session大家都在不停的争
辩， 因为争辩的时候太多， 有的人就走开了， 有的人就埋头拼。我们第一次拼出来
的时间其实比较晚， 加上那时候大多数人都不知道怎么拼， 我自己感觉最后五分钟能
拼好就不错了。第二个planning session结束的时候我听到他们讨论打破记录还觉得蛮
好笑的。 我相信大多数member到最后也没明白这个puzzle是怎么拼的， 你要让我自己
重新拼一遍， 我可能还要十分钟。
我自己觉得ownership和dependency clarification是critical的， 当然， 大前提是
feel challenged, believe and can do attitude。 | g*****g
发帖数: 34805 | 2 其实做软件，最重要的不是teamwork，而是有牛人能救火。
【在 c***d 的大作中提到】
: mitbbs programming board 内部交流， 谢绝转载。
: 第二个game更长。 这个game是把26个人分成两个组，每组都要用一摞木板在地板上搭
: 成一个pattern. pattern的图纸画的很简单， 就是几个box在一起。这个game是计时的
: ， 记录是20.5秒。
: 只有一套木板，两个组有点互相compete的意思。一个组可以先拿图纸planning, 另外
: 一个组可以拿木板practice。 每个组都有三次planning和practice的机会， 每个
: planning/practice的session是十分钟。
: 我们组挑的是先practice, 大家拿到木板才发现， 木板不但长短不一样， 每块木板的
: 开口也不一样。 开始大家试图拼起来， 但是过了八分钟也没有拼好， 于是决定记住
: 了总共有几种木板长短， 就开始了第一个planning session。
| c***d
发帖数: 996 | 3 牛人是从天上掉下来的。。吗？
我必须严肃的说， 我觉得你说的不对。
还要补充的是另外一个组， 因为抽签的关系， 他们先作planning session, 第一个
practice session就搭好了pattern, 到最后的成绩也比我们好了不到一秒钟。我平时
觉得planning， tdd都有点自欺欺人的感觉， 其实可能还是作的方法上不够好。
【在 g*****g 的大作中提到】
: 其实做软件，最重要的不是teamwork，而是有牛人能救火。
| g*****g
发帖数: 34805 | 4 我不是说teamwork没有用，而是说木桶原理，软件的质量不由teamwork决定，
而是由最烂的程序员决定的，特别是测试不充分的时候。
现在软件周期越来越短，对质量的要求并没有下降。像我们跑SaaS的，合同
动不动都是99.9%的availability。出问题的时候能一个小时解决和一天解决是
本质的区别。
【在 c***d 的大作中提到】
: 牛人是从天上掉下来的。。吗？
: 我必须严肃的说， 我觉得你说的不对。
: 还要补充的是另外一个组， 因为抽签的关系， 他们先作planning session, 第一个
: practice session就搭好了pattern, 到最后的成绩也比我们好了不到一秒钟。我平时
: 觉得planning， tdd都有点自欺欺人的感觉， 其实可能还是作的方法上不够好。
| c***d
发帖数: 996 | 5 说到这个我想起来刚招进来的一个principal, 写的code coverage每个人都摇头。不是
cover的不全，而是表面的coverage太全了， 真正会出问题的地方反而放过去了。code
coverage是工具，主要是交流， 有一点保险丝的作用，但绝对不是法律合同。
一个team有个牛人make call是很重要的， 但指望牛人解决所有问题，那就是这个team
本身有问题了。一个健康的team, 烂的程序员或者提高自己，或者很快就被边缘化。从
这个角度来说， 我倒是同意你牛人很重要， 但不是指望他出活，而更多的是coaching
和建立健康的team culture。
【在 g*****g 的大作中提到】
: 我不是说teamwork没有用，而是说木桶原理，软件的质量不由teamwork决定，
: 而是由最烂的程序员决定的，特别是测试不充分的时候。
: 现在软件周期越来越短，对质量的要求并没有下降。像我们跑SaaS的，合同
: 动不动都是99.9%的availability。出问题的时候能一个小时解决和一天解决是
: 本质的区别。
| g*****g
发帖数: 34805 | 6 那是你们软件周期太长，比较轻松。你大概没有碰上太多出了问题，
今天不睡觉都必须解决的时候。牛人是练出来的，更多的是逼出来的。
code
team
coaching
【在 c***d 的大作中提到】
: 说到这个我想起来刚招进来的一个principal, 写的code coverage每个人都摇头。不是
: cover的不全，而是表面的coverage太全了， 真正会出问题的地方反而放过去了。code
: coverage是工具，主要是交流， 有一点保险丝的作用，但绝对不是法律合同。
: 一个team有个牛人make call是很重要的， 但指望牛人解决所有问题，那就是这个team
: 本身有问题了。一个健康的team, 烂的程序员或者提高自己，或者很快就被边缘化。从
: 这个角度来说， 我倒是同意你牛人很重要， 但不是指望他出活，而更多的是coaching
: 和建立健康的team culture。
| a***y
发帖数: 2803 | 7 恩,慢慢程序员头发就少了.
其实,做程序,很多时候做出来的不是客户想要的,那就伤脑筋.于是软件周期有多个循环
...客户中途要加一些功能,删除一些功能,也很讨厌.
【在 g*****g 的大作中提到】
: 那是你们软件周期太长，比较轻松。你大概没有碰上太多出了问题，
: 今天不睡觉都必须解决的时候。牛人是练出来的，更多的是逼出来的。
:
: code
: team
: coaching
| a***y
发帖数: 2803 | 8 恩,一个组要有一个牛人,在deadline保证能完成任务.
【在 g*****g 的大作中提到】
: 那是你们软件周期太长，比较轻松。你大概没有碰上太多出了问题，
: 今天不睡觉都必须解决的时候。牛人是练出来的，更多的是逼出来的。
:
: code
: team
: coaching
| a***y
发帖数: 2803 | 9 teamwork还是有很多缺点的,比如social loafing,人一多,大家都指望别人,最后都没做
. 每一个team都有一个storming阶段,就是组里面会有些conflict,斗争,性格不合,有怨
言,这个阶段很难,过了这个阶段,大家都熟悉对方什么性格了,就好办多了.
【在 g*****g 的大作中提到】
: 我不是说teamwork没有用，而是说木桶原理，软件的质量不由teamwork决定，
: 而是由最烂的程序员决定的，特别是测试不充分的时候。
: 现在软件周期越来越短，对质量的要求并没有下降。像我们跑SaaS的，合同
: 动不动都是99.9%的availability。出问题的时候能一个小时解决和一天解决是
: 本质的区别。
| a***y
发帖数: 2803 | 10 要能用team里另外一个人的程序,在不看懂他的程序的前提下. 这听起来很不合理,但是
有时就是这样.sigh
【在 c***d 的大作中提到】
: mitbbs programming board 内部交流， 谢绝转载。
: 第二个game更长。 这个game是把26个人分成两个组，每组都要用一摞木板在地板上搭
: 成一个pattern. pattern的图纸画的很简单， 就是几个box在一起。这个game是计时的
: ， 记录是20.5秒。
: 只有一套木板，两个组有点互相compete的意思。一个组可以先拿图纸planning, 另外
: 一个组可以拿木板practice。 每个组都有三次planning和practice的机会， 每个
: planning/practice的session是十分钟。
: 我们组挑的是先practice, 大家拿到木板才发现， 木板不但长短不一样， 每块木板的
: 开口也不一样。 开始大家试图拼起来， 但是过了八分钟也没有拼好， 于是决定记住
: 了总共有几种木板长短， 就开始了第一个planning session。
|
|
