10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7914 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

17 | 程序员也可以“砍”需求吗?

郑晔 2019-02-06
我们前面讲的任务分解,主要是在讲开发任务的分解。今天我们换个角度,看看需求的分解。是的,需求也要分解。
有一次,我和一个做开发的同事聊天,他给我讲了他近期的烦恼。
同事:我们现在就是需求太多,开发的人太少,再这么干下去,哪天觉得自己抗不住了,我就拍拍屁股走人。
我:你没尝试着砍砍需求?
同事:怎么没尝试?产品的人都不同意。这批功能他们都说是关键功能。
我:你有没有尝试把需求拆开了再砍呢?
同事:还可以这样?
同事很惊讶,我一点都不意外。我们都是在说需求,但彼此对需求的理解却是大不相同。我先来问个问题,提到需求这个词,你会想到什么呢?
以我们用了好多次的登录为例,如果我问你这个需求是什么,大多数人的第一直觉还是用户名密码登录。
基本上,闯入你脑海的需求描述是主题(epic),在敏捷开发中,有人称之为主用户故事(master story)。
如果你对需求的管理粒度就是主题,那好多事情就没法谈了。比如,时间紧迫的时候,我想砍需求,你问产品经理,我不做登录行不行,你就等着被拒绝吧。
但是,如果你说时间比较紧,我能不能把登录验证码放到后面做,或是邮件地址验证的功能放到后面,这种建议产品经理是可以和你谈的。
这其中的差别就在于,后者将需求分解了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 西西弗与卡夫卡
    需求管理中印象最深的是刚进入开发行业时的一段经历。当时要显现某种单据,单据本身还嵌套子单据,原始需求是单据按层次显示,但某变量等于某个值时,某层次的单据就隐藏,但它的再下一层子单据需要显示。解决方案简单可以理解成页面要用递归方式才能正确显示。当时一心想显示自己牛鼻,因为无法用通常的页面模版机制,就自己写工具递归生成页面代码,看起来代码很巧妙,但别人难以维护。后来有段小插曲,若干年后项目移交到另外一个研发中心时,还需要有人专门去讲这段代码,否则接手人很难理解。再说回到之前,开发完后有一次和业务分析员再次聊起,说这个很不好实现但我啃下来了等等,他说那可以不用隐藏,显示空白层也可以,真如果这样实现就简单多了,也好理解多了。事不大,但在职业生涯里印象深刻。需求不光是拆解,更可以讨论后寻找简单解决方案,而不是用自以为牛鼻的代码实现。以更合理的成本实现需求交付价值,这其实是用户故事里Negotiable的意义所在

    作者回复: 多谢大年初二的学习与分享!

    程序员的锤子是代码,到处找钉子是直觉。

    2019-02-06
    9
  • 我对需求的理解分两个层面:用户需求和开发需求。在尽可能全面了解客户意图的基础上突出价值,通过开发需求框定范围。以往会形成两份不同的文档,主要是考虑到双方的知识背景不同而有针对性的准备,至于开发需求的误差程度往往得不到客户的有效确认,因为客户不习惯以程序员思维和工作模式去阅读开发文档,常常会给基本上是这样、差不多吧、先这么着看看这样的反馈。所以我在想应该可以用一种更“活泼”的方式去提高双方的沟通效率,如果能够以故事的方式去撰写用户故事,把问题拆分說透,用一个个能让对方身临其境界的场景故事去沟通,而非格式化的冷冰冰的文档去消除双方认知上的不足与分歧,这样除了可测试之外其他方面应该都能兼顾了吧。

    作者回复: 程序员喜欢活泼点的东西 :)

    2019-02-06
    3
  • 陈斯佳
    愿上帝赐予我能拆分需求的智慧……
    2019-07-31
    2
  • helloworld
    进行开发之前先把需求理解好,也就是要做什么,然后进行需求的拆分,也就是怎么做,到这时候有些用户故事肯定会由于某些原因做不了,就砍掉,再然后对需求进行排期。所以拆分需求的过程也是梳理项目的过程。

    作者回复: 这个理解的角度很不错!

    2019-03-01
    2
  • 老师,今天的内容,能不能理解为需要先将用户故事切分的足够小,然后以此来做需求合理性、工时评估、需求的降低标准等事情呢?

    作者回复: 先将需求分成用户故事,只有到达可以评估的大小,你才能更好地理解,才能开始做后续的工作。

    2019-02-06
    2
  • Phoenix
    要看公司,很多公司很多需求是老板提的,老板和产品都是强势方,这种情况是没法砍需求的

    作者回复: 你“认为”没法砍,那就真的没法砍了。

    2019-02-15
    1
  • WL
    可衡量才可以讨论,跟老师学习受益匪浅
    2019-02-12
    1
  • 丁丁历险记
    1 作者观点。绝大多数问题都是由于分解的粒度太大造成的,大块的需求不能谈取舍,但小的就比较合理。
    读后思考,(yy 个例子,和人讲把头发剃光是不好谈的,但是谈谈把哪里剃一下,可以换来xxx 这个是好谈的 )
    2 INVEST 介绍。
    Independent,独立的
    Negotiable,可协商的
    Valuable,有价值的
    Estimatable,可估算的
    Small,小
    Testable,可测试的
    读后思考,天啊,这么多的单词,这么详细的解释(罗里吧嗦), 我是记不住的,自己yy 个故事去记忆吧。(为了方便,直接借用作者昨天的例子来扯需求好了)
    google 整理术告诉我们,长期的记忆是一个encoding 过程,使用故事是一个非常好的套路(作者也同样说了这点,只是没站在大脑认知学的维度来谈而已)
    step1:在漫长的等待后,产品的用户登录登出需求出来了(出来了,出来了....)。 做为开发,我第一时间对他的需求做了梳理含以下内容, 基于(Independent 独立性的)分解如下 并且分解得很(small 小)
    手机号密码登陆(判断 (不能为空,手机号格式,密码长度校验))
    记住密码
    第三方登录(微信扫码,微博登录,qq 登录)
    登录时长为2小时
    。。。。。
    登出
    step2 : 我拉来了产品,协商。(便于简化 ,这里只谈记住密码,和第三方登录) 这写说明了,分解的粒度是(Negotiable 可协商的)
    2.1记住密码这事,其价值是用来方便用户的(Valuable 价值判断),但现在,chrome,ff,360se等浏览器 早以集成了这些功能,花了不少的时候,做出来的东西,并未额外给客户带来更多价值,所以,在我们这个mvp 版本中,这个先砍掉,我们多些思考,找出做这里的价值,再来开发如何。。。(small)
    2.2 第三方登录这事,(我们的客户特征,是一定有微信的,(在其它应用场景中,是直接使用了微信的例如群发通知,微信课评等...)) 所以,微博登录,qq 登录,对我们来说,是做了多余的事。
    关于微信登录呢,在沟通用说到 平台需要收集到用户的手机号,顺带方便客户手机登陆,所以在首次扫码时,提示下客户去做手机绑定,和直接使用。 (毕竟我们不是流氓平台,动不动强制用户绑了手机才能用)
    这个沟通, 我们先砍了价值 我们通过沟通发现,我们把微信登录后手机号绑定这个需求,单独给提了出来 (small) 并且把微信登录这事(Testable 可测试的) 的需求出来。
    step3 梳理玩需求后,开始估算进度了。
    微信登录这事吧 先拍脑袋 2 days (Estimatable) ( 我讲下如何拍出来的, 我看了下文档 https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html 难度适中,考虑到开发之前没有做过类似开发,但这个早已被大量网站给实践出来了,先初步给两天吧。 (基于dod 原则,我和程序员聊了下,给这么多时间,主要是 1 完成pc 端扫码登录的任务,并测试完成【紧急】。 2 熟悉知识和习惯一种与第三方协同的开发模式【重要】 我为认工程师不能只限于事务(完成1 ),还需要能力成长 (完成2) (再讲个个人习惯 ,我会再预留半天时间,程序员写崩了后,我去快速填坑 , 小概率事件,做一个合适的预留 ,这里我多扯一句,要基于库尔贝勒交叉熵去适当预留资源,项目开发需要鲁棒性,别让极小概率事件把整个项目搞崩) 其实这个 2days 的结论,也是由于分解的足够独立,且粒度足够小,才可以做出来估算. 所以,我在后续估算工做量发现蒙b 时,就会去思考是否分解到位了。
    3 作者推荐了两本书《User Stories Applied》和《Agile Estimating and Planning》。
    做以下操作, 复制 User Stories Applied 打开某东,搜索 User Stories Applied 先加入购物车
    由于价格很感人 User Stories Applied ¥571.00 Agile Estimating and Planning ¥620.00
    我登上download.csdn.net (vip ) 下载了对应的pdf , 然后再上传至百度网盘(还是vip)
     并分享出来 https://pan.baidu.com/s/1jWbXqUX2kXJGJcyurGDh4w 提取码: e28v
    2019-11-09
  • 小马哥Mark
    开发估期不应该靠直觉,而应该基于可控的需求任务量,而要需求任务量可控,这个需求就应该足够小,足够明确
    2019-08-20
  • 陈斯佳
    拆分需求,越小越好,这个是要不断打磨的一项技艺。做一个好的程序员,甚至一个好的项目经理,这应该是必不可少的技能。其实,这个方法都可以应用在我们生活当中。把我们生活看作一个个项目,把自己当作项目经理,去拆分一个个需求,慢慢的把它实现。
    2019-05-18
  • Sudouble
    这一节里介绍的用户故事,感觉和软件工程里的基于场景的需求建模很相似。明确需求是重中之重

    作者回复: 用户故事只是描述需求的一种方式而已。

    2019-02-15
收起评论
11
返回
顶部