Gitlab 项目管理原创

大家好，我是nightkiller，欢迎观看我的nightt killer系列手札视频，该视频是nightt killer系列手札电子书的配套视频。不知道你有没有注意到，我的所有视频封面上，在右上角都会有一个蓝色的logo，是一个冰山，上面一个月亮。这意味着nightt killller系列手札已经被getub收入，并且把它备份到了位于北极的一个地下250米的数据中心当中。这个数据中心位于挪威北部的一个地下废弃矿坑，Cat harb将其改造为数据中心，所有的数据会保留1000年，同时数据会保存在埃及亚利山大图书馆以及牛津的图书馆，还有加利福尼亚斯坦福图书馆，这是留给我们子孙后代的遗产，同时我也很欣慰。

1000年以后的人们可以看到我的电子书，不过很可能在1000年之后，这些知识已经没有任何用处。如果你对此感兴趣，可以去我的电子书首页，在首页当中有getub的链接。今天我们学习的内容是get lab项目管理。项目管理是管理学的一个分支，如果单独的去讨论项目管理，就可能需要做几期视频。今天我只是结合get lab如何应用于项目管理给大家讲解一下。我们学习项目管理最忌讳的就是照搬书本的知识，通常是我们根据企业自身的情况讲项目管理当中的章节进行裁剪，裁剪出我们需要的内容，结合我们的实际需求，最终定制出我们自己的项目管理版本。我们可以说在象牙塔当中研究出的管理学都属于实际脱节的，它是一种乌托邦式的理想状态，现实当中是不可能实现的。

如我们学习PM的几大模块，它包括了范围管理、进度管理。成本管理、集成管理、质量管理，包括沟通管理、采购管理、风险管理、人力资源管理等等很多模块你会发现简直就是在扯淡，所以我们需要对它裁剪之后才能使用。如果你对项目管理感兴趣，可以看我的net killer管理手札。我们的学习重点仍然是getlab为中心，今天的学习内容是标记的定义、工作流、里程碑、议题以及release note如何编写。在我们软件项目管理当中用的最多的是时间管理，也就是什么任务什么时间完成，质量管理，也就是测试这块。配置管理，在此前我们是需要一个配置管理员这个角色的，但是自从有了waps之后，我们就不再需要这个岗位了。沟通管理，也就是项目的协调跟沟通，在介绍议题的时候，我们会涉及到这块，传统的it项目会涉及到采购跟风险管理。通常我们。

和互联网这种高速迭代的产品，通常不涉及到这块，还有范围管理，也就是职责编辑。下面我就谈谈开发、测试、运维三个部门的关系。开发、测试跟运维在小公司呢，有可能是三个组，大公司有可能是三个独立的部门，他们看似独立，但是却紧密相连，他没有相互制约，也就是他们的工作是相互耦合的，很难独立分开，这就造成了管理混乱，几乎是初创企业的前三年都无法避免这种混乱。这是因为中小企业或者是初创企业，从成本的角度，他们无法聘用经验更丰富的管理者，如果他们熬过了这个阶段，或者企业突然处于一个高速上升的阶段，提升团队的平均年龄，或者去聘用经验更丰富的管理者，才会得到一些改善。

这是又面临一个重大的问题，就是之前所写的程序可能已经不能满足现在的需求了。由于此前团队比较年轻，他们对未来的规划是有限的，这是即使你提升团队的平均年龄，也无机于改善当前的代码质量。此时面临的一个问题叫做重构，就是推翻，重新再来。这是几乎所有中国互联网企业的发展历程。回到我们的主题，我们的开发只负责写程序，将运行无误的程序提交到代码库就可以了，至此开发就不用管了。接下来测试，从代码库当中去获取代码，通过offices系统打包编译、打包测试，然后部署，部署到测试环境。开发是不能私自将代码交给运维或交给测试去测试的，这样就跳过了版本库。那么当有一些人员变动的时候，就可能出现代码的丢失。测试也只能从代码库。

