0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

アジャイル開発実践:変化する製品開発プロセスを受け入れる

Posted at

 アジャイル開発の流行に伴い、ソフトウェア製品やアプリケーションの開発にアジャイル開発を採用する会社が増えてきている。
 筆者の製品開発チームは2年前からアジャイル開発方法を採用し、現在まで実践しており、製品機能がより市場や業務者のニーズに適合し、開発効率が向上していることを含めて良い成果を得ている。
 本文は実践の角度から筆者のチームの製品のアジャイル開発過程とアジャイル開発の体得を紹介した。
##一、アジャイル開発体験##
アジャイル開発を実施してここ2年、私は製品開発にアジャイルな方法を応用することを深く体験してきた。まず製品の背景について話します。
私が参加した製品は業界向けの製品で、全世界に顧客がいて、10年の歴史があり、100以上の異なるバージョンに基づく顧客がいて、私たちのチームは製品の未来の発展方向、発表計画、構造、設計、開発進捗、テスト、顧客支援などを完全に担当しています。
このようなグローバルな製品と自主的なチーム環境の中でのアジャイルな開発は特に深い。
####1.概念とアーキテクチャ設計を重視し,軽量詳細設計####
アジャイル開発では、概念やアーキテクチャ設計を重視し、軽量詳細設計である。
ここでの概念設計は、なぜこの製品やモジュールを作るのかと見なすことができ、製品の経路計画、市場傾向、顧客価値、技術傾向などを強調している。
アーキテクチャ設計は,全体的に見て,概念設計をどのように実現すべきか,いくつかの階層に分け、いくつかのコンポーネント、異なる階層とコンポーネントとの関係が何であるかと見なすことができる。詳細設計は、具体的な設計や仕様、APIインタフェースなどである。
1つの製品、特に業界向け製品は、概念設計やアーキテクチャ設計が非常に重要であり、業界の将来の発展方向、製品の市場における横方向と縦方向の比較、技術の発展方向、各モジュールの投入と収益の割合などを考慮する必要があり、製品が正しい方向に進むことを可能な限り保証することができる。
製品にモジュールを追加または削除するには非常に慎重である必要があり、新規モジュールがクライアントに使用されると、その後製品からこのモジュールを除去することは困難であるからである。
製品の各バージョン間の互換性や、クライアントのアップグレード移行も考慮する必要がある。したがって、本格的な開発を開始する前に、概念設計やアーキテクチャ設計により、考え方を整理する必要がある。
####2.SWOT分析####
従来、プロジェクトを行う際には、どの機能モジュールが必要である、どの機能モジュールが先にやるかを技術的に考慮することが多く、体系的な分析手法はなかった。
その結果、いくつかの機能モジュールが多くの資源を投入しているが、必ずしもクライアントが最も望んでいるとは限らない。
アジャイル開発では、顧客ニーズをより重視している。
製品に対してSWOT分析を行えば、最小の作業量を払うが、最大の価値を得ることができるモジュールを選択することができる。
SWOT解析段階は概念設計とアーキテクチャ設計の後に行われ,入力は概念設計とアーキテクチャ設計、出力はモジュールの重要度と所要時間である。
このようにコストパフォーマンスで順位付けを行うことができ、市場に最も適合するモジュールを選択することができる。
图片1.jpg
1つの製品がどのモジュールが重要で、どれが先にやるか、どのくらいの資源と時間をかけて投入するか、こんなに多くの時間と資源をかけたモジュールが顧客の心の中に相応の重要度があるかどうかなどは、この製品の市場戦略によって決定される。
すべての製品は市場と利益のために目的であり、アジャイル方法は企業がこれを実現するのをよりよく助ける。
####3.技術によって駆動されるのではなく業務や顧客によって駆動されています####
この点は体得といってもよいし、教訓ともいえる。
私たちの製品開発過程で、ある新しいバージョンで古いバージョンのある重要なモジュールを再設計し、いくつかの問題を引き起こしました。

