何为发布计划

发布计划是什么

In agile software development, a release plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.
根据以上的描述,用我们大白话来说就是,发布计划是告诉我们哪个特性具体在哪次release会发布。
敏捷又是一个如此强调节奏感的方法体系,那么发布计划自然也是具有超强节奏感的,有的公司会按照2-3个sprint发布一次。也有的会每个sprint都发布一次。那么根据这样的节奏,我们就需要推算我们大概在第几个release可以发布我们需要的特性了。

具体怎么来计划呢?

其实没那么复杂,计划方法就是考虑几个项目管理的基本特性,时间,成本,功能性以及最重要的是质量。例如:限定的时间,可变的成本,我们如何安排最需要的功能上线?这只是一个例子,但是这样就需要我们的PO们用自己的方法进行调整,逐步的排出一份自己的计划。那么敏捷中又是强调release planning的,自然意味着我们的计划是可以动态的去调整的。

如何调整呢?

在面对多团队的时候,我们就更需要这份计划帮助建立一份团队间的alignment(一致性)。通过scrum of scrums的时候,大家来一起调整相应的计划。保证一份公开透明的计划可以公布给所有人。知道我们是朝着这个目标而去的。只有一起调整各自的计划,才能完成一个更大的路线图(产品路线图 product roadmap)

发布计划例子:

总结,

发布计划告诉我们,敏捷是通过短迭代不断的调整着自己的计划的,但是并不是说敏捷就没有计划了。发布计划正是一份可以取代过去甘特图的动态计划,并且让多团队各自快速达成一致性。

博君一笑 - 敏捷转型

这是我从linkedin中摘录过来的一个漫画。
很难界定在企业中,如漫画所述的内容是对还是错。每个企业在这么做的过程中都有其背后无数的理由。所以说,在当下问10个人,10个人会说出10个不同的敏捷。
也有人说,敏捷就如盲人摸象,而以现在的我的视角看来,在不违反大敏捷原则和价值观的基础上,任何组织,流程的设立都是make sense的,只要是大家agree取得consensus的。
艾灸是一种内心的质变。也如金刚经所述“诸相非相”。

Can your integration team really use agile?

来自guidewire platform的一篇博客,个人觉得对于解释integration 团队作用甚大。
Other than wondering how to manage integration dependencies, the most frequent question I hear during the software evaluation phase is about the applicability of an agile development process to an integration team.
Of course! It’s just a little (maybe a lot?) more challenging than the product configuration tracks. Here’s why:
  • The scope of the integration work is mostly dependent on other groups in the company, as well as third-party software or service vendors;
  • The program in general, and the integration track in particular, have little to no control over what development methodologies these other teams use;
  • It’s most likely that the other teams are in business-as-usual (otherwise known as BAU) mode, with little capacity or budget for changes; and
  • Many integration themes (e.g. think general ledger, statistical reporting, data warehouse, etc.) are large chunks of work, which can’t be developed, documented and unit-tested within a 2- or 3-week sprint
Now that I’ve sufficiently scared you, let me explain how you can deal with all of these challenges using agile principles.
Despite the direct lack of control over these teams, you can agree during your project inception on a few items that go a long way to an on-time, on-budget delivery.
Definition of done
Before you begin, it’s important to agree on what the definition of done is. It seems obvious but you would be surprised at how many development teams overlook basic expectation-setting. This list can vary across projects, but usually includes:
  • Code which has been fully implemented and checked in
  • Unit tests with a minimum code coverage level
  • All appropriate detailed design documentation
Milestones
Modern software interfaces have different levels of maturity. One simple definition might specify
(1) the operation and interface definition itself,
(2) a working interface that returns mock data as a response,
(3) that same interface with the ability to accept real data and return a non-mocked response,
(4) the interface meets the definition of done and is ready for end-to-end stabilization testing.
Agreement on these kinds of maturity milestones will go a long way to de-risking your project. Any two teams, following the same timeline and ashared set of milestones, can move forward with their respective implementations. Each team is then empowered to schedule work as they see fit, with the methodology they prefer (or is mandated by their department, of course.)
Splitting work into sprints
The basic agile principle of breaking down work into smaller pieces can apply to types of epic user stories mentioned above. Most of this should be done during inception, but during sprint planning the team can further refine the tasks associated to these monster stories.
With some common sense and a few of these agile principles, your integration team can realize all of the benefits as the rest of your program.

Large-scale agile frameworks compared: SAFe vs DAD

最近很懒,所以直接转发
Though everyone is going agile these days, a common complaint is that agile development doesn’t scale well. Many of the concepts and recommendations, like using small, self-managing teams, work well for small projects. But guidance may be lacking when it comes to coordinating multiple teams working on a large-scale project, especially in early phases of the project, before coding begins.
A number of agile frameworks are now available for large-scale enterprise projects, but the first step in choosing one to fit your organization’s needs is education. This article focuses on two popular large-scale agile frameworks: Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). It provides a quick overview, describes the strengths and weaknesses of each, and looks at what’s ahead for the frameworks.

Start with the basics: Learn scrum and agile

