5

私は最近、開発サイクルのためにスクラムを導入し始めた会社にインタビューしました。開発者の一人に彼らの経験はどうだったのか聞いたところ、彼らは計画プロセスから完全に切り離されたようです。彼は、特定のスプリントに何が入ったかについての入力を許可されず、計画やグルーミング活動にも参加しませんでした。

基本的に、最後のスプリント（または2つ）の開始時に、彼はやることリストを手渡されました。彼はアイテムをそれぞれのタスクに分解する必要がありましたが（スプリントで作業できるようにするため）、計画活動には関与していませんでした。私は彼がアイテムがどれだけの努力をするかもしれないかについて多くのインプットを許されたのではないかと疑っています-建築家がチームのためにこれを決定したのではないかと思います。

これはスクラムの処理方法ですか？私の現在のチームは、すべての計画活動に完全に参加しており、機能に対処する方法と、機能にかかる可能性のある作業についての情報を継続的に追加しています。私は、開発者に入力を求めずにやることリストを渡すだけの会社に少し懐疑的（そして神経質）です。

注：スプリントが開始されると、リストは実際には優先されるToDoリストであることを理解しています。私の懸念は、最初から計画プロセスに情報を提供していないことです。

4

11 に答える 11

14

作業を行っている人が、スプリントにどのくらいの作業量が収まるかについて意見を述べることができず、ビジネスに最も重要なものを決定させ、それに合わせてスケジュールする必要があります。逃げるのはうまくいきません。彼らは新しいトレンディなアジャイル ワードを使用していますが、同じ古いことを行っています。

于 2010-10-01T17:30:48.440 に答える
9

(...) 彼は、特定のスプリントに何が入ったかについての意見を一切許可されず、計画やグルーミング活動にも参加しませんでした。

明らかに、彼らは依然としてコマンド アンド コントロールとマイクロ管理を行っており(チームは権限を与えられておらず、自己組織化も行っていません)、プッシュ ベースのスケジューリングを使用しています(プル スケジューリングを有効にしていませんでした)。

スクラムには他の特徴がありますが、上記の点は、彼らがスクラムを行っていないことを示すのに十分すぎるほどです.彼らがどのように名前を付けようと、彼らは時代遅れのウォーターフォールアプローチから実際に移行していません. ）。

これは、スクラムが何であるかについて、彼らがまだ完全に無知であり、まったく理解していないことを示す大きなヒントです。そして、これは、彼らが変更したい場合でも、いくつかの検査と適応なしには変更されません. これを実現する力がない場合は、逃げてください。

于 2010-10-01T19:46:18.333 に答える
7

これがスクラムの扱い方ですか?

いいえ。

于 2010-10-01T17:31:07.887 に答える
3

私は自分たちをアジャイルと呼ぶ場所で働きました。6〜8か月のリリースサイクルがありました。いくつかのことはバックログから来ましたが、「要件の収集」フェーズでは、基本的にマネージャーは社内のさまざまな人々と1〜2週間の会議を行い、機能リストを作成します。各4週間の「イテレーション」の初日、開発チームは全員が集まり、一連の会議ですべてを分解しました。イテレーションの最終日はデプロイメント日でした。そこでは、開発チームの外部の誰も見たことのないイントリムデプロイメントがありました。

8か月のリリースサイクルの間、マネージャーはリリースの最後の2か月に1〜2回、関係者と連絡を取ります。その時点で、リリース前に完了する可能性があった会議で提起された問題は、それらが実装されていない場合、全体の努力を役に立たなくするのに十分に悪い問題。

これはアジャイルではありません。これはウォーターフォールのバリエーションであり、他の方法論から選択されたアイデアや方法論の選択肢が不十分です。結局のところ、滝と同じ問題がまだ残っています。

私がそこで学んだ教訓は、開発方法論には理由があるものが含まれているということです。方法論を完全に理解せずに（そして完全に理解することで、実際にそれを使って作業したことを意味します）、方法論からチェリーを選ぶ場合、全体にとって実際に非常に重要なものを使用しない可能性が高くなります。たとえば、xpでは、ケントベックは、事前の設計を削減する方法として、後でリファクタリングに依存することを提唱しています。ただし、これが実際に機能する唯一の理由は、彼がTDDとペアプログラミングも提唱していることです。包括的なテストスイートがあり、全体に追加の目がある場合、リファクタリングはかなり安全です。最初の部分をチェリーピックして、それら2つを除外すると、基本的にカウボーイコーディングになります。

私はこの理由で独自の方法論を展開する買い物客に非常に懐疑的です。アジャイルの名の下に犯されている犯罪の量は絶対に衝撃的です。

于 2010-10-01T18:20:55.450 に答える
3

これがスクラムの扱い方ですか?

絶対にありません。スクラムは透明性の向上に努めています。開発者が活動を計画するのをブロックすることで、彼らはスクラムが示唆することとは反対のことをしています。

ここで 2 つのポイントについて話しました。2. バックログ グルーミング - ここでは必要な場合とそうでない場合があります。リソースを賢く、常識を持って使用する必要があります。ここでは、開発者としての経験が豊富なチーム メンバーが 1 人いれば問題ないと思います。

