要素の納期を固定することは、「アジャイル」な作業方法ですか？

私たちは、上級管理職による新しいプロジェクトに機敏に取り組んでいくと言われ続けています。彼らはスタンドアップ、スプリント計画、回顧などをセットアップしました。しかし、彼らは今、私たちが各要素に対して日付を提供し、それぞれでデモされるもので再び日付を見せたいすべての仕事を詳述する計画を思いつきました。 1。この計画は、2017年第2四半期に予定されています。

私にとってこれは最悪の意味でのウォーターフォールのように思えます。技術チームからの情報がない計画が作成されており、計画に関する特定のストーリーが非常に不明確であり、開発チームによって推定されていません。

しかし、私は彼らの議論が「シニアの利害関係者は日付を持たなければならず、計画が必要であり、単にバックログから作業することはできない」ことを知っています。私には、これは上級の利害関係者がアジャイルに買収していないようであり、したがって、私たちはそれをより低いレベルで実装することに失敗する運命にあります。

これは公平な判断ですか、それともこの計画に過剰に反応していますか？

期限を守ることと、すべての要件を満たすことには違いがあります。古い格言「速い、良い、安い、2つを選ぶ」のようなものです。

したがって、ここで納期が決まっています-それは良いことです。つまり、最後のスプリントの最後に納品したものが最終製品になるという点で時間枠があります。すべてのスプリントの最後に、動作しているソフトウェアを常にリリースする必要があることを覚えています。

起こる可能性があるのは、最終的なソフトウェアにいくつかの機能が欠けているということです。まあ、これはウォーターフォールを含むすべての開発方法論で起こります。起こるのは、後でパッチリリースまたはバージョン2を作成するというタスクを課せられることだけです。これは、最終的な配信がもちろん十分であることを前提としています。

そのため、固定日付は非アジャイルな作業方法ではありません。アジャイルは、新しいプランニングツールでプレイするための予算に制限がないという意味ではありません。それはあなたが配達に集中しなければならないことを意味します、それは決して悪いことではありません。

いいえ。これは、非ソフトウェア企業が行う傾向があるものです。計画、期限、予算があります。そして、人間は未来を予測するのを嫌うので、それは必然的に失敗するでしょう。

ここでさまざまなポイントを見ていきましょう。

私たちは、上級管理職による新しいプロジェクトに機敏に取り組んでいくと言われ続けています。

もしあなたがアジャイルなら、あなたは管理職による働き方を言われることなく、自己組織化されたチームを持つことになります。

しかし、彼らは今、私たちが各要素に対して日付で提供したいすべての仕事を詳述し、各要素でデモされるもので日付を再び紹介する計画を考え出しました。

いや。これは、繰り返し開発のアンチテーゼです。何かが起こり（誰かが病気になったり、誰かが去り、何らかの要件が忘れられ、サーバーが死ぬなど）、これらの目標の1つを逃します。現在、経営陣は、計画全体を再計算するか、開発の鞭を打ち破ることができます。

開発チームによって推定されたものはありません。

それで、経営者はこの計画が実行可能であることをどうやって知るのでしょうか？アジャイルでは、仕事は交渉です。ビジネスはこう言っています。エンジニアリングによると：わかりました、XYZと仮定すると、3週間かかります。あなたが説明していることには顧客とのコラボレーションはありません。個人や相互作用はありません。

私には、これは上級の利害関係者がアジャイルに買収していないようであり、したがって、私たちはそれをより低いレベルで実装することに失敗する運命にあります。

あなたは必ずしも運命にあるとは限りませんが、そうでない場合、それは単なる偶然です。経営陣が未来を見ることができないためにすべての作業が表示されると、日付を逃します（または粗雑なコードを生成するか、予想以上のリソースを必要とします）。それはあなたのせいです。経営陣は、おそらく、あなたがより多くの時間を働いて日付を打つように圧力をかけるか、あるいは人々に問題を投げかけるでしょう。

最良の場合、管理は実際にアジャイルであり、範囲を縮小するのに十分スマートです。つまり、彼らはこの時間すべてを費やして、価値のない大きな詳細な計画を立てただけです。

特定の機能の特定のセットが特定の日付に配信されることが予想される場合、いいえ、これはアジャイルプロジェクト管理ではありません。アジャイルプロジェクト管理は本質的に経験的です。予測は、役員の希望に基づいて行われるのではなく、過去の業績の分析に基づいて行われます。

あなたの説明は、私がカーゴカルトアジャイルだと思うものと一致します。エビデンスに基づいたプロジェクト管理の中核概念ではなく、特定のプロセスとセレモニーに焦点を当てています。これをリーンやTPSに関連付けると、ビジネスマンに理解してもらうことができるかもしれません。ここで解決する必要がある本当の問題は、未知のものに対する恐れを経営陣が乗り越えてしまうことです。経営陣への正しい答えは、「今はいつ物事が行われるかを伝えることはできませんが、価値を提供し始めたら、経験に基づいて予測を立てることができます」です。開発者は、「やったらやる」や「いつやるのかわからない」といったことを言う傾向があります。経営者は経営者にそのようなことを言わず、それは彼らをnincompoopsのように聞こえさせます。

