冰云@Blogging

Beijing Code Jam - 2 days agile development project

上周末忙忙碌碌的，在公司做了两天的公益项目。具体的过程郑晔说了不少了，我从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. 要在很短时间内需要搞清楚足够开发的需求，因此我们确定了项目远期目标、用户交互流程、特性的优先级，取消了评估开发时间一项。在下午需求会议开 始前，我们制定了：1 项目目标 2 功能范围 3 优先级 4 界面交互原型 5 用户故事 6 细节验收条件等会议步骤，在4个小时内准备好了可以开发的需求。
2. BA、QA和客户坐在一起交流需求。这是非常理想的情况，很多项目由于种种条件限制使得BA/QA没法从一开始在一起。
3. 需求和界面原型全部采用纸质管理，没有除了照片以外的任何电子存档。不管是开发人员还是BA/QA，都手持卡片和人交流，有任何问题和发现都记录 在卡片后面，这节约了很多时间。（当然，由于QQ太过谨慎，怕卡片被打扫卫生的阿姨清走，特地锁在了她的宝箱里，结果晚上胃病第二天没法来……由此可见， 项目风险总是不可能全部预测的）
4. 在Story的上面标注了依赖关系。以往做Story经常忽视这点。这次特别标记出来，在开发过程中作为Dev开发的参考。
5. 优先级的制定。没有采用传统的MoSCoW法，而是就用1-9的数字来表示。我们最终将1-3的大多数需求交付，客户很满意。
6. Hight Level 系统结构图。通过整理此图，我们全面的了解了系统的蓝图，客户也在过程中重新反思了不少的特性。这图不完全是流程，其实更像是Information Architecture+Domain Model，结合了功能+界面两种不同的元素

做的不够好的地方也有

1. 由于对Rails开发的效率无法预估，我错误的假设了两种不同类型的文档在提交时候有很大部分功能可以复用，因此在写第二类的时候，简化了一些Story，最后证明这些还是得写上。此处犯了INVEST中I的错误
2. 有些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. 自组织的团队。真正实现了自组织。每个人都尽力将事情向好的方向推进。大家都尽职尽责的完成任务。
2. 在开发优先级1需求的时候准备优先级3的A/C和优先级4-8的卡片，使我们不用在一开始就准备所有的功能。
3. 采用活动墙壁做需求墙，team需要看什么就把那个移动过来近些。
4. 开发团队频繁的轮换pair，可以收到很好的效果。从BA的角度可以很明显的感觉到哪个pair遇到了问题，从而协调team之间的取长补短。
5. 和客户交流频繁，所有一开始由于时间关系无法确认的需求都交由现场客户Steven解答。中间根据进度，我们建议更改2和3级别优先级的顺序，客户也确认了这次更改的必要性，使得我们最终能够交付正确的产品。
6. 一天两次的简短的standup。由于大家平时交流的充分，standup可退化成宣布值得大家知道、比较重要的事项的碰头会，如果没有事情说就不用说话。
7. 简短的retrospective。自组织的团队不需要太多的反省。每一个人都是很好很有能力很有想法的成员，只要列出来我们发现的问题，大家会自觉的去解决。
8. 从一开始就运行的test和build。很大程度上提高了团队的整合度。
9. 8dev团队，一天95次的提交次数，一天18个migrate脚本，一天12张story卡的速度。

做的还不够好的地方或者改进的想法还有

1. 在开发之初的设立UI pair，在开发后期设立专门BUG pair的作用不可忽视
2. 每天的switch pair还是做的不够多。我认为对于rails开发来说，理想情况2个小时就应该进行switch。更频繁的Switch能够使得知识传播的更快，尤其是 在团队中不是所有人都对Rails开发熟悉的情况下。由于做的还不够好，出现了有的pair工作在一张卡上太多时间的情况，原因是俩人对这块都不够熟悉， 如果早点switch就好了。
3. 由于Rails开发中一些scaffold的存在，几个相关的CRUD的story可能一下子就全好了。这对写Story提出了更多的要求。要精确掌握粒度不太容易
4. Rails和Textmate的中文支持还有待提高。看哪位神仙有空，给contribute一些plugin啦、月光宝盒什么的。

