项目管理首页菜单栏中的“新功能”怎么查看？不能点此图标进行查看，如下图：

背景目前，Scrum和看板已成为了帮助团队贯彻敏捷的重要方法，我们也能经常看到敏捷爱好者在关于二者在各类社区、场合的讨论。无论是交流分享还是企业的咨询实施，关于Scrum和看板的讨论就一直没有停歇过。那么，对于一个正准备实践敏捷的团队，到底应该如何选择呢？问题分析一般来说，客户会纠结Scrum和看板的选择问题，主要是因为不清楚Scrum和看板方法的区别，不知道哪种更适合目前的项目或团队，也不清楚Scrum和看板方法能应对哪些场景。首先，从Scrum和看板方法的比较来了解两者的不同，见下表：描述Scrum看板方法目的探讨未知，处理新的、复杂项目自我检讨、消除浪费、得到好的效能团队角色产品负责人，Scrum Master，开发团队没有指定的角色度量指标团队速率生产周期、WIP（在制品）多变性承诺在Sprint周期不发生改变变化随时可能发生交付周期固定的Sprint时间盒完成一项工作的时间表： Scrum和看板方法的特征比较如上表所示，Scrum和看板方法在不同方面特征有所不同，企业在选择使用Scrum和看板方法的时候，可以根据上表中二者的特征并结合不同的实际情况，做出选择，具体参考如下情况和详细解释：情况Scrum看板方法团队所做的项目VUCA、需要一定的可预测性√团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级√项目需要有固定的迭代交付时间（2到4周）√项目的初期探索迎合市场的阶段√团队规模较小（不足5人）或较大(9人以上)√表： Scrum和看板方法的选择情况1：团队所做的项目VUCA、需要一定的可预测性在VUCA（详见参考附录中的解释）的时代，很多团队做的是易变的、不确定的、复杂的、模糊的项目，如互联网项目。针对于这样的特性，团队如果需要在某特定的时间发布或推广产品，以达到一定的市场预期的话。团队一般会将需求进行拆分和细化，如 Epic、 Feature、 User Story 、Task后，制定发布计划。随着拆分为较小的需求后，团队可以通过检查每个Sprint的进度并进行调整，从而预测交付时间，进而确保整个项目成功交付，Scrum是首选的方式。情况2：团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级Scrum的价值观之一是，承诺在Sprint内对计划不做修改，如果团队经常会应对紧急情况或者修改任务的优先级，那么看板方法因其灵活的工作流程可以更好的适应。情况3：项目需要有固定的交付时间（2到4周）在Scrum中每个Sprint的时间长度是固定（2到4周），并且每个Sprint结束后会交付潜在可交付产品增量，如果项目需要有固定的交付时间（2到4周），那么Scrum是比较好的选择。情况4：项目的初期探索迎合市场阶段以市场为导向的产品，产品越年轻，使用Scrum方式就越可能受益。因为在开发全新产品，尝试实现PMF（产品市场契合）或努力保持产品增长时，通常面临许多未知因素以及大量不确定性和变化。要通过迭代不断的输出增量以获取市场的反馈，进而更快更好的迎合市场的需求，所以Scrum是比较好的选择。（详见参考附录中的Scrum适合你的项目吗？）情况5：团队规模较小（不足5人）或较大（9人以上）Scrum团队理想的规模是2个披萨团队，给出的建议是5到9人，如果团队不足5人，在人员方面可能无法发挥Scrum的最大功效或存在一定上的浪费，那么建议使用看板方法。（Scrum of Scrums 不在此FAQ讨论范围内。）解决措施目前很多企业和团队，都是通过工具在实践Scrum或看板方法，华为云的DevCloud也是基于敏捷思想设计的DevOps工具链（更多了解请见附件或官网），以DevCloud为例，在DevCloud中提供了更加鲜明化的Scrum项目和看板项目的选择，具体可以参考根因分析中针对不同情况选择不同的项目（详见，表： Scrum和看板方法的选择）从目的来说，Scrum主要是为了探讨未知，处理复杂（VUCA）项目从而提升效率，而处理和效率的字眼往往是和时间关联起来的，如要在一个什么样的时间得到什么样的结果，这也是要求了时间把控上或者说做计划的能力，当团队所做的项目为了这样的目的，那肯定是选用Scrum，哪怕团队的规模没有达到Scrum所推荐的5到9人，或者是团队要为估算所浪费的时间开销而苦恼，又或者说在一个Sprint中需求经常变更等情况。因为不管是人数的问题也好、还是估算的问题也好、又或是需求变更的问题都是可以通过团队在回顾中不断的分析、复盘、总结慢慢优化的，如估算问题，那就提高估算能力减少开销；如时间开销问题，可以通过熟练度的提升、形式的改变来较少开销。总之，只要核心是不变的或者说关注点是围绕Scrum目的就应选择Scrum项目，典型项目有：新的应用程序开发、品牌发展、营销活动、具有季度/定时发布时间表的大型企业等。相反，如果团队的关注点就是以优先响应需求的能力，需求是必须要随时跟进和变更的，项目的可预测性、产品市场的契合度等的优先级并没有成为超过响应能力的话，那么看板项目就是一种更好的选择，因为这正是看板方法的优势，让价值能够快速的流动起来，以更快的满足客户的需求，典型项目有：生产支持、补丁发布、UX设计、营销宣传材料、新闻稿等。所以，对Scrum项目和看板项目的选择上，一定参考的是客户认为最重要的关注的点是什么。以目的驱动做响应的选择。另外，在DevCloud的Scrum项目也提供了看板的视图，可以很好的在Scrum的项目中使用看板方法，进而让Scrum可以和看板有效的结合起来，发挥更强大的效能。在DevCloud中， Scrum项目是以Scrum框架为核心的，提供用于处理探讨未知，处理新的、复杂项目的项目类型。Scrum项目提供了类似思维导图的方式，用来整理需求做项目规划，并提供了Epic 、Feature 、Story、Task的四级需求划分，如下图。在Scrum项目中的迭代视图中，未规划工作项相当于 Scrum中的 Product Backlog，当前的迭代相当于Sprint Backlog，可以很好的结合Scrum中Product Backlog和Sprint Backlog两个工件，如下图。Scrum项目提供了通过切换卡片模式转为看板视图，以用来Scrum和看板有效的结合起来，如下图。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。在DevCloud中，看板项目是以看板方法为核心，为团队提供流程可视化、限制WIP， 加速价值流动，以更快的满足客户的需求，看板项目中提供了非常友好的可视化看板板，默认提供了，新建、进行中、测试中、已关闭等状态列，用来标示任务的状态，可以通过拖拽的方式来实现任务的价值流动。团队在使用看板项目时，还可以修改默认提供的列（修改列名等）和自定义列以实现项目或团队定制化需求。此外，看板项目还提供了很多过滤和显示的快捷和便利操作等。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。参考附录Scrum适合你的项目吗？DevCloud项目管理用户指南Scrum 指南2007版VUCA 维基百科

