《软件工程之美》打卡第二周，冲刺7天拿下Offer
作者：互联网
今天学习了宝玉老师的《软件工程之美》中的“08|怎么平衡软件质量与时间成本范围的关系？”，以下是我的总结：
这节课内容对我们日常工作很有启发作用，质量、成本、范围作为软件工程项目管理的金三角，是我们把项目做成的必然要素，我们都想用尽可能小的成本上去产出高质量的产品，这是个很美好的愿景。但在真实的软件项目开发过程中，只能在这三角中不停做妥协和平衡去寻找最优解。
今天学习了宝玉老师的《软件工程之美》中的“*一问一答第一期
*”，以下是我的总结：
基础理论一共有8讲，分别是：
-
01|到底怎么理解软件工程？
-
02|工程思维：把每件事都当做一个项目来推进
-
03|瀑布模型：像工厂流水线一样把软件开发分层化
-
04|瀑布模型之外，还有哪些开发模型？
-
05|敏捷开发到底是想解决什么问题？
-
06|大厂都在用哪些敏捷方法？（上）
-
07|大厂都在用哪些敏捷方法？（下）
-
08|怎么平衡软件质量与时间成本范围的关系？
从这8讲当中我重新温习了软件工程的一些基础概念和思考了自己实际工作中所实践的一些开发模型，比如敏捷开发和迭代增量开发，MVP最小可行版本等，以前只是知道我们在用，但没有深入去理解每个概念的背后到底在解决什么问题，这个专栏最大的价值在于让我重新理解了软件工程这门学科，它能让程序员更好的去掌控实际的开发工作，而不是被动去接受需求，要从更全局的视野去思考软件质量和时间成本之间的关系，从中做出最优的决策。专栏里面有很多人的分享都很有参考意义，着实让我扩展了视野。
今天学习了宝玉老师的《软件工程之美》中的“09|为什么软件工程项目普遍不重视可行性分析？”，以下是我的总结：
软件项目不特殊，只要项目具备了可行性研究的条件就需要去做，不然可能会带来不必要的麻烦，如果不具备可行性，则应该及时调整方案或及时止损。
做出科学的可行性分析，通过合理的方式反馈和建立可行研究的意识来降低项目失败的概率。
面对创新，可行性研究不是拦路虎，而是能够做出更准确的判断过滤掉不靠谱的创新想法。
软件项目的可行性研究，主要从以下几个方面入手：
-
经济可行性（看投入产出比和长期利益）
-
技术可行性（是有有专业的人，技术上解决不了的问题是否存在）
-
社会可行性（法律、道德、社会影响等，比如开源协议）
今天学习了宝玉老师的《软件工程之美》中的10 | 如果你想技术转管理，先来试试管好一个项目，以下是我的总结：
技术人员转管理的障碍
过于关注于技术细节，可能会忽视跟其他人的沟通，思考问题不够有大局观，不关注项目进展。
如何管理软件项目？
- 管好人
人主要是你的**客户和项目成员**，比如我们做教育产品的，我们的产品用户就是我们的客户，负责这个项目的开发人员、产品、设计、运营、测试等都是项目相关人员。
客户要管理好预期，我们要按时按质交付高质量的产品和内容，让客户对我们的产品产生经济价值，比如付费行为。
项目成员需要用流程和规范来完成高效协作，按时完成产品迭代。
- 管好事
软件项目的事就是完成项目目标，而完成目标是一系列过程，要做好项目管理也就是要做好对软件开发过程的管理。
- 选择合适的开发模式，比如迭代模型或者增量模型
合适的开发模式都有配套的流程规范和工具，来保证开发模式正确的被执行
- 制定好项目计划
举个我们产品的迭代计划的例子：
需求宣讲截止时间11.06
功能开发完成时间11.20
功能测试完成+bugfix完成 11.27
后台发布+拉发布流11.28
系统测试+bugfix完成 12.04
checklist+内部体验 12.05
灰度一周 12.05-12.11
全量上架12.12
具体节点和截止时间要完成的事情。
- 控制和跟踪计划，做好风险管理
让团队成员正确评估工作量，早点抛出风险点，然后可以通过调整期望值，比如控制范围和时间来达到目标。
灰度一周 12.05-12.11
全量上架12.12
具体节点和截止时间要完成的事情。
- 控制和跟踪计划，做好风险管理
让团队成员正确评估工作量，早点抛出风险点，然后可以通过调整期望值，比如控制范围和时间来达到目标。
标签：完成,项目,Offer,之美,软件工程,开发,软件,打卡 来源： https://blog.csdn.net/m0_66264699/article/details/122601040