スクラムを学術環境にどのように適合させることができますか？

現在、大学で提供されているソフトウェアエンジニアリングおよびキャップストーンデザインコースの新しいカリキュラムを開発するために、大学の教授と協力しています。

最近まで、両方のコースでウォーターフォールモデルを排他的に使用していたため、学生は長い時間をかけてレポートを作成していました。私からの多くのプレッシャーの後、私の教授は、この学期にスクラムをソフトウェアエンジニアリングカリキュラムに含めることにしました。

学期の前半はまだ滝のようで、学生は40ページの設計レポートとソフトウェア仕様書を書きました。学期中期には、すべてのチームがアプリケーションのデモをリリースする必要がありました。その時点で、コースはスクラムに切り替わり、3週間のスプリントが2回行われました。現在、ウォーターフォールを完全に排除し、スクラムベースのカリキュラムのみを作成する方法を考えています。

残念ながら、スクラムと学生の間でいくつかの非互換性が発生しました。

• 毎日のスクラム会議は、学生にとってほぼ不可能です。授業中であっても、教授が通常講義しているため、学生がスクラム会議を開催するのは不便です。
• 学生は経験が浅いため、何か時間がかかるのを正確に予測できないため、ポイント/時間の推定は困難です。
• スクラムは、常勤の同じ場所にいる開発者に最適ですが、学生もそうではありません。せいぜい、学生はコースに週15〜20時間を捧げ、仕事の会議を開催することは非常に困難です。チームには最大10人の生徒を含めることができます（常に1人または2人の怠け者がいます）。
• 教授はドキュメントを切望しています！スクラムレポートは聞いていません。バックログとバーンダウンチャートだけです（アカデミックをなだめるのに十分かどうかはわかりません）。
• 学生はしばしば、アジャイルは「すぐにジャンプして、振り返らずにコーディングを開始する」ことを意味すると思います。これは、想像できる最も恐ろしいコードの一部につながります。したがって、50ページのドキュメントやUMLダイアグラムの山を必要とせずに適切な設計を実施する方法を探しています。

これらの問題を考えると、教授と私はスクラムをアカデミックな環境で機能するようにどのように適応させることができると思いますか（そもそもスクラムを気にする必要がありますか）。また、ウォーターフォールモデルを教えることにはまだ価値がありますか？

フィードバックを事前にありがとう！

ウォーターフォールをあっという間に捨ててしまうのをためらうでしょう。

これは実際にソフトウェアシステムを構築するための欠陥モデルですが、ライフサイクルの各段階で優れたプラクティスを指導するのは悪い教育モデルではありません。プロジェクトに適用するプロセスモデルに関係なく、要件エンジニアリング、システムアーキテクチャと設計、実装、テスト、リリース、およびメンテナンス（リファクタリングと拡張を含む）を実行します。違いは、これらのフェーズがどのように編成され、実行されるかですが、すべてのアクティビティが引き続き発生します。

プロジェクトの途中でWaterfallからScrumに移行するのは最良のアイデアではないと主張します。スクラムの成功の鍵は、長期にわたるプロジェクトです。最初の3〜5回のスプリントは、チームが速度に落ち着き、プロセスを学習し、チーム開発を行うことです。モーションを介して実行していますが、その時点では実際にはスクラムではありません。さらに、スクラムのみに基づいたカリキュラムを作成しようとすることは、スクラムが特効薬ではないため、おそらく悪い考えです。単一の方法論よりもベストプラクティスを教える方が良いでしょう。労働力では、すべてのプロジェクトがスクラムを使用するわけではありません。実際、一部の環境では、スクラムはプロジェクトの成功に有害です。

アカデミックな環境でスクラムの問題を既に発見しているため、適切に対処するのが難しいものもあります。

非互換性リストにある問題ではないのは、推定が難しいことです。はい、そうです。しかし、推定を向上させる唯一の方法は、実際の推定値と推定値を比較することです。学生は、さまざまな手段（ストーリーポイント、コードのソース行、時間、ページ、人時間）を使用してサイズ、時間、および労力を早期に見積もる必要があります。

