画板仍在一边好久了，站立会议也很久没用了。。trello 也没用了。。。

#2 楼 @allenwei 想了解下当有紧急的 ticket 进来的时候，如何不影响迭代计划呢？

还有，我的观点是，ticket 和 issue 是分开的，ticket 给客户使用，issue 给开发人员，PM 将 ticket 拆解成 issue。貌似你们的团队不用直接接触客户需求。是么？

#3 楼 @liwei78 我觉得他第 3 点已经回答你了。你没有说清楚你们接的 ticket 都是什么，以及这些 ticket 的优先级情况。当然这些也要看你们的项目目前处于什么阶段了。

假设你们现阶段是 feature / bug fixing 一半对一半，那么每个迭代都要按照这个比例分配时间和人力。如果还像最开始那样全力铺给 feature，ticket 来了你们当然扛不住。讲敏捷的书好多都把重点放在 feature 阶段，因为大部分的目标读者都是做产品开发的。

敏捷不是唯一可用的方式，到了合适的阶段，不敏捷也无所谓，每个团队都会有每个团队的一套。到了最后你就会发现，敏捷不是方法论，而是一种价值观。

#4 楼 @nightire +1 #3 楼 @liwei78 可能是我运气太好了，我们团队的工作流程基本跟 2 楼说的一样。虽然技术老大是这么带领我们干活的，但是从来没告诉我们这就是敏捷。实践的结果，这么干起来最舒服，各方面的进展会顺利。不这么干就会焦头烂额，加班且感觉绝望，无数的 bug 和 feature，感觉有生之年都做不完。 #2 楼 总结的 4 点 非常到位。硬要补充的话，除了团队要敏捷，个人开发也得掌控住时间。我最近一周实践番茄工作法，效率确实有提高。以前经常是开发遇到一个问题，google 一下，然后看看技术文章然后被链接吸引到什么网站。不知不觉一上午过去了。现在每天大概有 8 个番茄是不被打断的。我是工作 25-30 分钟。休息 5-10 分钟喝茶，刷刷 ruby china，走两步松一松腿，换盘腿的姿势继续下一个番茄。然后 3-4 个番茄之后起来吃零食殴打一会妹子同事们。编程时候关掉 QQ 就行。因为我不上微博，多年不带手机（你知道的）所以不会被这些东西打断。

我觉得 XP 才是敏捷的核心，虽然要引入和接受比较难，但这部分是带来最大价值的。很多团队根据自己的情况量体裁衣，就把这最困难的部分扔掉了。

恩。。

#5 楼 @Victor 其它的学习了，只是其中有个 殴打一会妹子同事们 这个是打豆豆的节奏么？??

#3 楼 @liwei78 我们基本每个迭代都有额外的紧急的 ticket 要加入，所以我们一般都会留一些 buffer 时间，如果 ticket 比较大，那就置换出对应时间的 ticket，保持总量不变。但最好不要中间改动计划

#9 楼 @allenwei 控制好节奏体验 PM 的功力，看来你们对敏捷做的非常到位，拜服。。。

最近在看《实例化测试》和《赢在测试 2：中国软件测试专家访谈录》，有点心得，打算也写写敏捷开发的事呢，算是给过去一些年工作的总结。

求各位指点。

#5 楼 @Victor 请问 盘腿 盘久了 会疼吗

#11 楼 @themorecolor 楼要歪。。。。。

盘腿会疼，每天一小时，会有益的。时间久了，就舒畅了，这是谁谁谁说的忘记了，百家讲坛看到的。

盘腿打坐，内观十分钟，然后写代码，是很向往的状态。。。。

#11 楼 @themorecolor 又不是假肢，当然会疼。所以才要每个番茄之间走几步松一下。然后换个方向继续盘。 #8 楼 @046569 女同事太多，不打不舒服，一大帮妹子天天咋咋呼呼的。削一顿就老实了。不管你信不信，我是信了。

#12 楼 @liwei78 盘腿 在椅子上 还是在地上

#14 楼 @themorecolor 你舒服的地方就可以。。我记得马未都也讲过，古时候的一种椅子，是专门盘腿坐的，因为它面积很大，坐上去腰够不到椅背，只能盘腿坐上去。

唐代的时候是中国人的起居习惯发生巨大变化的一个时期发生裂变，我们知道刚才说了从东汉开始就有记载了，但是从东汉一直到唐这一段时间，是完成中国起居变化的一个漫长的过程，唐代是加快了这个速度，为什么呢〉唐代的经济发达，人的生活，活动的频率就快，比如我们知道的《韩熙载夜宴图》那件国宝，知道中国，了解中国绘画史的都知道这件国宝。韩熙载是有三坐两站，在一张图里出现，其中有一次是盘腿坐在椅子上，盘腿坐在椅子上是一个习俗，比如我们在陕北乡下待惯的人突然进城，他老愿意蹲着，因为他从小就蹲惯了，韩熙载当时也是这么一个情况，我这么高的地位，但是你让我老垂足而坐也不是很舒服，所以盘腿坐在椅子上，表明我们那个时候改变习惯的一个过程。

