投稿元:
レビューを見る
かんばんで見える化、とは言われるものの、「何のために見える化するの?」には明確に答えられない人が多いと思う(少なくとも自分の周りには)
この本を読むと、見える化したその先が具体的にイメージしやすくなるのではないかと思う。
身近に詳しい人がいなかったり、セミナーに参加するほどではくてWebや書籍で済ましたいという人には、この本をおすすめしたいと思う。
単なる作業の管理ツールではなく、改善のツールであることを多くの人に理解してほしい。
(そんなの当たり前じゃん、と余裕で言えるレベルの人には本書は不要かもしれない。)
投稿元:
レビューを見る
「カンバン」に関するかなり網羅的な解説書。語りもストーリー形式になっていて、頭に入りやすい。多くの組織ではスクラムよりカンバンの方がとっつきやすいと思われるため、マネージャーにとっては読む価値があると思われる。
投稿元:
レビューを見る
カンバンの使い方について物語を交えて書いている本。
ちょっとカンバン運用で迷った時に読むにはベストな本で、物理的な本を買うのが非常にオススメ!
投稿元:
レビューを見る
スクラムについて簡単に解説されている本
図と漫画が多いので読んでいて楽しい
実際の現場はすぐにカオスになるので、そうならないためにどうすればいいかっていうロールプレイができるのがうれしい
投稿元:
レビューを見る
アジャイルの勉強の一環で読み進めてみたが、気合い入れないと理解できない、構造(英書だから?)なので途中で挫折。。とほほ。
投稿元:
レビューを見る
感想は以下
http://masterka.seesaa.net/article/443533608.html
投稿元:
レビューを見る
■エッセンス
見える化が重要
カンバンの本質はWIP制限とそれによる改善
■感想
カンバンの導入本としては、分かりやすく網羅的だったので良い本だった。
ただ、中だるみというか冗長な部分があったのでもう少し薄いと読みやすい。
カンバンの優位性として、「どんなチームでも今から始められる」というのが印象に残っている。
ソフトウェアの開発は様々な方法が提案されているが、まず教育コストが非常に多くかかる事が多い。
その中で、この点がカンバンの強みだと思う。
また、見える化やWIP制限で自然と改善のきかっけを作れるのが非常に良い手法だと思った。
チームや状況に合わせて少しずつ最適化されていくのが素晴らしい。
本書に載っている全てを試す必要は当然無く、チームにとって必要な方法を取り入れると良い。
ただ、一つだけ懸念点がある。
自分が抱えているチームは本書のようにシーケンス毎に担当が分かれていない点だ。
一人で設計から実装・テストまで行うため、書かれていた導入例を元に設定することは出来ない。
ある意味で、WIPを一人ひとりに対して制限をかければ楽ではあるのだが、懸念は別の所にある。
一人が最初から最後までやる性質上、仕事の出来る人と出来ない人の見える化をし過ぎてしまう可能性がある。
ある人はどんどん仕事を進めるのにも関わらず、ある人はずっとWIPのまま。
上記が見える化することは改善でもあり、空気を乱す事を嫌う日本では改悪にもなりうると少し思った。
マネジメントや人事の評価がきちんとしているのであれば、このような点は簡単に解消されるかもしれない。
しかし、そうでない場合は、人間関係がギスギスするリスクがある気がする。
これはカンバンの問題というよりは、自分の所属するチームや会社の問題なので、問題が見えた所で最適な改善点を考えていきたい。
投稿元:
レビューを見る
http://public-errata.appspot.com/errata/book/9784873117645/
投稿元:
レビューを見る
始めるのをやめて、終わらせることを始めよう: Meet Up 大阪 @ blog
http://meetuposaka.seesaa.net/article/449306537.html
投稿元:
レビューを見る
Spotify というとても成功しているサービス。
その開発でカンバンが使用されている。
なんでもそうだし、どんなツールだって銀の弾丸ではない。
ただ成功している場所があるのだから、必ず失敗するとは絶対に言うことはできない。
まず課題。その解決方法に見える化。
複雑にせず、簡単にやれることをやる。
そう運用するためのツールがカンバンだと思わせてくれます。
読むと単純に簡単に見えますが、実際にはそんなことはありません。
運用にのるまではとても大変でしょう。
そこをのせるための運用者の力が試されるものだとは思います。
(以下抜粋。○:完全抜粋、●:簡略抜粋)
○家族が寝ているときに原稿を書き、家族と一緒に過ごすべき時間に原稿を書き、家族と一緒に遊ばずに267ページあたりを書きながら、意味不明な返事をする。それでも、家族はプロジェクトが終わるまで我々を支えてくれた。(P.xv)
○プロセスをより速い流れに最適化すると、リソースの稼働率は低下する。(P.27)
○抽象的な概念を教えるのに「コイン渡し」のようなゲームシミュレーションは優れている(P.28)
○スループットは、仕事を完了させる速度のことです。追跡するのは、こちらのほうが簡単です。(P.41)
●ソフトウェア開発における7つのムダ
未完成の作業のムダ、余分な機能のムダ、再学習のムダ、引き継ぎのムダ、遅れのムダ、タスク切り替えのムダ、欠陥のムダ(P.129-130)
○リーンソフトウェア開発における重要な原則のひとつに「最初から品質を作りこむ」というのがある(P.137)
○プランニングポーカーのスマートフォンアプリケーションもある(P.207)
○正確な期間の見積もりは、相対的な見積もりよりも難しい。(P.216)
○人がモノをつくるのだから、人をつくらねば仕事も始まらない。(P.218)
○繰り返しはすべての知識の源泉である。もういちど課題をやりなさい。(P.236)
●時間をかけているところを追跡しよう
(中略)
1日の終わりに、その日に(最も)時間を使った作業を付箋紙に書いて、ボードに張り付けるのだ。(P.269)
○コーチングのカタ、5つの質問。
1.目標とする状態は?
2.現在の状況は?
3.目標達成の障害物は何か?今一つだけ対処するとしたら?
4.次のステップ(次のPDCAや実験)は何か?何を期待するのか?
5.次のステップから学べるのはいつか?(P.236)
○チームとステークホルダーは、チームが獲得するポイントを追跡する方法を考えて、一定のポイントが貯まったら何をするか決めておく。たとえば、50ストーリーポイントもしくは20件の作業項目が完了したら、夜にオフィスでピザを注文してゲーム大会を開催するといったものだ。(P.276)
○リトルの法則(P.302)
投稿元:
レビューを見る
ソフトウェア開発における各タスクには着手してからリリースするまでの流れがあり、その流れがスムーズに流れるように気をつけていれば、うまくいくという発想。そのために、ボードを使って問題が起こってないか監視したり、 WIP の数を制限したりする。
読む前はカンバンボードは単に今取り組んでいるタスクを可視化して共有するためのものだと思っていたけど、実際はむしろ、一人で多くのタスクを抱えてしまったり、ボトルネックとなっているステップや長時間WIPのままになってしまっているタスクがないかといった問題を発見したり防止するためにある。
新しいタスクに着手する前に、途中になっているタスクを完了させることを優先するという発想も参考になる。
投稿元:
レビューを見る
全員のタスクを管理するためのカンバン
カンバンの使い方だけでなく、チーム内で協力するための方法(WIP制限)等も。
使い方はチームの状況に合わせていろいろ変えられる。
チーム内だけではなく、チーム同士を紐付けるためのツールにもなる。
一番重要なのは「終わらせることから始めよう」。
投稿元:
レビューを見る
フロー効率性とリソース効率性についての記事をきっかけに、カンバンに興味を持って読んだ。現場に導入するのは容易だが、最適な運用にたどり着くまでにはかなりの試行錯誤が必要そう。しかし理念や意図はとても共感できた。
投稿元:
レビューを見る
ポストイットなどカンバンを使って業務の見える化をしている人,また業務の見える化をどうやって進めようか悩んでいる人に絶賛お勧めの本.どういう考え方でカンバンを作るか? カンバンを使ってどのように業務を改善するか? メトリクス (活動状態の定量化) をどうするか? などが具体的に書かれており,非常に参考になる.
個人的に響いたのは「タスクを始めるより,終わらせる」 (WIP を増やさず,制限することで改善につなげる) ことと,ポストイットの正しいはがし方 :-).飛び込みの業務が入ると,つい,それに手をつけたくなるが,何が優先か? を冷静に考えながら仕事をしないと,いつまでたっても終わらないタスクが残り,精神的にもイマイチである.「始めるより,終わらせる」と呪文のように唱えながら仕事をしていこうと思う.