締め切りはアジャイルですか？

明確にするため、締め切りは次のとおりです。

制限時間または期限は、目標またはタスクを達成する必要がある狭い時間フィールドまたは特定の時点です。

^{ウィキペディアから}

私のソフトウェア開発のキャリア全体で「アジャイル」を行ってきましたが、これはどこでも、少なくとも次のプラクティスが順守されていることを意味しているように見えます。

• 毎週または隔週のスプリント
• 回顧スプリント計画
• 製品の所有者
• スクラム
• ユーザーストーリー

しかし、私がこれまでに行ったすべてのプロジェクトは、期限を設定することを主張しています。アジャイルが適応計画、柔軟性、変化に焦点を合わせようとしていることを考えると、締め切りはアジャイルですか？

私の意見では、納期が柔軟性の欠如と品質の欠如につながるため、そうではありません。代わりに、スプリントと早期納品に集中するほうが価値があると思います。しかし、私が参加したすべてのサークルで、そうではなく、締め切りはアジャイル開発と連動すると見られています。

締め切りは現実です。ほとんどの場合、特定の日付までに何かを持っている必要があります。やむを得ない。期限がなければ、アジャイルプロジェクトでさえパーキンソンの法則に屈する可能性があります。

作業は、完了に使用できる時間を埋めるように拡張されます。

言い換えれば、あなたのプロジェクトが永遠に続くことができれば、そうなります。

期限に関連して、アジャイルはいくつかのことをしようとします：

• 締切までにどれだけの作業が行われるかを全員が常に確認できるようにする
• 最も重要な機能が最初に完了することを確認してください
• まだ完了していない機能に依存しないという意味で、完了した機能が使用可能であることを確認します
• 開発が持続可能なペースで継続されるようにします

こうすることで、避けられない日が来ると、無駄なコードの山はなくなりますが、未完成の重要性の低いものだけを使用したテスト済みの機能する製品になります。そして、完成品に誰も驚かない。

あ、はい。「アジャイル」と「デッドライン」は完全に互換性があります。

締め切りは人生の事実です。非常に確固たる日付を持つものがあります。

Comdexのソフトウェアが必要です

または

ゲームはブラックフライデーまでに店頭で販売する必要があります

など。ComdexやBlack Fridayを延期することはできません。他の地域はそのようには機能しません。

アジャイルの目標は、期限に間に合わないものがより早く失敗することです（そしてそれは良いことです）。よりタイムリーに。

締め切りは厳しく定められた厳しい日付です。アジャイルは、ソフトウェアが当初の期待通りに開発に2倍の時間がかかることをサイクルの早い段階で実現できるツールです。プロジェクトマネージャーがこれらの問題を後よりも早く実現できることが重要です。これにより、リソースを追加したり、スコープを変更したり、期限を調整したり（確固たる期限ではなく会社である場合）、プロジェクトキャンセル。

アジャイルが求める透明性は、サイクルの早い段階で問題と進歩を示すことです。古典的な滝の配達の失敗は、あなたが密室で何ヶ月も費やし、期限の1週間前に製品を配達し、あなたがそれをすべて間違っていると言われ、あなたが数ヶ月を無駄にした（そして今、期限を完全に破った）ものです。もう1つの古典的な滝の失敗は、まだ数か月先の締め切りの1週間前を見つけることです。アジャイルは、これらの問題をプロセスの早い段階で知ろうとしています。

アジャイルが締め切りのコンテキストで実行しようとするもう1つの部分は、合意された機能の一部のみが（何らかの理由で）完了した場合でも、ソフトウェアの現在のバージョンは有用で展開可能であるということです。

わかりました。4月15日に税務ソフトウェアを導入するために必要なものがすべて揃っていませんでしたが、昨年11月に開始して以来、75％の実績があり、機能しています。12月中旬以降、完全な機能セットを展開できないことがわかっているため、顧客ベースの80％に努力を再集中しました。

いくつかの期限を守らなければなりません。契約上の義務、規約、規制要件。一部は、ソフトウェア開発をスプレッドシートの製造と同じチャートに配置できるようにしたいマネージャーによって課されます。原因が何であれ、ほとんどの人は逃げることができません。

