はてなブックマーク

たまに耳にする「スクラムバン」が気になったので調べてみました。元ネタはCorey Ladasさんによって書かれた「Scrum-ban（スクラムバン）」です（2008年の記事なのでちょっと古いけど）。なかには読み間違い、勘違いがあるかもしれないですが、読んで感じた私の主観をふまえてまとめてみます。 スクラムバン？ スクラムが世界的に広がっているので、その中でカンバン（方法論としてのカンバンです）に興味を持っている人を見つけるのはかなり簡単でしょう。なぜなら、みんなプロセス改善やマネジメント、リーンのアイデアなどに興味があり、仕事で活用したいと思っているからです。 カンバンはチームの性能を高めることに役立ちます。すでに現在、スクラムに取り組んでいるところでも活用できるはずです。スクラムバンでは、スクラムとカンバンのハイブリッドを現場で活用する方法が説明されています。 価値と量をコントロールする

「アジャイルソフトウェア開発の概要はわかったので、具体的な事例を知りたい」 アジャイル開発をテーマにした講演や研修に出かけていくと、この質問によく出会います。さまざまな立場の人たちと長らくこの問答を続けることで、わかってきたことがあります。それは、ひとくちに「事例」といっても、質問者が知りたいことは「プロジェクト実績」や「実際に起こった個々の出来事」に留まらないということです。この問いに込められている、質問者が本当に知りたいことを私なりに書き下せば次のような感じです。 日々のソフトウェア開発の現場で、 実際に起きる個々の出来事について、 アジャイル開発の知識を踏まえたうえで、 自分は都度、どのような意思決定を下していけばよいのか？ この質問の核心は「未体験のことへの不安」だと私は捉えています。リーン原則は開発プロセスについてのメンタルモデルであり、カンバンはワークフローの設計ツールです。ス

『リーン開発の現場』越境せよ！ 塹壕より。2013年10月26日発売の『リーン開発の現場 カンバンによる大規模プロジェクトの運営』のサポートページです。「かんばん」「リーン開発」を中心に、アジャイルな開発情報を発信しています！

(注)昨日の「Spotifyのスケーリングアジャイル」に続き、ヘンリックの許可を得てversion 1.1をざっくり意訳しました。細かい表現は主観で訳したので、気になる方は原文：How Spotify builds productsをどうぞ。訳に対するヘルプも歓迎します。 プロダクト開発は簡単ではない。実際に、そのほとんどの努力が失敗している。そして、その失敗に共通するほとんどの理由が、間違ったものを作ってしまうことだ。 Spotifyはスウェーデンのリーンスタートアップだ。そして、Spotifyはプロダクトデリバリーにおいて素晴らしい実績を持っている。Spotifyのプロダクトはユーザーやアーティストによって愛されており、ウイルスのように世界へと広がっている。アクティブユーザーは2000万人を超え、課金ユーザ（paying subscribers）は500万人と急成長している。例をあげる

ソフトウェア開発において、Todo、Doing、Doneを貼りつけた、シンプルな「かんばん」を使っている人は多いと思います。ただ、「リーンなかんばん」を使っている人は、まだまだ少ないでしょう。ここでいう「リーンなかんばん」とは、Kanbanという方法論で使われるツールです。 今回は、リーンかんばんの作り方について、Marcus Hammarberg氏の「Kanban in practice」という資料をベースに解説してみたいと思います。 用語について この記事では、わかりやすくするために、従来のかんばんとリーンかんばんをわけて表現します。また、かんばん上の縦の領域をステージ（舞台・段階）と呼び、横の領域をレーンと呼んでいます。 さらに、かんばんにはカードや付箋が貼りつけられます。カードと付箋の使い分けについては、また別の機会に整理したいと思います。

(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「

Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー（PO）の役割で、青い人たちが開発チーム（DEV。ここでは2名ずつ2チーム）、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP（Work in Progress：仕掛り作業）が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。

かんばん（Kanban）という方法論が誕生するまでの経緯が、『Kanban – Successful Evolutonary Change for Your Technology Business』（以下、かんばん本）に書かれていたので、ななめ読みですがご紹介です。 Kanbanとkanban かんばん本において、著者であるDavid J. Anderson氏は、大文字ではじまる「Kanban」と、小文字で始まる「kanban」を使い分けています。 Kanbanは方法論としてのかんばん kanbanはツールとしてのかんばん Kanbanでは、kanbanを使って、プル型システムであるkanbanシステムを実現します（ややこしいですね）。詳細については、英語版Wikipediaの「Kanban(development)」を日本語に訳したので、そちらも参照ください。 顧客からのプレッシャーとの

翻訳する上で、「かんばん」についていろいろ調べる機会がありました。「かんばん」について調べてみると、トヨタにおける「かんばん」と、ソフトウェア開発方法論としての「Kanban」が見つかります。今回はこの「かんばんたち」の違いについて、簡単ですが整理してみたいと思います。 トヨタのWebサイトで説明されいている情報がとてもわかりやすいので参考にしました。トヨタのかんばんのポイントは以下です。 生産管理方式。トヨタ生産方式で重要な役割となっている。 商品管理用のカードをかんばんと呼ぶ。 後工程が前工程に部品を調達しに行く際に、シグナルカードとして運ばれる道具がかんばん。 これによる効果は以下が挙げられます。 必要な部品を必要なだけ（ジャスト・イン・タイム）前工程に取りに行く（プルする）ことで、ムダな生産を改善する トヨタのWebサイトにあるかんばん方式の概念図を見ると、かんばんは運搬され、目印

Agile Conference Tokyo 2013に行ってきました。会場は満席に近く大盛況。コンテンツも目白押し。そんな中、ThoughtworksのKraig T.Parkinson氏によるキーノート「戦略としてのカンバン:ビジネスイノベーションのために」の感想を書いてみます。すげー意訳しています。 イントロダクション Thoughtworksは言わずと知れた開発企業です。15年前に60名だったスタッフも、グローバル化によって2000人へと増加したそうです。グローバルとはいえ、組織は似たような問題を持っています。例えば、「従来型のやり方にしばられてしまう」というのは典型的な課題でしょう。しかし、アジャイル開発のような手法は、すべてを投げ出すぐらいの意気込みがなければ実践は難しいものです。 すでに従来型産業と技術産業を区別する時代は終わりました。IT部門という考え方も古臭いものです。現

『リーン開発の現場』越境せよ！ 塹壕より。2013年10月26日発売の『リーン開発の現場 カンバンによる大規模プロジェクトの運営』のサポートページです。「かんばん」「リーン開発」を中心に、アジャイルな開発情報を発信しています！