XP祭り2018 SESSION-A-3-2 NTTの川淵がトークしたプレゼン資料です。 「未来を変える権利は、皆平等にあるんだぜ」 http://xpjug.com/xp2018-session-a-3-2/ Read less

って最初に言ったんですけど任されてしまいましたね。 リーダーを任されて数ヶ月、いろいろ考えた話。 そもそもチームリーダーはいないはずでは? スクラム開発にいるのはプロダクトオーナーと、スクラムマスター、チームメンバー。 スクラム開発にはチームリーダーはいない。 が、スクラムやってるはずのうちの会社、なぜかチームリーダーがいる。 リーダーの仕事はスクラムマスターの領域が近いけれど、実際の作業もやっているのでチームメンバーでもあるかんじ。バックログはチームで出している。POは誰だかよくわかんない。 なので実際、リーダーはただのスーパーマン。 要件からバックログのタスクにする。調整して、みんながタスクに集中できる環境をつくってあげられる。コード書いてタスクを燃やせる。なんでもできる。リーダーすごいよ。スクラムの全役ひとりでやってるのでは? というわけでうちのチームリーダーはなんかすごい。 模索、
ユニークなコンセプト #ScrumMasterWayはユニークなコンセプトです。アジャイルとスクラムの第一線に立つエキスパートであるZuzana 'Zuzi' Šochováが提唱しているもので、スクラムで卓越した成果を収める方法、グレートスクラムマスターになるための方法です。15年以上に渡るアジャイルとスクラムの経験、そしてグレートスクラムマスターになるための彼女なりのやり方もカバーしています。 #ScrumMasterWayのコンセプトは、優秀なチームや組織を作ったり、アジャイルな環境における変化に対応したり、非常に強力なスクラムマスターの道具箱を活用したりするのに役立ちます。 #ScrumMasterWayのコア要素 このコンセプトはスクラムの長所に焦点を当てています。メタスキル、学習、心理、 リーダーシップが4つの要素です。
今年から会社の方針も変わり、エバンジェリストからSoftware Development Engineer という職種に変わった。プレゼンとデモの世界から、お客様と一緒にハックしたりコードで世の中にインパクトを出す仕事に変わったので、楽しくも四苦八苦しながら頑張っている。 先日友人の Rochelle Kopp さんから Agile のビデオを作ってくれないか?という依頼があった。今から Agile を始めたいと思っている企業さんが増えてきたのだが、残念ながら私はコードを書くのが`今の仕事なので、エバンジェリストやコンサルをやっているときのように対応できない。出来るとしたら、自分が新技術導入 (Serverless, Microservices等)をご支援しているプロジェクトに限られる。 だから、彼女がビデオを作ってくれたらうれしいといったので、既存の資料を少しカスタマイズして、ビデオをい
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン(ソフトウェア)開発とは何か? 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発~アジャイル開発を実践する22の方法~ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感:結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
9. (例)DevOpsのメトリクス 9 開発・CI QA デプロイ リリース 運用 開発の リード・タイム 非稼働時間 デプロイの リード・タイム リリース頻度 MTTR 欠陥・ビルド失敗・シス テムダウンに 伴う再作業 検出・見逃した欠陥の 割合、および 欠陥の影響度合い デプロイ頻度と かかる時間 リリース毎の 時間とコストの割合 システムダウン時の コストと頻度の割合 非稼働時間 MTTD (検知にかかる時間) (システム)変更の 成功率 (リリース成功の) 予測可能性 営業時間後の 緊急呼び出しの頻度 進行中の作業と 技術負債 MTTR 性能と利用時間の 割合 サイクル・タイム Wallgren Anders, Measuring DevOps: the Key Metrics that Matter, Agile2016 10. (例)DevOpsのメトリクス 10 開発・CI
Tidy First? ―個人で実践する経験主義的ソフトウェア設計著者/訳者:Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ出版社:オライリー・ジャパン発売日:2024-12-25単行本(ソフトカバー):164ページISBN-13:9784814400911ASIN:4814400918 脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック著者/訳者:Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin出版社:オライリー・ジャパン発売日:2024-06-18単行本(ソフトカバー):312ページISBN-13:9784814400799ASIN:4814400799
こんにちは、斎藤です。 「スクラムガイドを読む」の第2回目です。 「スクラムガイドを読む(第1回)」はこちらです。 第2回目は、スクラムガイドの下記の内容に関して書いていきます。 スクラムイベント スプリント スプリント計画ミーティング デイリースクラム スプリントレビュー スプリントレトロスペクティブ スクラムの成果物 プロダクトバックログ スプリントバックログ インクリメント 「完了」の定義 結論 スクラムイベント スクラムでは、イベントを設けて規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化している。イベントには、時間に上限のあるタイムボックスを使う。これは、計画プロセスで時間を無駄にせず、必要な分だけ時間を使うようにするためである。 スプリント以外のすべてのスクラムイベントは、何かを検査・適応する公式の機会である(スプリントはその他のイベントの入れ物である)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 伝統的な品質保証(QA)からアジャイル品質(AQ)へと変わっていこう 2016/9/30、Hillside Group(後述)の代表Joseph Yoderさんが来日され、鷲崎先生と特別セミナーが開催されたとのこと。 そこで紹介された、**「QA to AQ: 品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ」**というパターンが秀逸で、かつ、日本のアジャイルオーディエンスに興味がある方が多いであろう、と思い、紹介します。 アジャイル開発は徐々に日本の開発現場にも浸透しています。特に、We
11. カンファレンス分析 (1) 11 ジャンル セッション数 ジャンル セッション数 Agile Bootcamp 9 Leadership 23 Audacious Salon 14 Learning 19 Coaching & Mentoring 20 Lightning Talks 3 Collaboration Culture & Teams 25 Open Jam 5 Development Practices & Craftsmanship 19 Project Program and Portfolio Management 21 DevOps 18 Stalwarts 6 Enterprise Agile 27 Testing & Quality 12 Experience Reports 23 The Future of Agile Software Developm
VersionOne 社が毎年出している "State Of Agile" レポートが今年で 10 年目だそうです。 簡単に内容を紹介します。ちなみに、この調査は基本的にアジャイル実践者が回答していることが多いこと、またアジャイルツールのベンダーの調査ですので、母集団や見せ方には多少のバイアスはあります。また、データの解釈については、私の私見も入っていますので、注意してください。 母集団とAgileの成長について 回答母数は3,880。===> 10年前(2006)の3倍。 回答者が属するソフトウェア開発組織として100名以上の会社が2/3、1,000名以上が1/3。 ===> 10年前は100名以下が2/3。 組織のアジャイル採用率95%。1/3以上が採用始めてから5年以上。 回答者は北米56%, 欧州26%, アジア11%, 南米6%, オセアニア2%, アフリカ1% 以下のレポートで
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです(資料の後半に細かいメモ書きがあります)。 そもそもウォータフォールは必要なのか? とはいえ、ウォータフォールを採用しなくてはならない状況は? なぜ、アジャイルを採用できないのか? チームは重要だけど、どういうメンバーがいいのか? アジャイルとはいえPM的な人が必要になることってあるよね? アジャイルの立ち上げってどうするのがいいの? 偶然、牛尾さんの 私は間違
先ごろ出版された「リーン開発の現場:カンバンによる大規模プロジェクトの運営」(ヘンリック・クニバーグ著/オーム社/2013年10月)は、アジャイル開発手法を実践事例の視点から解説した力作である。スクラム、カンバン、XPなどの手法に言及しているが、中でも「リーン開発」を正面から取り上げているのが大きな特徴となっている。 本書ではリーン開発現場の写真、会話をふんだんに使って事例解説がなされていたり、まさに現場でプロジェクトに立ち向かっているマネージャ、エンジニアたちによって訳されていたりと、実に臨場感あふれる仕上がりとなっている。ちなみに著者のヘンリック・クニバーグ氏は私の長年の友人であり、本書、日本語訳巻末の解説も私が担当した(詳細はこちらで紹介している/参考リンク:「リーン開発の現場」紹介ページ)。 ただ「リーン」という言葉は、米国で注目を集めた経営書「リーンスタートアップ」で広く知られる
開発者がチームをリードするポジションに昇進する場合、新たなスキルセットが必要だ。Talking with Tech Leadsの著者によればPatrick Kua氏によれば、技術的リーダーは共通の技術的なビジョンに向けてチームを動かすため、権限を委譲し、ファシリテーション、コミュニケーションをし、リスクを管理しなければならない。 Patrick Kua氏はOOP 2015カンファレンスでThe Geek‘s Guide to Leading Teamsと題した講演を行う予定だ。カンファレンスの模様はInfoQでも取り上げる。 InfoQは氏にインタビューを行い、技術的リーダーの必要性、スクラムマスタと技術的リードの役割の違い、リーダーシップのスキル、能力やスキルを磨くのを支援するために技術的リーダーがするべきことについて話を聞いた。 InfoQ: なぜ技術的リーダーが必要なのでしょうか。
1位もリーンスタートアップネタ。わずか10枚の資料が1位ってのが熱い。 6位から50位まで こうやってみるといろいろあって面白いですねぇ。スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!は自分の環境にあわせた感が素敵だし、AgileJapan2010 佐賀県庁でもできる!プロジェクトファシリテーションは、何回みても面白い熱い物語だし、「納品のない受託開発」にみるソフトウェア受託開発の未来は講演を2〜3回見ているけど、何回聞いても面白かった。 33729viewsUXのためのUIデザイン 31199viewsふつうの受託開発チームのつくりかた 28019viewsAgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」 27941viewsProject Facilitation From Hiranabe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く