软件工程:难点及应对:需求(模糊&多变&无逻辑)/ 工期 / 团队 / 工具 / 环境

更多
2019年04月17日 12点01分 作者:叶飞 修改

问:刚入行的程序员,如何才能装得像个老鸟的样子

答:很难!但如果你能在接到需求之后先琢磨点时间,再提出一两个问题,人家一定会高看你两眼……

对一个项目而言,新人通常会以为最难的“实现功能”,但实际上最让人头痛的,通常是“需求”!

为什么会:返工返工再返工,加班加班再加班?


模糊/歧义

飞哥是做过律师的……深知:精确的表达,是一种能力!而大多数人并不具备,(坏笑.jpg

请同学描述:源栈的红包政策

  • 一句话描述:违反纪律就要扣红包,用作聚餐 (类似于“做一个类似淘宝的网站”,这种人是程序员最痛恨的……)
  • 详细描述:迟到扣1个,玩游戏扣3个……聚餐的花费先从用红包冲抵……
  • 最精确描述:
    • 预缴/补缴
    • 迟到/玩游戏的判定
    • 聚餐费用的抵扣/分摊算法
    • ……
其他同学思考:需求描述是否准确、足够清晰和没有遗漏。

书面文档

代码要不要注释,可以两说……

但没有文档是绝对不行的:

  • 帮助自己理清思路:类似备课/写博客/小黄鸭调试法
  • 向其他人清晰传递自己的想法
  • 长期保存以备查验(固化需求)

谁来写需求文档?

  • 发包方:人家是大爷,想写就写,不想写你也没辙
  • 产品经理:除了要构思产品(软),更要能够将你的想法准确的呈现出来。而且,个人认为,产品经理还应该为产品的集成测试负责。
  • 项目经理:大家都恨写文档,脏活累活!但能写文档是一种资格……

需求文档怎么写?

最常见的“作坊式”写法:一张UI图片,加点描述说明……

深刻的理解语言的局限性:

  • 自然语言:我借了飞哥100块钱,究竟谁是借方谁是买方?
  • 描述性语言:用户名不能重复,怎么才算重复(大小写)?重复了又咋办?什么时候检查重复?

PS:判例法 vs 成文法

说实话,从业十多年来,我没看到过优秀的需求文档;但哪怕是稍稍过得去的测试文档,也让我耳目一新!

测试文档的写法:(示例:注册)

  1. 步骤:重置数据库
  2. 步骤:进入注册页面
    1. 输入用户名:fg
    2. 步骤:移出焦点
    3. 结果:显示 *用户名已使用
        --------
    1. 修改用户名:fg666
    2. 步骤:移出焦点
    3. 结果:*用户名已使用 错误提示消失    
        --------
    1.  修改用户名:FG
    2.  步骤:移出焦点
    3.  结果:显示 *用户名已使用
        --------
    1.  修改用户名:Fg
    2.  步骤:移出焦点
    3.  结果:显示 *用户名已使用

能不能把需求和测试两份文档合二为一呢?本质就是把描述和举例(但要求穷举)结合起来!

问!问!问!

重要的事情说三遍,不是:猜!猜!猜!

business logic is illogical,你猜不出来的。

我碰到过最奇葩的一件事:直接改我的文案,因为他觉得……

沟通非常重要。事前不沟通,事后板子要打到你身上的,

更高的要求:你是专业(professional)人士,客户没想到的,你要能想到。

我们的作业,有意识的埋了一些坑(模糊需求),目的就是锻炼大家“挑毛病”的意识,但是如果发现了模糊需求,不用来问我,每种可能性都实现一遍!^_^


需求变更

再次强调:不是需求模糊!

  • 放平心态:这是正常的,
  • 端正态度:没什么好抱怨的
  • 拥抱变化:体现你实力的时候到了!好的架构好的代码,就要能够应对变化……

本质上,为什么需求变更老是被抱怨?因为之前改的那些都不算你的工作量(就和加班不给加班费一样……)

场景:为什么项目延期?

程序员:需求老是改…… 产品经理:哪有?我就改了那么一点点……

契约式开发

需求发布/开发/验收三方像签订了合同一样,按约定履行各自的职责,并承担“违约”的责任。

飞哥的应对:自由飞·任务管理系统,使用工具,让一切有据可查。

责任的流转:

  • 发布 -> 承接:没看明白的需求你不要接,接了之后需求有歧义,责任算承接方的
  • 开发 -> 验收:功能完成之后仔细验收,验收之后再说哪里不对劲,责任验收方自己担着
要改?加钱。


业务逻辑无逻辑

作为开发人员,还是只有放平心态。

然后,加强沟通!很多技术上的难点,可以通过业务流程调整平滑实现。

  • 进度条:其实不能标明时间进度
  • 12306:催生抢票软件。解决方案:实名制+预定
  • 秒杀抢购:绕过常规订单系统,队列+计数+随机抽取

PS:因要求APP背景色根据手机壳颜色变化,产品经理被程序员暴打,^_^


团队

人是万物之灵,其实最难管理。

而编程开发(包括产品/测试)的工作,因为其高度的创造性,极难量化,更增加了管理的难度。

#题外话#很多时候项目的真实情况是:

上班摸鱼,加班干活;

忙的忙死,闲的闲死!

不管不行,但管呢,
  • 外行领导内行闹笑话:KPI一周提交多少行代码
  • 各个部门(产品/开发/测试/发布)互相指责,鸡飞狗跳

新人有鸡血但没能力,老人有能力没激情……

还有人员流动的问题:一个项目核心团队交接个几次基本上就散架了!


项目进度

总是能按时交付,是够一个项目团队吹一辈子的牛逼!

大多数项目上线,总是延期延期再延期,最后要么就崩了根本上不了线,要么就东拼西凑的硬着头皮先上线再说。

如果是外包项目,验收会上演示直接崩盘的事不要太多……

为什么?除了需求不明随时变更,团队水平参差不齐,还有一个很重要的原因:

软件开发是一个创造性工作,这项目很多东西都是以前从来没做过的。你不要以为增删改查写业务逻辑没啥技术含量,说不定哪里就整个幺蛾子出来,直接卡死你。

所以“江湖越老,胆子越小”,越是老人越倾向于老技术,只有新人才初生牛犊不怕虎,各种新技术可劲儿的往上堆!项目初期雄心勃勃,项目结束一地鸡毛……


任务细分

只是经验之谈:把任务(功能/实现)尽可能的切细。

前提:老大懂技术,最好是大牛

好处:

  • 在切分任务的过程中,加深对项目的理解。很多你之前没想到的东西,都会冒出来,所以你预估的工期就会更准确(保守)
  • 越细的任务,越好定工时:做一个一起帮要多少人天,这个真不知道;但做一个检查用户名是否重复的功能要多少人天?撑死0.5个人天

弊端:老大要花大量的时间切分/分配任务(但我认为是可以接受的,老大不就做这事的吗?)


项目环境

没有对比,就没有伤害。

程序员年轻的时候,可以适当的跳几次槽,开开眼界。

可以从以下几方面考察/评估项目环境:

流程

无论是最古老的瀑布模型,还是最新潮的敏捷开发,关键点就四个字:井井有条



  • 瀑布:最古老的“工业化”模式,需求 - 开发 - 测试 - 上线,单方向单线条,强调事先的良好规划
  • V型:测试和需求分析同时进行,强调测试
  • 迭代/螺旋/原型:强调项目/产品的进化,从单一的、有限的、核心的功能开始,不断的收集用户反馈,集大成者就被称之为:敏捷开发

注意:不要照搬教科书,敏捷(结对/站会/轻文档……)都已经走下神坛。最好的方式还是因地制宜。

工具

虽然说装备党人菜工具多,但一个项目组,还是应该有一些必备的项目管理工具的,比如jira、禅道、PingCode等,这些工具的功能都有重叠,但总体来说可以划分成:

  • 需求发布:需求不再写在word写在PPT里,用系统管理起来,便于查找检索,发布方一旦更新,相关人员都可以知道……
  • 任务分配:哪个功能/bug修复给谁做,预计要多久,实际做了多久,中间有哪些反馈交流,都有案可查……
  • 测试用例管理:一个一个的跑,跑过没跑过,全部有记录,而且自动通知相关开发人员……

氛围

我总结的三点:
  • 对新人有没有扶持:入职培训,rampup,你好我好大家好!不然给你捅点篓子出来……
  • 对老人有没有尊重:绝世高手刺杀皇帝,问题居然是找不到路……老马识途啊!大型项目(屎山代码)的95%的难点真的不在技术(毕竟只需要一个掏粪工)
  • 对骨干有没有公平:如上,闲的……忙的……


作业

设计一套打地鼠积分升级通关的游戏规则(其他也行)

  • 撰写一份书面的需求文档
  • 将其尽可能细的拆分成一个一个的子功能(可以在有一定编程基础后完成)
源栈 项目管理 需求 模糊 固化
赞: 0 踩: 0

打赏
已收到打赏的 帮帮币

你的 打赏 非常重要!
为了保证文章的质量,每一篇文章的发布,都已经消耗了作者 1 枚 帮帮币
没有“帮帮币”,作者无法发布新的文章。

全系列阅读
评论 / 0

编程基础


项目管理相关

需求发布、开发规划、部署、测试,源代码版本管理(git)等……

逸闻史话

认识计算机

编程语言

数据结构和算法

Web开发基础

全部
关键字



帮助

反馈