Posts Tagged ‘Atlassian’

Atlasianの98日リリースサイクルを読み解く

3月 6th, 2010

先月のデブサミであったAtlassianの発表は結構面白かったと思うのですが、ブログやTwitterに感想を書いている人は思ったよりも少ないみたいですね。会社説明は退屈だったかもしれないけど、社内で行っているアジャイル開発の事例は結構参考になるところがあるんじゃないかと思っています。セッションのスライドは以下から見ることが出来ます。

中でも98日間隔(14週間、約3ヶ月ですね)でリリースを繰り返すイテレーションの仕組みはもっと注目を集めても良いと思います。自分で眺めて考えてみた結果を以下にまとめてみます。

◯図のイテレーションはどうして9週目始まり?
開発の最後のイテレーション(Iteration5)と次期バージョンの仕様を決める時期が重なっているからですね。開発者は12週目から14週目の作業が少なくなっていますが、ここで自由裁量な開発期間(Googleの20%ルールみたいの)を割り当ててる人が多いと講演で言ってた気がします。

◯PMMの仕事
PMがProject ManagerならPMMは誰なんでしょう? パッと見でPMより偉い人みたいですが。PMM:Product Marketing Managerとのことです。気になったのはPMMが実施するレビューの順番です。

  • 1週目:マーケットと競合他社のレビュー
  • 2週目:Messagingレビュー(製品の打ち出し方 とかなのかな?)
  • 3週目:製品ローンチのゴールをレビュー

競合分析と最終ゴールの確認は大事ですよね。

◯PM:Product Managerの仕事
この辺は一般的? リリース基準を事前に策定するのは大事だよね。

  • 1週目:時期製品ターゲット層の検討
  • 2週目:6ヶ月先までのロードマップを更新(これより長期の計画は無いのかな? それとも別途作成?)
  • 3週目:リリース基準の策定
  • 4週目:詳細なストーリー作成(製品が使われるユースケースのことでいいのかな?)

◯デザイナの仕事
PMM/PMが製品コンセプトを固めている段階からデザイナの仕事が振ってあります。初期段階はPMと一緒に動き、開発が始まったらプログラマと協業するんですかね。

◯イテレーション
全5回、うち実質的に開発に振り分けられるのは最初の3週間。4週目は”Polishing”とある、機能追加を止めてパフォーマンスや使い勝手を作り上げていくフェーズなのかな? 5週目はリリースにあたっての準備期間の模様。
あと各イテレーションでコード書きはもちろん、バックログの整理や自動化されたテストも準備しているみたい。
社内でドッグフードを食べ始めるのはBETA1からかな?ドッグフードはイテレーションの1回目から食べ始めるそうです。デブサミの講演では「体感として1日1回は落ちる(Confluenceだったかな?)」と話されていましたが、開発直後の状態ならそれぐらい落ちても不思議ではないですね。

◯各フェーズでの確認事項
下部に書いてるのは各フェーズでの確認事項だと考えました。「顧客が求めているか、お金を払ってくれるか」「長期計画に沿っているか」「リリース出来るほど安定しているか」などなど。当たり前だけど大事なことですよね。

ということで、画像から読み取れることを自分なりに書いてみました。これぐらい短くリリース出来ると開発に緊張感が出て良いですね。どれぐらい短い間隔でリリース出来るのかという課題は突き詰めて考えてみると今のムダも見えて結構良いかもしれません。

Developers Summit 2010 参加メモ

2月 20th, 2010

2/18の午後だけ行ってきました。きちんと聞いてきたのは2講演です。

【18-B-3】Google 的分散コンピューティング
Gregor Horpe氏によるGoogleの分散コンピューティング技術の紹介と、その背景にある思想の話。

○Google内で使われている分散コンピューティング技術
GFS, Bigtable, MapReduce, Sawzallの紹介、Googleを支える技術 ~巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)が詳しいです。
Sawzallの発音が”ざうざーる”と言っているようでした、これまで”さうざーる”だと思い込んでた。

○Googleの分散システムの背景にある思想
8つに分けて、事例を交えて紹介してくれました。

  1. Shading
  2. Less is More
  3. Expect Failure
  4. Autonomy
  5. Enpower the Runtime
  6. Favor Stateless
  7. Separate Stateless from Stateful
  8. Precision vs Speed

1. Shading
分割して統治する。役割を分ける、機能を分ける、抽象化する。
例として挙げていたのはユーザアカウント管理に中小レイヤをかぶせるやつだった・・・かな? メモがなくスライドもまだ見れないのでうろ覚えです。