文書化の必要性は、教授の観点と学生の観点の両方から対処できるものです。リーンアプローチでは、チームにも顧客にも価値をもたらさないドキュメントは無駄です（時間とコストの面で）。ただし、学生と教授（顧客/クライアント）の両方の目的をさまざまな目的で達成するには、いくつかのドキュメントが必要です。全体として、プロセス調整と定量的プロジェクト管理（アジャイル手法でも役割を果たします）を教える機会のように思えます。

スクラムの会議とスケジューリングに関して、2つのアイデアが思い浮かびます。1つ目は、これはスクラムがアカデミックな環境で使用するのに最適なプロセスではない可能性があることを示していることです。（特に）スケジュール、人員配置、可視性、開発チームの経験などの要素を含む、ソフトウェアプロジェクトに特異な「最適なプロセスモデル」はありません。

全体として、単一の方法論よりも優れた実践、プロセス調整、およびプロセス改善を強調することをお勧めします。これにより、コースを受講するすべての人に最も効果的になり、さまざまなプロセス方法論にさらされ、特定の条件のベストプラクティスが何であるかを理解できます。

あなたは大学のカリキュラムを構築するために取り組んでいるので、私が参加した大学のソフトウェアエンジニアリングカリキュラムがどのように適合するかについて、高レベルの概要を説明します。

ソフトウェアエンジニアリングの入門は、ウォーターフォールモデルでプロジェクトを実施し、各フェーズでの講義は、そのフェーズのアクティビティを実施するさまざまな方法に対応していました。チームは同じ割合でフェーズを進みました。これらの明確に定義された境界を、チームでソフトウェアを構築するための作業経験がまったくないか最小限の人々のグループの教育モデルにうまく適合させます。コースを通して、他の方法論-さまざまなアジャイル手法（Scrum、XP）、Rational Unified Process、Spiral Model-の利点と欠点について言及されました。

アクティビティに関しては、要件エンジニアリング、アーキテクチャ、および設計について議論する特定のコース（2つのコース-オブジェクト指向手法を使用した詳細設計に焦点を当てたコースと、システムアーキテクチャに焦点を当てたコース）がありました。システムのクラス（リアルタイムおよび組み込みシステム、エンタープライズシステム、コンカレントシステム、分散システムなど）、およびソフトウェアテスト。

ソフトウェアプロセス専用の3つのコースもあります。複数の方法論に関してソフトウェアプロジェクトを管理するためのベストプラクティスに焦点を当てたソフトウェアエンジニアリングプロセスおよびプロジェクト管理。2番目のプロセスコースでは、測定、メトリック、およびプロセスの改善（CMMI、シックスシグマ、およびリーンを強調）を学びます。最後に、スクラム方法論を使用して実行されるプロジェクトを使用して、アジャイルソフトウェア開発（スクラム、エクストリームプログラミング、クリスタル、DSDMについて説明）を教えるプロセスコースがあります。

capstoneプロジェクトは、スポンサー企業のために実行され、スポンサーと教員アドバイザーの両方からの指導を受けて、学生プロジェクトチームによって完全に実行された2四半期のプロジェクトでした。プロジェクトの実施方法のあらゆる側面は、スポンサーが定める制約の範囲内で、学生次第です。大学が義務付けた唯一の締め切りは、プロジェクトの途中（10週間）での中間プレゼンテーション、最後の最終プレゼンテーション、および終わりの少し前のクワッドポスタープレゼンテーションでした。他のすべては、スポンサーとチームの同意次第でした。

ソフトウェアエンジニアリングの修士号を取得したとき、XP、スクラム、その他のアジャイルアプローチを扱うソフトウェアプロセスと呼ばれるコースがありました。基本的に、クラス全体が仮想のソフトウェア会社を形成し、コースの実行中にかなり精巧なソフトウェアを開発するように指示されました。講義は、XPの実践、スタンドアップミーティングの実施などに関するものでした。