当中去获取代码，然后进行编译、打包、运行测试。同时我们也不允许测试部将测试代码交给运维直接上线，我们应尽量避免代码没有经过版本库流入生产环境，这样会造成线上线下不一致的情况。运维部门也是直接从代码库当中获取代码，然后进行编译、打包、部署。这就是三个部门的关系，他们紧密联系又相互制约。现在来谈谈项目计划。所谓的项目计划就是制定路线图，我常常把项目的开发计划比作列车时间表，每一站就是一个里程碑。这个列车时间表的概念是来自于我早期参加的一个英国项目，当时我们使用一个项目管理软件叫TC，可能一些八零后的小伙伴还知道TC这个项目管理软件，它应该是一个初代项目管理软件，在这个管理软件当中。

就提出了很多现代管理软件的一些雏形，例如路线图、里程碑、时间线，还有它的任务管理，它的任务管理叫做take it，翻译成中文就是票的意思。由于这个软件是Python语言开发，而且它的框架也比较古老，后期维护的人也比较少，项目的更新速度也比较慢，最终就慢慢慢慢的被淘汰了。它被另一个软件叫redin的项目管理软件所替代，Redin也是红极一时的，但是后来get HUB跟getlab出现了，前面的一些管理软件都慢慢的淡出人们的视野，消失的项目观点软件包括red m conference b zla gira marti bug free Bel等等，这些软件我都用过，但是后来都慢慢的消失了。由于在tacc当中一个任务叫take it翻译成中文是票的意思，而它制定的路线图。

每个里程碑又像又很形象的相当于一个车站，每个里程碑当中都是一组take，我们的升级就如同开往下一站的火车，需要升级的任务就相当于买票上车。我们知道火车是不等人的，它是按时发车的。同理，我们的项目也是按照自己的路线图运行的，错过这一站，你就必须等下一班。项目经理会在我们的即时通信软件当中发布发车时间，也就是我们的升级上线时间。已经完成开发和测试的ticket，也就是任务需要升级，那么他就需要买票上车，如果任务没有完成测试，那么就赶下一班车。上车就是将ticket放入我们规定的里程碑当中，然后等待发车，发车就是升级上线。火车会偶尔晚点或者取消班次，偶尔还会临时停车，或者是直接开往下一站项目也是如此。

那么也会延期取消本次升级、超过里程碑、临时解决热修复，这些是项目管理当中的正常现象。所以项目计划就像列车时刻表一样，一旦拟定好就不要随意更改，必须按照设定的里程碑有条不紊的推进。项目一旦修改立开车时刻表，就需要同时调整全国的铁路运行网，随意去修改项目的road map也会出现类似的情况，会造成多米诺骨牌效应。下面介绍一下如何定义工作流，你会发现在getlab当中是没有工作流这个概念的，不仅getlab没有，微软的Microsoft project也没有。你是否想过为什么微软不做工作流相关的软件？为什么不把工作流集成到Microsoft的office当中？在我的职业生涯当中，我的第一份工作就是做OA办公自动化，当时有很多公司都想在OA这块分得一块。

蛋糕，其中也包括了像金山、金蝶、用友等等公司，其中无一例外他们所有的产品都失败了。如今20年过去了，没有一个OA产品获得成功。在很多企业的数字化转型过程当中，必上的一个项目就是OA，但是上来之后几乎无一例外的都是不了了之。为什么出现这种情况呢？OA没有成为主流的原因就是死在工作流上。每个企业都有自己的流程，无法统一标准，即使管理学诞生的西方国家也没有统一的标准跟流程，而在我们中国，人质又是主流，而不是制度去治理公司。一旦管理层出现变化，那么下面的所有的流程将会被推翻，新的管理层上任之后会启用新的流程，同时使用自己的人。同时市场的环境也在不断的变化，老的流程已经不适合现代。

企业的管理。这就是为什么微软不做工作流相关的软件，IBM也不做，Oracle也不做，大家都不做。虽然在技术有成熟的工作流引擎，而且是图形界面的，但是你会发现这些功能巨难用，只有技术人员才会使用，行政人员根本无法使用。那么怎样在getlab当中定义工作流呢？我们通常是使用标记来定义工作流的，通过改变标记的属性实现工作流的定义。例如，我们定义开发中已完成，测试中已测试，这样我们就可以设计成一个这样的任务。我们发一个议题，它的第一个标记叫任务，当这这个任务完成之后，我们将这个标记改为开发中，也就意味着该任务正在进行。当程序员完成了这个任务，就把它改成已完成。任务完成之后，我们可以把标记改为测试指派到测试部。测试部的。

