問題タブ [methodology]

私たちは、機能的に複雑な製品を開発している 3 人の開発者 (2 人は経験豊富ですが、この特定のビジネス セクターでは新しい) の小さなチームです。私たちはスクラムを使用しており、各スプリントの終わりにデモを行います。機能チームが多くのアイデアを持っていることは明らかですが、これらは開発チームに十分に伝えられておらず、デモは答えよりも多くの質問を提起しています.

機能的な人々からの入力の質を改善するための推奨事項はありますか?

詳細情報:問題の一部は、仕様やユーザー ストーリー自体がないことだと思います。個人的には、彼らはある種の要件を書き留める必要があると思います。どのようなものを書き留めるべきで、アジャイル プロセスを考えるとどのくらい複雑になるのでしょうか?

私の組織では、反対の証拠があるにもかかわらず、人々は軽量 CMMI は神話であると信じています。軽量 CMMI の経験は何ですか? あなたはそれをやったことがありますか？

スプリントのチーム ベロシティを計算するためのアドバイスが必要です。

私たちのチームは通常、約 4 人の開発者と 2 人のテスターで構成されています。スクラム マスターは、すべてのチーム メンバーがベロシティの計算に平等に貢献する必要があると主張しています。つまり、スプリントでどれだけのことができるかを計算するときに、開発者とテスターを区別してはなりません。スクラムによると正しいですが、ここに問題があります。

反対の提案にもかかわらず、テスターはテスト以外のタスクを手伝うことはなく、開発者は開発以外のタスクを手伝うことは決してありません。また、さまざまな提案にもかかわらず、テスターは通常、各スプリントの最初の数日間、何かをテストするのを待っています。

その結果、通常、スプリントで実際に処理できる能力よりもはるかに多くの開発作業を引き受けることになります。たとえば、開発者はベロシティの計算に 20 日間、テスターは 10 日間貢献する場合があります。ただし、スプリント計画の後にタスクを合計すると、開発タスクは最大 25 日、テスト タスクは最大 5 日になります。

皆さんは、このような状況にどのように対処していますか？

私の会社では、各開発者が自分で作業するプロジェクトを与えられているため、チームワークはほとんどありません。私はこのようなソフトウェアを、優れた開発方法論の規律なしで 1 年間構築してきました。結果は問題ありませんでしたが、次のプロジェクトでは、より本格的な開発アプローチを変更して使用したいと考えています。

自分でソフトウェアを開発するためのベスト プラクティスは何だと思いますか? ソフトウェア開発でよくある落とし穴を避けるために、どのような方法論を使用できますか? どのソフトウェア開発モデル (冗談ですが、ウォーターフォール、エクストリーム、アジャイルなど) が自分に最も適していますか?

より良い開発者になる方法を学べるリソースやチュートリアルを教えていただければ幸いです :)

ありがとう。

これは、皆さんがよく知っていると確信しているシナリオです。

1. あなたの顧客はかなり「無干渉」で、最善を尽くしても意思決定にあまり関与したくないと考えています。

2. 経験豊富な開発チームは、問題に対する特定のアプローチの長所と短所について何時間も話し合い、より明白なアプローチの落とし穴を回避する洗練されたソリューションを考え出します。

3. 顧客は、一目見ただけで、変更してほしいとさりげなく言います。彼らは、慎重に考え抜かれたアプローチで回避しようとしていたユーザビリティや一貫性の問題をすべて理解していません。

4. 説明にもかかわらず、お客様は興味がなく、変更を望んでいるだけです。

5. あなたはため息をつき、彼らが求めることを実行します。次に何が起こるかを十分に知っています...

6. 3 週間後、顧客はこの方法ではうまく機能していないと言いました。変更できますか? あなたが元のソリューションを再度提案すると、彼らは熱意を持ってそれを受け入れます。彼らは常に一種の選択的健忘症を持っていたようで、そもそもこれを台無しにするという彼らの役割をブロックしていました.

あなたの多くがこれを経験したと確信しています。私がいつも気になるのは、かなり頭脳明晰で有能な人々が問題を本当に理解し、良い解決策を考え出すために費やした時間と労力を知っているときです. フラストレーションは、これとは対照的に、顧客の選択は何気なく見ただけで 3 分で行われるという知識とは対照的です (さらに悪いことに、プロジェクトが実際に何であるかさえ知らないことが多いマネージャーによって)。ケーキのアイシングは、通常、1 日の非常に遅い時間に作られることです。

