ACP敏捷3.单团队单迭代.运营管理视角

908486905

已于 2022-06-26 00:40:21 修改

阅读量310

点赞数

分类专栏：敏捷开发ACP DevOps NPDP 文章标签：产品运营

于 2022-06-18 20:08:23 首次发布

本文链接：https://blog.csdn.net/u010025781/article/details/125350818

版权

敏捷开发ACP 同时被 3 个专栏收录

22 篇文章 9 订阅

订阅专栏

DevOps

3 篇文章 0 订阅

订阅专栏

NPDP

2 篇文章 0 订阅

订阅专栏

在交付了MVP最小可交付产品后，考虑运营的了，从持续运营的视角来看两个实践，一个是软件技术管理实践ExtremePrograming，一个是管理实践看板。

1. 极限编程

追求质量，达到极限的软件技术管理实践方法，XP

而SCRUM是一个管理框架，可用于非软件领域。

《解释极限编程拥抱变化》

1996年，贝克(Kent Beck)提出了极限编程(Extreme Programming , XP)，他曾经帮助戴姆勒公司做过- - 个名为C3 (克莱斯勒综合薪酬，ChryslerComprehensive Compensation)的开发项目，当时项目处于困境，贝克与坎宁安(Ward Cunningham)、杰弗里斯( Ron Jeffries) 、福勒(Martin Fowler) 等人使用XP帮助项目取得了成功，这或许是第一个XP项目。

XP定义：

价值观+实践+社区

XP是一种软件开发风格，专注于编程技术，清晰沟通还有团队协作的精彩实践。
XP包括:
●一种软件开发的哲学,基于沟通,反馈,简洁,勇气和尊重的价值观;
●-整套在软件开发中被证明有用的实践。这些实践相辅相成,互相增强，这些实践作为以上价值观的表现形式；
●- 系列用来将以上价值观投入实践的辅助原则和技术。当你缺乏应对你具体问题的现成的实践时，要依赖这些原则自己发明实践;
●一个共享这些价值观、原则和实践的社区。---民间组织，提高技能解决问题

XP的范式和属性：

确认方向；

验证结果；

反馈周期越来越短，逼近极限。

XP的社会化属性，XP取得成功的假设: (程序员的个人修炼)
●XP假设你把自己看成团队的一部分，一个具有清晰目标和执行计划的理想个体
●XP 假设你想与别人一起工作
●XP 假设可以经济的应付变化
●XP 假设你希望成长，改进自己的技能，改善人际关系
●XP 假设你能做出改变来达成这些目标

XP13个核心实践

核心实践3：

TDD+重构--开发；

持续集成；

1. 管理实践：团队协作(Whole Team)；

规划策略(The Planning Game)；

小型发布（Small Release）；

客户测试(Customer Tests)；

2. 管理与技术融合-管理规范-5：

代码共同所有权(Collective Code Ownership)

编码规范（Code Standards）

可持续的节奏（Sustainable Pace)

系统隐喻（System Metaphor)--通过打比方简化问题理解

持续集成(Continuous Integration)--集成前移，尽快看到结果

//持续集成、持续交付、持续部署，工具IDE的发展，持续集成不是问题了

3. 技术实践-4

测试驱动开发(Testing-Driven Development)

重构(Refactoring)

简单设计(Simple Design)

结对编程(Pair programming)--两个程序员结对，一个领队一个观察；老带新；

核心实践扩展DevOps

开发运维一体化

响应拥抱变化，需要维护稳定；开发和运维的脱节--是DevOps解决的问题；

DevOps一词本身是对于development以及operation两个词的混合，其目的在于缩短系统开发的生命周期，在这过程中发布特性、修复bug以及更新均被紧密的结合。
-- (Wiki)定义
DevOps是通过改善开发和运营员工之间的协作来理顺交付流程的各种实践的集合。.(PMI敏捷实践指南)

思想：开发测试联动-开发自测试；测试运维联动-测试自运维；开发运维联动，开发自运维；业务自运维；

DevOps工具

