我前些天貌似翻到过鲲鹏的软件开发云服务，里面有代码托管，项目集成，流水线，部署，测试之类的DevOps流。现在貌似不见了。是系统改版了吗？还是砍掉了已经？

在华为云官网上，没有找到软件开发云服务的白皮书，最好是整个服务就是一本白皮书的，想深入学习。感激不尽！

对于华为鲲鹏芯片上软件开发技术，您有什么想了解的问题吗？鲲鹏芯片上开发的软件怎么处理才能支持部署在 X86的架构上？鲲鹏软件开发是否有各种场景的案例可以参考学习？在鲲鹏芯片上软件开发成熟的技术问题解答社区非常重要，有没有这样的社区？社区活跃度怎样？我该怎样开始一个简单的开发一个程序在鲲鹏芯片上？

对于华为鲲鹏芯片上软件开发技术，您有什么想了解的问题吗？1：HDC会议上我看到了鲲鹏的板子都搞定了，可以向我们合作伙伴、开发者全面生态开发的了，这个我们如何才能采购到这样的板子，或者个人如何用一个鲲鹏的树莓派去做一些个人的开发的呢？2：现在的IOT华为的一个系统叫liteos能否也跑在鲲鹏芯片上的呢？以后liteos能否也用鲲鹏芯片作为主流芯片去做其中的开发板子或者生产板子的呢？3：作为个人开发者，我如何能够参与到华为云的华为生态上的呢？我就是关注华为云的鲲鹏论坛就可以的了吗？4：如何才能更加深入到了解和学习到鲲鹏的知识的呢？是不是还是要考一个鲲鹏的HCIA的呢？5：我学习了鲲鹏芯片，我如何还想往AI发展，是不是还的结合了解一下昇腾芯片的呢?6：目前上从X86架构上代码迁移到鲲鹏架构上的成功率和稳定行如何的呢？能够有一些实际的案例分享一下的呢？7：鲲鹏的云桌面，在安装原来X86架构的一些软件会不会存在一定问题的呢？8：鲲鹏生态上，会不会考虑到出一些鲲鹏架构的华为笔记本或者台式机给个人使用的呢？这个能否也能够在计算上部署一波的呢？9：华为的平板和华为的手机能否也使用鲲鹏芯片的呢？10：期待专家能够回到我这些问题哈，总的来说真心希望鲲鹏可以大放异彩，成为中国的领先技术芯片担当。甚至全球前茅技术芯片的担当。

讲到看板，不得不提拉动式生产及限制在制品数量，前者能帮助加快流动速度，后者能帮助找出瓶颈点并进一步加速，然而真的有用吗？最近在读《敏捷转型-打造VUCA时代的高效能组织》一书，重新审视了这两个观点，对其中一些描述信息持有不同的看法。拉动式生产真能提速和减少浪费吗？我们总说拉动式比推动式要快，为什么？下图是书中内容截图这里解释的结果，是拉动式生产能减少浪费。类比到软件开发就是，开发完的软件假如尚未投入生产，就是一种浪费。软件开发的过程中涉及到设计、开发、测试、部署等多个动作，按照拉动式生产方式，假如开发完5个需求，测试没有余力去拉动这5个需求进测试的话，开发人员就不能继续开发了，此时应该去解决测试这边的瓶颈问题，再开始开发（之前各个地方都是这么讲解的），常说的解决方案是开发人员帮助测试人员进行测试。这样能让整个流程加速，聚焦完成。这里我的不同意见为，这个见解太极端了，默认的前提是开发人员能够帮助测试人员进行测试，这一默认点一定有个前提是，大家认为开发去做的是手工测试的工作，这部分工作如果写好测试用例了的话，开发人员很容易上手做。那么是真的吗？我只能做开发人员能帮助做些事情，但是你不能说开发人员测试完了，测试人员就不用去检测了，除非对测试质量要求不高，或者这个团队的开发人员测试能力很强了。另外探索性测试、自动化测试等都不是开发人员随便能做的。好了，就算开发-测试这个环节用上面的方式能解决，其他环节呢？每次举例子都是开发-测试这个环节，而拉动式生产的说法已经被滥用到各个地方了，假如设计-开发阶段遇到了阻塞点，设计人员能帮助开发人员去写代码吗？假如测试-部署环节遇到了阻塞点，测试人员能帮助运维人员做部署吗？显而易见是不能的。所以我的意见是，设置了在制品数量限制，只能帮助识别瓶颈，让Scrum Master及团队重视这里，去想办法解决，但是本身并没有帮助到你解决它。并不能真正的加速。再说减少浪费，停止了开发，会避免开发出来的代码留在那里因为不交付而浪费。那么开发人员干啥去呢？除了说的帮助测试人员做测试，他们不能动代码的情况下，不就是浪费了吗？因为一旦瓶颈点解决，开发人员依旧是要做那些需求的，早做变成了浪费，然而晚做可能会导致最后做不完。为什么要限制在制品数量？在7.5.2章节，作者给出了几个原因：缩短平均周期时间：吞吐率=在制品/平均周期时间，所以如果在制品多的话，吞吐率低，平均周期时间长了。这点是我最不认同的。为了缩短平均周期，然后停止瓶颈点的工作，得到的只是一个短平均周期这个数值而已，除此之外有什么效果吗？还是应该说些干货，尤其是在软件开发过程中，你浪费的平均周期，给了开发人员，他能创造别的价值吗？如果不能的话，就是转移这个部分的浪费到了另外一个部分的浪费而已。打破在制品堆积的恶性循环。简单来说，就是开发出来的代码留在系统中，来不及测试，堆积的代码越多，系统中有的bug就越多，Bug多导致出各种恶性循环。       这一点我部分认同，认同的地方是，堆积的代码多，确实导致显性和隐形的bug就多了，修复时带来的新的bug又会带来隐患，最终导致交付变慢。不认同的地           方在于，软件研发的测试环节是个特殊的环节。首先测试这个事情就特殊，它是挑错的，其他环节不这样，不会带来bug这种隐患，所以限制设计-开发，测试-           部署等环节并不会通用这里说到的好处。第二，软件的测试要比其他生产的检测特殊，因为软件里的一个bug，可能会导致其他代码的功能受影响，而制造业就         不会出现这情况，你制造一个方向盘出问题了，不会导致你发动机不好用，即使由于方向盘的问题，车子无法正常行驶，你修复了方向盘，车子就正常了，这一         点和软件是不一样的。所以我个人觉得，限制在制品数量的好处就是，对软件开发来说，间接限制了产品中的bug数量，来减少bug这个是有用的，但是这个业态特殊了，一定要是测试类型的环节，以及bug之前互相有影响。换个场景，这个好处就荡然无存了。结论和同事交流了下，感觉限制在制品，就是能突出瓶颈，然后团队一起想想办法，如果长期出现这个问题，回顾会议上该讨论讨论，比如增加后面环节的人数。如果这个瓶颈在这种情况下解决不了的话，还是突破限制，该干啥干啥去吧，因为限制的前面环节的人留下来也没什么用。停止，本身就是一种浪费。

