Agile India会議でのDigital Transformationの日に、Fred George氏はファジィ問題を扱う際に、プログラミング問題を解決する方法をどのように変える必要があるかについて講演した。彼は、Cynefinフレームワークの複雑な領域を扱うとき、反応速度は他の要素よりも重要であり、我々が使用しているソフトウェア開発モデルは、必要とされる迅速な反復をサポートしていないと述べた。迅速な反復とは、数分から数時間のサイクルでライブ環境にデプロイできることである。彼は、このような環境における理想的な開発「チーム」は、非常に小さなサイクルでソフトウェアをデプロイする顧客と直接作業する一人の開発者から構成されると述べた。
伝統的でアジャイルなプラクティスが、シンプルで複雑な問題領域に適しているという説明で、IoT and Microservicesというタイトルの講演が始まった。そのような問題は理解されており、どのように問題に対処すればいいかが分かっている。アジャイル開発プラクティスとチームは、問題領域について学ぶ必要がある問題領域で効果的であるが、基本的な要件は比較的よく理解されているか、あるいは、理解することが可能である。
彼は次に、シンプルで複雑なドメインには当てはまらないタイプの問題を議論した。これらは、複雑モデルにおける複雑でカオスな領域にあり、要件が非常に不明確で、問題を解決するには迅速な学習、フィードバック、適応が必要である。彼は、金融機関向けのローン、デイトレーディング、グーグルアドワーズ、不正取引の特定など、そのような領域におけるファジーな意思決定の例を挙げた。
これらのファジィ領域では、問題を解決する最善の方法は、開発スキルを持つ人が顧客の横に座ってコードを書いてデプロイし、結果を顧客に示すことを、非常に短いサイクルで実施することである。この方法によって、実際の問題が明確になり、問題を解決する方法が高速なサイクルから浮かび上がるであろう。
彼は次に、自宅のIoTエコシステムを制御するために構築した一連のマイクロサービスを使って、どのようにしてマイクロサービスアーキテクチャがこのような動作をサポートするかの例を示した。そのアーキテクチャでは、「非同期通信に必要なパターン」を使って、バスを介して連携される独立した責任を持つ小規模サービスを多く開発することができる（コードはGitHubリポジトリで利用可能である）
彼は、システムを設計する際に使ったアーキテクチャの原則を示した。
- 不確実性 => ジャストインタイムデザイン
- 行動指向のサービス => できるだけ小さいサービス
- 結論を公開する => サービスが何か面白ければ、それをバスに公開する
- 冪等性による信頼性（必要に応じて同じ動作を繰り返す）とすべての要素の冗長性
彼は、例とシナリオを使用して多数のマイクロサービスサービスを徐々に提供することによって、支持者と出会ってきた。
彼はいくつかの見解を以って、システムに関する内容を結論づけた。
- このようなシステムでは、バス上に多数のメッセージが表示される
- サービス間にRESTfulインターフェイスはない
- 複数インスタンス/バージョンに対する制約はない
- マイクロサービスは非常に小さく、テストをせずに動作を理解できるため、単体テストは不要である
- アクセプタンステストではなく、高速フェイリングシステム
彼は次に、ファジィ問題向けのこの開発アプローチがアジャイル開発とどのように異なるかについて議論した。
- コミュニケーション、単純さ、フィードバック、勇気、敬意のXP値は非常に重要である
- チームが非常に小さく（プログラマと顧客）、しっかりと結合されているため、またペアリングさえもオプションであるため、アジャイルなプラクティスは必要ない
- アジャイルにおける役割は、開発者と顧客以外に必要ない
- 顧客の役割は要件を定義することではなく、開発者にその領域を教え、問題と解決の両方を理解するために協業することである
彼は、このアプローチがすべての先進的な開発者に必要であるわけではないが、ファジィ領域の開発者にとっては、これが実際に問題を解決する最善の方法であると明言した。
Rate this Article
- Editor Review
- Chief Editor Action