おそらく、計画は失敗し、修正する必要があります。チームにとって最大のリスクは、納期に間に合わせるための大きな推進力があり、品質が低下することです。ある時点で目標を達成できなくなり（最初の締め切りになる可能性が最も高い）、その日に間に合うようにプッシュされるでしょう。残業が予想され、コーナーをカットするプレッシャーがあります（ユニットテストのスキップ、コードレビューなど）。これは滑りやすいスロープであり、このパスを開始すると、少し下向きのスパイラルになり、物事がgetいものになります。このようにプロジェクトが継続されると、生産性が低下します。

開発チームに統一された前線を提示できるようになったら、品質のラインを押し戻して保持する必要があります。私の経験では、プロジェクトマネージャーはソフトウェアの出力は線形であると考える傾向があります。つまり、各期間XはYの「完了率」を生成します。つまり、許可された時間の半分までに「50％完了」していない場合、クラクソンは鳴り始めます。現実には、正しく実行している場合、最初の機能は50番目の機能（同じサイズの）よりもかなり長い時間がかかる傾向があります。何かが行われているのが見えます！」）おそらく大丈夫でしょう。

実際のビジネスへようこそ。

古いスタイルのビジネスがありますが、私はそれを「伝統的な開発」と馬鹿げて呼ぶ傾向があり、その後に新しいスタイルの「アジャイル開発」があります。これらを対立する理想として扱うと、真ん中の単純な分割が見られます。計画と要件は従来のコラムに、発見と進化はアジャイルのコラムにあります。それはきちんとしていて、きちんとしていて、間違っています。

実際には、ビジネスとは、両者の間の幸福な媒体を探すことです。どちらかの極端が実際にその面で平らになることを示すのは簡単です。アジャイルを愛する私たちは、伝統的な開発の純粋な理想のすべての問題を熱心に実証します。 成功しているアジャイル企業は、両者の間に特定のバランスが見られる企業です。成功している伝統的な企業は、両者の間に特定のバランスを見つける企業です。片方をもう片方なしに持つことはできません。

祝福されたSCRUMプロセスでさえ、両者のバランスを示しています。俊敏性を最大化する明確な試みがありますが、いくつかの重要なトレードオフがあります。たとえば、製品所有者には、すべての顧客を擁護するという強力な仕事があります。SCRUMは、その相互作用の仕組みを意図的に指定していません。誰もが一日の終わりに給料を払う必要があるという事実に意図的に手を振る。それは重要ではない錯覚を作成するプロダクトオーナーの仕事です。

（純粋なアジャイルは、製品を生産するまで支払いを受けず、権利が得られるまで専有情報にアクセスできない限り、素晴らしい働きをすることは興味深いことです。この貿易で起業家です）

そのため、管理者は、どの機能がそこにあり、いつ必要になるかを決定しました。それはいいです。私が聞いたフレーズは、「顧客が何を、いつを選ぶか、プロデューサーが誰を、どのように選ぶか」です。 「何」と「いつ」にサインアップしました。彼らは、あなたに「アジャイル」をあなたの方法として使う機会を提供することを除いて、誰や方法について何も述べていません。残っているのは、ニーズを満たすために雇用する必要がある人数を管理者が理解できるようにすることです。

完璧な世界では、あなたの会社は外部からアジャイルです。それは顧客とアジャイルな方法でやり取りし、開発者が彼らのために積極的に開発できるようにします。 しかし、非常に多くの場合、会社は内部を積極的に開発しながら外部と対話する必要があります。 その間には、常に各企業に固有の複雑なトレードオフのセットがあります。

個人的に、私はこの状況をアジャイル開発を理解していると思う人のためのテストケースとして扱います。将来のある時点で、期限までに製品を開発する必要があり、その製品/期限のペアは比較的修正されます。 固定された製品/期限がプロセスを粉砕した場合、そもそもアジャイルだったと本当に言えますか？

私のアドバイス：これを滝とは思わないでください。あなたはまだ「方法」を制御します。アジャイルが有名な高速スプリントと柔軟なプロトタイピングのすべてを引き続き行うことができます。 あなたは単にゴムが道路に出会うことを意識する必要があり、あなたは配達しなければなりません。これは現実の世界であり、理想の世界ではありません。そもそも彼らにあなたに尋ねたほうがよかったでしょうか？承知しました。あなたの電話ではなかったかもしれません。単にあなたが完全に理解していないので、彼らのやり方でそれをする千のビジネス関連の理由があるかもしれません。遠慮なくそれらを押し戻しますが、彼らが彼らがしたことの非常に正当な理由があるかもしれないことを理解してください。