2. Less is More
機能を絞って特徴を引き出す。
Bigtableはトランザクションを始めとしたRDBMSの機能が無いが、その分スケールするように作ることができた。

3. Expect Failure
「エラーが起きるかどうか」ではなく「エラーはいつ起きるか」を考える。ifではなくwhen。
GFSもMapReduceもベースにエラー処理がきちんと組み込まれている。
GFSなら自動でマスタが切り替わる仕組みとか、MapReduceなら失敗したタスクの再スケジューリングとか処理対象からの除外とか。

4. Autonomy
とにかく自動化、人では介さない。
例として挙げられていたのはGFSのMaster/Slave構成。
Masterに障害が発生するとSlave同士が投票しあって次のMasterを決めるようになっている。

5. Enpower the Runtime
言いたかった事がうまく受け取れなかった。「役割を明確に決めないで柔軟にやってね」ってことだと理解しました。

6. Favor Statelessと7. Separate from Stateless from Stateful
状態を持たない。なぜなら状態を持つと途端にスケールしなくなるから。
状態を持つにしても、スケールする部分をきちんと切り分けておくことが大事。

8. Precision vs Speed
ソフトウェアではfaster is better。正確性を期するよりも、高速で大体の精度の予測で動く。
Googleのクラウドで正確な負荷とか測れても意味がない。大体の傾向がつかめればOK。

【18-C-4】ドッグフーディングとアジャイル開発
アトラシアン社の営業さんによる会社の紹介と、社内で行っているアジャイル開発の紹介。
アトラシアンはエンタープライズWiki(Confluence)や障害管理システム(JIRA)を主力商品としており、国内外で多くのユーザを抱えている。日本国内では今回が初めての公演ということで会場は超満員でした。

アトラシアン社は2002年にオーストラリアで設立された。3つの方針を掲げ、OSSの世界をはじめ多くのユーザを抱えている。

  • いい製品を手ごろな価格で
  • 伝統的な営業マンを持たない(電話をかけまくったり、会社訪問しまくる営業マン無し)
  • エコシステムの構築に尽力(製品にプラグイン構成を持たせるなど)

アトラシアンの製品はショートリリースを基本としている。それはユーザからのフィードバックを得やすいからであって、サブスクリプションユーザに価値を提供するためでもある。またチームメンバの緊張感を適度に保ち、バグ修正に時間を割いて使うようにもなるメリットが有る。リリース期間が短いことから必然的にアジャイル開発の形態をとっており、社内で開発版を試す「ドッグフーディング」の文化も根付いている。会社設立時メンバが2人しか居らず、早急に事業を立ち上げるためアジャイル開発をとらざるを得なかったことも今の会社に影響しているかも知れないとのこと。

ドッグフード中のシステムは不安定で、Wikiなどはマイルストーンリリース時は1日1回ぐらい落ちるらしい。社員は不便を感じるが、それが客先で障害として発生するよりかはましという考え方をしている。バグ以外にフィードバックも社員から得られることもある。バグ情報やリクエストは社外に公開した障害管理システムで受け付けているとのこと。

最近ショートリリースのタイミングをさらに狭めたらしく、98日でイテレーションを回しているとのこと。98日のスケジュール詳細はDevelopers Summit 2010 Preso – Sean Osawa – アトラシアン ウィキから詳しく見ることができます。Googleの20%ルールに近い制度がアトラシアンにもあるらしく、開発者はイテレーション中の時間がある期間(Week 12 〜 Week 14あたりだったかな?)に直接の業務と関係が無いことも取り組んでいるらしい。

社内ではレビューを多用している。レビューには早期修正できるコスト削減効果や、開発者の教育効果がある。駄目なレビューでは単なるプレゼンになっていたり、熟練による支配が起きてしまう。

アトラシアン社員のレビューTIPSとして以下が挙げられてました。

  1. レビュー前にコードに関する課題、タスクに目を通す
  2. 変更構成を読む
  3. 機能が動いているかを確認する(確かに年に何回か動かない機能のコミットがある)
  4. 自分が変更するならどういう方針を取るかを考えてみる
  5. レビュー終了後に提案リストを優先順位をつけてまとめて送る

レビューのタイミングとしては頻繁に行うこと。朝でも昼でも、帰る前でも、まとめて行い、開発に割く時間をうまく確保するのもコツ。
見てもらうのは同僚が一番、同僚がだめならTech Lead(技術面の開発リーダかな?)がいいとのこと。ごもっとも。