华为云账号：HUAWEI_TX微信昵称：那年夏天总结一下：这次体验评测华为云DevCloud项目管理服务与管理协作工具Teambition，这里着重说明两点，希望华为云DevCloud项目管理服务，能够参考借鉴，改进产品，越做越好吧。管理协作工具Teambition相比较来说，界面更加简单，操作更加流畅。尤其对于一些常用功能，设置的位置比较明了，操作起来比较流畅，并且对于一些常用属性设置和非常用属性默认下拉菜单隐藏，我觉得这种做法非常棒，也增加了操作的简单流畅度。还有一些问题，我在体验评测PPT里也做了具体截图情况说明，希望华为云DevCloud项目管理服务参考改进，越做越好。

DevCloud项目管理系统不论是从整体的设计风格上还是从内容的设置上，个人觉得还是有待进一步优化。比如前端界面的一些按钮可以突出下位置，一些样式还是需要好好设计一下，可以借鉴一下其他的项目开发流程软件的界面设计，需要一个整体性的布局。内容的话，基本的功能和Teambition是一样的，但是有些细节的地方对用户还是不够友好，而且一些功能比较难找到，这会严重降低系统的易用性。Teambition是后面体验的，整体感觉要比DevCloud好很多，不论是在内容上还是在外观设计上，都很好，个人觉得DevCloud有很多可以借鉴Teambition的地方，具体建议的细节我已经写在了测评任务卡中，希望官方采纳。另外，还有一个建议，本次测评中很多的功能，在任务卡中的名称和实际系统中的名称是不一致的，这样导致我们会很矛盾去怎么做，最起码的这种名称应该一致才好，这样也会节省体验官很多时间。附件：word为比较完整的测评DevCloud的报告，PPT-1 中主要是对DevCloud中每一个测评任务给出的打分，整体评价也在ppt中。PPt-2 中主要是体验Teambition的测评分析及打分情况。姓名：王誓伟昵称：世伟

输出见PPT中，整体体验顺利群内昵称：极客潇

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

尊敬的华为云客户：为了提供更便捷的备案服务，华为云将上线备案用户真实身份电子化核验功能。自2019年9月12日起，您在华为云办理ICP备案可以通过华为云App进行“ICP备案主体真实身份信息采集”和“备案材料电子化提交”，在线即可完成备案信息资料提交和真实身份核验， 不再需要背景幕布前拍照核验等线下操作，极大的减少备案的复杂度，流程更简单、便捷。如有疑问可随时通过工单或致电华为云备案服务热线+86-4000-955-988或950808按1转5进行咨询。感谢您对华为云的支持！