1つは、新しいバージョンのモジュールと古いバージョンのモジュールの互換性の問題で、古いバージョンのクライアントが新しいバージョンに滑らかに移行できない。
2つは、新しいバージョンの改善は、顧客にとっても、内部のアーキテクチャにとっても、明らかな利益がない純粋な技術的再実現である。
その結果、我々は多くの資源や人的資源をかけて再実現したが、最後には様々な考慮により再実現されたモジュールを破棄し、依然として古いモジュールを使用している。
####4.いつでもバージョンの互換性を考慮する####
アジャイル開発は、冗長な文書や煩雑な設計を捨て、変化に迎合することを強調している。しかし製品としては、アジャイル開発は盲目的に変化することを意味しない。
設計変更、APIインタフェース再構成、プロファイル変更の際には、製品のアーキテクチャ、計画路線図、古いバージョンの互換性、および移行平滑性をつねに考慮する必要がある。そうでなければ、バージョンが多くなるにつれて、多くの維持作業に直面するだろう。
####5. 軽量化された文書ですが無文書ではありません####
アジャイル開発はコミュニケーションの重要性を強調し、冗長文書を軽い。
しかしアジャイル開発は文書なしを意味するわけではありません。
アジャイル開発において、適量の文書はやはり有用であり、考え方を整理し、コミュニケーションや議論を加速させるのに役立つ。
我々の製品中の文書には、__概念設計文書、アーキテクチャ、現在のバージョンで実現する機能リスト、SWOT分析__がある。
これらの文書は各製品バージョンが開始される前に生成され、各繰返しの過程で業務者や市場からのフィードバックによっても若干変更される。
私たちの実践を通じて、これは製品の構想、コミュニケーション討論に非常に役立つことを証明した。
また、これらの文書は、数ページのPPTが多く、書き込みや保守作業量が小さい。
##二、アジャイル開発過程##
アジャイル開発は製品の開発プロセスを改善し、チーム全体の効率を高めた。
次に、アジャイル開発前とアジャイル開発後の製品開発の各段階を分析する。
####1.アジャイル開発“前”の製品開発過程####

敏捷开发前.png
上の図はアジャイル開発前の我々の製品1バージョンの開発フローであり、開発全体が約1年程度続いている。上の図から、プロセス中の多くのアクティビティは逐次的に行われていることが分かる。このような滝のような開発プロセスは、需要が製品の初期段階で完全に捕獲され正確に分析されることを前提としており、最後に納入された製品が顧客が必要とする製品であることが保証されるが、通常このような理想的な状況では実現は困難である。
####2.アジャイル開発“後”の製品開発過程####
敏捷开发_后_的产品开发过程.png
上の図はアジャイル開発“後”我々の製品1バージョンの開発フローであり、開発全体も約1年程度続いているが、いずれの繰返しも1カ月である。
アジャイル開発前と比較して多くの違いや利点があり、次のような点があります。

市場と需要に牽引され、変化を受け入れる
当社の製品アジャイル開発では、各反復の終わりに、今月の開発結果をチームメンバー、ビジネス担当者、プリセールス、さらには顧客にデモンストレーションし、フィードバックを収集するための製品反復デモンストレーション会議が開催されます。さらに、開発プロセス中、製品のビジネス担当者とプリセールスは常にコミュニケーションを維持し、製品開発チームと協力して、開発された製品がビジネスニーズを満たすようにします。

リソースと時間を最大限に活用する
アジャイル開発の前は、製品要件の設計フェーズが開発プロセス全体の約35%を占めていました。この間、必要なコアアーキテクトとデザイナーはわずかであり、開発者とテスターを十分に活用できませんでした。アジャイル開発、反復開発、コミュニケーションの重視、およびドキュメントの削減の後、効率を最大化するために、各反復の開始時に開発とテスターの時間を最大限に活用できます。

毎日配達
製品開発プロセスでは、自動ビルドが毎日実行され、成果物が生成されます。ビジネス担当者と顧客はそれを試して、フィードバックと新しい要件を提供できます。