ほとんどの学生はこれらのテクニックについて聞いたことがあり、通常はそれらを適用することに熱心です。もちろん、チームに実際に反復的に作業を強制する方法などはありません。しかし、それは実際にコースのポイントでした。それは、それ自体が多くの短い会議、反復作業、継続的なビルド、人々のグループと短い時間で価値あるものを生み出す最も簡単で信頼性の高い方法です。

覚えておくべきことの1つは、顧客とうまくやり取りし、いくつかの重要な要件を途中で変更することです。または、最初に言及するのを「忘れる」。

その時点で、コースはスクラムに切り替わり、3週間のスプリントが2回行われました。現在、ウォーターフォールを完全に排除し、スクラムベースのカリキュラムのみを作成する方法を考えています。

目的は開発を促進するのか、スクラムを学ぶのか、それとも-私の推測では-両方ですか？学習プロセスをスピードアップするために、短距離のスプリントを検討します。

•毎日のスクラム会議は、学生にとってほぼ不可能です。授業中であっても、教授が通常講義しているため、学生がスクラム会議を開催するのは不便です。

おそらく、学生にとって最適な場合は、毎日のスタンドアップをより厳格でない形式に置き換えることができます。また、すべての会議に全員が参加する必要はありません。

•ポイント/時間を見積もることは困難です。なぜなら、学生は経験が浅いため、何かがどれくらいかかるかを正確に予測できないからです。

同じ理由で、カレンダーの時間を見積もるのはさらに難しくなります:-)ストーリーポイントでは、どれだけ時間がかかるかを見積もらず、相対的なサイズを見積もることができます。期間が導出されます。

•Scrumは、フルタイムの同じ場所にいる開発者に最適ですが、学生もそうではありません。せいぜい、学生はコースに週15〜20時間を捧げ、仕事の会議を開催することは非常に困難です。チームには最大10人の生徒を含めることができます（常に1人または2人の怠け者がいます）。

小さいチームで試してみませんか？10は、スクラムチームの上位スケールです。非フルタイムの分散チームでも同様に成功できると思いますが、もちろん難しいです！それ自体がレッスンになります。

•教授はドキュメントを切望しています！スクラムレポートは聞いていません。バックログとバーンダウンチャートだけです（アカデミックをなだめるのに十分かどうかはわかりません）。

スクラムは、必要なドキュメントの種類を指示しません。実際のところ、バーンダウンチャートでさえ必須ではありません。これは、ドキュメンテーションが禁止されていることを意味するものではありません。チームは、必要と思われるレポート教授を含む、必要なドキュメンテーションを作成する必要があります。

•学生はしばしば、アジャイルは「すぐにジャンプして、振り返らずにコーディングを開始する」ことを意味すると考えています。これは、想像できる最も恐ろしいコードの一部につながります。したがって、50ページのドキュメントやUMLダイアグラムの山を必要とせずに適切な設計を実施する方法を探しています。

学生だけではありません:-)ほとんどのスクラムチームは、TDD（テスト駆動開発）やリファクタリングなどのXPプラクティスを使用しています。それをカリキュラムに組み込むことをお勧めします。

また、ウォーターフォールモデルを教えることにはまだ価値がありますか？

はい、少なくとも次の2つの理由があります。1つ目は、学生がワークライフでスクラムを使用するかどうかということではありません。2つ目は、アジャイル開発の本質を比較するものがあれば理解しやすいことです。

それは私が一度取った主題に少し似ているように聞こえます。

いくつかの考え：