总之，如何更好的交流和协作是我们这次Code Jam学到的知识之一。Rails开发的效率极高，这对开发过程和开发团队就有了更多交流协作的要求。大家必须要通力协作：多提交和更新才能最快的把代码 整合在一起；多交流才能保证不会有架构和数据迁移的冲突；多和BA/QA交流才能不走错路做错功能；多更换pair才能学到更多的技能技巧，保障对系统的 了解程度；多和用户交流才能确保需求不会迷失方向。

周六晚上5点半showcase的时候，1优先级的功能差不多都出来了，可以大致预测到第二天的成果。可惜由于周日我下午又赶飞机，没能看到最后交付的场面，非常遗憾。

Tags: Agile 敏捷, Analyst, Business

Posted in Agile 敏捷, ThoughtBlogs, 需求分析, 项目管理 | 2 Comments »

进行性能测试

最近在项目中兼任QA的角色。QA的职责当然是保证质量。性能是质量的一部分，理所当然应该是QA的职责范围嘛。这次team中负责性能测试的QA调走了，只好由我硬着头皮顶上去了。想到前些日子还兼做了几天Dev，哎，忽然觉得自己好多功能啊。

以前从没亲自动手搞过性能测试，但在原理上了解，并在项目里看别人测过（有时候还指指点）。这次选用Jmeter进行测试，是第一次上手。好在这东西对我来说不太难，今天一天就做出了10,20,30,50并发的四组数据。

按照测试计划，我们在测试数据不变的情况下，增加用户的并发数，找到随着并发数增加系统的break point。然后根据测试结果进行下一步的动作，改进或者保持现状等。

性能测试关键不是看一次的数据结果，而是要进行持续的跟踪、度量、比较、分析。根据测试数据找到系统性能瓶颈，确定其优先级，先解决影响最大的部分。例如目前我们项目的首页响应速度比其他页要慢很多。

纵向对比，随着并发人数的增加，每个测试场景的性能是否保持在一个可接受范围内。横向对比，对同一场景用不同的测试数据，看是否随着数据量的不同有显著变化。记录每个版本的运行情况，测试每一处改进，看所做的改进是否真的促进了性能的增加。

测试工具的选取也需要根据实际项目的情况来确定。我这次用的Jmeter也算是大众工具了，虽然测试AJAX有些勉强，还没找到好方法，但也勉强可用。不过它的交互设计实在是令人发指。

Jmeter是程序员做的交互设计的典型，整个菜单基于一个神秘的Tree，还可以增节点，定义变量，增加循环判断等。至于结果报表放在listener菜单中这样的事情就更不用说了。太技术化了，非技术人员基本上无法理解这奇怪的工具。怪不得多数团队都要程序员来做性能测试。

另外一个关于性能测试的常见工具是JProfiler。我们同时也用这东西找找系统代码里面哪个部分最耗内存。结果发现40%的内存占用是由于Sitemesh，30%的内存占用是Joda Time。令人惊奇的发现啊。马上干掉Sitemesh，某些页面性能提高了10倍。

Posted in Skills, ThoughtBlogs, 项目管理 | 1 Comment »

敏捷团队建设

敏捷团队建设 本文发表于4月《软件世界》

最近很多人都问我，有没有适合的人可以推荐给他们公司，他们正在招人，面试了很多个，但有经验的开发人员太难找了。有一个朋友在问我要人的同时，他手下的一个开发人员反而问我有没有好的机会，他想跳槽。

不久前一份报告称，中国本地软件企业面临的最大问题之一，就是高级技术人才的缺乏。造成这种问题的原因，主要是由于本地软件企业的人才培养机制和管理机制的欠缺。人才大量涌入外资企业和频繁的流动，导致了各类有经验人才的欠缺。