機能しているチームで作業している場合、開発者と管理者/利害関係者とのコミュニケーションは、決定を下す必要のある人々に十分な情報を得て、期限を逃すか、開発を続けることがより重要かどうかを決定することを意味します。

完成したユーザーストーリーを週に1回、または月に2回配信している場合でも、おそらく期限があります。人が近づいてきたら、利害関係者が期限までに何が収まると思うかを知って、期待を設定してください。

あらゆる段階で現在必要な要件を満たして、最善のソフトウェアを絶えず構築している場合、スプリントの終わりの締め切りは理論的には問題になりません。実用的には、これは通常そうではありませんが、薄い空気から出て来るデッドラインもそうではありません。私がこれまでに与えられた最も重要な期限は、ずっと前に私に伝えられました、それは問題であった品質と機能の期待でした。

見逃しても結果をもたらさない任意の期限はあまり機敏ではありませんが、開発チームの管理期限外の理由で期限を設定して維持しなければならない状況があります。幸いなことに、期限が妥当であれば、方程式を逆にしてアジャイルな方法で期限を処理する方法がたくさんあります。

締め切りは常に間違っているとは限りません。私たち全員がオビ=ワンから学んだように：

「シスだけが絶対的に対処する」

ほとんどの場合、期限はばかげており、不必要であり、確かにアジャイルではありませんが、これは常に事実であると言うのは馬鹿です。architypalのケースは、選挙追跡ソフトウェアなど、時間に敏感な使用に必要なソフトウェアです。選挙に間に合うようにソフトウェアの準備ができていない場合、選挙を延期することは賢明でも実用的でもありません。あなたが私たちに支払っているこのソフトウェアは完全に価値がないことは知っていますが、期限はアジャイルではありません。

時間に敏感なものを求めて顧客にそれを突き出すように伝えることはあまりアジャイルではありません。そして結局、誰かがこれらのものを構築しなければならないでしょう。では、どのようにして顧客を満足させ、時間に敏感なものに対して一見合理的なソリューションを提供することができますか？さて、ソフトウェアの開発に不確実な時間がかかり、期限が可変でない場合、その不確実性を処理するために他の何かが可変でなければなりません...

納期が一定に保たれている場合、他の側面が変数になります。誰もが知っているように、ソフトウェアプロジェクトには多くの不確実性があります。プロジェクトを成功させるには、この不確実性に対応して何かを可変にする必要があります。通常は納期です。とにかく、それは十分に自然なようです。しかし、それはあなたの唯一の選択肢ではありません。厳しい締め切りに間に合わない場合、それを処理する方法は、提供される機能を可変にすることです。機能のリストに優先順位を付け、その日までに配信できる機能の量に不確実性があることを明確に伝えます。最も重要な機能が出荷される可能性が高くなるように、これらの機能に優先順位を付けるために顧客と協力してください。それから、通常通り、締め切りが来たときのみ、出荷の準備ができているものを出荷します。このモデルでは、

誰かが期限を設定したい場合、それは問題なく、期限は修正できますが、彼らが理解しなければならないのは、期限が修正された場合、スコープは柔軟なままでなければならないということです。

tl; dr

理想的な世界では、締め切りはなく、準備ができたら物を届けるだけです。しかし現実には、物事にお金を払っている人は通常、自分がいつ終わったかを知りたいと思っています。アジャイル方法論はこれを認識しますが、すべてを結びつけることができるわけではないことも認識しています。

これにより、製品に適したレベルで配信品質を維持できます。締め切りと範囲（および予算）を修正すると、物事が急ぎ過ぎて、プロジェクトの終わりに狂ったクランチタイムで古い滝の世界に戻ってしまいます。開発者とテスターを追加しても問題を迅速に解決できないため、予算を増やすことは通常、答えではありません。それはよく知られた見方であり（そして私は経験からそれに同意します）、より多くの人を追加する（それぞれが自分の脆弱性を持つ）ほど時間がかかります。

さて、通常（彼らが本当にアジャイル手法を理解していない限り）ソフトウェアの代金を支払う人は言われることを好まないので、私たちはあなたの締め切りに間に合うことができますが、あなたが望むすべてをすることはできません。これは、ソフトウェアを構成する機能に優先順位を付けることで管理できます。優先順位の議論は次のようになります。

