2013-09-11

1.1 敏捷联盟

敏捷这个词被滥用了很久,部分人认为站会、自动部署、没计划、没文档就是敏捷了。其实这都是片面且偏激的看法。从敏捷宣言的解读就可以看出,在强调个体能力和沟通的同时,它也不忽视工具。而在强调代码的同时,也不忽视文档,只是不要求“面面俱到”的文档,而是维护系统原理和架构文档,细节留给代码。而响应变化胜过遵循计划方面,我理解,在互联网行业里,从RD的角度来看,由于来自PM或用户的需求是多变的,所以无法生造出一个长远(横跨几个月)且不变的计划;但从PM或项目经理的角度,得有谱,得规划出产品的长远意义和走向,否则项目将失去灵魂。

1.2  原则

对于我们来说,与其规划一个耗时数月的产品,不如拆分为小功能,花上一两周作出第一版(需要有核心的产品价值和可快速迭代的架构),快速上线(不要局限于一个入口,尤其是需要有我们完全可控的入口),然后收集用户反馈、分析用户行为,持续升级和推广。这里不局限于一个入口,是有感于之前创业阶段,把宝都压在淘宝APP上,完全受制于对方的政策。可快速迭代的架构,我理解必须是内聚和解耦且拥有全面自动化回归case的,这样才可以放心的对某一些子功能动手术。所以,这里强调的是迭代规划、架构、人、数据监控与分析、推广

敏捷中人的作用尤其重要!对程序员的要求有:

  • 视软件如己出,为自己做事,且相信产品会为用户、世界带来极大的价值(后者可能对于我这样的人比较有意义)。只有这样,才有持续的动力 提高自己的技能、避免坏味并写出高质量的代码、主动发现有问题的点并修复它、自驱动领取力所能及的task等等。
  • 言出必行,由于强调的是面对面的交谈,文档、邮件仅作为备忘录记录大事件,所以对于细节更多是通过人的自律来保证的(在敏捷初始,可能还是需要通过细致的TODO list来保证吧?在涉及团队间交互时,接口文档还是必不可少的。)其实,个人觉得,这是不分行业的,是基本的要求,就是按时按质完成工作。

进度的评估,以可用功能完成进度为准,不包含调研、设计、文档、基础lib库的进展。因为后者都太虚无,PM或用户看不到真正的效果,也无法准确的验收进度。这也从另一方面,强迫敏捷开发团队将需求拆分为可独立上线的子功能,否则进度一直都是0%!

最后,每隔一段时间,敏捷团队需要坐下来回顾实施过程中的经验和困难,并作出调整。这一方面是积累,另一方面也可以看出敏捷的原则不是定死的,而是可以根据团队的情况,灵活应用。

 

2013-9-12

2.1.3 短交付周期

极限编程里有“发布计划”、“迭代计划”两个概念。前者是多个完整的story,进行一次发布或上线,持续3个月。后者虽然也由一个或多个story组成,但仅完成开发、测试并持续集成至版本仓库,不发布,持续2周。这种发布的频率可能是产生自传统软件行业,以通信行业为例,一个完整的系统交付可能持续数年甚至更长,每3个月做一个版本升级已经很快。但个人感觉虽然频率并不适合互联网,但思想仍可以借鉴。

3个月的发布计划,会迫使需求提出者作出较为长远的规划,避免需求无目的的堆积。而将多个有组织的需求,再拆分为较小的开发周期,并在此周期内保持需求的稳定,可以使开发者不至于因为需求的频繁变动而乱了节奏。但只要需求未被纳入开发迭代,提出者就可以对需求进行调整,也保持了快速应变的能力。

应用到互联网行业,我们是否仍然是做3个月的规划,2个周的迭代。改变的是迭代结束就上线,将效果交给最终的用户去评判,并加入监控和分析,对于影响较大的紧急反馈在RB分支里在几天内立刻修复并上线,而其他反馈并入随后的迭代里。

2.1.12 简单的设计、2.1.13 重构

简单的设计、不提前设计,这个在现实中如何平衡?而这两点,其实也是基于“重构”来的。简单的设计,在面对新需求,需要变更代码、lib库甚至架构时,如何处之?答案是有全面自动化case保证的重构和高质量的工程师!但现实中,100%全面的case是不存在的,人的方面更是变化多端。所以,个人觉得,需要折中。

  • 欢迎重构,但尽量把重构放在本迭代中,不把坏味代码留到发布版本里,减少后面为了消除代码坏味而进行的重构。
  • 通过数据推测性能需求,通过对需求提出者的诘问推测功能需求,为可预测的将来做准备。
  • 在需要对已有功能做重构时,化整为零,每重构完一个小功能就build,确保无误;并且尽量采取小流量的方式先试点再推广。

2.1.14 隐喻

TODO

Leave a Reply