• 本当にチーム全体のスクラム会議がありますか？サブチームは機能しますか？
• 「振り返らずに」がリファクタリングを意味しない場合、リファクタリングの証拠を評価しますか？
• 反省と文書化を評価する-生徒に活動のブログを維持してもらいます。（これは実際に職場で非常に役立つスキルです-ほとんどの正式な文書よりもはるかに）
• 推定値が悪い場合、うまくいけば学習している-推定値と現実の変動を追跡し、違いを反映し、何かを学んだことを実証できますか？
• 適切な設計を文書化する正式な方法はありませんか？
• 一部のスクラム会議には、SkypeやGchatなどで十分ですか？

私のアドバイスは、あなたが教えようとしているものを分離して隔離することです。ソフトウェア設計またはその他のソフトウェアエンジニアリングの科目（アルゴリズムまたはその他）のコースである場合は、それに焦点を合わせます。SCRUMの関与が障害になった場合（あなたが暗示するように）、それを気にしないでください。

私が大学にいたときにこれをどのように行ったかは、アジャイル方法論のための専用コースを持つことでした。このコースには、SCRUMまたはXPに従って実行される開発プロジェクトが含まれていました。コースの焦点はプログラミングや設計ではなくプロセスであったため、配信される実際のソフトウェアは些細なものでした。ここでの理由は、「ハードコア」ソフトウェア開発科目と方法論科目を混在させてはならない理由と同じです。一方の生徒は他の生徒を食いつぶす傾向があり、学生はその段階で両方を処理する準備ができておらず、十分なスキルもありません。

コースの成果物は、スプリント計画レポート、週ごとの進捗レポート、回顧録、バーンダウンレポートに加えて、TAが循環して聞くグループスタンドアップ/スクラム会議を含む最低2つのセッションが毎週行われました。

このコースにはTDD（テスト駆動開発）も含まれており、非常にうまく機能しました。

また、ウォーターフォールモデルを教えることにはまだ価値がありますか？

確かにそうです。多くの企業は、プロジェクトにこのモデルのバージョン（PPS、RUP、PROPSなど）を使用しています。多くの人が（正確には、私の意見では）「純粋な」SCRUMはプロジェクトよりも継続的なメンテナンスに適していると感じています。SCRUM（および一般的にはアジャイル）には、範囲に一定の柔軟性があり、途中で要件と配信をネゴシエートできる可能性が必要です。すべてのプロジェクトがそのように機能するわけではなく、バイナリです。YポイントでXを配信し、他のすべては失敗です。

アカデミックソフトウェアエンジニアリングコースのポイントは、ソフトウェアライフサイクルの基本段階-分析、設計、実装、テスト、および通常の宿題品質コードの代わりに実際のソフトウェア品質基準を使用することを教えることです。

非ウォーターフォールプロセスを使用して実践を実証することには価値がありますが、スクラムが適切なプロセスではないことを意味する理由により、学生は学期ごとに多くのコースを受講し、多くは勉強中に実際の仕事も持っているため、100専任のチームメンバーの割合、または毎日の会議を実施する。

代わりに、UP（RUP）などのアジャイル性の低い反復プロセスの使用を検討してください。

ウォーターフォールプロセスと比較した値を表示するには、反復間で要件を変更します。これは、UPとウォーターフォールの違いを示し、アジャイルプロセスを使用することの価値を示唆します。

UPは滝のすべての段階をカバーするため、この後の滝のデモンストレーションは冗長になります。

学期は比較的短いため、2回の小さな反復が現実的です。

このコースの重点は実装の深さではないため、学生が使用する幅広いフレームワークを提供します。そのための他のコースがあり、代わりにコーディング標準と単体テストを強調する必要があります。

コースでは、ウォーターフォール、UP、XP、SCRUM、かんばんなどのいくつかのプロセスの理論を説明します（他のトピック、例えば、執筆要件、UML、テストなど）。

上記のコースを修了した学生については、夏学期中にフルタイムの2週間を要する選択科目として、別のスクラムワークショップを検討してください。

スクラムは、学期/学期の長いプロジェクトがあり、クラスが6〜10人のグループに分かれている場合に機能します。その後、スクラム会議に授業時間の最後の10分間を捧げることができます。