機能仕様を開発するための共同ツールを探していました。私は次の能力を探しています：
私の最初の印象は、wiki を使用すると、このタスクに適したツールになる可能性があるということです。wiki を使用して機能仕様を作成した経験のある人はいますか? 要件管理ツールとは対照的に、このようなツールを使用することの長所と短所は何ですか?
ご意見をお待ちしております。
ウィキを使用しているにもかかわらず、あなたが説明したことを実行して、共同で要件を開発することは可能です。ウィキ パラダイムは、このプロセスを支援するものではありません。
Zend Framework プロジェクトで wiki を管理し、コンポーネントの提案を追跡しました。 彼らはまだそれを使用しています。 提案は機能仕様とは異なりますが、使用法はご質問と十分に類似しており、関連性があると思います。
ウィキはそれ自体を処理しません。それを管理し、ある程度の構造と一貫性があることを確認する責任者がいなければ、すぐに混乱してしまいます。現実世界で例えれば、各チームに白紙の用紙を渡して、要件の自分の部分を書き出すように指示します。これに関する問題は次のとおりです。
それを機能させる方法は、プロジェクトに何らかのプロセスを適用し、そのプロセスに従って wiki を使用することです。
「要件管理ツールとは対照的に、このようなツールを使用することの長所と短所は何ですか?」
素晴らしいアイデアのように思えますが、あなたが遭遇するのは、書くことができない、あるいは書くつもりのない人々です。
書けない人は -- まあ -- 書けない。彼らは、電子メール、ウィキ、または音声以外のメディアと通信することはできません。
「まとまりがない」人もいます。実際、書くことは直線的すぎて、直線的に考えることはできません。
一部の人々は、「あなたの聴衆に書く」ことを理解できず、理解できないものを書きます。
彼らが何について話しているのか、ましてや彼らが何について書いているのかさえ理解できないこともあります。彼らは専門用語やコードで話します。彼らはあまり知りませんが、聞くことを主張します。
書かない人もいます。
約束をすることを拒否する人もいます。撤回できるwikiでも。彼らは、すべてを事前に話し合う必要があると感じています。
誰かに指示を与えてすべてを行う習慣がある人もいます。彼らは自分自身のために文章を書かないか、人々をオフィスに立ち回らせて、話したりタイプしたりするのを聞いてもらいます。
一部の人々は、一般的にあらゆる種類のプロジェクトで有毒です。彼らは土壇場で新しい要件を生み出します。彼らの最初の反応は、「それは決してうまくいかない」です。彼らはブレインストーミングが苦手です。彼らがそれがうまくいくと言って、あなたが彼らに改善を求めたとき、彼らはそれを持っていません. 彼らはそれがうまくいかないことを知っているだけです。
私の経験では、Wiki をうまく使用できるのはプログラマだけです。そして上級レベルのプログラマーのみ。
N00bz には、噂や経営陣の浮気から設計の要件を整理するのに十分な経験がありません。
N00bz は、常に明確に書く言語スキルを持っているわけではありません。最終的にはそうなるかもしれませんが、彼らの Javadoc コメントを一目見れば、彼らが執筆の「明確さ」の部分に苦労していることがわかります。
とても魅力的です。一人の人が全員にインタビューして物事を書き留める従来のアプローチよりも多くの利点があると思うので、人々が wiki を上手に使えるようになることを願っています。しかし、それには、ほとんどの人が持っていないように見えるレベルの自信とコミュニケーションのスキルが必要です.
FogBugzの調査を検討してください。彼らは、プロジェクト管理のための最高の最高のものとして自分自身を宣伝しています。ジョエルの歴史を考えると、私は彼らに疑いの利益を与えるでしょう。彼らはあなたが今説明した方法でウィキを使用します。
真面目な方は、無料トライアルにサインアップすることをお勧めします。プロジェクトのサイズによっては、それを購入することは非常に良いオプションかもしれません。
少なくとも、彼らがそれをどのように構成しているかを見るか、フォーラムを読んで、独自の簡略化されたバージョンを作成する方法についてのアイデアを得ることができます。
専門的なツールは、物事を順調に進め、固定されたワークフローを導入するのに役立ちます。これは一種のポイントであり、物事を集中して機能的に保ちます。Wiki のような一般的なツールを使用することは、多くのプログラマーにとっては素晴らしいことかもしれませんが、「混合モード」の作業用に Wiki を導入するのは良くないかもしれません:
ベースキャンプのようなものを見てください。それらは、応用されたウィキ、または共同ツールと考えることができます。特定の目的のための汎用ツールには改良が必要です。MediaWiki や他の人が物事を整理して集中するのに十分なカスタマイズを行っているかどうかはわかりません。
要件管理ツール (再帰的であることはわかっています) の要件と、wiki 文化とオープン コミュニケーションの考え方からどのような側面 (コミュニケーションの側面) を取得できるかを収集することもできます。要件管理ツールも wiki も要求に合わない場合は、作成することを検討してください。次の大物かもしれません。Bugzilla の代わりに wiki を使用できますか?と言っているような気がします。
さまざまな役割の人が見て理解できる、オープンなコミュニケーションを重視した要件管理用の固定ワークフロー Web アプリケーションが良いかもしれません。
TWiki を使用してきましたが、現在はそのコンテキストで FosWiki を使用しています。無料で入手できるものはたくさんあります (バージョン管理、アクセス管理、Web ベース アクセス、検索、リモート管理、セキュリティ パッチなど)。数分で、以下を定義できます。
もちろん、途中でハイパーリンクや Wiki リンクを簡単に使用できます。FosWiki には、必要に応じて特定のワークフローを強制するために使用できる機能もあります。ユースケースやその他のパラダイムのフォームをサポートすることも簡単です (過去にこれを行ったことがあり、一般的にうまく機能しています)。
FosWiki などの Wiki は拡張可能であり、トレーサビリティ管理と影響分析、要件の表ベースの変更、全体的なパッケージングなどに関連する弱点に対処するためのさらなるモジュールを開発できます。
これは今では少し古いかもしれませんが、私は現在 Atlassian の「Confluence」を使用しています。私は現在、アジャイル プロセス内で「プロダクト オーナー」の役割を果たす UX エンジニアとして働いています。個々のインターフェイスの要件を文書化し、複数のユーザーのフィードバックとコメントを許可し、より大きなコンテキスト (ユーザー ストーリーなど) 内で各インターフェイスを他のインターフェイスと結び付けることができます。すべてが非常に動的で、テンプレート主導です。それは私の現在のニーズに非常によく合っています。