软件开发流程
软件开发流程/生命周期
软件生命周期
软件定义（需求讨论确定、原型效果图制作）、开发实施、测试与bug修复、上线、服务与更新、停服。
以我当前的经验或者认知，软件服务公司给别人做产品的具体流程大致应该是这这样的：
-
需求分析阶段（第一版功能、不可缺少的必要功能）。//沟通，与确定。考虑产出需求文档让客户签字确认。
-
仿真原型的设计制作。方便展示大致的界面和交互效果。
- 原型通知到领导并交由客户进行查看复审（该有的功能是否都有体现，有没有漏的，有没有明显不需要的或者流程错误的），然后提出修改意见。
- 技术人员有选择的修改原型并跟用户达成共识顺便通知领导。
- 原型最终确认并可以同时开始数据库表规划，技术方案设计。
-
效果图设计与确定，即软件界面的定义。
用户确认效果图或提出修改意见（仅涉及元素显示效果变动，如果涉及功能的修改添加请和老板沟通）
-
开发阶段
-
内部公测阶段。
- 内部测试后，再与客户共同体验测试。
- 对发现和提出的问题进行修改优化再测试。
-
宣布正式开服，开始服务。
-
维护、迭代
-
停止更新
-
停止服务
以上，最重要的是多和客户沟通，有选择地遵从客户意愿，原型/效果图，在经过前后端技术人员确认后，必须让客户看到，确认达成共识以便有共同的产品期望。
1、人们为了解决现实社会和生活中的各种问题，要求助于软件。软件开发团队为了做出能解决问题方便他人的软件，则需要了解人们的需求。
2、软件团队和客户代表要在需求阶段，要把需求的方方面面定义清楚，不出现模棱两可的情况，起码要清楚软件必须实现哪些功能。
3、软件开发前，必须要弄清楚：软件的相关角色想从软件中得到什么。
4、软件开发的过程，就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程：
5、与其坐在办公室里想象如何给老年人设计手机，不如去和老年人生活几天，从生活中得到体会和需求。开发人员自己开发的产品一定要在产品上线后，自己在实际环境中，作为一名普通用户亲身体验一把，这样也许就能发现许多待优化的地方，或者别的什么新发现。
6、不要让用户在各种菜单中幽幽暗暗反反复复地寻找某个功能，软件界面的目标之一是让用户在使用中“平平淡淡从从容容才是真”。
7、大众浏览网页时的眼球移动轨迹或叫视野专注区域变动轨迹：F模式。
参见：
https://baike.baidu.com/item/F形状网页浏览模式/15686166?fr=aladdin原文：https://www.zdnet.com/article/eye-tracking-web-usability/
软件产品的原型
原型反应了产品能做什么、不做什么，页面元素显示什么、不显示什么，具体某一功能上的交互逻辑或顺序是怎么的；这是最直观形象的“需求文档”展现形式。
原型和效果图都是对软件产品未来样子的描述表达。通常原型可以不那么逼真，只是页面展示信息和交互的大概模拟，效果图即产品最终的样子。软件产品比较简单的话，原型这一步非必须，可以直接由需求文档，制作效果图。
常用的原型制作工具：墨刀。
在需求沟通确立阶段，需要大伙儿一起明确需求、交换意见、希望各方对目标产品达成统一的认识与期待。但这只是口头或者脑袋里交换意见达成一致，太过抽象，而且交流过程中，每个人脑子里对所讨论东西的想象，很可能与对方表达出来的东西、或者已经商量好的共识是有较大差距的，因此，有必要将这些抽象反映到实实在在的可视化原型上。
有了她，大家就能更清晰直观的认识到需求在软件产品上到底是怎么体现的，因为是唯一可视化的。又或者发现跟自己想象的有什么不一样的地方，或者发现自己或者别人有漏洞的地方，进而促进团队之间达成更进一步的统一。如果产品功能简单，界面内容并没什么复杂的，也许一个对大家共识的记录文档或者思维导图就OK了。即使需要原型，这些文档或者思维导图也是必要的，起码能起到备忘或者说原型出来前的再次讨论记录不是吗？
软件产品的界面设计，即制作效果图
效果图即产品最终的样子。前端开发人员严格依此来进行工作。
效果图制作就是在这个软件产品原型的基础上打造用户视觉体验，如背景色，按钮大小形状，文字大小颜色等，即在“显示什么，不显示什么，做什么，不做什么”的限制内，发光发热，打造更优美、更流畅的用户视觉体验和交互体验。
原型出来后，必须由前后端人员审查确定、领导审阅、客户审阅通过后，再交给界面设计人员进行效果图设计。
效果图出来并经公司和客户确定后，前端就可以开始工作了。（后端可能要开始的更早）
效果图要保证没有没有数据或交互上走不通不合理的地方，如果原型不能导致后端正常开展工作，那项目经理和产品（或UI）之前的沟通工作需要质疑。
开发人员的个人流程
- 理解问题或任务
- 提出多种解决办法并估计工作量
- 其中包括寻找以前的解决方案，因为很多工作是重复性的 （模式）– 例如实现某些类似的web页面。
- 与相关角色交流解决问题的提案, 决定最终方案。
- 执行, 把想法变成实际中能工作的代码。
- 修复缺陷, 对结果负责。
团队有什么特征？
- 团队有一致的集体目标, 团队要一起完成这目标。
- 团队成员有各自的分工, 互相依赖合作, 共同完成任务。
在团队工作中, 稳定、一致的交付时间是衡量一个员工能力的重要方面。
PM
Product Manger：产品经理——正确的做产品。核心要求是，根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化问题。
Project Manage：项目经理——正确的做流程。对项目流程负责，即项目从立项到上线按时完成。正确的协调团队；内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划结项，是一个项目经理的核心价值。
Program Manger：微软的职位名称。微软产品团队三组鼎立的角色分配就是PM、开发、测试。PM做开发和测试之外的所有事情。PM要在整个项目的生命周期管理风险。PM经常和人、管理流程打交道，经常处理“不确定性”，在反复多次对“不确定性”进行处理的过程中，一个团长的风格和习惯就慢慢养成了。PM要有能够理解别人的处境、心理、动机的能力——同理心，能突然把自己变成一个完全不懂技术的菜鸟用户，从用户的角度来看问题。如果一定要说专业能力的话，PM的专业能力就是理解和表达。PM要能够分析出重点，找到优先级、做判断、做决定……PM 有一个任务就是：创建并维护软件的规格说明书，让它编程开发/测试人员及时准确的指导，而不是障碍。
PM的出现使得有专人负责开发/测试之外的许多事务和项目进度的管理，让开发和测试人员专注于技术方面的工作。总之，PM做开发和测试之外的所有事情。
项目的大小怎么统计呢？
我感觉用功能点比较好。//感觉功能点划分要尽可能小，小到很具体，具体到不能再拆分。
不用时间是因为，软件时间的估计，事实上是多个估计值的乘除法（估计的需求，估计的需求复杂度，估计的技术难度，估计的人员能力），如果这些估计都差一两个数量级，那么我们最终的结果就会偏离十万八千里。
论一个项目周期中的各种文档
需求文档
面向软件开发团队，以及软件最终所有者。不管什么文档类型，要能说明，开发的是什么，有什么功能，功能描述不要模棱两可，一定要清晰没有争议。
建议每个项目的需求文档，都保持最新的，持续维护的。不然一个老旧的需求文档，可能造成的问题，比如某天口头上，A主导定下了一个需求，B理解记忆的和C理解记忆的不一致，且当时以为都是一致的，那后期出现不一致，没有个公共的参考判定。这就导致可能又得各自回顾梳理一遍。又或者，开发完成后，测试时，发现有个功能和 “当初说好的” 不一致，但是【当初】的这个东西要是没个文档记录，这就很难受了。
软件功能说明书（functional spec）
面向软件用户（使用者）。主要用来说明软件的外部功能, 和用户的交互情况 (把软件当作一个黑盒子)。
从用户的角度描述软件产品的功能, 输入，输出，界面, 功能的边界问题, 功能的效率问题(对用户而言), 国际化, 本地化异常情况, 等; 不涉及软件内部的实现细节。
软件技术说明书/设计文档（technical spec/design doc)
面相开发运维人员。主要用来说明软件内部的设计 (把软件当作一个透明的箱子)。
数据库表结构说明文档
文档类型：.txt、markdown、pdf、doc，都行。
存在的意义或用处：
- 展示有那些table，即系统涉及的数据以及相关关系。
- 记录各数据表的结构即有哪些列名或属性，后续可以按此文档建立完整的数据库。
接口（API）文档
系统提供的用于获取数据，更新数据的接口。
文档类型不限，也可以是线上接口文档地址。
如何衡量一个软件工程师的专业水平？
绝大部分软件工程师的工作成果都是可以公开的，你参与的产品用户评价如何？市场占有率如何？对用户有多大价值？你在其中起来什么作用？行胜于言，这些实际的工作成果，是最重要的评价标准。
工程师应该在实际工作中不断学习和不断成长，根据自己的情况选择在哪个方面追求“专和精”，在哪几个方面达到“知道就好”的水平。
那么怎样提高技能呢？答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。
部分摘录自：《构建之法》
更新于：2023.5.26
