真北敏捷 | 敏捷健康度成熟度
内容摘要
Spotify的敏捷健康度模型
Mike Cohn/Ken Rubin的敏捷成熟度模型
评估频度，及与Retrospective结合和内化
Spotify的敏捷健康度模型
1. 定义一组检查项。
2. 定义每一检查项的红绿标准。
3. 下图供参考，可补充。
4. 团队一起确定每项实际的红黄绿。可以用类似估算纸牌的方法。
5. 制定改善措施。
6. 定期做，观察趋势。
Mike Cohn/Ken Rubin的敏捷成熟度模型
8类总计约50个问题，针对每个问题定期打分，可以用三分制或五分制。玩法参照估算纸牌，目的不是打分，而是制定改善措施。
Eight assessment Dimensions
ØTeamwork
ØRequirements
ØPlanning
ØTechnicalpractices
ØQuality
ØCulture
ØKnowledgecreation
ØOutcome
Teamwork
Great teamwork is the result ofempowered people working together in an effective and collaborative manner.This dimension gauges a number of important elements of high-performing teamssuch as how they are composed, internal patterns of communication and how workis conveyed from goals to concrete deliverables.
-Everyone required to go fromrequirements to finished system is on the team.
-Specialists are willing to workoutside their specialties to 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 to achieve them.
-Team members don't have to workon tasks that they deem to not add value.
-Management rarely changes theteam's priorities during an iteration.
-Team members communicate in a high-bandwidthmanner without undue interference.
-Team members from one teamcommunicate with team members from other teams in a high-bandwidth mannerwithout undue interference.
-Formal written documents areused to supplement rather than replace faster, more informal communication.
-Standup meetings are effectiveat synchronizing work.
-The team is not concerned aboutknowledge gaps when someone 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 perform well in this dimension typically do not spendexcessive amounts of time on activities such as documentation, meetings andextensive design sessions and instead focus on “just enough” documentation anddesign in order to quickly deliver value while being prepared to pivot whennecessary.
-Teams are able to start projectswith incomplete requirements.
-Non-functional requirements aredetermined early enough to appropriately influence design and testing.
-Requirements are represented atdifferent levels of detail based on how soon the team expects to implementthem.
-The product owner is availableto discuss upcoming features and work-in-progress.
-The whole team embraces changeand emergent opportunities in an efficient, low-ceremony way.
-Projects do not begin with anextensive technical design phase.
-The team performs iterativetechnical design throughout a project.
Planning
Having a crisp understanding ofthe "what" and the "why" is a critical element of businessagility. This dimension focuses on fundamental success factors such asprioritization, definition of work, Product Owner involvement and establishingpredictable delivery of value.
-Technical team members and theproduct owner are included in the planning process in a way that they canmeaningfully and appropriately affect scope and deadlines.
-Technical team members andproduct owners collaborate in determining what features will be included in therelease plan.
-At the start of each iteration,the team performs sufficient just-in-time planning to be confident of what itcan complete in the iteration.
-The product owner maintains aprioritized product backlog.
-One or more of scope, schedule,or resources is allowed to change during a project.
-Iterations focus on creatingfeatures with value to customers 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's progress within a release.
-Each day, there is a highlyvisible representation of the team's progress within an iteration.
-Each feature has a well-definedcompletion criteria that can be used to determine if the feature is done or notdone. We do not consider a partially completed feature done.
-Estimates are createdcollaboratively by the people who will do the work.
-Upfront planning is helpfulwithout being excessive.
Technical Practices
This dimension captures thedegree to which software is developed in a manner that embraces emergentdesign, addresses technical debt and engineering 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 done work) is made visible to both technical teammembers and stakeholders.
-The entire system is builtautomatically at least once per day.
-Automated unit and acceptancetests are run as part of each automated build.
-Within our team, anyone canchange anyone else's code.
-The team can change any code inthe system, even code written by other teams.
Quality
Evaluates the degree to whichQuality is built-in at the source. Clearly defined customer acceptancecriteria, an end-to-end testing strategy, automation and a commitment to onlydelivering fully tested code are all best practices that typically lead tohigher software quality, fewer defects in production and less rework.
-Product owners activelyparticipate in the creation of the acceptance criteria for each feature.
-All bugs are fixed during theiteration in which they are found.
-At the end of each iterationthere is little or no manual testing required.
-The team performs a variety oftypes of testing including functional, performance, integration, andscalability each iteration.
-Testers are involved andproductive right from the start of each iteration.
-At the end of each iteration,the team has high-quality working software that it is comfortable being testedby people outside of the team.
-The team has pre-defined andagreed-upon criteria for considering a feature done.
Culture
Organizational Culture has anoutsized impact on all other aspects of work and is a leading indicator offuture company performance. This dimension covers areas such as work/lifebalance, the perceived degree of stress in the workplace, whether work is performedat a sustainable pace and to what degree individual compensation structureshave an effect on team collaboration.
-When faced with a situationwhere scope cannot be met with the allotted resources in the allotted time, theteam's initial reaction is to prioritize and explore tradeoffs.
-The team maintains a steady rateof productivity without being overworked.
-The team considers the economicsof its choices when we make decisions.
-Bonuses, annual reviews, andcompensation promote team behavior.
-Titles are not significant inhow team members interact with one another.
Knowledge-Creating
The degree to which teams areembracing the concept of continuous improvement–effectively learning fromempirical evidence and their experience, evaluating existing processes andalways 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 each iteration in which the team evaluates how they aredoing and discuss how to get better.
-The team acts on retrospectivefeedback in a timely manner.
Outcomes
Business agility is about earlydelivery of business value, adapting to changing market conditions andcontinuously improving the way the organization operates. This dimensioncaptures the extent to which participants perceive Agile is making a differencerelative to the way they used to work or from 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 functionality of our products than before.
-Our customer(s) are moresatisfied with the usability of our products than before.
-The team has higher morale thanbefore.
-Our business is recognizinggreater economic value than before.
-We are delivering functionality to users more quickly and/or more often than before.
评估频度，及与Retrospective结合和内化
评估不应成为额外负担，可与Retrospective结合。
Spotify的模型较轻，可以每迭代使用。
Mike Cohn的模型较重，可以每季度使用。
如果在没有模型的情况下，团队已经有很多有建设性的想法，则不用模型。
团队没什么想法时，用一下模型，引一下想法。
內建自己的模型，例如：
八月活动：
阅读原文，补充扩展修订备用页。