問題タブ [agile]

アジャイルを使用している場合でも、プロジェクトの実装を開始する前に、高レベルのアーキテクチャが必要になります。

高レベルのアーキテクチャとは、プロジェクトを小さな部分、インフラストラクチャ、分散型/Web ベース/シック クライアントなどに分割することを意味します。

このトピックに関する書籍や記事はありますか??

スクラムとの対話における RUP

アジャイルとRUPには関係があります。実はアジャイル開発はRUPの一種だと思っていました。上記の IBM の記事では、モデルを RUP に適合させていることがわかります。

誰かがこれら 3 つの興味深い概念間の関係について実用的な説明を持っていますか?

組織にスクラムを実装したことのある人にとって、最大の障害は何でしたか。それを克服した場合、どのようにしたらよいでしょうか。

SCRUM を使用したいソフトウェア開発会社で、1 人が複数の役割を担っていても問題ないと思いますか?

例: 人が

• SCRUMマスターとチームメンバー
• プロダクトオーナーとチームメンバー
• SCRUMマスターとプロダクトオーナー

どの組み合わせが可能だと思いますか? あなたはそのようなチームで働いていますか？1 人が複数の役割を担っている場合、何を考慮する必要がありますか?

ヒントをありがとう。

私は、スクラムのメリットとプロセスについてかなりよく読んでいます。バックログ、バーンダウン チャート、イテレーション、ユーザー ストーリーの使用、およびスクラム「フレームワーク」のその他のさまざまな概念に関するアイデアを得ることができます。

そうは言っても... 私は、「制作チーム」を構成する6人のチームメンバーで、一度に複数のプロジェクトを管理するWeb開発会社で働いています。

複数のプロジェクトを持つスクラムはどのように機能しますか? 一定の時間内に 1 つのプロジェクトの反復をスケジュールし、チーム全体がそれに取り組み、その反復が完了すると、新しい反復で次のプロジェクトに移りますか? それとも、同時に 1 つのチームだけで独自の反復を行う複数のプロジェクトを管理する「アジャイル」な方法はありますか?

私の会社は最近スクラムを使い始めました。2回のスプリントを行いました。私たちはまだ学習中ですが、開発プロセスのいくつかの問題を明らかにして修正しました。ですから、一般的にはそれは私たちにとって良いことだと思います。

福音書記者、皮肉屋、そしてその間のすべての人からのスクラムに関するインターネットの思索の多くを読んで、3つの一般的でやや矛盾したテーマが私に際立っていました：

1. スクラムのプロセスが十分に厳密に実行されていないため、スクラムの実装は失敗します。
2. 組織がスクラムを独自の環境/文化/慣行に適応させていないため、スクラムの実装は失敗します。
3. スクラムのプロセスは重要ではありません。アジャイルマニフェストの値のみが重要です。

これらの例は、これらのSO質問への回答で見ることができます。

• スクラムやスプリントで悪い経験をしたことがありますか？
• スクラムは悪ですか？
• アジャイル開発は死んでいますか？

スクラムのすべてのガイドラインにまだ従っていないことを認めなければなりません。スプリントの最後にリリースを行っていません。スクラムマスターは、タスクをスプリントのバックログから最後の方に移動することを望んでいません。いくつかの例として、彼が私たちの計画がどれだけずれているかを確認できるように（つまり、バーンダウンチャートが0になることはありません）、緊急のカスタマーサポートの問題には、すべての人の計画を混乱させる信じられないほどの力があります。

私の質問は、これらの問題やその他の問題を解決しようとする際に、公式のスクラムプロセスに近づこうとするのが良いのか、スクラム前のプロセスのいくつかに近づくのが良いのか、それともスクラムの原則について瞑想するのが良いのかということです。まったく別のプロセスを考え出してみてください。

私の会社は、最初の大規模な開発プロジェクトの問い合わせを受けたばかりで、アジャイル プロセスを使用したいと考えています。クライアントはアプリケーションのビジョンを持っていますが、要件がほとんどないことを公然と認めており、時間単位で請求する必要があることを認識しています。このため、私は彼にアジャイル アプローチを勧めました。

問題は、彼が予算を立てる人物を望んでいることです。私は、クライアントがその数の予算を立て、要件が変わっても、彼らの頭の中や本の中の数はそうではないので、見積もりをあきらめないように主張する多くの記事を読みました.

契約の価格設定を考慮に入れる方法はいくつかあると読んだことがありますが、そのほとんどすべて (1 つを除く) に事前の数字が組み込まれています。これは、アジャイル開発の原則全体に違反しているように見えます。

そこで私の質問は、あなたがアジャイル開発者である場合、どうすればこのアジャイル開発のキャッチ 22 を回避できるのでしょうか?

開発にスクラム プロセスを使用し始めています。現在、すばらしいユーザー ストーリーの山があります。ユーザー ストーリーが完成し、テストされ、展開されたら、それを使って他に何かすることはありますか? 今使っているインデックスカードは小さいので、ゴミ箱に捨てるだけでいいと思います。

それらを保持している場合、後でそれらをどうしますか?

スクラムがウォーターフォール プロセスよりも優れている点を 1 つ挙げるとしたら、それは何ですか?

イテレーションの計画中に、私たちはこの男と同じ立場にいることがよくあります -経験がない場合にプログラミングタスクを見積もる方法

合理的な見積もりを出す前にプロトタイピングを行うことに私は間違いなく同意します。しかし、少しのアーキテクチャと設計が必要な場合にも同じことが当てはまりますが、スプリントの範囲外でこれらすべてを行うのはあまり快適ではありません。

基本的な考え方は、自信を持ってできる限り多くのタスクを特定し、それらを通常と推定することです。不明な領域については、調査と実装という 2 つの「タイプ」のタスクが特定されている必要があります。

調査タスクは、「Control X をデータにバインドする方法を調査する」など、不明な作業の簡単な説明です。これらについては、概算が提示されます。

実装タスクは、おそらく割り当てられたストーリー ポイントに基づいて、機能を実装するのにかかると思われる時間を大まかに推測したものです。

スプリント中に調査タスクが完了すると、開発者は何が起こっているのかをよりよく理解できる段階にあるはずです。その後、「適切な」タスクを識別できます。これは、実装プレースホルダーの代わりになります。さらに、この段階でさらなる調査タスクが特定される可能性があり、サイクルは継続します。

上記の例では、7 時間の調査タスクと推定 14 時間の実装タスクから開始します。最初の調査が完了すると、タスク 1、2、および 3 が特定され、ある程度確実に推定されます。ここで、タスク 3タスク 4 と 5 は後の段階で識別される別の調査タスクです。ご覧のとおり、最初の実装見積もりでは 14 時間以内に機能が配信されましたが、実際には少なくとも 4 + 7 + 3 + 4 + 2 = 20 かかりました。最初の見積もりよりも 3 分の 1 長くなりました。

代替テキスト http://www.duncangunn.me.uk/myweb/images/estimate.png

すべての考えを歓迎します - 私の本能はこれが飛ぶということです - 私は正しいですか、それとも私は間違った兄弟ですか?

乾杯！