九问敏捷

本文主要是介绍九问敏捷，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

PART 1

答：制造业部分首先我前面提到了，如果是已经设计好的东西，那么这部分精益制造有更好的方法，如果是盖楼，那么传统的建筑学有更好的方法。那么它能够发挥在什么地方呢？它是发挥在设计阶段，刚才我举的例子是水泵设计，那么也就是说制造业的前部分设计的部分，我们现在已经清晰的看到很多的公司是试用实用敏捷，我们最新有个江生自控，是一个世界五百强公司，发布了相应的报告。他们在江生自控的很多设计环节采用了敏捷方法论，所以这个制造业设计部分是可以的，但制造业本身制造部分用传统的精益生产更加好。

PART 2

答：不是的，他要求跟最终能够展现的产物相关，如果是软件开发的话恰恰不需要文档产出，恰恰需要可运行的软件。那么如果不是软件开发的话，就跟你自身的工作要出的产物一样，敏捷不要求额外的产物。敏捷只需要求在每个迭代你原来要做什么产物就做什么产物，所以它不会因为敏捷有额外任何文档的增加，所以这个文档整理的工作量不会更大，只会更少。

当然这里面我要多说一句，就刚才我已经说到了极限编程这方面是早年犯错误的，那么所以在现在的话呢，在这个文档处理方面，我们目前非常清晰地看到采用Wiki这样的工具来使得我们的文档能够得到自动的累积效果。人员能够编辑，然后自动的有版本控制，这样的话虽然你可以写的非常的马虎，但是他们这个文档会自然而然的累积下来。所以现在大规模敏捷的建设Wiki工具是离不开的，比如说comforence、Sharepoint 、微软的Azure DevOps等等都有内嵌这样的工具。那么反过来说，Word、PowerPoint、Excel这些工具，都是属于过时的工具，这些工具的整个的效率都不够高。所以的话就是我们鼓励各个规模化敏捷实施的组织都要换线上的协同工具。国产的石墨工具，国产的磨刀啊等等，线上多人协作的这种工具确实是好很多，这样的话文档的工作更加高效。

PART 3

答：其实整个敏捷团队跟传统的团队建设最大的区别用一个词就是仆人式领导，仆人式领导更多的传递能够创建良好的条件，支撑我们团队的开发，信任我们团队，授权我们团队，能够使得团队形成一个自组织自管理的氛围来推进。那这里面有一个敏捷方面的陷阱，或者说是大的台阶，大家要注意，就是我刚才提到的Scrum。

Scrum在团队模型当中是一个极端的团队模型，它取消了项目经理，它直接任命了Scrum Master和产品负责人，所以它是一个非常高效的团队模型，但是跟各个团队当前或者说起点的形态是有点距离的。所以业界出现了为了敏捷直接跳跃到Scrum团队模型，反而是出现负面影响的情况，所以我这里面有一个告诫就是说，“start from where you are”,从你当前的形态开始，然后寻求怎么一个小步的改变完了之后来推进敏捷的团队建设，不要一上来无视自身团队的实际情况强行套用所谓的最敏捷的团队模型，所以这是一个注意的地方。

PART 4

答：事实上敏捷和PMP是接在一起的，我刚才提到它最大的冲突点恰恰就是它最大的融合点，它最大的冲突点就是整个生命周期模型。

原先的PMP对于生命周期模型方面没有强制引入短迭代的要求，敏捷方面是有强制短迭代的要求，那么及时冲突的地方也是融合的地方。只要解决这个要点，就能够融会贯通的把PMP当中的其他所有的知识全部给用进去，包括WBS、时间管理、范围管理等等都可以用。

掌握了PMP再去做敏捷会更加的扎实，没有任何基础去考敏捷反而是有些薄弱，PMP和敏捷完全兼容，只要是在关键的融合点上把它融合好。

PART 5

