Infrastructure as Codeと組織構造
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
アジャイルメトリクス実践ガイド
9. （例）DevOpsのメトリクス 9 開発・CI QA デプロイ リリース 運用 開発の リード・タイム 非稼働時間 デプロイの リード・タイム リリース頻度 MTTR 欠陥・ビルド失敗・シス テムダウンに 伴う再作業 検出・見逃した欠陥の 割合、および 欠陥の影響度合い デプロイ頻度と かかる時間 リリース毎の 時間とコストの割合 システムダウン時の コストと頻度の割合 非稼働時間 MTTD (検知にかかる時間) （システム）変更の 成功率 （リリース成功の） 予測可能性 営業時間後の 緊急呼び出しの頻度 進行中の作業と 技術負債 MTTR 性能と利用時間の 割合 サイクル・タイム Wallgren Anders, Measuring DevOps: the Key Metrics that Matter, Agile2016 10. （例）DevOpsのメトリクス 10 開発・CI
【資料公開】スクラムの落とし穴 #RSGT2017
みなさんこんにちは。@ryuzeeです。 2017年1月12日〜13日にかけてスクラムのイベントであるRegional Scrum Gathering Tokyo 2017が開催されました。 その中でスクラムでよく起こる問題やその原因・対策に関するセッションを行いましたので資料を公開いたします。 アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。内容に関するご質問やご要望がありましたら是非Twitterなどで気軽にお寄せください。 それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2020-05-2
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
Agile Japan 2015 サテライト＜沖縄＞ に参加 / 発表してきました - Thanks Driven Life
Agile Japan 2015 サテライト＜沖縄＞ - Java Küche | Doorkeeper 発表した話は後ろで書きます。 セッション 基調講演 1, 2 2日前に行なわれた 本会場 での基調講演の録画動画を見ました。 Janet さんの「アジャイル・テスティング」というタイトルからしてテスト技法みたいなイメージがあったけど、 どちらかというと「テストを通してチーム/メンバー間でのコミュニケーションをどうすべきか」みたいな話題でした。 特にテストのタイミングになると「質問」というフェーズから様々な情報の共有が行われるので そこでしっかりしていこう、みたいな話だったと思います。多分。なるほどなー。 横塚さんは、正直なところ発表を見る前は 「東京海上日動システムズ株式会社 顧問」 って肩書だし、すごい堅い上に「なんちゃってアジャイル」について語るのでは みたいなイメージだったのです
継続的デリバリー vs 継続的デプロイ
みなさんこんにちは。@ryuzeeです。 Jez Humble氏のContinuous Delivery vs Continuous Deploymentが分かりやすいので抜粋・意訳にてご紹介します。 (翻訳部分はCC-BY−SAとします) ティモシー・フィッツの継続的デプロイに関するブログは、デイブと私が継続的デリバリーについての本を出版する1年以上も前に、すでに書かれていた。そんな中でなぜ私たちは異なる名前を選んだのだろうか。実際に違いはあるのだろうか？それとも単に我々が不親切なだけなのだろうか？ 我々はいくつかの理由で本の名前を「継続的デリバリー」とすることにした。まず第一に、デプロイがリリースを意味しないというちょっと学者ぶった事実。我々が本の中で言っているように、継続的に顧客受け入れ環境にデプロイすることはできるだろう。それ自体はたいしたことはない。継続的デプロイを特別なものにす
スクラムによるWebアプリケーション開発コース、enPiT PBL (Project Based Learning) 最終週 - 未来のいつか/hyoshiokの日記
10/4より行っていた、スクラムによるWebアプリケーション開発コースが修了した。 enPiT スクラムによるWebアプリケーション開発コース - 未来のいつか/hyoshiokの日記 スクラムによるWebアプリケーション開発コース 楽天株式会社が提供する各種サービスのAPI（Application Program Interface）を利用して、ビジネス展開も可能なオリジナルWebアプリケーションを作成していきます。作成中のアプリケーションは一般に公開し、ユーザーの意見を集めます。ユーザーからのフィードバックサイクルを回しながら、アプリケーションを育てるために、近年脚光を浴びているアジャイル開発手法の一つであるスクラムによるプロジェクトマネジメントを行います。複数のPBLチームの編成が可能です。 ★ 指導教員：永瀬美穂 特任准教授、吉岡弘隆 客員教授（楽天株式会社 技術理事） enPiT
Microsoft Word - n2jk.doc
73 A New Business Model of Custom Software Development for Agile Software Development Yoshihito Kuranuki SonicGarden 6F, 1-3-4 Jinnan, Shibuya-ku Tokyo, 150-0041, Japan kuranuki@sonicgarden.jp Tsuyoshi Ushio SimpleArchitect Japan ushio@simplearchitect.com Tsutomu Yasui Eiwa System Management Ueno HS Building 8F, 2-7-7, Ueno, Taito-ku, Tokyo 110-0005, Japan tsutomu.yasui@gmail.com Susumu Yamazaki U
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万以上の決済が行われている。また、そのプロダクトは「
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
もっと気軽にアジャイルを学べるようにしたい。「アジャイルチームを支える会」を設立表明、一般社団法人として
発起人は西村直人氏と市谷聡啓氏。両者はこれまで書籍「アジャイルサムライ」「リーン開発の現場」「Scrum Boot Camp The Book」などの翻訳や執筆に関わり、またイベント「Agile Samurai Base Camp」の開催などを通してアジャイル開発の普及を推進してきました。 その活動の延長として、もっと世の中にアジャイルチームを増やしたいという両者の思いが今回の社団法人設立の背景にあります。「僕たちの回りを見てもと、ぶっちゃけ、アジャイルをバリバリやってるチームって見ないですよね」（西村氏）。 活動を継続できる仕組みを持ちたかった 「なんで社団法人かというと、活動を継続できる仕組みを持ちたかった」（市谷氏）。社団法人は法人格として契約も結べ、たとえばセミナーの講師などに報酬が出せるなどの利点をあげて、「会社にもコミュニティーにもそれぞれの難しさがあるので、別の手段として社団
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】カンバンのキホン
Overview