《构建之法》第三章第八章内容要点笔记和读后感
第3章 软件工程师的职业发展
3.1 软件工程的定义与核心
综合性
软件工程不仅涵盖软件的开发，还包括运营和维护。这涉及多种技术、做法、习惯和思想。
软件开发流程
统一各种相关技术和过程，提高开发效率、用户满意度、软件可靠性和可维护性。流程不仅适用于团队，也适用于个人。
3.2 团队与个人流程
团队流程
通过有序组织团队成员的工作（开发、测试、设计、管理、交流等），提升整体效率。成功的团队流程能够积极管理冲突，促进合作。
个人流程
每个团队成员（称为Individual Contributor，IC）有自己的工作流程，包括理解需求、提出解决方案、编码、测试和维护。
3.3 衡量与证明能力
传统认证
如计算机等级考试、微软认证（MCP）、甲骨文认证（OCP）等，提供权威的能力证明，但存在局限，如无法评估团队合作能力和实际项目经验。
实际成果
参与的项目、用户评价、市场占有率等是更重要的衡量标准。工作质量直接影响软件的最终质量。
工作量与质量
通过项目大小（代码行数、功能点）、花费时间、代码质量（缺陷率）、按时交付等指标来衡量。
3.4 职业发展路径
知识与技能积累
技术技能
掌握编程语言（如Java、C++、C#）、性能优化、设备驱动、内核调试等。
领域知识
了解特定行业（如医疗、金融）的需求和挑战。
软件设计与工程思想
理解良好的设计原则和工程方法。
职业技能
自我管理、沟通协作、任务执行力等。
成长路径
考级与认证
通过国家或公司提供的认证考试证明能力。
公司内部成长
大公司（如微软）有详细的职业等级和成长路径，要求在多个知识领域达到一定水平。
自我评估
通过自我评价清单检查自己的技能和知识，持续学习和提升。
3.5 技能与问题解决
技能的反面
真正的能力不仅是记忆和执行技能（如魔方口诀），更重要的是能够理解原理并灵活应对变化。
持续学习与实践
通过不断的练习和实际项目经验，将低层次的问题解决转化为自动化操作，从而有更多时间和精力处理高层次的问题。
3.6 软件工程的本质
工程 vs. 艺术
软件工程既需要工程的严谨和规范，也需要艺术的创造力和灵活性。理解两者的平衡对于高效开发和创新至关重要。
代码质量与数量
随着项目规模的增加，代码的结构化和可维护性变得更加重要。质量优于数量，良好的设计和架构能够有效管理大型代码库。
3.7 实践中的启示
稳定与一致
在团队合作中，能够稳定、按时地交付高质量的工作结果，建立信任和可靠性。
持续改进与反馈
通过测试、反馈和迭代不断优化软件，提升整体质量和用户满意度。
自我管理与成长
主动学习新技术、优化工作流程、提升职业技能，才能在竞争激烈的行业中脱颖而出。
总结与启发
- 全面发展：不仅要提升编程技能，还要注重沟通、协作和自我管理能力。
- 重视实际成果：通过参与项目、积累经验和获得实际成果来证明自己的能力，而不仅仅依赖于认证和考试。
- 持续学习：软件工程是一个不断变化的领域，保持学习的热情和适应新技术的能力至关重要。
- 团队合作：理解团队流程，善于管理和利用团队中的不同意见，提升整体效率和成果。
- 质量优先：注重代码质量和软件的可维护性，避免仅追求代码量而忽视结构和设计。
第8章 需求分析
8.1 软件需求
1. 获取和引导需求（Elicitation）
软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。主要步骤包括：
-
需求获取：
- 识别利益相关者：用户、客户、市场分析师、监管机构、技术团队等。
- 理解需求：不仅包括用户明确表达的需求，还包括潜在需求和间接需求。
- 需求捕捉：通过交流、实验、快速原型等方法发现和捕捉需求。
-
需求引导：
- 用户可能不了解自己的确切需求，团队需要通过同理心和洞察力，替用户着想，挖掘深层次需求。
- 分析技术趋势、产业变化和社会发展，推测用户可能产生的新需求。
-
需求来源：
- 用户：直接使用软件的人，不同类型的用户可能有不同的需求。
- 技术趋势：如GPS技术、地理信息系统、智能手机性能提升等。
- 管理机构：需符合行业和政策规定，如内容管理、敏感词屏蔽等。
- 软件企业自身：商业模式的需求，如广告支持、用户分级收费等。
- 技术团队：代码迁移、架构演化、平台变更、新技术引入等。
2. 分析和定义需求（Analysis & Specification）
- 需求规整：整理从各方面获取的需求，定义需求的内涵。
- 量化需求：
- 实现的最后期限。
- 实现需求所需的时间和资源成本。
- 不同需求的优先级。
- 需求带来的收益等。
3. 验证需求（Validation）
- 与利益相关者沟通：通过分析报告、技术原型、用户调查或演示等形式，验证团队对需求的理解是否准确。
4. 需求管理（Management）
- 需求变化管理：在软件生命周期中，需求可能会变化，技术会发展，团队成员的能力也会提升。需持续审查和调整需求，以适应这些变化。
需求的类型
- 功能性需求：软件必须实现的具体功能。例如，学校选课软件的权限管理、先修课要求等。
- 开发过程需求：对开发流程的约束，如文档生成、代码规范、安全性检查等。
- 非功能性需求（服务质量需求）：如性能要求、并发用户数、安全性等。
- 综合需求：涉及多个系统或部门的复杂需求，如“购物网站必须在24小时内发送货物”，需协调软件系统、物流系统等多个部分。
8.2 软件产品的利益相关者
主要利益相关者
-
用户（User / End-User）：
- 直接使用软件系统的人，可能有多种不同的用户群体。
- 例如，打车软件的用户包括出租车司机、顾客和监管方。
-
顾客（Customer / Client）：
- 购买或委托软件的人，不一定是直接用户。
- 例如，购买英语学习软件的家长，或企业决定使用某款软件的管理人员。
-
市场分析师（Market Analyst）：
- 代表典型用户的需求，帮助定义市场导向的需求。
-
监管机构（Regulatory Bodies）：
- 确保软件符合行业和政策规定，尤其在金融、公共交通等行业。
-
软件工程师（Software Engineers）：
- 关注技术约束和特性对开发效率、难度及维护性的影响。
- 需要参与需求阶段，提出技术性的需求和意见。
8.3 获取用户需求——用户调查
软件开发过程中，需求从“用户最需要的东西”传递到最终用户，但在传递过程中可能会出现扭曲或丢失。为了确保需求准确传达，可以采用以下用户调研方法：
1. 焦点小组（Focus Group）
-
方法：
- 找到一群目标用户代表，加上项目的利益相关者进行讨论。
- 讨论用户想要什么，用户对软件的评价等。
-
优缺点：
- 优点：快速获取多样化的意见。
- 缺点：
- 群体压力，参与者可能为了讨好他人而避免表达不同意见。
- 善于表达的人可能主导讨论。
- 受主持人影响，可能出现偏见。
- 对于不熟悉的领域，参与者难以提供有价值的意见。
2. 深入面谈（In-depth Interview）
-
方法：
- 一对一详细访谈，广泛而深入地了解用户背景、心理和需求。
- 可用于软件可用性研究（Usability Study），观察用户使用软件时的行为和困难。
-
优缺点：
- 优点：获取深层次的需求和反馈。
- 缺点：费时费力，效果依赖于面谈者的能力。
3. 卡片分类（Card Sorting）
-
方法：
- 将需求制作成小卡片，通过讨论、归类和排序，理清需求结构。
- 有助于定义信息架构、用户工作流程、菜单结构等。
-
用途：
- 统一团队对软件需求的认识，量化特性，定义信息架构和用户路径。
4. 用户调查问卷（User Survey）
-
方法：
- 向用户提供预先设计的问题，让用户回答。
- 可采用开放式问题、二项选择题、多项选择题和顺位选择题。
-
常见错误：
- 问题定义不准确，导致用户困惑。
- 使用含糊不清的描述，如“最近”、“经常”等。
- 让用户花费额外努力回答复杂问题。
- 问题带有引导性，影响用户真实反馈。
- 涉及用户隐私或敏感信息。
5. 用户日志研究（User Diary Study）
-
方法：
- 用户记录自己日常工作或生活中与软件相关的行为。
- 可采用日记体文字描述、每日填表或使用软件跟踪。
-
优缺点：
- 优点：长期数据收集，提供详细的使用行为记录。
- 缺点：用户需具备高自律能力，隐私保护问题。
6. 人类学调查（Ethnographic Study）
-
方法：
- 深入用户生活环境，体验用户的日常活动，获取真实需求。
- 例如，与目标用户“同吃同住同劳动”，了解他们的真实需求和痛点。
-
示例：
- 《社交网络》（The Social Network）中，功能设计基于深入了解用户需求的场景。
7. 眼动跟踪研究（Eye Tracking）
- 方法：
- 分析用户在界面上的视觉行为，了解信息布局和用户注意力分布。
- 常见的用户浏览模式如F模式，指导信息和功能的布局优化。
8. 快速原型调研（Quick Prototype）
- 方法：
- 使用纸张模型或简单原型快速获取用户反馈。
- 例如，Palm Pilot早期设计通过实物原型获取用户反馈。
9. A/B测试（A/B Testing）
-
方法：
- 决定试验的UI版本和衡量标准。
- 技术上实现A/B测试，通常在5%-10%的用户上运行试验。
- 收集数据，分析数据，形成结论。
-
优缺点：
- 优点：基于现有用户数据做出决策。
- 缺点：
- 运行成本高，增加运维复杂度。
- 只能看到用户行为，无法捕捉情绪反应。
- 需分清因果关系，避免数据误导。
- 可能引起用户流失。
8.4 竞争性需求分析的框架
NABCD模型
-
N（Need，需求）
- 明确解决用户的具体需求和痛点。
- 充分了解用户的痛苦和不满意之处，挖掘未被满足的需求。
-
A（Approach，做法）
- 提出独特的解决方案或方法，涵盖技术、商业模式、地域优势等。
- 不仅限于技术能力，还包括商业模式、人脉、成本优势等。
-
B（Benefit，好处）
- 展示产品或服务带给用户的具体好处。
- 考虑用户迁移成本，确保用户愿意为新产品付出代价。
-
C（Competitors，竞争）
- 分析竞争对手，了解市场现状及竞争优势。
- 识别我方产品的优势和劣势，确保差异化。
-
D（Delivery，推广）
- 制定如何将产品交付给用户的策略，包括推广渠道和方法。
- 确保产品能够有效到达目标用户，获得市场认可。
功能的定位和优先级
- 四象限方法：
- 杀手功能（Core）：核心功能，具有差异化优势，能够吸引用户。
- 外围功能（Context）：辅助性功能，提升用户体验但非核心。
- 必要需求（Mission Critical）：必须满足的需求，产品入门的基本要求。
- 辅助需求（Enabling）：提升用户满意度的需求，非决定性因素。
- 资源分配方法：
- 维持：以最低成本维持功能。
- 抵消：达到“足够好”，与竞争对手持平。
- 优化：花大力气保持行业最好。
- 差异化：产生独特优势，与竞争对手区分开来。
- 不做：砍掉不必要的功能，避免资源浪费。
示例：英汉词典软件
- 杀手功能：OCR文字识别技术，拥有独家权威词典。
- 外围功能：良好的界面设计，跨平台运行。
- 必要需求：单词释义的准确性。
- 辅助需求：支持多种皮肤，提升用户体验。
8.5 计划和估计
8.6 计划和估计
8.6.1 估计的练习
-
目标、估计和决心的区分
- 目标：希望达到的状态。
- 估计：预测实现目标所需的时间和资源。
- 决心：保证在特定时间内完成任务。
-
估计方法：
- Wide-band Delphi方法：通过多轮讨论和假设澄清，达成团队一致的估计。
- 工作分解结构（WBS，Work Breakdown Structure）：将项目分解为可管理的小任务。
-
估计的实践与经验：
- 经验公式：实际时间花费依赖于估计时间和完成类似任务的经验次数。
- 学习与调整：通过项目里程碑和反馈，不断优化估计精度，提升团队的估计能力。
8.7 分而治之（Work Breakdown Structure）
-
WBS方法：
- 从最终产品开始，逐层分解为小型、具体的交付件。
- 确保覆盖全部内容，避免子节点相互覆盖。
- 叶子节点应足够小，便于在里程碑内完成。
-
WBS要点：
- 覆盖全部内容：确保所有子节点覆盖父节点包含的内容。
- 避免子节点覆盖：各子节点之间不重叠。
- 足够小的叶子节点：叶子节点的工作量通常不超过两周。
- 从结果出发：构建WBS时从交付成果出发，而非从团队的活动出发。
-
常见问题与解答：
- 文档是否包含在WBS中：如果文档是可交付给客户的，或开发团队需掌控其花费，则包含在WBS中；否则可作为项目管理的一部分。
- 开发活动如何算入WBS中：WBS描述交付的成果，不包含具体开发活动。开发活动可使用项目管理工具描述，如TFS中的工作项。
- 细枝末节的处理：不必单列细节，可归属于较大的任务。最终目标是开发出产品，而非产生详细清单。
- 非具体交付成果的处理：如技术研讨，可视情况作为交付成果，需有数据支持或相关报告。
8.8 练习与讨论
8.8.1 画扇面——调侃目标和远景
-
案例比较：
- 成功案例：Linux刚开始时的目标是“一个免费的操作系统”，并逐步发展。
- 失败案例：过于宏大的目标导致项目失败，如“大跃进”中的钢铁产量目标。
-
关键点：
- 解决小问题，逐步积累成功。
- 避免盲目追求大目标而忽视实际需求。
总结与启发
-
全面发展：
- 不仅要提升编程技能，还要注重沟通、协作和自我管理能力。
-
重视实际成果：
- 通过参与项目、积累经验和获得实际成果来证明自己的能力，而不仅仅依赖于认证和考试。
-
持续学习：
- 软件工程是一个不断变化的领域，保持学习的热情和适应新技术的能力至关重要。
-
团队合作：
- 理解团队流程，善于管理和利用团队中的不同意见，提升整体效率和成果。
-
质量优先：
- 注重代码质量和软件的可维护性，避免仅追求代码量而忽视结构和设计。
