| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Lean Architecture

Page history last edited by Dave Laribee 15 years, 5 months ago

Why is Release-per-Feature desirable? This session started with "popping the why stack" on this question. A few ideas we came up with:

 

1. It's a competitive advantage

2. Bigger ROI, Shorter Payback

3. Flow (pop the why stack on that, too)

4. ?

 

We then started dealing with the how. A few main topics emerged:

 

Composite Applications

 

Features are simply components or modifications to components. We can also turn things on/off. This is important as simply working off the mainline won't cut it anymore. If we release partial features, it's possible that we'll create semantic difficulties or out-and-out defects for users.

 

Branching Strategies, Distributed CI

 

Create a branch-per-feature. When a feature is done with development/test we merge back into mainline and deploy from there. There is a "simulator branch" that all feature branches auto-merge into on each commit (or part of the build pipeline). If a merge fails here, we stop the line (Andon) to deal with the merge issues.

 

We covered the idea that build pipelines (dependent CI builds that take artifacts through a series of work cells) often mimic the layout of your Kanban.

 

Team Composition

Pooling, feature crews, etc.

 

#

 

More coming soon ~ Dave Laribee

Comments (0)

You don't have permission to comment on this page.