每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人决定离职的因素。

有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司觉得自己的一套软件不停的实施就能不停盈利——而开发人员最厌烦的就是做重复性工作；有的公司要求开发人员必须上班打卡——好的，那开发人员绝对不会晚下班一分钟。有的公司从来不举行内部的技术交流和培训活动——而开发人员希望的技术提高绝不仅仅是只靠读书能够完成的。

公司要依靠软件来盈利。而要开发一个成功的软件项目，人的作用是第一位的。而个人的力量相对于整个团队来说，又是微不足道的。稍微有点规模项目的成功都是集体努力的结果，而不是靠一两个英雄程序员能够完成的。为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。

我所在的公司不仅仅以敏捷过程著称，同时，它以其特有的文化和团队氛围吸引了一大批高水平的开发人员。他们不仅仅是认同敏捷而聚在一起，更多的是，他们向往着这种平等、自由、轻松、快乐的空气。

人与团队

在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。

项目成功的一个重要因素就是交流。保障团队内外顺利交流是项目经理的责任之一。公司鼓励员工之间交流看法和讨论问题。在公司内部，如果有闲暇时间，随时可安排一场讲座。这些讲座都是由员工自发组织和自愿开展，话题多种多样，不仅仅限于技术。经济、法律、业务知识等等，都是大家平时感兴趣的领域。在项目中，定期的Learning Lunch也是公司项目的一大特色。和客户一起围坐在餐桌前，边享受公司提供的午餐边讨论项目中的技术，团队的学习交流气氛自然会无限高涨。

除了自发的、自由的交流，还有一些约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。

图略：站立会议

无论是在项目中还是在个人的发展过程中，回顾与总结都是一个必不可缺的步骤。公司内部任何事情告一段落的时候都会有一个总结活动。迭代总结，项目总结，发布总结，陪训总结等。在这段时间内什么做的好，什么做的不好，如何进行改进。任何的过程和成绩都不能是静止不变的。只有不断的反省和总结，才能够在未来的发展中进一步提高。项目团队一起召开总结会议活动，在这个活动中，任何人不能够对其他人进行指责和攻击，一切都应该以互相信任为基础，我们的目的是提高下次的工作效率和增强同伴的信心，而不是批斗和推卸责任。公司对员工的绩效考核，也是类似的由一起工作过的同伴来进行评价，360度全方位考核。这种定期的总结和回顾，提供给了员工与团队自我成长的机会。

除了内部的交流，公司还鼓励员工进行技术创新和参与其他社会活动，例如参与开源软件开发、撰写书籍、向杂志投稿、参加和举办技术社群活动等。这些对技术社区的贡献，不仅仅能够提高员工个人的能力，同时还展现了公司员工的整体能力和提升了公司的知名度。对公司和个人来说是双赢。

环境与工具

如果你有机会到我们的办公室，你就会发现，每一张墙都被占得满满的。墙上可能会贴满了各种颜色的小卡片，这些都是正在进行的项目的需求。每张卡片都是一条用户故事，开发人员根据用户故事实现系统功能。这种被贴在墙上的一目了然的管理方法叫做可视化管理。在公司内部，开发、招聘、销售等各种流程的状态都被一一列在墙上。一来可以作为工作的进展图公示于众，二来可以使每个感兴趣的人都可以随时提出他的想法或主意，集思广益，将工作做到最好。

图略：墙面

公司采用大长桌作为开发用桌。座位之间没有隔板。一方面适合与敏捷开发中的结对编程实践，另一方面可以减少隔板带来的交流障碍。如果你到一个采用隔板的公司去走一圈，再来比较公司的工作环境，就会明显的感受到交流频度和广度的明显不同。公司提供给开发人员舒适的座椅，带有扶手并可以调节高度和后仰角度，以适合每个人不同的需要。如果中午工作累了，还可以躺在椅子上小憩一会养足精神以便下午更好的投入到工作中。

