初探敏捷

2018-07-11 10:05:00
不可描述的声音
转贴:
简书
157

背景

基于公司自有线下产品开发线上互联网应用

团队成员

领导若干,策划3名,开发1名(全栈)

自己做还是别人做

一开始这个项目是打算外包形式,找过不少合作单位谈过效果都不理想,其根本原因还是在于我司所属行业并没有什么成熟案例可以参考,更谈不上有什么现成的模板可以复用,在行业没有成熟案例和产品参考的前提下,意味着项目未来会面临两个问题,一个是需求频繁的调整,一个是试错。同时合作单位需要投入较大的成本去了解我们这个行业然后开发相应的产品,在没有深度合作或战略合作的驱动下,多数单位并不能做出让我们满意的产品,持续的创作输出和沟通成本都是潜在的隐患,即便我们愿意为此付出一定的金钱。就在一筹莫展之际,腾讯推出了小程序这个东西,让我们看到了一丝曙光,我觉得我们可以自己做了。

自己怎么做

在内部沟通得到领导及业务部门的支持后,确立了前端小程序,后端PHP的技术方案。

为什么决定自己做?从前面的团队成员信息可以看出,开发只有一名,后端PHP是现有的技术资源,前端技术一直是当时的技术短板,而小程序的出现完美解决了前端技术短板的问题(各种封装好的API,大大降低了开发成本和学习成本),基于微信生态的应用从业务层面也解决了很多问题,如此一来,加上后端PHP开发而成的REST接口就可以直接构建成前后端分离的应用,为后续的维护、扩展打下了基础,前期技术层面的顾虑打消。

小程序和PHP的组合至今我都认为是一个最佳实践,PHP本广泛应用于web开发,特别是在引入面向对象设计后,迭代和维护变得更加简单,各种功能都能在这门轻量级语言快速实现或找到解决方案,性能还很高。

在解决了技术选型和架构设计的问题后,我开始思考怎么去推进这个项目,小程序加PHP的组合无疑大大提升了开发效率,但这只是技术层面;开发只有一个人,要应对市场瞬息万变,需求变更,还有测试、修复等等,所以,按照传统的开发方式显然没办法接受,光是起步阶段就得花去大量时间,必须换种方式。

小步快走,快速迭代

技术上,无论前端还是后端代码,全部采用模块化设计,包括产品功能,尽可能全部解耦,按优先级给功能划分了等级然后逐个开发,一个功能开发完毕就立马提测并进入下一个功能开发,然后有bug修bug,无bug上线公测并继续开发另外的功能;管理上,要求相关人员要积极配合测试和素材提供、需求提交、需求确认等(这时候就要领导带头啦)。

开会这事怎么说

开会的作用不言而喻,但是为了开会而开会那不是做产品应该做的事,所以我们每个月只有一次总结会,总结会的作用是沟通一些更高层面的问题还有让领导了解项目情况,具体的产品问题并不会提上会议议程。那我们开发怎么和策划做头脑风暴的呢?一律是在沙发上解决,区别只是走廊还是办公室,或者就这么站着,有限的时间和资源让我们更注重沟通的效率。

后知后觉

项目风风火火跑了一年有余,除了一些不可抗力的原因,总体项目保持了高速的运转,一些功能反复迭代了很多次,有些则直接砍掉,期间还经历了一次前后端的全面重构,让整个项目变得更加灵活。现在项目变得越来越复杂了,因此也不得不抽空学习各类知识以应对项目的发展,其中感悟最深的无疑是 敏捷软件开发,当我看到这套管理方法的时候特别有感触,因为这套方法我居然无意中就实践了。我个人的性格是喜欢“轻”,不必要的文档和冗长的会议对项目推进并没有太大的成效,这些都和敏捷所倡导的精神不谋而合,这套方法在我的项目上能有不错的实践效果我觉得有以下几点原因:

  • 团队小,成员都对业务非常熟悉,前期积累过不少想法,团队沟通成本低,容易达成共识
  • 团队目标一致,由于将原有一整套的功能都解耦分步迭代,阶段目标和交付物互相认可理解
  • 技术选型
  • 管理层支持

这里要说的是,敏捷管理只是在小团队中更容易实践起来,大型团队项目一样可以,只是还需要其他机制的引入,这里因为我没经历过大型团队敏捷项目就不赘述了,有兴趣的可以阅读《网易一千零一夜:互联网项目管理实战》,这本书分享了很多实战心得,结合项目去阅读体验更佳。


文章分类
联系我们
联系人: 郑女士
Email: zhengqiaoyin@cnezsoft.com
QQ: 2987868987