写在2015 项目回看 -- 敏捷在思想不在形式

面试的时候了解到的情况：

• 软件组主管刚刚离职，需要一个人接手
• 公司有一个成熟的框架，国外开发的，很多功能可以复用
• 公司的程序员都在公司干了2~3年左右

团队项目实际情况：

• 所谓的框架，实际上就是国外已经上线的一个系统。业务逻辑和功能模块是面向对象方式写的，但具有相当高的耦合性（编码不够抽象，业务和功能有时混在一起，功能写的时候是针对特定的业务）。
• 程序员，一个基本只会数据库，面向对象基本不了解，而且思想固执，很难沟通，我们暂叫他（H）吧 -- means Hard。
  一个90后，工作经验毕竟不足，但是学习和接受新知识的能力很强，我们暂叫他（N）-- means New。
• 系统大部分功能都是（H）在写，（H）闲（N）资历浅基本不让他参与编码，怕他把代码弄坏了，所以（N）在我来之前都在打酱油
• 我加入时问（H）系统是个什么状况了，他说需要的功能都好了，可以Beta测试了。
  我开始窃喜这下轻松了，结果随便点了几下问题一堆，我也就知道情况了：）基本不能用
• 需求，开发，设计文档基本为零
• 该项目需求来自于国外，出于语言，经验，国人内敛的性格问题和国外沟通也非常非常少

　　

　　看起来问题还真不少，但是来了就不能逃避，总归还是得解决问题啊。

　　现在回想起来幸好本人有敏捷思想和迭代开发护身符：）现在项目还算成功，经常被老外点赞，也已公开展出，明年开卖。下面看看怎么解决的吧。

 

扭转局面，步步为营：

　　恶补行业知识：

　　本人在加入该公司前对该公司的业务和行业知识了解基本为零，导致在交流功能和问题的时候很吃力，不知道很多术语是什么意思。

　　这个不知道肯定是不行的，然后到处寻找领域知识的文档，听到陌生的术语然后到实物上去对应，甚至还读了一本很厚的行业（英文）书籍

　　给交流沟通打下了良好的基础。

 

　　加强跟产品经理（PO）沟通, 了解客户需求和满意度：

　　首先和PO了解一下他对于现在项目的看法（不是很满意，项目进度很慢，软件基本不工作），以及对于产品的未来期望（期望很高，市场很大）。

　　了解了下中国这边情况：中国这边不大愿意和PO沟通，因为认为PO没有把系统明确，没有把需求文档写清楚。

　　双方僵持不下，项目进度只能推迟。还好我有敏捷思想：）

　　我首先仔细阅读了一下写得很肤浅的需求文档，大概了解了下整个系统的需求，然后将这些肤浅的需求输入到了TFS中，做成了Feature和Product Backlog.

　　对于不明确的地方专门找PO开了几次会议，他说我写（一般PO不愿意自己写，愿意说想法）初步把Product Backlog的描述填上了，格式当然是 As a <type of user>, I want <some goal> so that <some reason>

　　描述好了当然就是排优先级咯~~ 有开了一次会议把优先级给排好了。

　　有了比较好的Product Backlog，项目就可以脱胎换骨的重新开始运行了。和PO约定好了是两个星期为一个Sprint的迭代，第一个Sprint我们（可以不用Promise那么多，但是一定要可以交付），结果是我们成功的交付了：）PO也很开心

　　这样给后面两年的持续交付，打下了良好的基础。

　　这里要记住敏捷的另一个超级 超级 超级重要的点，每个sprint要有可运行的软件和潜在可交付的产品。

　　每次交互我都让团队成员演示自己开发的部分，让他们有成就感。每次review都会记录会议的Comments，结束之后我会发给PO和团队所有的人。我还鼓励团队成员积极和PO用邮件和面对面交流，开始他们都比较shy，我就带着他们

　　和PO视频会议，我作为协调者，慢慢的他们可以有信心了，自己也很积极的和PO沟通了，非常好的变化。

 

　　降低耦合功能分块，充分调动能用的资源：

　　首先我发了几天时间看了下系统功能和代码，不懂的就问问（H）和（N），问问现在系统是什么样个状况，是不是有些不合理的地方。

　　然后召开了一个会议大致了解了一下，系统架构。很快我就发现其实系统是分为客户端，服务器端的，他们之间是通过数据库作为交互，当时我就反复确认了这个架构。

　　架构确认了之后，窃喜：）当场做决定，客户端以后油（N）复杂，服务端和数据库由（H）负责。（H）发现没有人动到他数据库，他也是放心了。

　　就这样（N）的资源被有效的调动起来了，而且UI上WPF大家都是新手，他上手也很快，最后做出来的UI非常漂亮，PO也很是满意。

　　看来当初这个决定做对了：）

 

　　功能点各个击破，迭代开发，持续交付：

　　还记得我刚进公司的时候（H）说系统功能都好了可以beta测试了对吧。其实（H）就是拿着国外的老系统，照着很肤浅的需求文档，东改一点，西改一点，然后以为就好了：）

　　事实证明根本没有一个功能是能用的~~ 当然他是不会承认的，写软件的都不会承认自己做得不对，做得不好。我只能绕着弯说，PO对于系统有了新的需求，我都记录在TFS上了。

　　那我们这个重新找个机会把所有的功能都理一遍吧，理一遍他当然答应了。

　　这样我就按着TFS上Product Backlog的优先级开始“理”系统功能了，在最开始的两个星期迭代中（H）对于这种各个击破的思路很是不能接受，在开发A功能还老是想着B功能，总是说你这样只考虑A不考虑B是不行的，

　　系统以后会有问题的。

　　我只能不愿其烦的解释，不能东打一枪，西打一枪，一定要Focus， Focus， Focus，记住了敏捷中经常提到的专注力就是这个意思。

