質問

Web サイト ショップに推奨するアジャイル手法は何ですか?

私たちにはさまざまな小規模プロジェクトといくつかの大規模プロジェクトがあり、チームはプロジェクト間で連携し、マルチタスクを行っています。私たちはスクラムに非常に興味がありますが、現在私たちの時間の多くを占めている小規模プロジェクト (2 週間未満) には適用されないようです。

私たちの状況でアジャイル原則を実装するための代替手段は何でしょうか?

役に立ちましたか?

解決

私たちがスクラムを使い始めたのは、スクラムの正式な構造 (見積もり、ユーザー ストーリーの計画、タスクの計画、毎日のミーティング、振り返り) が、古い方法からより機敏になるのに役立ったからです。3 つの計画と見積もりの​​会議は、朝の会議でタスク/ユーザー ストーリー ベースで実行できることがわかりました。

ユーザー ストーリーごとに大きなピン ボードとピン オン インデックス カードを用意しています。ボードは、「未開始」、「進行中」、「完了」に分割されます。どのタスクも分解するのに 1 日以上かかることはありません。また、各ユーザー ストーリーは、それが必要になる日の毎日の朝の会議で分解されます。これにより機敏性が保たれ、ユーザー ストーリーとしての「機能」のリストをタスクに分割するのに時間を費やすことなく変更できるようになります。これにより、2 週間のプロジェクトも大規模なプロジェクトと同じように簡単に処理できるようになります。

速度を推定するために、週の終わりにカードを数えて、完了したタスクの数を確認します。欠点は、リリース計画とベロシティの推定がスクラムほど正確ではないことですが、このハイブリッド XP 手法により、開発者は準備ができたときにタスクに集中でき、会議にあまり時間を費やすことがなくなります。

タスクを小さくすることで、ソース管理へのより定期的なコミットも促進され、ビルド サーバーとデプロイメント スクリプトと組み合わせることで、少なくとも 1 日に 1 回アプリケーションの進行状況を提供できるため、クライアントからフィードバックを得るのに最適です。また、毎週の振り返りも行っており、正しい軌道に乗っているかどうかを確認するために、3 か月ごとに 1 週​​間アジャイル コンサルタントを雇っています。

他のヒント

スクラムは確かに 2 週間のプロジェクトに適用できます。スプリント期間を短縮することも、スプリントごとに複数のプロジェクトを実行することもできます。

また、プロジェクトで使用するさまざまな方法論の一部を選択できないということはありません。

プロジェクトごとに 1 つの方法論を試して、何がうまくいくかを確認してください。

これらのプロジェクトではTDD(テスト駆動開発)を使用すると多くのメリットが得られると思います。開発と設計に役立つでしょう。単体テストは、実装の詳細や設計上の決定に関する「マイクロ ドキュメント」にもなる可能性があります。

たとえ典型的なプロジェクトが小規模であっても、私なら 2 番目にスクラムを使いたいと思います。スプリントの長さは 2、3、または 4 日であると考えてください。スクラムの「大量の継続的なフィードバック」の基礎をプロジェクトに組み込むこともできます。

2 週間かけて何かに取り組み、最後には顧客に「ああ、それは私たちが望んでいたものではありませんでした!」と言われることは望ましくありません。

ケン・シュワバーの短編を聞いてください。 スクラムについて話す で終わった IT に関する会話 ところで、これには素晴らしいポッドキャストがたくさんあります。

それからティム・マッキノンの映画を観ます アジャイルについて話す で終わった InfoQ 素晴らしいトークやインタビューも満載です。

HTH。

乾杯、

ロブ

ケビンのように、現在のチームがどのように機能するかを確認する方法論を試してみるべきだと思います。XP やその他の新しい方法論を試すことにあまりオープンではない人もいます。また、小規模なプロジェクトと大規模なプロジェクトに応じて、さまざまな方法論を試す必要があります。2 週間のプロジェクトや 2 年間のプロジェクトの方法論は変わる可能性があります。2 週間のプロジェクトでは 1 回のイテレーションがあり、開始時に 2 週間全体の計画を立てることができますが、これは 2 年間のプロジェクトでは不可能です。

そのような小さなプロジェクトではスクラムは機能しません。その定義上、スクラム スプリントの長さは 2 週間です。XP のバリエーション、またはエクストリーム プログラミングの方がはるかに適しています。ただし、プロジェクトが複雑な場合、2 週間でプロジェクトを完了するには、開発者が非常に集中する必要があります。

また、どのような方法論を選択したとしても、チームに合わせてプロセスを変更することを恐れないでください。

スクラムをお勧めします。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top