写在前面根据我的经验报告中的截图一定都会丢失，这次因为太大了也不能附件上去，所以我 带图的报告详见http://note.youdao.com/noteshare?id=07ba4d712c81993e2b199b04ffbc270b今天用了 3 个小时左右的时间完成了这个测试和报告。为了保证测试的一致性，所有测试均在 Mac+chrome 上完成。一下所有提到的问题也都在这个配置上发现的。华为的产品功能很强大但是或多或少发现了不少问题，teambition 虽然功能室没有华为的强大，但是清爽，基本上功能都可以实现并且快捷键保证了各种电脑均可以使用。评测概括：1. 界面设计是否易易读？信息组织及页面关系是否清晰？华为的产品界面设计明显有点不伦不类，大部分地方是汉语有些地方是英语，给人一种凌乱的感觉，最好统一下,teambition 没发现这个问题2. 系统反馈是否明确？还不错3. 术语使用是否易易懂？帮助文档和学习资料是否充足？这次的体验中，工作项，工作流区分不是很清楚，建议做好定义4. 是否容易学习、便于记忆？需要学习的系统都不是好系统，所以基本还不错5. 系统性能是否稳定可靠？单个用户使用肯定6. 是否满足线上场景需求？小 bug 太多，细节都在详细过程里面7. 完成任务的障碍是什么？小 bug 太多，有些情景需求不明确，有些功能找不到比如华为产品找不到批量修改任务优先级，teambition 找不到新建的工作项状态和指派人对应。详细过程场景一：近期公司启动了一个全新的员工信息管理系统开发项目，您作为项目经理，打算在DevCloud上进行敏捷管理。大致了解了产品特性和操作教程后，您决定先创建一个Scrum项目进行体验。任务一- 创建scrum项目，总体来说没啥问题点确定以后，自动进入到了新建的项目中了这里提一个建议：默认还是这样但是如果可以让用户选择比如创建完是进入到项目，还是返回首页原因： PM 不一定只有一个项目，他可能想批量创建任务，如果每次都进入到项目比较烦人中英文支持都不错任务二： 任务说明：创建一个Story类型的工作项。创建的过程还是比较简单的，添加附件拖拽就可以。速度也很快里面做的和 confluence 很像可以@别人很不错，但是只有一个账号没有测试。但是这里有2 个 bug（我认为是 bug).1. 我把需求复制到下面的详细描述框的时候，复制粘贴的内容自动成了图片格式！！！，不能修改。我测试了很多次都是这样。有点不友好，还是希望可以粘贴成文本格式然后可以修改2. 点击创建完的项目，提示错误‘测试管理服务未开通’，我不确定是测试环境的问题还是本身的 bug,你们可以自己研究下总体评价 5 分任务三 - 任务说明：创建一个迭代。、迭代的创建时点击工作--》迭代==》创建 总体来说没啥问题。又到了提意见的时间：迭代名称看样子是不支持阿拉伯数字，看上图，建议做 类ajax的提示，或者直接在旁边加一个 help 说明名称的语法类型还有就目前的这个错误提示也不是很清楚为什么不合法，写清楚点。总体评价 5 分场景一- 任务四 - 任务说明：完成如下需求规划，创建一个Epic类型工作项，将其拆分为两个Feature类型工作项，再为第二个Feature类型添加一个子工作项Story按照提示先创建 epic ,然后弹出两个按钮，一个删除，另一个是创建子项，设计的不错创建完以后是这个样子快捷键说明有问题：这个快捷键明显不是针对 Mac 的，mac 上没有 insert 建场景二：项目开始两个迭代后，您发现系统默认的工作流不能完全满足企业的工作场景，您需要将评审环节也纳入到研发流程中来；同时，您也希望将某些环节变得自动化，以减少日常人工操作。后，您决定先创建一个Scrum项目进行体验。任务一：工作流状态添加，设置转换找了将近半个小时，在两个地方找到设置，一个在设置里面，另一个点状态里面有一个新建。。藏得太深了。。建议优化。。。任务二：把 story 状态改成评审，自动分派给小明和对应的 comment.场景三任务一：任务说明：进入"车辆管理系统"项目，在迭代3内管理任务：在列表中，直接把第一个工作项状态改为“测试中”在列表中，把第二个工作项挪到"迭代4“在列表中，将所有工作项的优先级批量修改为"高"我没有找到如何把工作向优先级批量设置为高，只找到怎么样一个一个设置场景四-任务一创建一个报表，统计迭代2中工作项数的燃尽趋势，并将其保存为"迭代2燃尽图"。工作项数的燃尽趋势比较简单，因为有默认的模板任务二：创建一个报表，统计迭代2内不同工作状态下的工作项数，并将其保存为"迭代2状态统计图"。和上图一样无非就是筛选条件不一样，直接上图不赘述场景五除了新项目以外， 您的公司还有一些维护中的项目。您觉得Scrum这种类型过于严格，于是采用看板类型的项目来管理这些项目，可以直接的呈现团队工作情况，快速处理任务，避免任务堆积。任务一：创建比较简单，邀请用户这有一个严重的 bug 看图当每页 30 记录没问题当每页显示 10 记录的时候，每页只有 9 条记录，并且找不到用户小明！！（我已经拉到最下面了）实际上 test9, test 19,test30 都没丢了没显示 （在设置--》成员管理 没有问题，但是新建项目自动弹出邀请成员有这个问题，测试了两遍可以重现）场景六场景 6 没啥可说的，就是双击会出来一个添加列，创建。但是不看说明书得测试半天才知道。。任务一：为当前工作流增加一个状态"设计中"。任务二，添加子任务场景七 -任务一：进入"市医院挂号系统"项目，为当前处于"就绪”状态的工作项“就绪的需求，等待启动后续的工作"添加为3条任务：任务1，任务2，任务3。总体来说也比较简单，和 trello 差不多任务二创建一个工作项"医生个人头像上传”，根据您平时的工作习惯酌情填写工作项描述、开始时间、完成时间，以及处理人等信息。就是普通的创建任务项任务三切换分组，状态拖过去然后指定人，也比较简单场景八任务一 :快捷键问题：快捷键对 mac 很不友好，ctrl 到底地是用 control 还是 command .我测试了下好像都不行 （测试的保存和保存关闭）后面的 Teambition 的测评报告场景一任务一敏捷开发类型项目：创建和华为差不多，也是创建完直接进入项目没有选择任务二：任务说明：创建一个需求类型的任务。遇到了相同的问题，在备注复制粘贴成了图片。谁模仿谁不太好说呀。。任务三，创建迭代在任务自动提醒创建迭代比华为做得好，任务四创建一个需求类型的任务总体来说，比较明了，UI 做的比较好满分场景 2任务一创建任务流和华为一样找了半天场景三进入"车辆管理系统"项目，在迭代3内管理任务：这个和华为比，不好说好坏，自行判断，加入吧一个任务放到下一个迭代，在当前 filter 里面就看不到了，华为的还可以看到，写一次筛选才看不到在这里说一下批量编辑，非常好用，为了证明不冤枉华为产品我又到华为项目管理界面再去找，还是没找到批量编辑场景四任务一报表 感觉两者差不多，华为可供选择的更多任务二： 创建一个报表，统计迭代2内不同工作状态下的工作项数，并将其保存为"迭代2状态统计图"。感觉也差不多，华为的 filter 好像更多一点场景五任务一创建普通项目很简单， 特色是可以分组，华为好像不行任务二为工作流添加状态设计中也没遇到啥问题，很快场景六任务一 为当前工作流加入一个状态设计中这是华为任务最坑的一个，也不说清楚是基于普通项目还是敏捷项目，根据我的侧是普通项目没有这个选项，在敏捷任务添加成功任务二为刚刚增加的设计中状态设置指定处理人“huawei test” 。使得每当工作项状态被改为“设计中”时，处理人就自动变为“huawei test”。我没找到状态和处理人对应设计的地方，如果有人找到 ，可以指出来场景 七任务一任务一，添加子任务任务二：添加任务分组任务三：创建子任务没什么问题。创建就好了场景八 快捷键虽然 tembition 快捷键少，但是他的快捷键是MAC 非 MAC 键盘通用的。这边比华为好太多，简单测试了下新建任务啥的都可以用总体来说华为产品功能强大，细节不够，还是需要仔细修复下。另外最好提供下一些性能测试报告，比如一个公司人过来用会不会有瓶颈之类的