图略 开发桌椅

在项目中，必不可缺的交流工具是白板和纸。再没有比这更廉价和更好用的工具了。两个开发人员遇到了分歧，两人走到白板前写写画画，很快，一副清晰的系统脉络就出现在两人面前。分歧达成了一致，开发继续进行，而图像留在白板上，任何过路的程序员都可以驻足观看，如果感兴趣还可以问一问作者，更深入的探讨。在开发的过程中，随时遇到问题或需要记录的，都可以立即写在手头的白纸上，一些简单的算法草稿，也都是用白纸完成。这些白纸多是打印用过一面的纸张，环保而又经济。

我公司和其他大多数外企公司一样，为员工提供免费的饮料和零食。每天早上，公司的面包机都会工作个不停，烤面包的香气会和着咖啡的味道飘扬在空气中。午饭后，从冰箱中拿出一罐健怡可乐，冰凉爽口，喝下后休息一下就可以精神十足的开展下午的工作。下午四五点钟，正是开始感到饿的时候，到零食区找一块巧克力吃补充一下体力，顺便休息几分钟，活动一下筋骨。

图略 饮料零食区

公司还在办公室内放了一台电视机和一台PS2，午饭后和下班后，你可以和同事相约PK一场实况足球，既休息了神经，又和同事加深了感情。公司还经常组织各种体育活动。每周租一次羽毛球场，让长期在电脑前工作的员工运动运动，有助于身体健康。

以上这些是我公司在团队文化建设的一些做法，提出这些供大家参考，希望更多的公司管理人员，能够从中或多或少的汲取一些经验，将之用于提高公司开发人员的物理和人文环境。

改造公司的开发环境，可以先从很简单的做起，例如，在办公室的一角开辟一处饮食区，提供免费的饮料和食品；在走廊上挂一个白板，随时有人记录一些东西；为员工提供更舒适的座椅。这些东西花不了多少成本，但其收效是明显的。不论是技术部门还是其他部门，都会为公司这一点点人性化的举动感到高兴。有了高昂的士气，做事情自然也会更加积极高效。不需要公司一下子全部改变，但往往一点点的细节变化就能够获得全体人员的支持。虽然有些投资，但员工给公司的回报会更多。

无论是敏捷开发理论还是精益管理理论中，都提到团队的作用是最重要的。如果能够发挥人的能动作用，并良好的保持下去。我想，没有什么目标是我们完不成的。如果所有的公司都能够提供良好的环境给开发人员，那不仅仅是开发人员的的幸事，更是我们整个中国IT界的一大幸事了。

Tags: Agile 敏捷, organization, team

Posted in Agile 敏捷, ThoughtBlogs, 项目管理 | No Comments »

客户协作 over 合同谈判

客户协作 Customer collaboration OVER 合同谈判 contract negotiation

最近有人和我谈起他们的项目管理。他是一个项目经理，负责项目的进度跟踪和与客户的沟通。他能够很好的保持客户关系。他的团队中有一个年轻的程序员，工作充满热情，喜欢思考，喜欢用新技术，也很勇于指出问题。

有一天，这个年轻的程序员在客户处外勤，跟客户交流的时候，讨论到了系统某一块儿的功能。年轻的程序员基于他的工作热情，向客户提出，如果这么这么做，那可能会给你带来更好的功能。客户听了挺高兴，觉得可行，这小伙说的不错。于是就反映到了项目经理处，说这小伙干的不赖，表扬表扬。这项目经理听到客户的表扬，也附和的说，他确实很上进，回头我再给他当众表扬一下。

