従来の（シリアル）ビジネスパーソンと連携するアジャイル開発者を管理する方法は？[閉まっている]

こんにちは、

私の職場環境には問題があります。私たちのITチームは機敏性を高めようとしていますが、実際にビジネスから賛同を得ているわけではありません。彼らは毎日のスタンドアップとスプリントのレビューに参加し、スプリントの計画を支援しますが、その後（大部分は）連続的な開発スタイルに進む前に、プロジェクトのために4か月の要件収集を行います。スプリントの目標は、「リリースにXX％近づく」などです。

ITチームにとって、彼らはスプリントを一種の死の行進に変えました。スプリントを1日終了し、翌日新しいスプリントを開始します。スプリント間で行われる反映や変更はありません。

これまでアジャイル方法論を実行したことがないので、私はそれらについて非常に快適な紹介をしていません。だから私の質問は：

1）リフレクション、イントロスペクション、変更などを行うには、スプリントの間に時間（おそらく1週間程度）が必要ですか？それとも、背中合わせのスプリントが標準なのでしょうか？

2）アジャイルなビジネスパートナーがいないアジャイルチームが生き残る可能性はありますか？そうでない場合、必ずしも俊敏なマインドセットではないにしても、ビジネスを反復的な方向に進めるためのいくつかの移行方法論やヒントがありますか？

3）チーム全体がすべてのスプリントに参加する必要がありますか？1人のスプリントにほぼ20人のプログラマーがいますが、完全に異なるプロジェクト（通常は3〜5人のチーム、時にはそれよりも大きいチーム）に取り組んでいます。単一のスプリントを使用するのは正常ですか、それとも複数の独立したスプリントを管理する必要がありますか？複数のスプリントを同時ロックステップで維持しようとしているのでしょうか、それともそれらのタイムテーブルを重複させて柔軟にする必要がありますか？

どんな考えやアドバイスも大歓迎です。SOから質問をするのは今回が初めてなので、これらの種類の質問を表現するより良い方法があるかどうかを知らせてください（FAQはかなり役に立ちましたが、完全にフォローしているとは限りません）。ありがとう！

1）通常、1つの会議の最後のスプリントを確認し、次の計画を立ててそれを開始できます。特に、タスクの見積もりがどれほど正確であったかを確認し、これを次のスプリントの見積もりにフィードします。前のスプリントの結果から顧客からのフィードバックを待つ必要があり、フィードバックが次のスプリントのタスクに影響を与えると思われる場合は、次のスプリントを遅らせることができます。

2）簡単にはなりませんが、チームはもちろん成功します。あなたのコメント

スプリントの目標は、「リリースにXX％近づく」などです。

理想的には、実証可能な機能/機能をスプリントの目標として含めたいので、少し心配です。

3）あなたは3-5個の完全に異なるプロジェクトがあると言います。それらが無関係である場合、つまり異なる製品の場合、それらを同期させる必要はありませんが、それぞれを独立したスプリントとして扱う必要があります。各スプリントのチームはおそらく良いサイズのようです。

1）リフレクション、イントロスペクション、変更などを行うには、スプリントの間に時間（おそらく1週間程度）が必要ですか？

いいえ、一週間？あなたは狂っていなければならない。2時間が限界です。

それとも、背中合わせのスプリントが標準なのでしょうか？

もちろんです。そうでなければ、あなたはあなたの車輪を回転させています。

アジャイルなビジネスパートナーがいないアジャイルチームが生き残るチャンスはありますか？

ビジネスは決して「アジャイル」ではありません。アジャイルはあなたがやるものです。それらではない。確かに、それらは決してありません。彼らはただランダムなものを求めます。あなたが管理します。

そうでない場合、必ずしも俊敏なマインドセットではないにしても、ビジネスを反復的な方向に進めるためのいくつかの移行方法論やヒントがありますか？

無し。要件をスプリントに分解します。それはあなたの規律です。彼らのものではない。

チーム全体がすべてのスプリントに参加する必要がありますか？

はい。

1人のスプリントにほぼ20人のプログラマーがいますが、完全に異なるプロジェクト（通常は3〜5人のチーム、時にはそれよりも大きいチーム）に取り組んでいます。

何？それはチームではありません。それはたくさんのチームです。4つまたは5つの個別のチーム。

単一のスプリントを使用するのは正常ですか、それとも複数の独立したスプリントを管理する必要がありますか？