项目管理系统就是“一千个读者就有一千个Hamlet”，怎样在个性化中提炼出满足绝大多数PM需求的项目管理系统是个很大的学问。在我经历的项目中，有使用Excel、思维导图、Microsoft Project、甚至使用OA进行软件开发项目的管理，但效果都不是十分好，而自主开发一套项目管理系统，又太耗费人力、物力，最近teambition也找到上门让我们去尝试，但teambition用起来也是没有达到想要的效果，那就试华为云的DevCloud。华为其实是有IPD研发体系，虽然对于中小型研发团队不一定适合，但希望能在DevCloud中看到IPD的身影。然而一进DevCloud就心凉了，scrum、看板这是敏捷开发的东东，还以为是IPD……从整个测评过程中，最让我满意的是树状流程图其实倒是希望能将华为的IPD做进来。并且项目管理不仅仅是盯着研发进度，还要关联到整个项目的成本核算、运维跟进等等，一个不小心项目就亏本......但目前真的没有一款产品能做出来，希望华为云能做一个使整个项目从商机挖掘一直到交付验收、售后等等项目管理的全流程产品出来。当然融合IPD是最好，并且能将IPD中的某些步骤能进行个性化调整以适应公司的流程。

尊敬的华为研发人员：我在做需求规划时，发现有两个地方可以改进，现提供给您，在做需求规划时，作为用户我想要在新建story时可以复制已有的story后修改，以便于更改最少的内容。我想要在新建story时，新的story可以出现在当前的story下方而不是新建一个story然后拖上来，以便于更好的排序。谢谢！

