Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/04/26)へのリンク始めに開発チームの多くは、テストの自動化を、ソフトウェアデリバリをスピードアップする手段と考えています。チーム内のボトルネックがそこにある、と思われることが多いためですが、開発プラクティス全体をより深く検討すれば、もっとよい結果を得ることができます。バグを防ぐテスト、特にUIレベルでのテストの自動化は、ソフトウェアデリバリのパイプラインの最終段階で実施される傾向があります。そこでは一般的に、ライブ環境に入り込んでエンドユーザに悪影響を与えるようなバグの捕捉が行われます。ここでは、テストによってバグの症状(symptom)を検出します。開発者がデプロイする修正は、その治療(cure)ということになります。自分たちのシステムが病気になるのを待って、何かをしようとしているかのようです。関連スポンサーコンテンツこのアプローチはチームにとって効果的ですが、現在の作業環境は、私たちに、より少ない人数で、より速く、より多くのことを行うように求めています。このアプローチを今後も長く続けることはできません。治療ではなく、予防が必要となるのは、このような理由からです。システムの構築方法を修正することで、問題が発生する前に検出することが可能になります。進んで、最初からバグが発生しにくくすること(予防)もできるのです。後になって原因を解決するのではなく、バグの発生を防止する、ということです。昔の諺にもあるように、予防は治療に勝るのです。私が最初に手がけたのは、VOD(ビデオオンデマンド)プロダクトの開発と管理を行っていたモバイルチームでした。当時、私たちのテストはすべて手動で実行されていました。各プラットフォームのリリースは、平均で年間2~3回に過ぎませんでした。スピードアップしたいと思っていたのですが、リリースにおいて最も明白なボトルネックがテストだったのです。各回帰テストサイクルには約2週間が必要でした。問題が見つからなかった場合は、です。問題が見つかれば、開発チームが問題を理解し、修正方法を決定し、それを適用する必要があります。これによって、すでに実行されたテストが無効になる可能性があるため、プロセスを再開しなければならず、テストサイクルに2倍の時間を要するのです。そこで私たちは、UIテストをより自動化する検討を始めました。最初は小さな部分から初めて、自分たちが望む方向に進むことを確認したいと考えていました。新しい機能のみを対象として、効果が証明されたならば、システムの既存の領域または既知の問題領域の自動化を検討したい、とも思っていました。チームとして、私たちが何を作りたいのか、その機能のための重要な受け入れ基準が何であるべきかを理解するために、3つのアミーゴを使用しました。これによって、機能をどのように分割するのか、ユーザが何を自動化するのかについて、出発点を得ることができたのです。そこから、テストの自動化に使用可能なツール(Calabash、最終的にはAppium)を特定し、実環境でテストを実行しました。私たちはこれを、エミュレータやシミュレータではなく、実際の携帯電話で行ないました。結果として、モバイルデバイスをより有効に活用できるような、独自のデバイステストファームを構築することができたのです。詳細については、私の一連のブログ記事を参照してください。features"の3部で構成されています。テスト自動化によって実現したメリット最初は、自動化の大きな支援によって、シンプルなシナリオを迅速かつ信頼性を持って実行し、必要なフィードバックを短期間で得られるようになりました。時間が経過し、最初に一連のバグが発見されてしまうと、発見できるイシューの数が段々少なくなり、それを探すような自動化テストケースを、意識的にコーディングしなければならなくなりました。いくつかのシナリオが自動化できなかったために、イシューがまだ解決していない点にも気付きました。使いやすさに関連するものは、すべて手動でテストする必要があったのです。これらのことから、いくつかの重要なシナリオを自動化して迅速に実行する、ハイブリッドソリューションにたどり着きました。明らかな問題が発生していないことをチームに知らせたり、新たな機能の予備的なテストを実施して、それが適切であれば自動化するのです。このように、テストは難しいものです。テストを実行しようとして間違いを犯したり、手作業で行う上で時間が掛かり過ぎたりすることは、よくあることです。自動化の過程において間接的に得られた、予期していなかったメリットは、リリースが早くなったことによって、達成しようとしていることに以前より集中できるようになった、という点です。結果として、新機能を小さなチャンクに分割し、独立して作業することが可能になり、自動化が実現するとともに、それらのチャンクを運用環境にすばやくリリースし、実際のユーザから現実的なフィードバックを得ることができるようになりました。自動化のシナリオを特定する方法を試していた最初の頃は、これはまだ明確ではありませんでした。チームの不注意からしてしまったことは、後にならなければ分からなかったのです。簡単に言うと、私たちは、私たちの仕事をエンドユーザ価値の小さなバッチに分割するようになった、ということです。私たちはやがて、自動化されたUIテストでは期待どおりの結果が得られない、ということに気付き始めました。このため、自分たちの開発プロセスの他の部分を見て、何か改善ができるかどうかを確認するようになりました。チームとしての私たちの問題のひとつは、プロセスが身近すぎて、何がうまくいっていないのかを客観的に見ることができなかったことでした。これを克服するため、私たちは、アジャイルコーチによる支援を仰ぐことにしました。実際には、2人のコーチを導入しました。ひとりは、チームが採用しているプロセスの理解を支援するためで、もうひとりは、エンジニアが実際のシステムを構築している方法について理解を深めるためです。彼らは、チーム外部の視点から、誰にも気兼ねすることなくシステムの一部を突くことができました。私たちに簡単な質問をして、作業方法の背景になっている理由を確認させることで、"いつもこの方法で行っている"という私たちのサイクルを打破してくれたのです。test)"、"完了(done)"といった一般的な列がありました。私たちのコーチは、なぜこれらのコラムで仕事を積み上げさせたのか、なぜ開発とテストを2つの異なる活動と見なしたのか、と質問することで、新たな気付きを与えてくれました。コーチのアプローチは、単に私たちのプロセスを変えるのではなく、それが引き起こしていた問題("next"や"waiting-for-test"として、隠れた形でキューに留まっている、未リリースの価値)を見出すことを支援してくれたのです。結果としてチームは、ウォークスルーを通じて"dev"と"test"の列を廃止し、単純で自明な"in-progress"という列に替えることができました。columnに寄稿した私の記事では、この作業方法の移行によるメリットについて詳しく説明しています。私たちが学んだことアジャイル開発プラクティスという観点から、私たちが発見した最大の問題のひとつは、私たちのチームには多くの"盲目的な乱用(cargo-culting)"があった、ということです。スタンドアップを実行して、小規模チームで活動して、スプリント単位でリリースしているだけでは、本当にアジャイルであるとは言えないのです。それは単に、私たちが"アジャイル"であるかのように見せかける、いくつかのセレモニに過ぎません。それをしているのか、さらには、それに何のメリットがあるのかさえ、全員に十分な確信があったのではないことが分かったのです。私たちが最初にしたことのひとつは、アジャイルであることの意味を明確にすることでした。それは客観的なフィードバックに基づいた持続可能なソフトウェアの提供であって、可能な限り速く行動しようとするのではなく、可能な限りのリリースを実行し、ベストを尽くすということです。私たちは読書会を通じてこれを行い、チーム内での共同理解を実現するためにチームディスカッションを進めました。これによってチームメンバは、アジャイルプラクティスの背後にある原則をより深く理解し、自分たちの仕事の方法において、より良い決断を下すことができるようになったのです。私たちは、実際にシステムを構築する方法についても、コードレベルでの検討を始めました。開発者がコードをコミットするタイミング、コミットの頻度、コミットの大きさの視覚化を試みたのです。これは、開発者を詰るのではなく、彼らがグループとしてコードベースにどのような影響を与えたのかを理解し、より生産的な開発者の習慣を奨励するための試みでした。一日の終わりに大規模なコミットをするのではなく、小さく、目的が明確で、定期的なコミットを行うような習慣です。大規模なコミットを行ったのであれば、それもOKですが、他の開発者にその理由を説明すれば、彼らもそこから学ぶことができます。チームに対する私たちの最大の変更点のひとつは、ペアプログラミングを奨励したことです。その結果、機能を単独で開発する開発者は誰もいなくなりました。これはコードレビューを早めましたが、それと同時に、責任を負うべき場合において、手っ取り早い方法を取るようなこともほとんどなくなりました。チームの若年メンバのスキルと知識をより短期間に向上させることが可能になり、多数のベテランメンバがダミープロジェクトをレビューしていた従来の方法に比べて生産性が向上しました。生産的で健全な開発ライフスタイルのためにチームとして活動する中で、生産的で健康的な開発プロセスとはどのようなものなのか、明らかにしてください。このような議論を始める上で有用な方法のひとつが、チームビデオクラブの設立です。これによってチームは、日々の活動から多少の時間を割いて、新しいツールやソフトウェア構築のアプローチについて学ぶことができます。各セッションの最後には、セッションリーダ(プロジェクトマネージャ、技術リーダ、あるいはアイデアをチームに紹介した人)がチームディスカッションを行い、その概念を使用してチームが新しい何かを試す方法を探ります。その上で、結果がどうあるべきかについて明確な考えを持って取り組むため、ひとつの概念を選択します。"よりよいユニットテスト"という例を取るならば、ユニットテストはチームにとって何を意味するのか、ということです。よいユニットテストを行うことで、チームが手に入れるものは何でしょうか。その答を得たならば、どうすればそれを達成することができるのか、複数のアイデアを作り出してください。その中から、成果を短期間かつ客観的にテスト可能なものをひとつ選択するのです。採用した新たなプロセスやテクニックが、本当に成果の達成に役立ったのか、あるいは設定された時間枠ではだめだったのか、はっきりさせたいと思うでしょう。よい結果であれば、それは素晴らしいことです。なければ、止めるべきでしょうか?もっと続けますか?あるいは、手を加える?また、誰が実際に実験を行うのか、どのようにしてチームの他のメンバに伝達するのか、といったことも決めなくてはなりません。新しいプロセスやアイデアをチームの中に定着させたいのであれば、全員がそれに関与する必要がある、ということを忘れないでください。なければ、そのアイデアは、困難の最初の兆候で立ち尽くすか、あるいは行き詰まって、恩恵を受けるのはそれに関わった人たちだけだった、ということになりかねません。Gosai氏は15年以上にわたり、携帯機器メーカからOSビルダ、アプリ開発者まで、さまざまな企業でテストを行ってきました。現在はTV&Radio部門の主任テスタとして、BBCのモバイル、TV、Webプラットフォームチームなどと協力して、彼らのテストアプローチ、チームのDevOpsやその先への移行を支援しています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。