Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。皆様のご要望にお応えするべく、ノイズを削減する機能セットを開発しました。皆様が関心をお持ちのトピックを、EメールとWeb通知で受け取ることができます。新機能をぜひお試しください。VersionOneから公開された。報告書の結論からは、顧客満足度の必要性の増大、アジャイルを大規模展開する企業の増加、アジャイルソフトウェア開発における分散型チームの一般化に加え、多くの企業が今後12ヶ月以内にDerOps活動を開始ないし計画していることが確認される。Reportについてインタビューした。調査で追跡しているトレンドは、基本的には年単位の漸進的な変化であって、その多くは、同じファンダメンタルに対処する必要のあることを示しています。企業文化などはその一例です。今年は、大きな変化がひとつありました。アジャイルイニシアティブ(変革活動そのもの)とアジャイルプロジェクトの両面で、顧客およびユーザ満足度の重要性が高くなったのです。これまでの調査では、“オンタイムデリバリ”や“品質”、“ビジネスバリュー”といったものが、顧客満足度よりも上位にありました。バリューストリームにおいて、顧客が最も重要なエンティティであるという認識が広まったからだと思います(そう願っています)。顧客の声を聞かず、本当に望まれているものを提供できなければ、彼らはただ立ち去るのみです。なってしまっては、オンタイムに提供できるか、価値があるか、バグが少ないかなどは、もはや問題ではありません。アジャイル憲章の第1原則では、顧客満足度が最優先事項である、とうたっています。それ以降の原則はそれを支えるためにある、と私は思っています。簡単に思えるかも知れませんが、企業として今一度この原則を検討して、自分たちの行なっていることが原則に反していないかを見極めるべきだと思います。“変革は顧客の競争上の優位性に結び付くものなのか、自分たちのスケジュールやリソース管理を優先して、実は変革を抑制しているのではないか?”、という疑問が生じるかも知れません。今回の調査では、アジャイルを採用する理由のトップ5として、“ソフトウェアデリバリの加速”、“優先度変更に対する管理能力の向上”、“生産性向上”、“ビジネスとITの整合性向上”、同率の5位に“ソフトウェア品質の向上”と“デリバリ予測性の向上”が挙げられています。ほとんどが数年前からトップ5にあったものです。この5つ(実際には6つ)の期待が、実現したメリットとして報告されている上位8つに含まれている点に注目してください。あと2つのメリットは“プロジェクトの可視性”と“チームのモラル”です。可視性もモラルももちろん、その他のものを達成することと大いに関係しています。強く求められている期待の大部分は、回答者の大多数の間ではすでに実現している、とも考えられます。予測可能性やリスク低減、品質といった分野で改善が見られない企業には、アジャイル変革の持続性という面で懸念があります。私の経験では、これらの領域で問題が解決されない場合、アジャイル変革への支持が徐々に失われていく可能性があるのです。報告書によると、アジャイルのスケールアップで最も有効なのは、社内のアジャイルコーチ、チーム間で一貫したプラクティスとプロセス、チーム間の共通ツール採用の3つです。大企業において、独立した複数の草の根アジャイル活動が時間の経過とともに形成されて、それぞれが異なる規範とさまざまなツールを備えるようになる、というのが一般的なシナリオです。このようにしてアジリティの孤島が多数発生した企業が、それらを取りまとめて、統制の取れた方法でアジャイルの力を活用したいという場面まで話を進めましょう。この時点になると、企業にとって意味のあることは何なのか、いくつかの決断を下さなければなりません。“これらのチーム間でリアルタイムの可視性を実現するにはどうすればよいか?”、“すべてのチームが同じ方向に進むために必要な共通性を育み、なおかつチームのアイデンティティを損なわないためにはどうすればよいか?”といった疑問が生じます。プラクティスの一貫性だけであれば、適切なツールを選べば十分です。単純な例としては、スクラムチームとかんばんチームが混在しているような企業があります。全体に共通する要因の改善機会を明らかにする目的で、すべてのチームのサイクルタイム計測を依頼するかも知れません。主体的に実施する必要があります。同時に、なぜそれを行うのか、私たちが説明できなくてはなりません。プラクティスの背後にある原則を重要だと考えるのは、そのような理由からです。同時に私たちは、うまくいっていないことを止める意思を持たなくてはなりません。向かって進むことになるかも知れないのです。分散型アジャイルチームが普通のものとなって、回答者の79パーセントが少なくともいくつかのチームでアジャルを実践している、と答えています。今日では多くの人々が、地理的に分散した企業拠点のみではなく、自宅や旅行中にも仕事をしている、という現実を反映したものだと思います。言葉を換えるならば、全員が同時に同じ部屋にいる必要はない、ということです。アジャイルが私たちにとって重要であるならば、それを機能させる方法を見出さなければなりません。--確実に向上しており、分散アジャイルを技術面で可能なものにしています。メンバの4人がフロリダ、1人がテキサス、もうひとりがアラスカというように、個々のチームメンバが地理的に離れた場所にいる分散型アジャイルで、成功を収めた企業もあります。チームメンバがあまりに多くのタイムゾーンに分散していると、この方法では難しくなるかも知れません。地理的に同じ場所にいるメンバが地理的に分散したチームを構成して、共同でひとつのプログラムやリリーストレインを開発した成功例もあります。分散型チームにアジャイルを適用する企業が成功を収めるための基本的な要因は、彼らが真のアジャイルチームであるかどうかにある、と私は思っています。ロケーションXにある“Dev”チームが作業をロケーションYの“QA”チームに引き渡すような方法では、成功は覚束ないでしょう。調査では、採用されているアジャイル技術について調べている。修正項目の反映(あるいは適用結果の確認)がアジリティにおいて不可欠である、という認識の現れだと思います。これがトップ5に入っているという事実は励みになりますね。逆に採用率の低いものとして、報告書では、共通作業領域やストーリマッピング、アジャイル/リーンUXが取り上げられています。したことは分かりませんが、意見として述べたいと思います。アジャイル“ショップ”の中にあって、UXはいまだ非常に特殊なスキルセットで、複数のチームの中でも1~2人のUXしかいないのが現状ではないかと思うのです。共通作業領域が比較的低いというのは、単に組織文化がアジャイルの価値観に対応していないことの現れでしょう。法人の施設部門が認定された座席配置からの逸脱を認めない、というのはよく聞く話です。楽観的に見るならば、作業労力が分散しているため、もはやチームメンバが同じ大陸にいる必要さえない、ということの現れかも知れません。ストーリマッピングは暫く使用していましたが、十分に理解されているかどうかは分かりません。いずれにせよ、人々は現在でも、階層的な機能のブレークダウンの方が安心できるのだと思います。目立ったのは、かんばんボードがトップスロットに上って、タスクボードに取って代わったことです。タスクボードはまだ3位ですが、これは開発を考えることから提供を考えることへの移行の兆候だと見ています。企業の71パーセントがDevOps活動を実施している、あるいは今後12ヶ月以内に開始する予定である、としています。回答者がDevOps活動の成功を評価する方法から考えれば、期待されていることのトップ3は、“提供速度の向上”、“品質改善”、“ユーザへのビジネス価値フローの向上”ということになります。“顧客満足度の向上”は5番目の回答に過ぎず、アジャイル活動に関して報告されている成功条件とは興味深い違いがあります。これは調査の回答者が、“DerOpsの成功”についてはデリバリパイプラインの効率を中心に考えるのに対して、“アジャイルの成功”ではバリューストリーム(デリバリパイプラインはその一部)の大きさを考えている、ということなのかも知れません。今年の調査には直接的な質問はありませんでしたが、来年は取り上げてみたいですね。調査とは別になりますが、完全な“コンセプト・トゥ・カスタマ”バリューストリームの一部としてDevOpsの採用にアプローチする場合には、単に“ITバリューストリーム”という観点から考える場合よりも、ビジネス価値のスループットに与える影響が大きいように思います。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。