背景
本文的灵感来自于看了极客时间的《软件工程之美》，其中的内容主要介绍了几种软件工程开发模型，例如最出名的瀑布模型，同时着重介绍了敏捷开发以及一些项目管理的心得。阅读期间，我对比自己在项目管理中的落实方式，引发的种种反思……
在这一年中，由于团队以应届生为主需要，引导的内容较多，所以我绞尽脑汁在不断思考的一个问题就是，怎么样能够调动大家的一个积极性，同时制定一个相对完善的有所依仗的流程，让组员在遇到突发情况，而我又无法抽身的情况下，有相关的内容可以指导其相关的应对方式。由一个“人治”不断向“法治”过渡……
本文将针对我有感悟的点进行记录，并结合我实际的案例
重新认识软件工程
在大学以及初步步入工作的几年，我对《软件工程》的理解就只停留在一个假大空的概念上；觉得是一些虚无缥缈的概念，但是当工作要求要逐步去把控整个项目进度，遇到了各种难以郁闷无语的事件；此时，我突然意识到，也许这些问题答案就在曾经的那些“虚无缥缈”的概念中……
软件过程不是搞科研，不是搞艺术，而是解决多人合作将一个想法落地的学科，其中包括严谨的过程步骤、规范，用于提高效率或防范风险的工具。
软件工程的主体是工程，这就要求我们具备基本的工程思维：模块化思维、抽象思维；具备一些关键的意识：质量意识、风险意识、交付意识。
这是摘取《软件工程之美》中一段评论，但是我感觉，是一个较为 准确的描述，同时也是我当下应该具备的基本素养！
其中，对工程中的描述：
模块化思维、抽象思维
让我一下子想到想到我们在项目管理中遇到的最普遍的一件事，接到新需求，遇到的以下一系列问题：
- 这个需求在实际落地中，我们应该划分到哪个系统，哪个模块？
- 有没有什么类似的场景，我们能够一并处理掉？
举例1：
在我们的财务系统团队，接到这样一个需求：我们售卖的商品要进行开票，而开票有一个要求是每个商品都有对应的税率，税务编码，税务明细描述，目前商品信息在我们的进销存系统进行维护；而这些财务信息该放到哪里维护？
a.)应该放到进销存系统去维护，基础资料应该都集中在一起，方便统一维护，统一添加修改
b.)应该放到财务系统维护，不同的系统操作的相关部门人员是不同的；所以业务同学都希望，我们在进销存系统只由供应链的同学去维护，而财务同学应该去财务系统维护财务相关的内容
目前，我们坚持了方案 a 从技术实现上和后期管理上，我们更倾向于在一个系统将基础资料全部一次性获取到，同时保证我们在新的商品信息添加，或者有信息修改时，我们能够利用一些系统层面的保护保证其一定会把财务相关信息补充到位，而这就是模块划分上遇到的一个很明显的问题。
举例2：
我们今年踩坑的比较多的另一个重灾区是账单调整功能，一个功能改了4次，纠其原因就在于我们初期对系统的用户故事的理解不够深刻，而一般的业务同学也无法完整的列出所有业务场景，此时我们的开发工作就变成了追着需求跑。
具体的其实需求，其实很简单，业务同学希望可以把自身产生的账单与企业生成的账单订单号对齐；可现实中会存在，门店员工订单信息录入较晚，或者客户将订单划分到了下一个月份，如此便需要应对两种情况
除了未来要挖掘需求更深外，其实另一点就在于，我们要抽象这一类问题；针对这一类的情况，都能够得以处理，否则始终就处在一个追着需求跑的状态！
迭代模型 vs 敏捷开发
在开始这个部分的讨论，先列举几个其他的
快速原型模型： 较为抛弃质量的做法，一般用于快速确认需求，在实际甲方公式较为少见，不多讨论
瀑布模型： 目前不适用现在甲方的公司开发，周期较长没法及时响应需求
增量模型: 分模块持续交付给客户，但不适用已经上线持续维护的项目，例如：有多个模块的小改动
迭代模型 与 敏捷开发的不同
迭代模型 固定时间周期，在固定的周期内选择适合的需求开发任务和Bug修复任务去完成，按时发布。其中的内容流程还是按照固定的
敏捷开发 而敏捷开发的不同在于没有固定哪个阶段在做哪件事情，时刻践行交付，同时交付后利用cd/ci以及人工测试快速上线，而产品不会去完整书写完prd，经过一段时间再交付开发，而是新建任务，交代清楚用户故事，将每个用户故事建立一个任务，将相关的用户故事放到一个sprint中
实际团队分析
我们有的：
1.开始制定对应sprint，放每期的需求
2.会利用backlog添加新的需求
3.有基本的cd/ci流程
4.有基本的站会
我们没有的：
1.组员还不足以，完全自身独立对接需求，了解用户故事
2.敏捷快速开发需要有一定比例的自动化测试规模，保证测试团队在cd,ci流程快速交付任务，快速进入上线流程，测试时间不会花费过久
3.测试资源还不足以独享，保证随时提测；随时对相关功能开测
4.自动化流程覆盖面还较低
后续：
1.先加强自动化测试覆盖率
2.将单元测试加入cd/ci
3.更新JIRa状态，考虑设计为自动化
我有写过一个小脚本，在CI里面运行，PR merge或者部署测试环境都自动更新，PR里面标题加上Ticket编号就可以。又酷又省心
4.目前晨会只有过任务进度环节和检查最新JIRA环节；应该加一个停车场问题环节
过程中很容易偏离主题，比如突然有人提了一句：“我们好久没团建了，是不是该出去玩玩了。”很可能大家都很high的讨论起来了，这时候会议主持者要及时打断，记录到“问题停车场”，让下一个人继续，先保证大家能高效完成这一环节。
问题停车场（Parking lot question），把需要进一步讨论的问题临时放到这里，一会儿再讨论。
5.部署时间尽量放到周三前，保证上线前几天能快速响应修复问题
6.及时的小型复盘会
软件项目管理金三角
在现实生活中，我们都知道，做产品想“多、快、好、省”都占着，是不可能的，最多只能选两样。想要便宜和质量好，就要花时间等；想要快还要质量好，那就得多花钱；想要又便宜又快，那就得接受难用、质量差。
一般我们发生了有紧急的需求，在一个sprint有紧急的需求，为了软件整体的质量，就应该该考虑减少一些相对不重要的需求；保证整体项目的质量。
可行性分析
经济可行性：从成本和收益角度分析，看投入产出比。不仅要分析短期利益，还要分析长期利益，看是不是值得做。
技术可行性：软件项目最终是需要人通过技术来实现的，所以要分析技术上是不是可行，如果有技术上解决不了的问题又能否规避。
社会可行性：社会可行性涉及法律、道德、社会影响等社会因素。比如，触犯国家法律的事情肯定不能做；产品如若不符合道德标准，可能带来较大的社会负面影响，那么也要慎重考虑
技术转管理
对于项目成员的管理，不需要过多依赖人的管理，否则项目经理就会成为项目管理的瓶颈。所以更多要落实到流程和工具上。
这句话是我比较有感悟的一个点，之前比较不理解感觉有时人为不管理，全部想办法找工具是一种管理的懈怠；但是实际上，随着设计的规范条款和管理的人等越来越多，人为管理的成本越来越高
1.制定计划
2.对计划跟踪控制，做好风险管理
经验教训
- 控制写代码的冲动
以前很多时候，我都会想自己的去直接将代码改掉，直接按自己的想法去调整；但是实际上，这样的后果就是，遇到问题，只能来找我，其他开发根本无法解决相关问题
比如说在项目进度吃紧的时候，你可能第一想法就是自己去写代码帮助团队赶上进度。
但是，你要知道，当你转型管理后，你的主要职责就管理，而不是写程序。如果你还是把大部分时间用在写程序上，那么你就很容易忽略项目中的问题。比如没有去关注项目的进展、目前项目的瓶颈、和客户以及其他项目组之间的沟通协调等。
帮助下属的成长，才可以让自己释放出更多的精力去做更有意义的事情。
我刚转型做管理的时候，问过老板一个问题：“是不是我把上级的工作做了，我就能升职了？”老板的回答很出乎我意料：“并不是你把上级的工作做了就能升职，而是你的下级都成长了，能替代你的位置了，你就可以升职了。”
这让我明白一个道理：作为一个管理者，团队的成功，才是你的成功。做程序员的时候，把代码写好就很成功了，但是转型做管理后，团队的成功和项目的成功，才是你的成功。
项目评估
-
任务分解，一般大的项目不适合去评估时间，但是一旦我们把任务拆解到一定的程度；那么评估的难度就简单了很多
-
估算时间，建议一定要开发人员参与到估算时间；保证估算时间时，消除我们的项目管理和开发的隔阂
-
排布任务优先级，可以利用甘特图排布依赖情况，以及任务平行进行情况
我们今年在做saas系统时，就缺乏一个统筹的甘特图，总是出现一个等一个的情况，那么整个情况就会非常混乱，任务出现重叠的情况，只能铜鼓加班解决相应的问题
- 如果是大型长期的项目，设立里程碑
这个是我今天体会比较明显的一点，在saas和我自己的员工考核kpi的系统中，整个重构的期限基本都是跨度在两个月左右的；那么此时我们的很容易陷入一种前松后紧的情况
- 项目的追踪和跟踪，除了站会外；要更多的利用看板，查看用户的情况
流程和规范
流程规范的作用：个体降低效率，提升团队效率；类似我们的交通灯一样
- 将好的实践标准化流程化，让大家可以共享经验
- 借助流程规范，让项目管理从人治到“法治” 如果规范和流程足够清晰，能够保证整个在无论成员如何替换的情况下，依旧能保证项目良好的完成
制定好的规范
-
从问题出发，以特定问题推导出解决方案；根据解决方案，推导出是否有类似的问题，可以一并解决
- 制定后，努力推广并且添加好对应的奖惩机制
- 借助工具将流程固定下来
什么样的会议是有意义？
先要把“开会是有成本的”这个意识树立起来，如果人数特别多的会议；则成本是更加的高
无价值的会
- 没有目标的会议。大家都在随意发散，完全没有主题；
- 不能形成决策，没有会后行动。如果一场会议看完后都没有什么结果，那跟没开都没啥差别；
- 你属于可有可无的角色。如果一个会议，跟你其实没什么关系，你无法提供有效的反馈，对你也没什么价值，只不过是被人拉过去开会的，那不如把这个时间用来做一点对项目更有价值的事。
减少参会人，降低开会成本
减少人数好处还在于，人一少，每个人都会更投入，也更有效率，所以往往时间反而会少产出会高。而且，如果会议上要形成一些决议，人越多越难做决策，人越少越容易达成一致。
项目管理工具：一切管理问题，都应思考能否通过工具解决
一切管理问题，都应思考能否通过工具或技术解决，如果当前工具或技术无法解决，暂时由流程规范代替，同时不停止寻找工具和技术。
感悟： 以前的误区，在于我认为应该着重用制定流程规范；同时应该人员上添加很多的监督，保证整个流程是完整，没有问题的；但是，实际上我自己忽略了很重要的一点在于，我们的工具才是最可靠的，而人为的管理，会造成人员的培训，等等一系列的问题的出现；如果人员离职，很多时候这种类似的事情还会反复发生
一个jira应该有的信息
那一个Ticket应该包含哪些主要信息呢？
一个Ticket，应该包含：
标题：摘要性的描述Ticket内容；
类型：属于什么类型的Ticket：Bug、需求、任务；
内容：Ticket的详细内容，例如，如果是Bug的话，除了要写清楚Bug内容，还需要重现步骤。如果是需求的话，要有需求的描述，可能还需要额外的文档链接辅助说明；
创建人：谁创建的这条Ticket；
优先级：这个Ticket的优先级高还是低；
状态：Ticket的状态，例如：未开始、处理中、已解决、重新打开、关闭等；
指派给谁：这个Ticket被指派给谁了，谁来负责；
历史记录：整个Ticket改变的历史信息，用以跟踪；
当然除了这些外，还有一些其他信息，例如创建时间、附件、标签、版本等。另外现在的Ticket跟踪软件都有强大的定制功能，可以增加额外的辅助信息，例如你是基于敏捷开发，还可以加上Sprint、故事分数等信息
利用可视化看板，确定哪些任务已经完成；哪些任务没有完成
总结
这么几年的开发下来，给我最大的感受就是；很多工作的疑惑，与其自己无脑处处碰壁，不如去自己重拾一下当年自己抛弃的理论书籍，得救之道，就在其中。