这是我们初步开发的功能软件算法Demo的流程框图，其中可以看到各个节点之间的数据流（也就是输入输出），与他们之间的通信协议；MDC（Mobile Data Center）300F可用于二次发开的芯片有Host（Kunpeng 920）和Mini（Ascend 310）。Host是ARM（Advanced RISC Machine）架构服务器级的CPU（Central Processing Unit），具有强大的计算能力；Mini是Ascend架构的图形处理芯片，MDC有4个Mini，分别是Mini0、Mini1、Mini2、Mini3。需要使用GPU加速的功能软件（如图像处理节点、点云聚类的NN算法节点）应部署在Mini上，其他节点可部署在Host上。

如您无法直接访问本帖中的指导链接，请与您对接的客户经理联系，或直接回复本帖，我们有专人与您联系。一、获取相关文档：在华为support网站 https://support.huawei.com/enterprise/zh/intelligent-automotive-solution/mdc-pid-23104241  可以获取到很多与产品相关的资料和文档。这些文档需要申请访问权限。其中涉及应用开发移植的内容截图如下：二、获取培训课程我们准备了应用开发、AI神经网络方面的培训课程，只等您来看！这个课程注册即可观看。https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXS018+Self-paced/courseware/0b76ee9857f54396b1ca74df16b4e237/3b772ac2de2d4be68748cfe1e1b5dfa9/如您有空，建议从课程的开头开始观看，以便获得全面的背景信息。三、从论坛获取帮助如您所见，我们的论坛中已经有不少不同用户反映的问题，这些问题中可能已经包含你的困惑。如果还是不能解决您的问题，您可以直接在板块下发帖，写下您的问题，我们有专人来解答您的问题。现在，就请您将目光移动至右上角，发表您的第一个求助帖吧~

书籍名称《Scrum敏捷软件开发》Mike Cohn著讨论主题自下而上的敏捷变革中，如何和高层做好汇报沟通？书中建议作者在书中引用了Mary Lynn Manns和Linda Rising在《Fearless Change：Patterns for Introducing New Ideas》一书中的观点：“我们相信引入变革的最佳方式是自下而上的，同时需要管理层在适当的时候给与支持，包括基层和更高层的。”同时作者写到一个组织尝试向Scrum转型，如果没有公司高层的支持，他们会遇到基层无法克服的阻力。强调了自下而上的敏捷变革中，高层的作用至关重要。个人观点通常汇报有两个核心点，我们可以结合这两个核心点来考虑：一是领导需要知道什么，要清楚领导的关注点在哪。和不同的人去聊敏捷，要抓住对方的关注点，比如老板关心钱，管理者关注效率，团队成员关注负荷，这是在变革开始之前就要沟通获取的，在进行过程中会发生变化，要随时对齐，这样你的敏捷变革才能有的放矢，针对领导的诉求点去落地实践形成可汇报的结果和数据；二是你需要领导知道什么，推动变革中的汇报就是要让领导认可和支持敏捷，那就要让领导看到敏捷的作用。团队交付的成果物和统计数据是客观的证明，汇报的时候找出和敏捷之间的关联去展示；团队氛围，成员状态，团队和成员能力的提升这些是主观的感受，可以邀请领导有时间的时候参与下团队的早会、评审会，去团队的工作空间参观下看板等带来感官的体验。你们的敏捷转型中是怎么和领导沟通汇报的？有什么好的想法和建议？欢迎留言交流。

有需要的小伙伴请联系邮箱地址：weihualv@huawei.com

