だから私は機能のバックログを持っており、私たちはかなりのプロジェクトを始めようとしています。私はスプリントの構造の定義に取り組んでおり、コミュニティのフィードバックに興味があります。
私が考えているのは：
スプリントは常に火曜日に終了する必要があります（週末のストレスを避けます）。
他に何か？これよりもアジャイルには明らかに多くのことがあります。このプロジェクトを開始するにあたり、私たちがどのように運営するかについての簡単な概要をチームに提供したいと思います。
1 か月よりも短いスプリントを試してみることを検討します。
個人的には、効果的なフィードバックを迅速に得るには、1 ～ 2 週間のイテレーションの方が効果的だと思います。また、イテレーション レベルで問題を引き起こしている可能性のある問題が、管理が難しくなるレベルまで構築されるのを防ぎます。
30 日間のスプリントの場合でも、スプリント レビューに 2 日間は約 1 日かかります...そして 1 日はふりかえりに約 0.5 日かかります。それ以上のことが必要な場合は、繰り返しが行われている間にコミュニケーションの問題が発生していることがわかりました。そのため、長いレビューが必要になる可能性があることを危険信号として検討することをお勧めします.
もちろん、これは私の経験に過ぎません。ほとんどの場合、小規模な (4 ～ 12 人の) チームで Web アプリを開発しています。あなたの経験は異なる場合があります。
そうは言っても、私は間違いなく短いスプリントを試してみます. 統合ビルドのように、頻繁に行うと多くのことが簡単になります。
コア コードの時間には、メール、携帯電話、インスタント メッセージング アプリをオフにします。これには、午前 10 時から午後 1 時、午後 2 時から午後 5 時が適しているかもしれません。
チームが「ゾーン」にいるときに、チームの食べ物や飲み物を注文します。
計画セッションの前日、後日、およびレビュー日の他のすべての会議をキャンセルします。
良いアプローチのように見えます。Adrianh と jedidja がおそらくより短い反復について言ったことに賛成です。私自身は1weekersが好きです。より良い見積もりだけでなく、「動作するソフトウェア」のアイデアをより短いサイクルで維持します。
いくつかの質問：
コードレビューが最後まで残されるのはなぜですか? ペア プログラムを行うか、進行しながらレビューを行います。
3 週間の開発は、「開発、テスト、ドキュメント、インストーラーなど」を意味しますか? つまり、あなたが本当に行う必要があるすべてですか？
スプリントが終わるまでコード レビューを延期することはお勧めしません。コード レビューは開発プロセスの不可欠な部分であるべきです。言い換えれば、コードがレビューされていない限り (そしてテストされ、文書化されていなければ)、タスクは完了していません。
スプリントレビューがスプリントの最終日であり、通常は約 1 時間続くことを除いて、スプリントは概要と非常によく似た構造になっています。スプリント レビューは、コード レビューを行う時間ではなく、顧客やその他の利害関係者に作業を示す時間です。コードレビューを行うことを選択した場合は、スプリント全体で定期的に行う必要があります。以前は、毎週 1 時間のブロックがあり、開発者が指定したコードを検討していました。つまり、書かれたすべての LOC をレビューするのに時間を無駄にしませんでした。
また、火曜日にスプリントを終了し、水曜日に出発する木曜日に開始して、ルーズエンドをまとめ、スプリント中に作成された技術的負債に取り組みます。
管理のために管理から離れることが重要です。SCRUM は 1 日に 1 回のミーティングしか必要とせず、それは短いものです。さらに、各スプリント中のその他のミーティングは、春のふりかえりとスプリント計画のみです。これにより、ROWE、つまり結果指向の作業環境を実装できます。いつ、どこで、どのように開発を行うかは、開発者に任せてください。毎日のスタンドアップを使用して、彼らが仕事をしていることを追跡します。それ以外は、後ろに下がって、その生産性に驚かされます。
「コーディング中に携帯電話の電源を切ったり、IM アプリを切ったりする」などの考えはすべて悪い考えです。あなたのチームを雇うとき、あなたは彼らが自分の仕事を正しく行う方法を知っているという自信を持って彼らを雇っています. その理解を持って彼らを雇ったのなら、なぜ彼らが可能な限り最善の方法で仕事を成し遂げる能力を制限したいのでしょうか? SCRUM を使用している場合、各開発者は自分ができると思う作業を選択したことになります。スクラム マスターとしてのあなたの仕事は、障害を作成することではなく、障害を取り除くことです。
コード レビュー: 絶対に必要です。コードのピア レビューは、ミーティングに参加している若手開発者や、コードのレビューを受けている開発者にとって優れた教育ツールです。
設計書: 個人的には、開発者が何をしようとしているのかをカバーする詳細な設計書は非常に重要であり、開発プロセスの重要な部分でもあると感じています. これは特にアジャイル開発に沿ったものではありませんが、個人的には何年も前に作成された設計ドキュメントを定期的に参照して、元の開発者がモジュールをコーディングしたときに何を考えていたかを確認しています。