DevOps的3大核心基础架构由于近年DevOps概念的火热，加之DevOps的涵盖面非常广，因此有很多文章和技术都在和DevOps强行关联，使很多想要了解学习DevOps的开发者迷惑不解。其实，DevOps的知识体系如果从顶层上来分解，可大分为2部分：方法论和工具链。方法论这部分，因为DevOps的很多理念脱胎于敏捷，所以你所能了解到的各种敏捷理念，实践和方法都可以作为DevOps知识体系的一部分，这部分在本文中不做赘述。本文主要说说关于DevOps工具链这部分内容。下图是一个DevOps工具链的元素周期表，提供给您作为参考。虽然表中内容十分全面，但并不易于理解与记忆，因此我们在这里DevOps的工具进行一个总结与归纳。简而言之，实现DevOps工具链，基本需要3个核心基础架构：SCM配置管理系统Automation自动化系统Cloud云（或者说可伸缩的、自服务的、虚拟化系统）SCM配置管理系统配置管理是DevOps最底层的基础设施。无论是Configuration As Code，还是Infrastructure As Code，强调的都是用管理代码的方式来管理环境。将环境版本化，无论对于快速创建，还是可稳定的重复创建这些DevOps的基本要求来说，都是最重要的基础。在周期表的左侧第二列所列出的就是各种可供选择的配置管理系统，如：GIT、SVN、Mercurial、GitHub、Bitbucket 等。对于DevOps实施来说，选择哪种SCM的一个重要考虑点，就是后续的Automation和Cloud这两个环节中的其它工具对这些工具的集成情况如何。作为近年来比较受欢迎的Git来说，这一切都不是问题，当然是最好的选择。SCM中所放置的内容又可以再分成2个层次，分别为：AppCode：即应用代码。EnvCode：即环境相关的代码，这部分内容又可以进一步细化成环境配置（Config）和配置数据（ConfigData）。环境配置：指那些针对当前应用基本上固定的环境配置。环境数据：值那些需要在部署的同时根据情况调整的数据，如：配置文件，开发、测试、生产环境的地址等等。Automation自动化系统自动化在DevOps中的作用不言而喻，这部分的主线一般由各种类型的Build系统来实现，如：Jekins、Team City、Travis CI、CC等等。仅仅有这些还不够，为了能够完成应用从开发环境到生产环境的迁移，我们还必须处理如编译、自动化测试、依赖恢复、容器构建、打包、编排等很多操作，因此还需要配置如Junit、Xunit、FitNesse、Selenium、NuGet、NPM、JMeter等许多其它的工具来实现。但这些工具只是在自动化系统中实现某一部分的功能，一般都需要由Build系统来驱动，并依赖于SCM中所提供的各种代码来实现的。因此我们现在通常选择华为云DevCloud这样能帮助团队完成DevOps端到端打通全流程的工具。在华为云DevCloud中提供了敏捷项目管理、配置管理、云测、部署、以及自动化流水线的DevOps端到端服务。通过DevCloud，用户可以一站式完成所有开发工作。Cloud云云服务的出现应该是催生DevOps的重要因素，没有云服务所提供的弹性、自服务等特性，很多DevOps的理念只能停留在纸面上。对于DevOps实施来说，我们需要了解的就是各种云所提供的API，因为无论是自动化系统还是前面的SCM的产出，最终都需要调用这些API来完成最终应用部署。在华为云DevCloud中，我们可以通过DevCloud直接调用华为云的其他公有云服务，例如ECS、CCE、SWR等，并可通过这些云服务帮助用户完成丰富多样的产品需求。通过编译构建任务的配置，将Docker镜像直接上传至SWR镜像仓库。通过调用ECS服务，直接将构建好的软件包部署到云主机中。

