重要！
- 記事には一定量の皮肉が含まれています。
- 記事が誰かの利益を侵害することは一切ありません。
- この記事では、SCRUMの滝とは対照的でなく、「ソフトとウォーム」を組み合わせていません。
- 誰もが、プロジェクトの開発プロセス、その経験またはその欠如、満足しているクライアント、または失敗したプロジェクトについて独自の意見を持っています。
- 優しくしてください！
スクラムはもちろん、スプリントの明確な一連のタスクがあり、チームの精神が際限なく高められ、クライアントがスプリントの代価を払っている場合に適しています。彼はすでにこれに慣れており、会社は収入を得て、プロジェクトが終了しないと信じています。
滝も素晴らしいです。クライアントは特定の予算に収まるものを明確に知っており、すべてのステップは細部までレイアウトされていますが、クライアントがプロジェクト内の何かを変更するか、プロジェクトが望ましい場所に進んでいないことを理解するまで。
クライアントがコストを明確に知りたい、チームがプロジェクトの進行に影響を与えたい、そして会社が収入を一貫して受け取りたいという状況では、マネージャーはこれらすべての要件を操作し、適切な方法、方法、原則、ルールを選択する必要があります。
だからこそ、方法論、ルール、原則を混ぜる傾向をたどることができます。
顧客について話しましょう
原則として、彼らは初期の計画予算に収まり、プロジェクトの結果を定期的に確認し、プロジェクトのコースに影響を与え、製品に変更を加えたいと考えています。
私たちと一緒のプロジェクト全体の固定予算は、例として、ウォーターフォールモデル、製品に影響を与え、変更を加える能力が柔軟な方法論で広く表現されていることを想定しています。
フランケンシュタインのクライアントにとって、このような非常に優れた方法論と管理アプローチが判明しています。
プロジェクトチーム向け
最も興味深いのは、改善の提案ができるプロジェクトです。 製品開発に参加する。 そのため、ブレーンストーミングの過程で、新しい便利なオプションを考え出すか、興味深いテクノロジー/プログラミング言語を使用できます。 このような作業では、創造性と高いリスクが絡み合っているため、固定予算はここでは適切ではなく、想像の範囲を絞って制限するのは大きな負担になります。 チームは時間と材料に基づいて作業し、開発がより便利になる順序でタスクの優先順位を選択します。 この柔軟なアプローチにより、新しい顧客の希望は非常に簡単に受け入れられ、タスクの優先順位が変わります。
企業向け
私の意見では、興味深い滝のモデル。 このアプローチでは、プロジェクトの開始時に、すべての要件が交渉および文書化され、フレームワークが設定され、プロジェクトの目的が明確に表示され、要件を受け入れ行為と簡単に比較できます。 最小限のサプライズ、最小限のリスクを得ると同時に、明確に定義された日付と予算を取得します。 そのようなモデルを使用すると、注文が増え、会社は次のトランシェの受領をより自信を持って予測します。
マネージャー向け
設計作業の観点から、理想的なモデルはウォーターフォールモデルです。 ここで最初に、製品を文書化し、すべてのリスクを予測し、すべてが計画どおりに進行するように制御する必要があります。しかし、チームワークの観点から、私は創造的であり、プロンプトを出し、経験を共有し、コースを変更します。 チームディスカッション、ブレインストーミング、毎日の集会、変化する製品-これらすべてがアジャイルの哲学を可能にします。
次の場合の状況ですべきこと：
-プロジェクトの開始時に詳細な分析を行う時間がないか、資金が割り当てられていません。
-契約で規定された厳格に固定された予算と納入段階があり、
-プロジェクトの過程で、製品の2番目のバージョンに転送できない新しい希望が発生し、他の計画外のタスクが表示されますか？
混ぜる！
あなたは滝で作業することができますが、操縦のための予算を残します。 このモデルでは、製品の基本機能に基づいて契約が作成され、追加の契約の助けを借りてプロジェクトの範囲を変更できます。 したがって、開発プロセス中の固定予算と製品へのイノベーションの追加のタスクは解決されます。
SCRUMで作業できますが、スプリントの固定セットを使用します。 このモデルは、製品の開発状況を確認して変更し、同時に予算内に収めたい場合に適しています。 スプリントの前に、タスクが選択、評価され、費用の見積もりがクライアントに提供されます。 この見積もりは承認されて機能し、変更は次のスプリントに転送されます。変更が8時間であれば、同じ時間数の他のタスクはプロジェクトから削除されます。 ここで、チームはタスクセットで効果的に作業でき、クライアントはスプリントにタスクを書き込むことでプロセスに影響を与え、クライアントは自分の予算を管理します。 この場合、機能が切り捨てられていても、製品が出てきます。
クライアントが月ごとに一定額を支払い、チームが月ごとに異なる数のタスクを処理するアプローチがあります。 つまり、 クライアントはチームをレンタルします 。 彼は彼らに一週間のタスクを埋めるか、またはタスクを全く準備しないかもしれません、そして、チームは月単位で合意された量を受け取ります。
このアプローチは、技術サポートプロジェクトに必ずしも適用されるわけではなく、製品開発にも適しています。
クライアントにとって、このアプローチは固定費であり、チームのロードに高い関心があることを意味します。 そのようなサービスを提供する会社の場合、従業員の雇用を保証し、予算を安定的に補充します。
結論として、私はすべての会社、クライアント、プロジェクトがユニークであると言いたいです。 既存のアプローチはいずれもプロジェクトに適している場合があり、そうでない場合は、独自のアプローチを考え出し、それを実装できるパートナーを見つけます。
あなたの経験を聞きたいのですが、1つの方法論/方法論の枠組み内でのみ働くことができますか？
古典的なカスケードモデルに従って作業した場合 、コンセプト/ TK /作業ドラフト/仕様/その他を作成し、ガントチャートを作成し、ウォーターフォールスキームを作成し、リスク登録簿を提供し、いわゆる「範囲外」を実施し、計画された作業が終了した後にのみ彼は、計画された予算と期限を満たし、クライアントはプロジェクトに満足しました。 あなたは細心の注意を払ったマネージャーであり、一方の身体の敏感な部分と他方の鉄の部分を使用して、プロジェクトの進捗を確認し、チームとクライアントの両方との合意を守るのに役立ちました。 「ウォーターフォール！」というコメントを書いてください。国はヒーローを一目で知る必要があります。
プロジェクトにアジャイルのアジャイル開発モデルを選択した場合、メールパスワードよりもアジャイルマニフェストの方が優れていること、チームが高度に組織化されていること、クライアントがイテレーションからイテレーションまでの結果に満足していること、魚のように感じること水中で、私はコースを見出し、あなたは若い！ あなたは柔軟な心、驚くほど速い反応、低い慣性、高いおしゃべりを持っています。 あなたは非常に多くのことを伝えています。 コメントに「アジャイル」と書いてください（全員に知らせてください。柔軟に作業でき、成功します！）。
方法論とテクニック、原則とルールを組み合わせて成功した場合、どうやってそれを行うかを全員に伝えてください
厳密に1つの方法/アプローチ/方法論のフレームワーク内で作業できないのは何ですか？ 顧客はそれほど違いますか？ 状況？ マネージャー？ 設計の決定？ 企業はどのように働いていますか？ 不快感と制限はありますか？