スクラムはどのようにして学術環境に適応させることができますか？
現在、私の大学の教授と協力して、大学で提供されているソフトウェアエンジニアリングコースとキャップストーンデザインコースの新しいカリキュラムを開発しています。
最近まで、両方のコースでウォーターフォールモデルのみが使用されていたため、学生は長い時間をかけて長いレポートを書いていました。私からの多くのプレッシャーを受けて、私の教授はこの前学期にソフトウェアエンジニアリングのカリキュラムにスクラムを含めることにしました。
学期の前半はまだ滝のようで、40ページの設計レポートとソフトウェア仕様書を学生が書いていました。学期半ばには、すべてのチームがアプリケーションのデモをリリースする必要がありました。その時点で、コースは3週間のスプリントが2回あるスクラムに切り替わりました。私たちは今、ウォーターフォールを完全に排除し、スクラムベースの独占的なカリキュラムを作成する方法を理解しようとしています。
残念ながら、私たちはスクラムと学生の間でいくつかの非互換性に遭遇しました：
- 毎日のスクラム会議は学生にとってほぼ不可能です。授業中でも、先生が普段講義をしているので、スクラムミーティングをするのは学生にとって不便です。
- 学生は経験が浅いため、何かにかかる時間を正確に予測できないため、ポイント/時間の見積もりは困難です。
- スクラムはフルタイムで同じ場所に配置された開発者に最適ですが、学生もそうではありません。多くても、学生は週に15〜20時間をコースに費やしており、作業会議を組織することは非常に困難です。チームには最大10人の学生を含めることができます（また、常に1つまたは2つのスラッカーがいます）。
- 教授はドキュメンテーションを切望します！スクラムの報告は聞いたことがありません。バックログとバーンダウンチャートだけです（学者をなだめるのに十分かどうかはわかりません）。
- 学生は、アジャイルが「すぐにジャンプして、振り返ることなくコーディングを開始する」ことを意味するとしばしば考える。これは、想像できる最も恐ろしいコードのいくつかにつながります。したがって、50ページのドキュメントやUMLダイアグラムの山を必要とせずに適切な設計を実施する方法を探しています。
これらの問題を踏まえて、私の教授と私は、スクラムを学術的環境で機能するようにどのように適応できると思いますか？また、ウォーターフォールモデルを教えることにはまだ価値がありますか？
フィードバックをお寄せいただきありがとうございます。
私はウォーターフォール全体をすぐに捨てるのをためらいます。
これは実際にソフトウェアシステムを構築するための欠陥のあるモデルですが、ライフサイクルの各段階の適切な実践方法を説明するのは悪い教育モデルではありません。プロジェクトに適用するプロセスモデルに関係なく、要件エンジニアリング、システムアーキテクチャと設計、実装、テスト、リリース、およびメンテナンス（リファクタリングと拡張を含む）を実行します。違いは、これらのフェーズがどのように組織され、実行されるかですが、すべてのアクティビティは引き続き発生します。
プロジェクトの途中でウォーターフォールからスクラムに移行することは、最良のアイデアではないと思います。スクラムの成功の鍵は、長期にわたるプロジェクトです。最初の3〜5回のスプリントは、チームが一定の速度で落ち着き、プロセスを学び、チーム開発を行うことです。あなたはモーションを通してやっていますが、その時点では実際にはスクラムではありません。さらに、スクラムのみに基づいたカリキュラムを作成しようとすることは、スクラムが特効薬ではないため、おそらく悪い考えです。単一の方法論ではなく、ベストプラクティスを教える方が良いです。労働力では、すべてのプロジェクトがスクラムを使用するわけではありません。実際、一部の環境では、スクラムはプロジェクトの成功に悪影響を及ぼします。
アカデミックな設定でスクラムの問題をすでに発見しましたが、それらのいくつかは適切に対処することが困難です。
非互換性のリストで問題とならないのは、見積もりが難しいことです。はい、そうです。しかし、見積もりをより良くする唯一の方法は、見積もりを見積もり、見積もりと比較することです。学生は、さまざまな手段（ストーリーポイント、コードのソース行、時間、ページ、人時間）を使用して、サイズ、時間、および労力を早期に見積もる必要があります。
文書化の必要性は、教授の視点と学生の視点の両方から取り組むことができるものです。リーンアプローチは、チームにも顧客にも価値をもたらさないドキュメントは（時間とコストの点で）無駄であると教えてくれます。ただし、さまざまな目的で学生と教授（顧客/クライアント）の両方の目的を達成するには、いくつかの文書が必要です。全体として、それはプロセスの調整と定量的なプロジェクト管理を教える機会のように聞こえます（これはアジャイルメソッドにも役割を果たします）。
スクラムのミーティングとスケジューリングに関して、私の頭に浮かぶ2つのアイデアがあります。 1つ目は、これはスクラムが学術的な設定で使用するのに最適なプロセスではない可能性があることを示しています。ソフトウェアプロジェクトには、スケジュール、人員配置、可視性、開発チームの経験（特に）の経験など、単一の「ベストプロセスモデル」はありません。
全体として、単一の方法論よりも優れた実践、プロセス調整、およびプロセス改善を強調することをお勧めします。これにより、コースを受講するすべての人にとって最も効果的になり、さまざまなプロセス手法にそれらを公開し、特定の条件のセットに対するベストプラクティスを理解することができます。
あなたは大学のカリキュラムの構築に取り組んでいるので、私は ソフトウェアエンジニアリングカリキュラム を 私が参加した大学 でどのように組み合わせるかについて概要を説明します。
これは入門的なソフトウェアエンジニアリングであり、ウォーターフォールモデルでプロジェクトを通過しました。各フェーズでの講義は、そのフェーズのアクティビティを実行するさまざまな方法に対応しています。チームは同じ速度でフェーズを進めました。これらの明確に定義された境界を持つことで、ソフトウェアを構築するためのチームでの作業の経験がまったくない、または最小限の人々のグループの教育モデルにうまく適合しました。コース全体を通して、他の方法論（さまざまなアジャイルメソッド（Scrum、XP）、Rational Unified Process、スパイラルモデル）について、それらの長所と短所について言及しました。
アクティビティに関しては、要件エンジニアリング、アーキテクチャ、および設計について説明する特定のコース（2つのコース-1つはオブジェクト指向の方法を使用した詳細設計に焦点を当て、もう1つはシステムアーキテクチャに焦点を当てます）、さまざまな設計と実装に焦点を当てた多数のコースがありました。システムのクラス（リアルタイムシステムと組み込みシステム、エンタープライズシステム、コンカレントシステム、分散システムなど）、およびソフトウェアテスト。
ソフトウェアプロセスに特化した3つのコースもあります。複数の方法論に関してソフトウェアプロジェクトを管理するためのベストプラクティスに焦点を当てたソフトウェアエンジニアリングプロセスおよびプロジェクト管理。 2番目のプロセスコースでは、測定、メトリック、およびプロセス改善（CMMI、シックスシグマ、およびリーンを強調）について説明します。最後に、スクラム方法論を使用して実行されるプロジェクトを使用して、アジャイルソフトウェア開発（スクラム、エクストリームプログラミング、クリスタル、DSDMについて説明）を教えるプロセスコースがあります。
キャップストーンプロジェクトは、スポンサー企業のために実施され、スポンサーと教員アドバイザーの両方からのガイダンスを受けて、学生プロジェクトチームによって完全に運営された2四半期プロジェクトです。プロジェクトを実施する方法のあらゆる側面は、スポンサーによって定められた制約の範囲内で、学生次第です。大学が義務付けた唯一の締め切りは、プロジェクトの途中（10週間）の中間プレゼンテーション、最後の最終プレゼンテーション、および終了直前のクワッドポスタープレゼンテーションでした。それ以外はすべて、スポンサーとチームが同意することでした。
ソフトウェアエンジニアリングで修士号を取得したとき、XP、スクラム、およびその他のアジャイルアプローチを扱うソフトウェアプロセスと呼ばれるコースがありました。基本的に、クラス全体が架空のソフトウェア会社を形成し、コースの実行中にかなり精巧なソフトウェアを開発するように指示されました。講義は、XPプラクティス、スタンドアップミーティングの実施など）に関するものでした。
ほとんどの学生はこれらの技術について聞いたことがあり、通常それらを適用することに熱心です。もちろんforceチームが実際に反復して作業するなどの方法はありません。しかし、それが実際にコースのポイントでした。それ自体が、多数の短い会議を開催し、反復的に作業し、継続的なビルドを行う動機になることです。等々。それは、それが人々のグループと短い時間で価値のあるものを生み出す最も簡単で信頼できる方法であることがすぐにわかるからです。
覚えておかなければならないことの1つは、顧客とうまくやり取りし、途中でいくつかの主要な要件を変更することです。または、最初にそれらを言及するのを「忘れる」。
その時点で、コースは3週間のスプリントが2回あるスクラムに切り替わりました。私たちは今、ウォーターフォールを完全に排除し、スクラムベースの独占的なカリキュラムを作成する方法を理解しようとしています。
開発を促進する目的か、スクラムを学ぶ目的か、それとも-私の推測では-両方ですか？私は学習プロセスをスピードアップするために短いスプリントを検討します。
•毎日のスクラム会議は学生にとってほぼ不可能です。授業中でも、先生が普段講義をしているので、スクラムミーティングをするのは学生にとって不便です。
おそらく、生徒にとって最も効果的な場合は、毎日のスタンドアップをそれほど厳格でないフォームに置き換えることができます。また、誰もがすべての会議に参加する必要があるわけではありません。
•学生は経験が浅いので、何かにかかる時間を正確に予測することができないため、ポイント/時間の推定は困難です。
同じ理由で、カレンダー時間の見積もりはさらに困難です:-)ストーリーポイントでは、何かにかかる時間を見積もりません。その相対的なサイズを見積もります。期間が導出されます。
•Scrumは、フルタイムで同じ場所に配置された開発者に最適ですが、学生もそうではありません。多くても、学生は週に15〜20時間をコースに費やしており、作業会議を組織することは非常に困難です。チームには最大10人の学生を含めることができます（また、常に1つまたは2つのスラッカーがいます）。
小さなチームで試してみませんか？ 10はスクラムチームの上位スケールです。フルタイム以外の分散チームでも成功できると思いますが、もちろん難しいです！それ自体が教訓になります。
•教授はドキュメンテーションを切望します！スクラムの報告は聞いたことがありません。バックログとバーンダウンチャートだけです（学者をなだめるのに十分かどうかはわかりません）。
スクラムは、どのような種類のドキュメントが必要かを指示しません。実際のところ、バーンダウンチャートでさえ必須ではありません。これは、ドキュメントが禁止されているという意味ではありません。チームは、教授が必要と考えるレポートを含め、必要なドキュメントを作成する必要があります。
•学生は、アジャイルは「すぐにジャンプして、振り返ることなくコーディングを開始する」ことを意味するとしばしば考えます。これは、想像できる最も恐ろしいコードのいくつかにつながります。したがって、50ページのドキュメントやUMLダイアグラムの山を必要とせずに適切な設計を実施する方法を探しています。
学生だけでなく:-)ほとんどのスクラムチームはTDD（テスト駆動開発）やリファクタリングなどのXPプラクティスを使用しています。これをカリキュラムに組み込むことをお勧めします。
また、ウォーターフォールモデルを教えることにはまだ価値がありますか？
はい、少なくとも2つの理由があります。1つ目は、生徒が仕事でスクラムを使用するかどうかわからないことです。2つ目は、アジャイル開発の本質を理解するのが簡単だと思います。
一度撮った主題に少し似ていますね。
いくつかの考え：
- チーム全体のスクラムミーティングを本当に開催しますか？サブチームは機能しますか？
- 「振り返らずに」がリファクタリングを意味しない場合、リファクタリングの証拠を評価しますか？
- 反省と文書化を評価する-生徒に活動のブログを維持してもらいます。 （これは実際には職場でかなり便利なスキルです-ほとんどの正式なドキュメントよりもはるかに優れています）
- 見積もりが悪い場合、うまくいけば彼らは学んでいる-彼らは見積もりと現実の間の変動を追跡し、違いを反映し、彼らが何かを学んだことを実証できるか？
- 適切であると思われる設計を文書化する正式な方法はありませんか？
- SkypeやGchatなどのスクラムミーティングで十分ですか？
私のアドバイスは、あなたが教えようとしていることを分離して分離することです。ソフトウェア設計またはその他のソフトウェアエンジニアリングの科目（アルゴリズムまたはその他）のコースである場合は、それに集中してください。 SCRUMを使用することが（ヒントとして）妨げになる場合は、気にしないでください。
私が大学にいたときに私たちがこれをした方法は、アジャイル方法論のための専用コースを持つことでした。このコースには、SCRUMまたはXPのいずれかに従って実行される開発プロジェクトが含まれていました。コースの焦点はプログラミングや設計ではなくプロセスだったため、配信される実際のソフトウェアは簡単なものでした。ここでの推論は、「ハードコア」ソフトウェア開発の科目と方法論の科目を混在させるべきではない理由と同じです。一方は他方をEclipse化する傾向があり、学生はほとんどその段階で両方を処理する準備ができていないか熟練していないからです。
コースの成果物は、スプリント計画レポート、毎週の進捗レポート、回顧レポート、バーンダウンレポートに加えて、TAが循環して耳を傾けるグループスタンドアップ/スクラムミーティングを含む少なくとも2つのセッションを毎週開催しました。
このコースにはTDD（テスト駆動開発）も含まれており、非常にうまくいきました。
また、ウォーターフォールモデルを教えることにはまだ価値がありますか？
それは確かです。多くの企業は、このモデルのバージョンをプロジェクト（PPS、RUP、PROPSなど）に使用しています。多くの人が（正しくは、私の意見では）、「純粋な」SCRUMは、プロジェクトよりも継続的なメンテナンスに適していると考えています。 SCRUM（および一般にアジャイル）では、範囲にある程度の柔軟性があり、要件と配信について交渉する可能性が求められます。すべてのプロジェクトがそのように機能するわけではなく、バイナリです。Yの時点でXを配信します。それ以外はすべて失敗します。
アカデミックソフトウェアエンジニアリングコースの目的は、ソフトウェアライフサイクルの基本的な段階、つまり、分析、設計、実装、テストと、通常の宿題の品質コードの代わりに実際のソフトウェア品質基準を使用することを教えることです。
ウォーターフォールではないプロセスを使用した実践を示すことには価値がありますただし、SCRUMは適切なプロセスではないという理由により、学生は学期ごとに多くのコースを受講しますしたがって、専任のチームメンバーを100％確保したり、毎日の会議を行ったりすることはできません。
代わりに、UP（RUP）などの俊敏性の低い反復プロセスの使用を検討してください。
ウォーターフォールプロセスと比較した値を表示するには、反復間で要件を変更します。 これは、UPとウォーターフォールの違いを示し、アジャイルプロセスを使用することの価値に対するヒントになります。
UPが滝のすべてのステージをカバーするため、この後の滝のデモは冗長になります。
学期は比較的短いため、2回の小さな反復が現実的です。
このコースの重点は実装の深さではないため、学生が使用する幅広いフレームワークを提供します。そのためのコースは他にもありますが、コーディング標準とユニットテストを強調する必要があります。
コース中、講義はいくつかのプロセスの理論を教えます。ウォーターフォール、UP、XP、SCRUM、かんばん（その他のトピック、たとえば要件の記述、UML、テストなど）。
上記のコースを修了した学生の場合、夏学期にフルタイムで2週間かかる選択コースとして、別のSCRUMワークショップを検討してください。