软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

“一问一答”第2期 | 30个软件开发常见问题解决策略

宝玉/专栏用户 2019-04-13
你好,我是宝玉。我们专栏已经完成了项目管理和需求分析这两个模块的学习。这两个模块看起来都和技术没什么关系,但却是项目中至关重要的部分。
项目管理贯穿项目始终,需求是项目的源头。希望通过对这两个模块的学习,能加深你对项目管理和需求分析知识的理解,能应用其中一些方法,帮助你个人能力更上一层,项目越做越好。
这个过程中一如既往的收到很多同学的精彩留言。其中有一些是提问,一些是针对文章主题自己独到的思考,这些内容都是对专栏内容最好的补充,可以加深你对软件工程的理解和学习。

一问一答

No.1
Charles:可行性分析形同虚设,小公司岗位职责不清晰,互相照顾面子怕得罪人,谁都怕犯错背锅,感觉谁都对,最终就导致谁是“老板”谁拍板!我感觉这个问题挺严重的,很影响决策正确性,只能等所谓的市场反馈。也用类似项目成员“扑克牌”打分的方式可以解决吗?核心问题出在哪里?
宝玉:这个问题已经不是可行性研究的问题了!核心问题在于没有一套合理的类似于扑克牌打分的机制和流程。
扑克牌为什么是个好机制:
公平合理,每个人都有机会不受他人影响的表达
不用背锅,估错了也没关系,意见不一致还可以讨论
可行性研究是不是也可以形成类似机制?有专门会议,大家提前准备,会议上一起讨论结果,不用背锅,根据讨论结果形成最终决议。项目结束后在回顾对比当初的分析,作为下一次的参考。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • 一路向北
    这个总结做的真是不错!看一遍,又把项目管理,产品开发实践等方面又重新温习了一遍,加深了印象。

    作者回复: 🤝要感谢编辑同学帮忙辛苦整理。

    2019-04-13
    5
  • 小老鼠
    技术人员如何学好业务知识?

    作者回复: 学什么都离不开:理论+实践

    2019-09-17
    1
  • 超神的新垣结衣
    第一段中提到的扑克牌打分是什么机制?

    作者回复: 其实是扑克牌估算工作量方法,可以参考:http://www.scrumcn.com/agile/scrum/4523.html

    《07 | 大厂都在用哪些敏捷方法?(下)》
    https://time.geekbang.org/column/article/85018

    2019-04-15
    1
  • 精选的真好,一方面更加深刻的理解了专栏的内容,一方面也学习了很多同学们做总结的方法。

    编辑回复: 嗯,有帮助就好😊

    2019-04-14
    1
  • 鸽足轻轻
    赞~
    2019-05-10
  • 货很干!点赞👍
    2019-04-15
  • 大茹
    赞👍
    2019-04-13
收起评论
7
返回
顶部