《软件工程之美》打卡第二周

这是笔者参加极客时间21天打卡第二周，分享和总结确实是个很好的学习方法，这一周我又对软件工程多了一些理解，每日总结内容如下：

第八天

今天学习了宝玉老师的《软件工程之美》中的“07|大厂都在用哪些敏捷方法？（下）”，以下是我的总结：

宝玉老师举的实施敏捷开发小组的日常的例子跟我们的还不太一样，人员配置上我们是按职能划分了客户端、前端、后台、运营、产品、设计、测试组，规模会更大一点。分工基本上类似，产品写完需求设计文档会拉起相关人员进行宣讲，然后我们会进行工作量量评估，后面每天的都是完成日常开发工作，需求和修复bug都是在周期内完成的。我们每个需求都会设置一个Owner，由Owner去负责整个需求的进度根据和推送，关于开发会基于主干拉起feature分支进行特性开发，开发完成之后合入主干，发布之前会拉起release分支进行系统测试，最后才是发布上线。说实在我们其实也不是严格意义上的敏捷开发，但价值观和原则是对齐敏捷开发的。我觉得这里比较好的地方就是培养Owner意识，需要每个人都为这个需求负责，不好的地方就是周期迭代需要加班，时间点卡的比较死，开发疲于应对需求，少了点时间去做一些技术建设和成长思考。

第九天

今天学习了宝玉老师的《软件工程之美》中的“08|怎么平衡软件质量与时间成本范围的关系？”，以下是我的总结：

这节课内容对我们日常工作很有启发作用，质量、成本、范围作为软件工程项目管理的金三角，是我们把项目做成的必然要素，我们都想用尽可能小的成本上去产出高质量的产品，这是个很美好的愿景。但在真实的软件项目开发过程中，只能在这三角中不停做妥协和平衡去寻找最优解。

第十天

今天学习了宝玉老师的《软件工程之美》中的“一问一答第一期”，以下是我的总结：

基础理论一共有8讲，分别是：

• 01|到底怎么理解软件工程？
• 02|工程思维：把每件事都当做一个项目来推进
• 03|瀑布模型：像工厂流水线一样把软件开发分层化
• 04|瀑布模型之外，还有哪些开发模型？
• 05|敏捷开发到底是想解决什么问题？
• 06|大厂都在用哪些敏捷方法？（上）
• 07|大厂都在用哪些敏捷方法？（下）
• 08|怎么平衡软件质量与时间成本范围的关系？

从这8讲当中我重新温习了软件工程的一些基础概念和思考了自己实际工作中所实践的一些开发模型，比如敏捷开发和迭代增量开发，MVP最小可行版本等，以前只是知道我们在用，但没有深入去理解每个概念的背后到底在解决什么问题，这个专栏最大的价值在于让我重新理解了软件工程这门学科，它能让程序员更好的去掌控实际的开发工作，而不是被动去接受需求，要从更全局的视野去思考软件质量和时间成本之间的关系，从中做出最优的决策。专栏里面有很多人的分享都很有参考意义，着实让我扩展了视野。

第十一天

今天学习了宝玉老师的《软件工程之美》中的“09|为什么软件工程项目普遍不重视可行性分析？”，以下是我的总结：

软件项目不特殊，只要项目具备了可行性研究的条件就需要去做，不然可能会带来不必要的麻烦，如果不具备可行性，则应该及时调整方案或及时止损。 做出科学的可行性分析，通过合理的方式反馈和建立可行研究的意识来降低项目失败的概率。 面对创新，可行性研究不是拦路虎，而是能够做出更准确的判断过滤掉不靠谱的创新想法。 软件项目的可行性研究，主要从以下几个方面入手：

1. 经济可行性（看投入产出比和长期利益）
2. 技术可行性（是有有专业的人，技术上解决不了的问题是否存在）
3. 社会可行性（法律、道德、社会影响等，比如开源协议）

第十二天

今天学习了宝玉老师的《软件工程之美》中的10 | 如果你想技术转管理，先来试试管好一个项目，以下是我的总结：

