Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。(株)チェンジビジョンプロのトレーナーとコーチが何度も目にしてきたことがある。あまりにも多くのアジャイルチームがはまり込んでしまうパターン、すなわち、ワクワクするような、高度な「活躍」をする段階に進めず、ただの平均的な「導入」の段階で行き詰まってしまうという現象だ。読者の皆さんも考えてみてほしい。すべてのソフトウェア開発プロジェクトに共通することで、最大限にしたときに生産性が急上昇するものがあるかもしれない。多くがソフトウェア開発の、一見単純ではあるが、よく忘れられる「秘伝」をすでに活用している。それは、頻繁にふりかえって学習する時間をつくることである。何について学ぶのか?お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。仮想実験ソフトウェア開発をより良くするために何ができるか?ソフトウェア開発で典型的なボトルネックは何か?すべてに共通するひとつの点があるか?本物の実験を実施することができた時代は、とっくに過ぎ去ってしまった。本物の実験を実施するためには、同じプロジェクトを2回構築しなければならないのだ。残念ながら今日のビジネス環境でこれをやるのは非常に高くつく。従って、共通する弱点が何なのか正確に把握するために、実際に実験を行なってみるのは今のところ非現実的である。同時に、私たちは皆、専門家という立場でソフトウェアを開発した経験がある。そこで多くの学生に示した仮定の状況を紹介しよう。私が顧客で、あなたやあなたのチームにソフトウェアシステムを構築するように頼んだと考えてください。あなたのチームはソフトウェアシステムの構築に着手します。次に、私はチームに感謝してソフトウェアを受け取り、それを捨てしまいます。それから私はあなたとあなたのチームにシステムを再構築するよう依頼します。あなたには、同じチームがあります。同じツールと同じソフトウェアもあります。(何も変わっていません)。この仮定の状況を示すと、彼らは大体、最初にかかった時間の20%から70%の範囲で答える。構築するのに1年かかったシステムを再構築するのに、わずか2.5から8.5ヵ月しかかからないことになる。大きい差なんだ!これだけソフトウェア開発に影響を及ぼすことができる要因が他にあるだろうか。それでは何が問題なのか?2回目のときは何が異なっていたのか?チームは学習したのだ。彼らはチームとして互いについて学び、1年間かけて調和していった。利用することを学んだ。基本的に、ソフトウェア・ソリューションを構築し提供するまで、よく分からないことに取り組んでいたのである。学習はソフトウェア工学の「ボトルネック」だ。[2]学習が必要になると、仕事のかなりの割合を占めることになる。実際に、それは開発時間のおよそ30%から80%の割合を占めると推測される。ここにアジャイルプラクティスがうまくいく主な理由がある。ここでいうアジャイルプラクティスはすべて変化に気づき対応することに関するものである。すべて、チームが速く学ぶことができるサイクルから成っている。あらゆる実行可能なプラクティスを反復することによって、アジャイルなチームはソフトウェア工学のボトルネックに本気で取り組み、学習を促進する。すべてをテストする」などと呼ばれることなのだ。「学習はボトルネックである」という眼鏡を通してアジャイルを見る関連スポンサーコンテンツアジャイルソフトウェア開発は効果的である。何百もの成功事例が過去8年間にわたって実証されてきた。アジャイル開発に関して興味を引かれることの1つはプラクティスの大半が新しくないということだ。実際、それらは非常に古い。アジャイルは単に最もうまくいったソフトウェア開発のプラクティスの多くを抜き出して、それらを集めたものだ。事実、アジャイルマニフェストは何も新しいことは言っていない。よる2つの異なる説明がある)。効果的なプラクティスの多くについてよく考えてみると、いくつかの非常におもしろい共通点が明らかになる。変化に気づき対応するためのサイクルどうやって学ぶか?私たちは間違いから学習する(もし注意を払っていればであって、多くの人はそうではないが)。やってより速く学習するか。間違いを速く経験する。「フェイル・ファースト」だ。学習したことをすぐに活用することが、学習を確固たるものにして自分の中に「定着」させる秘訣である。私たちが何度も目にする非常に一般的なサイクルは、次のようなものだ。その目的を達成するために行動する。行動した結果と最初の目的を比べる。それに応じて行動を変更し、(2)に戻る。ステップ(3)で学習し、ステップ(4)で適用する。この単純なサイクルはアジャイル開発における多くのプラクティスの基礎になっている。失敗するテストを書く。テストが通るようにコードを書く。テストが失敗しているなら、原因を調べて(2)に戻る。チームとしてその日のうちに完了させるタスクを決めて、毎日のスタンドアップミーティングで報告する。翌日、進み具合と進捗の妨げになっていることを報告する。学んだことを翌日の計画に適用する。要件をテストとして定義する。ソフトウェアを開発する。テストが通ったら完了。テストが通らなかったら、原因を解明して、(2)に戻る。「完了状態」を定義する。イテレーションのバックログにある要件に取り組むことを明言する。そのイテレーションでバックログを完了させるように取り組む。「完了状態」に対して各項目をテストしてイテレーションを終了し、完了のマークをつけるか、またはペンディングにして要件をバックログに戻す。デモ通常、イテレーションの終わりに行われる。実装が完了したときに、想定していた要件が本当に目の前の問題を解決するかどうか、実際に顧客が試すことができる。要件に盛り込むビジネスニーズ/価値を決定する。イテレーションの間、要件を構築する。ビジネスニーズに対して実装された要件を評価する。チームの進め方を決める。イテレーションの間、そのやり方で進める。プラクティスがどれくらいうまくいったかふりかえる。効果的なプロセスを作って、それを導入するためのアクション(担当者と期日も含む)を考え出す。リリースに向けたビジョンをつくり、リリースで満たすべきビジネスゴールを決める。リリースバックログをつくる。リリースを構築するために何度かイテレーションを行う。顧客の環境にデプロイし、次のリリースのためのフィードバックを集める。スクラムのスクラム一度に複数のプロジェクトを扱う場合、各プロジェクトはそれぞれ自分達のサイクルがあり、同時に定例会で同期をとる(スクラムのスクラム)。定例会は各プロジェクトの代表者が他のプロジェクトに報告する場である。それは企業レベルで変化に気づき対応する機会を与えることになる。プロダクトオーナーかビジネスステークホルダーと協力して、高い水準で、どうやってプロジェクトやリリースの成功を計測するか定義する。チームが期待に沿って機能するように、これらの「テスト」を見えるようにしておく。管理テストの評価をふりかえりの中に組み入れる。チームとプロダクトオーナーは、各イテレーションがこれらのテストに合うよう協力する。これらのサイクルの多くは、うまい具合に組み合わせて内部サイクル・外部サイクルにできる。テスト駆動要件にはいくつかのテスト駆動開発のサイクルがある。イテレーションにはいくつかのテスト駆動要件のサイクルがある。リリースにはいくつかのイテレーションのサイクルがある、など...。これらのサイクルはお互いに影響し合う。実際、外側のサイクルの誤りを発見するような学習が起こって、絶えずお互いに影響し合っている。テスト駆動開発のループはテスト駆動要件の中で入れ子になる。各要件ごとに、1つの要件を満たすためのいくつかのテスト駆動開発サイクルが起こる。したがって、例えば、テストが通らないのはコードが間違っているのかもしれないが、そうではなくて、これから構築する要件のために、以前の別の要件を破棄する必要があるのかもしれないのだ。テスト駆動開発のループでは要件について学ぶことになる。同様にイテレーションはリリースの中で入れ子になっている。そこで、予測外の技術的な制限により1つ以上目標が達成できないイテレーションがあると、システムの重要な部分を完成させるための工数が追加で必要になる。チームは再び集まって、リリースバックログを考慮し、新しい情報に対応するため優先順位の付け直しとスコープの変更を行う。サイクル:必要であるが、十分でないサイクルは変化に気づいて対応するための2つの基本的な要件のうちの1つである。サイクルは機会を提供する。2つ目の要件はコミュニケーション(みんなを巻き込むことで学習効果を高めること)である。したがって、アジャイル開発の試みの中では「情報発信器」が重要視される。情報はチーム内のメンバーをはじめチームの垣根を越えて伝える必要がある。コミュニケーションがなければ、問題に気づかないかもしれない。コミュニケーションがなければ、問題に気づいても解決策を見つけることができない人は、解決策が分かっている、自分とは異なるスキルを持っている人から、何も教えてもらうことができないかもしれない。チーム環境では、与えられた問題を解決するのに誰が一番ふさわしいか必ずしも明白ではない。みんなに知らせることによって、あらゆる利害関係者から提案を引き出すのだ(チームの「専門家」からだけでなく)。時には初心者や部外者が「これまでとは全く違った視点で考える」ことができて、驚くことがある。コミュニケーションは学習を促進し、強化する。考えるためにきちんと立ち止まることで、「急げ、急げ!」という叫び声によってコミュニケーションがかき消されないようにできる。このように立ち止まるには、正式にふりかえりを行ったり、イテレーションの終わりに気軽に食事に行ったりすればよい。学習と改善について話し合えばよいのだ。コミュニケーションは各サイクルの始め(目標を決めること)と終わり(テスト結果)に計画されたやり方で行うべきである。コミュニケーションからも大きく得るものがある。かなりの数のアジャイルプラクティスは、直接、コミュニケーション(公式なものも「浸透する」ものも)に注目している。チームが一緒に働くのは、起こる変化に一緒に対応するためである。チームメンバは一緒に座って、日常的にグループで会話をする。会話は周りの人の耳にも入る。各メンバは周りで何が起こっているのかなんとなく理解する。複数の専門分野を持つチームはエンド・ツー・エンドで問題を解決するために一緒に取り組む。一緒に働くことによって、各個人の専門知識を共有する。1つのタスクを解決するために2人が一緒に作業するのは経験と専門知識を共有するのに非常に意味がある形である。「大きな目立つ図」である。この図の唯一の目的は通りがかりの人にいくつかの重要なデータを伝えることである。アジャイルチームは話し合うためにドキュメントを一緒につくる。後で読むと、それらのドキュメントが議論全体とその状況を思い起こさせる。これらは、本来よく書かれている伝統的で壁越しに投げ渡すようなドキュメントよりもはるかに価値がある。正式なドキュメントというのは、あまりに力を入れすぎるので、実際に書かれている通りであるという(正しくない)確信をいだくことがあるのだ。アジャイルチームはちょうど完了したタスク、進捗の妨げになっているもの、次の1日のサイクルで完了させようと計画しているタスクを伝えることで毎日同期をとる。コミュニケーションをサイクルに加えると、チーム全体がより速く学習しチームとして反応することを可能にする。結局、ソフトウェア開発は協力してする仕事である。学習がチームのボトルネックであるなら、チーム全体としてできるだけ多く、そして速く学ぶ必要がある。上手にプラクティスを使っているなら、アジャイルチームはすべて(単に技術的なことだけでない)に関して素早く学習する。それは、設計(TDD、ペア・プログラミング、様々な仕事をこなすチーム)、要件(デモ、TDR)、製品(イテレーション、リリース)、人(ふりかえり、スタンドアップ・ミーティング)などである。学習はソフトウェア開発で非常に重要な部分であるらしい。学習は今認めているよりもさらに重要である。したというのだろうか?学習することで私のチームやあなたのチームがより良いソフトウェアを作り出す。それをどうやって手助けすることができるのか?前掲の「学習」のプラクティスのすべての例にもかかわらず、アジャイルチームは学習ボトルネックに影響される。緊急な要件の場合、(「まぁ、それは後でやるさ」と)学習ステップを省略して、短期的にうまく終わらせなければならないからだ。学習しないアジャイルチームは以下の兆候の一部あるいは全部を示す可能性がある。やる気の問題につながる疲労(本当に持続可能なペースで働いていない)1回のイテレーションで「完了」できないことが続く続けて約束を果たせない(いくつかの約束された機能やストーリーは着手もしていない)デプロイされたソフトウェアから、立て続けに多くの欠陥が見つかり、開発計画が頓挫するふりかえりを過小評価するかやめてしまう(「だって、実際に私たちが認識している問題を解決していないじゃない」)ボトルネックから目を離すな以下の図について考えよう。各ステップは、ステップ名の下に括弧で示された速度が示されている。2つのステップ間で速度が合わないとき、在庫がたまる。したがって、ステップAがステップBより速いので、Aの余った製品はBによって処理されるのを待つ。システム全体のスループットは、ボトルネック[6]によって、常に制限される。システム全体のスループットを向上させたいならば、ほぼ例外なくボトルネックのパフォーマンスを向上させることに重点的に取り組む必要があるということだ。他のところで費やされる努力は、無駄で逆効果になることさえありうる。SSP(以下の図)では、改善することができる唯一の方法はステップDを調整することである。他のものに取り組んでも改善しないであろう。学習が本当にソフトウェア開発のボトルネックであるならば、学習を優先順位の一番目にすべきである。それは、学習以外のことにどんなに努力を費やしたとしても生産性の向上は限られているということだ。逆に言えば、生産性を改善することは何かしら学習の度合いを改善してきたことになる。プロセスについてふりかえるとき、より多くの価値を提供する方法を熟考し、私たちが働いている企業に、通常いくつかの価値を提供していることを忘れてはならない。その価値はもちろん動作するソフトウェアだけでなく、メンテナンス可能で変更可能なソフトウェアとそういった仕事を持続する反応が速いチームである。最初の2つの優先事項は企業から求められるべきである。3番目は、単にプロ意識への期待であり、通常は開発組織のコントロールの範囲内にある。この最後の形をした価値(チームのアジャイルさ)は、実のところ組織の資産であり、個々のプロジェクトを超えて生き続ける。以降のプロジェクトでより大きな利益を生み出し、速度が増すきっかけとなる。アジャイルチームは成長して効率的なチームワークを発揮するために、6ヵ月以上を一緒に過ごす比較的安定した生命体でなければならない。そのようなチームを構築するには戦略的な視点が必要である。それは各イテレーションにおいて仕事としてやるべきこととともに考慮されなければならない。このバランスが維持されなければ、チームはすぐにその仕事で失敗することになる。プロセス中の問題は解決されず、予測できる開発速度や品質の支障となるからである。脆弱で一貫しないチームをつくるのを避けるために、私たちがプロセスについて考えるとき、次の2種類の質問をするべきだ。「これは、次のイテレーションで開発速度にどう影響するか?」そして「これは、学習にどう影響するか?」(言い換えると、以降のすべてのイテレーションとプロジェクトおいて私たちの開発速度と反応の仕方に影響するか)「ペア・プログラミングは開発速度を落とすだろうか?」とだけ尋ねるのではなく、「ペア・プログラミングは私たちの学習の速度を遅くするだろうか、それとも速くするだろうか?」とも尋ねるべきだ。「ステークホルダーは月1回のペースでしかミーティングに出席できないのに、本当に2週ごとにデモをするべきだろうか?」と尋ねる代わりに、「デモを月に1回の頻度に減らすと、学習にどう影響するだろうか?」と尋ねるべきだ。「アジャイルをサポートするためにどのツールをインストールするべきか?」と尋ねる代わりに、「ツールABCは学習を増進させるか?あるいは、それはコミュニケーションの機会を減らすため学習を遅らせるか?」と尋ねるべきだ。いいのは、(それから学習するために)情報を追って必要だと分かるまで待とう。あなたの仕事[7]をもっと減らすことができるツールを見つけよう。私たちは、学習が「チーム」という企業資産を強化することを理解すると、ステークホルダーに学習のプラクティスがもたらす利益について説明できるようになる。「はい、ペア・プログラミングは一見したところコストが高く付くように見えます。長期的に見たとき、それがどのようにリスクを相殺して、目に見えるコストを上回るかについて説明させてください...」アジャイルの短いサイクルで「長期間」というのはわずか3週間から6週間ほどであることをお忘れなく。ここからどこへ行くかこの記事を書く1つの目的があった。それは学習に関する理論や構造を分析することではなかった。できるし、実際そういうものは沢山あった。どれも異なるアジャイルプラクティスを分類ないし評価していなかった。それらは単なる例であったり、私たちが学べばすでに多くの学習方法があることを思い起こさせたりするものであった。私たちの目的は、学習を心と行動の第一線に導くことであった。それがアジャイルプラクティスの成功の鍵であると信じるからだ。心の中で学習し続けないで、それを前面に出しなさい。この記事は、アジャイルなやり方が既に多くの学習のプラクティスやメカニズムを提供しているということを思い出させる立場に立っている。それらすべてはチームとビジネスに役立つように効果的に使われているだろうか?「学習はボトルネックである」という眼鏡を通して世の中を見よう。すれば、儀式的なアジャイルプラクティスの出番を大いに減らし、最大の効果を得るために全力を注ぐことができるのである。Tuckman氏によって最初に提案された。Johnson氏から来ている。参照のこと制約理論に精通している読者はこの議論をなじみがあると感じるだろう。非線形のプロセスを考えるときは、いろいろな意味で全体的に単純化される。適切なアジャイルのメトリクスを参照(source)すること。第二次世界大戦中に、多くの空軍基地は、産業化されていない人が住む熱帯の離島に建てられた。戦争の間、兵士は飛行場と管制塔を建設して、積荷でいっぱいの大きな飛行機を着陸させて、積荷を降ろす様々な活動に従事した。地元の住人たちはこの積荷を分け合った。戦後、兵士たちが立ち去って、地元の住人たちにもう積荷はなかった。それで、彼らは積荷でいっぱいの飛行機を戻って来させようとして、表面的な形で滑走路と管制塔を作り、儀式的な振舞いをするようになった。カーゴカルトは実体の代わりに形式的なものを採用して、そうするのが望ましい結果を引き起こすと信じているグループです。Elssamadisy氏(source)はソフトウェアの専門家である。ソフトウェアの構築は非常に困難なことであり、Amr氏はソフトウェアを開発するより良い方法を見つけて、それをコミュニティと共有することに取り組んでいる。今日、アジャイルなソフトウェアのプラクティスをうまく取り入れることで、顧客がより良いソフトウェアを構築するのを手助けしている。将来は、私たちがソフトウェアを構築するより良い方法を学ぶにつれ、確実に何か違ったものになるだろう。Communityの編集者である。Hartmann氏(source)はバイリンガルのアジャイルの専門家である。トロントに本拠を置き、国際的に活躍している。Deborah氏は仕事を企業にとって価値あるものにすることとチームを楽しくすることに取り組んでいる。彼女はアジャイルを採用する大小の企業のコーチをしている。Communityの第一編集者を務める。カナダと米国でXPとBarCampのコミュニティのためのOpenSpace会議をファシリテートした。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。