Project-Management

前言在利用Git管理团队代码的时候，都会涉及到如何管理分支，如何发布版本的问题。如果能够制定一套统一的规则，就能够有效的保障团队的开发流程和效率。如下流程主要参考自 A successful Git branching model 进行的一个设计。能够确保各个分支的合理使用，以及发布版本的管理。此外，以下介绍的流程没有涉及到Pull Request 相关的操作，为的是能够快速地将每个开发的代码合并到主要分支，如果希望添加 Pull Request 的流程，可以在功能分支合并到开发分支中添加。 流程详细见: 中文：介绍一个成功的 Git 分支模型 英文：A successful Git branching model 主分支（长期分支） master 可执行版本记录分支，上面的每个节点都是发布到线上的一个版本，具体的版本号由tag确定develop 代码开发分支，所有开发辅助分支（短期分支） feature 详细功能分支，每个功能分支应该尽可能的小（最好一天以内），开发完成之后尽快移入仓库中release 测试版本发布分支，同时接收该版本的bugfix，直到稳定之后再发布到master，并合并到develop中。hotfix 紧急修复线上bug分支，直接从master的版本分出，同时最小版本号加1。修复完成后发布一个最新版本，同时合并到develop中。版本发布分支： master可执行版本记录分支，上面的每个节点都是发布到线上的一个版本，具体的版本号由tag确定 命名规范master是一条长期分支，仅有master这个名字。 commit note直接表示merge:Merge branch 'release/v1.0.1' 表示版本升级Bump version to v1.1.1 建议使用第二种，因为不想gitlab, github上的节点并不能看到tag，所有只能通过commit note来进行识别，而第二种可以清楚地表达出版本的变化的意思，而不是第一种的git操作。 注意 代码合并的时候，请务必使用 git merge --no-ff <branch-name> 这样会是分支的节点更加清晰，分支中才不会有无关的commit node，特别是对master分支极为重要。方便对代码的review，可以很清楚地知道这个功能修改了那些内容方便出错的时候进行回退，只需要回退一个节点接口完成代码的回退在代码发生冲突的时候，git会为我们创建一个节点，也就是平时看到的“Merge”信息的节点。但如果被合并的代码超前于目标分支，git就会将所有的节点都合并到目标分支中，而不是生成一个新的节点再合并。这对于master分支简直就是灾难，因为release分支或者hotfix分支必然是超前于master分支的。Tag操作每个tag即表示一个版本，也就是合并一个分支到master都需要打一个tag。 # git tag v1.2.3 #你可以省略对这个tag的说明git tag -a v1.2.3 -m "This is comment" [<commit-id>]git push origin v1.2.3[参考] 廖雪峰的官方网站-创建标签 廖雪峰的官方网站-操作标签 ...

