2017.07.12Mendixで課題解決 , アジャイル

あなたの会社の文化をウォーターフォールからアジャイルに変える

  • このエントリーをはてなブックマークに追加


Russell Martin
2017年3月30日

私の名前はRuss Martinです。

Erie InsuranceのシニアソフトウェアエンジニアとしてMendixを約3年間使ってきました。

Mendixプラットフォームを使用していくつかのプロジェクトを完成させ、成功を収めました。

ウォータフォールからアジャイルプロジェクトの方法論に焦点を当てようとする際に遭遇した試練と苦難、およびそれを克服する方法のヒントと共有したいと思います。

 

ウォータフォール チームにアジャイルを導入する

最初にアジャイルのコンセプトを紹介すると、これまでウォータフォールに親しんできた開発チームのメンバーは、ためらい、不安になるだろうと想像します。

多くの人にとって変化することは難しく、まして全く異なるものに移行するときには特にそう感じてしまうと思います。

ウォータフォールを採用している組織のほとんどは、一般的には、開発を開始する前にプロジェクト全体を設計し、レイアウトします。

ウォーターフォールに精通している人は、チームが実装の作業を開始する前に何ヶ月もの要件の収集と設計の為の会議が必要であると思うでしょう。

この中で、会議の参加メンバーだけでなく他の開発メンバーへ細かく情報の伝達を行うため、各分野の担当者間では情報の分断が起こります。

こうした状況を調整したり、情報共有するプロセスにより、かなりのオーバーヘッドと多くの時間がかかってしまいます。

アジャイルの開発プロセスはウォータフォールと全く違う、180度反対のものです。

これまでに経験してきた考え方に逆らって180度反対のものを導入しようとすると、人々は不安になることでしょう。

 

まずは、小さな概念実証に取り組むことから始めましょう。

アプリケーションの一部、またはリプレイスにかなりの時間がかかることが予想されるもののうち、数週間以内に完成できるものをピックアップします。

そして、ビジネスアナリスト、ソフトウェアエンジニア、品質保証など、さまざまな分野の担当者を少なくとも1人はチームに参加させてください。

その理由は、この変化を広げる際に、異なる視点を持ち影響力のある専門家の人々が必要だからです。

新しい方法論を理解した人々が数人に広がっていけば、開発チームのメンバーに理解してもらうこともずっと簡単になります。

もうひとつコツがあります。Mendixチームの専門知識を上手に活用してください。

このチームは、このように文化変えることに慣れています。

外部のチームとのやり取りによって、変化をスムーズに進めるためのノウハウを得ることができます。

この概念実証の鍵はチームワークです!

 

さて、始めましょう。ここから確かに険しい戦いに直面します。

まず、チームメンバーはスプリントゼロに参加する必要があります。

スプリントゼロとは、ユーザーインターフェースで何を見たいかを決めるために、いくつかのストーリーをまとめたものです。

チームのすべてのメンバーを関与させることによって、ストーリーに対して意見を聞きます。

その過程ではチームメンバーから様々な声を聞くことになるでしょう。

これまでのドキュメンテーションという重いプロセスから、「ストーリー」のアプローチへの移行は、ウォータフォールの方法論を実施している多くの人にとってはまったく異なる概念です。

チームメンバーからのプッシュバックに備えるのは、今後も継続するからです。

この概念実証が、実験であり変化への訓練のためのものであることを忘れないでください。

それは本格的なプロジェクトの開発のスタートではなく、多くの疑問を払しょくすることに役立ちます。

開発者の観点から見ると、これが長期に計画する予定のプロジェクトであれば、スプリントゼロはプロジェクトの基礎を築き、将来の時間を節約するのに役立ちます。

ほとんどの人は標準化する前に設計しすぎています。レーシングカーにアップグレードする前に軽自動車を開発しましょう。

アジャイルの概念を表すものの2つとして次の表現があります。

「レーシングカーでポイントAからポイントBに向かう必要はありません。そこに着くだけです。だから軽自動車を開発しましょう。一旦軽自動車で走ってみてから、普通乗用車へのアップグレードに焦点を当てることができます。」

これは分かりやすいコンセプトです。

私たちは始める前に過度に設計したいと考えてしまいます。

小規模から始めることで、まず開発者は実行可能な最小の製品である ”軽自動車”を開発することができます。

その後、機能を増強した本格的な製品”普通乗用車”にいかに迅速にアップグレードできるかを示してください。

これにより、ユーザーはまず”軽自動車”に乗り、フィードバックを提供し、その後、新機能を開発することが簡単であることを理解します。

 

プロジェクトで実践

概念実証がうまくいって、プロジェクト全体が青信号で前進ということになったら、プロジェクトに組み込むべき項目をいくつか取り上げて、スムーズにアジャイルへの移行を進めていきましょう。

こんどは、ビジネスアナリストと品質保証の観点から、アジャイルへの理解をさらに深めるための進め方・考え方の例をあげてみます。

まず初めに、「アミーゴセッション」という方法があります。

アミーゴ セッションは、開発者、アナリスト、テスターがある開発テーマ(スプリント)を確認する時に、割り当てられたカードを使ってすぐに不明点を指摘するというスタイルで行われる会議です。

この会議では、参加者全員が開発された画面を見ながら、カードを使って質問をします。