禅椅，打坐专用，外加一个 mac 本本，是不是古今通杀中外勾搭的杰出表现呀？？？

#13 楼 @Victor #15 楼 @liwei78 盘起腿来 是不是 需要把鞋啊 袜子啊 什么的脱掉 在公司的话，容易让人觉得 有点 2 啊 哈哈

#17 楼 @themorecolor 脱袜子干嘛？？确认下你的凳子够结实嘛？

楼，你不要歪。

#17 楼 @themorecolor 袜子不脱。任何时候都要穿袜子，精由足底生，寒也有足底生。都知道泡脚好，可是知道不知道脚底着凉对人很不好的。 我刚从山里来北京面试的时候就把自己的宗教信仰，生活习惯说的很清楚。boss 和同事表示可以接受。跑题了，不回了。晚安。

敏捷开发不正是适合小团队吗？ @liwei78 ，控制好节奏是 scrum master 的事情，在 agile team 里面没有 PM 这个 role。

这篇文章讲的非常生动： http://net.tutsplus.com/articles/editorials/scrum-the-story-of-an-agile-team/

敏捷开发确实适合小团队。上面大家说了很多有益的点，关于LZ对于任务被意外的 issue or bug fix 打断。我目前团队的解决方案有两个：

1. 完善的测试和严格的 code review.每个功能都要有完善而全面的测试，在计算 sprint 时要把写测试的时间算进去，新 feature merge 之前必然要做 code review。no review no merge. 每次修复BUG都要针对这个BUG写测试，最大努力确保一个问题只需要一次修复。这样坚持一段时间就是一个良性的循环，虽然项目进度可能会被拖慢一些，但是项目会非常稳定而且健壮，部署上去的东西出错机率会越来越小。bug fix 打断 sprint 的机率也一样。

2. 意外的 issue. 例如客户临时提出的要求，这个就需要一个强势的 leader. say no to client (at least no for now.) 恰好我目前的 leader 就是这样，而能做到这样，和坚持第一条所带来的良好的客户评价是密不可分的。

正身双盘确实有助于集中精力，你的脊柱要和你的见地一样直。冬天要到了 注意膝盖和足部保暖。

另 @Victor 烧水到70度就灭火 水是很难烧开的..

#20 楼 @jeff_duan 哈哈，我在酝酿的文章里就是想说 PM 对 5-10 人小团队多么的重要！ 话说，我也跑题了，研究 jekyll 用掉了昨天晚上的工作时间，本来那个时候要写点字的。。。

@liwei78 求敏捷开发相关的好书推荐。

#21 楼 @raven 好团队要做的就是可以把握时机的说“No”，前年的项目就是自己被“yes”搞死了。。。。道理多么浅显：“你永远无法满足客户的需求”。

#24 楼 @kongkong 搜 scrum 和敏捷开发，得到的书我就不说了，我在看《实例化需求：团队如何交付正确的软件》，推荐给你吧，里面还提到了一些书，比如《敏捷软件测试：测试人员与敏捷团队的实践指南》，2010 清华大学出版社。

我个人是从测试和重构的角度来看敏捷开发的。

#25 楼 @liwei78 有时会心软，说 yes。。。

#27 楼 @imlcl 所以要团队每个人都有发言权和决定权，meeting 的时候，coding 人员观点是很有预见性的，如果 PM 逐渐打压这种预见性，大家也就不愿意表达态度了，人会走向消极。

之前跟 @yedingding 聊得时候，我说我一直在找一个工具，可以让团队按照它的“约束”协调一致，我到现在都没有看到，呵呵。

#28 楼 @liwei78 有多少公司真的是搞工程师驱动的文化呢？一般公司比较难啊

"团队每个人都有发言权和决定权",可公司里面的“老人”们就没那么开明了，对于新人的观点，他们不屑一顾。确实冷了人心。让我想起来了“I had managers that gave me the freedom to be creative, but also the boundaries to be successful.”

#29 楼 @allenwei 所以我建议小团队里有个协调师，调度师，或者，PM。

#22 楼 @raven 谢谢，我的脊椎很直。只有每天早上会双盘静坐。白天在公司都是左右交替单盘。膝盖和足部保暖当然重要。但是也别忽视了脑后啊。怎么说我也是山里闭关了 3 年才出来混的。修身的要点还算是了解滴。但，我们就不要歪楼主的帖子了好吗。有兴趣可以在瞎扯淡下单开一个讨论健康和修身的主题。

#30 楼 @kongkong 小团队里，一个人的效率决定了项目效率的大部分，甚至 100%。这种决定性人物的观点往往影响所有的团队成员。

@liwei78推荐的书倒是对这个过程很有帮助的，因为很多迭代 delay 都是需求分析设计的时候下的功夫不够，为后面的开发埋了很多坑，临时需求的 said no 现在倒问题不大，这是沟通后很容易解决的。