アジャイル勉強会公開資料

アーキテクチャG　主催　「ソフトウェア工学」勉強会第 1ターン　「ソフトウェアライフサイクルモデル」

第 1回　「アジャイルについて」

2Copyright © 2016 Bigtree Technology&Consulting Ltd. All Rights Reserved.

1. ソフトウェアライフサイクルモデル

2. ソフトウェアプロジェクトの難しさと本質的な課題

3. 課題に対する解法（アジャイルが進めようとすること）

4. アジャイル方法論（エコシステム）概要

5. アジャイルが向かう道

アジェンダ


最初の第 1ターンでは、社内で取り組んでいる「方法論」の検討などを踏まえ、ライフサイクルモデルはひとつではないことを紹介したいと考えました

このテーマは「ソフトウェアエンジニアリングプロセス」分野のサブの分野（ソフトウェアライフサイクル）のトピックとなります

（ソフトウェアプロセス定義、ソフトウェアライフサイクル、ソフトウェアプロセス査定および改善、ソフトウェア計量、ソフトウェアエンジニアプロセスツール）

1　ソフトウェアライフサイクルモデル

ウォータフォールモデル

（線形モデル、予測型モデル）

開発を各フェーズ（フェーズ内でのフィードバックと反復がある）に分割して、それらを線形に接続し、実行するプロセスモデル。（ SWEBoK）（一般的には、要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、総合テスト等にフェーズを分ける）

反復モデル（適応型モデル）

反復サイクルに従った機能性の漸次拡大をおこなうプロセスモデル。（ SWEBoK）

（インクリメンタル、イテラーティブ開発などとも呼ぶ。 RUP（ Rational Unified Process）が代表的な手法。テーマを決めて進めるのであれば段階的リリースはこちらのモデルに近い）

アジャイルモデル（適応型モデル）

一般に、短い反復サイクルで、頻繁に、実行するソフトウェアを、顧客、またはソフトウェア開発に指示を与えるユーザ代表者に作動・展示し、引渡し可能で、小さな拡張部分の作動可能ソフトウェアをその都度、形成する。（ SWEBoK）

本日のテーマ


ソフトウェア開発プロジェクト（特に新規開発）の難しさはどこから来るのか考えてみましょう

2　ソフトウェア開発プロジェクトの難しさ

プロジェクト期間中に知識を得て、情報が生成される学習プロセスとして特徴づけられる。プロダクトとプロジェクトのスコープの不確実性、およびプロジェクトの進展につられて得られる知識である。ソフトウェアとは人間の認識プロセスの直接の成果物であるからである。ソフトウェア・プロジェクトは、建設や製造プロジェクトよりも研究開発プロジェクトにより類似している。ステークホルダーはソフトウェア・プロダクトによって満たされるニーズについて十分明確にできずに合意しないことが多いからである。

あいまいなコミュニケーションを経て、作り手が学習して、認知した「要件・仕様」がニーズと異なるのは当たり前！

しかも、それを初期段階（学習中）に変更無く作ることはできないのが当たり前！

PMBOKガイド第 5版　ソフトウェア拡張版　 1.3.1を参照。


2　 3つの背景と 2つの課題

市場が大きく変化し、要求・要件を決めたときと状況が変わっている。短期間で市場に出したい。（市場への早期展開）

顧客は、要求・要件は、実物をみないと深く考えない、考えられない。（要求・要件の暗黙知の必然性）

作り手は本当の意味で、要求・要件（その背景）を学習途中で設計・構築する必要がある。（フィードバックループの必然性）

あいまいな要求・要件に基づく仕様、更に続く伝言ゲーム。（仕様のあいまいさ）

変化に対して対応できない。（柔軟性の欠如）

p4の内容を検討し、 3つの背景と 2つの課題に分類した

背景

課題


私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

3　アジャイルソフトウェア開発宣言

2001年に発表されたものです。（日本語訳はずっと後）http://www.agilemanifesto.org/iso/ja/（翻訳は倉貫さんとのこと）

