これは素晴らしい ITとビジネスのコラボレーション アジャイル開発手法を用いて、部門はすぐにアプリを使い始め、最初の1,000週間でXNUMX件以上の作業ログが記録されたため、パイロットは大成功を収めました。このプロジェクトはすぐに、機能の幅と深さを拡大したいという企業にとってのプロジェクトへと発展しました。何よりも素晴らしいのは、基本的なシステム機能がわずかXNUMX週間で、わずかXNUMX人のスタッフによって実現されたことです。 Mendix エンジニア！

では、どうやってそれを実現したのでしょうか？LV=では、アジャイル環境で作業してきました。 Mendix 約2年になります。プロジェクトごとに、私たちはプロセスを「純粋なアジャイル」アプローチに近づけることで改善してきました。アジャイル開発アプローチを洗練させた結果、 Mendix、私たちは今、 6週間以内に新しい保険商品やサービスを発売する.

出席しました Mendix 2014年ワールドカップに出場し、 24時間ハッカソン慈善団体Terre des Hommesのために、チームと共に昼夜を問わず、完全に機能するアプリをリリースしました。これは素晴らしい学習体験であり、24時間でどれだけの成果を達成できるかについて大きな自信を与えてくれました。 Mendix.

このパイロットが 5 月に登場したとき、それは、これまでの経験から学んだすべての教訓とハッカソンのスリルとスピードを組み合わせて、非常に短い期間で本番環境に適したものを提供する絶好の機会でした。

1 回のスプリントで本番環境対応アプリを配信するための前提条件

プロジェクトを開始する際には、最終的にお客様が実際に使用できるものを提供できるよう、いくつかの前提条件を考慮することが重要です。以下は、成功につながる要素の一部です。

• アジャイル/スクラムと Mendix プロジェクト管理トレーニング: 当初、一部のプロジェクトでは、外部のトレーナーを招いて半日のアジャイル／スクラム研修を実施し、チーム内で言語、役割、責任について共通の理解を深めました。しかし、今回は小規模なパイロットプロジェクトであり、外部研修の予算がなかったため、アジャイル／スクラム研修は自社で行うことにしました。これにより、ビジネス部門に、私たちが採用するプロセスについて高いレベルで理解してもらい、スクラムの活用方法を理解してもらうことができました。 Mendix プロジェクト管理機能。これにより、チーム内で共通の理解と共通のコミュニケーション言語が確立され、ユーザーはユーザーストーリーを自らの責任として捉え、共通の目標に向かって取り組むことができます。プロジェクトの規模に関わらず、これは時間をかけるだけの価値があります。
• ワークショップ： パイロットスプリントを開始する前に半日のワークショップを開催し、プロジェクト全体と達成を目指すビジネス目標を理解することは必須ではありませんが、強くお勧めします。このミーティングにはプロジェクトスポンサーとプロダクトオーナーも参加し、最後にはパイロットスプリントで提供するもの（そして提供しないもの）について合意する必要があります。これは、パイロット終了時に彼らが何を期待しているか、そしてそれを本格的なプロジェクトへと発展させるための成功基準を把握するためのものです。
• 共存: LV=のパイロットプロジェクトでは、サイモン・ブラックと私は、その事業拠点であるオフィスを訪れました。プロジェクトの概要情報を入手し、パイロットのスプリント目標とプロダクトオーナーを決定し、「なぜ」という問いかけを通して、適切な成果を確実に実現できるようにしました。私たちはまず、既存のプロセスを見直し、「なぜこれをやっているのか？本当にこれをやる必要があるのか​​？何を改善できるのか？」と問いかけました。目標は、既存のプロセスを単に再現することではなく、改善することでした。なぜなら、 Mendix は迅速なアプリ開発プラットフォームであるため、製品を視覚的に理解できるフォームをいくつか構築することができました。
• 事前構築された開発コンポーネント – 何かを素早く調理したいなら、事前にすべての材料を準備しておく必要があります。私たちは、あらゆる新しいプロジェクトに必要なコアコンポーネントを1つにまとめることで、まさにそれを実現しました。 「スターターキット」モジュール それを当社のプライベート アプリ ストアで公開しました。(このモジュールにより、プロジェクトの必須コンポーネントの構築にかかる貴重な時間が節約され、ビジネス要件に集中できるようになります。

• 運用準備 – これは、チームが作業を開始する前に尋ねる必要のある最も重要な質問の 1 つですが、見落とされがちな質問の 1 つです。 Mendix 開発は予想以上に速いペースで進むことが多く、開発サイクルが予定よりも短くなることがあります。そのため、ビジネスが完成する前にソフトウェアが完成してしまうこともあります。過去には、運用側の準備が整っていなかったため、プロジェクトを一時停止せざるを得なかったこともありました。

プロジェクトを開始する前にビジネス部門に必ず尋ねるべき質問が 1 つあります。「このスプリントの終了までにスプリントの目標を達成できた場合、それを使用するのを妨げるものは何ですか?」というものです。その答えは、テスト リソースがない、トレーニングの時間がない、上級管理職の支援がないなど、さまざまな理由が考えられます。通常、私たちはチーム内で解決策を見つけます。たとえば、ブローカー ワークフロー アプリの場合、ビジネス部門がスプリント サイクル中のテストとトレーニングの責任を負い、私たちはドキュメント作成の責任を負いました。ビジネス部門はアジャイル/スクラム手法に非常にうまく適応し、仕事用のデスクトップに Chrome がインストールされていないこと (特定のドラッグ アンド ドロップ機能に必要) から、作業を追跡するために必要な日次レポートまで、ライブ化を妨げる可能性のある事項について教えてくれました。このフィードバックは、ユーザー ストーリーの優先順位付けに役立ち、スプリントの終了までにライブ化できるように、何が何でもそれらの事項を最初に提供できるようにしました。

このシリーズの第2部ではパイロットスプリント中に留意すべき重要な考慮事項を概説します。繰り返しになりますが、パイロットを成功させ、本格的なアプリデリバリープロジェクトへと発展させることを目標としています。今後の展開にご期待ください。その間、ぜひ下のコメント欄で皆様の体験を共有してください。