其实详细工时的特性已经上线好几个月了，一来确实比较忙（瞎忙），二来从产品经理的角度看，一直觉得详细工时是个很小的功能，算不上华为语境下的Tier 1特性好吧，以上都是借口，其实是我比较懒。。。呵呵但是，有些意外的发现，用户对工时的使用挺多的，很多用户甚至还夸奖了这个特性，不少用户最近还提了很多需求，大大超出我的预期，当然也有用户对于这个功能有些不解，觉得增加了门槛。那么就不能偷懒了，恰好最近因为左脚骨折，虽然还在坚持上班，但是同事们看我都觉得这是个病人，所以就有些可以自己支配的时间了，趁今天把我对工时的理解，和近期工时的功能介绍一下。Part1. 研发人员的工时之我见预警：如下言论主观意识非常浓烈，写的非常没有条理。，完全是个人心路历程的废话，如果大家希望看到“详细工时”的功能介绍，可以直接跳转到Part2.从我个人的工作经历看，我其实个人非常不喜欢工时这个机制，尤其是对于软件研发人员，我的主观看法，一直认为软件研发活动是个智力活动，不是机械劳动，也不是重复性的工作，可能有的时候一天也写不了一行代码，因为一直在琢磨，也可能一天写的代码狂多。而工时这个机制，来源于最早的制造业，计件计时付工资的模式，这种模式因为是这种工作的产出是机械的强可重复性的。这儿也顺便**一下，华为的研发工时，华为其实也有研发工时这个机制，最早也非常的复杂填写机制，一天多少小时写代码了，多少小时写设计了，开会多长时间了，我个人一直非常抵制，公司的研发员工也反对意见非常大，随着公司的氛围和管理机制变化，工时这个机制后面经过好多次优化和简化，虽然还要填工时，但是已经变成后台自动了，根据你的角色和项目，根据你考勤到岗自动填写，工时的分类（写代码，还是设计，还是产品管理）都固定几类。比如我是云服务产品经理，那么我每天的工时类型都是一类，也就是8个小时等，就不去细分你这8个小时具体是做什么的....我一直觉得工时是公司在监视你，是**裸的资本主义雇佣关系(呵呵，其实本来就是这样啊)，所以很反感。但是因为我有一段经历是弄公司的整体研发变革，我有机会深入的了解为什么华为这样的公司，还要用工时这个我觉得落后的不适用于软件开发的机制。其实道理也不复杂，还是为了项目预算和成本的一些考虑。所以，我在做项目管理服务产品经理后，也一直希望劝服我的客户们，应该弱化使用工时这个机制，给软件开发人员予以信任，所以总是不厌其烦的在各种布道中去传递软件开发是智力活动。项目管理服务最早提供的工时功能是在每个工作项上有一个实际工时字段，一个预计工时字段。业界类似的产品也是这种为主。但是，后来很多客户都灵魂拷问我一个VoC（Voice of Customer）：一个工作项有多个人处理，由于不是按每个人花费在这个工作项上的工时填写的，每个人的工时花费都被抹了啊，这样不公平啊。同时后面我们上线自定义统计报表后，很多用户满心喜欢，因为可以统计成员的工时了，结果发现报表是有，但是统计到的那个成员是当前作为处理人的成员，相当于之前处理人的花费工时都被记录到最后一个处理人那儿了。由于工时的诉求特别集中，我也开始反思，我于是和很多用户开始联系（当面或电话或微信），我逐渐明白了，很多企业是真的需要通过项目成员的进行成本、预算、项目收益，甚至成员绩效的管理。很多企业的管理者都让我换位思考一下，如果你是一个项目经理，一个企业的管理者，怎么核算每个项目的投入成本，怎么评估每个成员的绩效。我开始理解了，华为和很多我们的企业用户不一样，我们的不少企业用户都还在生存爬升阶段，规模不算大，产品线单一，扛风险不强，而软件研发人员往往是这些企业最大的成本。我后来利用有些机会，也和很多同行类似产品的产品经理交流，因为他们也是大厂出身，他们一早也是和我们类似的认识，觉得研发人员就不应该填写工时。可是他们和客户交流后，也跟我一样产生了反思感。痛定思痛，我们在开发团队人力管道有限的情况下，还是决定调高详细工时的优先级，大概在去年10月份就上线了，悄然上线，部分用户使用后持续给我们反馈，我们也持续迭代改了几版，也补齐了大家最想要的成员工时统计分析。Part 2. 详细工时的功能使用说明 产品设计的基本逻辑。我们不是做一个独立的工时系统，我们的工时还是基于现有的产品功能，依托于工作项。我们认为工作项就是你需要完成的工作，你把你花费在这个工作项上的时间填写为工时即可。因此还是主要面向使用软件开发的企业使用。我们定位于是工作项的详细工时，原先工作项上的“实际工时”其实是这个工作项的总工时。如果一个工作项不填写任何的详细工时，用户可以直接填写工作项的“实际工时”，如果一个工作项填写了详细工时，那么工作项的“实际工时”字段就会自动累加所有的详细工时，同时用户也不能再直接改“实际工时”这个字段了。      2. “详细工时”的使用说明   2.1 通过工作项的详情页，进行详细工时的填写。    选择填写工时     选择工时的时间：可以选择一个时间段，从某天到某天，也可以选择是否包含周末（周末也填工时，这是996还是997？：），希望大家都不勾选这个） 填写工时记录：这儿有两个工时选项，如果是选择“总数”，那么系统会被你填写的工时值平均分到你填写时间范围的每一天。举个例子，如果你选择的时间是01-16 到 01-17，你填写的工时值是10，那么系统会自动生成两条记录，01-16 5人时，01-17 5人时如果选择“每天”，那么系统会认为你每天都是这个值。举个例子，如果你选择的是01-16 到 01-17，填写的工时值是10，那么系统会自动生成两条记录，01-16 10人时，01-17 10人时。（每天工作10小时？：））填写 可选填工时类型：系统预置了一些研发领域常见的工时类型，如前端开发，后端开发，测试验证，缺陷修复等可选填工时内容。可以填写更多工作时间花费的描述下图是我填写的一个样样例，我选择了“总计“，填了工时值为1 。       2.2  列表模式快捷填写工时。在各个工作项的列表模式下，如果修改工作项状态时，也可以及时填写工时。因为通常一个处理人修改工作项状态，也通常是他要把工作项传递给下一个处理人的时候，因此这个时候也可以顺便把自己花费的时间一并填写列表模式下，修改工作项状态，在原有的弹窗中新增了“是否填写工时”的选项勾选填写工时的选项后，会增加类似的工时信息填写3. 详细工时的覆盖规则详细工时的记录是可以改的，也可以删除，对于同一天的同一个人的工时有一个基本规则：同一天的同一个人的相同工作项类型的工时，只能有一条记录，会使用最新的值覆盖前值如下图，我在1-17有两条工时记录，但是因为工时类型不同，因此是允许的道理很简单，同一天基于同样的工作就一条记录就可以了。4. 详细工时的填写权限我们遵循统一的权限控制机制：如果一个项目成员拥有这个工作项的编辑权限，那么他就可以填写这个工作项的详细工时，不同的企业可以配置不同角色的权限。系统默认的“开发人员”角色举例说明一下。如果项目成员的角色是默认的开发人员，那么根据默认的角色机制。这个项目成员对于在他名下的工作项是可以编辑的，因此他可以填写这些工作项的工时。但是默认权限他没有编辑其他处理人的工作项权限，因此他无法填写其他工作项的详细工时。如果企业使用了这种角色配置，项目成员应该在切换处理人或状态时，及时填写自己花费的工时，避免一旦移交给其他处理人后，自己就没有权限填写了工时。当然企业也可以调整一下“开发人员”的权限，在项目设置中可以修改。5. 工作项的“实际工时”前面介绍了，一旦填写了详细工时，为了避免工作项的总实际工时被修改，而导致大家每个人的详细工时无效了，因此一旦有了详细工时，工作项的“实际工时”字段就会自动变成禁止修改的自动计算状态，会自动统计累加本工作项的详细工时的值，这样也方便大家的工作项实际工时统计，如下图所示：当然，如果没有填写详细工时，那么这个工作项的实际工时也还是可以像以前那样手工修改。6. 有子工作项的 “实际工时”如果一个工作项有子工作项，且它自己也有详细工时，那么这个工作项的“实际工时”= 其自身的详细工时累加 + 所有子工作项的“实际工时”我们来看个例子，如下Story下有一个Task，这个Task也填写了详细工时，这个Task的实际工时等于两条详细工时的累加值。那么对于父工作项的Story，它的工时就变成了3小时，它自己的1个小时 + 子工作项Task的2个小时。7. 项目成员工时的统计报表如果使用详细工时后，那么项目成员工时的统计就会非常准确的统计到每个人在每个工作项的时间花费，进入项目的“统计报表”菜单，我们这次特意为详细工时增加了一个可自定义的项目成员工时统计报表进入后，可以选择要分析的成员清单，可以全选也可以按角色也可以按照不同维度进行对比，比如迭代，重要程度，比如选择了“重要程度”，就不仅可以看到每个成员的工时，还可以看到这些成员的工时在不同重要程度工作项上的分布，比如下图，我在一般级别的工作项上的工时是11，在提示的工作项上的花费工时是31柱状图的下面还有汇总表格也可以选择导出统计值或者导出明细表，进行更详细的线下分析Part.3 写作最后1. 当前我们只在Scrum项目类型提供了详细工时，我们近期会在“新看板项目类型”也补充上这个功能特性。2. 针对开始有客户希望能通过API获取成员详细工时的需求，我们也在规划，当然这需要客户自己进行一些基于API的二次开发了。欢迎大家在评论中反馈给我们更多的意见本文写于 1-17日，也提前祝大家新春快乐！一个左脚骨折打着石膏的恒少