敏捷项目管理敏捷开发中如何制定项目计划？在对项目的需求进行简单的规划后，我们就要进入具体的开发环节。而在开发之前，当然需要对即将开展的工作进行计划。那么，在敏捷的开发模式中，计划是如何制定的呢？让我们以DevCloud这个产品为例，一起来看看DevCloud作为一款产品是如何制定它的开发计划的。两级项目计划计划是演进的，试图在项目一开始制定“完备”的甚至是“完美”的计划是不现实的。做计划的目的之一是减少风险，但在信息最少的项目初期阶段做出最重要的决定是不切实际并且风险巨大的。敏捷计划的模式是渐进式的，一开始只规划一个大的方向，并制定最近1-2个迭代需要构建什么以及何时完成的计划。随着项目的进展，新特性不断的增加并交付给客户，团队不断的获取有关产品、技术、市场、用户相关的信息，新的迭代计划也在不断的演进，但依然是经济并且现实的只规划最近的1-2个迭代。在此过程中，通过不断的交付价值与沟通反馈，建立团队内部彼此之间以及团队与客户之间的沟通、信任与信心。在DevCloud中，计划是分为两级的，第一级是大的发布计划，以月度、季度、年度为粒度，我们称之为路标；第二级是具体的迭代计划，以周或双周为粒度，这是团队开发及交付的节奏和心跳。针对Product Backlog进行分层，近期要做的拆分到Story级别，例如2-3个迭代内的；中期要做的拆分到Feature级别，例如3个月之内的；长期待定的就留成Epic，例如3个月以上的。产品发布计划DevCloud整体是一个DevOps平台，包括敏捷项目管理、代码托管、流水线、代码检查、编译构建、部署、云测、发布等多个服务，每个服务每周固定都会有一个上线版本，特殊情况可以做到按天的发布周期。在此情况下，将相关的新功能放在一个发布计划中依然是有必要的，发布计划就是产品的Roadmap路线图，在华为我们称之为路标。我们会以年为单位制定大的路标进行对齐，同时拆分到每个季度，路标代表我们产品演进的方向和关注的重点，是中长期的目标。目标一定会发生变化，所以路标会定期进行调整，体现了我们对市场变化的判断以及对客户反馈的响应。目前在版本历程中，我们以双周为单位定期发布产品的Release Notes。Release Notes很重要，是产品新特性的发布公告，是一种事后的告知方式。还有一种事先的预告，即Release Plan产品路标，可以让客户有所预期甚至提前获得反馈。计划是一个承诺，是一个目标，计划的目的是为了更好的响应变化；制定计划很重要，但盲目遵循计划就没必要了；更重要的是做计划的过程，而不是计划本身。敏捷也好，DevOps也好，都是为了应对快速的市场变化，以及更好的响应需求的变化。产品的发布计划也是如此，没必要盲目依从，也不会100%都达成（这种情况只能说明目标太没野心了），路标需要定期检查与调整；路标的发布同时也是一种获取反馈的机制，客户可以提出反馈意见，例如对在规划发布的一个功能非常喜欢或是非常不喜欢，都可以通过意见反馈系统进行反馈，产品会基于反馈信息进行判断进而调整发布计划。迭代计划一个发布由多个迭代组成，每一个迭代都要有具体的目标，迭代过程需要度量迭代速率，团队要根据自己的速率以及工程能力确定迭代长度。DevCloud目前的迭代长度为一周，由于设计与开发的依赖关系，所以我们的设计迭代与开发迭代会有一个错位，UCD设计会超前一周完成低保证及高保真设计，随后开发会进行前后端的开发工作。在迭代计划会议上，产品经理PD对高优先级需求进行串讲，团队提出问题，并充实或调整产品Backlog的优先级，进而设定Sprint目标。根据团队速率，选择进行Sprint Backlog填充。以目前一周的迭代长度而言，这一过程大概会进行1-2小时.使用Scrum项目模板管理制定迭代计划，并进行迭代开发通过DevCloud提供的迭代管理，可以帮助您快速的制定迭代计划、管理和追踪相关工作进度。迭代创建以及管理单击“工作 > 迭代”，进入迭代管理视图。  当前视图列出了所有的迭代，包含过去的3个迭代，接下来我们创建一个新的迭代作为当前迭代。2、单击“新建迭代”，输入迭代名称“迭代04”。设置迭代日期：开始日期为本周一，结束日期为下周五。单击“新建”按钮。 说明： 请按照实际情况修改项目迭代时间。系统会根据设置的时间周期自动将“迭代04”显示在“当前迭代”列表。3、按照同样的方式，创建“迭代05”，并设置开始时间与结束时间为下一个迭代周期。系统根据设置的时间周期自动将“迭代05”显示在 “将来迭代”列表。

