私について、1Cスクールとコース「ソフトウェア開発の管理」の6月のモジュールについて

6月に1Cでソフトウェア開発管理のコースを教えました：Club of Programmers。 2週間にわたり、私たちは小学生とITライフの現実について話し合い、チームの小学生はプロジェクトをコーディングしました。 この投稿では、私たちがやったことを正確に伝えます。

私は誰ですか？

私の名前はVitaliy Pavlenkoです。モスクワ物理学技術研究所を卒業し、応用数学とコンピューターサイエンスの学位を取得しました。 Intelでソフトウェアエンジニアとして1年間訓練されました。 過去4年間、モスクワの体育館1534でオリンピックプログラミンググループを率い、知的学校でコンピューターサイエンスのレッスンを行い、サマーコンピュータースクールや他の多くの訪問学校で教えてきました。 ダイクストラとデカルトツリーを学童に伝えるのに慣れていましたが、昨年はWebフレームワークと暗号化プロトコルについても話そうとしました。



この春、私は1C：Club of Programmers（ http://club.1c.ru ）に招かれて、「ソフトウェア開発の管理」というタイトルのコースを読みました。 コースプログラムは私には非常に珍しいようでした。 その一部は、FIVTの学部の大学で、「イノベーションワークショップ」と「プロジェクト管理」のコースで教えられました。 その他の部分は、ソフトウェア会社で働くことの現実に関する一般的な知識です。

どんな学校、どんなコース？

後で学んだように、「1C：プログラマーのクラブ」は、ロシアのさまざまな地域にある数百の支社のネットワークであり、1C製品を扱う大人の教育センターに基づいて作成されました。 その中の小学生は、1C：Enterpriseではなく、より興味深いことを教えられます。Javaプログラミングの基本、基本的なアルゴリズム、およびシステム管理の要素です。 さらに、さまざまなセンターでの教育を標準化するために、コースのプログラム、学生向けのマニュアル、教師向けのマニュアルの開発が一元的に行われています。



今年、学校経営陣は、「Javaプログラミングの基礎」コースの卒業生を対象とする新しいコース「ソフトウェア開発の管理」を開始することを決定しました。 彼らはすでにウィンドウアプリケーションの操作やフォームの描画など、プログラミングが得意です。 新しいコースの主なアイデアは、IT業界で何が起こっているかを話し、学生にコース中にプロジェクトをコーディングする小さなチームの機会を与えることです。



トピックの理論的なプレゼンテーションを含む教科書は、ニコライ・ザヴリエフ（情報技術No. 1533、モスクワ）によって書かれました。

教科書はそのようなことについて語っています：

-さまざまな従業員がIT企業で働いていること、彼らがしていること

-ソフトウェア製品パス：設計、実装、テスト、実装

-要件、参照条件を収集するプロセス

-ソフトウェア開発モデル、ウォーターフォールモデル、反復開発、アジャイルおよびスクラム

-ユーザーインターフェイスの設計

今年の6月はどうなりましたか？

学校での時間の流れの基礎はモジュールです。 1年のうち、モジュールは週末の2学業時間の12レッスンです（モジュール=学業半年）。 今年、1C：プログラマークラブは、モスクワの学童のために6月の特別な2週間のモジュールを開催しました。



6月のモジュールには、すでに以前にクラブに行った人だけがいました。 6月に、各学生は、システム管理、オリンピックプログラミングおよび管理の3つのコースのいずれかを学びました。 コース「ソフトウェア製品開発管理」のパイロットモジュールは、私に読むように割り当てられました。

問題文は、彼らが言うように、挑戦的でした：書かれたばかりの教科書と14人の学童がいます。 このコースをどのように読むかを考える必要があります。理論をどのように伝え、どの実践的な課題を与えるか。 また、学生は、理論の開発とともに、2〜4人のチームに分かれ、プロジェクトのトピックを選択する必要がありました。トピックは、2週間で一緒にコーディングできます。 プロジェクトのテーマは、来年に機能を拡張し、春のプロジェクトOlympiadsの1つでプロジェクトを紹介できるように選ばれました。



6月のモジュールは、典型的なサマースクールとして開催されました。昼食前には、理論と実践の2つのペアがあり、昼食後、生徒は主に遠足で構成される文化プログラムを行いました。 学校の指導者は、MIPT、モスクワ州立大学、高等経済学部などの主要IT大学、地下バンカー、ヤンデックスの本社、バスキンロビンズアイスクリーム工場など、多くの遠足を企画することができました。



学校の最後に、最後に、各チームはすべての生徒とその両親にプロジェクトを発表しました。

そのようなスピーチの例を次に示します。http ： //www.youtube.com/watch？v = VA-30ANDArA

コースについて

仕組み

コースの一部として行ったことはすべて、3つの部分に分けることができます。

最初は、理論自体の議論です。 毎日、教科書の1つのトピックについて話し合いましたが、30分から1時間かかりました。

