短い時間だったのでかなり駆け足でした。もっとじっくり聞きたい感じでした。
以下適当なメモ。嘘かいてあるかもしれません。
なぜ今アジリティが求められる？
- ほとんどの会社が5年しないうちに出て行ってしまう
- 残る会社は戦略を変えつづけている
- 顧客ニーズへの俊敏な対応
アジャイル導入の効果は魅力的
- 導入により改善されたと答えている人の割合
- 生産性82% 品質87% 顧客満足度78% コスト72%
IBMソフトウェアグループでの開発手法の変遷
- 日本では 15%〜20%
- 反復型は50%以上
- 普及が進んでいる
アジャイル開発の本質
- アジャイル開発を企業に導入する際の課題
- 規模に関係なく適用可能なプラクティス
- 大規模だからこと考えるプラクティス
アジャイル開発手法の共通点は確かにある
- 基本的なベストプラクティスには共通点がある
- 反復＆インクリメンタル＆適応型の開発
- 短いタイムボックス内で動くコード
- 小さな一口単位で開発
リーン開発とアジャイルは切っても切り離せない
- トヨタ開発手法でアジャイルを上司に説明する手もある
- 在庫を持たない
- → 無駄に仕様書を書きすぎていませんか
- サイクル単位を短くする
- → 要件定義をしてからシステムリリースまでの期間
反復＆インクリメンタル＆適応型
- 要求は劣化していく
- 時間がたてば要求の信頼度は落ちていく
- 要件を最初に決めきれるのか
- 一番最後にシステム統合するリスク
アジャイルの共通ポイント1:アジャイルでは全体をおさえた上で
- 無駄に詳細要求を作らない
- システム統合リスクを初期に削減
- フィードバックを得手が句集改善
- 重要なものから作る
- 早期にリリース可能
アジャイルの共通ポイント2:短いタイムボックス内で動くコードを
- バックログ 優先順位をつけて管理されている
- チームが定義、構築、テスト、評価してタイムボックスで繰り返す
- バックログで優先順位を常に管理
- チームの中でテストまですべておこなう
アジャイルの共通ポイント3:小さな一口単位で開発する
- 仕事はストーリーとタスクに分ける
- ストーリー
- 「柔軟な」要求の表現
- またはある要求の話し合いの必要性を示したもの
- 実現すべき機能
- タスク
- ストーリーを実装するために、メンバーが行うべきこと
パラダイムシフト：スコープを固定せずに管理する
- 要求が固定
- リソースと期日を見積もる
- リソースと記述が固定
- 要求(スコープ)を見積る
ユーザーと理解し合えるかが大事
- 製品開発では企画と開発チームがちゃんとこれを抑えられるかが大事
- アジャイル開発なのに最初にきめた要求を出せといわれると失敗。
なぜ、アジャイルは企業レベルでは使えないと思われるのか？
- もともと小規模開発から発達してきた経緯
- XPは元は10人以下のチーム向き
- 実質的に大規模開発に不向きなものがある
- 「同一地点での開発」「顧客もチームの一部に」
- 既存の開発スタイルに慣れている組織にとっては「新しいもの」を導入することが難しい
- 縦割り組織、官僚的文化、契約体系、既存アセット
- 日本特有の請負契約では難しい
方法論、技術、ツールが進化。大規模適用をサポート
- アジャイルのメリットをいかせる
- 不向きなプラクティスは改良すればいい
アーキテクチャは自然発現する。
企業その物に内在する課題
- 公式なポリシーと手続き
- 過去の苦い経験によって追加されていく
規模に関係なく適用可能なプラクティス
- 定義・構築・テストのコンポーネントチーム
- Jazzプロジェクトは 2005年より7ヶ国 120名
- 「定義・構築・テスト」のスキルを有したチームを核としてチーム編成
- 4-10人のチームが20個
- PM、リーダーをあつめたPMCというチームが統括
反復型開発、頻繁な小規模リリース
- 立ち上げリリース計画
- 要件定義
- マイルストーンにn回反復
- １反復4週間
- イテレーションごとのテストデモふりかえり
- エンドゲーム
- 修正・洗練化
- テスト修正
2レベル計画作りと追跡
- アジャイルでは、粗いリリース計画と、詳細な反復計画を用いて計画づくりとトラッキングを行う
- 反復毎に詳細な計画をたてる
コンカレントテスティング
- アジャイルでは、「すべてのコードはテストされたコード」である
- チームの中でテストはやっている
- 統合テストチームが統合テストパフォーマンステストをやっている
- 正常に動くビルドを少なくとも1日1回作り出す
- ソース統合、ビルド自動化、テスト自動化が必要
反復ごとの「ふりかえり」の実施
- 定期的間隔で、チームはより効率を高めるためにどうすべきか考察し、やり方を改善する
大規模だからこそ必要なプラクティス
意図的なアーキテクチャ
リーン要求開発
- 仕様書つくる暇あったら動くコードを作った方が早い
- とはいっても大規模では、ビジョンや非機能要求などの共通な要求は前倒しで作っておかないといけない
- 要求の劣化をさけるためにジャストインタイムで要求を詳細化する必要がある
高度に分散化した開発の管理
- 大規模開発では分散開発にならざるをえない
- 優先度、リアルタイムの上京、依存関係、阻害要因の共有が不可欠
- ツールの使用と組織的なアプローチが必要
- 上位チームは週2回のミーティングをやっている
アジャイル・リリーストレイン
- 一般的にアジャイルチームはより多くの成果を素早く納品できる
- 複数チームの同期が難しい
- リリースを固定され遅らせることができないスケジュールと考える
- 時間通りに次々と発車する電車のように
- リリース日、テーマ、品質が固定
- 落とすのは機能
- 同期を取らなければならないものは必須。それ以外は優先順位付けしたものから作る
顧客とオペレーションへのインパクトの調整
- 開発チームが小規模リリースを実施できても企業としてはそれで終わらない
- 顧客にどう届けるか
- Jazz.net では開発の模様を完全に外に公開,ソースコードも丸見え
組織を変化させる
- ボトムアップアプローチ
- 小さなチームで隠れてやってもそれなりの成果は出るけど、トップダウンでやるべき。
- 組織が抱える課題に取り組む
ビジネスパフォーマンスを計測する
- 開発チームだけではだめビジネスとしてのメトリックスが必要
- 経営者が複数プロジェクトを横串で見てポートフォリオとして判断する仕組みが必要
まとめ
大規模でもアジャイル開発できる。これははじまったばかりでもなく終わりでもない。
アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)
- 作者: ディーン・レフィングウェル,玉川憲,橘高陸夫,畑秀明,藤井智弘,和田洋,大澤浩二
- 出版社/メーカー: 翔泳社
- 発売日: 2010/02/18
- メディア: 大型本
- 購入: 5人 クリック: 255回
- この商品を含むブログ (18件) を見る