敏捷项目管理规划项目并管理需求项目情景   刚刚接到业务部门的最后通牒，要求月底必须上线 【门店网络查询功能】，可以在凤凰商城中查询各个门店的相关信息。   应该如何对此功能模块进行规划呢？   首先让我们看看在敏捷的项目中，应该如何进行项目规划以及需求的制定。如何拆分需求   需求通常以“Epic-Feature-Story”进行层级拆分：   战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。Independent 独立的Neogociable 可讨论的Valuable 对客户/用户有价值的Estimatable 可估计的Small 小的Testable 可测试的。Epic通常是公司重要战略举措或者巨大的需求，例如“凤凰商城”对于“无极限零部件公司”是一个与企业生存攸关的关键战略措施，就是一个Epic。Feature通常是在Epic之下，对用户有价值的功能，用户可以通过使用特性满足他们的需求。比如“凤凰商城”的 “门店网络查询功能”，特性通常会通过多个迭代持续交付。Story通常是对一个功能进行用户场景细分，并且能在一个迭代内完成。Story通常需要满足INVEST原则：Story又可以继续拆成Task。Task是实现层面的，例如准备环境，准备测试用例等，都可以是完成Story的细分任务。Task无需遵循INVEST原则。        战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。使用Scrum项目模板进行项目规划，并管理Epic和Feature在DevCloud中，可以使用提供的“需求规划”功能以思维导图的模式完成需求从“Epic > Feature > Story > Task”的创建以及管理。需求规划打开凤凰商城项目，单击“工作 > 需求规划”，项目规划视图以树形结构列出了需求从“Epic > Feature > Story > Task”的逐级关系。      2、创建新的Feature， 在凤凰商城Epic上单击“**子主题”。输入标题“门店网络”，回车保存。            3、按照同样的方式，完成Story“作为用户应该可以查看、查询所有门店网络”的创建。项目规划折叠    为了更清晰的展示规划视图，不同用户角色可以根据实际需求，展开/折叠对应级别的列表。   例如，某用户角色只关心 Feature级别的列表，单击“Feature”旁边的完成折叠。        折叠后如下图所示：导出项目规划    DevCloud还支持将项目规划导出到Excel，以“条目化”的方式查看以及管理。    单击页面右上角“导出”。导出后的表格如下图所示：需求描述：以用户故事来描述需求维基百科上说，用户故事的目的在于以更快的速度、更少的消耗来应对现实世界需求的快速变化。在DevCloud，我们以用户故事的形式来记录需求。华为以往也用需求规格说明书以及用例的形式，但这样的方式非常乏味、容易出错、编写耗时，而且说真心话没人愿意去读。采用用户故事的好处在于：用户故事强调对话而不是书面沟通。故事更容易被客户和开发人员理解。用户故事大小适中，适合做迭代计划。用户故事鼓励重要的事情先做。鼓励推迟决策，延迟考虑细节。支持随需求而变的开发。用户故事将重点从以往的文档转换到了更实用的对话。面面俱到的文档看上去固然很美，但费时费力而且还没人去看。用户故事取而代之，以通过与客户沟通来获取需求，通过与用户协作来澄清需求，通过频繁的发布来确认需求。用户故事通常按照如下的格式来表达：As a <Role>, I want to <Activity>, so that <Business Value>.作为一个<角色>，我想要<活动>，以便于<商业价值>。三段式的用户故事，核心是从用户角度出发描述问题，站在用户的立场思考问题。好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。有了Who、Why、What的信息，How就变得呼之欲出了。以往我们上来就写需求的，往往注意到的是What（干什么），却忽略了Who（为谁做）以及Why（为什么做）。而Who-Why-How-What的逻辑模式，恰好也是影响地图的结构。有关影响地图，请阅读文章《影响地图》。DevCloud需求编辑操作在DevCloud中，我们可以通过工作项管理模块，进入每一个工作项中，单独编辑该工作项的详细信息，并可对工作项进行详细的用户故事内容描述。单击“工作 > Backlog”，打开Story“作为用户应该可以查看、查询所有门店网络”。     2、修改Story描述信息、开始日期、结束日期、预计工时、优先级、重要程度字段信息，单击“保存”按钮完成修改。此外，DevCloud支持工作项模板，在“设置->项目设置”中，可以看到如何将用户故事的三段式预置在Story的工作项模板中，也可以根据需要自行定义描述信息。同时，DevCloud也遵循3C原则。卡片是用户故事的展现形式，用户可以切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。