测试人员接收到任务以后，把它改成为测试中标记，同样测试完成之后改为已测试，这样就形成了一个工作流。下面讲一下工作流的设计原则，工作流应尽量使用减法原则，而不是加法原则，工作流流转的节点越少越好，尽量是线性的，也就是一端流向另一端，还要尽量的避免分叉，也就是逻辑判断，也就是A的审批决定了下一步是流向B还是流向C，最后的理清依赖关系，避免循环，目的是让工作流可操作，E操作能冗余。既然我们使用标记来定义工作流，那么如何用好标记呢？在盖APP当中，标记分为组标记跟项目标记，在组中定义完标记以后，项目会继承组的标记。我们可以利用这个特性来讲一些公用的标记，定义为组标记，然后在项目当中。

来定义个性化标记。我们可以使用组合标记，在组中选择一个标记，在项目当中再选择一个标记。例如组中的标记叫升级，那么项目当中的标记叫数据库，那么就表示数据库升级。在getlab当中，每一个任务是对应一个议题的。通常我们会先定义里程碑，里程碑就是我们的项目节点，然后创建例题的时候，我们会选择对应的里程碑，这样就完成了项目road map的定义。当我们写议题的时候，面临一个问题，就是任务分解。任务分解是十分讲究的，任务分解要尽量解耦，避免交叉，要理清依赖关系。软件项目管理混乱的原因多出现在任务分解上，例如很多没有经验的管理人员会将一个功能或者将一个拈去分解成一个任务，但实际功能当中，每个功能、某个拈块它们之间是有相互依赖的。譬如只有A功能实现之后才能进行B功能的开发，然后B功能完成之后才会进行C功能的开发，而C功能同时又依赖A功能。如果处理不好这个依赖关系，我们分解出的任务是有问题的，就会出现各种各样的冲突。所以我们要用上帝视角来去分解任务。所谓的上帝视角就是全局思维或者更高维度的思维，就如同我们从高空俯瞰一个迷宫一样，我们可以清晰的看到它的路线图。而迷宫里的凶鼠只能通过。

不断的试错，也就是走一条路，走的尽头它不通，再走第二条路，就把所有的路线全部试验一遍，才能达到最终的目的地。而这个试错的过程是需要经验积累的，任何人员都不可能跳过这个步骤达到目的地，也就是我们需要一个非常有经验的人去做这项任务分解工作。在下一期视频当中，我还会继续讲解关于任务分解，下一期视频的主题是并行开发，要实现并行开发，也就是同时进行多个功能、多个任务，或者是多个小组、多个团队同时开发，那么就需要满足3.1是合理的分解任务，二是配套的环境，三是开发分支的应用。视频时长的关系我会放在下一期，这一期就先不讲解了。怎样写这个议题呢？通常写议题要精确表达任务，避免只模糊词汇，避免造成误解。

我通常是使用5WIH的分配法则，5WIH任务分配法则，那么what就要代表是要做什么事，WHY为什么要做这件事？有什么意义？目的是什么，有必要吗？问就是什么时候做，什么时候完成。where你是在哪里做？Who是谁做，谁来负责，谁来执行，最后是how怎样做，有时候我们还会加入一个how much，也就是成本。最后来讲一下如何写release not release not就是当我们进行升级的时候，记录这次升级的。

变化release not当中通常是写此次升级的内容，比如新增了什么，修改了什么，修复了之前的什么bug，被解决什么问题，改善了什么，忽略了哪些bug。在我的net kerwas手单当中又详细的讲解，几乎正规的软件发行都会有这个release not，所以我们可以去参考，这里就不给大家演示了，你可以看看MYSQ的release not如何编写，还有呃，Java的，只要我们找一个开源软件就可以找到它的release not，与release not配套的还有一个叫change职log change职log当中描述的是更详细的一些升级的变化。关于项目管理，今天就先讲到这里，有什么问题可以在评论区给我留言，或者给我私信，喜欢我电子书跟视频的小伙伴请关注我，给我点点小红心，最后谢谢大家观看。