诸如FlowDock或HipChat这样的DevOps实用工具能够帮助开发团队的成员互相以及与DevOps人员保持联系。诸如Asana或Basecamp这类服务能够有助于跟踪开发任务以及在应用发布中的注意事项。
诸如以客户为中心的支持门户网站可让用户直接与管理层或开发团队进行需求沟通。这将有助于触发新的或改进的功能，并确保客户的需求能够得到满足。一个DevOps团队能够帮助建立这些服务，并让团队成员了解相关技术。
无论是纵向集成还是横向集成，DevOps都需要通过工具链与持续集成、交付、反馈与优化进行端到端整合。

华为基于二十几年的研发实践，并融合DevOps等理念方法，打造了软件开发云服务，希望为企业提供一站式的云上开发工具平台。据了解，华为软件开发云提供了项目管理、配置管理、代码检查、编译构建、测试、部署、发布等端到端地覆盖软件生命周期的相关服务。

在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时，DevOps也已经稳健地在业务思维方式中占有一席之地。在应用驱动、云连接、移动化的大环境下，DevOps战略将助力业务增值。

与DevOps相伴的一个变化是向持续集成的演进。软件开发和部署的速度是其中一个驱动因素，使得开发和运维的合并不是空谈而成为必需。

Scrum vs XP

scrum--定位管理方法；XP: 定位仅适用于软件开发，有详细的工程实践定义；

Scrum核心手段是工程学，没有太多关注人；

XP则希望全面改善人的社会属性和技能。

2. 看板（基于精益思想的管理方法）招牌/传递反馈信号

七个精益原则

消除浪费:识别浪费、价值流图
增强学习:反馈、迭代、同步、基于集合开发
延迟决策:可选项、最后责任时刻、制定决策
快速交付:拉动系统、排队理论、延迟成本
授权团队:自我决策、动机、领导力、专业技能
内建质量:感知、概念、重构、测试
整体优化:度量、合同

WIDETOM: 价值流程图中，WIDETOM可用于记录不同形式的浪费：
W-waiting等待
I-inventory不必要的库存
D-defects缺陷/次品
E-extra processing额外流程/不当流程；
T-transportation运输/搬运
O-over-production过度生产（限制各个环节的在制品WIP Working in Progress）
M-motion动态/不必要的行动；

看板故事

过度生产导致的在制品挤压就是浪费，需要控制在制品数量。

看板的6个核心实践：

可视化工作流程
约束在建品WIP
度量和管理流动-管理流动
显示化规则(贴在看板旁边)
建立反馈环路
在协作及实践中改进

1.看板区别与任务板,看板按流程列泳道，每个流程节点按产量限制在制品的数量，反馈给前期节点。 //过渡生产是浪费

管理和度量流动方法：

1. CFD-CumulativeFlowDiagram图，累计流量图--预测待完成需求完成时间

2. Littes Law利特尔法则

//提高节点的单件生产效率；

//减小等待队列长度.

SCRUM团队用任务板或者分层看板：

任务版-->转换为看板

把Doying的具体流程分拆为泳道，并加上在制品限制

任务版流动的是用户故事；

看板流动的是任务；

服务水平协议/工作分类分层

（开发任务+运维任务+突发任务）团队

Scrum vs 看板：

1. Scrum中不限制在制品，Scrum限制时间盒，超时迭代失败结束；

看板限制在制品，不限制时间，从更长期持续运营的角度管理问题，没有迭代的概念。更适合运维管理。

2. Scrum的计划会，评审会和回顾会会有规律的按周期举行。

看板团队则不一定，也许有固定频率，也许按需安排。

3. Scrum团队任务会有明确的规律的三个阶段。而看板没要求。

因此看板使用场景更加灵活，运维团队更加容易介入看板管理方法。

看板实施

《看板和Scrum相得益彰》

8. DevOps

DevOps是Development和Operations缩写，现在市场需求和技术变化都非常快，为了配合市场的需求，开发周期就要变短（但是软件质量不能因为这个原因降低），比如说某些APP可能每周就要更新一次，所以说为了跟上市场的变化，势必就要缩短开发周期，但是传统的开发过程中与运维相关的部分比如测试，发布，部署都很花时间，所以往往开发人员和运维人员之间有着很深的隔阂，并且两者沟通效率低，为了解决这个问题，使之能够更专注于开发。

DevOps简单的说就是为了打破传统开发和运维之间的隔阂与低效，在保证产品质量的前提下实现更自动化、更高效的协作与产品的交付。

DevOps是什么

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说，就是在软件交付和部署过程中的提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。