アジャイル/スクラムおよび機能仕様
私は4人の開発者、1人のドメインエキスパート、1人のマネージャーの小さなチームで働いています。私たちは、スクラムを使用してプロセスを試み、形式化することを目指しています。
私がアジャイルについて理解していることから、それは私たちがとにかくやっていることに近い（ようである）ようです。私たちの製品が持つ全体的な機能を簡潔にまとめたドキュメントがあります。各機能をコーディングするとき、私たちは座って口頭でスラッシュアウトし、顧客が望むものをドメインエキスパートに頼ります。その後、コードを記述し、他の開発者/ドメインエキスパートが漠然とした方法でテストします。改善が提案され、実装されます。
前回のISO 9001監査では、トレーサビリティがないために（当然のことながら）懲戒処分を受けました。監査人は、製品が何をするかの記録があることを確認し、それがそれを行ったことを証明するためのテストを行う何らかの方法を求めていました。
このためのスクラムとその他のメリットを提供するためにスクラムを探していますが、これまでのところ、詳細な機能要件がどこで記録/テストされているかという私の質問には答えていません。アジャイル/スクラムについての私の理解は完全とはほど遠いので、誤解がある場合は訂正してください。
例として、「顧客として、A、B、またはCのシステム状態を選択できるようにする必要がある」というユーザーストーリーがあるとします。 「状態A、B、またはCを選択できるはずです。システムはその状態に変わります」という受け入れテストがあります。
これが実装されるスプリントに来て、座って、A、B、Cラジオボタンと「適用」ボタンを備えたウィジェットを作成することを決定します。次に、それをコーディングします。
このウィジェットをテストすると、次の問題が見つかります。1. Bを選択しても、前のラジオボタンがオフにならない場合があります。 2.オプションCはシステムで使用できない場合があるため、グレー表示されているはずです。 3.最初に開いたとき、最初の選択は現在のシステム状態と一致しません。
私の質問は、これがどこでどのように記録されるかです。 「3つのラジオボタンを持つウィジェットが存在します。ウィジェットが作成されると、現在のラジオの選択はシステムの状態と一致するはずです」という詳細な機能仕様はありません。このドキュメントの欠如を踏まえて、システムが監査人に想定されていることを実行するか、実行しないことを証明するにはどうすればよいですか？
このドキュメントの欠如を踏まえて、システムが監査人に想定されていることを実行するか、実行しないことを証明するにはどうすればよいですか？
なぜそれが与えられたのですか？作成されるのはソフトウェアだけであるというスクラムのルールはありません。受入基準に「ISO 9001に準拠した詳細な機能仕様がある場合に行う」を含めるようにします。または、別の話にまとめてください：「ISO 9001チームの開発者として、私たちのソフトウェアが準拠するように機能仕様が必要です」。仕様を作成し、そこからその仕様を実装するために必要なストーリーを思いつくことができます。
この質問へのコメントで、@ Peteは、仕様がストーリーである場合、反復の後に配信されるものがすべて仕様である場合、製品を「潜在的に出荷可能」にすることができると懸念を表明しました。
このように見てください。最終製品は、A、B、C、Dなどの多くの部分で構成されています。各反復の終わりに、これらの部分の1つが完成し、出荷できる可能性があります。 Aが完了すると、出荷可能になるはずです。 Bが完了すると、出荷可能になる可能性があります。
Aはソフトウェア製品である必要があるとどこに記載されていますか？は、単なる機能仕様、テストケース、またはDBスキーマなどであっても、出荷可能になる可能性があります。
それはどういうわけかあなたの製品の外にあるようにあなたの機能仕様を見ないでください。代わりに、ソフトウェア、DBスキーマ、テストケース、ユーザーガイドなどと同等に、提供する製品の不可欠な部分としてそれを見てください。
例として、「顧客として、A、B、またはCのシステム状態を選択できるようにする必要がある」というユーザーストーリーがあるとします。 「状態A、B、またはCを選択できるはずです。システムはその状態に変わります」という受け入れテストがあります。
私の意見では、あなたの問題があります。そして、アジャイルの領域に含まれるプロジェクト管理手法であるスクラム（2つの用語を混同しないでください）は役に立ちません。しかし、他にもアジャイル技術があります。このシナリオでは、 動作駆動型開発 が注目すべき場所です。
これが問題だと思う理由を説明します。最初のステートメントは実際にはユーザーの要件ではなく（BDDの機能）、2番目のステートメントは動作の定義ではありません（シナリオ、BDD）。
Feature: State A
As a customer
I need to be able to select system state A
So that the fires of Mordor will burn
Feature: State B
As a customer
I need to be able to select system state B
So that the orcs will be at the gates
（私はこれらのどちらももう一方を必要としないと想定しているので、それらは別個の機能です。）
"So that ..."句に注意してください。それらは機能の重要な部分です。各機能に「So that ...」を書くのに問題がある場合は、その機能が必要ないか、またはそのスコープが大きすぎます。このケースでは後者を疑っているので、3つの状態に分類しました。
テスト定義は似ていますが、実際には何も指定していません。 BDDには、私たちがテストしているシナリオに集中するのに役立つ、Given-When-Then構文があります。
Given that I am on the state selection screen
When I select state B
Then the horn of Mordor should sound
And the orc-cages should be unlocked
各句には、必要に応じてAnd、But、Orの拡張子を付けることができますが、一般的には、When（ユーザーアクション）は単一の定義アクションである必要があります。
リストした3つのバグに戻ります。
# Selecting B sometimes doesn't uncheck the previous radio button.
Given that I am on the state-selection screen
When I select option B
Then options A and C should be deselected
これは完全に有効なテストです。標準ライブラリのラジオボタンを使用する場合はまったく不要ですが、このバグがある場合は明らかにそうではないので、それを考慮する必要があります。
# Sometimes option C is unavailable on the system, and so should be greyed out.
Given that state C is unavailable
When I load the state-selection screen
Then option C should be greyed out
And option C should be unusable
Given that I am on the state-selection screen
When state C becomes unavailable
Then option C should be greyed out
And option C should be unusable
2つの動作が必要であると想定して、別々にテストする必要がある2つの動作.
# When first opened, the initial selection does not match the current system state.
Given that the current system state is C
When I load the state-selection screen
Then option C should be pre-selected
アイデアを得始めましたか？誤解しないでください、これはハードワークです。しかし、アジャイルであることは、人々が思っているよりもはるかに規律があります。 ISO 9001認定を取得して保持する場合は、自分に適した分野を決定し、それに準拠する必要があります。これが手間がかかる場合は、おそらく機能仕様に戻る必要があります。
さて、アジャイル/スクラムがISO 9001のようなものとどのように関連するのかと思います。ISO9001はドキュメントとプロセスを念頭に置いており、 アジャイルマニフェスト は実用的なソフトウェアを念頭に置いています。ドキュメント/ドキュメントを評価しますが、焦点は通常、十分です。
これの背後にある理由は、それをすべて書き留めることができ、それを実装してから1週間後に、顧客が自分の考えを変える可能性があることです。もちろん、ドキュメントの同期を保つことができますが、しばらくすると、ドキュメントに多くの労力と時間が費やされていることに気付くでしょう。
このすべてのドキュメントの付加価値は何ですか？ソフトウェアがクライアントの希望どおりに機能しない場合は、クライアントに通知する必要があります。これは、VersionOne、TFSなどのシステムに組み込んで後でフォールバックすることができますが、このすべてのドキュメントでは、遠くに行くことはお勧めしません。
そのままのアプリケーションが、重要なはずです。特定の文書が言うことではありません。
これは、アジャイルが変化を受け入れ、ソフトウェアが絶えず変化し、固定することができないという事実を認めるためです。
Henrik Knibergによる「スクラムとXPトレンチから）」をお勧めします。ログインすると、InfoQで確認できますが、入手可能です こちら 。
あなたの例では、スプリント後にウィジェットを顧客にデモすると思います。彼はそれが彼が望んでいることをしていないことを見て、これを指摘するでしょう。これは、顧客があなたが行った作業を受け入れるか、受け入れない瞬間です。彼はまた、次の優先事項は何かを指摘することができます。おそらく、彼は最初に他の優先事項を持っています。または彼はあなたがそれを修正しなければならないと言うかもしれません。
次のデモでは、ウィジェットが期待どおりに動作するのを見て、そう言うかもしれません。
たぶん、これをある種の会議メモに書き留めることができます。しかし、結局のところ、私はまだ批判的であり、ISO 9001の付加価値について尋ねます。そのために、より高速で効率的な方法でより優れたソフトウェアを構築しましたか？それとも、ドキュメントとプロセスの大きなデータベースがあり、俊敏性を妨げていますか？
とにかくISO 9001認定が必要だと思います。アジャイル開発では、常にプロセスを変更することをいとわないので、プロセスをできるだけ文書化しないことをお勧めします。常に前進するための最良の方法を求めています。常に自分を批判している（これが回顧展の目的です）。