スクラムにはもう 1 つのタイプがあります。

リリース計画 - ここでは開発者は必要ないと言う人もいるかもしれません。しかし、スクラムガイドによると、「リリース計画には、リリースの製品バックログの見積もりと優先順位付けが必要です」。優先順位付けは PO が行い、利害関係者が提案することもできますが、見積もりは実際に作業を行う人が行う場合に最も正確になるため、ここに開発者を関与させることをお勧めします。繰り返しますが、リソースは賢く使用する必要があります。すべての開発者を巻き込むのではなく、順番を交代して見積もることが理にかなっているのであれば、それは悪い考えではありません。

この構造に従うことをお勧めします: スプリント計画 - パート 1: プロダクト バックログからスプリントのバックログを見積もって引き出します (PO、SM、およびチームはここでは豚です) スプリント計画 - パート 2: タスキング、タスク時間の見積もりとそれらの分解 (SM とチームは豚、PO もタスクを実行しない限り、PO は鶏です)

于 2010-10-01T19:40:53.447 に答える
2

スプリント計画会議中に、選択した製品バックログを出荷可能な製品機能に変える方法を理解するのはチーム次第です。このプロセスに参加していない場合、コミットすることはできません。

于 2010-10-01T17:39:39.043 に答える
2

タイトルの質問に対する答えは次のとおりです。開発者 (チーム) は計画会議に参加する必要があります。開発者（チーム）向けの企画会議です。

適切なアプローチは、各スプリントの開始時に 2 つの計画会議 (計画会議 1 と計画会議 2) を開催することです。チームとチームは、最も優先度の高いユーザー ストーリーについて話し合い始めます。議論された各ユーザー ストーリーについて、チームは以下を収集できる必要があります。

  • 詳細な要件 (たとえば、入力フォームに必要なフィールドなど)
  • 制約 (機能の速度など)
  • 受け入れテスト（結果の検証）
  • UI スケッチ (たとえば、UI フローがどのように見えるか)
  • 受け入れ基準 (エンドユーザーからの検証 - 受け入れ基準は実際のテストである必要はありません。「使いやすさ」などに関連するものである可能性があります)

計画会議 1 の時間境界があるはずです。話し合うことができたユーザー ストーリーの数は、次のスプリントで完了することができるユーザー ストーリーの数に対応している可能性があります。計画会議の最後に、1 つのチームが約束をする必要があります。議論されたユーザー ストーリーのうち、今後のスプリントで実行される予定の数を伝えます。スプリント計画会議 2 は、チームがユーザー ストーリーについてさらに話し合い、タスクに分割するため、チーム専用です。

于 2010-10-02T08:25:11.330 に答える
1

一般的に、もちろんそうすべきです。明らかに、開発者が望んでいるほど現実的には不可能です。ただし、スプリントが通常、開発者が真剣なインプットをまったく得ない「Hair On Fire」タイプの業務である場合は、少なくとも定期的にスケジュールされた「エントロピー削減」スプリントが必要です。がらくたをきれいにする目的で開発者。

于 2010-10-01T17:35:07.800 に答える
0

チームは、正式なプロセスや会議なしで計画プロセスに関与できます。計画プロセスは非常に流動的です。開始時の目標は、スプリントをできるだけ早く開始することです。最初のスプリントが非常に滝を感じる前に計画に多くの時間を費やすと、みんなの時間の無駄になります。私は、チームメンバーとして、組織の機能不全の性質を示しているという事実を除いて、その一部ではないことに安心します。チームは常に継続的に自由にアイデアを表明する必要があります（実際の計画が行われるのはそのときだからです）。しかし、あなたが言及した2つのことが私に最も関係があります。

まず、このスプリントで実行できるバックログアイテムの数を決定するのはチームだけである必要があります。彼らは確かに努力の見積もりに関与するでしょう。それは大きな問題です。

第二に、チームはプロダクトオーナーにアクセスできるようには聞こえません（おそらくここには1人もいないでしょう）。チームがこれまで「計画」に関与していなくても、計画会議でプロダクトオーナーと話していたり​​、他の時間にそれらにアクセスしたりした場合は、時間の経過とともに提案を表明します。

于 2010-10-04T21:29:15.340 に答える
0

私は自分のインプットについてはあまり心配していませんが、自分の洞察について心配しています。私は最近、計画が完成したと思われる私に手渡される前に、そのプロジェクトについて何も知らなかったプロジェクトに参加しました。悪夢は、プロセスが完全に考え抜かれておらず、データ定義が完全ではないことに気付いたときに始まりました。必要な答えを得るために、プロセス全体をもう一度実行する必要がありました。

于 2010-10-01T20:03:42.463 に答える
0

作業を適切に見積もり、パイプライン化できるように、少なくとも何人かの開発者がそこにいる必要があります。

しかし、すべての開発者がそこにいる必要はありません。それがより理にかなっていれば、すべてがそこにある可能性があります。

一方、開発者は、ビジネスの優先事項が優先事項であることを理解する必要があります。次に何をすべきかは関係ありません。それを機能させるには、全員が協力しなければなりません。

于 2010-10-01T17:34:55.030 に答える