u012730075的专栏

因为我们每次迭代都会针对实施DevOps过程中出现的问题进行总结和复盘。目前，此实践已经在团队级、子公司级得到了很好的认可和实施，正在向全集团推广中，希望有更多的业界朋友也能尝试拥抱DevOps，享受到它的实施成果。

云原生技术生态除了上述篇章已经讲述的微服务架构、容器技术（Docker）、容器编排技术（Kubernetes）、ServiceMesh技术（Istio） 等技术体系，还有一个很重要的管理实践—— DevOps，在进行深层次的微服务或云原生应用架构改造后，进行对应的DevOps整体研发流程改造，可实现业务流程的自动化。下面我们就来了解一下 DevOps 这种产品研发管理实践。...

在自己从事产品研发实践和管理的十几年职业生涯里，经历过以瀑布式开发为主导的产品研发模式，经历过以敏捷开发为主导的产品研发模式，其相应的背景也是在软件项目和互联网软件平台为主导的情境下。但是当企业产品主要是硬件的研发、生产、销售时，经历的却是以IPD（集成产品开发）为主导的产品研发模式。其实自己经历过对IPD的抗拒，慢慢地适应，到着力推行的转变。...

希望所有研发人员能够敢于并且会表达自己，让更多的人了解自己；希望所有的研发人员不仅仅是机械的写代码，也能洞悉市场、了解用户，让自己的产出能够适配用户和市场的需求，这何尝不是一种成就感；希望所有的研发人员不再受困于狭窄的职场方向，而是有更多可能转型产品、市场、管理我认为敏捷开发的实践带给了我这些：工作的收益、内心的释放、转型的机遇以及最重要的自信，所以也想分享给大家这些。...

前期如果能预见到技术债务，而且时间又紧张的话，自己多努力再努力去解决，因为这是为你以后争取时间和精力；中期如果能及时发现技术债务，不管付出再大也要有勇气决然解决，因为这可能关系到产品和你的生存；后期发现了这些问题那你就吸取教训，开展下一个项目时去避免。......

截止到现在自己已经有了3年多的敏捷团队实践，包括有一年多的敏捷团队管理经验。个人对敏捷还是比较推崇的，但是必须要注意结合实际进行落地，否则就成了邯郸学步。其中我感觉落地的重点就是千万不要生搬硬套敏捷的实施条款，而是去理解其精髓去融汇贯通。恰好《高效程序员的45个习惯——敏捷开发修炼之道》就给了我们这么一个机会去深入了解敏捷的精髓，在第二次读此书之际我对书中内容进行了些总结归纳，分享给大家。

先讲一个场景：“团队负责人接到一个新项目，他会把项目进行需求细化，功能细化，然后他会分配给不同的团队成员完成”。 在这个场景中，团队负责人就是master，团队成员就是worker，至于这样做的好处，不用说大家也明白，如果团队负责人一个人干，估么着他要么累死，要么任务完不成被领导骂死。     master-worker模型的最大作用就是提高处理效率，特别是在多核cpu上，多worker的

案例1：这阶段公司内部在测试一个即将上线的产品，好几次都遇到运行良好的服务在某个时间段后不能提供正确服务的情况，由于产品涉及到多个端，协作人员众多，而且各端软件的更替也较频繁，在从内部排查问题的同时也在从外部着手确定是否有人更改过某个程序，众研发人员都说没有更改过程序。但是随着排查的深入往往会发现是某个人搞混了自己发布程序的版本。案例2：团队中有人在发布动态库或应用程序时采用日期来做版本号

背景：不管您的公司是以产品为导向还是以项目为导向总需要一支团队去完成任务。这个团队有可能是一个研发部门，也有可能是由多个研发部门的成员混合组成，甚至有可能还包含研发部门之外的其他的组织成员，比如产品部门、运维部门。这些都依赖于你们的研发体系究竟采用了何种组织结构。几种常见划分组织结构的方式1.项目型/产品型在这种组织架构中是依据所负责的产品来划分部门。比如现在要开发一套

(关于Jira和Confluence的基本介绍请参看文章团队协作，集成工具推荐)背景：已经使用Jira和Confluence管理了一个产品团队的任务和资源，现在又想加入另外一个产品团队的任务和资源,首要问题是如何解决两个团队之间的权限隔离。研究了半天，阅读了Jira和confluence的相关文档，终于搞定，现在分享给大家。Jira打开系统管理中的权限模型我们可

大型项目往往需要比较多的人员参与，如果轻视管理协调，工具的规范，代码规范，版本发布规范......那么项目一定会逐步陷入失控的境地。    下面是我经历过的而且认为的一个比较理想的项目规范： >开发模式 敏捷开发，选择敏捷，是因为我认为敏捷的核心理念之中，“沟通”正好可以解决项目由于参与人员太多的协调问题，对于项目通常有需求讨论会，设计评审会，节点总结和计划会，相关人员都必须参

1.技术牛X型，脾气不好：这种经理的特质往往是很关注技术细节，做产品时个人英雄主义极为严重，容不得组员有半点质疑，即使给组员质疑的机会，他也往往会坚持己见，对这种项目经理，当你做为菜鸟时一定会对他敬畏有加，觉得他好好有魄力啊，往往他给组员分配任务时只是一个大苦瓜分三份，你吃这个，你，你吃那个。当你有不能解决的问题时，他会先奚落你一番，然后啪啪啪给你配置好环境，咔咔咔给你敲好代码.......然后再