開発チーム（D）：「最も重要なものを最初に、配信したい機能に優先順位を付けてください」

顧客（C）：「すべてが優先度1です。来月の終わりまでにすべてを完了してほしい」

D：「それは可能かもしれませんが、要件が変更されたり、開発中に予期していなかった問題を発見した場合は不可能かもしれません。」

C：「もしも​​っとお金をあげたらどうだ？」

D：「ため息をつく ...リソースが増えたとしても、実際に軌道に乗るのに1ヶ月かかるだろう。だから、機能の優先順位を決める方法がわからない場合は、最初にやりたい機能を教えてくれ」

C：「わかりました。大きなボタンが欲しいのですが、本当に大きくして、それから...など」

これで、優先度順に機能を使用して作業を開始できます。また、優先順位の低いアイテムをチームで先読みし、いくつかの早期の見積もりを行うことも役立ちます。詳細については、開発に着手するときに変更できる可能性があることを知っています。ロードマップをまだ定義していない場合は、これを使用してロードマップを再定義または作成できます。これがリリース計画の基礎となります。ロードマップは、スコープが変更される可能性があることを認めながら顧客と話し合うことができますが、納品する順番はあります。

アジャイルの大きな利点の1つは、開発を経て物事が変化し、そのように調整することを認識することです。従来のアプローチとは異なり、この原則は、通常のスプリントの成果物と顧客との継続的なコミュニケーションと併せて、当然ながら進歩についてより透明性を持たざるを得ないことを意味します。これは良いことです。

顧客は、特定の日付までに必要なものが得られないことを好まない場合がありますが、その理由と、得られるものの品質は良好です。また、機能が提供されてから6か月後、顧客は特定の日付までにあなたが提供したことを気にかけたり、覚えたりすることはなく、彼らはまだ使用している製品の品質を覚えます。

締め切りは伝統的にビジネスのライフサイクルに基づいています。税務ソフトウェアは4月15日までに必要です。次の会計年度の報告は、7月までに行う必要があります。

アジャイルマニフェストの状態：

プロセスとツールを介した個人と相互作用

包括的なドキュメントよりも機能するソフトウェア

契約交渉を介した顧客コラボレーション

計画の変更への対応

締め切りは契約です。彼らは計画です。彼らはあなたのチームの速度に反応しません。3人の最高の開発者を失っても、彼らは変わりません。

期限はアジャイルではありませんが、アジャイルは期限に関するフィードバックを提供してくれます。アジャイルでは、機能がカットされない限り、速度によって期限を設定できない場合があります。また、期限を設定するために雇用する必要があるかどうかもお知らせします。また、場合によっては、カットする機能が残っていない場合、締め切りが不可能であることをお知らせします。

アジャイルチームができる最善のことは、彼らの速度と優先順位付けされたバックログに納期をかけることです。これにより、配達予定日がわかります。それらが期限外になった場合は、クライアントとの真剣な話し合いの時間であり、期限が実行可能かどうかを判断します。

各スプリントの配達は交渉不可能だと思います。仕事を評価し、その上にカードサイズを配置し、スプリントが終了するまでチームを忙しくするのに十分な負荷をかけます（そしてスプリントは小さくなければなりません-週から月まで何でも）。「納期」は、予想される作業に対する完了した作業の歴史的傾向に基づいている必要があります。アジャイルは、古い「コスト/時間/スコープ」制約のアイデアから何も追加/削除しません。それは、より多くのお金や時間を費やすよりもスコープに対する優先順位付けが一般的に望ましいという理由で、スリッページを管理する好ましい方法としてスコープを単に使用します。

一部の人々は、アジャイルを「ワイルドウェスト」と混同しているようです。アジャイルは、何もうまくいかないという意味ではありません。アジャイルとは、合理的な人がどれだけうまく見積もることができるかについて私たちが嘘をつくのをやめることを意味します。基本的に、ソフトウェア開発は約2〜4週間先まで予測できます。それを超えて、それはすべて盗品と推測の程度が異なります。さらに悪いことに、物事の見積りをさらに将来にわたって提供するコストは、作業を行うだけのコストに近づきます。なんらかの理由で、プロジェクトマネージャーは歴史的に、これらの絶対的な真実を顧客に認めようとはしませんでした。アジャイルは、ソフトウェアエンジニアリングの将来をどれだけうまく予測できるかに限界があると主張することでその考え方を調整し、長期予測の「エビデンスベースの推定」に微妙に切り替えます。見積もることができ、これまで提供してきたものに基づいて、長期的な将来の提供のかなり合理的な見積りを提供できます。

