ウォーターフォールからアジャイルへ企業文化を変える

ラッセル・マーティン
2017 年 3 月 30 日
分読み

私の名前はラス・マーティンです。 Mendix エリー保険のシニアソフトウェアエンジニアとして3年近く働いています。 Mendix プラットフォームを利用していくつかのプロジェクトを完了し、大きな成功を収めてきました。ウォーターフォールからアジャイルプロジェクト手法、そしてそれらを克服するためのヒントもいくつか紹介します。

ウォーターフォールチームへのアジャイルの導入

最初に紹介したときは想像がつくと思いますが、アジャイルの概念、ウォーターフォールチームから当初の躊躇や懸念が寄せられるでしょう。変化は多くの人にとって難しいものであり、特にまったく異なるものに移行する場合はなおさらです。私たちが見つけた 2 つの最大のハードルは、反復開発の概念の導入と継続的な要件でした。

多くのウォーターフォール組織では、開発を開始する前にプロジェクト全体を設計してレイアウトするのが一般的な傾向です。ウォーターフォールに精通している方なら、チームがコードに取り組み始める前に、要件収集と設計セッションに数か月かかることをご存知でしょう。また、これらのセッションにチーム全体が関与しないため、分野間の断絶も生じ、知識の移転も必要になります。このプロセスでは、かなりのオーバーヘッドが発生し、非常に時間がかかります。アジャイルプロセスは、ウォーターフォールとはまったく異なります。人々の考え方を、これまでのトレーニングや経験に反するように変えようとすると、不安が生じます。これは正常で予想されたことです。

アジャイルプロセスは、ウォーターフォールとはまったく異なります。この変更に対する不安は予想されており、むしろ正常です。

これを克服するには、アジャイル手法の利点を示すことで、人々にその価値を理解してもらうことができると私は考えています。まずは小さな概念実証から始めましょう。アプリケーションの小さな部分、または置き換えにかなりの時間がかかると思われる部分を取り上げて、数週間以内に何ができるかを確認します。ビジネスアナリスト、ソフトウェアエンジニア、品質保証など、さまざまな分野から少なくとも 1 人を関与させます。その理由は、この種の変更に影響を与えるには、さまざまな視点を持つ人々が必要になるためです。複数の人に新しい手法を理解してもらうことができれば、組織の残りの部分を参加させることがはるかに簡単になります。また、 Mendix チームは、このような文化の変化に対処する経験があります。外部の人が質問に答えるのを手伝ってくれることで、理解がさらに深まり、導入の促進につながります。

この概念実証の鍵は、チームワークです。間違いなく困難な戦いに直面することになるでしょう。スプリントゼロ演習にチームを参加させる必要があります。ここで、チームはいくつかのストーリーをまとめて、ユーザーインターフェイスに何を表示したいかを決定します。チームのすべてのメンバーを参加させることで、彼らは結果にもっと投資するようになります。彼らはプロセスに発言権があると感じるでしょう。長期的にはこれがいかに重要であるかを強調しきれません。ドキュメント重視のプロセスからストーリーカードアプローチに移行することは、ウォーターフォール手法を実践する多くの人にとって馴染みのない概念です。チームメンバーからの反発に備えてください。それは普通のことです。この概念実証は、実験、トレーニング演習であることを忘れないでください。これは、本番環境に移行する本格的なプロジェクトではないため、多くの懐疑論者の懸念を和らげるのに役立ちます。開発者の観点から覚えておいてください。これが長期的に使用する予定のプロジェクトである場合、これは完全なプロジェクトの基礎を築くのに役立ち、将来の時間を節約するチャンスです。

ほとんどの人は、始める前から過剰に設計しすぎています。メルセデスベンツにアップグレードする前にフォードを作りましょう。

私たちがやろうとしていることを強調するために使った概念の 1 つは、「A 地点から B 地点まで行くのにメルセデスベンツは必要ありません。そこにたどり着くだけでいいのです。だからフォードを開発しましょう。そして、路上に出たら、車に望むアップグレードに集中できます。」というものでした。これは便利な概念でした。なぜなら、ほとんどの人は完成した製品を望んでいるからです。彼らは、着手する前から過剰設計したがります。小規模から始めることで、開発者は「ピント」という、目的を達成できる最小限の実行可能な製品を開発できます。次に、車両を「キャデラック」という、機能と機能性を高めた本格的な製品にアップグレードできるスピードを示します。これにより、ユーザーはピントに乗り、フィードバックを提供できます。その後、新機能の開発がいかに簡単であるかをユーザーに示すことができます。

プロジェクト作業への移行

概念実証がすべてうまくいき、プロジェクト全体の承認が得られた場合は、移行をスムーズにするためにプロジェクトに組み込むことができるいくつかの項目を検討できます。

ビジネスアナリストと品質保証の観点から、理解のプロセスをさらに促進するために活用できるものがいくつかあります。私たちは、最初は「アミーゴスセッション」が非常に役立つことを発見しました。アミーゴスセッションでは、開発者、アナリスト、テスターが即席のミーティングを開き、特定のスプリントに割り当てられたカードを確認します。これにより、参加者全員が各カードで開発されている内容について共通の認識を持つことができ、作業に関する具体的な質問をする機会が得られます。これらのミーティングは非公式なもので、開発前にアドホック形式で実施する必要があります。開発が完了したら、完成したコーディングを確認するために別のアミーゴスセッションを開催します。これにより、全員が完了した作業をレビューできます。同時に、開発者は変更が必要な項目にどれだけ迅速に対応できるかを示す機会が得られます。たとえば、アナリストが最終的なアミーゴスレビューで見落とされた要件を指摘します。これにより、開発者は変更をその場で行い、修正されたコードを画面に表示して、コードベースの適応性と変更要求への迅速な応答時間をチームメンバーに証明できます。これは、プラットフォームで何ができるかを他の人に理解してもらうのに大いに役立ちます。この目的は、これを永久に続けることではありません。最初は、全員が新しいプロセスに慣れるまで、アミーゴスレビューを実施する必要があります。その時点では、ストーリーカード開発の最後にのみこの手法を活用すればよいことになります。

