• Innovation Never Sleep

    2012-02-28

    分类:咨询之道

            估值千亿的facebook快要上市了,互联网也将要迎来一个新的高潮!离当年的Microsoft和Google的风光并不遥远。都不禁在问:下个风景在哪?

     

     
            人想要一批更快的马时,有了汽车;
            人想要去玩一把大型机时,出现了PC;
            人感觉电脑职能搞搞文档时,它就能联网了;
            人迷惑上网能干啥的时,你可以购物,看电影,晒8卦;
            人还想我的手机除了能打电话以外能多干点啥时,电脑也已经能打电话了;
            ...
            走一步迈出的并不大,一回头已万水千山!
     
            我们能预测未来五年的趋势吗?不能!但是,我们能预测未来五年什么不是趋势!
     
            1)创新来源于跨领域综合;
            并不是说将来没有更新的技术诞生,相反我个人觉得反而会越来越多!但是像电的使用、无线电通讯、光纤传导并不是你的机会,核能也目前只能给北朝和伊朗用来爆爆料,发明水变油的人必然还没出生,所以还是各上各班,各回各家。
            看过一个据说时 Apple 预测未来人类家庭信息化的生活的广告片,相信很多人也都看过,视频里的家庭就是一个平板电脑的世界,电冰箱、厨具、桌子、梳妆台、镜子都是你的ipad;做家具的兄弟们准备好了吗?以后苹果也可以坐的哦!
            每一次这样一次革新,都有机会造就一个新的行业,造就出一个伟大的公司!
     
            2)后来者都是都是在新的领域超越先驱者;
            第一次看到这句话,应该是老周说的吧,大概意思差不多。后来者想要和吃盐都比他吃饭都多的老大一绝高低的话难度还是挺大的,特别是高科技行业,先到的占据了资金、人才、技术、市场、用户,所以就像武侠里那样,徒弟总是很难战胜师傅,高手都得要跨门派的绝技!
            
            3)任何企业,任何团队都不能失去创业精神;
            否则,结果就是被淘汰!那有什么又是创业精神?企业对于变化的态度已经从过去的恐惧变成了无可奈何的接受,但是未来对你要求是成为变化的领导者,直接对团队外部的绩效负责,直接的面对市场。
     
            4)更多的人享有原本属于少数人的服务;
            更多的时候不再是过把瘾,而是像滑雪、登山都已经成为你我生活的一部分。
     
            青山依旧在,几度夕阳红?
  • Code Jam 中的 BA

    2012-02-14

    分类:敏捷项目

      Code Jam -代码果酱,我的理解是大家聚在一起像做果酱一样用代码完成一个真正可用的产品。开发的时间只有两天,产品还要保证高质量,无疑对参加 Code Jam 的每一个人都是个人能力极限的挑战!

      作为BA,如何在 Code Jam 和团队一起发挥最大的效率,完成这个似乎不可能完成的任务呢?我通过R2 项目看板 Code Jam”担任BA的体会,认为主要有以下三个方面:


      更充分的准备


      1. 项目启动前和客户一起确定项目的功能点和目标。根据功能点,BA就能写出用户需求故事卡,明确产品整体功能的范围,尽量做到滴水不漏;明确了目标,就能对客户心中的优先级做到心里有数。

      (用户故事卡左上角为故事编号,中间为故事优先级,正文为故事内容,贴有负责人照片)

      2. 帮助 UI 设计产品页面模型。BA提前完成界面模型的制作,画出界面的 Mockup ,交由 UI 实现,BA负责 Review ,确定最终版本。这样即能保证系统界面风格的一致性,又能让开发在写代码过程中更关注业务流程。

      3. 向开发和测试介绍用户故事并共同排定优先级。在编写完用户需求故事之后,需要保证开发和测试对它的理解是相同的,那么就需要BA简洁的给出描述,这样大家通过讨论,能够对用户故事的范围达成一致,根据业务加值和技术风险共同排定故事的优先级。 本次 Code Jam 产生 40 张故事卡片,优先级高 30 张,优先级中 3 张,低优先级故事卡 7 张。  

      BA作为项目贯穿始终的参与者,保质保量的完成这些 " 家庭作业 " 是必须的!


      更高效的沟通


      代码的开发与集成,功能的验收与测试,项目的部署与发布 都要在两天完成。所以让开发、测试、 UICI 、BA、项目经理都坐到了一个会议室里,如何利用这样有利条件更高效的沟通,BA必须更加积极!


      1. 和测试一起做功能的验收。在开发完成一个功能之后,马上举手示意,BA和测试将一起做功能验收,检查所开发功能业务流程的正确性。BA会把发现的问题逐个写在贴纸上,交给开发去修复;开发修复完成之后,BA和测试将会参考贴纸的内容再次进行功能验收。

    (反馈卡右上角写有对应的用户故事编号,一次列出需要修复的功能点)

     

     

      2. 为测试排定 Bug 的优先级。在测试发现一个功能的 Bug 后,马上举手示意,BA将和测试一起重新复现确认,并且将现象和复现方式记录在贴纸上。BA负责搜集 Bug ,并且根据业务价值排定优先级。对于高优先级的 Bug (使得系统核心功能出错)将贴纸交给相关开发即刻修复。

    Bug卡首先描述 Bug 场景,然后是出现问题,最后是优先级)   

     


      3. 和团队做 Showcase 搜集反馈。在主要开内容发完成之后,将团队所有人员聚集在一起,BA负责演示完成的所有功能点,大家一方面看到自己的劳动成果,另一方面团队成员可以戴上 " 客户 " 的帽子对完成的功能进行回顾、讨论、达成改进方案。BA需要记录并且与 Bug 一起排定优先级,进行解决。


      更可控的流程


      1. 项目进度的透明化。每个用户故事的状态都分成“待开发”,“开发中”,“待测试”,“测试中”,“已完成”五个状态;在墙上划出相对应五列,对应五种状态,这样用户故事卡就在开发过程中在不同状态间移动;并且在卡片上贴上负责人的照片;这样一来整个项目和团队的状态通过故事墙就一目了然。

      2. 及时发现风险调整计划。BA督促在开发和测试在工作完成之后更新故事墙上卡片的状态,并且定期统计,绘制项目燃尽图,与预先的计划做出比较,汇报项目经理,以便及时发现问题,做出响应调整以保证项目交付。

         

    (上图分别为本次 Code Jam 的故事墙和燃尽图)

      最后,虽然整个 Code Jam 过程是压力山大,但是还是灰常开心的;有欢乐多多的自我介绍,美味的巧克力冰激凌,一天两次的水果以及最重要的自我挑战的激情!

  • 自然简单

    2011-09-02

    分类:敏捷项目

    人是喜欢简单的动物;

    所以,人喜欢的软件;

     

     

    于是,就要简单的设计;

    那么,什么才是简单,什么才是简单设计(不是简单的去设计);

    1. 简单是针对使用者而言的;

    一间装修精美的房间对你来说是简单的,你只需要入住;一块红砖对于一位建筑工人是简单的,他只需要把它垒放在另一块的上面;然而,那块转头当你需要派人的时候(不论线上线下)也是简单的,只要拽出去就行,你还能拽第二块、第三块...

    所以 Google 的主页是简单的,一个关键只需要一个回车就能开始它的匹配;但是 它的实现 对于开发工程师来说又是复杂的;

    2. 简单的本质:

    1)Reliable, Predictable

    用水杯喝水,知道可以解渴,因为简单;尽管有气象台,想要预报天气,还是很困难,因为复杂;

    2)Cheap

    拿到一部 iphone,不要阅读长篇大部头的说明书,就能点触开始;一台电脑,插上网线,就能接入网络;学习成本,接入成本,使用成本;

    3)Value

    低成本并不代表没有价值,反而相对而言有更加专一的价值;

    4)Building Blocks

    砖石砌成楼房、细胞形成躯体、硅晶二极管组成集成电路、电脑连成网络;

     

    再看,如何做出简单设计?

    对于产品的管理者:如何让使用者一目了然?什么才是用户最想要的功能?

    对于类库的实现者:如何提供简单的接口调用?如何让设计让更多人容易理解?

    对于代码的开发者:如何写出简单的代码?

     

    说到这里,那些大牛们提出的 代码 简单设计的原则 就不再 突兀;

    1)需要有针对的测试,保证功能的可靠性;

    2)代码尽可能的短小,学习、调用的成本降低;

    3)单一的职责原则,让函数/模块提供单一的功能;

    4)简单代码之间的紧密配合才能有简单的系统;

    是不是很顺其自然;

     

    最后 TDD 测试驱动开发 是一种方便的实现简单设计的方法,但决不是惟一的;任何的工具或者方法都有他使用环境,使用者的上下文,当明辨之、慎思之!

     

    自然的就是简单的!