敏捷项目管理组建Scrum团队本文将以一个示例项目为对象，介绍如何进行敏捷项目管理，示例项目背景如下：凤凰商城示例项目介绍【凤凰商城】示例项目是耗时数月所开发的汽车零部件配件电子商城。项目采用 Scrum模式 进行迭代开发，每个迭代周期为“两周”，前3个迭代已经完成“凤凰商城1.0” 版本的开发，当前正在进行 “迭代4” 的规划。在开始项目规划之前，我们首先要组建团队，并确定团队的运作模式。而在这个客户需求不断变化，交付周期不断压缩的时代，敏捷开发模式无疑是各个开发团队的首选。DevCloud提供了多种项目管理模式，其中就有基于Scrum框架的项目类型。因此，我们将以Scrum框架为例，并在此简单对Scrum进行介绍。Scrum的定义  Scrum（名词）：Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。Scrum是：自上世纪90年代初以来，它就已经被应用于管理复杂产品的工作上。 Scrum并不是一种过程、技术或决定性方法，而是一个框架，在此框架中您可以使用各种不同的过程和技术。 Scrum让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。Scrum框架由Scrum团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要的。Scrum的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。轻量的易于理解的难以精通的Scrum团队在开始介绍Scrum的组织架构之前，让我们先看一个小故事。一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行。”猪说：“我把自己全搭进去了，而你只是参与而已。”  这则故事应用在敏捷开发中，用来说明不同角色的职责。在Scrum过程中，“猪”是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作；鸡”并不是实际Scrum过程中全身投入的一部分，但是必须考虑他们。Scrum团队由一名产品负责人、开发团队和一名Scrum Master组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。以上关于Scrum概念以及团队角色职责部分内容描述，摘自《2017 Scrum Guide》。关于Scrum的更多详细信息，以及管理实践方法，可参考《Scrum Guide》。使用DevCloud添加项目成员，并配置成员角色简单了解Scrum框架以后，我们就可以开始组建项目团队了。在DevCloud中，每个项目中有多个项目成员，但由于每个成员在项目中担任的职责不同，需要通过成员角色给予区分，并在操作权限上做出相应的体现。单击“设置 > 基本信息”。项目的基本信息列出了项目名称，项目描述，项目类型，创建时间，创建人。项目描述可以根据情况进行修改。  单击“成员管理”，可以添加新的用户到这个项目中。  DevCloud提供以下两种添加用户的方式：添加方式说明添加成员添加本企业租户下的成员，如果成员不存在可以为其创建子用户。通过链接邀请邀请非本企业租户下的成员。添加进项目中的成员，可以点击成员信息右侧的操作按钮，对成员角色进行编辑。  项目角色一共有6种，分别对应不同的操作权限，项目管理人员可以根据项目实际情况对成员角色进行分配。  

大家好，我是华为云DevCloud产品经理白眉，2019年上半年我们收集到不少如下类似的VOC：[问题描述]:目前每创建一个新的项目时，都需要单独配置工作项目自定义，而其实每个项目的模板都是一样的；还有仪表盘也要单独去配置一遍。[建议方案]:建议在配置时可以选择从某个项目去复制，或者可以统一修改默认配置，以后新建项目都是一样的配置。[问题描述]:若我在某个项目中，项目设置-工作项自定义中，定义了字段或状态，切换到另外一个项目时，无法复用我之前自定义的字段或状态，需要重新再创建一遍。[建议方案]:可以增加复制项目功能，例如我创建一个项目后，搭好项目模板，然后我再创建新项目时可以直接复制这个项目模板虽然现有的项目设置里提供了状态、模块等字段的一键复制功能，但是相比于上述用户需求来说还是杯水车薪得，经过产品团队内部讨论，我们设计了项目设置模板的功能：用户可以根据自身需要自定义项目设置模板，然后再快速复用至其他项目。考虑该功能涉及的范围广且工作量大，所以我们的第一个版本主要实现了如下的特性：将某个项目设置的内容存为模板新建项目时可选择自定义模板配置模板的内容仅对新建项目生效，不会影响已使用项目此外第一个版本也有如下的一些限制：项目设置模板仅针对scrum项目 项目设置模板包含的项目设置项内容限于【工作项管理】部分模板的操作权限限于租户管理员和项目创建者上述的限制也只是暂时的，我们在第二个版本将扩展项目设置模板的内容覆盖所有项目设置项的内容，该版本预计在9月初上线，此外我们也会根据用户使用情况不断扩展项目设置模板的功能以满足大家的实际需求。目前项目设置模板的第一个版本已经上线，欢迎大家体验该功能并随时反馈！如下给大家简单介绍第一个版本的基本用法。1、新建模板进入某个项目的项目设置页，即可以查看到“保存为模板”的入口，如果没有权限则该入口不可操作。2、使用模板新建项目选择Scrum类型，即可以看到选择项目设置模板的入口。3、模板管理所有项目设置模板可在模板管理页面查看和管理，包括系统默认的模板和用户自定义模板。用户可在模板管理页面查看到模板的信息包括：模板名称、描述、来源（基于哪个项目的设置创建）、创建者和已使用项目数目。点击已使用项目数目列具体的某个数字，可查看具体使用的项目情况。在模板管理页用户也可以对自定义模板编辑模板名称和描述，系统默认模板不支持编辑。点击操作列表的编辑按钮，在弹出框内可编辑模板名称和描述。在模板管理页面，用户点击模板名称可进入模板详情页，对已有模板内容做配置。