项目经理回到了公司，就把这程序员单独叫来聊了一下，他说，你给客户提建议，这样多思考挺好的，不过，咱们给客户开发，要一单一单的做。你说的那个功能我早就想到了，但我没提，主要是考虑这个功能实现起来很容易，我们可以放在下一期，我们引导客户一下，让他们提出，我们再把它说的复杂艰巨点，这样咱们很容易就能完成任务，下一期时间更充裕，而且还能收更多的钱。所以以后有想法咱们内部讨论，先别跟客户说。程序员点头称是。

这样的事情在很多公司都很常见。他们把客户视作敌方阵营，利用自己对IT知识优势了解，努力在一些地方上欺瞒和糊弄客户。

与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的囚徒困境，结局就是纳什均衡(Nash equilibrium)，或非合作均衡。

软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，咨询公司采用了加深客户协作的方式来达成目标。咨询师会和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。咨询师会站在和客户同一方的阵营，和客户一起思考、学习和成长。虽然说起来很粗泛，但我所认识的每个咨询师确实都在认认真真的为客户考虑。

另一个会产生非合作均衡现象的是按时收费的单价合同和固定价格固定范围合同的问题。一般PM书籍上都会讲FFP合同对买方的风险比较低，而单价合同对于买方风险可高可低，取决于内容和项目性质。

如果签订固定价格合同，通常的，由于价格固定，客户会倾向于在这个价格内挤入更多的需求，有些人甚至不顾质量而要求更多的特性，反正完成不了都是开发方的责任。而相对的，开发公司会希望在这里面减少成本，或者是人，或者是需求范围，甚至是不惜牺牲质量。最终两方博弈的结果就是项目出了问题。

这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己的能力，尽最大可能来保证质量和进度。另一种改进过的单价合同，是基于开发方对项目的理解和估算，报出一个固定价格。在合作共赢的前提下，双方信任并接受这个契约。这种情况好像更加适合国内的甲方。

前些天，一个原来的同事电话我，她以前是负责销售的，现在自己开了家公司。她雇佣了一个公司给她开发软件，开发了两个多月了还没见到是什么样子。眼看就要到交付期限了，她想去看看，就问我应该怎么样去中期查验这软件。我告诉她，要怎么怎么样才能看出这系统到底能不能做完，怎么看出到底做的质量如何等等。

瞧瞧，怎么样，客户也不是很好糊弄的嘛。你糊弄客户，焉知客户不会另请人来对付你？所以，在商业的博弈中，合作才能双赢。这就是为什么客户协作 over 合同谈判的原因了。

Tags: Agile 敏捷

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 项目管理 | 1 Comment »

敏捷团队中的角色

在ThoughtWorks一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：迭代经理，美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在ThoughtWorks内部，人与人之间是完全平等没有级别区分的。公司这种平等的文化，使得人与人之间的交流不会因为等级差距而丧失。同时，公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。

以前公司同事写过一篇团队角色定义的文章：http://news.csdn.net/n/20060429/89961.html， 补完一些。

• - Project Manager
  • 作为团队的精神支柱存在。与团队的每个人进行必要的沟通以保障项目成员的士气和稳定性。
  • 维持开发秩序，保障团队间交流的效率和效果，负责主持必要的活动
  • 消除外部干扰，负责与客户进行协调和协作。管理来自与客户的scope变更
  • 跟踪团队的开发效率，维持开发速率，进行适当调整以保证开发的顺利进行
  • 管理项目风险，维护项目风险日志，识别风险并采取措施防治风险
  • 负责最终的项目交付成功

• - Business Aanlyst
  • 需求获取与管理，与客户持续交流获取新的需求，并保持良好的客户关系。管理需求的优先级。
  • 保障下一个迭代需要开发的需求能够预备到位。提前准备好需要的Story卡片，在Iteration Kickoff会议解释每个Story的具体需求给Developer
  • 主持必要的会议，例如Iteration Kickoff和需求的评估活动
  • 对需求进行初步的功能验收，保证功能的交付符合原始需求

