スクラムの原典を読み解く(1)：An Agile Way：オルタナティブ・ブログ
連載で、スクラムの元になった"The New New Product Development Game"を再び読み、そこから得られるアイディアと、現在のアジャイルにおけるスクラム、を対比させて解説しよう、という試みをはじめます！ 第一回目。 竹内弘高・野中郁次郎の論文「The New New Product Development Games」 (1986年)は、日本で行われている「新製品開発のプロセス」をNASA等の米国型のそれと比較して論じたものだ（図）。 この論文では、Type Aを米国NASAのPPP(Phased Program Planning)を例にとって、「各工程の専門家集団が、文書で次の工程の集団にバトンを渡すようにリレーをしている」と書いた。これに対して、Type Bの例として富士ゼロックスが、そしてType Cの例としてキヤノンとホンダが挙げられ、「ラグビーのようにボ
アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)
みなさんこんにちは。@ryuzeeです。 弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。 今日はよくある質問とその答えについていくつかご紹介したいと思います。 好評そうだったら続編も書く予定です。 ■アジャイル開発において、ドキュメント作成の一般的な指針を教えてくださいどのようなドキュメントがいつ、どの粒度で必要なのかはプロダクトやプロジェクトに依存します。 プロダクトやプロジェクトにはそれぞれ固有の品質基準があり、それはアジャイルやウォーターフォールといった方法論の違いによって変わるものでもありません。 したがってプロジェクト冒頭でプロダクトオーナーやステークホルダー（品質管理部門や顧客など）と「なんのために」「どのようなドキュメントが」「どのような記述レベルで」「いつまでに必要なのか」を決定してください。 誰も使う予定
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
Spotify Modelは"アジャイルの涅槃"ではない
Spotifyでは、マネジメントと組織の動きは人を育てることによってチームとアジャイルの実践を支援している。しかし、Spotifyは"アジャイルの涅槃"ではない。継続的に成長し、変化し、新しいチームに分裂するような高い成果を産むチームに達するのは難しい。Spotifyのチームとリーダーシップのコーチを務めるJoakim Sundén氏は、ビジョンを持ち続け、小さなステップを刻みながら向かうことを推奨している。 Sundén氏はSpotifyでのスムーズに進まなかった問題やどのようにその問題を解決しようとしたのかについてLean Agile Scotland 2017で語った。InfoQはこのカンファレンスの模様をインタビューや記事で取り上げている。 InfoQはSundén氏にインタビューし、うまくいかなかったことが製品にどのような影響を与えたのか、Spotifyでエンジニアリングマネージ
アジャイルFAQ | ワイクル株式会社
コンサルや研修しているときに聞かれた質疑応答の一覧です。ひとまず2017年にいただいたものをまとめました。 Q. 1人でスクラムを始めたいと思いますができますか？ 「スクラム」はできないですが、スクラムのなかの特定の手法は可能です。たとえば、バックログを作って上から順番にやっていくとか、定期的にふりかえるとか。 Q. 遠隔チームでのスクラムはデジタルツールを使えば可能？ 「最初のうちは同じ場所で、慣れてきたら離れて」が基本 チームの成熟度次第なので、最初からうまくできるチームもあります Q. チームの相乗効果を上げるにはどうすれば？ チームの数だけやり方がある。 チームだけの文化や言語を作っていくことが重要かも。「一緒にご飯を食べる」というのは鉄板です。 『Team Geek』オススメです！！！！！（宣伝） Q. 開発チームがステークホルダーに直接アクセスするのはNG？ あとでPOに情報共
「総務」×「アジャイル」=「可能性は∞」
総務におけるアジャイルの取り組み事例です。 2017/9/15 総務で見える化カイゼンMeetup! https://connpass.com/event/63738/
アジャイルコーチに都合のいいスクラム
By: Phil_Heck コーチを仕事にしている人と話す機会があると、必ず「で、あなたのコミットメントは何なんですか？」と聞いています。人によっていろいろ意見はあるんですが、今ひとつ納得感がない。なんでそう思ってしまうのかをふと考えました。 ティーチングとコーチング ティーチング、コーチングはそれぞれ違います。僕は専門家ではないのでざっくりした書き方になりますが・・・ ティーチングは指導です。知識や経験の少ない人に、基本やノウハウを教えること。答えを教えるので、新しい知識や技術が習得できます。 コーチングは導くコミュニケーション技法です。答えを見つけさせるため、意欲やポテンシャルを引き出していきます。 これだけで考えれば、ティーチングで知識を対象者に与え、対象者がそれを実践するのを支援していくのがコーチングです。 アジャイル開発でのティーチング アジャイルコーチやコンサルは、知識を持って
アジャイルコーチって何するの？
みなさんこんにちは。@ryuzeeです。 InfoQに“アジャイルコーチ” とは何か という記事があったので、アジャイルコーチとして活動している僕が普段どんなことをやっているのか説明したいと思います。 オンラインでのコミュニケーションTwitterやFacebook、そしてこのサイトからアジャイルに取り組んでいる方や、これから取り組みをはじめようとする方からよくご質問を頂きます。 コーチとしては、実践する上でどういうことに困っているかを色々と知ることができるので大変ありがたいです。 特に金銭のやりとりはありませんが、コーチとして責任をもった回答をする必要があると思っているので、文献や海外のサイトや海外の著名トレーナーの資料などを参照しつつ自分の見解も交えて回答させて頂いているつもりです。 質問は回答をうける側よりも、回答する側のトレーニングになると思っています。 質問頂いた内容は、一般化し
アジャイルコーチによるアジャイル開発の成果と効果測定とは？
自分のチームをマネジメント＆コーチングしていて、ふと「自分の成果はどうやって表現したらいいだろう？」と考えました。 そのつぶやきに答えてくださった、尊敬するアジャイルコーチの方々の意見をまとめてみました。
"総務も！！"アジャイルプラクティス！
「XP祭り 2015」でのLTスライド。 総務でやっているアジャイルプラクティスを簡単に紹介したものです。
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog
最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得
【資料公開】アジャイル開発プロジェクトの始め方
みなさんこんにちは。@ryuzeeです。 これからアジャイル開発を始めるときには、気をつけておいた方がよいことや、実際にスクラムでスプリントを回す前にやっておいた方がよいことが色々あります。 それについて使っている資料がありますので参考までに公開しておきます。 これもやった方がいい、こういう時にはどうするの？などありましたら是非[Twitter](https://twitter.com/ryuzee)などでお知らせいただければと思います。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2020-05-20単行本（ソフトカバー）：288ページISBN-13：9784798163680ASIN：4798163686
アジャイル・メトリクスと、モダン・アジャイルと、Agile Japan 2017と - The HIRO Says
行ってきたぜ船堀！2017年4月13日（木）にタワーホール船堀で開催された、Agile Japan 2017に参加してきました。 今回の私の立場は、ワークショップの講師。『メトリクスによる「見える化」のススメ：No 見える化、No 改善』というタイトルで、アジャイル・メトリクスをみんなで創るワークショップを開催してきました。 今回は特に、私のワークショップと、モダン・アジャイルにまつわるお話をさせていただきます。 １．アジャイル・メトリクスのワークショップ 参考資料 （１）今回のワークショップの資料 メトリクスによる「見える化」のススメ:No 見える化、No 改善 （２）アジャイル・メトリクスについて最初に明示的に紹介した資料 メトリクスによる「見える化」のススメ: エッセンシャル・リーン （３）アジャイル・メトリクスについて踏み込んで勉強するための資料 世界と事例から学ぶ、プロダクトオー
アジャイル開発を導入して1年以上経ちました — みんなのウェディングエンジニアリングブログ
みんなのウェディング、松久（@kamonegi1977）です。 みんなのウェディングでは、アジャイル開発を導入して1年以上が経ちました。現在、どんな組織・チームでサービス開発をすすめているのかを説明します。 なぜ？アジャイル開発を導入したのか アジャイル開発を導入する前は、以下のような流れで開発が行われていました。 マーケティングから企画がまとめられて、開発依頼が出される 開発担当がアサインされ、デザイナー、エンジニアが決まる Excel などで仕様書（画面構成）があり、リリース日が決まっている リリースすると開発終了。次の開発へ（1に戻る） この流れは、エンジニアが1つの開発に集中できるメリットがあります。 一方でリリース日が重視されるため、機能や品質が犠牲となることがありました。リリースを終えると次の開発に入ることが多く、リリースした新機能や変更を改善することが難しい状態でした。チーム
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔
プロジェクトファシリテーション実践編：ふりかえりガイド
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか？ 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを１００％以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション（PF）」です。 プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
当たり前を当たり前に：Agile2017レポート
50分でふりかえるアジャイルムーブメントの歴史 2017年版
Project Facilitation