TL; DR

締め切りは[a] gileですか？... [D] eadlinesは[a] gile開発と連動すると見られています。

ここでの多くの回答は、質問の工学的側面に焦点を当てている可能性があります。代わりに、プロジェクト管理の観点からこれに対処します。

期限は、アジャイルの原則に沿っていない多くの事前計画を意味します。代わりに、反復的な開発モデルは、ジャストインタイム計画を含むタイムボックス、リズム、およびリリースサイクルに依存しますが、従来のプロジェクト管理の期限に一般的に関連付けられる「大規模な事前計画」には依存しません。

アジャイル方法論でリリース計画を行うことはまだ可能ですが、計画は通常、フィアットによって設定された管理目標ではなく、目標を達成するために必要な反復回数の推定に基づいています。これは、出荷の日付を設定することができないことを言っているのではないか、目標を満たすことができないこと、しかし、道、彼らが定義され、満たされていることは、従来のプロジェクト管理手法に比べてかなり異なっています。

期限ではなくタイムボックスを考える

しかし、私がこれまでに行ったすべてのプロジェクトは、期限を設定することを主張しています。アジャイルが適応計画、柔軟性、変化に焦点を合わせようとしていることを考えると、締め切りはアジャイルですか？

これは、アジャイル原則の一般的な誤解です。スクラムやかんばんなどのアジャイルフレームワークは、期限に焦点を当てているのではなく、タイムボクシングと持続可能な配信のリズムに焦点を当てています。

たとえば、スクラムでは、スプリントは「期限」ではありません。これは、チームが時間枠内に収まると見積もる作業量でいっぱいになる時間枠であり、時間枠が期限切れになると「完了」または「未完了」のいずれかになります。一度なくなると、タイムボックスは永遠に消えます。行われていない作業は、プロジェクトの当時の（歴史的ではなく）ニーズに基づいて、同様に一時的な新しいタイムボックス内で再計画および再評価する必要があります。

タイムボックスの重要性は、利害関係者が進捗を確認する予測可能なリズムと、潜在的に出荷可能な価値の増分を提供するチームの持続可能なペースの両方を作成することです。作業はインクリメンタルであり、リズムに従います。したがって、大きな前払い期限の概念は、アジャイルの原則と一致していません。

タイムボックスに基づいたリリース計画

おそらく、アジャイルプロセスを従来のフレームワークにマッピングするのが最も難しいのは、リリース計画です。リリース計画には、多くの場合、固定スコープまたは固定日付の成果物が含まれます。アジャイルフレームワークでは、リリースの計画は通常、スコープが可変変数として明示的に定義されている推定プロセスを通じて行われますが、リリース日は反復で推定されます。

たとえば、プロジェクトは、20回の反復の終了時にプロジェクトのv1.0のリリースにコミットする場合があります。リリースされる範囲はプロジェクトの存続期間を通じて変化する可能性があります（範囲、機能、優先順位はすべてのスプリントの開始時に変更される可能性があります）が、各リリースの目標日はプロジェクト計画で固定されています。チームは、各スプリントごとに出荷可能な可能性のある増分を提供するよう努めており、定義の完了には、各スプリントの終了時にプロジェクトがリリース可能な状態にあることを確認するための継続的な統合などの品質チェックが含まれています。

スコープが固定されているアジャイルプロジェクトが表示される場合がありますが、スコープはアジャイルプロジェクトの可変変数であるため、各反復のスコープがプロジェクトの進化するニーズに合わせて調整、変更、または適応されると、リリース日が時間とともに変化する場合があります。アジャイルチーム、特に経験の浅いチームには固定スコープのアプローチをお勧めしませんが、正しいアプローチである場合があります。

こちらもご覧ください

• アジャイルリリースプランニングの実行方法

期限をコミットメントと考えてください。プロジェクトがアジャイルであることは、特定の日付に特定の機能を提供することをコミットしてはならないという意味ではありません。