アジャイルの方法論がまさにこの種の問題を解決するように設計されていることは知っていますが、特定のタイプの顧客 (通常は他人のお金を使う人々) が与えることをいとわないという点で、ある程度の顧客の購入が必要です。

あなたがこれにどのように対処するかについての賢い洞察はありますか？

編集: おっと-ちなみに、これは現在または最近の顧客について話しているのではありません。あくまでも仮説ですが…

更新：開発の観点からこれを求めていますが、説明のために、頭に浮かぶ標準的な非開発の例は、99％の稼働率を維持するためにたとえば10,000ドルかかる場合、理論的には100,000ドルかかる可能性があるということです99.9％のレートを維持するために、そしておそらく99.99％のレートを維持するために$1,000,000。

0に近づく微積分のように、100％に近づくと、コストが指数関数的に増加する可能性があります。したがって、開発者またはPMとして、時間と金銭的な制約を考慮して、成果物が「十分に良い」とどこで判断しますか。たとえば、99％、99.9％、99.99％で良好なROIを取得していますか。

開発の確かな指標がわからないため、開発以外の例を使用しています。たぶん、上記の例では、「稼働時間」を「ファンクションポイントと欠陥の比率」、またはコードの複雑さに対するバグのそのような合理的な測定率に置き換えることができます。また、ソフトウェア開発ライフサイクルのすべての段階に関する意見を歓迎します。

従来のプロジェクトの三角形の制約（品質、速度、コスト）を念頭に置いてください。そして、顧客が当初の予算で提供できる最高の品質を望んでいると仮定しましょう。

Martin Fowler による技術的負債、Steve McConnellによる

YAGNI (You Ain't Gonna Need It)ウィキペディアより

ウィキペディアによるBDUF (Big Design Up Front)

更新：質問を明確にするために、このように述べて、私の意味を維持することもできると思います：

「あなたは、アジャイルの実践者として、各イテレーション内で、「クイック アンド ダーティ」(YAGNI に準拠しようとして意図せずに技術的負債を負う危険を冒すこと) とオーバーエンジニアリング (BDUF) の間の適切なバランスをどのように見つけますか?

適切なライフサイクルと方法論を選択することは、それほど多くの方法論がなかった以前ほど簡単ではありません。今日では、新しい方法論が毎日出現しています。

ほとんどのプロジェクトには一定レベルの進化が必要であり、各プロジェクトは他のプロジェクトとは異なることがわかりました。このように、エクストリーム プログラミングは、従業員 15 人の特定の会社のプロジェクトでは機能しますが、従業員 100 人の企業ではうまく機能しないか、特定のプロジェクト タイプ (たとえば、リアルタイム アプリケーション、科学的アプリケーションなど) では機能しません。 .

主に、プロジェクトの種類、プロジェクトのサイズ (それに取り組んでいる人数)、プロジェクトの時間 (実際または計画)、プロジェクトのライフサイクルと方法論、およびプロジェクトが成功したか失敗したかを示す、経験のリストが欲しいです。 . 十分なデータがあれば、いくつかのパターンを見つけることができると思います。もちろん、コメントも大歓迎です。

• PS: 非常に大きい、PT: 非常に長い、LC: インクリメンタル CMMI、PR: 成功
• PS: 非常に大きい、PT: 非常に長い、LC: Waterfall-CMMI、PR: 成功

編集：すべての回答の統計を含む「要約」を作成します。

メソッド プラグインにカスタム カテゴリ (「分野」) があり、既存の分野 (スクラム プラグインと EPF OpenUP ライブラリから) を含めるために使用したいと考えています。 OpenUPのもの）。それらを簡単に追加し、必要に応じて並べ替えて、[ブラウジング パースペクティブとプレビュー] タブで表示できます。

ただし、公開すると、追加または拡張した分野が表示されません。パブリッシュ ログにエラーはなく、他のことを参照した警告もありません。

私はこれを行うための最良の方法は何であるかを尋ねるつもりでしたが、それが必要であるかどうかさえ尋ねるべきであると決めました。私はそれがJSP開発で行われるのを見たことがありませんが、それはで一般的な慣行のようPHPです。これの背後にある理由は何ですか、そして私がこれから保護しない場合、私は他に何を考慮に入れるべきですか？