アジャイル開発の基礎知識抜粋版

アジャイル開発プロセスの基礎知識
2016/7/13 1Copyright (c) 2002-2016 Eiwa System Management, Inc.
抜粋版

2Copyright (c) 2002-2016 Eiwa System Management, Inc.2016/7/13
アジャイル開発を必要とする状況
システム開発には様々なリスクが潜んでいる
要求
ニーズ
システム
市
場
供
給
者
¥
供給獲得
開発要求を早く固定すると
ニーズとかい離する
リスクが大きくなる
参考：IPA「非ウォーターフォール型開発WG活動報告書」 http://sec.ipa.go.jp/reports/20110407.html
変化が早く大きい
システムが
ニーズに対して
陳腐化する
【前提】
供給したシステムが、
ニーズに合致し続ける
ことが、成功条件。
【前提】
供給されたシステムに
よって、さらにニーズが
変化する。

開発プロセスの短サイクル化
開発／運用技術の進歩に後押しされて、短サイクル化が進行
分析
設計
実装
テスト
時
間
時
間
要求(スコープ) 要求(スコープ)
ウォータフォールイテレーション
要件定義
各工程を
並行で実施
1～4週間
イテレーション
時
間
要求(スコープ)
フロー
短サイクル化

アジャイルソフトウェア開発宣言
2001年「アジャイルソフトウェア開発」という言葉が発明された
http://agilemanifesto.org/iso/ja/principles.html
「アジャイル開発宣言」と同時に、
各手法の共通項を原則としてまと
めた。
当時、軽量級と呼ばれていたソフトウェア開
発手法の提唱者により、各手法の共通点を
まとめて、「アジャイル開発宣言」とした。
http://agilemanifesto.org/iso/ja/

アジャイルの潮流
進化し、ビジネスへの活用が高まっている
Lean/Agile
Agile/UX
大規模
組織改革
XP
2000
Agile
2001
スクラム
FDD, Crystal,
DSDM, ASD
2010
リーンソフトウェア開発
Evo
Patterns
TPS
Deming
Lean
201６
Kanban
Lean Startup
Enterprise Agile
・SAFe
・DAD
・LESS
KAIZEN
Scrum
RAD

代表的なアジャイル開発手法
各手法は提唱者の関心事で情報をまとめたものにすぎない
XP
Extreme
Programming
Kent Beckらが提唱している手法。
「変化ヲ抱擁セヨ」をスローガンとして、ソフトウェア開発
技術の複数のベストプラクティスを極端に実施すること
で、開発サイクルを素早く回す。
開発者視点
・原理/原則
・開発プラクティス
・管理プラクティス
スクラム
Scrum
Ken Schwaber、Jeff Sutherlandらが提唱している手法。
ソフトウェア開発のマネジメント面にフォーカスをあて、
チームを自律的に動かすための場作りの仕掛け（フ
レームワーク）を提供している。
管理者視点
・原理/原則
・管理プラクティス
リーン
Lean Software
Development
Mary Poppendiekらが提唱している手法（考え方）。
トヨタ生産方式をお手本として、ソフトウェア開発を成功
させるための原則集。この原則をもとに、具体的なプラ
クティスを生み出す。第一原則は「ムダの排除」。
経営者視点
・原理/原則

アジャイルチームでの開発実践例
スクラムのフレームワークに様々なプラクティスをプラグイン
スクラムフレームワーク

アジャイルチーム
アジャイル開発の主な登場人物
3つの役割でチームを運営する
プロダクト
オーナー
(顧客)
プロセスが円滑に進
むようにする人達支援者
開発者
要求
成果物
支援
市場
ニーズ
サービス要求をもとに開発を
する人達
スクラムでは
・支援者⇒スクラムマスター
ビジネスの責任者と
して、成果物の価値
を最大化する人(達)
ユーザー役割は目印で、
実際の肩書とは
異なることもある

多重のPDCAサイクル(チームの視点)
イテレーション毎に動くソフトウェアを開発する
Plan
・イテレーション計画会
Do
・朝会
・開発
Done
Keep Try
Problem
KPT
DoneToDo Doing Done
ﾀｽｸﾎﾞｰﾄﾞ動く
ソフトウェア
ﾊﾞｰﾝﾀﾞｳﾝﾁｬｰﾄ
動作させて
確認するので
ごまかせない
Plan
・インセプションデッキ
・リリース計画会
プロダクト
バックログ
要求
要求
要求
要求
要求
要求
要求
CheckAct
・ふりかえり会
・レビュー会
PDCA
2016/7/13 Copyright (c) 2002-2016 Eiwa System Management, Inc. 9