アジリティがもたらすのは、その間に起こることです。特定の日付にサブ機能B、C、D、Eで構成される機能Aを提供することを定義する厳密なソフトウェア要件仕様書を用意する代わりに、特定の日付に機能Aを提供することを約束します。初期段階では、あなたもあなたの顧客も機能がどのように見えるかを知らないか、サブ機能B、C、DおよびE、あるいはBとC、または他の多数のサブ機能を持つでしょう。

以前に小企業にのみ商品を配送し、大企業と契約を結んだばかりの会社を想像してください。この大企業はEDIFACTを使用していますが、会社で使用されている現在の会計ソフトウェアはEDIFACTを処理していないようです。あなたは契約、あなたの会社は4月15日のために準備する必要がありますことを考えると、それを行うプラグインを作成するように要求している^目。

俊敏性は、中間ステップが段階的に提供され、定期的なフィードバックに基づいていることを意味します。基本的に、会計士に進捗状況を示し、彼らはそれについてどう思うか、考えられる問題は何かなどを教えてくれます。これはまた、元々、会計士は、彼らが考えて改善できる素晴らしいアイデアを持っていたことを意味します実質的にユーザーエクスペリエンス。3週間後、それほど改善されていないだけでなく、1か月の追加開発が行われるように見えました。アジャイルのおかげで、この機能から他の何かに努力を向けることができ、時間通りに納品できます。

また、顧客の視点を理解する必要があります。

• 多くの場合、企業には特定の納期が必要です。たとえば、オリンピックの終了後にオリンピックのオンラインストリーミングサービスを提供することはできません。ビジネス面では、これは単なる失敗であり、大きなマイナスの結果をもたらします。

• コミットメントがなければ、開発者または下請け業者が完璧主義者になるか、プロジェクトの優先度を低くするのは魅力的です。スプリントの規則性は役立ちますが、このリスクを完全に防ぐわけではありません。

  特に締め切りが非常に簡単に起こるため、私はその締め切りが好きではありませんが、多くの企業がそうする理由を今でも理解しています。スプリントだけを見ると、プロジェクトが予定より遅れていることを確認するのは必ずしも容易ではありません。このコンテキストでは、期限を逃すと、何かが制御不能になり、今すぐ対処する必要があることを明確に思い出させることができます。

eXtreme Programmingはリリース計画について述べています：

リリース計画の基本的な考え方は、プロジェクトを4つの変数（範囲、リソース、時間、および品質）で定量化できることです。

それは公平なようです。また、

4つの変数すべてを制御できる人はいません。あるものを変更すると、それに応じて別のものが誤って変更されます。品質を優れたものよりも低くすると、他の3つの変数に予期しない影響を与えることに注意してください

そして、すでにbr3w5で指摘されているように、リソースの増加は制限されたソリューションです。彼らが何か他のものに派遣された場合、おそらくチームの一部であったカップルを追加することができます。しかし、少なくとも多くの時間を要するチームの再編成なしでは、チームの規模を迅速かつ無期限に単純に増やすことはできません。

そのため、削減できない品質と固定されたリソース：期限が時間の制約になるため、スコープを調整する必要があります。また、アジリティを使用すると、可能な限り最も生産的な範囲で期限を守ることができます。ただし、通常、スコープの一部が時間内に完了することを保証できます。これは、期限を下回って制限される時間を信頼できる形で推定できる部分です。通常、あなたが何回かやってきたことに本当に近く、ほとんど知られていない何か。

ソフトウェア開発方法の目的は、正しく理解されている場合、思考に集中することで生産性を高め、一般的な状況に共通の言語を提供することです。それは、心のコントロールと罪悪感ではなく、インスピレーションと可能性についてです。

妥協のないソフトウェア開発方法に文字通り従うことは、他の文脈における急進主義または原理主義と呼ばれるものに対応します。この異常の純粋な形態は、通常市場で急速な失敗につながるため、実際にはめったに見られません。しかし、もちろん、開発者が特定の方法を実装するという難しいタスクで競う場合、マークをオーバーシュートするのは自然なことです。