Large-scale agile frameworks build upon many of the ideas, concepts, and techniques used in scrum and other lean and agile frameworks. Scrum is the most common agile framework. In fact, it is referred to so often in agile literature that many people use the terms scrum and agile interchangeably. For those new to agile, the first recommendation would be to get some basic agile and scrum training. You wouldn’t want to start building a house without knowing how to use a hammer. As such, it’s important to learn basic terminology, concepts, and techniques, providing you with the building blocks for understanding any other agile framework.
Those who have been working in an agile environment with small teams will have an easier time extending their current practices to a large-scale framework. Scrum provides the basic tools, and the large-scale frameworks will provide some additional tools.
Continuing with the construction analogy, scrum will give you what you need to install the electrical, plumbing, and drywall, and to build furniture for the house. However, if you want a blueprint in which there is some consistency in the way the rooms are laid out, you need a solid architecture and agreement on certain standards so there’s a common look and feel throughout the house. Large-scale agile frameworks provide that kind of architecture. They give you the tools to help coordinate larger projects so that teams can build on a solid foundation, take advantage of reusability. and maintain consistency of agreed-upon standards.

What is Scaled Agile Framework (SAFe)?

The Scaled Agile Framework, developed by methodologist Dean Leffingwell, uses a combination of existing lean and agile principles and combines them into a methodology for large-scale projects.
SAFe includes Team, Program, and Portfolio processes. At the Team level, the techniques outlined are those used in scrum, recommending two-week sprint cycles. At the Program level, SAFe extends scrum by using the same ideas but one level up. The Program level works on a Release Train, which is composed of five sprint cycles. There’s also a sixth innovation planning sprint, which allows teams to innovate, inspect, and adapt. Roles and processes are defined at the Program level, which allows for consistency and collaboration across the project. SAFe also provides processes one level higher, at the Portfolio level, using lean principles, such as optimizing value streams to help executives and leaders identify and prioritize epics, and features that can be broken down at the Program level and scheduled on Release Trains.

What is Disciplined Agile Delivery (DAD)?

Disciplined Agile Delivery, developed by Scott Ambler and Mark Lines, is similar to SAFe in that it recommends using existing lean and agile techniques. DAD, however, aims to address areas that aren’t thoroughly covered in smaller-scale agile frameworks. This framework recommends three phases: Inception, Construction, and Transition. While many agile frameworks address what DAD labels the Construction phase, DAD gives recommendations on processes that come earlier in the project (inception) and as teams prepare for delivery (transition). For this reason, DAD’s strengths are in providing more guidance in the areas of architecture and design (inception) and DevOps (transition).
DAD also provides flexibility in suggesting different process guidelines for four categories of lifecycles: agile/basic, lean/advanced, continuous delivery, and exploratory. The Construction phase of agile/basic is scrum, but DAD, as in each of the four lifecycles, adds recommendations for the Inception and Transition phases. The lean/advanced lifecycle uses processes similar to Kanban, maximizing flow and minimizing work in process. The continuous delivery lifecycle focuses on mature DevOps, continuous integration, and deployment processes for projects that require frequent delivery to stakeholders. The exploratory lifecycle minimizes early planning in favor of fast delivery, gaining feedback, and incorporating that feedback into the next delivery.

Pros and cons of each framework

SAFe has been criticized for being too prescriptive, not allowing teams as much flexibility in process decisions. Some critics feel that SAFe is not pure agile because there is more upfront planning and some top-down processes. Having too much process definition implies a lack of flexibility in approach, which goes against one of the primary agile characteristics of adaptability.
Though agile purists may feel this approach is too structured, that may be exactly what’s needed for those who are transitioning from a more traditional environment, especially in the context of a larger project. A common failure for agile adoption is the difficulty in introducing such a major cultural change to an organization. SAFe provides the structure that may make for a smoother transition to an agile framework. SAFe also follows agile practices of inspecting and adapting, even providing an innovation sprint and stressing autonomy and decision-making for the knowledge workers.
With four lifecycle models, DAD provides more flexibility in project guidance and recommendations for best processes within each type of project. In the construction analogy, DAD provides a basic framework for building a cottage, a mansion, a townhouse, or a mobile home. Rather than providing a prescriptive blueprint, it provides guidance on the types of tools and processes you might want to use, depending on the type of house you are building.
Though this flexibility may be appreciated by those with a good understanding of agile, it might not provide enough guidance for those who are transitioning from traditional models. Marketplace adoption for DAD is slow compared with SAFe. And though DAD and SAFe are more complementary than competitive, due to the lack of specific guidance, experienced coaches and consultants are more likely needed to successfully implement DAD.

What’s next?

Though the ever-growing number of frameworks and the various opinions about them can be confusing, they demonstrate the adaptability that agile is known for. Continuous evolution and debate, though frustrating for those who want definitive answers, lead to one thing that all agile methodologists agree on: the need to inspect and adapt. The experiences of those who use the frameworks, both positive and negative, help provide data for the next “version,” whether that be improvement of a current framework or a new framework altogether.
When asked what’s next for DAD, Scott Ambler answers: “The Disciplined Agile framework is constantly evolving. Right now we are in the process of releasing Disciplined Agile 2.0, which extends DAD into the IT space to explicitly address areas such as Enterprise ArchitecturePortfolio Management, Reuse EngineeringDisciplined DevOps, and many other key activities.”
Meanwhile, Dean Leffingwell recently released SAFe 4.0. He writes: “We’ve been extracting and refining the immutable Lean-Agile principles on which SAFe is based. In so doing, we’ll be able to make the Principles and Practices clear and distinct, and further elaborate the principles (like “Limiting WIP”) without worrying about elaborating the principle in the body of a particular article.”
Regardless of whether you choose to work with SAFe, DAD, or another framework, the first step is to educate your organization and get a firm grasp on the lean and agile principles that make up the frameworks. In doing so, your team will have the tools to build a house of any size.