本文探讨了敏捷开发的核心理念，强调团队协作、需求管理、计划制定和技术实践的重要性。通过Spotify的团队健康度和Mike Cohn的Scrum成熟度评估，阐述了高效团队的特征和工作方式。同时，提到了质量和文化的影响力，以及DevOps的黄金指标和度量体系，如代码扫描、持续集成、缺陷密度等，展示了敏捷方法如何提升业务价值和团队效率。
一言以蔽之，敏捷就是做正确的事，一切美好，都是敏捷。前文回放:
一个中心两个基本点：敏捷是释放和激发人的善意和内驱力--Scrum背后的秘密
根在文化：敏捷适配还是敏捷转型？
大规模合作：规模化敏捷是管理依赖，对齐目标、进度、风险、质量
回归本源，度量不要跟考核挂钩。度量的本源是PDCA中的C，用来支撑A，并提升下一轮的PD。
1、Spotify的团队健康度：人性与科学的结合
2、MikeCohn的Scrum成熟度：Scrum落地的保障方法，Scrum融合人性与科学
Eightassessment Dimensions
ØTeamwork
ØRequirements
ØPlanning
ØTechnicalpractices
ØQuality
ØCulture
ØKnowledgecreation
ØOutcome
Teamwork
Great teamwork is the result ofempowered people workingtogether in an effective and collaborative manner.This dimension gauges anumber of important elements of high-performing teamssuch as how they arecomposed, internal patterns of communication and how workis conveyed from goalsto concrete deliverables.
-Everyone required to go fromrequirements to finishedsystem is on the team.
-Specialists are willing to workoutside their specialtiesto achieve team goals.
-Whole teams, including the ScrumMasterand Product Owner,have no more than 12 people on them.
-People are not on more than twoteams
-Team members are kept togetheras long as possible.
-Team members choose which tasksto work on.
-Management sets goals butdoesn't tell team members how toachieve them.
-Team members don't have to workon tasks that they deem tonot add value.
-Management rarely changes theteam's priorities during aniteration.
-Team members communicate in a high-bandwidthmannerwithout undue interference.
-Team members from one teamcommunicate with team membersfrom other teams in a high-bandwidth mannerwithout undue interference.
-Formal written documents areused to supplement ratherthan replace faster, more informal communication.
-Standup meetings are effectiveat synchronizing work.
-The team is not concerned aboutknowledge gaps whensomeone goes on vacation (or is otherwise unavailable).
Requirements
Addresses core concepts such asjust-in-time (JIT)planning, emergent design and focus on customer value.Organizations that performwell in this dimension typically do not spendexcessive amounts of time onactivities such as documentation, meetings andextensive design sessions andinstead focus on “just enough” documentation anddesign in order to quickly deliver value whilebeing prepared to pivot whennecessary.
-Teams are able to start projectswith incompleterequirements.
-Non-functional requirements aredetermined early enough toappropriately influence design and testing.
-Requirements are represented atdifferent levels of detailbased on how soon the team expects to implementthem.
-The product owner is availableto discuss upcomingfeatures and work-in-progress.
-The whole team embraces changeand emergent opportunitiesin an efficient, low-ceremony way.
-Projects do not begin with anextensive technical designphase.
-The team performs iterativetechnical design throughout aproject.
Planning
Having a crisp understanding ofthe "what" andthe "why" is a critical element of businessagility. This dimensionfocuses on fundamental success factors such asprioritization, definition ofwork, Product Owner involvement and establishingpredictable delivery of value.
-Technical team members and theproduct owner are includedin the planning process in a way that they canmeaningfully and appropriatelyaffect scope and deadlines.
-Technical team members andproduct owners collaborate indetermining what features will be included in therelease plan.
-At the start of each iteration,the team performssufficient just-in-time planning to be confident of what itcan complete in theiteration.
-The product owner maintains aprioritized product backlog.
-One or more of scope, schedule,or resources is allowed tochange during a project.
-Iterations focus on creatingfeatures with value tocustomers and infrequently focus on infrastructurespecific work.
-All work is done in iterationsof no more than 30 days.
-Teams know their velocity.
-There is a highly visiblerepresentation of the team'sprogress within a release.
-Each day, there is a highlyvisible representation of theteam's progress within an iteration.
-Each feature has a well-definedcompletion criteria thatcan be used to determine if the feature is done or notdone. We do not considera partially completed feature done.
-Estimates are createdcollaboratively by the people whowill do the work.
-Upfront planning is helpfulwithout being excessive.
TechnicalPractices
This dimension captures thedegree to which software isdeveloped in a manner that embraces emergentdesign, addresses technical debt andengineering practices typically associatedwith the principles of XP.
-Most code is written usingtest-driven development (TDD).
-Code is written usingpair-programming.
-Team members pair program atappropriate times.
-Refactoring is performedwhenever needed.
-Technical debt (i.e.,accumulated undone or poorly donework) is made visible to both technical teammembers and stakeholders.
-The entire system is builtautomatically at least once perday.
-Automated unit and acceptancetests are run as part ofeach automated build.
-Within our team, anyone canchange anyone else's code.
-The team can change any code inthe system, even codewritten by other teams.
Quality
Evaluates the degree to whichQuality is built-in at thesource. Clearly defined customer acceptancecriteria, an end-to-end testingstrategy, automation and a commitment to onlydelivering fully tested code areall best practices that typically lead tohigher software quality, fewer defectsin production and less rework.
-Product owners activelyparticipate in the creation of theacceptance criteria for each feature.
-All bugs are fixed during theiteration in which they arefound.
-At the end of each iterationthere is little or no manualtesting required.
-The team performs a variety oftypes of testing includingfunctional, performance, integration, andscalability each iteration.
-Testers are involved andproductive right from the startof each iteration.
-At the end of each iteration,the team has high-qualityworking software that it is comfortable being testedby people outside of theteam.
-The team has pre-defined andagreed-upon criteria forconsidering a feature done.
Culture
Organizational Culture has anoutsized impact on all otheraspects of work and is a leading indicator offuture company performance. Thisdimension covers areas such as work/lifebalance, the perceived degree of stressin the workplace, whether work is performedat a sustainable pace and to whatdegree individual compensation structureshave an effect on team collaboration.
-When faced with a situationwhere scope cannot be met withthe allotted resources in the allotted time, theteam's initial reaction is toprioritize and explore tradeoffs.
-The team maintains a steady rateof productivity withoutbeing overworked.
-The team considers the economicsof its choices when wemake decisions.
-Bonuses, annual reviews, andcompensation promote teambehavior.
-Titles are not significant inhow team members interactwith one another.
Knowledge-Creating
The degree to which teams areembracing the concept ofcontinuous improvement–effectively learningfromempirical evidence and their experience, evaluating existing processesandalways improving the way they work.
-Iteration reviews are attendedby product owners,stakeholders, and team members who provide actionablefeedback.
-The team holds retrospectivemeetings at the end of eachiteration in which the team evaluates how they aredoing and discuss how to getbetter.
-The team acts on retrospectivefeedback in a timelymanner.
Outcomes
Business agility is about earlydelivery of business value,adapting to changing market conditions andcontinuously improving the way theorganization operates. This dimensioncaptures the extent to which participantsperceive Agile is making a differencerelative to the way they used to work orfrom the last time they took thesurvey.
-The team is producing higherquality products than before.
-The team is more productive thanbefore.
-Our customer(s) are moresatisfied with the functionalityof our products than before.
-Our customer(s) are moresatisfied with the usability ofour products than before.
-The team has higher morale thanbefore.
-Our business is recognizinggreater economic value thanbefore.
-We aredelivering functionality to users more quickly and/or more often than before.
3、阿里的211：互联网唯快不破
4、DevOps黄金指标：精英级效能组织的质量与效率，影响业务目标和企业成功，全球市值五大的追求
5、DevOps成熟度：配置管理、持续集成、测试管理、数据管理、环境管理、部署与发布，以评促改
能力域 | 能力子域 | 能力项 | 能力子项 | 1级 |
持续交付 | 配置管理 | 版本控制 | 版本控制系统 | 源代码分散在研发本地自行管理 |
分支管理 | 无 | |||
制品管理 | 构建产物分散在研发本地自行管理 | |||
单一可信数据源 | 无 | |||
变更管理 | 变更过程 | 1) 无变更过程 | ||
变更追溯 | 无 | |||
变更回滚 | 无 | |||
构建与持续集成 | 构建实践 | 构建方式 | 采用手工方式进行构建 | |
构建环境 | 使用研发本地设备构建 | |||
构建计划 | 构建任务不定期执行 | |||
构建职责 | 无专人专岗负责构建 | |||
持续集成 | 集成服务 | 无持续集成服务 | ||
集成频率 | 长期本地开发代码，集成频率几周或者几月一次 | |||
集成方式 | 代码集成作为软件交付流程中的一个独立阶段 | |||
反馈周期 | 每次集成伴随大量的问题和冲突，集成期间主干长期不可用 | |||
测试管理 | 测试分层策略 | 分层方法 | 只进行用户/业务级的UI测试 | |
分层策略 | 无测试分层策略 | |||
测试时机 | 测试在软件交付过程中在开发完成后才介入 | |||
代码质量管理 | 质量规约 | 具备初始代码质量规约，规约停留在个人级 | ||
检查方式 | 代码质量检查采用人工方式进行评审 | |||
反馈处理 | 无代码质量检查结果处理机制，存在大量技术债 | |||
自动化测试 | 自动化设计 | 无 | ||
自动化开发 | 自动化测试脚本与工具分散管理 | |||
自动化执行 | 1) 手工测试为主，自动化程度低 | |||
自动化分析 | 手工对测试结果进行分析判断 | |||
部署与发布管理 | 部署与发布模式 | 部署方式 | 运维人员手工完成所有环境的部署 | |
部署过程 | 部署过程存在较长的服务中止时间 | |||
部署策略 | 1) 采用定期部署策略，部署频率以月为单位 | |||
部署质量 | 1) 部署整体失败率较高 | |||
部署流水线 | 协作模式 | 1) 整个软件交付过程严格遵循预先计划 | ||
流水线过程 | 软件交付过程中的大部分工作通过手工方式完成 | |||
过程可视化 | 1) 交付过程中的信息是封闭的 | |||
环境管理 | 环境管理 | 环境类型 | 环境类型只有生产环境和非生产环境的划分 | |
环境构建 | 1) 人工创建环境 | |||
环境依赖与配置管理 | 1) 无依赖管理 | |||
数据管理 | 测试数据管理 | 数据来源 | 测试时手工创建临时数据 | |
数据覆盖 | 测试数据覆盖部分测试场景 | |||
数据独立性 | 无 | |||
数据变更管理 | 变更过程 | 1) 数据变更由专业人员在后台手工完成 | ||
兼容回滚 | 没有建立数据库版本，数据库和应用存在不兼容风险 | |||
数据监控 | 数据变更结果需要访问数据库进行验证 | |||
度量与反馈 | 度量指标 | 度量指标定义 | 在持续交付部分阶段定义度量指标 | |
度量指标类型 | 无 | |||
度量数据管理 | 度量数据是临时性的 | |||
度量指标更新 | 无 | |||
度量驱动改进 | 内容和生成方式 | 度量报告通过手工方式生成 | ||
数据时效性 | 数据和度量报告的时效性存在差异 | |||
覆盖范围 | 仅部分人员可查看报告 | |||
反馈改进 | 度量反馈问题解决周期较长 |
6、工行DevOps度量：代码扫描、持续集成与自动化测试、缺陷密度、需求流速
7、一组建议的指标：
质量（左移）：缺陷密度、故障密度、技术债务（未处理的代码扫描问题等）
效率（流动）：需求交付周期、流动效率（处理时间/周期时间）、吞吐量
价值（目标）：系统可用度与业务指标
团队（人）：满意度
扫一扫
1318
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
