期限はアジャイルですか？
明確にするために、締め切りは次のとおりです。
時間制限または期限は、目的またはタスクを達成する必要がある狭い時間フィールドまたは特定の時点です。
から wikipedia
私のソフトウェア開発のキャリア全体で「アジャイル」を行ってきましたが、それはどこでも、少なくとも以下のプラクティスが遵守されていることを意味するようです。
- 毎週または隔週のスプリント
- 回顧スプリント計画
- 製品所有者
- スクラム
- ユーザーストーリー
しかし、私がこれまでに取り組んだすべてのプロジェクトは、期限を設定することを主張しました。アジャイルが適応計画、柔軟性、変化に焦点を当てようとしていることを考えると、期限はアジャイルですか？
私の意見では、柔軟性がないことや品質の不足につながる期限があるので、そうではありません。代わりに、スプリントと早期配信に集中することで、より多くの価値が提供されると思います。しかし、私が参加したすべてのサークルでそうであるとは限らず、期限はアジャイル開発と連動すると見られています。
締め切りは現実です。ほとんどの場合、特定の日付までに何かが必要です。やむを得ない。期限がなければ、アジャイルプロジェクトでも パーキンソンの法則 に屈する可能性があります。
作業は、完了に利用できる時間を満たすように拡大します。
言い換えれば、プロジェクトがcan永久に続行できる場合、それは続行されます。
期限に関して、アジャイルはいくつかのことを試みます。
- 全員が締め切りまでにどれだけの作業が行われるかを常に確認できるようにする
- 最も重要な機能が最初に完了していることを確認してください
- まだ完了していない機能に依存しないという意味で、完了した機能が使用可能であることを確認します
- 開発が持続可能なペースで継続するようにする
そうすれば、避けられない日が来ても、無駄なコードの山はありませんが、うまくいけば、最も重要でないものだけが完成していない、テスト済みの製品です。そして、完成した製品に誰も驚かない。
あ、はい。 「アジャイル」と「期限」は完全に互換性があります。
締め切りは人生の事実です。非常にしっかりしたデートがあるものがあります。
Comdexのソフトウェアが必要です
または
ゲームはブラックフライデーまでに店頭になければならない
など。コムデックスやブラックフライデーを延期することはできません。他の国々はそのように機能しません。
アジャイルの目標は、締め切りに間に合わないものはより速く失敗する（そしてそれは良いことです）、またはスコープをより早く再調査してリソースを正しいROIに集中できるようにすることですよりタイムリーな方法。
締め切りは、しっかりと定められた難しい日付です。アジャイルは、ソフトウェアが最初に期待していたものの2倍の時間がかかることをサイクルの早い段階で認識できるツールです。より多くのリソースを追加したり、範囲を変更したり、期限を調整したり（堅固な期限ではなく会社の場合）、またはプロジェクトを行うために、プロジェクトマネージャーはこれらの問題を後から早く実現できることが重要です。キャンセル。
アジャイルが求める透明性は、サイクルの早い段階で問題と進捗状況を示すことです。古典的なウォーターフォール配信の失敗は、閉鎖されたドアの後ろで何ヶ月も費やして、締め切りの1週間前に製品を配達し、それをすべて間違って行っていると言われ、何ヶ月も無駄にしてしまった（そして今、締め切りを完全に吹き飛ばした）ものです。 。もう1つの古典的なウォーターフォールの失敗は、まだ数か月の期限の1週間前に判明することです。アジャイルは、プロセスの早い段階でこれらの問題を明らかにすることを目指しています。
アジャイルが期限のコンテキストで実行しようとするもう1つの部分は、合意された機能の一部だけが（何らかの理由で）完了している場合でも、現在のバージョンのソフトウェアが有用であり、展開可能であることです。
OK、4月15日に税務ソフトウェアを導入するために必要なものがすべて揃っていなかったのですが、昨年11月の開始以来、75％の実績があり、機能しています。 12月中旬以降、完全な機能セットを展開することができなくなることがわかっており、顧客ベースの80％に再び注力しました。
いくつかの締め切りに間に合わなければなりません。契約上の義務、規則、規制要件。ソフトウェア開発をスプレッドシートで製造と同じチャートに入れられるようにしたいマネージャから課せられるものもあります。原因が何であれ、ほとんどの人は彼らから逃れることができません。
機能しているチームで作業している場合、開発者と管理/利害関係者間のコミュニケーションは、決定を下す必要のある人々が十分な情報を得て、締め切りを逃したり、開発を続行したりすることがより重要であることを意味します。
完成したユーザーストーリーを週に1回または月に2回配信する場合でも、おそらく締め切りがあります。近づいたら、締め切りまでに何に当てはまるかを関係者に知らせ、期待を設定してください。
あらゆる段階で現在持っている要件を使用して、できる限り最高のソフトウェアを常に構築している場合、スプリントの最後の期限は理論的には問題になりません。実際には、これは通常のケースではありませんが、どちらも薄い空気から出てくる期限ではありません。私がこれまでに与えられた最も重要な期限はずっと前に私に伝えられました、それは問題であった品質と機能への期待でした。私が考えることができるすべての締め切りはどこにもないところから来ていますが、それは嘘のためです。営業は顧客に機能が存在するか、コンサルティングなしで、場合によってはエンジニアリングに通知することなく追加できることを伝えたか、誰かが上司にすでに完了していると伝えました。
見逃しても結果が出ない任意の期限はあまり機敏ではありませんが、開発チームの管理範囲外の理由で期限を設定して維持しなければならない場合があります。幸いにも、締め切りが妥当であれば、方程式を逆転させてアジャイルな方法で締め切りを処理する方法はたくさんあります。
締め切りが間違っているとは限りません。オビ＝ワンから学んだように、
「シスだけが絶対的に対処する」
ほとんどの場合、締め切りはばかばかしく、不必要で、確かにアジャイルではないと言えますが、これが常に当てはまるとは言えません。古風な事件は、選挙の追跡ソフトウェアなど、時間に敏感な使用に必要なソフトウェアです。選挙に間に合うようにソフトウェアの準備ができていない場合、選挙を延期することは賢明でも実用的でもありません。「申し訳ありませんが、時間がかかりすぎたようです。あなたが私たちに支払っているこのソフトウェアは完全に無価値であることは知っていますが、締め切りはアジャイルではないので、どうすればそれらに会わなかったために私たちに対抗することができますか？」
時間に敏感な何かを求めてそれを押し出すように顧客に伝えることはあまりアジャイルではなく、1日の終わりにsomebodyはこれらのものを構築します。それでは、どうすれば顧客を満足させ、時間に敏感な問題に対して一見合理的なソリューションを提供できるでしょうか。まあ、ソフトウェアの開発に不確実な時間がかかり、期限が可変でない場合、何か他のものはその不確実性を処理するために可変でなければならないでしょう...
納期が一定に保たれると、他のいくつかの要素が変数になります。ご存じのように、ソフトウェアプロジェクトにはかなりの不確実性があります。プロジェクトで成功したい場合、この不確実性に応じて何かを可変にする必要があります。通常、それは納期です。とにかく、それは十分に自然なようです。しかし、それが唯一の選択肢ではありません。厳しい納期に間に合わない場合、それを処理する方法は、提供される機能を可変にすることです。機能のリストに優先順位を付け、その日付までに配信できる機能の量に不確実性があることを明確に伝えます。お客様と協力してこれらの機能に優先順位を付け、最も重要な機能が出荷される可能性が高くなるようにします。次に、それは通常どおりの仕事です。締め切りが迫っていて、出荷の準備ができているものは何でも出荷します。このモデルでは、より多くの機能を出荷することは、以前の日に出荷することに類似しており、より少ない機能を出荷することは、後で出荷することに類似しています。
誰かが期限を設定したい場合、それは問題なく、期限は修正できますが、彼らが理解しなければならないのは、期限が修正された場合、スコープは柔軟なままでなければならないということです。
tl; dr
理想的な世界では、締め切りはなく、準備ができたときに納品するだけです。しかし現実は、物事にお金を払う人は通常、いつ終わったのかを知りたいのです。アジャイル方法論はこれを認識していますが、すべてを拘束できるわけではないことも認識しています。
これにより、製品に適したレベルで配信品質を維持できます。期限と範囲（および予算）を修正すると、物事が急がれ、プロジェクトの終わりにクレイジーなクランチタイムで古い滝の世界に戻ります。開発者とテスターを追加しても問題を迅速に解決できないため、通常、予算を増やすことは答えではありません。 よく知られた見方 （そして経験から私はそれに同意します）であり、追加する人々（それぞれが自分自身の可能性を持つ）が増えるほど、より多くの時間がかかります。
さて、通常（彼らがアジャイルの方法を本当に理解しているのでない限り）ソフトウェアの料金を支払う人は言われるのを嫌います、私たちはあなたの締め切りに間に合うことができますが、私たちはあなたが望むすべてを行うことはできません。これは、ソフトウェアを構成する機能に優先順位を付けることで管理できます。優先順位付けの議論は次のようになります。
開発チーム（D）：「提供したい機能に優先順位を付けることができます。最も重要なものから始めてください。」
お客様（C）：「すべてが優先1-来月末までにすべて完了してほしい。」
[〜＃〜] d [〜＃〜]：「それは可能かもしれませんが、要件が変更されたり、問題が発見されたりすると、可能にならない可能性があります開発中は期待していませんでした。」
C：「もっとお金をあげたらどうなるの？」
D： "sigh...より多くのリソースがあっても、実際には1か月かかります機能を優先する方法がわからない場合は、どの機能を最初に実行するかを教えてください。」
C：「OK大きなボタンが必要ですが、実際に大きくしてから... etc」
これで、優先順位に従って機能の作業を開始できます。また、優先順位の低い項目をチームで先読みし、いくつかの初期見積もりを行うこともできます。詳細については、開発に着手したときに変更できる可能性があることを知っているからです。ロードマップがまだない場合は、これを使用してロードマップを再定義または作成できます。これがリリース計画の基礎となります。ロードマップは、範囲が変更される可能性があることをお客様が認識していると話し合うことができますが、提供するものの順序はあります。
アジャイルの大きな利点の1つは、開発の過程で状況が変化し、それに合わせて調整することを認めることです。従来のアプローチとは対照的に、この原則は、定期的なスプリントの成果物と継続的な顧客とのコミュニケーションと併せて、当然、進行状況についてより透明性を強いられます。これは良いことです。
顧客は、特定の日付までに欲しいものを手に入れられないことを好まない場合がありますが、彼らは理由を理解し、得られるものは質の良いものになるでしょう。また、機能が提供されてから6か月後、お客様は特定の日付までに提供されたことを気にしないか覚えていなくても、まだ使用している製品の品質を覚えています。
締め切りは伝統的にビジネスライフサイクルに基づいています。税務ソフトウェアは4月15日までに提供される必要があります。次年度の報告は7月までに行う必要があるかもしれません。
アジャイルマニフェスト の状態：
プロセスとツールを介した個人と相互作用
包括的なドキュメントに対応する実用的なソフトウェア
契約交渉を介した顧客のコラボレーション
切り替えへの対応計画に従う
締め切りは契約です。彼らは計画です。彼らはあなたのチームの速度に反応しません。 3人の優秀な開発者を失っても、変更はありません。
締め切りはアジャイルではありませんが、アジャイルは締め切りに関するフィードバックを提供することができます。アジャイルでは、機能がカットされない限り、ベロシティによって期限を設定できない場合はお知らせください。また、締め切りまでに雇用する必要があるかどうかもお知らせください。そして、場合によっては、カットする機能が残っていないときに締め切りが不可能であることを知らせます。
アジャイルチームができる最善のことは、彼らの速度と優先順位付けバックログに締め切りを追い込ませることです。これにより、配送予定日がわかります。それらが締め切りを超えている場合は、クライアントと真剣に話し合い、締め切りが実行可能かどうかを判断する時間です。
各スプリントの配信は交渉できないと私は言うでしょう。作業を評価し、カードのサイズをその上に置き、スプリントが終了するまでチームをビジー状態に保つのに十分な量をロードします（スプリントは小さくなければなりません-1週間から1か月まで）。 「納期」は、予定された作業に対する完了した作業の過去の傾向に基づいている必要があります。アジャイルは、古い「コスト/時間/スコープ」という制約の考えから何も追加/削除しません。スコープを優先するのは、より多くのお金や時間を費やすよりもスコープに対する優先度が一般的に望ましいという理由で、スリッページを管理するための好ましい方法としてスコープを使用するだけです。
一部の人々は、「野生の西」のためにアジャイルを混乱させるようです。アジャイルは、何かがうまくいくという意味ではありません。アジャイルとは、合理的な人がどれだけ適切に見積もることができるかについて、自分たちに嘘をつくことをやめることを意味します。基本的に、ソフトウェアの開発は、約2〜4週間後と推定できます。それを超えて、それはすべてさまざまな程度の盗品と推測です。さらに悪いことに、物事の見積もりを将来にわたってさらに提供するコストは、単に作業を行うコストに近づきます。どんな理由であれ、プロジェクトマネージャーは歴史的にこれらの絶対的な真実を顧客に認めようとはしませんでした。アジャイルは、ソフトウェアエンジニアリングの将来を予測するのに十分な限界があると断言することでその考え方を調整し、長期予測のために「エビデンスベースの推定」に微妙に切り替えます。小さなチャンクで死んだ特定の配信、および長期的なものの証拠に基づく配信を提供することにより、両方の世界の最高のものに近いものを得ます-私たちは実際に何について真実であるようになりますare見積もることができます、そして、これまでに提供してきたことに基づいて、長期的な将来の提供についてかなり合理的な見積もりを提供することができます。
TL; DR
期限は[a] gileですか？... [D]期限は[a] gileの開発と密接に関連していると考えられています。
ここでの多くの回答は、質問の工学的側面に焦点を当てている可能性があります。代わりに、プロジェクト管理の観点からこれに対処します。
期限は、アジャイルの原則に沿っていない大量の事前計画を意味します。代わりに、反復開発モデルは、タイムボックス、ケイデンス、リリースサイクルに依存しますincludeジャストインタイムの計画ではなく、一般に、従来のプロジェクト管理の期限に関連付けられています。
アジャイルな方法論でリリース計画を行うことは依然として可能ですが、計画は通常、フィアットによって設定された管理目標ではなく、目標を達成するために必要な反復数の推定に基づいています。それは、出荷日を設定できない、または目標を達成できないと言っているわけではありませんが、それらが定義され、満たされているwayは、従来のプロジェクト管理方法論。
期限ではなくタイムボックスを考える
しかし、私がこれまでに取り組んだすべてのプロジェクトは、期限を設定することを主張しました。アジャイルが適応計画、柔軟性、変化に焦点を当てようとしていることを考えると、期限はアジャイルですか？
これは、アジャイル原則の一般的な誤解です。スクラムやカンバンなどのアジャイルフレームワークは、期限に焦点を当てているのではなく、タイムボクシングと持続可能なデリバリーケイデンスに焦点を当てています。
たとえば、スクラムでは、スプリントは「期限」ではありません。これは、チームがオーバーフローすることなくタイムボックス内に収まると予測する作業量で満たされたタイムボックスであり、タイムボックスが期限切れになると、「完了」または「未完了」になります。一度なくなると、タイムボックスは永久になくなります。実行されていない作業は、プロジェクトの現在の（履歴ではなく）ニーズに基づいて、新しい一時的な時間枠内で再計画および再推定する必要があります。
タイムボックスの重要性は、進捗状況を確認するための利害関係者の予測可能なリズムと、潜在的に出荷可能な価値の増分をチームが提供する持続可能なペースの両方を作成することです 。仕事は漸進的であり、ケイデンスに従います。したがって、大規模な事前納期の概念は、アジャイルの原則に沿っていません。
タイムボックスに基づくリリース計画
おそらく、人々がアジャイルプロセスを従来のフレームワークにマッピングするのが最も難しい領域の1つは、リリース計画です。リリース計画には、多くの場合、固定範囲または固定日付の成果物が含まれます。アジャイルフレームワークでは、リリース計画は通常scopeが変更可能な変数として明示的に定義されている推定プロセスを通じて行われますが、リリース日は反復で推定されます。
たとえば、プロジェクトは、20回の反復の最後にプロジェクトのv1.0をリリースすることにコミットする場合があります。リリースされる対象の範囲はプロジェクトの存続期間中に変更される可能性があります（範囲、機能、および優先順位はすべてのスプリントの開始時に変更される可能性があるため）が、各リリースの目標日はプロジェクト計画で固定されています。チームは各スプリントの出荷可能な増分を提供するよう努めており、完了の定義には、継続的な統合などの品質チェックが含まれており、プロジェクトが各スプリントの終了時に解放可能な状態であることを確認します。
時々、スコープが固定されているアジャイルプロジェクトが表示されますが、スコープはアジャイルプロジェクトの可変変数であるため、リリースの日付は、各反復のスコープがプロジェクトの進化するニーズに合わせて調整、変更、または適応するにつれて、時間とともに変化する可能性があります。固定スコープアプローチはアジャイルチーム、特に経験の浅いチームにはお勧めしませんが、適切なアプローチである場合があります。
こちらもご覧ください
期限はコミットメントと考えてください。プロジェクトがアジャイルであるという事実は、特定の日付に特定の機能を提供することを約束するべきではないという意味ではありません。
俊敏性がもたらすのは、その間に何が起こるかです。特定の日付にサブ機能B、C、D、Eで構成される機能Aを提供する必要があることを定義する厳密なソフトウェア要件仕様ドキュメントを用意する代わりに、特定の日付に機能Aを提供することを約束します。初期段階では、あなたもあなたの顧客もその機能がどのように見えるかを知らないか、サブ機能B、C、D、E、またはおそらくBとC、または他の多数のサブ機能を持っているでしょう。
以前は小企業にのみ商品を配送し、大企業と契約を結んだばかりの企業を想像してみてください。この大企業はEDIFACTを使用しており、会社で使用されている現在の会計ソフトウェアはEDIFACTを処理していないようです。それを行うプラグインを作成するように要求されます。契約上、あなたの会社は4月15日の準備ができているはずです番目。
俊敏性は、中間ステップが段階的に提供され、定期的なフィードバックに基づくことを意味します。基本的に、あなたはあなたの進捗状況を会計士に示し、彼らは彼らがそれについてどう思うか、起こり得る問題は何かなどをあなたに教えてくれます。実質的にユーザーエクスペリエンス。 3週間後、それはそれをそれほど改善しないだけでなく、さらに1ヶ月の追加の開発をもたらすように見えました。アジャイルのおかげで、この機能から別の機能に作業をリダイレクトできるため、時間どおりに配信できます。
また、顧客の視点も理解する必要があります。
多くの場合、企業は特定の納期を必要とします。たとえば、オリンピックのオンラインストリーミングサービスafterオリンピックの終了を配信することはできません。ビジネス的には、これは単なる失敗であり、大きなマイナスの結果をもたらします。
コミットメントがなければ、開発者や下請け業者が完璧主義者になるか、プロジェクトの優先度を低くするのは魅力的です。スプリントの規則性は役立ちますが、このリスクを完全に防ぐわけではありません。
特に締め切りは非常に簡単に発生するため、私はその期限が好きではありませんが、多くの企業がなぜそうするのかはまだ理解しています。スプリントだけを見ても、プロジェクトが予定より遅れていることを確認するのは必ずしも容易ではありません。この場合、期限を逃したことは、何かが制御不能になり、現在対処する必要があることを明確に思い出させるかもしれません。
eXtremeプログラミング リリース計画に関する状態：
リリース計画の基本的な考え方は、プロジェクトは4つの変数（スコープ、リソース、時間、および品質）によって定量化できるということです。
それは公平に思えます。また、
4つの変数すべてを制御することはできません。 1つを変更すると、不注意で別の応答が変化します。品質を優れたレベルよりも低くすると、他の3つの変数に予期しない影響が生じることに注意してください。
br3w5 ですでに述べたように、リソースを増やすことは制限付きのソリューションです。他の何かに派遣された場合は、すでにチームに参加していたカップルを追加できます。ただし、チームサイズをすばやく無期限に単純に拡大することはできません。少なくとも、チームの再編成を行わなければ、時間がかかります。
したがって、削減できない品質と固定リソースを使用すると、期限が時間の制約になるため、スコープを調整する必要があります。また、俊敏性を使用することで、可能な限り最も生産的な範囲で期限を守ることができます。ただし、通常は、スコープの一部が時間内に実行されることを保証できます。これは、納期を下回る時間を確実に見積もることができる部分です。典型的には、あなたが数回行ったことに本当に近いものであり、未知のものはほとんどありません。
ソフトウェア開発方法の目的は、正しく理解された場合、私たちの考えに焦点を当てることにより生産性を高め、一般的な状況に共通の言語を提供することです。それはインスピレーションと可能性についてであり、マインドコントロールと罪悪感についてではありません。
文字通り妥協のないソフトウェア開発方法に従うことは、他の文脈における過激主義または原理主義と呼ばれるものに対応します。この異常の純粋な形は、市場での急速な失敗につながるため、実際にはめったに見られません。しかしもちろん、開発者が特定の方法を実装するという困難なタスクで競合する場合、マークのオーバーシュートは自然な出来事です。
問題は、宣教師と伝道者が主にまだメソッドを使用することを説得する必要がある人々をターゲットにしているという事実によってさらに悪化します。そして、たとえ彼らが節度を説教したとしても、人間の本性はそれがあまり注目されないことを保証します。