InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
いつものかんばんをリーンかんばんに進化させる方法
ソフトウェア開発において、Todo、Doing、Doneを貼りつけた、シンプルな「かんばん」を使っている人は多いと思います。ただ、「リーンなかんばん」を使っている人は、まだまだ少ないでしょう。ここでいう「リーンなかんばん」とは、Kanbanという方法論で使われるツールです。 今回は、リーンかんばんの作り方について、Marcus Hammarberg氏の「Kanban in practice」という資料をベースに解説してみたいと思います。 用語について この記事では、わかりやすくするために、従来のかんばんとリーンかんばんをわけて表現します。また、かんばん上の縦の領域をステージ（舞台・段階）と呼び、横の領域をレーンと呼んでいます。 さらに、かんばんにはカードや付箋が貼りつけられます。カードと付箋の使い分けについては、また別の機会に整理したいと思います。
スクラムチームのためのカンバンガイド by Scrum.org
※本記事は旧版です。最新版（2019年9月）はオフィシャルサイトからPDFをダウンロード可能です。 この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。 目的カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。 この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受
カンバンの基本のキ - Qiita
この記事は Rakuten Advent Calendar 2016 の記事です。 こんにちは、アジャイルモンスターこと及部敬雄（@TAKAKING22）です。 現在は最近できたスタートアップの部署に所属しており、エンタープライズスタートアップの成功例をつくるべく、チームづくりからプロダクトマネジメントから越えられる壁はすべて越えるつもりで日々奮闘しております。 今日はカンバンについて取り上げてみます。 ペンと付箋があれば始められる オンラインサービスも数多く存在する アジャイル開発を取り入れているか否かに関わらずエッセンスを取り入れることが可能である など導入のしやすさから、今ではメジャーなソフトウェア開発手法の1つになっています。実際に皆さんの現場でもカンバンを運用している、あるいはまわりで運用しているチームがいる方も多くいらっしゃるのではないでしょうか？ 楽天でも、私がカンバンを始め
5分で理解するリーンな「かんばん」
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー（PO）の役割で、青い人たちが開発チーム（DEV。ここでは2名ずつ2チーム）、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP（Work in Progress：仕掛り作業）が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
Pairs事業部全体での「カンバン」をまたまた作り直しました。
これまでの「カンバン」の課題週一で行っているプロセス改善委員会にて、いくつかカンバンV2に関する課題点などがエンジニア・POなど職種問わずあがるようになりました。いくつか代表的な課題点についてまとめます。 「エピック」「ストーリー」など言葉の定義から認識がバラバラで、チケットの大きさがわからないカンバンV2では、各ストーリーやタスクなどを紐付ける大きな単位として「エピック」を定義し各エピックごとに横軸のレーンを用意、それぞれのレーンの中でストーリーやタスクなどを動かし、プロジェクトのステータスを表していました。 しかし、運用していくにつれ、各チーム間でエピックやストーリーとして言われているものの粒度がバラバラに・・。エピックとして扱うものがストーリーとしてカンバン上に鎮座し何週間も動きがないチケットがあったりと、それぞれのプロジェクトチームごとに異なる粒度でチケットが定義されていました。
なぜWIPの制限が重要なのか
みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2. タスクの切り替えが減る一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
タウンワークをドライブさせるためになんちゃってアジャイルをやめた話 #devsumi #devsumiB / devsumi2018
スクラムチームをやめて、20人でカンバン運用してきた半年間の軌跡 / Stop Scrum Start Kanban