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 »
Wednesday, July 11th, 2007
2007年7月14日下午，俺在AgileChina大会上做演讲：敏捷需求管理。
根据2006年的调查报告，软件项目失败原因的71%是由于缺乏或糟糕的需求管理造成的。敏捷需求管理过程注重于用户交互和客户参与，能够最大程度的发现和发掘用户的真实需求，从而引导正确的软件开发。敏捷需求管理是敏捷过程的重要一环。良好的需求管理可以使开发团队交付更令用户满意的软件。敬请关注 
[updated: 2009.05.07 - added the slide]
Tags: Agile 敏捷, Analyst, Business
Posted in Agile 敏捷, ThoughtBlogs, 需求分析 | 1 Comment »
Wednesday, January 31st, 2007
本次活动由AgileChina与BJUG两个组织共同举办，由北京和利时信息技术有限公司提供支持。我们的目的是让一切对技术和敏捷等有热情的 同学们共同学习、共同进步。我们相信来参加活动的都是愿意交流，愿意上进的朋友。让我们一起努力交流，结交志同道合的朋友，把我们所热衷的技术、思想推广 到整个IT界。
这次活动采用开放的活动形式(类似Open Space和Unconference)，将由所有参会的人贡献并选出自己感兴趣的话题，每一个愿意交流的人都可以写出自己希望交流的topic，在活动 一开始贴在墙壁上，大家投票选择。得票最多的几个topic将会作为当天的Session奉献给大家。
主题1 敏捷软件实践 — 乔梁
主题2 敏捷需求分析师 — 冰云
http://groups.google.com/group/agilechina
http://www.bjug.org
Tags: Agile 敏捷, Analyst, Business
Posted in Life, 需求分析 | No Comments »
Sunday, November 19th, 2006
（本文发表于程序员杂志2006年第4期）
在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。
真的是这样吗？敏捷过程到底是如何做需求分析？用户故事和用例有什么区别？敏捷过程如何去管理需求的？这些是一些想要实践敏捷的人一直在困惑的事情。
我们常常看到书中讲，程序员拿到一个用户故事后，怎么计划，怎么分解，怎么写单元测试，怎么小步前进，怎么持续集成。这是典型的程序员视角。事实上，敏捷方法分为三部分，敏捷项目管理，敏捷需求分析，敏捷软件开发。上述书中提到的完全是敏捷开发中的实践，很多人了解到的敏捷，只是敏捷的三分之一。
在敏捷的团队中，作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看，只需要选择一张他感兴趣的故事卡片，了解清楚该卡片的需求，开始从功能测试写代码，等通过了所有测试就完工。基本上不需要考虑太多的事情，非常轻松愉快。但程序员向谁去问清楚需求？故事卡片是怎样写出来的呢？让我们来关注开发前发生的事情。
了解敏捷过程的人都知道，Kent Beck在XP过程中提到了现场客户，如果一个敏捷团队能够有现场客户，这当然是最棒的事情。但多数情况下，客户都是很忙碌的，很难全力投入到软件开发过程中。这时候，我们就需要商务分析师这个角色，来充当客户的角色。
我在ThoughtWorks的团队中担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事并将需求转述给程序员。同时，商务分析师也要代替客户负责功能验收测试。
敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。和客户进行交流，最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么，挖掘出他真正的目标。
在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求？有没有更好的解决方案？有没有简单并且低廉的方式？换一种形式是不是也能达到这样的需求？这个需求有多少地方涉及到以前的软件变更？
搞清楚这些事情后，就可以写出用户故事。用户故事的书写遵循一定的原则，一般包括三部分：”作为（系统的一个涉众），我想要（做一件事），从而（达到一个商业价值）”。在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。
举一个最常见的用户故事例子，”作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务”。其中，用户是系统涉众，登录是他想要做的事情，而他的目标是获得个性化的服务。
从这个例子我们可以想象到，这个页面可能存在两个文本框，用于输入用户名和密码，有一个按钮来登录，并且不登录就不能看到个人资料，另外，如果用户输入错误需要提示”登录失败请重试”。这就是可见性，也可以称为可测试性。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。
用户故事的作用有两个，一个是作为进度跟踪的依据，一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成，这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。
不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用。用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度和工作量都相差不多，这和用例有很大的区别。用户故事是小粒度的，可测试的，可见的，并且是有价值的。[注:此处存有争议，请读者辨证阅读，勿断章取义]
ThoughtWorks有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目，在开工的时候客户对功能需求还不明确，但需要快速推出抢占市场，正是最适合敏捷过程的项目。
在项目伊始，商务分析师和客户做了深入的谈话，了解他的商业构想，他的盈利模式，搞清楚宏观的结构，然后思考并整理获得的结果，花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善，不足以做好整个系统。但对于我们开始项目的前一阵，已经足够了。我们可以从这里开始项目。
敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不同的难度和风险，并提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选，客户可以选择这些用户故事，或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。
客户看到每个迭代交付的可运行的软件后或者得到用户反馈后，常常会有新的想法冒出来。有些想法是好的，有些想法就属于看到别家网站有这个功能，不假思索的提出的功能。这些不同的需求都需要经过认真的分析，找出哪些是值得我们立即考虑的，哪些是不用急迫的去实现的。
有一次和客户谈话时，他说到希望增加拍卖功能。那么，我们为什么需要拍卖呢？客户说希望让用户拍卖物品以获得最高价格。经过考虑，我们发现，网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求，因此，用户最终放弃了这个特性。
另一次，客服人员提出增加一个查询用户交易的功能，而此时我们有其他更加重要的功能需要先去考虑，查询用户交易功能可以由技术人员临时通过数据库直接代为查询，因为项目运营初期交易不是很多，暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上，始终没有排到最高的优先级。
客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合，客户也逐渐适应了许多敏捷思想，甚至我在和客户讨论时，偶然提起了后期的某种可能的情况，他们还能够帮我纠正应当考虑目前的情况，为近期的情况作计划。
用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展，是否已经开始实现？是否已经完成代码开发？是否已经开始功能测试？不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后，团队的开发速度基本保持恒定，我们就可以很容易的知道每个迭代能做多少个用户故事，这样就可以安排下一迭代的开发。
每个迭代内分析好恰好足够下一个迭代开发的需求，就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成，包括需求的了解，分析，评估和排列优先级。
在每个迭代开始的时候，由商务分析师主持召开迭代计划会议，在会议上向所有的程序员解释这个迭代要完成的用户故事，然后由程序员自由提问，知道他们能够获得足够开始实现该功能的信息。
在程序员完成一个用户故事后，商务分析师还要来代表客户做功能验收测试，查看是否完成了预计的功能，是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然，更多的测试还需要QA来完成。
我们的实践充分表明了，敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。这就是ThoughtWorks敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中，起到了纽带和桥梁的作用，是一个团队不可缺少的角色。
Tags: Agile 敏捷, Analyst, Business
Posted in Agile 敏捷, 需求分析 | 4 Comments »
Wednesday, June 7th, 2006
Quickstart是TW-UK提出的一种项目启动方式。这个东西通过和客户的不断交流和反馈，达到让客户了解自己项目的目的，让客户的IT和Business部门、最终用户之间在项目的目标和模式上达成一致。让所有人了解到项目的价值，从而使得项目能够平缓和畅通无阻的开始。
这次Quickstart的培训是3days的培训，大概是个走马观花型的概览，时间比较紧迫，做的实践还是不够。不过能够有Liv Wild来给我们培训是个很好的机会，平时项目中的问题可以一次提出来搞清楚。比自己摸索要快得多。
Quickstart将一些实用的技术和技巧串接在一起。包括各种访谈、总结会、头脑风暴、Process建模、与客户的互动游戏、交互设计、计划和评估、各种有效的可视图等。这些东西的目标都是要让不同的客户都能够共享思想。每个单独的过程其实我们都不同程度上实践过，但能够把它们有机的串接在一起，确实是很不错的方法。
Gino博士在Awayday上说，要阐述个人感觉给另一个人，必须有同样的Sementic Base。Quickstart就是本着这种思路，用各种能够共享体验的方式，将项目的Sementic Base展示给所有人。这是Quickstart的实践的原则。任何可以达到这样目标的实践，都可以引入Quickstart。这和Agile一样，需要根据不同的情况来制定不同的实践方式。在中国，我们肯定需要对Quickstart进行一些本地化才可以用。
Quickstart不同于传统的前期需求调研和分析。这是一次和客户之间的互动，对客户本身也是一次反思的过程。Quickstart是迭代式进行的，一点点地了解需求和业务，不停的交流和反馈。一般要持续1-4周。复杂的项目需要较长的时间。
据说，在英国，购买公司Quickstart服务的客户甚至超过了购买Agile开发的服务。因为能够Quickstart帮助公司了解他们自己。这也是很多国内公司需要逐渐改变的观念。对于国内的一些项目，领导们常希望我们拿着需求说明书就给出设计和开发方案，这样很难和敏捷开发接合起来。至于如何在国内尤其是政府类、国企类项目应用整个敏捷过程，还需要具体的实践和思考。
虽然了解了很多的东西，也有了不少的收获，但也还存在很大的困惑和不解。必须要通过一次实践才可能完全了解。希望下一个Project能够有机会做一次。
Tags: Agile 敏捷, Analyst, Business
Posted in Agile 敏捷, 需求分析 | No Comments »
李默，ID冰云，ThoughtWorks公司高级咨询师、业务分析师，敏捷过程教练，BJUG创始人。目前主要专注于互联网产品需求管理与市场营销的合作、产品交互设计、敏捷组织方法等方面的工作。联系方式: icecloud (at) gmail.com 
