天机不可泄漏

只要你开始与其他人一起做任何事情，你就在构建一支团队。 1. 远景 远景，就是能让团队感到激动的大成果。 大成果也就意味着要有大的吸引力。第一步就是设置目标。这个目标应该是包含挑战的，能提升个人价值的。 2. 承诺 有的人很喜欢承诺；有的人不敢轻易许下承诺。是因为于承诺所带来的一些附属品，承诺经常被认为是一个危险的概念，比如，承诺可能意味着要花更长的时间，或者要投入更大的生产力。 如果一开始你如果没有承诺，这通常意味着你会不在乎，甚至是大家都不在乎。 能解决这种问题的方法有两种：1. 建立信任的氛围。 2. 营造相互鼓励和包容的氛围。 3. 信任 信任是解决害怕承诺和滥用承诺的良方。信任意味着对团队和远景充满信心。如果相互间产生信任，那么团队成员会更加愿意去尝试不同的事甚至是一些有潜在损失的事。 当队友作出承诺时，信任是最有效的回应，因为每个团队成员都相信那些对未来做出的承诺都是可信的。建立信任最有效的一个方法就是消除不确定性和增强安区感。 4. 包容 领导者要和团队成员或者潜在的团队成员进行沟通，互相去了解对方，使大家对远景都有一个确定的概念，包括让大家了解到风险的存在、回报以及如何达到目标，并且了解队员疑惑的地方。 5. 交换意见 最后，团队成员在自己熟悉的领域提出各种信息。这个时候，信任感会不断的增强，团队成员会热衷于协作。 队员互相听取建议，最后达成共识，这里面需要一些沟通的技巧，比如：明确的提问、良好的倾听和直接的回答。

1. Patterns & Practices 团队 (via)   2. An XP Team Room 英文版：http://www.scissor.com/resources/teamroom/ 日文版：http://www.scissor.com/resources/teamroom/indexjaJP-utf8.html  (最近看日文越来越吃力了，反而对英语感觉越来越好了。) 3. AOL 团队照片 如果你订阅我的BLOG的话，会发现最近在有很多相关文摘输出在http://feed.allenle.cn上。 阅读更多…

在上一篇《产品的客户满意度》中，我们了解到客户的满意度是被分为：阈值条件、线性条件和惊喜条件3种。 如上图所示， 阈值条件(必需功能)：当客户满意度达到一定程度后，增加必需功能的实现，对客户的满意度的增加是有限的。 线性条件(线性功能)：每一项线性功能的实现直接使客户满意度得到提升。 惊喜条件(惊喜功能)：一开始实现的惊喜功能，可以快速的使客户满意度得到提升。要注意的是，有时候惊喜条件会变成必需功能。 所以，在产品功能的开发优先级就是： 实现部分的必需功能，但不需要实现所有的必需功能，因为，后期必需条件所带来的客户满意度的提升是有限的。 尽可能多的线性功能。线性功能所带来的客户满意度提升始终能够得到保障。 少量的惊喜条件。因为惊喜条件会逐渐的变成必须条件。1年前的惊喜，可能到现在已经变成必需品了，所以还是把惊喜留在后面吧。 在每一次的迭代中，首先确保必需功能，因为这是生存的根本；其次尽可能多的线性功能，稳步提高客户满意度；最后，少量的惊喜条件，给你的客户一个小小的惊喜吧。

客户如何被满足 我在做旅游计划的时候，通常对住宿提出的条件是：有一张床，一间浴室，房间干净，安全。我对于酒店的要求也就只有这些。如果其中少了一个条件的话，我估计我不会选择这家酒店。OK，现在好的是，基本都能满足我的要求。我在想如果那张床更加大一些如何？恩，不错。有免费的网络接入呢？恩，更好。甚至有WII可以供你娱乐呢？Perfect! 看，客户就是这样被满足的。 Kano模型 这个模型最初是由日本管理学家Noriaki Kano提出的，他的方法帮助我们搞清楚一系列服务、功能是如何被分为3类的： 阈值条件。 线性条件。 惊喜条件。 在上面的例子中，你能找出哪些是“阈值条件”、哪些是“线性条件”、哪些是“惊喜条件”吗？ 阈值条件，就是必须具备的功能。比如一张床，一间浴室，房间干净、安全。如果提供给我的2张床，我想对我的满意度影响不大。例如登录界面，是必须的，但用什么设计，用什么cool的技术实现，对用户的满意度没多少影响。 线性条件，就是“越多越好”或“越……越好”的功能。如果酒店的床很大，浴室能提供高级淋浴设备，那我是不是会更加高兴呢？当然。而且如果有更好的床褥，并且需要为此付出额外的费用，我想我也是会愿意的。一个流程从原来的6步，减少到3步，是不是更吸引人？返回一个搜索结果从用时5秒减少到1秒，是不是能让客户更加满意呢？ 最后，惊喜条件，哇！这个房间居然提供WII！是不是很爽？没错，但是如果没有它，对酒店的满意度也不会因此而下降。也就是说“惊喜条件”是你自己可能都不知道酒店能提供的服务。在我一开始用gmail的时候，就经常发出这样的感叹，哇居然还能这样！ 最后 通过本文，我们知道了客户如何被满足的，并且把客户满足的程度分为3类，分别是“阈值条件”、“线性条件”、“惊喜条件”。 通过对客户满意度的分类，我们就能排出我们的行动优先级了，敬请期待——《制定产品功能开发优先级》

开文      今天工作中经过讨论做出决定——重构Platform。 问题      怎么会导致重构Platform？ 宣言和原则      罗列出敏捷开发的宣言和原则，也许能说明遇到的问题。 宣言 个体和交互胜过过程和工具。 可以工作的软件胜过面面俱到的文档。 客户合作胜过合同谈判 响应变化胜过遵循计划 原则 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。负责人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单——使未完成的工作最大化的艺术——是根本的。 最好的构架、需求和设计出自于自组织的团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后对应地对自己的行为进行调整。 检查报告 　　首先，我们错过了第1条和第3条原则。尽管在开始，使用了一些集成工具，想以工具来指导持续的自动集成和交付，但该工具效果较差，有较多不满意的地方，包括稳定性，时常发现不能正常的从版本管理工具中获取代码。后来采用人工集成，收到效果，这样集成的周期能维持在周。 　　其次，我错过了宣言第2条。并不否定文档，而是文档数量应该得到控制，之前我试图完成完整的文档，并且试图维护这些文档，发现『编制众多的文档需要花费大量时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大、复杂的谎言，会造成重大的误导。』(摘自《Agile Software Development – Principles,Patterns, and Practices》)，最好的教训是在做Finance那块东西，我发现在做文档的时候，貌似在编写初级会计教程，最后不得不放弃。而在最近的开发体验中，发现原型图是很好的“初期文档”，而初期编写的项目计划可能就会成为“庞大的、复杂的谎言”。 　　最后，我们做的够好的地方。项目开发期间，我们和业务人员保持良好的沟通，天天都在一起工作；同时，我们获得了最大的信任和激励；我们采用传递信息的方式，是面对面的交谈，这是最具有效果并且富有效率的；几乎很少加班，为了保持一个长期的、恒定的开发速度，这条是很重要的   ；做简单的设计，这个是John最推崇，也是我比较欣赏的一点。 最后 　　相信之后的开发工作会有更多的实践体验，会有更多可以学的东西，包括很久一直想，但从未体验，近几个月来最大的收获:Be Professional