　　一个有着所有功能但不能工作的系统是没有用的，还不如一个系统只有几个功能，但是这些功能都好用~~ 说了几次之后（H）总算是答应了~~

　　在集中开发某一两个功能的两个星期后，系统总算有部分功能可以无大问题的工作了，PO也很开心，提出了一些改进建议，我们再改善，再迭代~~ 如此反复也就成了现在的模式。

 

　　引入冲突，发现系统薄弱点：

 　  国人很害羞，有想法不敢说藏心里。国人以和为贵，即便有不同的意见也不说，藏心里。国人公事私事揉成一团，公事吵架了怕伤了和气影响同事之间私下的感情，有想法不敢说藏心里。

　　但是在多年丹麦文化和敏捷思想熏陶下的我，毅然决定了引入冲突，我坚信真理只有在冲突和讨论中才能浮现。

　　当然敏捷给了我们一个很好的工具，Daily Standup Meeting（每日站立会议）。再完成了 每日会议仪式性的3个问题之后，就进入了我们的Fighting时候。

　　我总是会抛出一些系统不太好的地方，让大家出谋划策，讨论讨论。当然有时候会听到如 “你们是真的需要吵吗？”，“你们想怎么样就怎么样吧，我不说了”。这时候我就要出来安抚了 ：）

　　有个现象告诉大家，人在吵架的时候都会丧失理智，所以你说什么即便是对的，有人也会据理力驳，即便是歪理~~

　　但是好的结果是，过几天当大家冷静下来思考时，真理就慢慢浮现出来的。

　　刚开始大半年我们基本是9:30开会，吵到11:30 吃饭，定时开吵。也成了公司的一到靓丽的风景线~~ 当架构慢慢稳定了，我们的争吵现在也少了，其他部门都不适应了。总觉得少了点什么：）

　　大半年每天开吵，当时（H）多次提出，天天这样吵半天我们还要不要做事？我每次的回答都是：与其天天做正确的事（低头写代码），不如把事情做正确了（正确设计架构，发现解决潜在风险和问题）。

　　事实证明开发进度并没减慢，PO也很满意我们的产出，PO也希望拿到的是稳定的系统。

 

　　改变思想，引导重构：

　　很多人没有经过系统的培训或大公司熏陶的人，代码功能能完成，但是代码风格是五花八门，像个垃圾堆，我称之为“野路子”。

　　开始我定义了一些Coding Standards， 但是大部分人是文档看看就扔，还是我行我素。 这个要改变真的很难，特别是在项目压力下，花时间把“野路子”变成“正规军”。

　　我也只能一点点的促使改变，比方代码对齐，负责代码注释，大功能切分，减少Copy & Paste，还有命名注意规范，这些都是最基础的。　

　　刚进来的时候还想有时间要使代码面向接口，测试驱动开发。不过现在还没实现，在团队面向对象都不怎么了解的情况下这个暂时很难实施，所以有些东西还是要面对现实的。

　　现在能做的是在项目比较空闲期的时候，督促他们删掉无用代码，整合功能，提取可复用代码进行封装。

　　时不时发一下best practice，或者挑战下他们明显的代码问题。

　　重构之路还很长，压力还是很大~~　重构，重构，重构很重要！XP里面也有提到吧~~

　　对了，还有很多人比方（N）一上来就想重构架构，说现在架构这里有问题，那里有问题，重构一下几天就能搞定。

　　我只是想说，越是年轻的程序员越是乐观。重构架构听起来很美，实施起来不容易，特别是在项目进度压力之下，慎重考虑。

　　我是准备第二版有时间的时候再重构架构了，而且架构这个说实话这个词真的说出来简单，动起来超级复杂（除非你第一版设计就留足了灵活性，要知道这个项目我是半路杀入还是带了一帮OO思想不熟悉的人）。

　　如果你真的理解了架构这个词的话，类比的感觉应该是相当于把房子推了重建~~

 　　

　　其他：

　　和许多其它团队一样，我也经历了原来的软件主管回归和团队成员的离职。

　　现在情况是原来的软件主管归到了我的旗下，我们合作得还很不错。

　　由于项目比较紧，离职的团队成员我们采取了类似外部的性质，做到项目结束。

　　我给他定功能交付时间，他定期来公司了解需求和讨论。

 

新的挑战：

 

　　日本作为第三方加入，提出系统改进需求：

 　  日本人来了！！！

　　日本人作为大股东开始插手项目了，时不时的找我提出一些系统需求，怎么办？

　　敏捷思想再次用到，单一PO！！！

　　我总是会把他们的需求记下来（表示友好，重视），然后告诉他们这个需求你需要和我们原来的PO商量是否加入，以及由PO来排优先级，找我没用。

　　我只能了解你的需求，要不要做我不做决定！

　　在默认了游戏规则之后，现在需求提出还是比较顺畅，我还是和原来PO沟通下一sprint的交付物是什么。当然也会提醒PO说日本人有一些新的东西是否考虑是否加入backlog。

　

整个项目做下来，发现敏捷思想真的可以解决很多难题，一切都是那么的顺畅和自然。

希望大家改变瀑布思想，拥抱敏捷，拥抱变化，迭代开发，每个迭代都有可交付产品。

PO希望玩真正的东西，而不是一堆设计文档和不能交付的借口。

 

好吧说两句对日本人的看法：

• 做事是比较认真
• 没有中国人聪明
• 他们有民族自豪感，有看不起国人倾向
• 喜欢装，喜欢用讽刺
• 喜欢找你麻烦而不是合作的态度
• 喜欢揪你小辫子，背后打小报告

哈哈哈哈~~ 2015 最后一天，暂时就写这么多了 ：）　希望你们喜欢我码的字~~