Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Butt氏はこのように主張する。効果を証明されたエンジニアリングプラクティスはたくさんあるが,期待されるほど広くは活用されていないのが実情である。結果として,アイスクリームコーン型ソフトウェアテストなどアジャイルのアンチパターン,技術的負債の蓄積,機能的サイロが,スプリントの終了時におけるリリース可能な製品の提供を妨げている,とNafees氏は言う。アンチパターンには,定期的な検査とシステム思考を適用することで対処することができる。2016で,リリース可能な製品のインクリメンタルな開発について講演を行なう予定だ。InfoQは氏にインタビューして,アジャイルのアンチパターンと対処方法,技術的な洗練が重要な理由,推奨されるエンジニアリングプラクティス,優れたエンジニアリングプラクティスを備えた文化を確立するために企業ができること,などについて聞いた。技術的な観点から言えば,最も多かったアジャイルアンチパターンは次のようなものです。テストの大部分がUIを要するために,均整の取れたテストピラミッドの概念が失われているケース。この状態になったチームや企業は,受け入れテストをできる限り自動化しようと試みますが,そのようなUIテストは,その非決定論的な性質のためにエラーを返したり,実行や維持にコストを要したり,ミニ・ウォーターフォールを形成したり,チームへのフィードバックに遅延を発生させたり,将来的なUI改良に対する柔軟性を損なったりします。技術的負債の暴利は,よく見られるもうひとつのアンチパターンです。これは(今日という革新の時代においては,すべての製品開発グループが抱く)切迫感と,設計のための十分な時間がないという誤った前提に由来します。このアンチパターンのバリデーションとして,実践者がクラフトマンシップに従わず,ボーイスカウトのルールも実勢しないために,コードベースが朽ちたまま放置される状況もよく見られます。継続的インテグレーションと継続的デリバリに関わるツール類はこの10年で成熟しましたが,継続的インテグレーションの“継続”の部分が失われつつあります。長く存在していた機能ブランチがマージ時のコンフリクトによって台無しになる,というのが,このアンチパターンの一般的な症状です。技術的制限ではありませんが,このような構造的障害にも重大な技術的波及効果があります。cult)としてアジャイルプラクティスを適用したことの副作用です。すべてが無駄なのです。ひとつは調査と適応の重要性を常に強調すること,もうひとつはシステム思考です。今日見られる技術的プラクティスのアンチパターンのほとんどは,木を見て森を見ない企業の姿勢と,部分最適化に終始する意思決定に起因しています。学習するチームや企業に必要なのは全体論的な視野だけではありません。行動とシステムの状態との因果関係の理解も不可欠です。この調査を定期的に行ない,適切な対応を実施することで,こういったアンチパターンに対処することができます。具体的な例が,私が2年ほど前に働いていたチームにあります。Webブラウザオートメーションを使った受入テストを始めたところでした。シナリオの自動化には成功したのですが,いくつかのスプリントの中で,その欠点が明らかになってきました。そのためチームは,スプリントのレトロスペクティブのひとつを使って状況を分析して,自動化自体が目的なのではない,テスト自体が(実行に時間がかかるために)フィードバックを遅らせていて,余分な作業を発生させている(UIが変更されると,テストをリファクタしなくてはならない)のであれば,それは,別の手段が必要だという結論に達した,ということです。test)を導入することで,フィードバック時間の改善とUI変更時のリファクタが不要になるのではないか,と指摘して,チームに方向性を与えてくれました。レトロスペクティブではメンバからさまざまな主張があったのですが,彼らが継続的改善に注力することで全体的な改善を達成しているという自負を得られていなかったことが,結果としてこの問題への対処を可能にしたのです。excellence)の問題について次のように説明している。アジャイルはソフトウェアデリバリの方法を改善するために生まれました。私たちが技術的卓越性にフォーカスしないのであれば,ソフトウェアの品質は苦痛を覚えるまでに低下し,簡単には変更できなくなるでしょう。なってしまっては,もはやアジャイルプロセスが何であるかの問題ではありません。開発はそれ以上先に進まず,企業はアジリティを失うことになります。ウォーターフォールの時代には,事前の設計やアーキテクチャに何ヶ月も費やす贅沢が許されていましたのですが,もはやそれは許されません。リーンによる湖や岩のメタファ,さらにはアジャイルで一般的になった頻繁なイテレーションが,非効率なプラクティスを痛切に明確化したからです。事前にスコープを固定せず,段階的な変更の提供を確約することは大事業であり,技術的な卓越性を秘めた強固な製品構築をその基盤とします。技術面での卓越性なくしては,コードベースの悪化という負担の下で,クライアントの要件を段階的に提供し続けるという約束を維持できない,ということが分かるでしょう。した努力は,結局は口先だけのアジャイルに行き着くだけで,真のアジャイルの兆しとはなり得ません。クリーンアーキテクチャの概念を例にしましょう。Rule)とは,アプリケーションがレイヤ化されていて,ジャストインタイムの意思決定が可能であることだけでなく,修正や拡張において自明でない作業を必要としないオープン性と柔軟性を備えていることを保証するものです(詳しくはSOLID原則のOCPを参照)。私は以前,医療保険を統合するイニシアティブで,ゲートウェイを段階的に開発するためにクリーンアーキテクチャを採用したのですが,最終的には国の医療保険データの70%を処理するまでになりました。私の最近の大規模な製品開発を中心とした経験から,中堅から大手の企業が競争上の優位に立つ上で必ずものにする必要がある,2つのプラクティスを(出発点として)お勧めしたいと思います。ドメイン駆動設計の必要性は,いくら強調しても足りません(と言っても,何もマイクロサービスを推している訳ではなく,ドメインの定める継ぎ目を越えるものならば,簡素な製品設計でも何でも構わないのですが)。技術者の数の限られているスタートアップならば,革新的なアイデアを素早く提供することも容易いのですが,グループのサイズが何十人(あるいはそれ以上)に増えるにつれて,複数のチームによるアプリケーションのさまざまなコンポーネント間の調整や依存関係が,変化するマーケットニーズに応える企業の能力を損ない始めます。ドメイン駆動設計のコンセプトでアーキテクチャされた製品ならば,スタートアップと成功企業の間のキャズムを越えた後も,その能力を維持することができるのです。私が経験したもうひとつの常習犯は非機能要件の軽視です(2016年のオーストラリア国勢調査をご存知でしょうか?)。私の意見として,製品が一定の負荷の下で,一定の応答時間の制約で動作する必要があるならば,それは機能仕様の一部なのであり,最初から考慮しておく必要があります。機能要件に適用されるATDD(受入テスト駆動開発)と同じ厳格さを,このような,いわゆる非機能要件にも適用しなくてはなりません。手遅れになるまで無視され続けるのです。Grenning氏にインタビューして,技術的卓越性の向上を目的とした技術的プラクティス適用のために何ができるのかを尋ねたことがある。失敗の一因は,単独作業と専門化の文化にあると思います。自分のコードだけを見ていると,それで問題ない,新たに学ぶものは何もない,という考えを持つようになります。開発サイクル後半のコードレビューでは,改善は非常に難しくなります。お互いがより緊密に協力するように奨励することが必要です。ペアプログラミングは技術的卓越性を広める方法として,双方向であるという点でも,非常に優れた手法です。将来を見据えた採用ですね。新たな才能はいつでも,既存の均衡状態に波風を立てます。エンジニアリングプラクティスに関わる企業文化が未熟な状態であれば,既存の文化に合った人材よりも,成熟を目標とした採用をするべきだと思います。この方法で,現状に前向きな影響を与える成熟の触媒として,新たな才能を使うことができます。一つ重要なのが,外部の支援を得ることです。ほとんどの企業において,現在のアーキテクトは過去10年間プログラマだった人材です。そのランクを強く希望する者がいたとしても,既存の階層構造においてこの技術分野に習熟することは,非常に難しくなっています。外部の支援を得ることは,それが既存の官僚主義に対抗するものであったとしても,組織の現在の状態を映し出す契機になります。最後に,エンジニアが解決すべき問題を与えられず,代わりにソリューションの実装を依頼されている場合には,反復型開発が終わりのない悪循環のように思われるかも知れません。作業者に権限を与えて自己組織化(自己流であっても)し,背景にある目標を与えることで,当事者意識が向上し,結果として作業者の積極性が得られます。従来型のマネジメントが認める以上に,作業者はチャレンジを求めています。自律性と目標提示をうまく組み合わせることで,彼らは積極的にすべてのエネルギーを提供してくれるでしょう。Stadiumで9月12日と13日に開催される。2016年版は第2回のアジャイル開発およびソフトウェアクラフトマンシップの会議として,サウスウェールズ州のソフトウェア開発者,ソフトウェアアーキテクト,プロジェクトマネージャ,コンサルタントらが集う予定だ。カンファレンスの様子はInfoQでもQ&Aや要約,アーティクルを通じて伝えて行く予定だ。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。