アジャイル開発は文書が少ない分、コミュニケーションの善し悪しで成功するかしないかが分かれる開発方法だと思っています。そこで、ビジネスチーム(ユーザ側)と技術者(ベンダー側)との間で要件の誤理解がないように防ぐ工夫をおしえてください。特に、ベンダー側の工夫ではなく、ビジネスチーム側の工夫として、ベンダーが誤って要件を理解していないことを確認するような手法があると望ましいです。もしくは、ビジネスチーム側が持っている無言の前提をきちんと共有できているかどうか、などというところも重要だと思いますので、そういったところを確認する術があれば教えてください。

回答の条件
  • 1人2回まで
  • 13歳以上
  • 登録:2010/12/21 00:11:16
  • 終了:2010/12/23 00:57:40

ベストアンサー

id:asuka645 No.1

あすか回答回数856ベストアンサー獲得回数972010/12/21 00:45:05

ポイント23pt

まず、「アジャイル開発は文書が少ない分」という前提が間違っています。

文書が少なければ、それに反比例するようにユーザー側とベンダー側の齟齬が発生します。

アジャイル開発では、仕様や設計変更に臨機応変に対応するために、従来のウォーターフォールモデル以上に文書による確認が必要とされます。


ただ、むやみに文書を増やせば良いというわけではありません。

エクストリーム・プログラミングの手法を参考にすると良いでしょう。

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング

  • 作者: James Shore Shane Warden
  • 出版社/メーカー: オライリージャパン
  • メディア: 大型本

id:maggy91

ありがとうございます。「仕様や設計変更に臨機応変に対応するために、従来のウォーターフォールモデル以上に文書による確認が必要」とありますが、具体的にはセッションノートの他にはどのような文章でしょうか?

2010/12/21 00:56:20

その他の回答(3件)

id:asuka645 No.1

あすか回答回数856ベストアンサー獲得回数972010/12/21 00:45:05ここでベストアンサー

ポイント23pt

まず、「アジャイル開発は文書が少ない分」という前提が間違っています。

文書が少なければ、それに反比例するようにユーザー側とベンダー側の齟齬が発生します。

アジャイル開発では、仕様や設計変更に臨機応変に対応するために、従来のウォーターフォールモデル以上に文書による確認が必要とされます。


ただ、むやみに文書を増やせば良いというわけではありません。

エクストリーム・プログラミングの手法を参考にすると良いでしょう。

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング

  • 作者: James Shore Shane Warden
  • 出版社/メーカー: オライリージャパン
  • メディア: 大型本

id:maggy91

ありがとうございます。「仕様や設計変更に臨機応変に対応するために、従来のウォーターフォールモデル以上に文書による確認が必要」とありますが、具体的にはセッションノートの他にはどのような文章でしょうか?

2010/12/21 00:56:20
id:ko8820 No.2

ko8820回答回数1221ベストアンサー獲得回数692010/12/21 00:46:02

ポイント23pt

>アジャイル開発は文書が少ない分

これは誤解です。文章を多くすることも可能です。

アメリカでは契約社会ですが、

文章に書かれていない要件に関して保障をえるのは難しいです。

>ビジネスチーム側の工夫として、ベンダーが誤って要件を理解していないことを確認するような手法

要件の文章とともに

必ず数例の実例を明記

要件が理解できなくても、入力と出力例で最低限理解できるようにしておく

>ビジネスチーム側が持っている無言の前提をきちんと共有

無理です。どんな開発手法を使っても無理です。

アジャイル開発では重要なことは、無理なことは無理と認め、努力しないことです。

無言の前提を共有なんてできません。できないというスタンスから、できなくても問題の内容に考えるのが

アジャイル開発の考え方です。

アジャイル開発の特徴に反復があります。

何度も同じ工程を行うことで、精度を高める手法です。

要件が間違って伝わってないかを何度も確認する手法を導入すべきです。

正しく伝わることに努力することよりも、間違って伝わったことを検出する方法を導入すべきなのです。

上記にあげるように、サンプル例をIN-OUTの形で提示するのも、検出する技法のひとつです。


アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)
ディーン・レフィングウェル 玉川 憲
4798120405

id:maggy91

ありがとうございます。参考になりました。

2010/12/23 00:50:51
id:asuka645 No.3

あすか回答回数856ベストアンサー獲得回数972010/12/21 01:27:13

ポイント22pt

具体的にはセッションノートの他にはどのような文章でしょうか?

セッションノートは単なる議事録です。

それよりも、以下のドキュメントの方が重要です。

  • 開発標準
  • 成果物共有方式
  • ストーリー&プラニング
  • コードレビュー
  • リファクタリングレビュー
  • 受け入れテスト成果
id:maggy91

フォローありがとうございます。参考になりました。

2010/12/23 00:51:08
id:tama213 No.4

tama213回答回数486ベストアンサー獲得回数302010/12/23 00:49:31

ポイント22pt

ウォーターフォールモデルとアジャイルの違いは、

単に、前工程に戻ることを許容するかしないかの違いです。

アジャイルの開発手法を導入してるところでも

文書はほとんど、ウォーターフォールモデルと同じところがほとんどです。

ご存知のとおりアジャイル手法もだんだん考え方が変化してます。

http://d.hatena.ne.jp/mnishikawa/20100410/1271463563

>コミュニケーションの善し悪しで成功するかしないかが分かれる開発方法だと思っています

これは、どの開発モデルでもそうです。

ウォーターフォールモデルでも同じです。

id:maggy91

ありがとうございます。

2010/12/23 00:57:23

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません