かんばん方式を実践する
InfoQ: では，変化を受け入れる合意ができたとしましょう。私たちは正しい選択をしたいと思います。それが革新的な変化を伴うのならば，その心構えもします。その一方で，斬新的な変化で大きな改善が望めるのなら，できればそちらを選びたいとも思うでしょう。デリバリや予測可能性，透明性の改善といった観点で，結果を目にしたいのです。 Roock博士: 経験から言えば，かんばん方式を導入するまでは，大きな目標に対する同意が必要です。それはつまり，マネージメントの介入が必要だということです。 あるいは草の根的な "ステルス" アプローチで，マネージメントから隠れて，チーム内だけで事を進めようとする場合もあるでしょう。そのようなアプローチでもある程度は成功できるかも知れませんが，すぐに限界に突き当たってしまいます。企業規模での本当の成功を望むなら，マネージメントの介入は必要なのです。マネージメントと話して，
)
スクラムのリーン
David Starr 著。 David Starr は、Scrum.org のチーフ ソフトウェア クラフトマンであり、ソフトウェア開発という専門職の能力を向上させることに注力しています。 彼は、オンライン テクニカル コミュニティである ElegantCode.com の設立者でもあります。 2012 年 7 月 スクラム フレームワーク特有のリーン品質と、リーン思考を使用してスクラム チームの生産性を向上させるために役立つさまざまな方法について考察します。 対象 Team Foundation Server Overview Seeing Scrum Through the Lean Lens Toward Leaner Scrum Conclusion アジャイル ソフトウェア開発に関する現在の議論では、ソフトウェアの開発活動を計画、監視、実行するための 3 つのツールとして、スク
カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ
カンバンを導入する間違った理由5個
みなさんこんにちは。@ryuzeeです。 ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。 5つの間違い1.ユーザーストーリーの多様性我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う 2.スプリントがうまくいかない1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う 3.ふりかえりミーティングがうまくいかないふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う 4. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
アジャイル開発の実態調査(State of Agile Development Survey Results) (1)：An Agile Way：オルタナティブ・ブログ
毎年注目している、VersionOne社の State of Agile Development Survey Results ですが、昨年の結果が発表されています。この調査はもう６年続いていて、ぼくも毎年追っかけているものです。ここ数年は同じ傾向が続いているのですが、いくつか解説したいと思います。（たぶん連載） 結果のソース⇒http://www.versionone.com/state_of_agile_development_survey/11/ まずは利用されている方法論。これは、昨年とほとんど変わっていなくて、やっぱりScrumとXP+Scrumを足すと70%に近い。Scrumの圧勝だ。XP単独というのは2%まで下がっている。今年の大きな変化は、Kanbanが認知されたことだろう。3%にまで上がってきている。それでもまだ3%というのがScrumの強さを物語る。また、Custom
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2012/01/17/20120116agile-project-management-software-swift-kanban-aims-to-help-organizations-get-lean/