有些人问了，为什么交付的产品包含了用户要求的功能，却不招用户待见，很快就被搁置一边了。乔帮主会这样回答你，苹果的产品能俘获众多用户的心是因为注重用户体验，关注细节。    在我们每个人的项目实践中多多少少都会更关注需求，功能的实现，而忽视了用户体验。但是，请诸位先换位思考下，现在我是用户，对于一个产品来说，你满足了我需要的功能，但是界面简单，操作复杂，而且运行还不流畅，我一定会暗骂开发这款产品的团

做了多年的研发工程师，在所处的环境中，所接触的开发人员中很少有看重对自己代码进行测试这项工作的。大多研发人员往往是写好了代码运行起来，简单做下测试，甚至不去测试就抛给接口使用者或者质量管理人员。而且理由很充分“没时间...；我觉得应该没问题...；这种简单的事让专职人员去测试，否则浪费自己的时间....”从这些话首先该否定的是其人的职业素养，还有就是设计的代码结构不好测试，或者根本就写不出好的测试

想必大家对敏捷开发中的结对编程都有所了解，可在公司试用推广时却很容易遭到大多数同事的反对，反对理由如下：1.长期的习惯导致在有个人在旁边监督你编写代码时很别扭；2.敏捷的结对编程要求两个程序员最好能力水平相当？这个不好界定吧，另外每个人都有每个人的编码习惯，大家也知道，做为程序员的我们往往比较固执，也比较爱布道，所以很容易产生各种实时冲突，影响开发效率；3.也许两个人会聊其他话题哦，比如这款智能机

“只要参与过一两个软件项目，就一定对书中介绍的情景深有感触，也必然会从中得到经验教训”这是《软件随想录》的作者Joel Spolsky对这本书的感受。    以下我也结合自己实际的工作体验对这本书中的模式场景说一下自己的感受：    模式“玩的就是心跳”大概介绍的就是这样一种场景，在工作中永远都是紧迫的项目，在项目中永远都是紧迫的功能，项目组永远处于紧迫忙碌的状态中，试问这样团队怎样能有高质量的产

去年，在慢慢了解了公司的研发体系和存在的一些问题后，向公司高层提了关于实施敏捷的建议，并没有讲具体的敏捷理论，也没有讲如何实施敏捷的，只是把我经历敏捷后的一些感受讲了出来。 对公司而言——敏捷思想带来民主、透明、自觉的文化； 对团队而言——敏捷团队带来了交流沟通、互助学习、友好信任； 对产品而言——在业务人员和测试人员提早介入跟进的情况下有了周期保证、质量保证； 对个人而言——每个

在之前的你们的团队是怎样组织开展大型项目的？这篇文章中指出了要在团队内引入协作工具，在我经历的团队和使用的工具中，我感觉项目管理工具jira、wiki知识库工具confluence、持续集成工具hudson—jenkins比较出色，而且易于团队使用。（前两款都不是免费软件，虽然网上有很多破解版本，但是希望大家如果在条件支持的情况下还是能使用正版软件，而hudson—jenkins则是开源的）  

首先我要说明的是题目有着双关的含义。一层含义针对我而言，而这个“人月神话”是指Brooks老爷子的书籍《人月神话》，我很认可这本书中的大多数观点。一层含义针对一些企业管理者而言，我从我的角度对某些企业的管理层提出质疑，为什么他们确实相信人月这个神话。首先讲讲《人月神话》这本书之前这本书的大名早就如雷贯耳，但是一想到是一本几十年前的老龄书籍，心里想着伴随着软件业日新月异的发展，这本书的观点一定也是老

一直以来觉得技术圈是很纯洁的，小人在这个圈子中很少。但是说句真心话，自私抑或自大的人在这个圈中可不少，而且多以中层管理居多，特别是牵扯到自身利益和部门利益时这种行为表现的更为明显。案例1：1部门要开发一款产品A，其中2部门曾经做产品B时，已经做过很多A产品类似的功能模块或技术点，但是隐含的规则就是你是你的，我是我的。2部门会看紧家门，防止1部门获取这些。1部门怕功劳落入其他人手中，也闭门不出，开始

近期公司要求各部门必须要制定详尽的KPI考核方案，看了下人力下发的模版，对研发非常非常不科学，简直把研发工作当做了工厂产线，于是特别针对我们部门的敏捷团队，制定了这么一套考核方案。(参考：敏捷团队的绩效考核)两个考核方向：团队绩效考核，个人绩效考核；团队绩效考核目的：促使团队成员对整体质量负责；考核内容：1.每次迭代的交付物可否被接受。（团队采用的敏捷开发，每一阶段会制定一个产出计划和产出目标）目

因为现在开展项目几乎都是用的迭代式开发， 在开展一个软件项目的起始阶段，难免需要关注关键点，在实际实施中和从项目管理书籍的学习中，我总结了以下优先级，不光是个人看法，是对别人看法的总结，觉得很有道理。1.高可靠性；（High Availability)2.低成本；（Cost Effective）3.可扩展性；（Scalability）4.投放市场快速性；（Time to Marke