品質保証の観点から見ると、アジャイルの主な利点はテスト駆動開発です。

品質保証の観点から見ると、アジャイルの主な利点はテスト駆動開発（TDD）です。TDDはITコミュニティでよく使われるプロセスです。ユニットテストモジュールで利用可能 Mendix App Store では、開発者は各開発スプリントに結び付けられた複数のユニットテストを作成できます。ユニットテストモジュールでは、各デプロイでレポートを実行して、ユニットテストが成功したか失敗したかを表示することもできます (開発者として、新しい欠陥を作成しなかったことを確認するのに役立ちます)。これにより、QA チームはコードが安定していること、以前にテストしたコードがまだ機能していることを確認できます。もちろん、彼らは独自のテストを行いたいと思うでしょう。しかし、この方法により、完了したスプリントごとにコードベースが劣化していないことがある程度わかります。これは、プロジェクトの最後に 1 回テストするのではなく、反復スケジュールでテストするため重要です。テストの努力が無駄ではなかったことを彼らに知らせるためにできることは何でも、長期的には大きな勝利です。

開発者の観点から見ると、コードレビューはプロジェクトの成功に不可欠であることがわかりました。その理由は単純です。コードをレビューする人の数が増えるほど、ミスの可能性が低くなるからです。また、これは開発者向けのコーディング標準とプロセスの実装にも役立ち、チームのすべてのメンバーが活用できます。コーディングを効率化するために他の人が行ったことを知ることができれば、市場投入までの時間を短縮できます。また、アジャイルへの適応が遅い人にも大いに役立ちます。なぜでしょうか。彼らは、チームが堅牢なコードを作成できるようにできる限りのことをしていることを知っているため、システムで見つかる欠陥の数を減らすのに役立ちます。発生する欠陥が少なければ少ないほど、チームはこの新しいアジャイルアプローチを高く評価するでしょう。

管理についてはどうですか?

経営陣はチームの開発の細部に関心がなく、関心を持つべきでもありません。彼らが関心を持つのは、リソース、スピード、品質です。では、私たちが簡単にメンテナンスできる優れたシステムを開発していることを示す具体的な方法をどのように提供できるでしょうか。 Mendix 品質およびセキュリティ管理ツール。

コードベースに変更を加える前に、システムのメトリクスを提供できました。これにより、実装したいアイデアが AQM スコアを上げて価値をもたらしたことを簡単に示すことができました。

AQM は、リポジトリ内のコミットされたコードをスキャンして 1 から 5 のスケールで評価を決定することにより、McCabe 複雑度を活用します。McCabe 複雑度測定に馴染みのない方のために説明すると、これはプログラムの複雑度を示すために使用されるソフトウェアメトリックです。AQM ツールは、コードベースを XNUMX つの異なるカテゴリに分類します。これらのカテゴリは、開発の観点からも非常に役立ちます。これにより、チームが過度に複雑ではなく、簡単に保守できるアイテムを作成していることを確認できます。これは、新しい開発者をオンボーディングするときにも役立ちます。これにより、チームは開発者の理解レベルを確認でき、コーディングが間違っている可能性のある場所を簡単に指摘できます。これにより、組織の標準に基づいてマイクロフローを適切に構造化する方法を教えることができます。

では、経営陣はどうでしょうか。経営陣は、会議で使用するために、読みやすいグラフを提供する、短く簡潔で要点を押さえたレポートを好むことは周知の事実です。AQM ツールには、開発中のコードに関する洞察を提供するレポートオプションがいくつか用意されています。これは、私たちの組織で非常に役立っています。コードベースに変更を加える前に、システムのメトリックを提供できました。これにより、実装したいアイデアが AQM スコアを上げることで価値をもたらしたことを簡単に示すことができました。このアプローチにより、経営陣に前後のメトリックを示すことで、最も違反が多かったマイクロフローの一部を削除することもできました。

AQM を使用すると、チームが過度に複雑ではなく、簡単に保守できるアイテムを作成していることを確認できます。

また、管理チームにユーザーログインを設定して、管理チームがこれらの指標にアクセスし、組織全体のディスカッションでそれらを使用できるようにすることもできます。覚えておいてください: 人々に安心感を与えるほど、賛同を得やすくなります。

前進

これは、組織の文化を変えるために私が提供した高レベルのアプローチです。最初から最後まで順調に進むわけではないことに注意してください。プロセス全体を通して、浮き沈みが多くあります。最後には価値があるということを覚えておいてください。これらの項目を使用すると、誰もが新しいプロセスを理解し、慣れることができます。プロセスを繰り返す際の一貫性は、人々にとって大きな効果があります。各スプリントからチームにリリースする内容が多ければ多いほど、彼らは自分の労働の成果をより多く目にするでしょう。これらの手順は、アジャイルアプローチが大きな成功を収めることができることを開発チームが理解するのに大いに役立ちました。