写在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 最后一天,暂时就写这么多了 :) 希望你们喜欢我码的字~~

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构

毕业3年同样是java程序员,为何技术能力相差越来越大?

导读:毕业三年,每个人在技术能力跑道上,有了或大或小的差距。有些人永远在重复的劳动,有些人却能从中总结和解决问题。今天我们来探讨下,如何避免让战术上的勤奋掩盖战...

12550
来自专栏Java架构

离职总结:大公司与小公司的个人体验

26250
来自专栏CSDN技术头条

如何在3年内摆脱“普通程序员”标签

很多开发人员日常工作中接到需求直接动手开发,在开发过程中一边开发一边设计,特别是刚入职的程序员,大多数更是只注重功能的实现,接到需求后往往只是在脑中勾画一个大概...

9330
来自专栏钱塘大数据

【推荐收藏】这些数据获取网站,帮你工作提质增效!

在这个用数据说话的时代,能够打动人的往往是用数据说话的理性分析,无论是对于混迹职场的小年轻,还是需要数据进行分析和研究的同学,能够找到合适的数据源都是非常重要的...

56790
来自专栏技术小黑屋

程序员怎样才能写出一篇好的技术文章

首先,这算是一篇回答知乎问题 程序员怎样才能写出一篇好的博客或者技术文章?的文章。

30620
来自专栏SDNLAB

ONAP发布Beijing版本,为网络自动化和编排提供最佳平台

开放网络自动化平台(ONAP)项目致力于为端到端闭环网络自动化提供统一平台,今天发布了第二个版本“Beijing”。Beijing版本降低了网络运营商部署ONA...

19420
来自专栏PPV课数据科学社区

大数据从小做起—中小企业的Big Data之道

任何一个时代或者模式的兴起,都离不开与之相关的Killer App,比如,C/S时代的SAP ERP,互联网 1.0 时代的门户,以及互联网 2.0时代的搜索和...

34850
来自专栏大数据文摘

谷歌利用大数据提高通用翻译

217110
来自专栏陈树义

6、市场需求文档(MRD)撰写方法与技巧

1、MRD与BRD文档的不同 -BRD 这么做有什么好处,并说明好处在哪里 -MRD 通过BRD明确了这个事情值得一做后,描述应该怎么做,并说明这么做的原因 2...

50570
来自专栏理论坞

用户体验案例:从头到尾的设计经验

作为设计师,我们常常抱怨产品不尽人意。我之前也常常会这样想,直到前一段时间有幸参与到某个金融项目中,才对彼此的工作有所的了解。当中的很多理念都是未来设计师所必须...

12430

扫码关注云+社区

领取腾讯云代金券