作者 黄隽 Charlie背景开发团队如何管理琐碎、突发性工作？企业的一些软件开发团队经常出现类似培训支撑等突发性工作，开发团队不清楚如何管理好类似客户培训这样的突发性支撑工作。解决突发性工作的问题被很多开发团队所重视，它直接影响开发团队工作的进度和速率，间接着影响迭代目标是否能完成，甚至整个项目的成败。所以降低或解决突发性工作对开发团队的干扰非常重要。问题分析一种情况，支撑工作与开发工作混合，没有明显的优先级，来了新的支撑任务需要随时接受和完成。从管理上来说，这些突发的琐碎任务和开发任务同时管理增加了很大的难度。另一种情况，开发团队正常进行开发工作的时候，客户经常会提出一些干扰开发团队冲突任务。而且突发性的工作是由客户重点提出并需要优先处理的，所以开发团队经常会额外付出工作量去处理，造成迭代目标不能达成的风险。开发团队主要想解决如何处理琐碎、突发性的支撑工作，如何提高工作效率的问题。我们先将情况大致分类如下表：        类 型           特   点                                                          分       析          一支撑工作与开发工作混合，出现突发性工作是常态。支撑的工作和正常的开发工作混合在一起，开发人员会经常临时切换工作内容，难免会对管理增加难度，频繁切换工作内容也会造成时间的浪费，因为开发人员需要梳理新工作，新工作完成后还要继续回想之前的工作做到了哪里。因此，问题的根源在于开发团队模式上，在此模式下需要考虑时刻应对问题、风险。         二开发工作为主，伴随着出现突发性应急工作，也就是正常的需求变更。有了新的应急工作，开发团队成员不知道怎么应对，什么时候去接受这个工作，谁来决定是否要做，谁去做，没有一个公开、透明的规则。没有一个可以承载这些新工作的地方。问题的根源在于如何管理好Backlog。再进一步理解，当有新的工作项加进来时，如何更新Backlog，也就是我们常说的有了需求变更（临时增加任务也算需求变更）怎么办？解决措施敏捷方式是趋势，越来越多的开发团队开始接触和使用，DevCloud产品也是基于敏捷思维设计的，以下内容均以敏捷方式叙述，包括但不限于Scrum框架。类型一，可以从人员分工角度思考，建议开发团队人员最好有工作侧重点的划分。一部分人员精力用于开发，另一部分人员侧重于应对突发工作。应对突发工作的人员时刻准备着问题风险的对应（比如开发工作尽量领取简单、松耦合的）。应对开发工作的人员专心完成开发内容。不管工作分工是哪种类型的开发团队，再有新的工作进来时，都需要遵循开发团队制定的规则，也就是管理好工作项的规则。类型二，是我们很多开发团队中经常遇见过的，也是本解决方案着重描述术的情况。从根本解决工作项优先级的问题，系统地学习怎么样应对需求变更才是根本。解决方案思路我们知道了管理好工作项是解决问题的核心，那么在形成工作项之前，我们需要解决谁对工作项负责或者说工作项来源的问题，然后要针对工作项做好工作计划，这样开发团队才能很好的执行。首先，明确产品经理，做到需求来源唯一。其次，梳理产品待办列表，高优先级的工作项先做。然后，重新定计划，确保开发团队容量适合，合理更新迭代目标。再然后，回顾总结，选出改善点，下个迭代做得更好。最后，几个迭代下来，度量分析，不断改善。另外，同步需要进行的是人才的培养，向跨职能型团队努力。解决方案思路示意图如下： 明确需求责任人明确需求责任人，做到需求来源唯一。在DevCloud中一般指产品经理充当这个角色。需求责任人至少同时要面对两个方向。方向一，需求责任人必须很好地理解项目中的利益干系人、客户和用户的需要（包括前面提到的突发工作项）及其优先级，以便能充当他们的代言人。从这个角度理解，一般是产品经理充当需求责任人。方向二，需求责任人必须与开发团队交流要构建的特性及其构建顺序。需求责任人还必须保证特性的接收标准已有明确说明，让开发团队可以确定在什么情况下需求责任人可以认为特性完成了。在这个角度理解，一般是业务分析人员和测试人员的角色。同时，需求责任人还要在版本、迭代和Backlog层面都能够持续做出良好的经济决策，管理经济效益。为了统一叫法、便于理解，后面需求责任人都由产品经理充当（类似Scrum框架中的产品负责人）。总结一下，产品经理的主要职责如下图所示：图中标亮部分的产品经理职责就与迭代中对应这些突发性工作相关了。产品经理需要与利益干系人充分沟通，确定这些突发的工作优先级别，同时从业务价值和管理经济效益等维度考虑，明确是否一定要在本迭代中完成。一旦确定这些突发工作属于高优先级，必须在本迭代中完成，那就需要重新梳理工作项了。梳理Backlog梳理Backlog，高优先级的Backlog放到迭代待办列表即迭代中（更多关于迭代待办列表的内容请参考下面的“了解更多”）中先做。首先，我们一起先来了解一下什么是Backlog。Backlog是一个按优先顺序排列的、预期产品功能的列表。其次，再来理解一下什么是工作项。工作项是Backlog中的待办事项。对用户和客户来说，大多数的工作项都是有实际价值的特性和功能，当然也包括一些需要缺陷修复、技术改进、知识获取等工作以及产品负责人认为有价值的任何工作（当然有价值的突发性工作也属于工作项）。然后，什么是梳理？梳理是指三大重要活动。第一，确立并细化工作项；第二，对工作项进行估算；第三，为工作项排列优先顺序。下图说明了通过梳理活动改变Backlog的结构：梳理后，对应DevCloud中的体现，如DevCloud梳理活动结果图所示。经过产品经理梳理后，如图红色框线部分，突发培训任务的工作项得到了合理的优先级，而且是经过工作量估算，同时将原来的查询产品名称任务进行了拆分细化。产品经理是梳理活动的最终决策者，也就是说突发性的工作由产品经理主导梳理。优秀的产品经理能够充分协调利益干系人安排足够的时间，根据开发团队的特点和项目类型来开展梳理活动。同时开发团队还要估算新加入突发工作的工作量，帮助产品经理根据技术依赖关系和资源约束来排列工作项的优先顺序，如果新加入突发性培训任务的工作项优先级高，那么就会纳入本迭代代办列表中。 重新定计划重新定计划，确保开发团队容量适合，合理更新迭代目标。在重新定计划之前，我们一起来了解下什么是敏捷下的计划，敏捷提倡的计划和传统瀑布开发模式下的计划有什么区别。我们知道敏捷宣言中提倡“响应变化高于遵循计划。”，它与传统瀑布开发模式或者说计划驱动的顺序开发模式的计划不同点就是一个是偏向响应变化，一个是偏向遵循计划。顺序开发过程中，是计划驱动，计划是工作如何开展、何时进行的权威信息源。因此，计划是需要遵循的。相比之下，在敏捷中，根据实时信息关注适应重新制定计划胜于遵循计划。我们认为盲目的相信计划往往会让我们忽视“计划可能有错”这个事实。敏捷开发过程中，我们的目标不是满足某个计划或者某个事先认为事情如何进展的预言。相反，我们的目标是快速地重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。因此，通过梳理以后的工作项,可以对应的调整计划。原计划准备做的工作项可能被移入到下一个迭代中实现，这里体现的是“等价交换原则”，意思是用优先级高的突发性工作项，替掉同等工作量的其它工作项，这也是为了保开发团队按照一个稳定的节奏交付。因为固定的开发团队一个迭代中容量是不变的，新加入突发工作项而不移除其它工作项势必会给开发团队交付带来压力，破坏开发团队的交付节奏。等价交换示意图如下：具体在DevCloud中的体现，如【等价交换图一】和【等价交换图二】所示。                                                                                           【等价交换图一】                                                                                        【等价交换图二】最后，从迭代中选取差不多工作量的低优先级工作项移回到Backlog中，即在DevCloud中完成了工作项的等价交换。 迭代回顾，识别改善点迭代回顾是一个会议，目标是持续改进流程，根据开发团队的需要改进和制定流程，以提高士气，提高效率，提高工作产出速率。几个迭代下来，需要对这类突发工作进行度量分析，识别改善点，持续改善。虽然我们提倡响应变化高于遵循计划，但同时执行迭代的时候也需要开发团队在不受干扰的情况下全力以赴的迭代。因此，就应该思考为什么每个迭代中都有外界的干扰（突发工作）存在，开发团队共同学会分析和找到解决办法才是真正的解决问题之道。这里给出一个DevCloud产品很好的小实践，可以提供客观数据帮助回顾。新纳入迭代待办列表的突发性工作项可以在DevCould的“模块”下进行管理。也就是说，在新建User Story之前建立一个“突发任务”模块，然后将User Story中的“模块”属性选中它。这是为了在后续几个迭代中对这类突发性工作进行度量分析（可以按模块排序，方便度量分析）以便持续改善做准备。如下【新建突发模块图】和【新建User Story图】所示：                                                                                        【新建突发模块图】                                                                                               【 新建User Story图】选择【报表】—【新建报表】—【自定义报表—【增加筛选条件（模块）】—【按迭代维度】—【保存】。然后对统计出来的数据进行分析。可以以图和表两种方式展示，具体如【按图展示】和【按表展示】所示：                                                       【按图展示】                                                  【按表展示】 同步进行人才培养同步需要进行的是人才的培养，向跨职能型开发团队努力。不仅仅是应对处理突发性工作，而是让开发团队更高效。每个任务应该由谁来做，或者说突发性工作应该由谁来做？答案很明显，应该是能够最快且正确完成这个工作的人来做。如果这个人不在了怎么办？或者他正在做其他工作，抽不出时间，但这个任务需要马上完成。开发团队成员都有责任考虑各种不确定因素，做出最好的选择。如果开发团队成员都是T型技能的时候，每个任务都有好几个人可以做，那么开发团队就能够在迭代执行期间几个人全力完成制约工作项流程的任务，更灵活地平衡资源，使开发团队更高效。了解更多什么是迭代待办列表？迭代待办列表在DevCloud中称“迭代”，它是一组为当前迭代选出的产品待办列表项，同时加上交付产品增量和实现迭代目标的计划。迭代待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能能到“完成”的增量中所需要工作的预测。当新工作出现时，开发团队需要将其加入到迭代待办列表中去。随着工作的执行或完成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。在迭代期间，只有开发团队可以改变迭代待办列表。迭代待办列表是高度可见的，是对开发团队计划在当前迭代内工作完成情况的实时反映，该列表由开发团队全权负责。迭代待办列表在迭代计划会议中形成，其中开发团队不会被动分配任务而是由开发团队成员主动认领他们擅长和喜爱的任务。任务被分解为以小时为单位，建议任务不要超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。每项任务信息包括其负责人、工作量、承诺的完成时间及其在迭代中任意一天的剩余工作量，且仅开发团队有权改变其内容。参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。2、Scrum 指南2007版。 3、Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。----------------------------------------------作者随笔作为敏捷推广者和马拉松爱好者，聊聊敏捷与马拉松。一个胖子想变成瘦子，方法很多，比如无氧器械、疯狂单车、要命波比跳，当然还有马拉松。近年来马拉松被炒得火热，引得大家蜂拥而至。马拉松看似简单，实际上一个优秀的跑者是需要长年的基础训练和日积月累的跑量。有些人参加拉松是为了赶时髦，全凭三分热度，急于求成。往往前者已达终点，后者却在半路怀疑人生，早早弃赛。敏捷转型就像马拉松一样：理论实践vs基础训练，稳定速率vs平稳配速，定期回顾vs适时补给，持续改善vs健康奔跑，团队稳定vs跑得长久，个人有所长，团队全功能vs个人跑得快，群体跑得远。如果没有夜以继日的“内功”修炼，想要一朝练成“碧海潮生曲”，无疑是天方夜谭，必以失败告终。—敏捷江湖桃花岛 黄药师附件：开发团队如何管理琐碎、突发性任务.pdf[hide]链接: https://pan.baidu.com/s/1iP8JExPhIXfzKin0Jr0k4A提取码: 5nxp[/hide]

