[Story]
Scrum等Agile开发技术已经席卷全球，成为解决目前项目困境的又一选项。但要将Scrum融入到Offshore项目开发，在现实中会遇到非常多的障碍。联迪恒星在3年的实践中，在经历一些失败和成功之后，逐渐建立了适合实际情况的离岸敏捷开发模式。虽然成功建立起合适的敏捷模式非常的不容易，甚至在最初会增加成本，但一旦形成，将会持续不断地提升开发的效率，品质，降低开发成本，达到用户满意度以及开发者的成就感的双重满足。联迪恒星也有自信，在既有的成功经验的基础上，为贵公司的建立起成熟的敏捷开发模式，获得项目更大的成功。
经过了一些事情，我认识到其实目前的Scrum团队大部分已经开始失败。
这个原因让我反思了很久。因为各个团队有不同的原因，但是都不约而同地走向平庸，甚至懒散。是缺少管理么，无庸置疑。指定项目管理人员当然可以解决一些问题，但这样做，就代表了对信心和梦想的背叛。那么这个管理在哪里丢失了呢。有可能是团队，有可能是PO，也有可能是那些掌握更多资源的部长，经理们。而在我看来，最大的问题就在于这些丢失，让所有人感觉到问题，但是谁都不愿出来承认这是我们的错。
现在该是我们首先站出来的时候啦。
开发团队，从一开始，就希望按照着怎么舒服怎么来的方式行动。在他们看来，一切Scrum的实践都是在为自己的舒服而服务。其实不然，Scrum最终的目的是让项目成功，而增加开发者的舒适度，只是促经这个目的的途径。但是如果某些舒适度，其实违背了这个目的，那么这个就是背弃。例如一些必要的文档已经不再书写，一些重要的设计已经不再认真。而这些暂时的舒服，带来的无非是项目的混乱，而开发者的痛苦也就来临了。所以到了现在，即使是开发者，也在期望着有人能来管一管。
接下来是我们这些Resouce的管理者。我们做了什么，我们除了和客户谈妥单价和工作方式外，剩下的就只是那些琐碎得不能在琐碎的事情。我们高喊口号，却从不直接出力。我们希望控制和来自团队的报告，却对团队的不足和懒散视而不见。结果，我们在享受Scrum让我们轻松的同时，开始憎恨Scrum，认为是它，让团队一天一天松懈。
冰冻三尺，非一日之寒。我不想去讨论客户那边的问题，我只想说，我们只有改变自己，才能让自己强大得足以去帮助客户甚至挑选客户。
最近工作上发生了很多的变故。当一个包袱放下，拿起另外一个包袱的时候，你很难说是这是一种痛苦，还是一种解脱。
年初的时候，一切都在按步就班。正因为如此，也注定了今年又将无法改变，年初就已经注定了年终不可能或得成功。所以期盼期盼着变化的到来，但其实心里还是默默地念着，其实真的变化来了，也许还会感叹现在的日子有多舒服。
果然，在我虽然已经开始准备，却还没有获得成果的时候，期盼已久的变化象狂风暴雨一般呼啸而来，让我猝不及防，更谈不上做什么准备。可是事已至此，去缅怀，去伤悲也是没有用的，忘前看吧，至少变化已经发生。虽然这个包袱抬起的时候，我多半是不情愿的，但正因为无法确定，所以才有好坏不明的刺激，才有争取努力的动力不是。
随着既有体制的不断被撕破，开始忙碌着为手下的人的项目寻着落。其实实施起来远比想象的要复杂，因为有很多不确定的因素，总是在不断判断，分析中寻找最佳的机会。渐渐的，开始有了新的变化，从之前为一个客户的包人开发，变得更多元化。有产品开发的全力推动，也有外部派人的学习和锻炼；有既有客户的包人继续，也有新客户新项目的积极响应；有面向用户的应用开发，也有面向企业的系统开发。。。也许这个阵痛是不可避免的，那就是再猛烈些又如何，至少我们还存活着，那么我们就有继续前进的机会。我们变化着，我们就有无限的可能。
无论如何，还是要和过去的两年说拜拜了。在这两年里，自己从无知，认真，狂热，冷静，反省，妥协一路走来，学到了很多，这也让我更加清楚地知道，无论外界形式如何变化，内心需要保持相对的平静。只有这样，才能做到“胜似闲庭信步 败也处乱不惊”。相信终有一天回头看看，现在不过只是一次华丽的转身而已。
事情的源委是这样的。
1）打开自己的Blog网站，发现不能正确跳转到主页
2）在Gmail中收到一封，宣告我的Bythost帐号挂起的邮件
As a result of the high MySQL server load and resource usage, your account b11_999999 was suspended.
3）进入Bythost的cPanel控制平台，已经通知我的帐号挂起，需要升级
至此已经清楚不能跳转的原因，按照经验采取措施
1）在cPanel中，发出一个技术票给管理员，我就写了一句话“Please reactive my account”
2）数分钟后，收到管理员的Mail，确认被重新激活。网页可以正常访问
3）进入WordPress后台，看到了竟然有2000多封待认证的评论，立马知道了这次数据库超额的根本原因
4）用手一封一封删除，显然太慢，直接进入数据库，删除了这几天的所有评论。因为也没有什么评论，也不怕删除合法数据的。
5）发现垃圾评论还在攻击，过了一会儿又攒了十几个，看来必须关闭评论功能。有很多方式，可以参考http://www.xuelangteam.com/blog/wordpresslaji/
最后选择了直接关闭所有文章的评论功能，等风头过了，再重开
经过一番努力，终于完全恢复，看来只要暴露在网上，不管网站又多小，都要小心来自外部的恶意的攻击。
算上这个月，Scrum成熟度模式的评价已经默默进行了20个月。现在该是说拜拜了。
记得3年前从原来的部门转入的时候，我向部长提出一个很奇怪的问题，为什么新的部门不能把每个人的评价公开出来。因为公开出来的评价能让我们清楚地知道自己在一群人中是否出色，又是否拖了后腿。但谁都清楚，公开与否其实是一把双刃剑。
2年前刚刚迈入Scrum的时候，我很烦恼每个月的评价，因为再也没有一个Leader能帮我来分担。一个人要写出2,30个人的评价本就很困难，更何况我还无法深入知晓每个团队每个人的表现。
无意中发现，Scrum有种Team评价的方式，于是开始设计适合Scrum的评价项目，以及更加公开，互动的评价方法。这就是现在的Scrum成熟度评价。
对于初衷，当然不希望大锅饭，而是个人的成就必须体现在Team的表现之上。个人表现再出色，Team表现不行，依然会有差的评价。期望就是，表现差的人会得到更大的压力，表现好的人也更有动力去帮助团队的其他人。
其实也考虑到，一些个人表现，特别是项目外的额外付出，以需要有途径去正面评价，于是衍生了TeamBuilding这种个人补充评价方式。
初衷归初衷，但是现实并不是完全按照我的想法运行。每次的评价，得到的反馈越来越少，常常SM评价就是最终的评价。而评价公开的结果，也不比私密来得透明，受人欢迎。
于是走到了今天，一方面Scrum的开发人员已经开始缩减，导致这种评价方式，即使在一个部门内也越来越另类。另外一方面，公司的评价方式也做了改变，导致目前的方式已经变得没有意义， 也无法继续执行。
即使如此我依然要求大家把3月份的做完。因为我希望看到的是一个有所准备的结束。今天写完成熟度评价的那一刻，我感觉有种如释重负的感觉，自己再也不用为这个小怪物当惊受怕了。。。
也非常感谢大家在这20个月，每个月底对这种评价方式的支持。
这个月底，有一些人即将离开团队，留下来的人也有一大部分做了调整。现实让人不得不承认，其实我们的Scrum并不成功！但是我依然乐观，经过一些挫折，Scrum的一些真正的做法，想法一定能够更加深远地方式影响我们。
无论是今后的瀑布管理和Scrum混合的项目，还是更加激发设计的Game，或是从0起步的商业产品研发。我都相信，Scrum的实践还将持续下去。而对于一些固有的，不合时宜的方式，我依然会去挑战。
时隔一年之后，公司有组织了一次中层干部的联谊会议。
和上一次相比，市场和公司已经发生了很大的不同。当时日元汇率很高，公司的业务也是应接不暇。而现在一方面日元汇率已经下降超过20%，而且公司的业务量也发生了萎缩。
其实这些问题是每一个在这个对日外包行业的公司要共同面对的。没有充足的准备和合适的应对措施，就只能在这个冬天死去。
公司很多人都清楚这一点，所以也有越来越多的部门部长，经理一方面开始做好现有客户的满意度，另外一方面也在积极地寻求新的利润增长方式。
我也是他们的一员。但是我很清楚一点，就像我在微博里面写的
有时候团队的问题，就是所有人都只有同样的能力；有时候公司的问题，就是所有团队都在同样的思考；有时候行业的问题，就是所有公司都在走同样的模式。。。
也许我们正站在一个十字路口，何去何从，就看我们做出什么样的选择。
Scrum成败的关键
1. 善于控制全局的PO
理解产品内涵是PO的职责。而现实中，要帮助项目成功，
优秀PO还要能够把握全局。对于每一个Sprint的内部的计划，分工
是Team责任，PO无需深入。但是整个Product的开发计划，
必须由PO确定，并且不断去跟踪执行。
2. 懂得如何和PO交流的优秀Team
理解式样要求，并且就式样提出问题，这是普通Team的要求。
在Scrum中还要求，Team能够站在PO角度，和PO讨论问题，
提出自己的方案。只有这样，关于Team拥抱变化，关于Team的
责任感才能够实现。
用技术者语言容易，学会用PO语言交流是很困难的。
3. 一个全身心投入，适时介入的优秀ScrumMaster
ScrumMaster不仅仅是一个布道者，他要深入到Team的工作
中，在Team遇到问题，或者Team浑然不知却有风险的时候，
能适时提出来，知道Team如何去改进。
而现实中很多SM，只能宣讲理论，组织流程，事后诸葛。
Scrum的成熟特征
1. 团队与PO充分交流，能够更早地发现问题，更快地解决问题，
同时由于Team也参与了式样的改进，从而使得Team天然拥抱式样改变。
2. 融洽的团队与PO的关系和氛围。其基础就是相互的信任，减少不必要的
确认，承认，解释。这也能提高团队的OwnerShip，提高主人翁想法，
从而团结一致地提高产品自身价值
3. 不断成长和成熟的团队。团队通过周期的回顾会议（我们使用KPT会议
的形式），不断自己寻找问题，寻求突破和改进。一旦这个持续改进的
巨轮开动了，就让一切都能称为可能
4. 由于Scrum天然的是一个一个迭代。这必然带来了回归测试的不断累计。
普通瀑布，可以最后用一个专门的测试阶段，把所有的东西一个不落的测试
一下。可是Scrum不行，所以就必然要求持续集成（CI）来解决这个问题。
CI不是Scrum特有的，却是Scrum最需要的。而且CI也能为TDD实施提供
基础。
偶然机会看到，虾米网的口号是“Give Music A Chance”，联想到最近发生的事情，不禁有感而发，“Give Change A Chance”。
一位非常受人信任且思维活跃的同事，向我提出了辞职。其实我特不愿意接受这样的事情，倒不是仅仅因为他离开了，自己少了一个人。而是这个人，是我希望能够改变环境的，而他的离开，从心里依然是满含祝福。
因为我们需要改变，所以问题就落在，是环境改变人，还是人改变环境。
要环境改变人，那前提基本上是，公司突然出现一个乔布斯的人物，大刀阔斧的彻底改变公司的现状。别说我们这样的小公司，就像柯达，诺基亚这类的大公司，也不是请一两个潮流CEO所能扭转的。所以这个并不现实。
所以剩下的只有让人来改变这个环境。这里的人是指那些从下而上的，有着很高理想的，潮气蓬勃的年轻人们。我们并不是没有这个群体，只是让我懊恼的是，这些人一旦冒头出来，很快就因为环境改变过于缓慢，而离我们而去。更加严酷的现实是，他们出去之后，往往比留下更好，还是因为这里的环境变化太慢。
这位同事，很诚恳的表达了对我的看法“你很能干，工作非常务实，也是在努力一步一步寻求改变，可是。。。这些改变的步伐实在太小了，太慢了，让我看不到信心和斗志。。”我明白他的意思，这就是现实，我是要考虑如何去改变，但首先要做到的就是养活我们自己。作为一个外包企业，养活自己，常常就意味着，不要太多变化，不需要开放思维，只需要认真踏实，安分守己，成本低廉的程序员们。所以我看不到任何跳跃的可能性。
最近养活自己这一块颇为不顺，但是却又莫名其妙给了我改变的机会。之前优秀的人才都被焊死在外包项目中，现在人员缩小，刚好可以出来一些优秀的开发者，去做我们期望的事业。和以往不同的是，他们可以是全职的。
所以与其对现在的市场唉声叹气，无能为力，还不如认认真真地考虑一下如何把握好这次机会，实现真正改变的跳跃。
正如亲人和我说的，要不，就干一把，如果干不好，即使走人，至少不会留下遗憾。那就give change a chance吧。
MEAP故名思议，就是移动企业应用平台。它不是指某一项移动软件开发技术，还是一种移动解决方案，是成套完整的移动软件开发管理方式。
MEAP解决方案一般分为两个部分，一个是移动中间件服务器，另外一个是移动终端程序。
中间件服务器，处理包括所有的系统集成，如安全，通讯，扩展性，跨平台支持等等的解决方案组件。其实中间件并不保存数据，仅仅是将后台的数据，通过它处理后，送达到移动终端，并取得反馈数据。大部分的MEAP还会提供一套移动设备的配置管理/开发管理的工具集，从而帮助企业实施和校正其移动系统。
移动终端应用是通过连接中间件服务器，同时处理用户界面以及业务逻辑的终端应用。这些终端应用，通常应该能和安装他们的移动平台无缝连接，所以一般是“胖应用”（即脱离服务器也能部分使用）或者是本地App，或者是基于浏览器的扩展技术如HTML5等的Web应用。无论是胖应用还是瘦应用，都是基于应用本身的复杂性，平台支持，所需的用户体验，以及是否需要在无网络的情形下的工作能力要求。
下面是Antenna Mobility Platform: AMPchromaTM
和一位同事讨论如何改掉粗心大意的毛病。虽然增加自己检查是解决所有问题的灵丹妙药。但并不能根本解决问题。
他喜欢Copy别人的程序，他认为这是最高效的，
他喜欢从文档里面直接Copy内容，他认为这是最正确的，
他喜欢立马去开发客户需要的功能，他认为这是最快的。
但为什么自己总是发现不了的问题，到了别人那里却能轻易发现。
其实这些貌似正常的推理才是问题的根源。
如果他知道程序其实也有美丑之分，那就知道如何去让Coding成为艺术的创作。
如果他知道软件也是有生命和价值的，他就会敬畏软件的功能，就会用心去尝试用户的感受，就不会容忍那些小瑕疵。
所以我想，一个优秀的程序员，应该对程序有审美之心，对软件有敬畏之意