重构 小团队敏捷开发,大家怎么看?求真心话。

liwei78 · 2013年10月20日 · 最后由 louisliu813 回复于 2014年02月16日 · 9895 次阅读

rt

画板仍在一边好久了,站立会议也很久没用了。。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 现在倒问题不大,这是沟通后很容易解决的。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册