何を言っているのかわからない。しかし、4つまたは5つのチームがすべてつぶされているように見えるので、大きな混乱が生じることは明らかです。

複数のスプリントを同時ロックステップで維持しようとしているのでしょうか、それともそれらのタイムテーブルを重複させて柔軟にする必要がありますか？

各チーム、そしてチームのスプリントは、チームの問題です。他の人はいない。

一部の人々は、このような大きなプロジェクトは「スクラムのスクラム」であるべきだと考えています。チームは目標を設定し、物事を構築します。各チームの代表者が定期的に集まり、チームを調整して相互に有益なリリースを実現します。

明らかに明らかに機能不全に陥っている組織にいることを残念に思います。

進行状況を測定する機能を使用する場合は、100％完全なマイルストーンの観点から計画することが絶対に不可欠です。特定のマイルストーンが何であるかについて正直な意見の不一致の余地がある場合、自然な傾向は、仕事をしている人が彼らが行った量について可能な限り最も楽観的な解釈をすること、そして彼らが言うことを聞くために彼らが言うことを聞くことです最も楽観的な方法で。これは、チェーンを上っていくにつれてニュースがどんどん良くなり、現実とトップが聞くものとの間の完全な分離をもたらすことを意味します。 http://www.davar.net/HUMOR/JOKES/SHIT.HTMは、この現象に対するユーモラスで完全に現実的な見方です。

この切断はどれほど悪いですか？このことを考慮。平均的なプロジェクトでは、完了までにかかった実際の時間（そこに到達した場合）は、平均で元の見積もりの​​2倍になります。しかし、プロジェクトがどれだけ遅れても、通常、トップの人々はプロジェクトが遅れているという最初のヒントを納期の約2週間前まで受け取りません。現実はもはや隠すことができません。

したがって、XX％近い目標は実際の要件ではありません。文字通り、チームはそれらを実際の要件として受け入れることを拒否する必要があります。具体的で実用的なタスクが必要であることを教育するのはあなたの仕事です。計画を立てる際には、最大で数時間かかると推定できる特定のタスクに分解する必要があります。

第二に、他の人が言ったように、あなたは絶対にあなたのチームをより小さなユニットに分解する必要があります、それはおそらく異なるスケジュールである必要があるでしょう。調査によると、1つのことに取り組んでいる20人の単一のソフトウェアチームは、5〜8人のチームと同じくらいの成果を上げることができます。（私はこの驚くべき事実をSteve McConnellの優れた本Software Estimationで見つけました。

第三に、それは死の行進のように感じることは本当に大きな赤い旗です。死の行進のように感じられる場合は、おそらく死の行進です。ソフトウェア開発者は、週に35〜40時間働いているときにピークパフォーマンスになる傾向があります。（その数値はSteve McConnellのRapid Developmentから得たものです。）長時間作業すると、一時的にパフォーマンスが向上する可能性がありますが、長期的にはパフォーマンスが低下します。大規模なプロジェクトはマラソンであり、ペースを合わせる必要があります。

第四に、スプリントにはリズムが本当に必要です。スクラムを行うチームで働いていたとき、各スプリントを「ロングフォーカス」と「ショートフォーカス」と呼ばれる2つのセクションに分割すると非常に便利であることがわかりました。「ロングフォーカス」の期間中、そのスプリントで合意されたタスクについて、ソフトウェア開発を進めました。「ショートフォーカス」の間、多くの中断とタスクの切り替えを含む、必要なすべてのことを行いました。それで、QA、バグ修正、さまざまな会議、次のスプリントのタスクの見積もりを行い、最後に次のスプリントに何を含めるか、何を行わないかについて合意しました。多くのソフトウェア開発は「ゾーン」にいるときにしか行えないため、これは私たちにとって非常にうまくいきました。

そのようなリズムに従うと、チーム間で異なるスケジュールを持つことでもう1つの勝利を収めることができます。QAスタッフは、現在QAに参加しているチームであればいつでも作業できるため、一定のレベルの作業を維持できます。

幸運を祈ります。上からのサポートがないと、機能障害を修正できない場合があることに注意してください。それが事実である場合、あなたの最良の現実的な選択肢は、組織をそれがそうならないものにしようとするのではなく、より健康な組織がその一部であることを見つけることです。