インセプションデッキ
 プロジェクトを始めるにあたり、プロジェクトの関係
者で合意すべきことを話し合うセッション、および、
そのための質問
 プロジェクト憲章
 プロジェクトの途中でも効果が高い
関係者が話し合いを通じて合意する
出典：『アジャイルサムライ』サポートページ https://github.com/agile-samurai-ja/support
我われはなぜここにいるのか
• 大事な理由その1
<このプロジェクトの根幹に
関わる理由を1つ、ここに書く>
エレベーターピッチ
• [潜在的なニーズを満たしたり、
潜在的な課題を解決したり] したい
• [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある理
由] ができ、
• [代替手段の最右翼] とは違って、
• [差別化の決定的な特徴] が備わっている。
パッケージデザイン
(プロダクトの名前)
(素敵な写真)
(最高のキャッチコピー)
(ユーザーへのアピールその1)
やらないことリスト
やるやらない
あとで决める
プロジェクトコミュニティは...
コアチーム
(○○グループ)
(他のチーム)
(ほげほげ部門)
関係者全員を！
...思っているよりもずっと大きい！
技術的な解決策の概要
←リスクがある箇所
←今回は対象外
採用する技術:
* <プログラミング言語>
* <ライブラリ>
* <ツール>
* <その他の要素技術>
夜も眠れなくなるような問題は何だろう?
• もし起きたらこわーいこと、その1
俺たちの“Aチーム”
人数役割強みや期待すること
1 アナリスト必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
素早い繰り返し型の開発スタイルで働ける。
2 開発者 C#、MVC.NET、jQuery、SQL
ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
0.5 マネージャ顧客と直接顔を合わせてのコミュニケーションを担当する。
状況報告、スコープ調整、予算管理、レポートラインへの報告
期間を見極める
リリース!
構築受入テストトレーニング
~3ヶ月
あくまで推測であって、確約するものではありません。
1週間 1週間
トレードオフ・スライダー
典型的なフォース
機能をぜんぶ揃える(スコープ)
予算内に収める(予算)
期日を死守する(時間)
高い品質、少ない欠陥(品質)
MAX MIN
MAX MIN
MAX MIN
MAX MIN
上記以外で重要なこと
簡単に使える
考えさせない！
詳細な証跡(なんでもログを取る)
(などなど)
MAX MIN
MAX MIN
MAX MIN
MAX MIN
初回のリリースに必要なもの
3名、3.5ヶ月、$250K
リリース!
構築受入テストトレーニング
~3ヶ月 1週間 1週間
<プロジェクトの名前>
<スポンサーの名前>

短期間のイテレーションで開発する
タイムボックスで時間を区切って開発する
計
画
会
レ
ビ
ュ
ー
会
開発実施
計
画
会
ふ
り
か
え
り
会
開発実施
計
画
会
ふ
り
か
え
り
会
開発実施・・・
計
画
会
ふ
り
か
え
り
会
開発実施
外部に
リリースする
場合もある
P D
・・・
イテレーションは
1～4週間の
タイムボックスふ
り
か
え
り
会C
A
レ
ビ
ュ
ー
会
リ
リ
ー
ス
レ
ビ
ュ
ー
会
レ
ビ
ュ
ー
会
・・・
早期の失敗は
次の糧となる

イテレーション計画会
POと開発でゴールを合意し、その達成方法までを計画する
プロダクト
バックログ
要求
要求
要求
要求
要求
要求
要求
バックログ
開発者が中心となって、
優先順位の高い要求から
タスクに分けて見積る
タスクタスク
タスクタスク
イテレーションゴール
(イテレーションで実現する分)を
プロダクトオーナーと開発で合意
優先順位の低い要求は
見積もらない
計画/見積りは
分析/設計活動を
兼ねる
オーバーコミットに
注意

プロダクト
バックログ
プロダクトバックログ(ＰＢＬ)
優先順位づけされた製品の実現に必要な項目（要求）リスト
要求
要求
要求
要求
要求
要求
要求要求
イテレーション中も
新たな要求を追加可能
新たな要求を追加すれば、
バックログからあふれる
or 優先順位が下がる
要求
優先度ではなく
優先順位
優
先
順
位
高
低
優先順位の高いものほど
詳細化されている
近い
遠い
細かい
粗い
ユースケースを
使うこともある
要求の管理単位は
ユーザストーリが
よく使われる
リファインメントは
POと開発が協力して
行なう
優先順位は絶えず
メンテされている

タスクボード
 イテレーション内で完了すべき要求や、タスク(実装、
調査、改善)の状態を可視化したボード
 イテレーションバックログを管理する