欢迎关注我的公众号睿Talk，获取我最新的文章：一、前言年前公司组织了一次项目管理培训，激活了几年前考 PMP 的一些回忆。结合这两年来项目管理的实战经验，又有很多新的体会，这就是所谓的温故知新吧。学习过程中的一些想法总结成这篇文章，等有了新的感悟再继续扩展。二、人不能闲着培训开始前来了个热身思考题，题目如下：有拖地、擦窗和切菜 3 个任务，每个任务需要一个人 30 分钟的工作量。每个任务只有唯一的工具（拖把、抹布、刀），2 个人完成这 3 个任务最短需要多少时间。这个题目的关键是要把任务进行合理的拆分，让 2 个人都有事做，不能有一人闲下来。解题思路比较简单，每个 30 分钟的任务都拆成 2 个 15 分钟的子任务，然后将任务分成 3 组，每组 15 分钟 2 个并行进行的任务。所以最短时间是 45 分钟。这个题目的场景在真实项目中也经常遇到，抽象来说就是在确定的项目范围和人员的情况下，如何更快的完成项目。以年前的一个项目为例，投入了 3 个前端小伙伴进行开发，估时的时候发现项目的最长路径在前端，而且其中一个人的工作量明显比其他 2 人多出一截。也就是说到项目后期，就一个人在忙，其他人都闲着了。解决方法跟这个题目的解题思路类似，就是将任务拆细，然后分给另外的 2 人，最终计划的完成时间也随之缩短了 2 天。这种方法虽然能缩短计划工期，但在执行阶段可能出现其它问题，比如分出去的工作别人可能没那么熟悉，协作的时候需要更多的沟通。代码质量也可能会降低，出现更多的 bug。这些风险都要提前识别出来，然后制定相应的应对计划。三、目标管理课程开始的时候提出了一个引子：西游记 4 师徒的目标是什么？很多人都不假思索的说是到西天拜佛求经。唐僧自己在化缘和借宿的时候不也是这么说的吗？但这是真正的目标吗？显然不是。这个项目的真正目标应该是普度众生，拜佛求经只是一种方式，或者说是一个重要的里程碑。再细想一下，其实师徒 4 人每个人的目标都是不一样的，孙悟空只想从五指山下出来，八戒就是个贪图美色没有目标的吃货，而沙僧只想混点资历好日后升官。目标管理对一个项目的成败有重要的影响，如果能将项目成员的个人目标跟项目目标统一起来，就能最大限度的激发他们的主观能动性，推动项目的顺利进行。还是以年前的项目为例子，产品的目标是上线新功能以满足商家的需求，客户成功的目标是提高商家的日活，而技术的目标是满足需求的基础上完成代码重构，方便代码日后的维护。要达成每个项目干系人的目标，需要前期不断的调频、协商，某些情况下为了达成项目目标需要某些人的妥协，比如工期太紧就下次再重构。把目标管理的工作做好了，在执行阶段会起到事半功倍的效果。四、期望管理接着我们就分组进行主题为婚礼的项目规划，有多个限制条件，其中一个是丈母娘要满意。在着手制定方案的时候，我们组内一直在猜想丈母娘的需求是什么，怎么样的婚礼是她想要的，没有一个人提出说要跟丈母娘聊聊，听听她的意见。这其实是项目管理的一个大忌。对重要的项目干系人，一定要事先做好沟通，了解需求，并根据项目的客观情况来管理他们的期望。如果期望没管理好，最终的结果很可能是辛辛苦苦把项目完成了，自我感觉不错，但干系人却并不满意。之前就做过一个项目，下了死命令一定要在某天发布。过程中费了好大的力气，连续加班将近一个月，项目终于如期上线了。就在小伙伴们以为可以松一口气的时候，收到了客户们如潮水般的吐槽。由于新版变化很大，并且是一个高频的功能，客户已有的操作习惯完全被打破，客户成功疲于应付各种质问，无论对内还是对外都产生了不良的影响。现在回想起来，其实就是没对终端用户这群重要干系人做好期望管理。如果在项目发布前一周甚至是前一天，提前跟他们做好沟通，预告接下来将发生的变化和提供一些新版操作的指引，相信会有完全不一样的结果。五、领导力在聊项目经理技能树的时候，主要有 3 个要求：项目管理知识领导力业务知识其中我对领导力的感悟比较深。课堂上放了《可复制的领导力》视频，当中说到领导的核心驱动是尊敬和信任。一个人的领导力是否强大主要看能否做到以下几方面：树立共同的目标，给员工以目标感和价值感有清晰明确的规则及时反馈自愿参与，帮助员工成长布置任务的时候，最好做到 5 个来回的沟通：第一遍，交代清楚事项；第二遍，要求员工复述；第三遍，和员工探讨此事项的目的；第四遍，做应急预案；第五遍，要求员工提出个人见解；这颠覆了我对领导力的认识，我以前认为一个领导力强的人必须能说会道，见多识广。但这些其实只是一些表面功夫，要提高自己的领导力，更需要深入到做事的细节当中。六、目标驱动在项目启动的时候，要先跟项目成员阐述项目的目标是什么，来源在哪里，解决什么问题。这部分可能花的时间不多，但对项目的顺利执行是很有益处的。描述得越具体，细节越丰富，作用就越大。最好让大家都能切身感受到痛点，从而激发大家改进的愿望。在我们公司业务发展的早期，需求下来后只是着重讲解功能点是什么，并没有同步为什么要做这个，背后的产品逻辑是怎样的。结果就是大家都很被动的去完成功能，做得到底好不好，没有一个评判标准。随着业务的发展和项目管理经验的积累，这一问题得到了改善。产品经理在需求沟通的时候会先介绍做了哪些调研，哪些客户提出了需求，没这个功能对他们来说有多不方便。在了解这些背景资料后，往往会激发大家的目标感和使命感，更积极主动的去推进项目。迭代上线后，也可以聆听客户的反馈，形成一个完美的闭环。七、透明、检视、调整在敏捷项目的体系里面，看板是一个十分重要的存在。通过在看版上面罗列需求和展示对应的状态，可以让项目干系人很直观的看到需求所处的阶段和完成的情况，以透明的方式达到信息同步与鞭策的作用。每天站会的时候，可以提前更新任务的状态，方便大家去检视项目的健康状况。当有需求变更或计划调整的时候，也可以直接反映到看版上，可谓一举多得。八、团队五阶段团队的生命周期会经历 5 个阶段，它们是：形成阶段。在本阶段，团队成员相互认识，并了解项目情况及他们在项目中的正式角色与职责。团队成员倾向于相互独立，不一定开诚布公。震荡阶段。在本阶段，团队开始从事项目工作，制定技术决策和讨论项目管理方法。如果团队成员不能用合作和开放的态度对待不同观点和意见，团队环境可能变得事与愿违。规范阶段。在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员开始相互信任。成熟阶段。进入这一阶段后，团队就像一个组织有序的单位那样工作。团队成员之间相互依靠，平稳高效地解决问题。解散阶段。团队完成所有工作，团队成员离开项目。最近一年多我就完整的经历了这 5 个阶段，上面的总结都非常到位，深有体会。随着业务的发展，原有团队完成历史使命，解散后又成立一个新的团队。目前正处于团队形成的阶段，共同去完成新的挑战。九、5 Why当项目出现问题的时候，可以用 5 Why 这个思维工具来找到根本原因。凡事多问几个为什么，会得到意想不到的收获。比如：项目为什么会延期？因为开发时间太短了。为什么开发时间短？因为开发过程中遇到了意想不到的问题。为什么会遇到意想不到的问题？技术设计的时候想得不够详细。为什么技术设计的时候想得不够详细？主观觉得这个需求很简单，没必要做详细的设计。为什么简单的需求会遇到意想不到的问题？因为对代码不熟悉。…通过这么一层一层的刨根问底，对问题的认识会更深刻，制定出的改进方案会更有效。十、项目管理铁三角范围、成本和时间构成项目管理的铁三角，而项目质量跟三方都有密切关系，任何一方的变动都会对另外几方面产生影响。比如：范围确定的情况下，要缩短项目时间，就必须投入更多的资源，成本也随之上升。如果要缩短项目时间，但成本不变，就必须调整项目范围，也就是所谓的砍需求。当项目进行的过程中，如果有需求变更，范围扩大了，人员不变的情况下就需要增加时间。十一、总结以上就是这次课程的一些感悟，也是真实项目中给我的切身体会。项目管理其实就是一套方法论和工具体系，它不但可以在工作中发挥作用，还可以应用到日常生活之中，通过周密的计划，对人、事、物做好管理，从而取得满意的结果。