理論が許せば、2番目は理論の実践的な演習です。 TKについての理論の後、各チームはプロジェクトの技術的なタスクを1時間でまとめて書く必要があったとしましょう。

3番目はチームでのプログラミングです。 1日約2時間、チームは学校自体でプログラムを作成し、多くは夕方に自宅で何かをコーディングしました。



私は人道的開発管理コースを呼び出します。 その内容が厳密な論理構造である技術とは対照的に、このコースは著者の観点からの現実の自由な記述で構成されています。 そのようなコースを教えることは、私にとって新しい経験でした。



アルゴリズムを教えるときの状況は次のとおりです：レッスンの始めに、あなたは教室で幅の広さを知っている唯一の人（まあ、またはほとんど唯一の人）、そして最後に-多くの学生にとっては、彼らも何かを理解したようです。 つまり、最初の段階では知識に明確な違いがあり、レッスン中には具体的な移行プロセスがあります。 IT業界の現実に関するコースを教えるとき、これはそうではありません。 Habrを読んで、IT会社で働いています。 しかし、学童もHabrを読み、多くの親もIT企業で働いています。 多くの人が特定の側面と現実をすでに知っているので、みんなに本当に新しいことを伝えるのは非常に困難です。 ただし、そのようなコースを教えるのは簡単です。 アルゴリズムのコースでは、教師は歩幅をうまく説明できず、生徒はそれを理解できない場合があります。 開発管理のコースにはそのような問題はほとんどありませんでした。



コースを教えることを考えて、2つのことを行うことが重要であると判断しました。 まず、可能な限り聴衆に質問を前書きすることが重要です。これについて何を知っていますか？ たとえば、プロジェクトの実施段階について議論するときは、最初に学童に質問する必要があります。プロジェクトコードはどこに保存されていますか、実際にはどこに保存されていますか。 または：適切なプログラミングスタイルは何ですか？ こだわり続ける価値はありますか？ なぜプログラマーはこれをするのですか？ 学童は、あなた自身がそのトピックについて知っていることのほとんどを知っており、彼らのビジョンを伝えます。 そして、ここで2番目のことを行うことが重要です。何か新しいこと、ほとんど誰も知らないことを伝えることです。 たとえば、コードストレージのトピックについて議論した後、バージョン管理システムとそのデバイスについて話します。 または、プログラミングスタイルについて説明した後、スタイルガイドから実際のルールの例を示し、数時間のハッピーデバッグがそれに従わないことがなぜ価値があるのか​​を説明します。 私自身の職場での実例や友人の話の例を挙げるのはとても良いことです。

理論についてより具体的に

クラスがどのように開催されたかの具体的なアイデアを示すために、「実際、私たちは何を開発していますか？」というトピックをどのように経験したかを説明します。 次のように配置されます。

-要件を収集する段階：顧客とのコミュニケーション、なぜ彼と共通言語を見つけるのが難しいのですか？

-アナリストと顧客との作業：既存のソリューションのデモ、将来のユーザーの生活の監視。

-要件を決定するためのブレインストーミング。 3つの段階：潜在的なユーザーの輪を集め、製品に実装するためのアイデアを生成し、最適なアイデアを分析して選択します。

-参照条件：その内容、「TKですべてを説明することはできません」という問題。



最初に理論について議論しました。 私たちはそのような状況の集合的な議論から始めました。 顧客があなたに来て言います：「私は、100,000ルーブルの週収のスマートフォンを販売するためのウェブサイトが欲しいです。」 プログラマーとして私たちに本当に必要なことを徐々に理解するために、彼との対話を始める価値はありますか？



レッスンで理論を議論し、別荘用のサイトを作成するための実際のTKの例を見てから、各チームに提案しました。

-2週間でプロジェクトの要件を実装するためのブレインストーミング。

-TKのブレーンストーミングに基づいて作成します。



基礎として、理論に基づいて分析したTKを取ることをお勧めします。 1時間の作業の後、各チームがTORを提示し、作業の長所と短所について話し合いました。



参照条件に関するレッスンは、コースの3日目にすべてのチームがプロジェクトフレームワークを既に完了したときに行われました。 もちろん、要件を開発して設計した後にコードを書き始める方が論理的です。 しかし、コースの一貫した論理的なプレゼンテーションで、最初の2つのクラスでは、IT業界の専門職とソフトウェアライフサイクルについて議論します。 同時に生徒はすでにコードを書き始めています。要件を収集する際にクラスを受講するのを待たないでください。 これは、このようなコースの一般的な問題です。理論的な知識が遅れます。

理論の実践

コースの1つのモジュールについて、プログラムの半分を完了しました。 3つの実用的なタスクがありました。以前の決定の分析、TKのブレーンストーミング、およびTKのコンパイルとインターフェース設計です。 各チームは、プロジェクトに関連して最初の2つのタスクを実行します。

以前の決定を分析する過程で、チームは自分のプロジェクトに似た機能とトピックを持つプロジェクトのデータをインターネットで検索し、類似物の長所と短所を分析し、プロジェクトの独自の機能で決定します。