答：测试报告在敏捷开发当中是一个很大的问题，事实上传统的测试策略在敏捷当中需要修改，简单说，基于覆盖率的传统策略是无法在敏捷当中长期使用的，因为敏捷每个迭代都会有新东西，也就意味着在迭代迭代走下去的时候，回归测试所谓的量就在不断的增加。

所以这里面有两个选择方案，第一个用自动化测试能够跟代码开发配套，这样的话手工测试就少。再一个是探索性测试，要用新的探索性测试策略来改变原先的手工回归测试。需求的文档这个量确实也要交代清楚，最新的一个情况刚才我强调了，确实要积累文档，它就绝对的字数而言，不排除是会多一些的。但是我可以乐观的告诉大家，虽然字数会多但写的速度反而会快。

敏捷采用了用户故事这样的直观表达方式，能够使得我们脑袋当中想到的东西快速的表达出来，这是它的优势。那么这也是我们敏捷项目管理现场培训的一个焦点，我们在现场培训的时候会花大量时间来阐述如何进行条目化管理，如何把指示工作切分成一条一条。那么这里面一个核心的工具和手段就是用户故事和敏捷故事。我们通过敏捷故事能够自然而然的把各种各样的工作进行包装进行管理，使得成为WBS的基石，它所要表达的内容和承载的项目管理的抓手能够合二为一，也就是说原先的WBS跟原先项目管理当中做的事情它不是合二为一的，而在敏捷当中是合二为一的。不过今天我们先给大家介绍这么些。

PART 6

答：这个部分是测试数据如何建设的问题，这个不同公司有不同策略。那么生产数据是一个很好的测试数据的源头，有些地方要进行脱敏，所以如果你是金融企业的话那是快不了的。所以他就是要有一定的策略，比如说每季度拉一次还是每半年拉一次，不需要每个迭代都来拉，所以这是测试数据的建设部分，想办法把它加快也确实是能够提升我们的敏捷速度。

PART 7

答：这个问题在早年间的小敏捷时代没有得到回答，在规模化的敏捷时代得到了清晰的回答。在SAFe框架当中，软件设计师是团队之团队上面的一个固定角色。比如说当有五六个、七八个敏捷团队的时候，它就建议有专门的架构师这样的角色。

这个架构师不属于特定的一线敏捷团队，他属于二线，一个架构师支撑几个敏捷团队。那么从介入角度讲，那就是一开始去介入。不仅是一开始介入，每个迭代都要介入。每个迭代都要问一下我们这次的功能变化对架构是不是产生了影响。是架构推进要求我们的功能做相应的变化还是说功能推进需要架构有什么样的变化。

所以这个是架构在新的规模化敏捷当中非常重要，不可或缺的。原先在小敏捷时代，在极限编程也好，在Scrum也好，都缺失了这个角色。

PART 8

答：这几乎是必须的。

我们敏捷建设有专门的敏捷建设金字塔，只有塔尖部分是手工测试，塔身和塔基都是自动化测试。这里面有突出的一个实践来自于极限编程，就叫做持续集成。

PART 9

答：这个看属于哪个传统金融企业，最新我们中原银行行长和董事长都发表了长篇的敏捷银行的报告，平安银行蔡兴发副行长接受的麦肯锡的采访，也发布了平安银行的敏捷战略。

麦肯锡本身敏捷银行的报告写了很多份，所以我们看到现在的传统金融都是纷纷的拥抱敏捷，这里面还有一个非常典型的例子是汇丰银行。汇丰银行就是一头大奔向，汇丰银行在2016年就启动了DevOps & Agile的transformation，他们为什么把DevOps放在前面呢？

他们取了一个D字，&是&字，Agile是A字，所以它缩写是D&A。汇丰的口号是要把DevOps & Agile成为汇丰21世纪的新基因。现在汇丰整体上面转型仍在进行当中，但是已经取得了明显的效果，16年到19年。所以这是传统金融企业我们看到都在往这个方向去，工行也好，建行也好，农行也好，中国的都有相应的报道。

这篇关于九问敏捷的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---