タスクの現時点の状況を把握できる
ToDo Doing Done
タスク
要求タスク
タスク
タスク
タスク
タスク
タスク
タスク
未着手実施中完了
着手完了要求
タスク
タスク

朝会
 現状とその日の行動を確認
 昨日やったこと、
今日やること、
問題点の3点のみ報告
 問題点の洗い出しが目的
 タスクボードなどの前で行なう
 開発は全員参加
 スタンドアップで15分以内で実施
 問題点の検討は2次会で人を絞って実施
 イテレーションゴールが達成できるように協力
イテレーションゴールが達成可能か、障害があるか確認する
朝会の例
参考：「PF実践編：朝会ガイド」 http://ObjectClub.jp/community/pf/

テスト駆動開発 (TDD：Test-Driven Development)
 ユニットテストを作り、ユニットテストで動作を確認し
ながら、開発をすすめるという、開発手法
 Extreme Programming（XP）のプラクティスでテストファー
ストと呼ばれていた開発手法の進化系
 品質保証の手法ではない、開発者のための設計手法
 開発のフィードバックサイクルを小さくする技術
 ユニットテスト、リファクタリングと相互補完する
テストの実施を繰り返すことで、開発を駆動していく
ユニットテストリファクタリングTDD
参考：『リファクタリング』

単体テストコードを作りながら開発
小さなゴール達成を繰り返して、確実に開発を進める
単体テスト
コードを書く
テストに沿った
製品コードを
書く
テストの失敗を
確認する
テストが通る
最小コードを
記述する
テストが通ること
を確認する
不吉な臭いは
リファクタリング
テストが通ること
を確認する
1 2 3 4
567
8 素早く繰り返す
TDDのプロセス

製品
継続的インテグレーション(CI：Continuous Integration)
常に製品を出荷可能な状態を維持する
モジュール
モジュール
モジュール
結合&
テスト
製品
モジュール
モジュール
モジュール
モジュール
製品
モジュール
モジュール
モジュール
モジュール
不具合
不具合の原因は、
最後に結合した
モジュールに起因
結合&
テスト
参考：「継続的インテグレーション」http://ObjectClub.jp/community/XP-jp/xp_relate/cont-j

他の利害関係者にも
参加してもらうのが
望ましい
イテレーションの終了
ふりかえり会の質がチームの成長に影響する
ふりかえり会
プログラミング
ユニットテスト
計画した作業が残っていても、
時間になったら終了する
(タイムボックス)
受入テスト・・・
終了前に
イテレーションを
中止することもある
レビュー会
チームがより良くなる
改善のアイデアを
創出する
イテレーションで
学んだことを確認する
プロダクトオーナーに
デモを行い
フィードバックをもらう
イテレーション中は、
外部からの
ゴールが変わるような
変更は受け付けない

テーマ：作業を効率的に行なうために
KPT(Keep、Problem、Try)ふりかえり
アジャイルチームのメンバー全員参加で行なう
Keep Try
Problem
(1‘)試してみてうまくいったこと／続けること
(2) 不満点、問題点
(4)Problemに効きそうな改善策
(3)Keepを強化する改善策
(1)続けること、良いこと
開始前に深呼吸する
机の上を片付ける
●焦ったら、深呼吸する
●迷ったら、アラームを挙げる
●....
●作業場所が狭い
●迷うことが多い
●....
●机の上を片付ける
●立って行なう
●荷物はイスの上に置く
●事前に何をするか、確認
する
●開始前に深呼吸する
(6)試すことを選択、
合意する
(5)工夫したいこと●指のストレッチをする
●....
参考：『これだけ！KPT』

イテレーションの時間割 (1週間の例)
木金月火水
9:30～9:45 朝会朝会朝会朝会朝会
10:00～12:00 レビュー会
13:30～15:30 ふりかえり会
16:00～18:00 勉強会
計画会
時間の使い方を事前に定めることで、調整のコストを減らせる
原則的に
定時後は
仕事をしない
ふりかえり会の直後に
計画を立てる
日々の開発も
タイムボックス
会議以外は開発
勉強会の時間も
事前に確保する

 本資料に関するお問い合わせは下記までお願いし
ます。
sales@esm.co.jp
twitter @esmsec
株式会社永和システムマネジメント
コンサルティングセンター
http://sec.tky.esm.co.jp/
お問い合わせ

アジャイル開発の基礎知識抜粋版

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a アジャイル開発の基礎知識抜粋版

Semelhante a アジャイル開発の基礎知識抜粋版 (20)

Mais de ESM SEC

Mais de ESM SEC (20)

Último

Último (12)