ブレーンストーミングは、アイデアを生成する段階を、アイデアの分析と選択の段階から明確に分離するタスクです。 ToRの準備中に、チームはブレーンストーミング中に選択された各機能を詳細に記述し、形式化しようとします。

インターフェースを設計するタスクの前に、良い設計のいくつかの一般的な法則について議論しました：ユーザーに焦点を合わせ、ユーザーのタスクから始め、めったに使用されない機能を隠し、一般的な目的でオブジェクトをグループ化し、システムで何が起こっているかについてユーザーにフィードバックを与えます。 タスク自体は次のとおりです。インターフェイスプロトタイピングサービスを使用して、医師との患者の予約を記録するためのWebサイトを設計およびプロトタイプ化しました。 このアイデアは独創的ではありません。「研修生Artyom Gorbunovの学校」の入り口から借りました。 インターフェースのプロトタイプを作成するためのサービスとして、gomockingbird.comを使用することをお勧めします。これは非常にシンプルで、数秒で開始できます。 最初の2つのタスクの場合と同様に、プロトタイピングの後、各チームがソリューションを提示し、議論しました。

プロジェクト

最初のレッスンでは、モジュール中に実行できるプロジェクトの多くを紹介しました。 生徒は5つのチームに分けられ、各チームは独自のトピックを選択しました。

最初のチームは、交通と信号機をモデル化するための大規模なプロジェクトに取り組みました。 6月のモジュールでは、交差点道路の交通ビジュアライザーと道路エディターを作成しようとしました。







2番目-Lightbotに基づいた教育用ゲームを書くことにしました。







3番目は、式解析モジュールを備えた関数グラフビルダーです。







4つ目は、アーケード迷路とマップエディターです。







第五に、彼女は倉庫番ゲームをルービックキューブに移そうとしました。 アクションは、キューブの表面N * N * Nで行われます。 あらゆる瞬間に、ユーザーはスキャン全体を見ることができ、小さな男が顔の1つに立って、引き出し、壁、キューブの表面にターゲットセルが描かれます。 ルービックキューブは回転できるため、フィールドは非常に複雑に変化する可能性があります。







毎日、クラスは2組続きました-ラインから昼食まで。 最初のペアの終わりと2番目のペア全体が、教室でのプログラミングに割り当てられました。 プログラミングの主な原則は反復でした。各開始前に、各チームに前日にプロジェクトで何が行われたのか、そして数時間以内に何をコーディングするのかを伝えるよう要求しました。 2番目のペアの終わりに、各チームは他のすべての人に、今日の計画をどの程度実現できるかを示しました。 日々、チームは自分の長所を正しく評価し、より現実的な目標を設定し、小さなステップで行動することを学びました。 「2時間ごとに、すべてが機能し、新しい何かが実現されなければなりません。」 個人的には、この原則を学童に浸透させることは非常に重要だと思います。 私たち一人一人のプログラミング生活の初めに、無害なおもちゃを装って宇宙船を設計する「滝の開発の悪魔」が住んでいます。 この悪魔は、幼少期からの小さな繰り返しによって腐食されなければなりません。

不均衡

チームのプログラミング中、チームの力が等しくなく、チーム内の力が等しくないことは非常に気分が良いです。 初期に信号機をシミュレートしたチームは、自分のホームサーバーでgitリポジトリを上げようとしました。 マーフィーの法則によれば、チームはすべてを自分で管理したいという欲求を支払いました。ある日、家の照明が消えたためにリモートgitサーバーがまだ横たわっていました。



他のチームはバージョン管理システムについて全く知りませんでした。 私は彼らにこれを教えようとしませんでした：最初は、コードをクラウドファイルストレージに保存し、チームが地獄からのファイルのコピーの競合にうんざりしている場合にのみバージョン管理システムに切り替える方が良いと思います。 ただし、多くのチームは、クラウドストレージを使用することを渋っていました。 教室でのプログラミングでは、ローカルネットワークを構築し、チームはその中の共有フォルダーを介してデータを交換しました。



Lightbotアナログを開発したチームには3人がいましたが、そのうちの1人は他の人には高すぎました。 この男だけが、プロジェクトのフレームワーク全体を終日Javaで作成しました。 翌日、Javaでドラッグアンドドロップを使用するのはあまり便利ではないと思われ、プロジェクト全体をJavascriptで書き直してGithubに配置しました。 このチームで働くことは私の完全な教育的失敗でした。他の2人のチームメンバーに、Javascriptが何で、gitが何であり、自分で何かをプログラムする方法を説明するよう説得することができませんでした。 ほとんどの場合、他の2人のチームメンバーは適切なイラストを検索し、レベルを考え出しました。

次は？

私はこのコースを教える方法を理解できたと思います。 現在、学生向けのマニュアル、私の著者の教師向けのトレーニングマニュアルがあり、地域の優秀な教師を選択しています。 10月から、コースはロシアの多くの1Cトレーニングセンターで教えられます。