•Kent Beck（ XP) •Mike Beedle (Scrum)•Arie van Bennekum (DSDM)•Alistair Cockburn (クリスタル）•Ward Cunningham (XP)•Martin Fowler (XP)•James Grenning (組込みアジャイル、プラニングポーカー）•Jim Highsmith (ASD)•Andrew Hunt (達人プログラマの著者 )•Ron Jeffries (XP)•Jon Kern　（ FDD)•Brian Marick•Robert C. Martin　（アジャイル開発の奥義の著者）•Steve Mellor （ Shlaer–Mellor法）•Ken Schwaber (Scrum)•Jeff Sutherland (Scrum)•Dave Thomas (達人プログラマの著者 )

これらの状況を鑑みて、「アジャイルソフトウェア開発」を推進する動きが生まれた！

http://www.agilemanifesto.org/iso/ja/


3　（解法）小さなフィードバックループの実現

要求・要件の暗黙化

フィードバックループの必要性小さなフィードバックループの実現

優先度のつけ方

ビジネス価値の高いもの順

仕様のあいまいさ

要求・要件の問題、作り手の学習の問題、いずれの問題についても「動くソフトウェア」をもとに、フィードバックすることで解決することを考える

そのフィードバックループは小さければ小さいほど、容易かつコストがかかりにくい

フィードバック

「動く」ソフトウェア

開発

顧客開発メンバ

この 1サイクルを短くする

フィードバック単位が小さいことで、見積精度が上がり、管理しやすさにもつながる


段階リリースはアジャイル以外のプロセスモデルでも利用されているが、期間を小さくし、フィードバックを顧客だけでなく、利用者からも得て改善していく

3　 (解法）小さな単位でのリリースサイクル

市場への早期展開小さな単位でのリリースサイクル

優先度のつけ方

ビジネス価値の高いもの順



開発

顧客開発メンバ

この 2つのフィードバックループの 1サイクルを短くする（ SIモデル）

リリースされたソフトウェア

利用者

リリース



変更容易性を確保するために、変更する箇所の削減、よい設計・実装の採用、デグレ防止を実現する必要がある

3　（解法）変更容易性の確保

柔軟性の欠如変更容易性の確保

デグレの防止

よい設計・実装の維持

変更工数の低減

変更工数の低減

「変更追跡性を担保する」あるいは「不要な文書」を作成しないなどの施策により、変更する場合の工数を低減する。

よい設計・実装の維持

よいプログラム設計の技法（ OCP、 DIPなど）、よい実装の技法（DRY、 KISS等）を用いたプログラムとする。あいまいな要件やとりあえず～の実装をおこなう場合（「技術的負債が増加する」といいます）の修正は期間を決めて、リファクタリングをおこない、技術的負債を返済し、『よい設計・実装』を維持する。

デグレの防止

モジュールレベルの単体テスト、コントローラからの単体テスト、正常系とバリデーションレベルの E2Eテストをおこなうといった施策によってデグレが起こった場合に判定できるようにする。


管理手法を「コマンドオブコントロール」リーダシップから「サーバント」リーダシップへ変更する

主眼をチームにおき、チームが成長できるように「プロセス」を従とするコミュニケーションに変更する

3　（解法）コミュニケーションの改善

仕様のあいまいさコミュニケーションの改善

士気の向上

理解しようとするマインド醸成

進め方の改善をおこなう

オンサイト顧客（ XPプラクティス）

要求・要件を説明できる顧客がすぐ目の前にいるようにすることでコミュニケーションコストを低減する手法。

レトロスペクティブ（ふりかえり）

進め方を一定期間（ 2週間、フェーズ単位など）分を振り替えて、進め方を改善する手法。（予測型プロセスにおける SEPG（ Software Engineering Process Group）と同義）

コードの共同所有（ XPプラクティス）

コードを共有することで変更への影響を確認したり、仕様を確認することを促進するプラクティス。


アジャイル開発を説明した最初の手法

4つの価値（コミュニケーション・シンプル・フィードバック・勇気）と 12のプラクティスを紹介

4　 XP（エクストリームプログラミング）

コードの共同所有

オンサイト顧客計画ゲーム

ペアプログラミング

メタファ週 40時間労働

YAGNI（ You Aren’t Going to Need It)

短期リリースリファクタリング

テストファースト

継続的インテグレーション

コーディング規約

今は「受入テスト」ファーストもよくやられるので、テスト粒度が重要。


アジャイル開発をメジャーにした貢献者。

管理に特化してアジャイルの解法・プラクティスを取り入れたため「管理者」が率先して採用した。

4　 Scrum　 (スクラム）

動作検証の結果をフィードバックしバックログに追加する

4.フィードバック


3.スプリント

2～ 4週間程度のタイムスケジュール。実行中のスプリントは外部からの変更を受け入れない

プロダクトの機能、顧客からの要求、バグ等に優先順位を付けた一覧

1.プロダクトバックログプロダクトの機能、顧客からの要求、バグ等に優先順位を付けた一覧

2.スプリントバックログ顧客顧客顧客目線で実際に動作するソフトウェア

スクラムプロセスをコントロールする。スプリントバックログのタスクへの落とし込み及び進捗管理を実施する

スクラムマスター

開発メンバ

プロダクトを開発する。実作業としては、スプリントバックログに紐づく個々のタスクを日々消化していく。

プロダクトオーナー

プロダクト (最終成果物 )に対して責任を持ち、バックログに優先順位を付ける


RADを形式化した手法機能、設計構築、実装のフェーズを分けて、フェーズの中およびフェーズ間を反復で実現する手法

4 DSDM (Dynamic Solution Delivery Model)

アジャイルソフトウェア開発エコシステムから図を引用（ p253)


アリスタコーバンが主張した手法。

テラーリングを意識し、重要度とメンバ数で分類して、現実的な方法論として整理している。（下図参照）

4　クリスタル

以降Maroon　 (81-200)Diamond (201-500)Sapphire (501-1000)と続く

Orange Webというのもある。

http://users.dcc.uchile.cl/~nbaloian/cc1001-03/ejercicios/crystalclearV5d.pdfから図を引用。

アジャイルソフトウェア開発エコシステムから図を引用（ p262)

http://users.dcc.uchile.cl/~nbaloian/cc1001-03/ejercicios/crystalclearV5d.pdf

http://users.dcc.uchile.cl/~nbaloian/cc1001-03/ejercicios/crystalclearV5d.pdf


アジャイル開発というのは効果があることがわかっています

いつ導入するかという選択のみが問われます

アジャイルはもはやその枠を超えて、発展し始めています

5　アジャイルが向かう道　

アジャイル

エンタープライズ

SAFe（ Scaled Agile Framework)DAD（ Disciplined Agile Delivery)

顧客の対話

DDD（Domain Driven Development)

速度の向上

DevOpsボトルネックがリリースに移った（ Amazon/

Netflix)インフラ技術の向上クラウド技術の普及

MSAの発達が背景

ここにも影響

Immutable InfrastructureInfrastructure as a CodeBlue/Green DeployCanary Deploy


なぜ、今アジャイル開発が進められていないでしょうか？

議題

Technology

アジャイル勉強会 公開資料

アジャイル勉強会公開資料