すでにハブに書いたロシアとドイツの共同学生学校JASS-2012の一環として開催された「モバイルデバイスでのユーザビリティエンジニアリングとユビキタスコンピューティング」の過程で生じた観察を共有したいと思います。 ただし、前回の投稿とは異なり、主催者の目を通して学校について説明します。
学校について、またはモバイルデバイス用プログラムの開発に特化したトラックについてです。 ドイツとロシアの学生で構成される3つの国際チームが編成され、これらのチームは非常に困難なタスクに直面しました。非常に短い時間でソフトウェアプロジェクトをゼロから開発することです。 チームの時間は限られており、合計でプロジェクトの所要時間は4日弱でした。
主催者には2つの目標がありました。 第一に、アジャイル開発テクノロジーの学生に効果的なトレーニングを構築する方法を理解するため、そして第二に、チームが最も効果的に働く条件を理解したかった。 それで、開発訓練プロセスはどのように構築され、私たちは自分自身のためにどんな教訓を学んだのでしょうか。
プロジェクトの開始
最初に、ロシア側とドイツ側の主催者がプロジェクトのいくつかのアイデアを思いつき、それらの詳細について話し合い、チーム間でそれらを配布する準備をしました。 しかし、最初の対面会議で、間違いを犯したことが明らかになりました。 私たちのタスクは、進行中のプロジェクトで各開発者の最大の関心を引く条件を作成することであり、最も重要なこと以外はすべて行いました-参加者に尋ねませんでした（開発プロセスで「消費者/顧客」を関与させず、柔軟な開発の言語を話しました）。
私たちは間違いに気付いたので、最初の計画に従わないことに決めました-アジャイルになるなら、すべてにアジャイルになると、ブレーンストーミングセッションからプロジェクトの言葉遣いに取り組み始めました。
とても楽しそうでした。 参加者には、最も素晴らしいプロジェクトのアイデアを生み出すために、数パックのステッカーと10分が与えられました。 各アイデアはステッカーに記録され、マーカーボードに接着されました。 10分で、数十のアイデアが生成されました。 私たちは、ボードからアイデアを1つ読み始めたモデレーターを選びました。これにより、著者は自分のアイデアを明確にし、存在するものに興味を持ちます。 各アイデアの著者は、説明するのに約15〜30秒かかりました。 プレゼンテーションの後、アイデアは受け取った投票数によって同じボードでランク付けされました（誰もが、剣闘士の決闘の観客として、アイデアをバスケットに送るか、その実施に投票する権利を持っていました）。
最終的に、いくつかのより良いアイデアが残っています。 そのような投票の過程で、私たちは新しいプロジェクトの統合を観察したと言う価値があります。 いくつかのアイデアは非常に近かったため、一緒に組み合わせると、もう1つの一般的なプロジェクトの単なる機能（機能）になりました。
最後のフェーズは、チームによる参加者の配布です。 誰もが選択したプロジェクトのいずれかに参加を申請できますが、いくつかの制限が設けられました-チームには少なくともロシアとドイツの代表者が1人含まれる必要があり、プロジェクトに5人以上3人未満を含めることはできません。 したがって、私たちは非常にやる気と戦闘チームに急いで作成しました。
必要条件
要件がソフトウェア開発の基礎であることは秘密ではありません。 彼らは定式化するのがとても難しく、各チームメンバーに伝え、フォローフォローフォローの変更と条件を変更します...多くの本は、各開発者（ブルックス、デマルコ、スポルスキー、クーパーなど）が何度も何度も読んで理解の本質を説明しなければなりません要件、その管理、開発者間の関係のチームは、プロジェクトマネージャーやプログラマーの心に最終的な啓発をもたらすことはありません。
私の意見では、要件を管理するための非常に効果的な方法論を次のように適用しました。要件の収集と開発を映画の作成と考えました。 はい、はい-45〜60秒続く小さなクリップ。 このビデオは、すぐに製品を販売するためのコマーシャルとして位置付けられました。 チームの各メンバーはそのようなビデオの作成に参加しましたが、その外観は一方ではチームの処理要件の結果であり、最も重要なことは、プロジェクトが作成されている唯一のメインユーザーケースを修正することです。 なぜ小さなチームでこれが他の要件管理メカニズムよりもうまく機能するのですか？ はい、映画の画像が簡単であるだけでなく、テキスト、トラッカーのタスクセット、またはその他の正式または準正式な文書よりも、頭に留めておくのが心理的にも楽しいからです。 実際、これは視覚化されたユーザーストーリーであり、開発者は誰もが作成に参加したため、その意味を理解するために努力する必要はありません。 私はそのような映画の準備を、要件の知覚の感情的なエンハンサーと呼びます。
プロセス
開発とトレーニングに非常に限られた時間しかなかったため、いくつかのタイプのスクラムラリーを学生でテストすることが決定されました（英語集会、集会から）。
最初の集団-すべてのプロジェクトの参加者は、各チームがその状況を報告し、問題をブロックし、義務を果たす方法を聞きます。 このような集合的な形式により、チームは互いに連携し、プロジェクトの速度を隣接するプロジェクトの速度と相関させることができます。 遅れたチームは加速し始め、隣のチームはより多くの進歩を遂げ、成功したチームも加速し始め、現在の段階での成功感からエンドルフィン注射を受けます。
2番目のタイプの会議は、デザイン会議です。 pr索好きな目がなく、専用の静かな部屋にいる1つのチームのみがステータスを分析します。 この場合、チームはプロジェクトに存在する問題を開いて議論し、解決策を見つける傾向があります。
学校内で使用されるラリーの3番目のタイプは、各チームが独自にステータスを決定し、強調表示された参加者が一種のラリーでチームのステータスについて話すときに、スクラムスクラムを実装する試みです。 この演習では、大規模なプロジェクトでプロセスをどのようにスケーリングできるかを理解します。
カオルディックティーチング
ドイツの同僚と実験の過程を話し合うと、小さなチームでプロジェクトを開発するプロセスにあらゆる分野を教えるプロセスの明確な類似性を見つけて驚きました。 L.S.を覚えている 学習能力のしきい値と快適な学習のゾーンを備えたVygotsky。 一言で言えば、これは次のように説明できます。
トレーニングとソフトウェア開発は、学生が快適なゾーンにいる場合、実質的に自己組織化できるプロセスです。 ゾーンの下限は関心を決定します-未解決の非自明なタスクの存在は、脳が行動するように刺激します-脳は学ぶのが大好きです。 ゾーンの上限は、チーム自体の影響の最大可能性によって決まります。 チームが要件の強い不確実性に遭遇した場合、またはリソースが存在しない場合（たとえば、私たちの場合、インターネットへのアクセスだったために壊れた場合）、プロジェクトの速度は低下し始めます。 他のすべての場合、快適なトレーニングまたは快適な開発条件のゾーンにいるチームは、自己組織化が可能です。
私たちは、Chaordicの指導にこのアプローチを呼びました。VISAのCEOとしてChaosとOrder（英語のカオスと秩序）から形成されたそのような言葉を適用したDee Ward Hockからのアイデアを借り、革新と発見。 そして、私たちの学校では、これが教育の分野でも開発の分野でも本当に有効であると確信していました。
結論
学校は去りました、私はそれを確信しました、参加者と主催者の各々にとって驚くべき感覚。 3つのプロジェクトが開発され、最後の休日のイベントで発表されました。 私のすべての経験から、開発の質と完全性に関するこのようなプロジェクトはほとんど思い出せません。 プロジェクトは、仕事を始める前に、さらに異なる言語で話し、異なる文化から来た人々によって完全になじみのないものにされたことを思い出させてください。
カオルディック教育のアイデアがとても気に入ったので、次回のSECR会議でこのトピックに関する小さな共同レポートを作成することを計画しました。
結論として、私はすべての参加者とイベントの主催者、特にハブにすでにポストがあり、そのようなイベントと実験のために常に開いているアカデミック大学に感謝するしかありません。