この問題は、宣教師と伝道者が主にまだこの方法を使うことを納得させる必要がある人々を主に対象にしているという事実によって悪化しています。そして、たとえ彼らが節度を説いていたとしても、人間の本性はそれがあまり注目されないことを保証します。

締め切りは機敏ではなく、次のとおりです。

1）滝、および2）間違っています。

ソフトウェアと期限は一緒にうまく機能せず、機能しません。多くの点で、アジャイル手法は、期限を守れないことが明らかになったときに放棄された期限やソフトウェアの大きな問題に対する反応です（予算の問題も同様）。

アジャイルは、「締め切りや機能がずれたり、変化することを知っているので、それを知っているので、ふりをしないで右足で降りましょう」と言って、現実を状況に注入しようとします。

重要なのは、期限が単にソフトウェアの最初のバージョンのリリース日になることです。それはまだ石で書かれているかもしれません-たとえば、ソフトウェアは学術用であり、学期の開始までに使用可能でなければなりません-しかし、あなたが提供するものはそうではありません。それまでに誰もが納品できると確信できる最低限の実行可能な製品があり、「持ちたい」ものがたくさんあります。リスト全体が「期限」までに配信されないことが判明したときに全員が手を放すのではなく、MVPをドアから出して、できるだけ多くの「持ちたい」可能な場合、その時点での残りの費用/便益を評価します。

コンピュータゲームを長期間プレイしている人なら誰でも、これがどのように機能するかを正確に知っています。最初のリリースがベータ標準に達している場合、多くのゲーマーは満足しているので、実際の生活の中で「しっかりした、本当の締め切り」が意味することへの期待は低いです。

締め切りは機敏ではなく、ソフトウェアはハードウェアや鉄鋼工学のように扱われると人々が考えていた時代からのホールドオーバーです。これは、ソフトウェアがハードウェアよりも優れている最大の利点であるソフトであるため、これは可能でも望ましくもないことを学びました。

アジャイルは、橋の設計では不可能だった方法で、プロジェクトの過程で目標を開発および変更できるようにすることで、この柔軟性を活用しようとします。

「おそらくいいえ」と答える

Project_management_triangleは、コスト、時間および範囲（及び、品質）は相互に依存することを述べています。（「2つを選んで3番目を獲得」）

スクラムスプリントは、固定時間（7日=スプリントの長さ）とコスト（7チームメンバーの予算）を選択し、範囲（スプリントで行われるストーリーの数）を推定します

経営陣または営業部門が3つすべて（コスト、時間、範囲）を定義しようとする場合、チームは（quality = definition-of-doneに違反することなく）目標を達成することを約束できないため、スクラムの意味で機敏ではありません

専門の経営陣は、満たすべき一定の日付がある場合、必要に応じてコストと時間を定義し、範囲を縮小しようとします。

これに簡単に直接答えることはできませんか？

期限は機敏ではありません。

全体のポイントは、あなたが行くにつれて学習と適応を繰り返す方法でできることを構築することです。

期限は「x x yで配信する必要があります」で、事前に決められたタイムスケールで固定された成果物を約束しているという点で失敗します（アジャイルは配信しようとしているものがわからない、アジャイルから学ぶことは、たとえタイムスケールについて確実性を持つことが非常に難しいことを知っていても、またはその解決された問題であり、とにかくそれを行うべきではないことを教えてくれます。

質問に対する答えが「いいえ、締め切りは機敏ではない」ことを確立した後、「機敏なコンテキストで締め切りにどのように対処するか」という質問に対処する興味深い会話をすることができます。他の答えでそれについて考えます。

後者に対する合理的な答えは、価値の増分を早期かつ頻繁に提供し、やがてどこにいるかを見るということです-しかし、すべてに適合するサイズはありません。

自分の仕事に必要な敏ility性の程度は、組織図での自分の位置の高さに反比例します。

「アジャイル」は、それが何であるかについては良いことです。「アジャイル」というのは、「十分な能力を備えたオープンマインド」を意味します。最も機敏でなければならないのは、一番下のうなり声です。

管理レベルで、先のとがった上司が週に1回期限を遅らせることでより良い製品が得られること、または会社がまたは部門）で2週間を節約できます。これはアジャイルの締め切りです。

しかし、賢明な自己利益のように、それは実際には存在しません。