大規模アジャイルフレームワークの紹介
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
Mob Programming Startup Manual #MobProgramming #モブプロ
現場でモブプログラミングを始める時、ワークショップをする時の説明に使えるように作成しました。 許諾は必要ありませんのでご自由にお使い下さい！！ （使用した時にTweetしてくれると勝手に喜びます） Updated at 2018/9/3
一括契約でアジャイルなんてとんでもない？ - novtanの日常
takigawa401.hatenablog.com この話のキモは「請負で」じゃなくて「一括で」ということだと思うのだけど、法的な請負契約のことを一括請負と言ったり単に請負と言ったりするだけで区別はないと思うんだけど、客のニュアンスとしては「完成まで全部１つの契約で」ってことだと思うんだよね。 そういう意味では、アジャイルを請負でやる、というだけであればどういう単位で契約するか、何を成果物に契約するか、細切れになって手続きの負荷は妥当な範囲か、あたりの問題をクリアできれば不可能ではないんだけどね。 ただ、本質的に請負とアジャイルというのは親和性がない。なぜなら、請負契約が責任を持つのはアウトプットだけなんだから、やり方に顧客が口をはさむなんてとんでもないわけです。当然途中で成果物の範囲が変わることもありえない。なので、１～２週間毎に毎回成果物を明確にして契約を取り交わす、なんてのが現実で
Microsoft Corporation
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
しょぼちむ！スクラムチームの外側の話をちょっと書いてみたよ！ - Mitsuyuki.Shiiba
しょぼちむ Advent Calendar 2014 - Adventar の22日目のエントリーです。 チーム開発の話でもしようかと。せとさんが「まぁいいんじゃね？」って、テストファーストの話書いてるし、いいよね。 しょぼちむにテストファーストについて説明してみる - ふぃーるどのーつ Role 社内開発前提で考えてみます。 開発チーム ビジネス側と開発側で向き合ってるとこんな感じ？ でも、これだとビジネスと開発の距離がありすぎるね。 Producer ってことで開発リードをチームから剥がして、真ん中に立たせてみよう。 んで、Producerというロールにしよう。 おし。これでビジネス側との距離が縮まった。 んでも、開発チームとの距離が遠くなっちゃったな。 ってか、このロール、仕事多くね？ DevLead ってことで、やっぱり開発チーム側にリード立てよう。 これでチームのリードはプロデュ
資料公開しました - POStudy Day 2014 Autumn in Tokyo ～プロダクトオーナーシップを磨くための一日～ #postudy - 2014/11/30(日)
資料公開しました - POStudy Day 2014 Autumn in Tokyo ～プロダクトオーナーシップを磨くための一日～ #postudy - 2014/11/30(日) 2014/11/30(日)10:00-19:00に開催した 『POStudy Day 2014 Autumn in Tokyo ～プロダクトオーナーシップを磨くための一日～』 の資料を公開しました。 当日は日曜日で有料にもかかわらず 69名 もの方にお越しいただき、大盛況でした。 今回のイベントを開催するにあたり、11名もの当日スタッフの方々に多大なご協力をいただきました。彼ら彼女らがいなければ開催できませんでした。本当にありがとうございます！ 当日のツイートはtogetterでまとめてあります。 2014/11/30(日) POStudy Day 2014 Autumn in Tokyo #postudy
「お前らのアジャイルは間違っている」と彼は言った
少し前にマネージャ層にアジャイル開発事例を話す機会がありました。皆さん「アジャイル」という言葉に抵抗があるようです。さてさてどうやって伝えたらいいものか。発表資料を作りながら悩んだことをここに書いておこうを思います。 アジャイルを語ると胡散臭い 前にもちょっと書いたんですが、アジャイル開発を話す人は胡散臭いです。 たとえば、アジャイルサムライの著者をお呼びしてトレーニングをしたときに思ったんですが、本のファン以外の人にトレーニングの価値を伝えにくかった感触がありました。おそらく「有識者」と名乗る見ず知らずの人（しかも外国人）の話を「信じてください」には無理があるんでしょう。 そのほかにも、別の誰かの話をしだす人は胡散臭いです（海外では〜、○○社では〜、書籍には〜）。これはリーンソフトウェア開発の提唱者メアリー・ポッペンディークさんの本が顕著です。すぐに3Mの話をしだすし具体的な要素が少ない
アジャイル開発に関係ありそうな日本語資料ベスト50
1位もリーンスタートアップネタ。わずか10枚の資料が1位ってのが熱い。 6位から50位まで こうやってみるといろいろあって面白いですねぇ。スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!は自分の環境にあわせた感が素敵だし、AgileJapan2010 佐賀県庁でもできる！プロジェクトファシリテーションは、何回みても面白い熱い物語だし、「納品のない受託開発」にみるソフトウェア受託開発の未来は講演を2〜3回見ているけど、何回聞いても面白かった。 33729viewsUXのためのUIデザイン 31199viewsふつうの受託開発チームのつくりかた 28019viewsAgileJapan2010 基調講演：野中郁次郎先生による「実践知のリーダシップ～スクラムと知の場作り」 27941viewsProject Facilitation From Hiranabe
プロダクトオーナーを見つけてみよう!! #scrumbcbook - ヲトナ.backtrace
最近、再びあちこちの会社さんに遊びにいかせていただく機会が多くありました。 ＃ あちこち遊びにいきたいので呼んでいただけるところを随時募集してますのでお気軽に!! そこでいろいろと話していると、拙著「Scrum Boot Camp The Book」の感想や質問をもらえたりして、嬉しいなーと実感してたりしますww けれど、そのなかで「スクラムチームからプロダクトオーナーを話しあって選ぶのは良いと思うのですが、やっぱり誰が適任か判断するのが難しい」と何回か聞かれました。 そこで本を読んでくれた人向けにプロダクトオーナーを見つけるためのちょっとしたアクティビティを考えてみました。 名づけて「プロダクトオーナーは誰だ!?エクササイズ」です。 以下のような紙に書かれた質問にこれからスクラムチームになるプロジェクト関係者が答えていって、プロダクトオーナーを決めていきます。 これらの質問は、僕が仕事で
self-organization in hanoi traffic
hanoi, vietnam, 24feb2009. this is a nice example of self-organization as described by complexity theory. there are no fixed "top-down" laws (i.e. traffic lights), and yet the incredible traffic flows continuously. in complexity terms, the collective motion emerges from the multiple local interactions between the "agents" (drivers and pedestrians), mediated by horn sounds, eye contact, body ges
世界よ、これが日本のSCRUMだ #sgt2013 http://twitter.yfrog.com/odqsqhgcj
Introducing the new yfrog social network designed for people, not advertisers.
SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Players
元ド底辺SIerの私が心機一転、スタートアップに参加して約1年半が立ちました。 今後の自分の仕事を占う意味でも、ここらで自分がこれまでに感じたこと、悩んだこと、考えたことを整理しておこうかと思います。 もしも現在、SIer系の仕事をされていて、いずれはベンチャーで働いてみたいという人の参考になればもちろん嬉しいのだけど、ベンチャーってのは本当に千差万別で、ここで書いたことがそのまま他のベンチャー企業に当てはまるとは限らない、ということだけはご了承を。 「仕様」って言うな！ 最初の問題はこれ。 SIerにとって「仕様」って言葉は絶対的な意味があるわけですよ。 お客様から要求を聞いて、要件を定義して、「はい、コレコレこういうもの作りますよ。この製品ではこういうことができます。逆にこういうことはできません。よろしいですか？」と約束した結果が仕様だから当然と言えば当然。だからこそ、仕様を定めること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
150社以上・3000人以上のエンジニア・マネージャが受講したアジャイル研修を動画公開 #アジャイル開発の基礎知識 | Agile Studio
【事前公開版】アジャイルカルチャーが組織に根付くまでの挑戦 // Speaker Deck
Overview
Scaled Agile Framework – SAFe for Lean Software and System Engineering
Scrum Boot Camp in NII
かんばん！～もし女子高生がRedmineで「スクラム」開発をしたら
一目で分かるスクラムマスター(A Quick Overview of the ScrumMaster) - The HIRO Says
クライアントの要望にこたえるWebサービス開発 ～「らせん型ワークフロー」のススメ～
