営業さんに知ってほしいアジャイルの勘所 R2

営業さんに知って欲しい
アジャイル開発の勘所

Nov.2012
　しんすく

アジャイルって何ですか？

まず、その理念。

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

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

読み方と最重要ポイント

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

最もシンプルな理解。
またはソフトウェア開発のコンテキストにおいて「アジャイル」と言った時の定義。

“ アジャイル”は
「求められる心がけ」。

“ アジャイルプロセス”は
「開発プロセス」。

求められる心がけとは。

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

多いのでコア・バリューだけ
•顧客価値の最優先 / 継続的提供
•意欲に満ちたチーム構成と支援の提供
および完了までの信頼
•自律的な組織と振り返り
•進捗の尺度は動くソフトウェア
•変化を抱擁する

開発プロセスとは。
ソフトウェアの上手な作り方
。ウォーターフォール型反復型

RUP

ウォーターフォールアジャイル

スパイラル

WF との主な違い
ウォーターフォールアジャイルプロセス

要件初期に固定優先度必須で変化

コスト要件に比例して反復の数だけ
固定

リリース後半に数回反復の数だけ

アジャイルプロセスとは

http://www.versionone.com/state_of_agile_development_survey/11/

アジャイルプロセスとは

ほぼ SCRUM が主流と
考えてよい状態。

SCRUM プロセスの採用事例

http://sec.ipa.go.jp/reports/20120611.html

一枚でわかる SCRUM の概要

http://www.ryuzee.com/contents/blog/4789

最もシンプルな理解。再
掲



最もシンプルな理解。再
掲

どちらが欠けても
ダメ！

アジャイル契約の勘所

本日の最重要ポイント

お客様のコミットが必須な箇所

http://www.ryuzee.com/contents/blog/4789

これを契約で表現するには
•相互協力の義務を明記
•合意内容の変更を一方が
求めた場合に他方がそれを
受け入れる義務の明記
•連絡協議会の開催頻度と
協議内容を明記
( いわゆるスプリントレビュー
)

基本 / 個別契約モデル

http://sec.ipa.go.jp/reports/20120326.html

参考：納品しない受託開発

•どちらもアジャイルプロセス
が前提 http://www.sonicgarden.jp/33

http://www.esm.co.jp/new-agile-contracts-service.html

具体的なお客様の作業 / 責任
1.ユーザストーリーを一緒に検討
すること
2.プロダクトバックログの優先度
を設定すること
( スプリント期間中は原則変更できない )

3.スプリントレビューへ参加し、
チームにフィードバックするこ
と

アジャイル開発の特性

•( 決断できないと ) 早くない
•( 決断を誤ると ) 安くない
•変化に対応できる
•お客様はチームの一員

おまけ

開発側にこんな傾向が
見えたら要注意

国内で最も多い勘違い１

http://objectclub.jp/technicaldoc/xp/agile_misunderstanding

「それは、本当に仕様変更ですか」
「そもそも、それは本当に仕様
“ 変更”ですか？ユーザにも
　理解してもらい、必要な機能のみ
　を組み込みましょう」
※ 注： SCRUM プロセスでは
原則、スプリント期間中に要件の
変更はできません。

「それは、本当に仕様変更ですか」

「変更反映のタイミングも重要です。
　各イテレーションでリリースした
　製品をユーザに評価してもらい、
　その結果を次のイテレーションで
　反映するようにしましょう。」

国内で最も多い勘違い２

http://objectclub.jp/technicaldoc/xp/agile_misunderstanding

「正直、迷惑しています。」

「完全なドキュメントより
動くソフトウェアを相対的に
重視するだけです。」

「正直、迷惑しています。」
「最小限の文書化で、
　最大限の効果を狙う
　必要最小限のドキュメント。
　そうしたドキュメントは
　一朝一夕に書けるものでは
　ありません。」

おつかれさまでした

ご質問などありましたら

Recommended