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

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

Nov.2012

　しんすく

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

まず、その理念。

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

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://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

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

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

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

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

おつかれさまでした

ご質問などありましたら

Documents

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