アジャイルは、マイルストーンの計画を妨げるものではありません（たとえば、3か月でV 1.0をリリースします）が、各マイルストーンの内容は修正できません。

どのように対応すべきかは、プロジェクトの性質に依存すると思います。プロジェクトが2017年第2四半期までに月に男を送ることである場合、誰もが失敗する運命にあることに同意するでしょう。2017年第2四半期末までにMVPを提供できると思われる場合は、スプリントごとにスプリントに取り組む必要があります。

経営陣がチームが最善を尽くしていると判断し、各スプリントで進捗状況を示すことができれば、より長い時間交渉することができるはずです。

すべてのビジネス関連プロジェクトには制約があります。

• 時間
• 資源
• 予想される最小機能セット

これは他に何もありません。アジャイルを開発するということは、「人々が私たちにお金を払うので、準備ができていればいつでも好きなものを開発できる」という意味ではありません。常にいくつかの最小要件を持つ日付があり、それらが満たされない場合、プロジェクトはキャンセルされ、失敗と呼ばれます。それらは暗黙的である場合があります-そのため、マネージャーは「4週間後にこれらの機能を備えたUIが動作しない場合、このプロジェクトは失敗する運命にある」ことを知っています。

法律に起因する多くのプロジェクトがあります。-新しい法律を尊重するために2017年までフィーチャーXを実装する必要があると政府が決定した場合、交渉不能な期限と準備が必要な一連のフィーチャーがあります。唯一の変数は、管理者がタスクに割り当てることができるリソースの量です。-期限が外部の決定であるこれらのプロジェクトでは、目標を達成するために、進捗を監視し、予言を聞き、チームのスタッフを配置するか、作業の一部を外部委託する必要があります。

これはすべて、アジャイル開発に反対するものではありません。あなたはまだ自分のスプリントを持ち、自分の時間枠で機能を開発します。常にクライアントから機能の優先順位を取得します-そして、期限までにできるだけ多くのこれらの機能を提供するように働きます。

期限が実際に利用可能なリソースで満たされるかどうかは、管理上の問題です。あなたはあなたの予後と毎週/毎日のステータスの更新を与えることができ、彼らは彼らがより多くのリソースを必要とするかどうかを決めることができます。それ以外の場合は、スプリントでの作業を継続し、実行可能ファイルを提供します-他のプロジェクトと同じです。

マニフェストが言う前に誰かがすでに指摘したように：

プロセスに関する個人と相互作用

提案された計画を見て、変更を提案することをお勧めします。マニフェストは、バックログは決して最終的なものではなく、進化し続けると述べています。

だから、あなたはチームにあなたの提案を取ることができます。有効な推論があり、チームがそれに同意する場合、自分の塩に値する製品所有者はそれらを考慮し、チーム全体の意見を反映するためにバックログを削除します。

これが、2つの方法に進むことができるポイントです。

1. 製品の所有者とビジネスは、あなたの推論に同意し、それがオプションである場合は期限を満たすためにリソースを増やすか、期限を満たすためにいくつかの機能を削除することを選択する場合があります。

2. チームの集合的な意見に反して、自分たちのバージョンに固執したい場合があります。

結果が＃2の場合、これはアジャイルではありません。

もしあなたが＃1になったら、私はチームが正しい軌道に乗っていると言うでしょう。なぜならアジャイルは単に開発者の「変化への対応」ではなく、ビジネスが変化に対応できることでもあるからです。

誰かに壁、家、そして街全体をペイントするように頼むことを想像してみてください。

あなたの答えが何であれ、あなたは間違っているでしょう。それでおしまい。

仕事をする必要のある人に自分の考えを聞かなければ、日付について正しいことはできません。

ところで、もしあなたが（チームとして）これらの日付を受け入れるなら、あなたはそこで間違っています。

利害関係者と一緒にこの計画に取り組むためにしばらく時間をとって、物事を成し遂げるのがどれだけ簡単で速いかに応じて優先順位を設定できるようにしてください。

たとえば、最終的な作業には思ったよりも2倍の時間がかかるかもしれませんが、予想よりずっと早くベータ版を使用できます。

全体として、高速化できないか高速化できる場合、Y時間でXを実行できると人々に思わせることはできません。それは、詳細と時間の観点から必要なものを明確にする責任です。

その計画ではありません。

しかし、あなたが計画を知らないふりをするなら、スプリントごとにスプリントをするだけです。それは働いているかもしれません。

常に日付と予算があります。彼らが見逃したりオーバーランしたりするリスクは常にあり、それが起こると、常にプランBにフォールバックしなければなりません。

アジャイルな方法で作業している場合、プランBが最後のスプリントのデモになることを願っています