• - Developer/Architect：
  • 了解系统业务和需求，设计和演进系统整体架构，能够做出适当的技术决策
  • 编码，并对系统的每行代码负责，保持代码的干净，保持较高的测试覆盖率
  • 维护项目基础设施如持续集成服务器、版本控制服务器等
  • 评估需求，并在开发完成后演示开发的需求

• - Quality Assurance
  • 负责了解需求并编写需求验收条件，负责制定测试计划
  • 负责测试开发人员完成的需求，并报告错误
  • 负责对软件进行性能、压力、容量、负载测试等，负责项目的手工功能测试和发布测试

• - Iteration Manager - 小团队多由项目经理或分析师兼任
  • 负责项目过程的顺利进行，协调项目资源
  • 主持各种迭代会议，如Standup和Retrospective
  • 负责跟踪需求的状态
  • 负责项目的其他日常事务

• - User Interaction Designer -多和分析师为同一人
  • 在项目初期参与前期需求的收集，提出可行的交互设计方案，保证软件的可用性
  • 建立和维护Lo-fi prototype，负责指导项目的界面开发原则
  • 进行用户测试，持续改进系统的可用性

• - Database Administrator
  • 维护软件所需的数据库，定期进行数据备份
  • 了解数据库重构和演化方法，负责维持数据库的每一条更新脚本

• - System Engineer/Webmaster
  • 维护软件所需的各种硬件和网络系统
  • 了解敏捷开发中的发布过程，保证每次迭代发布的实施

• - Art Designer - 一般团队最缺少优秀的Art Designer，了解敏捷的Art Designer更甚
  • 了解项目的远景和规划，了解迭代方法，应用增量式美术设计方法
  • 了解软件的交互设计，能够设计出可用性良好的系统

有一类角色，在敏捷团队中至关重要，不得不重视起来的，就是Customer。

• - Customer
  • 理解迭代开发的过程，与团队进行频繁和和谐的交流，参与团队的各种必要的活动如Showcase
  • 理解需求和排序需求的优先级
  • 验收需求，并及时的提出反馈

我经常说，分类学毫无用处，因为很多时候分类无法cover到所有的情况，尤其是两者皆有的时候。我在项目中曾经同时担任过BA/QA/IM，这些角色的职责都是我应该了解的。同时，有些职责，例如随时发现和识别项目中的风险，保证尽最大努力完成任务，主动交流，遇到难以完成的任务及时尽早告诉相关人员等，是每个角色都应当承担的。

为了项目的成功，尽可能多的做一些事情，对个人和对项目都是有利的。

Tags: Agile 敏捷

Posted in Agile 敏捷, ThoughtBlogs, 项目管理 | 2 Comments »

令人烦恼的项目估算

Annoying Project Estimation

对一个项目的评估，往往被要求在项目需求还不明确的时候开始。不知道你是否有这样的体会，客户给你简单介绍了一点需求，或者发给你一份写的很粗略的文档，就要求你给个价格看这东西大概是要花多少钱多少时间才能建成。以前我做网站的时候，遇到过好多好多的这类问题。

在软件开发过程中，总要面临一个”估算(Estimation)”的问题。这个项目需要多长时间？这个模块你大概多久完成？一共要花多少钱才能搞出来？软件开发的成本主常常用人月来计算，当然，也有人/小时，人/天。从数学上说，计算一个时间的先决条件，是必须要知道速率和距离。那软件开发度速率是多少？开发要走完的距离又怎么估计？

假定”人天”可以作为我们需要找到的速率(Velocity)的单位，就是某个人每天8小时能干的活的工作量，或说他的开发能力。对于一大堆待要开发的需求，它的总工作量和整个团队的单位开发能力的计算需要考虑更多的因素。

先来考虑需求的总量。我们来看这一个例子，列举你认识的满足下面条件的人：人，男人，20岁的男人，20岁的 头发有些染黄的男人，20岁的头发有些染黄抽烟的男人。从这一组词中，我们可以看到，从左到右描述的越来越具体，你能列举出的也越来越少。而反过来顺序，词的外延更大，你的能想到的却越来越多的。