技术人员转管理的障碍 过于关注于技术细节，可能会忽视跟其他人的沟通，思考问题不够有大局观，不关注项目进展。 如何管理软件项目？

• 管好人 人主要是你的客户和项目成员，比如我们做教育产品的，我们的产品用户就是我们的客户，负责这个项目的开发人员、产品、设计、运营、测试等都是项目相关人员。 客户要管理好预期，我们要按时按质交付高质量的产品和内容，让客户对我们的产品产生经济价值，比如付费行为。 项目成员需要用流程和规范来完成高效协作，按时完成产品迭代。
• 管好事 软件项目的事就是完成项目目标，而完成目标是一系列过程，要做好项目管理也就是要做好对软件开发过程的管理。

1. 选择合适的开发模式，比如迭代模型或者增量模型 合适的开发模式都有配套的流程规范和工具，来保证开发模式正确的被执行
2. 制定好项目计划 举个我们产品的迭代计划的例子： 需求宣讲截止时间11.06 功能开发完成时间11.20 功能测试完成+bugfix完成 11.27 后台发布+拉发布流11.28 系统测试+bugfix完成 12.04 checklist+内部体验 12.05 灰度一周 12.05-12.11 全量上架12.12 具体节点和截止时间要完成的事情。
3. 控制和跟踪计划，做好风险管理 让团队成员正确评估工作量，早点抛出风险点，然后可以通过调整期望值，比如控制范围和时间来达到目标。

第十三天

今天学习了宝玉老师的《软件工程之美》中的11 | 代码未动，计划先行，以下是我的总结：

软件项目管理中的计划是保证项目在执行过程中不会陷入一种无序和混乱中。 对于程序员来说也应关心计划，这可以让我们更好的安排实际的工作，比如你需要关心执行过程中是否存在风险，任务之间存在的依赖关系。 制定计划的步骤一般有以下三个步骤：

1. 任务分解 任务分解可以按照WBS（工作分解结构）来拆分，将大阶段拆分为小阶段，将小阶段再进一步拆分为具体的任务。
2. 估算时间 估算时间不能由项目经理来做，因为可能会存在偏差，开发人员和项目经理需要充分沟通来消除这种偏差，让开发时间的估算变得更加合理。
3. 排任务路径 任务可能不是串行的，排路径要根据任务之间的关系，资源占用情况，排出合适的顺序。

项目计划制定好之后还没有完事，还需要进行跟踪和根据实际情况进行调整，进度跟踪可以是项目经理定期收集或者项目成员主动汇报。也可以参考敏捷的一些实践，比如每日站会和看板来跟踪。

第十四天

今天学习了宝玉老师的《软件工程之美》中的12 | 流程和规范：红绿灯不是约束，而是用来提高效率，以下是我的总结：

好的流程规范不是约束，而是用来提升团队效率的。比如指定代码规范，让大家写出差别不大的代码，提升了代码可读性又增加了可维护性，别人接手起来也不至于太困难。 关于这点我是很认同的，规范能让团队中能力不同的人都能够写出好的代码，也能够让新人更好的融入团队。 制定流程规范一般有四个步骤： 第一步：明确要解决的问题 第二步：提出解决方案 第三步：达成共识，推广执行 第四步：持续优化，不断改进 近段时间我在负责关于热更新在项目落地的事情，也制定了相应的流程规范，基本是按照这四个步骤在做。 规范是为了提升效率，如果太过依赖人去执行，反而可能降低了效率，所以应该想办法通过技术手段来帮助人去执行规范，还是代码规范的例子，不可能每个人都熟记里面每一条规则，我们可以借助IDE或者一些代码格式检查工具来辅助开发人员去检查规范。

最后

第二周的内容正式进入项目规划篇，这周我学习到了关于可行性分析对软件项目的重要性，技术转管理需要跨越的阻碍，怎么做项目计划，如何制定流程和规划，这些内容都是代码之外的功夫，而这些功夫能让自己走得更远，对我来说需求不仅仅只是个需求，项目的成功是有套路的。用更好的方法去指导自己的日常工作，不至于埋头工作忘了抬头看天。下周会继续分享我在学习软件工程之美学习的内容，谢谢阅读。