「Agile Conference Tokyo 2014」に行ってきました。
ソフトウェア開発手法の「アジャイル開発」についてのカンファレンス「Agile Conference Tokyo 2014」に行ってきました。
Agile Conference Tokyo 2014 - イベントTOP
開催概要
- 2014/07/23（水）10:10-17:00
- 日立ソリューションズタワーA@品川シーサイド
- 参加者数 約200人
- 英語でのプレゼンには同時翻訳あり
会場雰囲気
セッションメモと雑記
エンタープライズDevOps: 開発とIT運用間の障壁を取り除くには
- 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化の著者。
- エンタープライズは「プロセス＝waterfall、開発=scrum、運用=waterfall」で行われている。
- これでは遅すぎる。
- これはもともと欧米発な作り方で、ソフトウェアではなく軍事関係（ミサイルとか）で行われていた。日本でこれが行われている（流行っている）理由がわからない。
- 問題点
- 作ってからしか触れない。
- 作ってからしか価値がわからない。
- 作ってから変えられない。
- 最近の関心は、「どれだけ早く火を消せるか。」
- Amazonの例。Amazonの高速にリリース/デプロイしている。
- Amazonはなぜリリース/デプロイに投資するのか？
- 価値が届かない機能を作らないように。
- 最初は安価なものでテスト。最初はスケーラビリティはなくていい。0.1%の人に見せる。その結果と成果を確認すべき。
- 価値が届かない機能を作らないように。
- 全機能のうち、1／3は人に必要とされるが、2/3は必要とされていない。
- 価値が無い機能は無駄の極み。価値は提供しないし、メンテナンス対象となっているため、工数は発生する。
- Amazonはなぜリリース/デプロイに投資するのか？
- 企業の開発パフォーマンスとは？
- リリース頻度。
- チェックインからリリースまでの時間。
- リカバリーまでの時間。
- 変更（リリース）の失敗率。
- インクリメントな変更で、リスク/時間/コストを減らすべき。
- 自動化されたフィードバックの仕組みも必要。フィードバックも自動化すべき。作りながらテストすべき（作り終わったらテストではなく）。
- トヨタの機織り機の例。
- 機織り機について、当初は機器を人がずっと見ていた。その後カイゼンにより、機械がなにか異常が発生したら、機械が人間に通知する仕組み（ブザーなど）を作った。
- ヒトが多くの機器を管理できるようになった。
- フィードバックを自動でする仕組みは大切だ。
- フィードバックが来たら、その場で直す。
- 機織り機について、当初は機器を人がずっと見ていた。その後カイゼンにより、機械がなにか異常が発生したら、機械が人間に通知する仕組み（ブザーなど）を作った。
- テスターと一緒に自動化されたテストを作る。
- Googleの例
- trunkを必ずメンテナンスする。
- ブランチがいっぱいいあると、マージ後するまで、テストできない。
- 必ずトランクからリリースする。1つのtrunkで全てのコードを管理している。
- 機能が大きくなったら、分割すべき。
- 分割するには、多くの負荷と創造性が必要である。簡単なことではない。
- 「リリースすべき/対策すべき」の検討は、やっている者同士で検討/承認しあう。マネージャによる承認プロセスはリスクヘッジしていると思われているが、それは振りでしかなく品質は向上していない。
- 互いのチームで満足度と信頼度が高いと、パフォーマンスが高い。
- Amazonの例：本当に良いと思ったら、承認されなくても勝手にやって成果を出す。
- 失敗を組織でどう扱うか。
- 誰がやったかではなくてとりあえず直す。
- ヒトを批判するのはあまり意味がない。
- 自分がAさんの立場だったら、回避できたか？
- ヒトは悪くない。組織、システムが悪い。
- システム改善はみんなで考えるべき。
- 変えるのはリーダーの責務。
- 失敗することに対して、寛容になる。失敗は当たり前。どれだけ早く対応するか。
- 所感
アジャイルなプロダクト計画策定と分析手法「発見から納品へ (Discover to Deliver) 」入門
- DtD手法の説明。DtD=Discover to Deliver
- 価値のある機能の管理方法、コミュケーション方法
- DtDでは以下を行う。
- 多面的な分析
- 業務パートナー、顧客パートナー、技術パートナーを巻き込んで。
- 計画視点
- 全体、事前(次バージョン)、現在
- ファシリテーション
- 多面的な分析
- ユーザストーリー
- ○として○ができる。
- それにより、○がもたらされる。
- ユーザストーリーの3つのC
- カード
- 会話
- 完了条件。
- 以下はあとで調べる。
- プラグマティックペルソナ。
- ユーザーストーリーは、「時間(リリースタイミング)」対「優先度」のマトリックスで管理すべき。
- 課題管理
- 機能的な側面になりがち。
- 各人で関心は違う。
- 11月ごろに本が出る。
- 所感
- 内容的には以下の内容を合わせた感じ。
アジャイル開発を支えるコード品質とリスク解析
- 静的解析ツール「coverity」の紹介。
- Swiss cheese model
- Swiss cheese model - Wikipedia, the free encyclopedia
- 各工程テストにおいて、テスト実施が漏れているところが重なり、最終的にテスト未実施の部分ができてしまうこと。
- 危険なコード
- 昔より今編集したコード。
- テストカバレッジでカバーしていないコード。
- 変更したコードを呼び出しているコード。
- テスト実施において、テストケースを絞ることが大切。
- バグをもちこさない。
- 無駄なテストを作らない。無駄なテストを実行しない。
- 所感
- coverityでなるほどと思ったこと：ユーザー操作で呼び出されるメソッドを管理して、影響範囲をみる。今後はそれで影響範囲を見る。
- スポンサーセッション(˘ω˘)スヤァ
Thoughtworks社による海外導入事例 ～分散アジャイルの事例～
- Thoughtworks社のアジア、オーストラリア担当コンサルタント
- 数字の話
- 45%のプロジェクトは予算オーバーしている。
- 7%のプロジェクトは納期遅れしている。
- 最終的な価値は56%程度。
- まずは優先順位付けすべき。
- 全部重要はありえない。重要ななかでも優先順位が必ずある。
- アジャイル実施例
- 作業の見える化。カンバン。
- ショーケース：各チーム間で、毎週デリバリーした価値の確認し合う。
- Always on Video：24時間スカイプをつなぎっぱなしにする。
- 孤独を感じるので。
- Fail Fast：できるだけ早くテストをエラーにすること。
- 7%の工数でユーザーテストはできる。
- 今の企業は、自分たちのアイディアが合っていて、みんながきっと買ってくれると勘違いしている。
- 早めにユーザーテストすべき。
- 実施中は全て記憶すべき。操作や発言、表情も。
- one teamにあるために。
- ITとビジネスの壁を取っ払う。その場でみんなで決定し合う。
- ビジョンを共有する。
- チームのショーケース：他チームへの知識伝達。
- チームのローテーション：知識吸収、獲得した技術を活用すべき
- まとめ
- やることを減らすと、価値が増える。
- できる限り見える化を。他のチームと話そう。
- 小分けにテスト。作る前にテストする。
- ビジネスとITの壁を取っ払う。
- アジャイルはミステリーではない。マインドセットのこと。小さいところから始めよう。
- 所感
継続的デリバリーの実現へ！～クラウドによってアプリケーション開発はどう変わるのか？～
- ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイドの訳者
- 今後の流れ
- 1万以上のWebAPIがあり、APIをまとめカタログを提供する企業がある。
- 初期投資を抑えた早い開発が求められる。
- ジャストインタイムな開発。
- そのためには、開発/運用/フィードバックまで検討しないといけない。
- フィードバックの仕組みの例
- 所感
- 最近「フィードバック」という観点がブーム？
- 仕組み自体は汎用的なツールでできそう。
- セットアップする手間を軽減したいときに使うのだろうけど、使うとベンダーロックインされそう。。。
JBoss BRMSとアジャイルプロセスの親和性
- BRMS:ビジネス ルール マネージメント システム
- http://jp.redhat.com/products/jbossenterprisemiddleware/business-rules/
- ビジネスルールの定義、分析のための開発基盤。
- ビジネスルールからロジック部分のプログラムを自動生成する。
- エクセルやDSLで書いて出力する。
- 初回のみ実施する想定。
- 開発者が書くコードはjavascriptとjspだけ。
- いろいろなフレームワークが内在している。
- Struts, Spring, MyBatis
- OpenShif(RedHatのPaaS)tの紹介。
- 今後のPaaSの流れ。
- RedHat Enterprise Linux Atomic Hostの紹介
- 所感
- あっという間に技術が進んでいる。
所感と雑記
- 他のカンファレンス/勉強会と比べ、雰囲気が固かったです。
- 企業間の勉強会のような雰囲気。
- 7割ぐらいスーツ。
- 平日だから？
- クラウド基盤や静的解析のセッションなどもあり「アジャイル」という観点では薄かった。しかし、Thoughtworks社の2名の特別講演は内容も濃く素晴らしかった。
その他
某IBMのアンケート。こういん邪悪なことはやめてほしいものです(；´Д｀)