これらの会議は非公式に、臨機応変に必要なタイミングで行うほうがいいでしょう。

スプリントが完了したら完成した部分をアミーゴセッションによって確認します。

アミーゴセッションでは、完了した時点ですべての人の作業を見直すことができ、さらに開発者は変更要件にどれだけ迅速に対応できるのかを示すことができます。

例えば、アナリストは、最後のアミーゴレビューで修正点を指摘します。

それに対して、開発者はその場で変更を行い、修正された画面を表示し、迅速に対応できることを参加者全員に向けて実証することができます。

このセッションは、参加メンバーが新しいアプリケーションでできることを理解するのにも役立ちます。

この会議はいつまでも続ける必要はありません。

関係者全員がこのセッションを活用した開発プロセスに慣れてきたと感じるまで続ければいいでしょう。

そうすれば、開発プロセスの最後にこのセッションを行うだけでいいのです。

 

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

TDDは、ITコミュニティ内で使用されるよく知られたプロセスです。

Mendix App Storeで入手可能なユニットテストモジュールで、開発者は各開発スプリントでいくつかの単体テストを作成することができます。

ユニットテストモジュールでは、デプロイごとにレポートを作成し、ユニットテストが合格したか失敗したかを示します(また、開発者が新しいバグを作成しなかったことを確認するのに役立ちます)。

これにより、QAチームは、コードが安定しており、以前にテストされたコードが動作し続けていることを確認することができます。

もちろん、彼らは自分自身でテストをしたいと思うでしょう。

しかし、この方法では、完成したスプリントごとにデグレをしていないことが分かります。

これは、プロジェクト終了時のみのテストに比べて反復スケジュールでテストされることが重要です。

テストで時間を浪費されないということは、長期的には大きな効果となります。

開発者の観点からは、プロジェクトの成功に不可欠なコードレビューが必要です。

理由は簡単です。

コードを見ている目が増えるほど、間違いの可能性は少なくなります。

これは、チームの全員が活用できる開発者向けのコーディング標準とプロセスの実装にも役立ちます。

チームが確実なコードを作成していることを確認し、システム内で見つかったバグの量を減らすのに役立ちます。

開発バグの数が少ないほど、チームはこの新しいアジャイルアプローチについてより良く感じるでしょう。

 

経営者に向けて

コードベース内で変更を加える前に、システムの基準を提供することができました。

このようにすることで、AQMスコアを上げて提供した価値を実現したいという考えを簡単に示すことができました。

経営陣はチーム開発には関心がなく、関心があってはいけません。

彼らは、リソース、スピード、および品質により多くの関心があります。

経営陣に素晴らしいシステムを開発し続けていることを簡単に示すためには、具体的には何をあげられますか

私はアプリケーション品質監視(AQM)ツールを使用することを推奨します。

AQMは、リポジトリ内のコミットされたコードをスキャンして、1~5の評価を決定することによって、McCabeの複雑さを活用します。

McCabeの複雑さの尺度に精通していない人に説明しますと、これはプログラムの複雑さを示すために使用されるソフトウェアメトリックです。

AQMツールは、コードベースを8つの異なるカテゴリに分類します。

これらのカテゴリは、開発の観点からも非常に役立ちます。

 

チームが簡単にメンテナンスできるアイテムを作っているのが分かります。

これは、新規開発者の作業を判定するときにも役立ちます。

チームは、開発者がどの程度の理解度を持っているかを知ることができ、コーディングが間違っている可能性がある箇所を簡単に指摘することができます。

これにより、組織の標準に基づいてマイクロフローを構成する適切な方法を教える機会が提供されます。

経営陣に向けてはどうですか?

経営陣は会議で、グラフなど読みやすく簡潔な、そしてポイント・ツー・ポイントのレポートを好みます。

AQMツールには、開発中のコードについての洞察を提供するいくつかのレポートオプションがあります。

これは組織にとって非常に有用であることが証明されています。

コードベース内で変更を加える前に、システムの評価を提供することができます。

AQMスコアを上げることによって、アイデアを簡単に開発していることを示すことができました。

このアプローチにより、経営陣に評価を提示することで、最も大きな障害となっていたマイクロフローの一部を削除することもありました。

AQMを使用すると、チームが簡単にメンテナンスできるアプリを作成していることがわかります。

また、管理者チームがユーザーログインを設定して、組織全体のディスカッション内でこれらの評価にアクセスして参照することもできます。

覚えておいてください:人々に提供する快適性が高いほど、導入が容易になります。

 

前へ進もう

アジャイルは、組織の文化を変えることを助ける、高度なアプローチです。

なので、全体的にスムーズに出航することはできないことに注意してください。

プロセス全体には多くの浮き沈みがあります。

最後に、アジャイルは価値があることを覚えておいてください。

これにより、誰もが新しいプロセスを理解し、快適になります。

このプロセスを繰り返すことは、人々と長い道のりを歩んでいるようなものです。

各スプリントのリリースをすることで、作業の成果を見る機会が増えていきます。

これらのステップで、アジャイルのアプローチが大成功を収めることを、開発チームは理解するでしょう。

翻訳元:https://www.mendix.com/blog/changing-your-companys-culture-from-waterfall-to-agile/

  • このエントリーをはてなブックマークに追加

このエントリーにコメントする

必須項目は全て入力してください。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)