カテゴリー別アーカイブ: Uncategorized

ああ、投稿の間が空いているというのに、宣伝とは・・・orz

突然の告知ですが、この度「エンタープライズ・アジャイル実践入門」という、なんとも身の程知らずなタイトルの書籍を上梓いたしました。宣伝URLはこちら(http://book.impress.co.jp/books/1115170060)。なぜここで告知しているかというと、サブタイトルが「HPE Agile Managerではじめるディシプリンド・アジャイル・デリバリー」だからです!1115170060-170x

WebサイトThinkITさんで連載していたツール解説記事に加筆修正・・・とは名ばかりのほとんど書き直しに近いモノです。

私は現在ヒューレット・パッカードに勤務しており、会社としてはSAFe(Scaled Agile Framework)推しだし、このAgile ManagerというツールもSAFe推しなのですが、そんなこたぁ気にもかけず、DADしてみました。ま、100ページくらいですから、抜けも多く記述も大雑把ですが、「500ページのDAD本に挫けたあなたにはちょうど良いかも・・・」ということで、時間と小遣いが余ったら、暇つぶしにぜひ。

ちなみに、電子書籍では中の図表がカラーです。上記リンクに取り扱い書店の一覧が出ておりますmOm

Pocket

DevOps戦略:組織的リリース管理の戦略 – DDevOps#8

今回のテーマはリリース管理戦略をまとめ上げるにあたっての2つの課題について取り上げる。その2つとは、リリース管理のスコープをどうやって決めるかとチーム編成だ。

リリース管理作業のスコープを考慮する際に、2つの基本的な課題がある。

  1. パラダイムのサポート  あなたの組織のリリース管理プロセスがフォーカスをあてているのは単一のパラダイムのチーム・・・例えばアジャイル/リーンチーム・・・だけだろうか?あるいはもっと広範囲な・・・アジャイル/リーンチーム、従来型の手法を採用するチーム、反復型を採用するチーム、そしてアドホックでプロセスに則らないチームまで・・・サポートを検討しているだろうか?リリース管理については現在著述している人々の多くが単一のパラダイムにフォーカスをあてる傾向がある(そのように明確に記してはいないが)。しかし、実際には複数のパラダイムが必要とされているのが、エンタープライズの現実だ。
  2. ドメインのサポート  あなたのリリース管理プロセスは、ITに関連する課題だけにフォーカスをあてているだろうか?それともビジネスに関わるリリースの課題すべてを扱おうとしているのだろうか?ITに関連する課題には、新しいソフトウェアとハードウェアを運用環境にデプロイすることが含まれる。ビジネス面でのリリースの問題には、2,3例を挙げると、マーケティング·キャンペーンや販売組織へのトレーニング、エンドユーザーのための外部支援の枠組みの構築等がある。これは、エンドユーザに向けて構築されたコマーシャルなソリューションであれば、とりわけ重要な要素だ。

これら2つの課題から、リリース管理として扱われる可能性のある範囲を表現する次のグラフが導かれる。

Scope

ディシプリンドDevOpsの観点からは、我々はエンタープライズ全体を対象とする戦略を当然ながら推奨する。対象範囲についてどのような選択をしようが、リリース管理戦略は、デリバリチームがスケーリングすることに対応・支援できる必要がある。検討すべき要因には次のようなものがある:様々なサイズのチーム、地理的分布の度合い、様々なレベルのドメインや技術的な複雑さ、法令遵守が求められる状況下での異なる組織によって構成・分散されているチーム。

リリース管理チームを編成するために考慮すべき戦略には次の3つがある:

  1. 運用部門主導   多くの小〜中規模の組織におけるリリース管理は、運用チームによる多くの活動のうちのひとつとなっている。この”リリースチーム”・・・個人の場合もあるが・・・のアプローチでは、プロジェクト単位でのソリューションのリリースに組み入れられる。開発チームから運用チームへの引き渡しは何回か起こりうるが、運用チームは、開発チームから数名のメンバーがデプロイメント作業に積極的に関与するよう要求するかもしれない。
    運用部門がリリースを管理することの利点は、彼らが現在の運用環境に習熟しており、他のリリースが(もしあれば)並行して行われることを知っている点だ。それにより彼らは全体の状況を把握している。
    主な欠点は、新しいリリースの複雑さについて知らないだろうということであり、それゆえ開発チームメンバーの参画が必要なのだ。
  2. 別々のリリースチーム  より大規模な組織では、リリース管理チームを明確に設けている姿がしばしば見られる。運用部門のサブグループとして設けられることも珍しくない。別チームとする利点は、リリース管理の専門知識をより深めることが出来、本番運用環境に精通し、統合されたやり方でリリースを管理することができるという点だ。欠点は、リリースされるソリューションについては詳しくはなく、リリースプロセス全体でみると、瀬在的にオーバーヘッドをもたらす恐れがあることだ。
  3. デリバリーチームが主導  このアプローチは、開発チームとは別の運用チームを持っていない、非常に小さな組織では一般的であり、そのような組織のデリバリー·チームは、継続的デプロイのプラクティスを実現し、DevOpsに対して非常に統制の取れたアプローチを採用している。デリバリーチームによるアプローチの利点は、チームが、ソリューションがどのようにビルドされるかを知っていることであり、運用へのデプロイ作業を必要に応じて柔軟に行うことができることだ。欠点は、複数のチームの持つ環境でデプロイが衝突するリスクがあることと、異なるシステム間の運用環境への統合問題のリスクがあることだ。幸いなことに、これらの欠点は、開発チーム主導のDevOpsプラクティスと次回以降取り上げるリリース管理プラクティスとの組み合わせで対処することができるだろう。

 

 

オリジナル:Strategies for Organizing Release Management

http://www.disciplinedagiledelivery.com/devops-release-management-teams/

(翻訳 藤井智弘)

Pocket

DADから、DA@ScaleそしてAgility at Scale

本業がすこしベースに乗ってきたので、このブログへの投稿を再活性化させようかと思っています(ま、なにが本業かは様々な見解があるところですが)。きっかけの一つは、今年の5月に、”Disciplined Agile at Scale”という題のホワイトペーパーがでたこと(※今翻訳してます!)、そしてもうひとつは、つい最近ですが、”Agility at Scale”のいわゆるランディングページ(landing page URL : http://disciplinedagiledelivery.wordpress.com/agility-at-scale/)が出来てきたことです。

これまでDADに関してはあちらこちらでお時間をいただいてご紹介をさせていただきましたが、その場でかならず念を押してきたのが、DAD自身はいわゆる”大規模エンタープライム向け”という規模限定ではないということ(#書籍の帯では大規模ゆうとるやないかって?それもまたビジネスというもので・・・バキッ!!☆/(x_x))。

それよりも多様な利害関係者が絡む環境での意志決定のフレームワークを標榜しています。いつの世もどんな組織でも、みんな好き勝手言うもの。ですが、まずはそのような環境で、どのタイミングでどういう材料で何を判断するか、ある程度の枠組みを決め運営できれば、そこから大規模開発へのスケールアップが可能になるというアプローチを採っています。そこで、DADは小規模チームを前提とした意志決定のフレームワーク、それを大規模開発向けにスケールアップしたものを、Agility at Scaleと称してしました(書籍の中にもこのモデルは提示されています)。

で、市場へAgility at Scaleのメッセージを展開しようということで、上記のサイトが立ち上がった次第。

こりゃ、フォローせねば!

ということで、しばらく本業そっちのけでバキッ!!☆/(x_x)・・・様子見ながらフォローしていきますw

 

Pocket

DADステッカーの「Got Discipline?」とは?

dad-sticker-black-metalic

セミナーやイベントなど、DAD関係者が出没する場所でときどき配付される「DADステッカー」。
このステッカー、なぜ「DAD」や「Disciplined Agile Delivery」ではなく、「Got Discipline?」なのかご存じでしょうか。
続きを読む

Pocket

DevLOVE DADご紹介セッション、ありがとうございました。

ちょっと間が空いちまいましたが、去る7/16にDevLOVEさん主催でDAD本の紹介セッションの機会をいただきました。事後、私のFacebookでお礼のメッセージをポストしたのですが、よくよく考えるとごくごく狭い業界関係者だけの公開範囲なので、本来お礼を伝えるべき皆さんに届かない…ということに気づき、こちらに再掲させていただきます。

———————————————————————————————

ちょっと遅れましたが…DevLOVEで企画していただいたDADのご紹介セッションに参加して…というか最後はコメントまでかまさせていただきました。

前職時代に「この本だけは絶対に翻訳して紹介しておくべきだ」と思い、翻訳者チームを集め、1年を経て形になったわけですが、さてホントに意味があっただろうか?
…このイベントで参加者のみなさんが真剣に議論されているのを見て、答は出たと思います。
読書会が立ち上がるという話も耳にしていますが、ありがたいことです。
翻訳チームによるサポートコミュニティもご用意しておりますし、お声がけいただければ、いろんなところに顔を出して、このフレームワークの価値を伝えて行きたいと思います。

DevLOVE企画チームの皆さん、参加者の皆さん、ありがとうございました。

Pocket

発売されました!

先週末、無事にDAD本が発売開始されました!!もう手に取っていただけましたでしょうか?
ある本屋では、こんなに堂々と置かれていました。

dad_book

本も出ましたので、より深い議論などできるような場も持ちたく、セミナーや勉強会などの情報もこのブログで更新します。感想や質問もコメントなどでお寄せください。

翻訳チームはまずは正誤表から 🙂

Pocket

Coming Soon! いよいよ最終確認中〜!

いよいよ最終確認段階に入りました。これで当初の目論見通り、6月中発売なるか?オリジナルの発売からほぼ1年かかってしまいました。途中翻訳者が転職したり会社名変えたりと、一時はどうなることかと思いました。なんとかここまで漕ぎ着けました…ってまだ終わってないけど。
もうすぐ御手元に届きますので、お楽しみに。

by Tomohiro

Pocket