かんばん方式を実践する
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 つのツールとして、スク
大組織の中でのリーン
2012/12/17 ヤフー株式会社にて行われた「Running Lean」出版記念セミナーでのヤフーセッション発表資料。補足改定版。Read less
ソニックガーデン流 無駄のないシステム開発
2012/12/6 Cloudforce Japan2012にてお話をさせて頂いたスライドです。Read less
Jasst12九州 倉貫資料：アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
アジャイルとRuby、そしてクラウドを活用することで、新しいビジネスモデル「納品のない受託開発」を、私たちの会社ソニックガーデンでは実現しました。このビジネスモデルは「サービス型の受託開発」として、IT業界の多くの課題を解決するとして、日経コンピュータをはじめ多くのメディアで取り上げられるなど注目を集めています。 その開発現場において、どのような開発スタイルを実現しているのか、そこでの開発環境やテストの実践のノウハウについて、実際の現場の様子や担当者の声を交えながら紹介します。また、ここで紹介する開発スタイルが成立するのは、いったい何故なのか、開発ビジネスに対するパラダイムシフトまでお話します。 【講師プロフィール】 株式会社ソニックガーデン 代表取締役 1974年京都生まれ。1999年立命館大学大学院を卒業し、TIS（旧 東洋情報システム）に入社。2003年に同社の基盤技術センターの立ち
『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。：An Agile Way：オルタナティブ・ブログ
わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。 最後に書いた、 多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか｢人は交換可能である｣というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品
スクラムの先へ進む
アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう？ スクラムだけで十分なのだろうか？ Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する
「納品のない受託開発」にみるソフトウェア受託開発の未来〜PMシンポジウム2012の講演資料と質疑応答 | Social Change!
9月6日7日で開催されたPMシンポジウム2012にて、講演させて頂きました。 なんと2時間半という長い時間を頂いての講演でした。講演の内容は、私の定番の話なのですが、普段はあえて詰めこむ感じで早口で喋るというスタイルをとっているのですが、今回はじっくりとお話させて頂きました。 私自身の自己紹介と共に、ソフトウェア開発ビジネスの世界の問題点をお話したあと、私の取り組んできた考えの変遷をお伝えし、今わたしたちがやっている「納品のない受託開発」というビジネスモデルについてお話をしました。 一旦そこで質疑応答に入り、質疑応答の後、そこから未来に向けての話をして終わるという流れです。 講演資料を以下から見えるようにしておきます。 頂いた講演時間が長かったため、普段と少し流れを変えて、プレゼンの途中で質疑応答をたっぷりと行いました。 その質疑応答の様子を、iPhoneのボイスメモで録ってはいたのですが
Agile2012の参加レポート - オブログ
市谷です。 8月13日から17日までテキサス州ダラスで開催されていたAgile2012に参加してきました。Agile2012は世界中からAgile開発の関係者が集まる、Agileにおける重要なカンファレンスの1つです。セッションの数は200以上。Agile界隈でリーダーシップを取っている著名な方々が一堂に会する貴重な場でもあります。永和システムマネジメントからは、今年は安井力、西村直人、市谷聡啓の3人が参加しました。 私が参加したセッションのうち、3つのレポートを以下にあげています。 Leanがビジネス価値を駆動する 参加セッション: Scaling Agile with Multiple Teams: Using Lean to Drive Business Value スピーカー: Alan Shalloway へんりっくのかんがえたさいきょうのかんばん 参加セッション: Lean f
[8/14] Leanがビジネス価値を駆動する – Agile2012 現地レポート(15) – manaslink
[8/14] Leanがビジネス価値を駆動する – Agile2012 現地レポート(15)Published by きいろいの on 2012年8月15日2012年8月15日 規模の大きさに向かうために、チームをどのように組織するか。 このテーマで思い浮かべるのは、Scrum of Scrumだろう。Alanの今回のセッションは、Scrumのアプローチとは異なる、複数チームの組織化の紹介であった。大規模なエンタープライズ／サービス開発において参考になるところがあるかもしれない。 ■全体は部分に制約される まずはベースとなる考え方、バリューストリームが示される。 Alan Shalloway『Business Driven Software Development』6スライドめより そもそもバリューストリームの定義として、ビジネス価値を発見するフェーズと、それをデリバリするフェーズに分けて
![[8/14] Leanがビジネス価値を駆動する – Agile2012 現地レポート(15) – manaslink](https://cdn-ak-scissors.b.st-hatena.com/image/square/1108f8167054eeff0ed71052b30e9ae8f1c7f55c/height=288;version=1;width=512/https%3A%2F%2Fwww.manaslink.com%2Fwp-content%2Fuploads%2F2012%2F08%2Fslide0_214-175.jpg)
カンバンを導入する正しい理由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. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012
DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 DevOpsに関する国内最大のイベントとなった「DevOps Days Tokyo 2012」が5月26日に都内で開催されました。 前の記事「DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012」では、John Wills氏の講演を紹介しました。この記事では、企業の中でDevOpsを通してビジネスを改善するために欠かせないメトリクスについて解説した、Damon Edwards氏の講演のハイライトを紹介します。 DevOps Business Justification and Metrics DTO Solutionsの共同創業者、Damon Edwards氏。 普段はインフラについてのコンサルティングなどをしている。eコマース、金融、オンラインゲーム
アジャイルに対するマネジメントの見方
Steve Denning氏はForbesでの連載記事でアジャイルコミュニティが主流のマネジメントに受け入れられるために直面する困難について書いている。 連載の第一回目の記事で氏はアジャイルはマネジメントの秘密の奥義だと主張している。過去数世紀の間にも、既存の考え方に対立する大胆な新しいアイディアが、門外漢からもたらされたことで無視されるということが何度もあった。 ...ちょうど10年前、マネジメント手法にブレークスルーが起きました。このブレークスルーによってソフトウエア開発チームは規律ある作業の実施と継続的イノベーションを両立させることができるようになりました。これは従来のマネジメント手法では達成できないことです。しかし残念ながらこのブレークスルーを起こしたのは“正しい人々”、つまり、ビジネススクールの研究者や大企業の高給取りのマネージャーではありませんでした。最もマネジメントの問題を解
オン・ザ・けものみち — 【Agile Japan 再演】アジャイルな開発からアジャイルな組織へ に参加しました
【Agile Japan 再演】アジャイルな開発からアジャイルな組織へ に参加しました アジャイルジャパン2012で大盛況だったとの噂の「アジャイルな開発からアジャイルな組織へ」の再演に参加しました。 告知ページ 公演の内容は Togetter 及び Slideshare などを確認していただければ雰囲気を感じていただけるかと思います。 公演内容は、時に痛快で、時に気づきがあり、時にいいパンチをもらうような楽しい公演でした。 印象に残っているところを 変化に対応しないといけない ビジネスを取り巻く環境が変わっている 不安定な場所をものすごいスピード競争している 意思決定を早くする必要がある。 考えてても偉くない やったほうが偉い ビジネスモデルの賞味期限が短くなっている 改善するかしないかが肝心である。 Scrumなどの方法論は無駄をなくそうという話！ 価値を高めないものはすべてムダ！ 求
IA meets Lean/Agile UX ～リーン／アジャイルな201x年型Web制作スタイルの可能性～ @OpenCU 2012.4.12
TABILABO×OpenCU これからの“旅”を再定義しよう 自分の“旅”をデザインしよう@2014.7.16 OpenCU 7年前 232 視聴者数
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
意思決定の正しいタイミング
リーンやアジャイルの契約書の書き方
https://www.featureteamprimer.org/ja/feature_team_primer_ja.pdf