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


               Nov.2012
               しんすく
アジャイルって何ですか?


 まず、その理念。
アジャイルソフトウェア開発宣言




            http://agilemanifesto.org/iso/ja/
読み方と最重要ポイント

すなわち、左記のことがらに
価値があることを認めながら
も、私たちは右記のことがら
により価値を置く
最もシンプルな理解。
またはソフトウェア開発のコンテキストにおいて「アジャイル」と言った時の定義。




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

“ アジャイルプロセス”は
「開発プロセス」。
求められる心がけとは。




              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://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.スプリントレビューへ参加し、
  チームにフィードバックするこ
  と
アジャイル開発の特性

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

開発側にこんな傾向が
見えたら要注意
国内で最も多い勘違い1




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

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




      http://objectclub.jp/technicaldoc/xp/agile_misunderstanding
「正直、迷惑しています。」

 「完全なドキュメントより
 動くソフトウェアを相対的に
 重視するだけです。」
「正直、迷惑しています。」
「最小限の文書化で、
 最大限の効果を狙う
 必要最小限のドキュメント。
 そうしたドキュメントは
 一朝一夕に書けるものでは
 ありません。」
おつかれさまでした


ご質問などありましたら

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