同样的，对于需求的描述，如果描述的越细致，你就越能够准确的估算它的工作量。 登录系统，这样的需求很难说要多久。而一个使用用户名密码登录，支持找回密码功能的登录系统就稍微好一些。如果能够画出界面原型图那就更加清晰了。对于这样的需求，我们可以用”理想的人天”来评估。我们说某一个需求的成本，是2 Ideal Days。 就是一个人在理想的2天内能够完成这个工作。

说到开发人员的”理想的人天”，就不能离开团队孤立的看。一个团队包括项目经理和需求分析师、测试员等角色。他们的工作不直接反应到代码量的多少。如果只考虑一个项目开发人员的代码开发量成本，毫无疑问要亏损的。另外，团队成员水准参差不齐，不同的任务不同程序员来完成所花费的时间也不同。因此，单独相加每个成员的”人天”毫无意义。必须要整体考虑一个团队的总”人天”。

那么如何衡量一个团队的总”人天”？如果一个团队已经经过长期的磨合，那么可以从以往的数据来获得他们的开发量。 如果是新建立的团队，没有经过磨合，那就需要开始实际进行一段时间的开发，在开发后3-4个星期再回头来计算这几个星期的团队速率。一般的，一个团队经过一段时间的磨合，在开发速率上会有缓慢的提升。例如一个需求的估算是5理想人天，而团队实际开发了10天。那么团队的速率就是5理想人天，团队的负载系数，即正常被其他事情干扰而降低的比率是2。

有了这个团队的速率，项目经理就可以放心大胆的说，我们团队有10人，开发能力是”n理想人天每周”，负载系数是2，由于有20n的需求总量，我们大概在40周左右完成。因此，我们的报价是xx,xxx,xxx元。

如果你有幸长期跟踪过一个团队的开发速率，就会发现很多有趣的现象。一开始，团队速率很低，但慢慢的成长。到达一定时期后，就会稳定在一个固定值附近。有时候有新的成员加入进团队，团队的开发速率会出人意外的降低一段时间再慢慢回增。

成本、时间、范围、质量，这是项目管理常见的四要素，四者很难同时满足。如果关心时间，又不想出钱，还要完成那么多功能，那牺牲的就真正是质量了。常说的一分钱一份货，在软件开发中反映的淋漓尽致。所以，为了能够保证按时按质完成任务，一个合理的开发价格是合格的项目经理必须能够估算出来的。而这需要长期经验和实践的积累，急不来的。

但有些时候，也有些不好处理的问题。有人问：我是老板，如果我的开发团队合起伙来编造一个估算，把我的需求估算的很多，而把他们的速率估算的很低，工起来工作量不饱和，老消极怠工怎么办？呃。。我只能说，这只好借助于开发方法以外的事情了，例如奖金激励、绩效考核、引入外部咨询团队(例如ThoughtWorks)等等，人的问题不是能够简单靠过程就解决了的，如果道歉有用的话，要警察干嘛？

Tags: Agile 敏捷

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 项目管理 | 1 Comment »

What is a ProjectManager?

Searching what is a Project Manager?

define:Project+Manager

The person or firm responsible for the planning, coordination and controlling of a project from inception to completion, meeting the project’s requirements and ensuring completion on time, within cost and to required quality standards.

A systems analyst with a diverse set of skills–management, leadership, technical, conflict management, and customer relationship–who is responsible for initiating, planning, executing, and closing down a project.

The Project Manager defines, plans, schedules, and controls the project. The project plan must include tasks, deliverables and resources – the people who will perform the tasks. The manager will monitor and coordinate the activities of the team, and will review their deliverables.

IMO, PM is:
coordinator,assistant and best friend of team members
planner, monitor, reportor of the project or progress.

Posted in 项目管理 | 1 Comment »