数年前、私たちも熱心に柔軟な開発方法論に簡単に切り替え始めました：アジャイルを実装します。 私たちは外部コンサルタントを雇い、プロセスを実行するために大きな製品を割り当て、熱心に素早く効率的にそれを始めました。 彼らはそれをし、彼らはそれをし、それから秘書と1000人のキャラクターについてのジョークのように、それはアジャイルではなく、ある種のナンセンスであることに気づきました。 そして、すべての仲間が以前と同じように働いており、人々は経験を積んでおり、製品は機能しているように見えます。
チームの動機が落ちました。 顧客は、「魔法の」日付の申し立てが満たされていないという事実から途方に暮れており、一般的に、アジャイルはまともな社会には居場所がないと言っています。 その結果、小さなグループのアジャイルトランスフォーマーが座ってブレインストーミングしましたが、なぜ機能しないのですか？ 彼らは私たちを妨げる制限を書き始めました。 それらはたくさんあり、私たちはそれらをドラゴンと呼びました。
大企業では、プロセス、製品、チーム間に相互依存関係がたくさんあります。 そして、何か新しいもの-私たちの場合はアジャイル手法-を導入するには、干渉する関係を解消し、多くのプロセスを修正する必要があります。 そして、何があなたを悩ませているのかを正確に理解せずに対処する方法がなければ、すべての良い進歩的な取り組みは失敗に終わる可能性が高いでしょう。
すでに私たちが大切なアジャイルに到達するのを妨げるものを議論した会議で、私たちは、障害を打ち負かす必要がある障害を「ドラゴン」と呼ぶアイデアを思いつきました。 そしてすぐに、各恐竜に対する勝利の段階を定めました。 それはすべて2年前に始まり、私たちのドラゴンのほとんどはすでに敗北していますが、カップルはまだひらひらしています。
まず、アジャイルに加えて、当社の大規模な製品では、ウォーターフォール開発プロセスも使用しているため、導入が妨げられていることを明確にする必要があります。最初に分析段階、次に開発およびテスト段階を経ました。 問題は、アナリストが解放されると、別のタスクに切り替えることです。 そして、開発者やテスターが困難で、アナリストに頼ると、それらの頭はすでに完全に異なるタスクで占められているので、彼らが最初の段階で何をしたかを思い出すことさえ困難です。 また、他のユニットについても同じことが言えます。これは、ある時点で、前のステージを実行した同僚にアピールします。
各「ドラゴン」について、Jiraに個別のセクションを作成し、このドラゴンに関連するユーザーストーリーを入力しました。 彼らがすべて閉じたとたんに、ドラゴンは敗北したと見なされました。
私たちのケースで最も有害なドラゴンの1つは、 請負業者と締結した一定額の契約であることが判明しました。 契約の合計額が不変であることは、ある時点で生産の変更の配信を単純に凍結できることを意味していました。 つまり、すべての価格はかつて設定されていたものであり、何らかのアジャイルを導入することを計画していたため、作業量は増加する可能性がありますが、契約の量はそうではないため、最終結果を保証する人はいません。 私たちはそもそもこのドラゴンを殺しました：請負業者と協力するという原則を変え、最終的な製品やサービスではなく、開発チームのリソースを購入し始めました。つまり、全員との反復開発に切り替えました。
私たちが取り組んだ 2番目のドラゴンは、 GitFlow開発プロセスの欠如です。 アジャイルは絶え間ない反復的な変更を意味し、通常のGitFlowの代わりに、3か月から5か月の巨大で不器用なリリースがあり、すぐに実稼働に移行しました。 エンドツーエンドのテストやユニットテストはなく、統一されたテストデータさえありませんでした。 すべてが手動で実行されたため、テストフェーズは非常に長く続きました。 一度に3匹のドラゴン！
おなじみの「滝」を壊すという難しい段階が始まりました。 GitFlowのトレーニングを実施し、現在のリリーススキームに最適なブランチを維持するためのルールを実装した後、新しい開発プロセスとサポートサービスに移行しました。 その結果、今日、いくつかの異なるチームがいくつかの開発ブランチを率いて機能を作成しており、メインブランチには現時点で必要な機能のみを注ぎ込んでいます。 ここで、同時に2、3匹のドラゴンを釘付けにしました。自動テスト手順を導入し、回帰自動テスト用のテストデータを準備し、ユニットテストの使用を開始しました。 そのため、3か月に及ぶ大規模なリリースの代わりに、少なくとも毎日運用環境で作成されたmasterブランチに機能を送信し、セルフテストによりコードを実行できます。 確かに、自動テストの問題が完全に解決されたとは言えません。カバレッジの程度などの基準があるためです。 しかし、私たちは卓越性のために努力しています。
「 技術的義務 」と呼ばれるドラゴンと戦わなければなりませんでした。 おそらく、彼に対する勝利は私たちに最も難しいものを与えられたのでしょう。 それ以前は、それがどのような義務であるか、またはそれをどのように使用するかをまったく理解していませんでした。 以前は、人々はそれを台無しにすることは可能だと考えていましたが、サポートはいつかそれを修正するでしょう。 いいえ、申し訳ありませんが、あなたはあなたのコードに対して責任を負わなければなりません。 技術的負債を処理するためのルールを決定し、コードをレビューするためのチェックリストを作成し、技術的負債のバックログを処理するプロセスをデバッグし、チームでコードをレビューする必要がありました。
ドラゴンの数の中で、同僚と知識とスキルを共有することができないことも消耗しました。 誰かが何かをした-そして走った。 詳細な文書の作成、または「口コミによる」神聖な知識の伝達にさえ、ほとんど注意が払われませんでした。 このドラゴンに対処するために、部門内のスペシャリスト間で経験を交換するプロセスを導入し、アジャイルチームで毎週コードレビュープロセスを確立し、スペシャリストの包括的なトレーニングと開発のための定期的なイベントを開始しました。
しかし、ドラゴン「 透明性 」と「 CI / CD 」はまだ勝てません。 状況は2年前よりもはるかに良くなっていますが、勝利は近いです。
透明性とはどういう意味ですか？ たとえば、製品の所有者は顧客からタスクを受け取り、それをチームに持ち込みます。 チームから戻って、彼は顧客の用語、理解、実装をもたらします。 プロジェクトマネージャーがいない場合の一種の送信リンク。 そして、これまでのところ、顧客は期限などの管理方法について十分に理解していません。
同時に、チームは以前、顧客が達成したい製品のビジネス価値を必ずしも理解していませんでした。 アーティストと顧客はほとんどコミュニケーションしませんでした。 同時に、KPI、いくつかの目標の達成の成功は顧客の条件に依存し、請負業者はプロジェクトで提供するコードの価値と役割を理解していませんでした。 特に、複数のチームがあり、それらが並行して作業している場合。 さまざまな同期イベントの助けを借りてこのドラゴンを倒そうとしています。パフォーマーと顧客の間のミーティングを手配することがよくあります。 これはチームの動機付けに役立ちますが、ドラゴンはまだ呼吸しています。 そして、これを合わせて「上と下の両方から透明性を確保する」と呼びます。
CI / CDについては、テスト中の問題に関する通知を設定し、リリースカテゴリを導入し、それぞれのチェックリストを開発し、あらゆる環境でコードのブランチを展開する機能を実装し、本番環境に完全に自動展開しました。
アジャイルはどうですか？
彼はすべて順調で、彼は働いています。そして今、SAFeを基盤として会社全体に拡大しています。 すでに製品間チームがあり、複雑さが大幅に増加しています。また、このため、新しいドラゴンが発生し、それらを一緒に絞めなければなりません。 さまざまな困難とそれらを克服する方法を議論する会議の社内名もあります-「ドラゴンを殺す」。 この用語は、アジャイルで動作しないチームに根付いています。 仕事を妨げるものはすべてドラゴンと呼ばれ始め、彼らは戦わなければならないことを暗示しています。 従業員の一人が彼の作業報告書に書き留めたときに奇妙なケースがありました：彼はドラゴンを殺しました。 つまり、私は現在の状況とさらなるステップの議論に参加しました。 彼の上司は「よく、よくやった」と読みましたが、報告書が弁護士、投資家、方法論者を経て上司に来て、労働時間中にドラゴンを濡らしても大丈夫かどうか尋ねました。
私は翼のある爬虫類を持つ戦闘機の困難な日常生活について話さなければなりませんでした。