概述围绕项目需求变更频繁，如何做好有效的需求管理和规划，本文从背景、问题分析、解决措施、如何进行需求结构化管理？如何进行需求优先级管理？如何避免重要需求遗漏？几个方面进行了细致解答。全文字数：__2662 字__，预估阅读时间：___7 分钟__。全程干货。背景不管是项目型软件开发还是产品型软件开发，需求变更频繁都是影响研发效能的第一号因素，在2019年中国DevOps现状调查报告中也可以发现，超半数企业认为需求的频繁变更是阻碍软件按时交付的主要原因。解决或缓解需求变更频繁带来的影响，是势在必行的重要工作。联想阅读2019年中国DevOps行业现状报告：中国信息通信研究院、华为云DevCloud、南京大学联合发布    问题分析由于每家企业的情况不同，包括客户合作方式、人员能力水平、研发流程等各方面的差异，同样是需求变更频繁，所体现出来的具体症状却有所不同，导致问题发生的根因也可能不同，所应采取的措施也需要根据实际情况来选择。根据我们的观察以及与企业交流的经验发现，一般都体现为如下几种情况，接下来我们结合这些情况的部分实例来分析：第一种情况：需求杂乱、经常变更，难以管理；第二种情况：领导或客户时不时地要把某些需求提前，打乱了开发计划；第三种情况：做着做着发现有些需求遗漏了；【第一种情况】软件项目前期结构清楚，开发到后期，需求变化多而细，如何管理，如何规划。困扰我们的是前期需求不明确、不完善，导致后期需改动，需求需要发生变更。而使用DevCloud的项目管理的支持不够。我们发现出现这种情况，往往跟客户未能正确使用需求规划有一定关系，存在着需求层次划分不清晰、缺少规范机制等问题。例如，某客户规划一个用户登录功能，按照下图所示规划需求。用户会将其中管理员登录的Task放在第一个版本中发布，后期又增加了一个手机号登录的需求，设置成Task放在第二个版本中发布，这样一个Story里面存在多个不同版本（或迭代）发布的Task，不方便管理。由此我们可以将这个问题的根因定性为如何进行需求结构化管理的问题：没有区分跟随项目进展而持续产生的碎片化需求和系统/产品持续完善的功能特性；对DevCloud提供的Epic-Feature-Story的需求结构理解有误，未能正确使用；【第二种情况】软件项目进行过程中，领导需要提拉需求，在敏捷研发模式中该如何去操作？提拉需求的意思也就是要将某些需求的优先级提高，要求团队先实现它们，因而我们将此问题定性为需求优先级管理的问题。解决此问题，我们需要了解：为什么领导会要提拉需求？如果是合理的，那么我们就应该提升响应能力、优化工作安排流程，使得优先级调整对研发进展带来的影响最小化，且我们能够尽快地响应领导需要，先交付被提拉的需求；这种情况发生频率有多高？如果是经常发生，那就是一种常态，而且是一种不好的常态，那我们需要去思考是什么导致了这种常态发生，并考虑如何从流程、制度、协作模式或人员能力等方面去做调整，减少过程中提拉需求情况的发生；如果是偶尔发生，那就可以特事特办，为例外情况调整流程、制度反而会加重常态工作的负担，没有必要；需要提拉的需求有无共性特点？比如是否都跟某个客户有关，或者跟某个功能域（如退款）有关？如果能够找到共性，那我们就可以针对这些共性去思考针对性的解决方案。【第三种情况】由于外界原因经常会临时增加一些紧急需求，并且这是目前常态临时增加需求，首先是一个如何处理突发需求的问题；紧急需求，也就是说需要马上就做，而且是插队，那就不仅仅是紧急，肯定也是重要的需求，不然不需要插队先做，所以这还涉及到需求优先级管理的问题。但是当两种情况合在一起，我们需要将它定性为是重要需求遗漏的问题，反问一句就是 —— 为什么这些紧急重要的需求无法更早预见？同样的，我们需要了解：具体是哪些外界原因？这些原因是否有共性，有的话，那就针对性处理；增加的需求有无共性特点？有的话，可以针对性处理；临时增加有多临时？我们是否有提高或改善响应能力的空间，如果我们可以更快调整和响应，使得这些临时需求对我们产生不了什么影响，那么这个问题也就不再是问题了；既然是常态，为何我们的流程没有做出调整去应对？是调整过流程或工作方式，还是无法解决问题，还是说不知道该怎么调整流程或工作方式去适应？解决措施综上，前面几种参考情况经分析后得出了根因，基于这些根因，我们将所要解决的问题重新描述如下：如何进行需求结构化管理？如何进行需求优先级管理？如何避免重要需求遗漏？如何进行需求结构化管理？首先，并不是说任何情况下都需要进行需求的结构化管理。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。那么我们应该以什么为脉络来建立这个结构呢？这就意味着，我们的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。简单来说，可以通过如下三个步骤来完成：针对产品或系统建立DevCloud项目确立Epic-Feature-Story的需求结构对不同模块以及版本的管理，可以通过工作项的属性来进行管理联想阅读 【华为云 · 敏捷智库】如何进行需求结构化管理？如何进行需求优先级管理？需求优先级的管理，其实是为了帮助我们确定先做哪个需求后做哪个需求，从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理，或者更直接来说是优先级顺序管理，我们需要做到如下几件事情：确定优先级模型：需要考虑的因素以及因素的综合判断原则，比如Kano模型；排定需求优先级顺序：因素的具体量化和排序标准，例如成本收益法是按照收入还是按利润的多少来排序；调整需求优先级顺序；改进优先级模型：根据反馈调整模型或模型的落地实施细节，以提升效果；联想阅读【华为云 · 敏捷智库】如何进行需求优先级管理？    如何避免重要需求遗漏？根据重要需求遗漏的事前、事中、事后的不同时间点，我们可以采取不同的措施。参照八二原则，我们需要确保常态问题有对应的处理方式，软件项目成员按照既定方案进行处理即可，而特殊情况要有应急机制指导现场处理、事后再复盘总结。事中的处理：按照常规做法进行处理，或是特殊情况特殊处理，先解决眼下的问题；事后的处理：基于模型或思路进行复盘，并落实为新的常规做法或特殊情况处理方式；事前的处理：明确如何区分常规情况或特殊情况，并制定相应的处理方式或应急机制；联想阅读【华为云 · 敏捷智库】如何避免重要需求遗漏？参考附录相关文章敏捷联盟网站上的Epic术语解释：https://www.agilealliance.org/glossary/epic维基百科上的Kano模型词条：https://en.wikipedia.org/wiki/Kano_model相关书籍Mike Cohn：《用户故事实战》杰拉尔德·温伯格：《成为技术领导者》邱昭良：《复盘+：把经验转化为能力》

