目录
使用有效的测试完成度标准
原则122 达成有效的测试覆盖
原则123 不要在单元测试之前集成
原则 124 测量你的软件
原则125 分析错误的原因
对错不对人
原则127 好的管理比好的技术更重要
使用恰当的方法
原则 129 不要相信你读到的一切
原则130 理解客户的优先级
原则131 人是成功的关键
几个好手，要强过很多生手
倾听你的员工
信任你的员工
期望优秀
沟通技巧是必要的
端茶送水
人们的动机是不同的
让办公室保持安静
布鲁克斯定律
人和时间是不可逆的
软件工程师之间存在巨大的差异
原则 142 你可以优化任何你想要优化的
原则143 隐蔽地收集数据
原则144 每行代码的成本是没用的
原则145 衡量开发效率没有完美的方法
裁剪成本估算方法
不要设定不切实际的截止时间
避免不可能
评估之前先要了解
收集生产力数据
不要忘记团队效率
LOC/PM与语言无关
相信排期
排期的定义
精确的成本估算并不是万无一失的
原则155 定期重新评估排期
轻微的低估不总是坏事
原则157 分配合适的资源
原则158 制订详细的项目计划
原则159 及时更新你的计划
原则160 避免驻波
原则161 知晓十大风险
使用有效的测试完成度标准
很多项目都在时间到期的时候宣布测试结束。这么做从政治角度来说是有意义的，但却是不负责任的。
对于测试进度的一个无效指标是测试用例通过的百分比(当然除非你确定测试用例很好地覆盖了需求 )。
原则122 达成有效的测试覆盖
1.语句覆盖率，用于衡量至少执行一次的语句的百分比。
2.分支覆盖率，用于衡量程序中被执行的分支的百分比。
3.路径覆盖率，用于衡量所有可能的路径（通常是无限的）覆盖程度。
原则123 不要在单元测试之前集成
子系统无法满足集成测试计划，可能是由于接口的错误，也可能是由于一个事先没经过测试的组件的错误。而很多时间要被花费在确定哪一个是真正的原因上。
其次，当发现集成测试的重要组件无法在需要的时候达到可用时，就让集成测试人员开始开发临时脚手架软件来模拟缺失的组件。
原则 124 测量你的软件
将特殊的指令嵌入软件，用以报告执行轨迹、异常状况、过程调用等
管理和调度真的是一个很难的问题呢
做工程，如何协调一个团队的合作，如何与人打交道，如何去解决一个问题，并且使得我们一个团队更加少的犯错误是很有必要的。
我们的社会需要一定量的卷度，但是不能全是内卷。内卷是不利于产业升级和社会进步的。举一个例子，如果我是一位房地产老板，我现在要盖一栋房子，之后，我面对的是极为廉价的工人，尽管他们的效率很低，但是他们足够便宜，此外，我面临的环境是，我仍可以降低他们的工资，因为还有很多人抢这份工作，并且，如果工地出了什么事故，因为法律监管不是很严格，我更可以节省在安全上的护具与监管费用，另外，由于当地为了拉动经济，对于房屋的质量要求也不是很高，我在建筑材料和施工严谨程度上，也可以减少很多费用。
如此，我盖出的是什么样的房子呢？那些工人能赚到多少钱呢？
如果我们不提高我们工人的社会保障与福利，从生产源头端，老板位置就没有理由和欲望去提高我们单个工人的素质和生产工具的工程效率，源头不投资财力、物力，下游的研发与生产，就更没有必要去改进我们的生产工具的效率和工人有宽裕的时间和金钱去做个人技能上的提升。
在上述的那个例子中，整个社会无疑陷入了恶性循环，内卷没有问题，但是要有底线，要在内卷的同时，逐步提升我们的社会保障与福利待遇，和加强无论是安全还是质量的监管与惩处。不然，我们几乎是在透支我们的长期良性发展和个人生存基准来维持眼前的进步，如果没有人戳破这层脆弱的泡沫，到头来我们可能迎来的就是一泻千里、、、
原则125 分析错误的原因
当一个错误被发现时，有两件事要做:（1）分析它的原因，(2）修复它。
对于错误的原因，要尽可能全面地进行记录。
让更多的人知道哪些地方容易犯错，这点真的很重要
让每个人知道是什么原因引起了错误
对错不对人
管理是围绕软件开发的所有工程活动，是进行计划(plan )控制(control)、监视(monitor ) 和报告 ( report)的一组活动。
管理是 计划、控制、监视和报告
原则127 好的管理比好的技术更重要
成功的软件初创公司，不是因为它们有强大的流程或者强大的工具(或与此相关的优秀产品)而成功。大多数的成功都源于成功的管理和出色的市场营销。
使用恰当的方法
原则 129 不要相信你读到的一切
一般来讲，相信特定想法的人，会搜索支持这个想法的数据，而抛弃不支持的数据。要说服处于某个位置的某人，显然会使用支持的数据，而不是不支持的数据。
原则130 理解客户的优先级
很有可能的是，如果客户能按时获得必需的 10%的系统功能，那么他们可以忍受其余 90%的功能延迟交付。
此外，你必须理解客户对于“必要'（essential)“期望”( desirable)和“可选”( optional)的说明。
原则131 人是成功的关键
人才质量是无法替代的
几个好手，要强过很多生手
但是一个项目中要控制适当的比例，如果那少数的好手跑路了怎么办？
倾听你的员工
你必须信任那些为你工作的人。如果他们不值得信赖（或者你不信任他们)，你的项目将会失败。如果他们不信任你，你的项目也将会失败。你的员工很快就能看由你不信任他们，就跟你能很快发现你的老板不信任你一样。
信任的第一个原则就是倾听。
信任你的员工
成为一个坏人的机会远远比成为一个好人的要多。抓住每个能让你成为好人的机会。
期望优秀
如果你对员工有更高的期待，他们将表现得更好。沃伦·本尼斯(Warren Bennis)的研究证明:你期望的越多，获得的成就就越大(显然有一定限制。
沟通技巧是必要的
端茶送水
当你的员工要工作很长时间来完成软件工程的工作时，你应该工作相同的时间
为他们点点外卖、拿一杯水、深夜送个小烧烤去看望他们都是可以的
人们的动机是不同的
我特别希望对干得好的员工大幅加薪，以激励他们更加努力地工作。当我向某个员工第一次提出加薪时，他说:“谢谢，但是我真正需要的是一台更快的电脑”。
让办公室保持安静
最有效率的员工和公司都拥有安静和私密的办公区
布鲁克斯定律
简单说，就是人越多，不代表效率越高
布鲁克斯定律（Brooks' Law）是由计算机科学家弗雷德里克·布鲁克斯于1975年提出的一条经验规律。该定律指出：在开发软件项目时，增加人力资源不一定能够加快项目的进度，反而可能导致工作效率的下降。
布鲁克斯定律的原理基于以下观察和假设：
-
新成员的学习成本：当一个新成员加入一个正在进行的软件项目时，他们需要一段时间来熟悉项目的目标、架构、代码等方面的知识。这个学习过程需要由其他团队成员来指导和支持，从而导致团队整体的工作效率下降。
-
沟通与协调成本：随着团队规模的增大，沟通和协调的成本也会相应增加。更多的人意味着更多的交流和合作，而这对于一个复杂的软件项目来说是一项挑战。团队成员之间需要花费更多的时间和精力来讨论和解决问题，从而延缓了项目的进展。
-
人员变动带来的影响：当新的团队成员加入或原有成员离开时，团队的动态和稳定性可能会受到影响。新成员需要时间来适应和融入团队文化，而离开的成员可能留下的空缺需要其他人来填补，这可能导致工作效率的降低。
根据布鲁克斯定律，增加团队规模并不总是能够加速软件项目的开发进程。相反，团队规模过大可能会导致沟通、协调和学习成本的增加，从而减慢项目进展的速度。布鲁克斯提出，管理者在决定增加团队规模时应该谨慎，同时要考虑到团队的协作效率和团队成员之间的默契配合。
人和时间是不可逆的
只用“人月”来衡量一个项目几乎没有任何意义。如果一个项目能够由6个人在1年内完成，是不是意味着 72 个人能在一个月内完成呢?当然不是
软件工程师之间存在巨大的差异
好的与差的工程师差距几千倍
原则 142 你可以优化任何你想要优化的
如果你告诉你的员工一切(例如，工期、大小、可维护性、性能和用户友好性)都同等重要，那么任何地方都不会被优化。如果你告诉他们只有一两个很重要，而其余的不重要，那么只有重要的地方会得到改善。如果你给他们一个通用的优先级排序，该排序可能不适用于项目中的所有情况。事实是，在产品开发过程中，有很多选择一不同的权衡一一不得以而进行取舍。与你的员工一起工作，并帮助他们了解你和你的用户的优先级。
原则143 隐蔽地收集数据
另外以别人不情愿的方式收集数据是没有意义的(比如，需要软件开发员做大量额外的工作 )，因为这种收集方式会影响数据本身。此外从不想提供此类数据的开发人员那里获取数据可能会毫无用处，因为不合作的开发人员不太可能提供有意义的数据。
收集数据的最佳方法是自动进行，这样开发人员不会感到被干扰显然，你不能在所有时间对所有数据都这么做，但是应尽可能自动地执行数据收集
几乎世间一切，都是如此，不愿意的一般效果都很差
原则144 每行代码的成本是没用的
与选择非常低级的语言相比，选择高级的语言将花费更少的时间
但是，由于软件开发的固定成本(例如，用户文档、需求和设计),如果我们选择高级语言，每行代码的成本实际上会增加!
原则145 衡量开发效率没有完美的方法
代码不是越多干的就越好
效率是真的很难办的事情
其实，这是一个问题，这些说的都是你的天赋或者能力很好的前提下，所讲述的
裁剪成本估算方法
要生成更加准确的估算，就需要针对工作环境进行裁剪
如何说决定了能力有多大
《设计方法与设计》
拿着本专业的东西，去结合大模型
本身所在的地方，就有很多亟待解决的问题
把自己家乡的问题没有研究好
地域关联性 大家的家国情怀
By using "can," the sentence introduces an element of contingency, indicating that the obligation is conditional and subject to the person's actions or behavior.
不要设定不切实际的截止时间
绝大部分软件项目的完成都远远超出预算，并且大大超出了计划的完成时间
设立这样垃圾的时间，
不良的影响：1.削弱士气 2.是员工不信任你（高离职率）3.其他不良影响
避免不可能
不要认为自己可以超出一般定律
评估之前先要了解
收集生产力数据
从过去的项目中收集详细的数据
少量经过充分理解、认真收集、模型化及演绎的数据，要好于大量没有这些特性的数据。
不要忘记团队效率
要汇聚一套大家共同想要什么的公约数，每个人把个体的能力发挥到最大，合在一起，不一定是一个强大的队伍，因为团队合作有很多其他的因素需要被考虑。
LOC/PM与语言无关
相信排期
最好的建议是，让工程师制定排期
排期的定义
在软件工程中，排期（Scheduling）指的是规划和安排软件项目中各个任务、活动或阶段的时间表。排期是项目管理的重要部分，它涉及确定项目的起始时间、截止时间、任务的顺序和并发执行、资源分配等。通过合理的排期，团队可以更好地控制项目进度，确保项目按时完成，并有效地利用资源。
排期的过程包括以下几个关键步骤：
-
任务识别： 首先，需要识别项目中的所有任务和活动。这可以通过拆分项目为更小的任务、编写需求文档、确定开发阶段等方式来实现。
-
任务估算： 对每个任务估计所需的时间和资源。这可以通过经验、历史数据、专家意见等方法来进行。估算的结果有助于确定任务的工期。
-
任务依赖关系： 确定任务之间的依赖关系。某些任务可能需要在其他任务完成后才能开始，这会影响任务的排期顺序。
-
时间分配： 将估计的时间分配给每个任务，形成一个时间表。这可以通过甘特图、时序图等方式进行可视化展示。
-
资源分配： 确定每个任务所需的资源，包括人员、设备和工具等。资源的可用性会影响任务的并发执行和工期。
-
风险考虑： 考虑可能的风险因素，如延误、资源不足等，以便在排期中预留一些缓冲时间。
-
优化和调整： 对排期进行优化，确保任务之间没有冲突，最大限度地提高资源利用率，同时满足项目时间要求。
-
监控和更新： 在项目执行过程中，持续监控排期的执行情况，及时更新排期以反映实际进展。
总之，排期在软件项目管理中起着至关重要的作用，它有助于规划、控制和跟踪项目进度，以确保项目按时、高效地完成。
精确的成本估算并不是万无一失的
如果我告诉你我要抛硬币 100次，并要求你预测硬币正面向上出现的次数，你很可能会选择 50次。这是否意味着真的会出现50次正面向上? 当然不是。实际上，如果真的刚好出现了 50次正面向上，你将感到很惊奇
不要认为你的规划没有问题，人的规划考虑的因素真的太少了，为什么你一个少参数问题能够精准概括估计到一个复杂参数问题呢
把规划放的宽一点
原则155 定期重新评估排期
应与客户和/或上级建立工作关系。要报告每个可能的日期变更(通常是延期)，并讨论克服这些困难的可选策略。只有各方的早期干预和参与才能防止延期升级。
轻微的低估不总是坏事
就是不要太满，一满就装不下东西了
对员工也不能说，你真的是棒的没有边，你真的无敌了
应该说，你做的不错，但是这里那里还是可以再提升一下
工作进度就算喜人，或者按部就班，但是也不能说，进度真的很快，大家不用担心，这就不行了
原则157 分配合适的资源
不管人员的质量如何，工具、语言或流程的可用性如何，人为强加的进度和不恰当的预算将会毁了一个项目。
原则158 制订详细的项目计划
你需要的计划的最小集合如下，
显示任务之间相互依赖关系的 PERT 表
显示每个任务的活动何时进行的甘特图
实际里程碑的列表(基于早期的项目，见原则 150)。
编写文档和代码的一套标准。
各种不同任务中的人员分配
原则159 及时更新你的计划
有一个过时的计划比完全没有计划更精糕。当你没有计划时，你应该知道你已经失控了。当你有一个过时的计划时，你可能天真地以为一切在你的控制之中。所以无论任何时候情况发生变化，都要更新你的计划。
(但是人家说的是，你已经很恶劣了，你都没有计划的前提下，一个过时的计划更加可笑，但是很多的人，连迈都不迈步子，这不更是一种悲哀吗？
这里说的都是愿意干的人，你不要走弯路)
原则160 避免驻波
在这种情况下，你总是计划“在未来几周内”可以“康复”的策略。由于落后于计划的项目往往会进一步落后于计划,因此这种“康复”的策略“在未来几周内”-将会需要越来越多的资源(或奇迹如果不采取纠正措施，波动会变得越来越大。
（我感觉这个驻波形容的很好，相似的两个，合力形成一个更大的波向前）
如果你不一点点纠正，你个危害就如滔天洪水一样，奔涌袭来。
原则161 知晓十大风险
相据Boehm的说法，它们是
人员短缺(见原则 131)。
不切实际的排期(见原则 148。
不理解需求(见原则 40 )。
开发糟糕的用户界面( 见原则 42 )。
当用户并不需要时尝试镀金( 见原则 67)
没有控制需求变交更《见原则 179 和189 )。
缺乏可重用的或者接口化的组件。
外部执行任务不满足要求。
糟糕的响应时间。（自己做微信小程序的时候真是把自己害惨了，这个响应时间真的是很要命）
试图超越当前计算机技术的能力。