1. 私の経験では、スプリントは通常、背中合わせになっており、遡及調査を実行し、機能をデモンストレーションし、次のスプリントを計画する時間がいくらか失われています。たとえば、スプリントの最終日は、通常、その日にまたがる3つの会議があり、2週間のスプリントが9営業日に相当するため、取り消しと見なされます。スプリントの最後の回顧は、ある意味ですぐに始まる次のスプリントで試される変更をもたらす可能性があります。

2. 可能性はありますが、スクラムを使用しているかのようにかなり小さいです。あるストーリーが他のストーリーと比較してどれほど緊急であるかの優先順位付けを指示するために経営陣によって承認された製品所有者がいるはずです。別の部分は、「リリースに近いXX％」は、適切に実行することがほぼ不可能であるバグやその他の直前の問題を含まない傾向があるため、私の心にはかなり貧弱な指標であることですが、彼らの責任についてある程度理解する必要があります私の限られた経験で推定します。また、優先順位の変更がチームに認識され、スプリントの計画に使用できる場合について理解するために言うべきこともあります。彼らがあなたのしていることを理解していないかのように、それは静止したトレッドミルの上を歩いている間に配達をしようとするようなものかもしれないので、経営者の賛同は重要です。あなたの足が動いている間、あなたは

3. 必ずしもそうとは限りませんが、場合によってはそうなることがあります。重要なのは、各開発者がプロ​​ジェクトにどれだけ割り当てられているかを把握し、これを一貫性のある状態に保つことです。これにより、最初の数回のスプリントから速度が出た場合、これは、作業時間の数として役に立たないのではなく、将来の速度を予測するのに役立ちます。プロジェクトは跳ねすぎて、スプリントで実行できるポイント数を簡単に見積もることができません。プロジェクトが数週間の作業にまたがるほど大きい場合、プロジェクトごとに独自のスプリントセットが必要です。

彼らがしなければならないこととこれがどのように機能するかという点で管理を教育する上での幸運は、ここで克服するためのあなたの大きなハードルかもしれません。

プロジェクトがスクラムを利用している場合は、プロセスがどのように機能するかについてすべての関係者を教育することを仕事とするスクラムマスターが必要です。あなたがスクラムをしている場合、プロジェクトのビジネス側からの買収がないことは巨大な（そして珍しいことではない）ロードブロッキングであるため、スクラムマスターが彼/彼女の仕事をしていないように聞こえます。

完了までXX％近づいたと言われたら、プログラムの人々にそれをねじ込むように伝えます。そのような日付までに必要なX、Y、Zを完了することを伝えます。スケジュールを縮小したい場合は、何を削除したいかを尋ねます。もし彼らが言うなら、それらを削除するか、時間を追加します。それを成し遂げるか、さもなければ少し良いことをしないと言います。彼らがプッシュした場合、そのスプリントを完了するためにプロジェクトマネージャーのコードを割り当てます。アジャイルはチームの努力であることに留意してください。プロジェクト管理者が12時間働いていない場合は、そこにいる人のためにピザやソーダを入手し、予定より早く、または予定より早く仕事をするためのボーナスがあれば、その作業を行った人にも行ってください。プロジェクト管理者を訓練していないときにアジャイルを押し付けたのはおそらく、上位管理職にもあります。

進捗状況を追跡し、調整を行ってから、満たす次の要件を選択します。すべてが完了するまでプロジェクトが提供されない場合は、機能の優先順位を気にしないでください。将来の作品のためにどの機能が実行されるかについて心配してください。これの所有権を取得する必要があります。死の行進であってはならない。スクラムプロジェクトは、NORMALスプリントの期間中に完了できる作業量を測定する必要があります。その10（または上記の9）通常の8時間の稼働日。

数年前のアジャイル会議で聞いた1つのことは、あなたのチームは工場のようなものであり、スプリントごとにX台の車（またはあなたの場合は機能）を生産できるということです。

また、スプリントチームは20ではなく3〜5人である必要があります。これは問題の一部である可能性があります。各チームは自分たちのストーリー（必要に応じて要件のラインアイテム）を選び、それに取り組む必要があります。彼らは別々にスクラムするべきですが、アイデアを共有するためにいくつかの基準で大規模なグループに会います。

これらのタイプのチームを管理する場合、マネージャーが個別にスクラムして、必要なチーム間のタスクを決定し、適切な人に連絡をとる方がよい場合があります。20人のスタンドアップは、関係する人々にとって単調で退屈です。