黄隽 Charlie序  言随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱、文献，活跃于敏捷大咖们的议题讨论，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容分享给那些已经或者正准备踏上敏捷之路的朋友们，用于个人学习、研究和讨论，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。正常情况下的移动使用看板主要意图之一是控制在制品数量（WIP, work in process）,需要拉动式的移动，这样可以有效控制在制品数量，防止工作项过多积压。另外需要提示一点，在整个移动过程的前提是需要制定一套移动规则，具体什么样的规则这里不做过多的描述，根据团队自身情况定义就好，规则根据团队意见可以调整几次，最后团队满意就是合适的。需求变更情况下的移动不接受变更当一个Sprint的Sprint Backlog和Sprint 目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog,因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。 拥抱变更完成拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况：1)    无价值需求与PO沟通协商，对于无价值需求果断拒绝，当然是与PO协商后的结论，看板中的卡片不做任何移动。至于这些无价值的需求怎么来的，情况比较多，这里不做引申了。2)    变更少，影响小的需求高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程,然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理:一种是移回到Product Backlog列,这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看中的团队，团队需要对工作量进行有效统计。当然第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。3)    变更多，影响很大的需求高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。

为什么要进行需求结构化管理？首先，并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用DevCloud的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。以什么为依据进行需求结构化管理？需求结构化管理，应该以什么为脉络来建立这个结构呢？软件研发无非是分为项目型软件研发和产品型软件研发两种，项目通常来讲都是临时性的，或者说短期性的，而产品或者软件系统是长期性的，或者说我们会持续维护、更新其功能特性的。项目复项目，我们很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标，交付软件项目所要求的功能特性的。这就意味着，我们的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。使用DevCloud进行需求结构化管理的一种方式接下来，我们介绍推荐的一种方式。一、针对产品或系统建立DevCloud项目也即一个产品或系统，建立一个DevCloud项目，该产品或系统的所有需求，都在此DevCloud项目里面进行管理。二、确立Epic-Feature-Story的需求结构这个产品或系统的业务模块作为Epic，比如用户中心、购物车、配送管理等，比如一家货运云商，他们的油卡业务，就适合作为一个Epic，针对油卡的各种功能，就可以作为Feature展开；Epic要承载业务价值，也即Epic需要是对企业本身是有意义的；针对前面业务模块的具体展开、拆开，就可以作为Feature，也可以简单理解为一个业务流程、用户流程；以前面用户中心为例，用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature；或者以油卡为例，购买油卡、我的油卡等就可以作为不同的Feature；Feature要承载用户价值，也即对于用户来说，是可以理解这个Feature，且认可其价值的，通常Feature也是用户可以直接感知、可以操作的；Feature往往还是有些大有些复杂，那就需要拆成颗粒度更小的Story，用来承载一个具体的用户操作，例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能；再往下一级的Task，就主要是为了分工协作，也即是说，如果Story可以包干到人，那么不再拆分Task也是可以的；Task往往是关于工程师需要具体做的工作，也就跟业务价值、用户价值、用户单步操作都没有了什么关系，通常都是把Story按照具体的组件、模块进行拆分，例如前端、后台、数据库之类的，或者是按照工作流程分工来拆分，例如UCD、开发、测试、部署等；如下图所示，各层级为：Epic：用户中心Feature：地址管理Story：用户可以新建地址Task：【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现三、不同模块以及版本的管理可以通过工作项的属性来进行管理，如下图：模块：Web端发布版本号：1.0.1.2至于模块清单的维护，可以在工作项编辑状态，点击“模块”字段右侧的小齿轮图标，即可在弹出窗口进行操作，可以添加、修改、删除模块：在工作项管理的Backlog视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，当然也可以进行过滤：参考附录相关文章敏捷联盟网站上的Epic术语解释：https://www.agilealliance.org/glossary/epic相关书籍Mike Cohn：《用户故事实战》

        最近想要可能会接一个用Teambition的项目，借此机会也了解一下。Teambition很久之前了解过一点，之后就没用过了。Teambition这个在业界的知名度还是可以的，现在因为区政府和华为云合作，所以都是使用的华为软件开发云。使用华为云有一年的时间了，这里着重讲一下软件开发云这一块吧。华为云软件开发服务（DevCloud）是集华为近30年研发实践、前沿研发理念、先进研发工具为一体的一站式云端DevOps平台，面向开发者提供的云服务，即开即用，随时随地在云端进行项目管理、代码托管、代码检查、流水线、编译、构建、部署、测试、发布等，让开发者快速而又轻松地开启云端开发之旅。在使用华为云之前，项目管理使用的是DevSuite等工具，代码管理使用的是git，然后项目部署多是使用jenkins。整个软件开发过程中，使用了不同的工具，对于初学者而言是需要学习不同工具的使用，而且各个工具之前并没有关联性。软件开发服务，可以很好的把上述的问题解决，所有软件开发周期，都是通过一个工具来解决。代码的提交都可以与需求关联起来，软件发布部署，可以设置自动化部署，当项目有提交的时候，可以自动部署，方便快捷。省去了中级人工操作的步骤。总体来说，使用了华为云软件开发服务之后，开发效率大大提高，尤其是管理效率，多部门之间的配合程度更加密切，特别适合管理者使用，了解项目进度和问题等。        此外近期还接触了jira，感觉只是作为项目管理的话，jira也不错也有自己的优势，只是侧重点不同。华为云DevColud的其他优势，本次测评没有突出，其实我更看重的是全流程的打通，代码管理、项目管理、代码编译发布等这个是一个特色。希望这个产品越来越好。