Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。projects"というセッションの中で,すべてのプロジェクトを一掃してはどうか,という問題提起を行った。InfoQでは氏にインタビューして,アジャイルにとって有益なプロジェクト管理の実践,および製品開発資金に関する話を聞いた。今までとは違った考え方を引き出したかったのです。複雑な環境の中で行う製品開発において,"プロジェクトを行う"ことが本当に適切なのか。何か他の方法で利益を維持し,欠陥を取り除くことはできないのか。今回のセッションでは,そのようなことを明確にしたいと思っていました。実際に私は今,非常に大きな組織で仕事をしているのですが,そこではプロジェクトマネージャという肩書きは廃止されています。チームがあって,製品があって,それらが直接,ビジネス上のニーズによって動いているのです。それでは,プロジェクトマネージャと呼ばれていた人たちの持っているスキルは,もはや企業の必要とするものではないのかというと,そういう訳ではありません。その人たちは基本的に,自身のスキルセットに見合った役割に移っていけばよいのです。目的や方法,資金,タイムラインなどの管理が非常に重要であることは,アジャイルでも変わりありません。いわゆるプロジェクトマネージメントには,グッドプラクティスと呼ばれるものは山ほどあります。それらのほとんどは,プロジェクトなしで製品開発を行った場合でも,十分に応用可能です。私たちが本当に排除したいのは,予測や指揮統制管理の誤った運用に関するプラクティスなのです。いう行為と,極めて強く結びついていることが分かっています。その上,私たちが経験してきたプロジェクト組織は,人や品質,価値といった,本当に必要なものへの考慮が十分ではありません。いった意味から私は,"プロジェクトを行う"ことなく開発を実施する方法について,考える価値があると思うのです。組織から製品開発の資金を獲得する場合,予算請求を行うのが一般的です。予算というのは,およそ考えられる中で,もっともくだらない仕組みです。予算を立てたが最後,1年前には予想もしなかったことに縛り付けられる1年サイクルから逃れらなくなります。その上,年末になって要求した予算額が必要でなかったならば,何とかしてそれを消化しようとします。しないと,翌年の予算が削られるからです。最近では多くの企業が,反復的あるいは段階的な方法で開発資金を提供するようになっています。そこでは自らのメリットを基準として,すべての投資が判断されています。