Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。私はここ数年間、多くのチームで働いてきました。そのうちのいくつかは非常に長い期間に渡って仕事をしてきましたが、かなり短い仕事も数多くありました。それらの仕事を通じて、多くのチームに共通して話題になることがある、ということに気づきました、その話題というものは、チーム構成の変動です。通常は、チームだけの力では対処できないようなものが引き金になります。チームメンバーが病気にかかったり、長い休暇を取ったり、プロジェクトが大きくなったり、新しいプロジェクトが立ち上げられたり、あるいはその本人が(環境の)変化を望んだり、といったことがあります。それらを理解する事前の知識が十分にない場合には、日次スタンドアップミーティングや、ペア・プログラミングといったアジャイル・プラクティスを使ったとしても、役に立たない情報ばかり伝わってしまいます。アジャイルプラクティスは新チームメーンバーが知りたい情報を直接提供するものではありません。そこで私は、新しいチームメンバーの「セットアップ時間」の削減するために、新しいプラクティスを提案します。製造業では、伝統的にリードタイムを以下のように4つに分割して考えます。実際に作業を開始する前の準備をするプロセスに使用される時間です。実際に作業を実行するプロセスに含まれる作業項目に使用される時間です。この時間はプロセスの時間と待ちの時間に分割されることもあります。次のプロセスに移動する作業に使用される時間です。次のセットアッププロセスに入るまで待つ時間です。新しいチームメンバーの増員ということがあったとすると、この概念を適用してみると、以下のような図ができあがります。リードタイムの後半の2項目(移動時間と待ち時間)は個々のプロジェクトに影響を与えることはありません。そのため、重要になってくるのは前半の2項目(セットアップ、実行)です。新しいチームメンバーのセットアップというものは、いままでいたチームメンバーとほぼ同じぐらい働く開発者に変化するのにかかる時間です。このような時間をカウントする必要があるかというと、新メンバーを受け入れるためには既存のメンバーが時間をかけたり、取り組みを行って、チームのやり方の要領を伝える必要があるからです。これは、新メンバーが持っている能力を完全に発揮できるまで行う必要があります。実行時間には、新メンバーがチームの中でどの程度の効率で働いているのか、ということが含まれます。氏の「人月の神話」では、プロジェクトに人を追加する際の影響が詳しく説明されています。問題が発生しているプロジェクトについて考察されています。本の中で強調されていることは、新しいチームメンバーがプロジェクトを学ぶ必要があります。(実際にそれを達成しようとすると)、それの多くの人が時間を使う必要があります。いった活動から、コミュニケーションのオーバーヘッドが発生し、大きな問題になっていく、書かれています。チームの他のメンバーとのコミュニケーションのオーバーヘッドはセットアップ時だけなく、実行時にも継続して発生します。これらの要因を考慮すると、新しいチームメンバーを入れることによって発生するトータルコストは以下の図のようになります。関連スポンサーコンテンツチームでの活動を向上させることにフォーカスしているプロセスはどれも、実行時のコミュニケーションを削減しようとするものが多い。これらは、新メンバー投入時にかかる時間の削除には目を向けていない。これは、新チームメンバーがどれだけ早くチームになじめるか、チームが新しいメンバーに合わせて内部構造をどれだけうまく変化させられるか、という時間である。実行時のためのアジャイルプラクティスすべてのアジャイル開発方法論において、学習は必要不可欠な要素となっています。多くのアジャイルプロセスはフィードバックのサイクルなるべく早くして、反復練習をすることにフォーカスしている。継続的な改善を行い続けることを重視しています。プロジェクトに新加入したメンバーと、しばらくプロジェクトにしたメンバーでは、何を学習したいかというニーズは大幅に異なります。新メンバーに情報を吸収させる方法としては、ただ質問を待って答えるよりも、積極的に疑問を持たせるようにする作戦もあります。Scrumのスタンドアップミーティングで発言されるような「私は昨日・・・をしました」という定型的な文章を聞けば、「(最初からチームにいた)彼らは何について話しているんだろうか?どうすればチームの輪に加われるんだろうか?」という疑問を持たせることができるでしょう。新メンバーに情報伝達の手段としてのペアプログラミングは、状況によって効果も変化します。ペアのうちの一人が新しいメンバーで、詳細ではなくての全体を見る視点を持っていると効率が上がります。逆に、ユーザストーリーを次から次へと開発をしているチームでは新メンバーの加入による効果はないでしょう。この場合は新メンバーは大きな俯瞰図ではなく、細かい詳細ばかりを次々見せられます。多くの新メンバーが、メインの処理とは絡まないような、細かい情報ばかり与えられてフラストレーションを貯めていく例を、私は数多く見てきました。プロジェクトの大まかなコンテキスト(前後関係、背景など)を知ることが新メンバーの目標です。彼らは知るべきことを見つけ出し、ドメイン特有の言葉を理解し、チームやその文化の中で仕事をし始めます。プロジェクトが複雑であったり、多くのメンバーが加入したりすると、このフェーズにかかる時間は長くなります。新メンバーがコンテキストの理解を完了すると、今度は詳細の深い知識の学習をし始めます。わずかであっても、コンテキストを学んでおくと関連した情報の吸収が早くなります。大まかなコンテキストを理解している場合には、日次スタンドアップミーティングや、ペアプログラミング、テスト駆動開発、レトロスペクティブなどのプラクティスは付随的な種類の情報を理解するのに役立ちます。コンテキストを理解していない場合には逆に役に立ちません。アジャイル開発のプラクティスは新しいチームメンバーの学習を直接の目的とはしていません。アジャイル開発のプラクティス以外の方法について何か良い別案があるでしょうか?この場合は「セットアップ時間」の削減にフォーカスしている、別のプラクティスを用いることにします。以下の短いリストはアジャイルプラクティスに含まれるプラクティスのうち、周囲の情報を完全に理解するのに役立つテクニックをまとめたものです。これらは実際に、私のチームに加わった新しいメンバーに役に立つと判断して取り入れたものです。新メンバーがチームに加入する前にプロジェクトの背景を説明するEメールを送ります。このメールを読むことで、新メンバーはプロジェクトに関する書籍を読んだり、スキルを身につけたり、知識を学ぶ機会を得ることができます。新メンバーに見せるセッションを行います。ドメイン固有の言語への理解が得られます。仕事を開始してもすぐにビジョンの方をきちんと向いて働くことができるようになります。ダイアグラムを使うと、大きくなったシステムのコンセプトに小さなコンセプトを追加で実装するのがやりやすくなります。可視かを行うと、例えば、現在開発している機能の情報について集中して話をする場合や、いくつかのアーキテクチャがお互いにどのように関連しているのかということを話すのに使用することができます。元からいたチームメンバーが、「この箇所は改善しないといけない(今のコードがとても良くない)」と考えていることは素直に話しましょう。することで、「どんなにコードが良くないか」という議論に陥るのを避けて、「どうやって改善するのか?」「どういう計画を立てるか?」ということにフォーカスできます。大きくて大量にある仕事を小さなタスクに分割します。すると、新メンバーが必要とすると手助けの量を減らします。チームメンバーが日常的にこなしている一般的なタスクにはどういうものがあるかを理解しやすくなります。日常業務として、同じような仕事をしている仲間を集めて、他の人の役に立ちそうな知識やトリックを共有する会を開きます。この会ではスキルを学ぶこと、共有することに集中します。他のチームメンバーの手助けを新メンバーに伝える役割を与えます。新メンバーは他のチームメンバーにコンセプトを説明したりする必要が出てきます。この活動を通じて学んだことを強化したり、考えを洗練させたりすることができます。学習のプロセスはメンバー一人一人に合わせる必要があります。ダイアグラム、ドキュメント、CRCカードなど、幅広いコンテキストを描くことができるツールを使って下さい。新チームメンバーには安全な環境で失敗を体験できるような十分なスペースを与えましょう。学習項目に応じては、自分自身で学んだ方がいいものも多いからです。プロジェクト内でのメンバーの交換は難しく考える必要はないアジャイルプラクティスは学習という観点で見ると、すばらしい提案であることは確かです。それは「セットアップ時間」ではなくて「実行時間」の削減にフォーカスしているため、新チームメンバーにとっては、既存のメンバーと比べると効果は大きくありません。新チームメンバーが持つ学習のニーズが、通常のケースと異なるということを理解してください。チームメンバーの導入に特化したプラクティスをもいい手、この問題に正面から取り組んで下さい。(新メンバー用の)プラクティスを適用して、「セットアップ時間」の減少にトライし続けてみて下さい。多くの人が会社に入る時に、研修プログラムを学ぶのは主にこういったことが理由になります。Kua氏はThoughtworks社で開発者、トレーナー、コーチをしています。Patrick氏は一緒に働いているチームの価値を高めるのに情熱を持っています。自分の仕事や活動を楽しむことに熱心なメンバーの手助けをすることについても情熱を注いでいます。彼は仕事の中でしていることと、楽しむことを両方とも維持して達成することが、よりよい結果を生むという信念を持っています。彼はこの3.5年間は、アジャイルに取り組む数多くのチームに参加をして、コーチをしたり、リーダーをしてきました。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。