十分に自動化
アジャイル開発は変化を受け入れることを強調し、それは必然的に製品コードの混乱につながるでしょう。すべての新しい機能と変更された機能は、他の機能に影響を及ぼし、副作用を引き起こす可能性があります。したがって、変更をサポートし、変更中の品質と開発速度を確保するには、コンパイルの自動化、ユニットテストの自動化、機能テストの自動化、UIテストの自動化、統合テストの自動化などの自動化が必要です。
##三、アーキテクトとスクラムマスターの重要性##
プロセスの変化は必ず職場と職責の変化をもたらし、アーキテクチャ師とスクラムマスターは敏捷開発における2つの重要な人物の役割である。
####1.製品構造師####
製品のアジャイル開発、特に私が参加している製品が業界志向の製品である場合、アーキテクトは極めて重要な役割であり、深い業界のバックグラウンド、イノベーション能力、およびアーキテクチャ能力を必要とします。
あるクラスの顧客のニーズを解決するための製品が存在します。しかし、顧客のニーズは事業の発展とともに変化することが多く、競合他社も同様の製品を発売します。したがって、製品が市場に投入された後、その機能モジュールは徐々に成熟し、競争相手はますます増え、徐々に競争力を失います。優れた製品、特に業界志向の製品が長期的な活力を持つためには、次の図に示すような製品モデルが必要です。
未命名文件.png
成熟したモジュール:市場に投入されてからの期間を指します。これらの機能モジュールは、顧客のニーズを満たすために広く使用されています。市場が安定するにつれ、多くの競合他社の製品が同様の機能を開始しました。これらの成熟したモジュールは製品の基本モジュールであり、製品の競争力を表すものではありません。製品にこれらの機能モジュールしかない場合、激しい需要と競争で徐々に消滅します。 1990年代のBPマシンのように、携帯電話が発売されると、この製品は死んでしまいます。
開発中のモジュール:市場に投入されたばかりで、市場の活力が強く、過去数年間の顧客のビジネス開発ニーズを満たし、主要な顧客に受け入れられている機能モジュールを指します。これらの機能モジュールは、製品が市場を占めるための原動力であり、成熟した機能モジュールに続く製品の新しい成長の原動力です。
研究中の次世代製品の方向性:これは、まだ市場に投入されておらず、研究中であり、今後5年から10年の業界の開発方向性に沿ったモジュールを指します。もちろん、将来の開発の方向性を作ることができれば、それは最高の状態です。ニンテンドーのWii、アップルのiPhoneなど。

業界のソフトウェア製品が長期的な活力を維持するには、これら3つのモジュールと機能を製品ライフサイクルアーキテクチャ全体の計画で考慮する必要があります。この方法でのみ、製品の高度な性質と長期的な活力を維持できます。
アジャイル開発はまた、市場の変化を受け入れることを強調します。これは、製品アーキテクトに高い要求を課します-深いビジネス背景、革新能力、技術的洞察、およびアーキテクチャのアイデア。
####2.スクラムマスター####
スクラムマスターはアジャイル開発の新しい用語ですが、その作業内容は開発チームリーダーの作業内容と大差ありません。タスクの調整、リソースの調整、進行状況の制御、問題の解決です。
アーキテクトは、業界の理解と革新に基づいて製品アーキテクチャを設計します。スクラムマスターは、このアーキテクチャの各コンポーネントをさらに分解して実装します。 「オリンピック開会式」が製品として説明されている場合、建築家は開会式全体のテーマ、創造性、建築、主要なリンクを設計し、スクラムマスターは巨大なプロジェクト全体の詳細な設計者およびコーディネーターです。
当社の製品には3つのスクラムマスターがあり、それぞれがアーキテクチャ内のさまざまなモジュールを担当し、開発者と協力してモジュールを個別の測定可能なユースケースに分解し、開発者を調整して高品質のタスクを完了します。
さらに、チームメンバーは毎朝約10分間スクラムミーティングを主催する必要があります。各チームメンバーは、昨日完了したタスク、タスクを完了したかどうか、発生した問題、そして最後に今日完了する予定のタスクについて報告します。スクラムマスターは、製品の進歩と品質を確保するために、毎日発生する問題を解決するために調整します。
##四、まとめ##
著者の理解では、アジャイル開発は考え方とソフトウェアプロセスの方法論、および一連のベストプラクティスであり、チームが市場のニーズにより一致する製品を開発するのに役立ちます。 2つのバージョンの製品のアジャイル開発プロセスの間、私たちのチームは常に彼らに適した製品アジャイル開発プロセスを調査し、見つけました。私たちはアジャイル開発プロセスを改善するためにアジャイルアイデアを引き続き使用します。私たちはあなたと話し合い、調査したいと思っています。改善し続けます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?