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

モード2チーム内でアジャイルを適用しない方法

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

Roald Kruit
2016年4月19日

 

 「変化することが基準であり、変化のコストを削減する必要があるため、アジャイルは小説の未知の空間を探索するのにとても合理的な手法です。」 – Simon Wardley

 

新しい収益源を生み出すデジタル製品のアイデアや、会社をもっと差別化して顧客に対していっそう魅力的に映る方法を考えてみましょう。

こうした新しい未知の領域を表すためアイデアを価値の高いアプリケーションに変えるためには、頻繁な反復と開発者とビジネスの緊密な連携が必要です。

そのため、Scrumのようなアジャイル手法は、新しいアイデアを迅速に開発、テスト、改良するために必要な短いフィードバックサイクルを促進することから、デジタルトランスフォーメーションの重要な要素と言えます。

新しいアイデアを迅速に開発、テスト、改良するために必要な短いフィードバックサイクルを促進します。

そして、Simon Wardley氏が指摘しているように、絶え間のない変化に対処するための仕組みを提供します。

しかし、私たちが組織の「アジャイルを導入する」のを手伝った時に学んだように、モード2の組織では実際には機能しないのに一般的に言われているScrumの原則がたくさんあります。

この記事では、Mendixチーム内でScrumを適切に適用するために、いくつかの一般的な落とし穴とその回避策を共有します。

 

開発チームをビジネス側から守らないでください

これまで、スクラムマスターの役割は、開発チームを外部からの邪魔や干渉から保護することでした。

フィードバックは他の優先事項と競合する可能性があるため、スクラムマスターはビジネスからのインプットを収集し、処理し、優先順位を付けるための中心的な接点となります。

実は、 デジタルイノベーションビジネスとITの緊密な連携が必要です。

開発者がビジネス関係者と直接対話できるようにすることで、フィードバックサイクルを短縮し、反復を迅速に行うことができます。

お客様のサイトでは、開発者がビジネスユーザーとオンサイトで作業し、フィードバックに基づいてすぐに変更を行うことが一般的です。

もちろん、1:1の設定で対処できない競合や優先順位について議論するためには、毎週のミーティングが必要です。

 

技術的な責任者を組織化しないでください

ほとんどの伝統的なスクラムチームは、データベース、統合、セキュリティ、UIなど、特定の技術分野ごとに責任者が配置されています。

モード2の組織では、Mendixのようなプラットフォームを使用しています。

このチーム編成は、二つの基本的な問題につながります。

・ひとつは、開発者が汎用技術コンポーネント(セキュリティフレームワークなど)と付加価値の高いビジネス機能にかなり多くの時間を投入し、そこに集中することです。

・もうひとつは、Mendixプラットフォームは大量の重労働(データベース作成など)の大部分を自動化するため、専門家はプロジェクトに参加中の長期間に渡ってアイドル状態になることです。

その代わりに(Mendixのおかげで) より小さいチーム2〜3人のビジネスエンジニアが仕事の80〜90%を自ら行うことができます。

その後、必要に応じて、統合やパフォーマンスチューニングなどの特定の技術的問題について、一時的にエキスパートを呼び出すことができます。

さらに、プロジェクトの作業は、エンドユーザーの日常的な言語で書かれた特定の機能を指すスクラム用語であるユーザーストーリーに基づいて分割する必要があります。

これにより、依存関係や知識移転の必要性が制限されます。

また、開発者が各スプリントの機能を完全に構築できるようにすることで、ビジネス価値の提供とタスクの完了に集中できます。

 

各スプリントのデモの重要性を見逃さないでください

システム設計は非常に抽象的なエクササイズになることができます。

2人の人が文字通り何時間も同じ部屋に座って、実際にはまったく別のページにいるときに同じことを話していると思います。

だからこそ、各スプリントレビューミーティングで良いデモを見せることが重要です。

デモは既存のビジネス要件を検証し、新しいニーズを明らかにするのに役立ちます。

このプロセスは、デジタルイノベーションプロジェクトの初期段階で特に重要です。

要件を検証するのを待つ時間が長くなればなるほど、コースを修正するために必要な時間と労力が増えます。

デモでは、デモの機能が他の方法よりも少なくて済むようにしてください。

デモのヒントやトリックについては、以前の記事を参照してください。

 

すべての時間を新しい機能に割り当てないでください

できるだけタイムラインを維持するために、スクラムチームはスプリントの計画とマイルストーンを新機能に集中し、ユーザーのフィードバックを処理する余地はほとんどありません。

これは、迅速な反復を容易にするためであり、本来の目的からはずれます。

既存の機能に関するフィードバックを処理するためにスプリントの20〜30%を割り当てることを推奨します。

アプリケーションのリファクタリングに10〜20%を費やして、長期的なメンテナンス性を向上させる必要があります。

もちろん、新しい機能に重点を置いているプロジェクトでは、その割合が以前よりも低くなりますが、一般的な経験則として役立つはずです。

これらのガイドラインを監視して遵守するには、次の4つのバケツを使用してユーザーストーリーにラベルを付けることを検討してください。

  • 新しい機能 – 新しい機能を構築する場所
  • 既存の機能強化 – ユーザーのフィードバックを処理する場所
  • リファクタリング – メンテナンス性を向上させる場所
  • 予想外のもの – インシデントやその他の外部依存関係が計画できず、チームを目標から逸らす

 

厳密に2〜4週間のスプリントルールに従わないでください

スクラムは通常、2〜4週間のスプリントを必要とします。

しかし、Mendixは従来のアプローチに比べて生産性の点で大きなメリットがあるため、これを半分に減らすことをお勧めします。

開発者が前もって仮定したことを、4週間後には実際にアプリケーションのデモをして見せることができます。

プロジェクトの開始時には毎週スプリントを開催して、ビジネス要件の迅速な発見と洗練を促進します。

その後、アプリケーションが形を整え始めると、2週間のスプリントに移ってください。

 

デジタルイノベーションに必要な迅速な反復を容易にするアジャイル

Scrumのようなアジャイル手法は、デジタルトランスフォーメーションにとって非常に重要です。

最初は革新的なアプリケーションの要件が不明または不明瞭なため、開発者は短期間、反復的なサイクルで作業し、機能を構築し、リリースし、ユーザーのフィードバックに基づいて継続的に反復する必要があります。

上記の落とし穴を避けてScrumを実施すると、Mendixのような高速アプリケーション開発プラットフォームの生産性と俊敏性を最大限に引き出すことができます。

 

翻訳元:https://www.mendix.com/blog/not-apply-agile-within-mode-2-team/

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

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

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

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