タスクボードの改善事例がたくさん詰まった「アジャイルコーチの道具箱 – 見える化実例集」を読んだ #見える化実例集 - 邪道（旧）
「アジャイルコーチの道具箱 – 見える化実例集」を読んでみました。 leanpub.com この本はタスクボードを中心とした見える化のTipsがひたすら紹介されている本です。 Tips集なので前から読んでいく必要もなく、気になったTipsを辞書感覚で見たり、気軽にパラパラめくって読むことができました。 読みながらツイートしていたので、臨場感あふれる感想を貼っておきます。 ボードのリファクタリングってけっこう重要。ずっと同じだと飽きちゃうし、情報量多いと見ないし。ホワイトボード使うと面積という制限があるからいいよね。 "情報がどんどん追加されて、どんどん複雑になっていってしまう" #見える化実例集 #アジャイルコーチの道具箱— OYB48 (@TAKAKING22) 2016年4月16日 カンバンにないタスクが増えるときはすぐに全員で足すかどうかを決めて、足すときは違う色の付箋orシンボルつ
スチレンスプリントボードとスプリントバックログマッピング - Mitsuyuki.Shiiba
モヤモヤ チームのメンバーから「ホワイトボードが使いづらいー」というモヤモヤがあがってきました。今まで、ホワイトボードに付箋を貼ってスプリントボードにしてたんです。でも、ちょっと前に席替えがあって、ホワイトボードが使いづらい場所になっちゃったんですね。 モヤモヤ会 余談ですが。楽天の大阪の開発部ではモヤモヤ会というものがたまにあって、そこでは全員が集まって今モヤモヤしてることを共有するんです。そこで出たモヤモヤは、マネージャーやリーダーが出来る限り解決していきます。詳しくはAgile Japanでうちのマネージャと一緒に話したこのスライドで。後半部分ね。 組織とスクラムチームのあいだ from Mitsuyuki Shiiba スチレンボード？ んー。どうしようかなー。と考えてみて思い出したのが、川口さん( @kawaguti )と佐藤さん( @sato_ryu )の「スチレンボードいい
ソフトウェアかんばんと仕掛けかんばん、引き取りかんばん - プログラマの思索
「アジャイル開発でよく言われるソフトウェアかんばんとは、仕掛けかんばんなのか？ 引き取りかんばんなのか？」という質問を聞いたので、改めて調べてみた。 完全に理解できてないので、情報だけ集めておく。 【元ネタ】 InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ カンバン - Wikipedia 教えて！Ziddyちゃん - 生産管理について2点 かんばん生産入門 第1回 かんばん（狭義） | J I T基本用語集 仕掛けかんばん | J I T基本用語集 引き取りかんばん | J I T基本用語集 飲食店に学ぶ生産管理トップページ InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへの記事のように、平鍋さんはソフトウェアかんばんに、トヨタ式生産方式(TPS)にある仕掛けかんばんと引き取りかんばんのアイデアを注入しようと試されている
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
カンバンはどのように動作するか
CT (Cycle Time)は、アイテムを完了させるのにチームが必要とする平均時間です。 リトルの法則の力学はすばらしいものです。ソフトウエア開発の複雑な状態を説明し、解決策をもたらしてくれます。次のケーススタディを分析するために、Diagrams of Effects2を活用します。この図は、非線形のシステムやふたつ以上の効果や影響がシステムの振る舞いに影響を与える場合を分析するのに優れた効果を発揮します。 ケース1: チームのスループットを増大する Adamはふたりの開発者とひとりのテスターで構成するチームのコーチで、企業の幅広い製品のメンテナンスに責任を持っています。この企業は2013年に製品のマーケティングに投資を行い、なんとか顧客を2倍に増やしました。今、Adamのチームの受けるサポートリクエストは増大しています。しかし、CEOはチームのサイズを大きくするつもりはありません。
インフラで実践したチームビルディングそれはサバ天 : インフラエンジニアに成る
スクラムにあこがれて。 インフラで実践したチームビルディングそれはサバ天 from ume3_ カンバンをやってカイゼンをしたというお話です。 ここ1年ぐらいずーっとリーダーとして チームビルディングに勤しんでいた。 チームを強くするにはどうすればいいか？ チームでわいわいやるにはどうすればいいか？ 簡単な話、仕事ってどうやったら進むのか？ それをつきつめていった結果、なぜか特異な結果が生まれた。 なんだこれは。 社内に共有したものをせっかくなのでこちらへ公開という流れです。 モザイク多いのは勘弁。 これでも、けっこう内容けずったのです。 やっていることは、ホワイトボードの前で付箋紙はってわいわいやっているだけ。 スライドでは説明不足ですが、サイクルがちゃんとあって ぐるぐる回すことでチームが加速化するのが狙い。 見える化の力を今も実感しています。 こういったフレームワークの活用からの発展
トヨタのかんばんとソフトウェア開発のかんばんの違い
翻訳する上で、「かんばん」についていろいろ調べる機会がありました。「かんばん」について調べてみると、トヨタにおける「かんばん」と、ソフトウェア開発方法論としての「Kanban」が見つかります。今回はこの「かんばんたち」の違いについて、簡単ですが整理してみたいと思います。 トヨタのWebサイトで説明されいている情報がとてもわかりやすいので参考にしました。トヨタのかんばんのポイントは以下です。 生産管理方式。トヨタ生産方式で重要な役割となっている。 商品管理用のカードをかんばんと呼ぶ。 後工程が前工程に部品を調達しに行く際に、シグナルカードとして運ばれる道具がかんばん。 これによる効果は以下が挙げられます。 必要な部品を必要なだけ（ジャスト・イン・タイム）前工程に取りに行く（プルする）ことで、ムダな生産を改善する トヨタのWebサイトにあるかんばん方式の概念図を見ると、かんばんは運搬され、目印
かんばん方式を実践する
InfoQ: では，変化を受け入れる合意ができたとしましょう。私たちは正しい選択をしたいと思います。それが革新的な変化を伴うのならば，その心構えもします。その一方で，斬新的な変化で大きな改善が望めるのなら，できればそちらを選びたいとも思うでしょう。デリバリや予測可能性，透明性の改善といった観点で，結果を目にしたいのです。 Roock博士: 経験から言えば，かんばん方式を導入するまでは，大きな目標に対する同意が必要です。それはつまり，マネージメントの介入が必要だということです。 あるいは草の根的な "ステルス" アプローチで，マネージメントから隠れて，チーム内だけで事を進めようとする場合もあるでしょう。そのようなアプローチでもある程度は成功できるかも知れませんが，すぐに限界に突き当たってしまいます。企業規模での本当の成功を望むなら，マネージメントの介入は必要なのです。マネージメントと話して，
ソフトウェア開発における「かんばん」とは何か - プログラマの思索
@daipresentsさんが、ソフトウェア開発における「かんばん」をWikipeidaに記載していたのでリンクしておく。 内容が整理されているので、大変参考になる。 【元ネタ】 Twitter / akipii: @daipresents さんがWikipediaに書いた「かんばん」の説明。これは力作！ アジャイル開発に携わる人は必見かな。かんばん (ソフトウェア開発) - Wikipedia http://bit.ly/15jvK8O かんばん (ソフトウェア開発) - Wikipedia 【１】上記の記事では、日本の製造業が生み出した「かんばん」をソフトウェア開発へ適用した「かんばん」として説明している。 「かんばん」の最大の特徴は、上記の記事にあるように、「かんばん」を仕掛品(Work-in-progress)という未完成の中間物とセットで運用することで、仕掛品を減らして在庫を減ら
Kanban and Scrum 〜 デブサミ2013 OpenJam で発表してきました。 - kawaguti’s diary
デブサミ2013の Open Jam で発表をしてきました。 最近周りでカンバンについて整理してほしいという要望をいただいたので、作ってみた資料です。 今年も関さん( @m_seki )に鋭いご指摘を頂きました。「ScrumとKanban、入り口をあえて分ける必要がないのでは？」うーむそうかもしれません。どっちから入っても、Kanbanなら多能工が重要になってロールがオーバーラップしていくし、Scrumなら徐々にプロセスが安定化して列が増えていきます。関さんとは昨年のOpenJamでのSECIモデルの話を一緒にさせていただいたのですがすごく勉強になりました。 instagramで白羽さんに撮影していただいた風景です。( instagramからの貼付け方が分からず画面キャプチャです。) 結構、聞いてくださる方が多くて感動しました。(ほとんど技術と関係ないカンバンの話ですみません。) 長々と謝
振り返ればカンバンがある ~チームとカンバンとProduct Ownership~
2013年1月15,16日開催のScrum Alliance Regional Gathering Tokyo 2013 (http://scrumgatheringtokyo.org/2013/) にて発表した資料。チームとカンバンの変化から見えてきた価値提供のために必要なことを考えてみた。Product Ownershipは一緒に働く事からはじまるのかもしれない。Read less
End of Methodology (日本語訳)：An Agile Way：オルタナティブ・ブログ
アリスターコーバーンの新着記事『方法論の終焉』(End of methodology)の翻訳です。この翻訳は、twitterを使って数名で短時間で人力翻訳する、という実験プロジェクトでやってみました（末尾にその話）。 元記事は、こちら。http://alistair.cockburn.us/The+end+of+methodology アジャイル開発が「方法論」といった体裁からどんどんはなれ、「自分たちで自分たちやリ方を(Reflective=ふりかえり)どんどんよくしていく(Improvement=改善)そんな枠組み（Framework)」になっていったことに、一つの名前を与えようとしている。そんな話です。この名前自体（当然その日本語も）まだ良いものではなく、新しい名前がこれにつくことの前兆となる記事だと思っています。 方法論の終焉(End of Methodology) by Ali
)
スクラムのリーン
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 つのツールとして、スク
[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18) – manaslink
[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18)Published by きいろいの on 2012年8月16日2012年8月16日 ストックホルムのCrisp社でアジャイルおよびリーンのコーチをしており『塹壕よりScrumとXP』の著者でもあるヘンリック・クニベルグ氏。日本でも、Qcon2009やScrum Gathering Tokyo 2011でスピーカーを務めています。 Agile2012では「Lean from Trenched: Managing Large Scale Projects with Kanban & Scrum & XP」というテーマのもと、大きくなっていくプロジェクト／組織に対して、どのようにカンバン・スクラム・XPなどのツールを用いてマネジメントしていくのかを話しました
![[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18) – manaslink](https://cdn-ak-scissors.b.st-hatena.com/image/square/aaaa9c17144e25c0f9756ff274d0a2ddb4b3e294/height=288;version=1;width=512/https%3A%2F%2Fwww.manaslink.com%2Fwp-content%2Fuploads%2F2012%2F08%2Fd12c568f883b46aef2eeec1071bbdab51.jpg)
[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17) – manaslink
[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17)Published by きいろいの on 2012年8月16日2012年8月16日 Henrik Knibergによる、かんばんを用いたプロジェクト運営の事例紹介。 この発表のベースは書籍があり、Pragmatic Bookshelf から出ている。また、発表スライドは、Henrikのブログから入手できるので、参照してほしい。 書籍：『Lean from the Trenches: Managing Large-Scale Projects with Kanban』 スライド：Lean from the Trenches @ Agile2012, Dallas 実物のかんばんが登場するため、話にリアリティがある。また、Henrikのトークスタイルは、ライトニングトーク的な忙しさで聴き手を
![[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17) – manaslink](https://cdn-ak-scissors.b.st-hatena.com/image/square/39517f3e9f7cd7031ce7a50253a343e12d68c2c7/height=288;version=1;width=512/https%3A%2F%2Fwww.manaslink.com%2Fwp-content%2Fuploads%2F2012%2F08%2Fhenrik_233-175.jpg)
Web開発チームをタスクボードだけで見える化する 5つのコツ - Lancers開発ブログ
はじめまして。今月からランサーズにJOINしましたkeiと申します。 長らく更新が滞っていた本ブログですが、これから定期的に情報発信していこうと思ってますので、どうぞよろしくお願いします！ ランサーズでは、エンジニアの作業を見える化するために、タスクボードを導入しています。 今回は、社内で運用してみて効果的だった5つのコツをご紹介します。 タスクボードとは ボードを作業予定、作業中、作業完了(ランサーズではToDo,Doing,Done)の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. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【情報】タスク管理に最適なツール10選 AgileNewsFlash
Kanbanは新しいScrumか？
