Archive for the ‘Agile 敏捷’ Category
Thursday, May 7th, 2009
我今天出差讲的ppt，第一次在一个舞台上演讲。。聚光灯照的我完全看不见台下人表情，烤的我一头汗。
总结：
Well：观点来自我的论文；时间刚好1小时；图像比较符合；
Less Well：互动不足；乐趣不足，图片找的太匆忙；history部分讲的感觉有点简略；自己画的图貌似有点小错；时间太短，一些观点没法讲透彻。
Tags: Agile 敏捷
Posted in Agile 敏捷, ThoughtBlogs | 5 Comments »
Monday, April 20th, 2009
关于交流
1. 永远不要以否定词开始你的对话
最近经常听到人说话时候把“不是”这个词放在句首，例如有人说：“我觉得这个设计是符合可用性原则的，你看这用户按钮这么大，多好点击啊！”有人说“不是，按钮大不代表可用性就好啊。。。”我认为这是一种很不好的习惯。他在不经意间，把自己的立场摆在了和讲话的人的对立面。甚至他们观点实际上相同的时候仍然不自觉的用“不是”开头。对方听到“不是”，虽然表面没说，但心中早已掀起滔天巨浪…… 这样说话要花很多功夫才能达成一致。（貌似很多老北京都这么说话，很奇怪。）
作为一个咨询师，当尝试解决用户的问题的时候，或尝试推销解决办法的时候，切忌用否定的句子开始阐述。当一个咨询师说“不是”的时候，无论你后面的论证多么的严谨和完美，客户都已经提前丧失了兴趣。有的时候，赞扬谈判对手能够更快的达成一致。
这时候一定要换一种说法：“你说的很有道理，我帮你改善一点……”，“你说的对，如果……能够再……一点……用户体验就更好了”。
2. 交流的唯一目的是达成共识
交流发生于双方发生分歧的时刻。例如你对工资不满意了要和老板交流，再比如需求搞不清楚了要和客户交流，在家里有矛盾了得和老婆交流等等。总之交流这个事件的产生动机总是因为有些东西搞不清楚，而交流的目的就是把这个东西搞清楚，大家对问题达成一致的理解。
然而，很多时候交流的双方忽视了交流的目的，陷入了盲目的交流漩涡。尤其是看到两个人在pair programming的时候，为了一个设计争得面红耳赤不可开交，这时候他们只是为了说服对方、或者证明自己的权威而交流，目的改变了。
3. 交流的基础是尊重
顺畅的交流是建立在互相尊重的基础上。当你和一个人说话的时候，如果他眼睛望向一边，心不在焉，根本不仔细听，敷衍的和你说，这时候说话的人是什么感觉？如果对方用傲慢的语气粗鲁的对你说，“你这个观点很愚蠢”，“我的一个朋友才是我见过最牛的（言下之意就是你不够牛）”，这时候说的人还有没有动力继续说下去？
交流的时候一定要怀着一颗平等的心。。。无论和你交流的人经验深浅，无论地位高低，无论贵贱。
4. 交流是双向的。要用心听，认真反馈
一个很好的实践叫做“Active Listening”，或者叫“主动倾听”。 所谓Active Listening，通俗的说就是指听别人交流的时候，要经常嗯嗯啊啊的赞同，并且不停的问“后来呢？”这个讲故事的人最爱听的短句，以及经常的总结一下对方的观点。这样的主动交流比较能够促进说话的人的积极性，使得话题能够不断的进行。
更重要的，是要对说话的一方提出反馈。工业上说反馈是质量的关键，只有建立了良好的反馈渠道，产品的质量才能达到客户的要求。当然，要区分的是，有时候别人说了一件事情，并不是真的想要听者提供反馈，只是抱怨和发泄一下需要听众而已。
关于反馈和提建议
1. 当你要反对的时候，请同时给出你的建议
在一个风和日丽的中午，你问旁边的同事：咱们中午一起去吃7-11好不好？他回答说：又是7-11啊，不去。或者，你好不容易写了一段感觉良好的代码，给你的同事看，他说：写的不好。（下面没有了）。总有一些人习惯于否定对方的意见建议，又不能给出自己的办法。这样人非常多。
当提出反对的时候，一定要同时给出建议。例如我们做开发过程的回顾会议（Retrospective）的时候，如果光说出不好的地方在哪里而又没有改进建议，那几乎和没说差不多。
2. 提意见建议之前，先赞扬好的一面
意见建议这个词，老外经常会用Feedback。这Feedback是个好词。辞典里说：“If you get feedback on your work or progress, someone tells you how well or badly you are doing, and how you could improve. If you get good feedback you have worked or performed well.”
说起Feedback的时候，隐含的含义就是要告诉你什么做的好，什么做的不好，并且告诉你如何改进。其中更重要的是要发扬好的。而反过来看我国这边，很多情况下我们叫提“意见建议”，意思就是对你做的不好的地方指点一下，在给你提出点改进建议。我国古代曾经有活动叫“批评与自我批评”，更多的是看到了坏的一面，而忽视了对好的一面的坚持和发扬。
有人发明了“建设性意见”这个奇怪的词，难道对应的应该叫“破坏性”意见？貌似从来就没有一个中性的词来指给别人的Feedback。可能是自古以来朝堂上就只有抨击诘责没有正面的Feedback吧，就算有也被归于了阿谀奉承、溜须拍马一类。由于我们的这种传统，在很多情况下，我们给人提Feedback时，都容易倾向于对人进行批评性的评论。而这种评论，是破坏团队关系公司文化的特效药。
3 Feedback的目的是提高效率和增强信心
以前参加过培训，其中一课就专门讲到给人提供Feedback。给人提供Feedback，你只有两个目的：提高对方的效率，或者增强对方的信心。前者，就是针对某些不好的地方提供改进建议，后者，就是对于对方做的好的地方表示支持和鼓励，希望他再接再厉。因此，所有的Feedback，应该都能够达到这两个目标。这两个作用之外的任何其他作用，都不是合适的Feedback。
我们公司内部Feedback的种类有很多，有非正式的Feedback，离开项目的Feedback，半年期的Performance Feedback，面试之后有Feedback等等，但做法都大同小异。首先，想要给人提Feedback，你要先获得对方的允许。反之，你如果想得到别人的Feedback，你要向对方正式提出邀请。
4 提Feedback要针对行为，要具体
人的行为其实都有动机。动机(Motivation)决定了态度(Attitude)，态度决定了行为(Behavior)。例如一个人的动机是想赚大钱，他的态度就会很积极上进寻找机会，他的行为就会表现为愿意参加各种创业俱乐部之类的。
提Feedback的时候，只能针对行为来提，或者说，就事论事，而绝对是不可以针对人的动机或态度提。例如说，提Feedback说这个人太自私，平时总不积极参加活动什么的。这是错误的提法。可以改为：某某最近不经常参加某活动，如果他以后能够参加这个活动，那么他能够在活动中获得什么什么知识等等。如果针对人的动机提Feedback，一来提Feedback的人会先入为主出现偏颇，二来听Feedback的人会听不下去。
另一个提Feedback的时候的常见情况是太空泛。常见的是在提Positive Feedback的时候，有人说：某某非常nice，某某非常容易相处。好话人人爱听，并且这好话都是针对态度的话。然而，这些话纯粹是拍马屁没有实际用途。 要用事实说话，举实例。要说某某做了什么让你觉得nice，某某做了什么证明了他容易相处。这些具体的实例对于接受Feedback的人会起到促进的作用。
另外要避免使用我认为，我估计，我猜，可能之类的词。因为这些词不客观。想对一个人进行了解，只能根据客观事实来判断，而不是可以根据别人的判断而判断。
5 给组织提Feedback就是Retrospective
当我们把上述的实践用于组织和过程，就是敏捷方法中常见的Retrospective了。Retrospective的目的是增强团队的效率和提高团队的信心，一个有效的Retrospective也需要：先提出团队过程中好的一面；当提出不好的时候一定要有具体的改进建议；提出的好坏方面都必须具体，对事不对人。
当我们每个团队的个体成员都学会了如何交流，如何提Feedback的时候，那么团队的自组织和自完善也就很好办了。团队建立起完全平等和安全的交流环境，成员们就会逐渐的去进行交流和反馈。
Tags: Agile 敏捷, communication, consulting, feedback
Posted in Agile 敏捷, ThoughtBlogs | 3 Comments »
Thursday, April 9th, 2009
昨天和前天参加了两天QCon Beijing的会议。有所感想。
关于话题和话题的质量
听了2天的Session，发觉人的演讲水平确实能够很大程度上决定一个Session的好坏。这里说的演讲水平不仅仅是指台上的语音、声调、手势、姿态，还包括他做PPT的能力。
第一天的话题我主要听了敏捷开发部分。
Martin Fowler的Ruby Session特点是组织严谨。不愧是俺公司的科学家。观点的逻辑组织非常的严谨。所有的观点都有证据，满篇都是调查、数字、统计。基本上可以说，这个Ruby的话题可以作为论证Ruby在软件开发中价值的一篇很好的论文。结论是Ruby在ThoughtWorks被认为是Positive的选择。老马底气充足，吐字清晰，一口不标准的伦敦音非常容易懂。美中不足的是两点：1 他图片上的颜色选得很难看，2 PPT中采访的几个人说的话由于音响噪音干扰听不太清楚。
Henrik Kniberg的多团队敏捷胜在图片详实。他用很形象的图表示了团队的组成，又通过很多现场照片具体列出了实践的过程和问题。印象最深的部分是那个IPM的例子，90人的团队IPM/Planning的Session面对面来做，甚至不惜把人从不同的地方飞过来。总之讲的比较务实。一个值得借鉴的做法是他把图片中的人脸模糊化了以避免冒犯客户。
傍晚参加晚宴。晚宴中有位老外讲敏捷Session，明显的犯了几个演讲大忌：1 对听众了解不足。从敏捷历史甚至软件过程的历史讲起，认为下面听众都不了解。整个主题只讲了为什么要敏捷这一个话题。反正我是觉得没有新意。2 演讲的ppt很失败。一页八行句子，他还在照着读。加上现场音响不好，后面的人听不清楚。于是有的人开始私聊，隔一会儿抬头读一下PPT上的字。会场噪音更大。
之后的大师论坛还是很有趣的。几位老外＋Ben Wang在台上论述他们认为的企业开发发展趋势。话题不外乎云计算、动态语言、多语言编程、开源、敏捷/精益等。多数老外的论述比较充分，证据和推论都很清晰。其中唯一令我觉得不靠谱是Rod Johnson同学，他说了一些话让我觉得很费解，例如Opensource is good，because developers have to like it. 还勉强类比Tomcat是精益的软件，Websphere是不Lean的。说的有些不够令人信服。
第二天开始的话题主要是网站架构。
一开始是Rod的话题。他的演讲语速非常慢，慢到一句话都要分3短句来说。上述的Tomcat/Webshpere问题又被抛出。后来才知道SpringSource现在在维护Tomcat，这么做未免太着相了。。总之这个Session很平淡，没有什么出彩的地方，印象不深刻。
之后是EBay的话题。这个Session被讲过好多次了，唯一的问题是PPT字太多而且太小。。我们坐最后一排根本看不清楚第三级的字。强烈建议Randy下次改改PPT。这个Session概括了大规模Web的最佳实践、模式以及问题等等，可以作为这第二天全天话题的一个总结。虽然没有具体的实施例子，但把问题分析的很清楚。在什么情况下，应该采用什么样的策略，好处是什么，坏处可能有什么等等。
上午最后一个是一个讲Agile+CMMi的。这个Session的最大问题不在于演讲技巧了。。而在于他的观点本身，听了一会儿我们就听不下去了，决定提前去吃饭。后来Steven发帖提到：Joke of the day: “Repeatable and Controllable Agile Processes”
下午的话题是重头戏，估计大多数人是冲着这个来的。
首先是来自支付宝的程立带来的SOA治理。这个演讲的PPT可以说是最炫的PPT之一，画了很多的非常华丽的过程、架构等图，如果作为售前用PPT将非常有冲击力。然而，这个话题听的令我一头雾水，到后来基本全部LOST，不知道他在讲什么。归其原因，我认为有3点：1 演讲所提到的架构和我平时所理解的架构不是同一个“架构”。貌似这里提到的架构分很多种层次，例如公司架构、组织架构、业务架构、应用架构，不同层次有不同的关注点。SOA治理这个词更偏向于治理而非SOA，因此对核心名词语义的不同理解导致了从一开始我就没能跟上思路。2 演讲的PPT似乎没有一个清晰的逻辑主线。前后的逻辑关系我没能听清楚。 3 下午第一场，刚吃完饭，未免有些小乏。 以上原因导致该话题完全脱离了本人的理解范围。
豆瓣洪强宁的Session在会前被冯大辉狠狠的赞了一次。因此这次被报以的期望很高。该Session按照时间顺序组织。从豆瓣一开始上线的情况、架构选择，到后来不同用户级别时候出现的不同问题，应对措施，解决办法，甚至相关代码。非常完整和清晰的展现了豆瓣架构发展里程和其中所采用的具体策略。这样具体的Topic非常的精彩。强宁的演讲技巧也蛮好，语速发音都很专业，一定是练过。有趣的话题，专业的演讲，加得当的Slide，个人认为本Session可以当之无愧的成为QCon今年最佳Session。
有道的Session是关于日志分析。话题其实可以讲的很有趣，但遗憾的是邓毅同学的PPT做的貌似太过简单。原本可以讲的很详细很有趣的故事被简化到了若干的纯文字中，非常可惜。如果能够多一些图，更好的组织一下故事，可能会是一个非常精彩的演讲。
优酷网邱丹的话题也是关于性能和扩展性。由于优酷和豆瓣本身的区别，其对扩展所采用的策略和方式都非常不同。这个演讲的PPT做的有点山寨，图片看起来太简朴了。邱丹同学的演讲技巧还需要进一步加强才好。优酷和豆瓣的话题加在一起可以看做是对EBay Randy话题的完美诠释。一面是具体实践，一面是总结的模式和最佳实践。
从第二天下午的演讲，可以明显的看出，一份精彩的演讲，其讲师的技巧、PPT编写、话题的组织、以及对听众预期的满足都非常重要。任何方面的欠缺都会导致Session的精彩程度大大降低。
关于活动组织和对下次活动的期望
本次活动是QCon第一次组织国内的大会。能感觉到QCon在组织方面做了很多的努力，但规模貌似还是有些保守了，可能是怕第一次做太大万一失败有压力吧。组织方式上有很多方面值得其他办活动的人借鉴和改进。
组织方面：
路标提示。虽然在网站上写清楚了地址，但现场的标记似乎还不是很清楚。只看到会议厅最前面有个白板上画着地图，这白板应该放外面去。尤其一楼门口应当设置一个大大的广告牌。很多人一开始都找不到这地方。
吃饭时间和方式。目前大家同时放学去吃午饭，结果排长队或者没地方坐，结果导致下午会议延时开始。这是典型学校食堂遇到的问题。。一般学校都靠错开吃饭时间来解决。但显然这会议时间错不开，不妨弄点简单食物，或者延长午休时间。
午休时间如何利用。午休时间大家好像在会场里面没啥事情，于是就有人播放美女视频。。这个时间其实本可以是各个厂商展示的好机会。
茶歇。。有点山寨。。咖啡饮料都装在一个19升的矿泉水桶里面送来。。可以理解这是为了减少成本。不过貌似这方面还是可以改进一下下的。另外吃的和饮料都摆在一个桌子上造成了拥堵。
主持人和课程组织。这次活动主持人的作用没能很好的发挥出来。每个主持人都是该领域的专家，如果他们能够更多的露面和讲话就更好了。例如晚上可以分会场让每个主持人来组织活动。
晚宴的组织。晚宴时候最大的败笔就在于座位的摆放。其实晚宴更多的应该是社交活动，有没有椅子都不重要。重要的是大家应该能四处走动和别人搭话交流。晚上饮料提供的不够哎，喝了点水就没了，再说半天话口干的很。
设施方面（理想会议场馆建设指南）：
讲台布局。这次的场馆讲台中央很宽大，但作者只能站在一个小台子边上做演讲，两边的投影幕布太小了，字小了看不清。如果有场馆能提供TED那种讲台就好了。下回找个舞台或剧院试试看。
会议厅。这次分了两个厅，大厅很宽敞，但是小厅非常的狭小，很窄很长，屏幕又小，又不够通风。因此小厅的效果不好。理想的场馆应该是能有大厅一个，多个50－100人的小厅才够用。
网络和电源。现在越来越多的活动鼓励大家twitter或者上传现场照片，这样网络和电源就成了必需品。这次的无线网络的DHCP不能用，因此很多人都没法上网。电源也是稀缺物品。
存物柜。现在这季节大家都穿个大衣来，进屋又要脱。如果有场馆能够提供一个地方挂衣帽就更好了。如果能临时锁书包就更佳，因为大家很多都带着电脑来，中午又不放心放会场，只能背着去吃饭占用食堂空间。
当然拉这些只是我自己的理想中的场馆。貌似这样场馆真不多。
对于下一届QCon的期望，当然是希望能够像QCon london一样举办5天每天5个track一共近百的Session才好。这才能显示出QCon在技术社区的影响力。
关于参会的目的
从公司角度来讲，公司来参加这样的会议一方面是建立自己的品牌，看是否能有业务机会，一方面也是可以支持公司员工学习交流。
从个人角度讲，参加QCon学习知识只是一方面，其实最大的目的还是来交朋友。这次俺结识了几位新朋友，例如冯大辉、洪强宁，也见到了以前网上聊过很多但一直没过见面的几位，例如林昊、苏锐、Steven Mak麦天志，还见到了好久不见的老朋友吕晋、InfoQ编辑团队一小撮人等等，嘿嘿，非常的高兴。遗憾的是时间有限没能一起去吃饭哎。
有一些参会人，来了之后就光听讲座，听完之后不提问题也不和人交流，这样的参与者回家之后能获得什么呢？公司花几千元买的门票，不是让你来上课的。想听讲座的人在家呆着听视频看文章多好，还省事。
Tags: qcon, qconbeijing
Posted in Agile 敏捷, ThoughtBlogs | 3 Comments »
Sunday, September 28th, 2008
此指南为我所在的项目引入新BA的参考步骤，并非ThoughtWorks官方指南，仅适用于特定项目的特定情况。
Task 1: 请自己去认识团队的所有人。
BA肩负着交流者的使命，需要和客户和团队都创建一定的关系，主动去认识每一个人，做自我介绍，发放名片，请大家多关照，以后合作愉快。
Task 2: 了解项目背景
BA应该是最了解项目背景的人。项目之后的驱动因素，项目的目标，项目所解决的问题，项目的流程，项目所涉及到的其他系统，项目的范围，项目的涉众，项目的用户，项目的发布蓝图，项目的当前状态。
Task 3: 简单了解敏捷开发过程
在敏捷的过程中，BA处于一个承前启后的角色。BA需要了解项目过程中的各个术语，项目迭代的长短，交流方式和频度，客户如何计划，如何给客户展示，每天何时开始工作，项目状态交流方式，团队的分工，分布团队的工作方式等。
Task 4: 了解BA工作职责
BA的日常工作包括很多事。每个迭代让客户确认需求，与客户沟通，澄清问题，询问细节，电话会议，组织讨论，给开发团队介绍业务，保证开发速度，在mingle上管理需求，确认defect的优先级，回答开发人员的问题。
Task 5: 学习基本BA技能技巧
BA的基本生活技能包括：和业务人员的交流能力，和技术人员的交流能力，足够的展示能力，能够可视化的表现需求，演讲文稿制作，英语交流和写作，商务信函的处理，控制会议的简短和有效，有条理的描述清楚需求，分析复杂的需求和过程，快速发现用户问题，设计良好的用户体验，逻辑的分析和叙述问题。
Task 6: 尝试完成当前项目的工作任务
快速了解系统功能，阅读项目的需求清单，在本机实际运行项目，测试和了解项目的功能，Shadow当前的有经验的BA，接手简单的工作，处理业务邮件，参加需求讨论，阅读以前的相关文档。
Task 7: 了解BA的Career Path
和sponsor坐在一起，了解行业中的BA能做什么，我们公司的BA做什么，BA发展发展方向有哪些，公司提供哪些机会给BA发展，公司提供什么培训，明确自己的兴趣爱好，搞清自己对生活与工作的权衡，找到自己的前进动力，确定自己的发展目标
Task 8: 制定自己的学习计划
确定一个短期计划，确立学习和努力目标，制定近期的实现步骤，阅读参考书或资料，定下review时间，为自己创造压力，然后努力的开始做这份有前途的BA职业吧。
附录：新时代情况下对新BA的四大要求：
要聪明，客户时间紧团队任务重，没有人有空把一个事情解释很多遍。
要谦虚，在没搞清楚问题之前不要自以为全盘了解。
有条理，要能够在毫无头绪的需求中有逻辑的分析出可行的方案。
英语好，不仅仅是读写，听说更加重要，并且要是business english.
Tags: Agile 敏捷, Analyst, Business
Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 需求分析 | 1 Comment »
Tuesday, April 22nd, 2008
上周末忙忙碌碌的，在公司做了两天的公益项目。具体的过程郑晔说了不少了，我从BA的角度做些补充。
Code Jam是ThoughtWorks特别的活动之一，在很短的时间内为客户交付可用的软件（或原型），团队经过短期高强度的锻炼，可以对开发过程和开发技巧都做一些反思。这次的Code Jam是为乡村教育基金会做一个网站，属于一次公益性质的活动。我们几个人从周五开始就忙碌了起来。
首先，作为BA，先期了解一些需求是必要的。在开发之前，必须要知道Scope和优先级。周五下午我和QQ俩人就和我们的Client，来自（伦 敦、香港、墨尔本）的Steven，一起进行了简短的需求分析。由于项目不大，而且总共只有2天时间，我们重点关注于需求的优先级。在搞清楚流程的基础 上，把优先级分了7级。听起来好像很多的样子，实际上，从需求完整性考虑的话，前1－3级的需求比较多，后面的都是很小的功能模块。我们保证每一级开发出 来都必须是可用的软件。Steven非常聪明，对我们的方式适应极快，很快把握到排序的要点，到后面亲自操刀开始写Story，终于达到了”客户编写用户 故事“的极境，令俺窃喜不已。
终于，4个多小时之后，全新的story list出炉了，1-3级story有卡，1-2级的卡背面写有A/C。总结下来，这次需求分析做的比较好的地方有：
- 要在很短时间内需要搞清楚足够开发的需求，因此我们确定了项目远期目标、用户交互流程、特性的优先级，取消了评估开发时间一项。在下午需求会议开 始前，我们制定了：1 项目目标 2 功能范围 3 优先级 4 界面交互原型 5 用户故事 6 细节验收条件等会议步骤，在4个小时内准备好了可以开发的需求。
- BA、QA和客户坐在一起交流需求。这是非常理想的情况，很多项目由于种种条件限制使得BA/QA没法从一开始在一起。
- 需求和界面原型全部采用纸质管理，没有除了照片以外的任何电子存档。不管是开发人员还是BA/QA，都手持卡片和人交流，有任何问题和发现都记录 在卡片后面，这节约了很多时间。（当然，由于QQ太过谨慎，怕卡片被打扫卫生的阿姨清走，特地锁在了她的宝箱里，结果晚上胃病第二天没法来……由此可见， 项目风险总是不可能全部预测的）
- 在Story的上面标注了依赖关系。以往做Story经常忽视这点。这次特别标记出来，在开发过程中作为Dev开发的参考。
- 优先级的制定。没有采用传统的MoSCoW法，而是就用1-9的数字来表示。我们最终将1-3的大多数需求交付，客户很满意。
- Hight Level 系统结构图。通过整理此图，我们全面的了解了系统的蓝图，客户也在过程中重新反思了不少的特性。这图不完全是流程，其实更像是Information Architecture+Domain Model，结合了功能+界面两种不同的元素
做的不够好的地方也有
- 由于对Rails开发的效率无法预估，我错误的假设了两种不同类型的文档在提交时候有很大部分功能可以复用，因此在写第二类的时候，简化了一些Story，最后证明这些还是得写上。此处犯了INVEST中I的错误
- 有些Story的A/C描述的不够。凡是有可能出错的地方都一定出错定律。。。例如，search结果的list中，通常都有link可以view detail，因此就没写在A/C，果然被遗漏了
周六开始进入正式的开发阶段。由于时间短，我在周六早上主持了很短的kick-off，大致说明了项目情况，读了一遍优先级1的需求，就开始开发 了。团队都是非常优秀的人，很容易就形成了自组织的团队。一开始所有的人都开始找BA问问题，有些手忙脚乱。好在过了启动这段后就好多了。
我和其他两位过来帮忙的BA一起，安装了只有ready, in dev, dev done, qa done四个状态的story wall在墙上。公司的推拉白板柜门很好用，需要用哪张墙就推过来，不用的就推走。一共占用了4张白板。Story Wall，流程Wall，界面流程Wall和Wiki Wall各一个。
因为大家采用Textmate，而并不是所有人都用过它，因此一开始team是用过的和没用过的pair，先熟悉工具。中午时候大家switch。
在开发阶段，我们整个团队做的比较好的地方有：
- 自组织的团队。真正实现了自组织。每个人都尽力将事情向好的方向推进。大家都尽职尽责的完成任务。
- 在开发优先级1需求的时候准备优先级3的A/C和优先级4-8的卡片，使我们不用在一开始就准备所有的功能。
- 采用活动墙壁做需求墙，team需要看什么就把那个移动过来近些。
- 开发团队频繁的轮换pair，可以收到很好的效果。从BA的角度可以很明显的感觉到哪个pair遇到了问题，从而协调team之间的取长补短。
- 和客户交流频繁，所有一开始由于时间关系无法确认的需求都交由现场客户Steven解答。中间根据进度，我们建议更改2和3级别优先级的顺序，客户也确认了这次更改的必要性，使得我们最终能够交付正确的产品。
- 一天两次的简短的standup。由于大家平时交流的充分，standup可退化成宣布值得大家知道、比较重要的事项的碰头会，如果没有事情说就不用说话。
- 简短的retrospective。自组织的团队不需要太多的反省。每一个人都是很好很有能力很有想法的成员，只要列出来我们发现的问题，大家会自觉的去解决。
- 从一开始就运行的test和build。很大程度上提高了团队的整合度。
- 8dev团队，一天95次的提交次数，一天18个migrate脚本，一天12张story卡的速度。
做的还不够好的地方或者改进的想法还有
- 在开发之初的设立UI pair，在开发后期设立专门BUG pair的作用不可忽视
- 每天的switch pair还是做的不够多。我认为对于rails开发来说，理想情况2个小时就应该进行switch。更频繁的Switch能够使得知识传播的更快，尤其是 在团队中不是所有人都对Rails开发熟悉的情况下。由于做的还不够好，出现了有的pair工作在一张卡上太多时间的情况，原因是俩人对这块都不够熟悉， 如果早点switch就好了。
- 由于Rails开发中一些scaffold的存在，几个相关的CRUD的story可能一下子就全好了。这对写Story提出了更多的要求。要精确掌握粒度不太容易
- Rails和Textmate的中文支持还有待提高。看哪位神仙有空，给contribute一些plugin啦、月光宝盒什么的。
总之，如何更好的交流和协作是我们这次Code Jam学到的知识之一。Rails开发的效率极高，这对开发过程和开发团队就有了更多交流协作的要求。大家必须要通力协作：多提交和更新才能最快的把代码 整合在一起；多交流才能保证不会有架构和数据迁移的冲突；多和BA/QA交流才能不走错路做错功能；多更换pair才能学到更多的技能技巧，保障对系统的 了解程度；多和用户交流才能确保需求不会迷失方向。
周六晚上5点半showcase的时候，1优先级的功能差不多都出来了，可以大致预测到第二天的成果。可惜由于周日我下午又赶飞机，没能看到最后交付的场面，非常遗憾。
Tags: Agile 敏捷, Analyst, Business
Posted in Agile 敏捷, ThoughtBlogs, 需求分析, 项目管理 | 2 Comments »
李默，ID冰云，ThoughtWorks公司高级咨询师、业务分析师，敏捷过程教练，BJUG创始人。目前主要专注于互联网产品需求管理与市场营销的合作、产品交互设计、敏捷组织方法等方面的工作。联系方式: icecloud (at) gmail.com 
