無料ブログはココログ

« [#TiDD] ツール・技法の導入法 | トップページ | 対外発表する理由 #RxTstudy #seakansai »

[#TiDD] 複雑な並列作業における変更 - 受け入れ、協調、分離の定石 - #RxTstudy

チケット駆動開発に限らず、ツールや技法を導入する際に否定的な意見を聞く事があります。不勉強なだけなら説明するだけ良いですが、理解された上での発言の場合は、そもそも向いていないものを当てはめようとされている場合もあります。

その判断は簡単ではありません。問題を明確にした上で、定石をあてはめ、その善し悪しを検討し、その組織に会わせた実施するといった一連の手順が必要です。

定石とは組合せ可能なベストプラクティスではなく、アンチパターンにもなりうるツールや技法の典型的な方法と言う意味で使っています。プログラミングと同じように、様々な制約の中でバランス考慮してその採否や組合せを決めます。

ここでは、前回のRxTstudy/SEA関西で議論が時間切れになった大規模な並列作業における変更について考えてみます。複雑とは規模の大小ではなく、基盤ソフトウェアとアプリケーションなど、互いに依存する複数チームからなるという意味で使っています。

複数チームが並列に開発している中で仕様変更が会った場合、どのように対応できるか、変更の受け入れ、協調、分離の定石にあてはめてみます。

変更の受け入れ

まず、各チームがどのように変更の受け入れるかを考えます。変更の受け入れには、同期、バッファ、パイプラインの定石があります。

XPやスクラムでは、仕様変更の受け入れがイテレーション、あるいは、スプリントと呼ばれる繰り返し期間の区切りに同期されます。つまり、イテレーション中の仕様は凍結して実施され、次のイテレーションを開始する前にスコープが変更されます。

FDDやハイブリッドアジャイルでは、あらかじめ仕様変更に対するバッファがそれぞれ10%と20%用意され、開発中に変更に対応されます。バッファを超える変更はマネージメントが介在して、計画の見直しが行われます。

リーンかんばんでは各工程の作業がパイプラインで実施されます。 それまでの入力は仕様凍結されたまま、新しい仕様はパイプラインの入力になって順次実施されます。

仕様を凍結して同期させるとプロジェクトの混乱は押さえられますが、小規模な手戻りは避けられません。あらかじめバッファを用意して仕様変更を随時変更を入れる場合は、受け入れに限界があります。それぞれの想定を超える場合は、実行中の作業を含めて見直しが必要になります。

協調

規模が増大して複数のチームで並行開発する場合、仕様変更を正しく伝達・分担できるようにする必要があります。その定石は階層的協調と同期です。

リーン開発やスクラムオブスクラムでは階層的協調が行われます。リーン開発では日々のミーティングを同時間に行い、その後に階層的なミーティングを行います。スクラムオブスクラムではリーン開発と同じようにスクラムマスターが日々集まり、さらに多くの関係者を集めたステアリングコミッティが週次に行われます。

階層的管理では情報共有が重要で、必要に応じて文書の作成や対面の会議をします。こうして仕様変更が伝搬されますが、上に書いたようにそれぞれの方法で受け入れられ、実施、統合されます。

実施時にGitなどの分散バージョン管理ツールを利用していれば、効率よく修正パッチをそれぞれに適用できるかもしれません。Subversionのような集中バージョン管理ツールでも、修正パッチや共通ライブラリを作成すれば、作業が効率化できるでしょう。

統合する際はチーム間の同期を取る必要があります。固定的な繰り返し期間を持つXPやスクラムでは、電車の駅の待ち合わせの様にリリースのタイミングを合わせるアジャイルリリーストレインと呼ばれる方法がとられます。

リーンソフトウェア開発では、工程毎のチーム間にバッファがあり、作業の無駄なくで同期が取られ順次統合されます。

このような同期を取らない方法では、あらかじめ基盤部分のモックを用意するなど統合の戦略が別途必要になります。

統合はそれぞれの仕様が明確でないとうまくいきません。そこで、各チームの協調が重要になります。

分離

仕様変更による作業の変更は、体制に会わせてチケットを階層的に使い、依存関係を持たせるとうまくいくように思われます。しかし、当初の決定に認識違いがあった場合や、さらに変更があった場合には、複雑な依存関係をメンテナンスしないといけません。

これは完全型チケット駆動開発を目指す際に生じる難しさです。現状のプロジェクトはそのままに仕様変更プロジェクトとして補完するチケットを分離するとうまくいく場合があります。 仕様変更の分離は、抽象クラスの修正が難しい場合に、派生クラスを作成して影響を局所化する戦略に似ています。

補完チケット駆動開発に類似する定石としては、変更仕様書あるいは改造仕様書として仕様の差分だけを別プロジェクトにまとめる方法や、XDDPのような派生開発があります。

これらはマスターを直接修正するのではなく、差分を整理します。差分だけのプロジェクトで、差分だけを管理しますので、全体の管理よりは把握やレビューが容易になります。

差分で作られたものはマスターからの派生ですが、ドキュメントを整備してマスターにする事もありますし、差分を取り込んで新たに作られるものをマスターにするかもしれません。いずれマスターになるのであれば、マスターの関連する作業を中断し、マスターから削除すれば手戻りを少なくできるでしょう。

チケット駆動開発で、全体の管理を理論的に実現しようとしても、必ずしもうまくいくとは限りません。全体と部分の独立性を高め、階層ごとに管理することも検討してください。

チーム間で協調・同期するのは仕様・リリースであって、チケットではありません。むやみに依存関係をつかうと、完了しないことや、開始できないこともありますし、変更が難しくなります。 一方向の参照を利用して、クエリでレビューする方が変化に強くなります。

チケット駆動開発であっても、コミュニケーションは必要な時に必要なものを使いましょう。人と人をつなぐことが目的で、チケットをつなぐ事が目的ではないからです。

まとめ

変更の受け入れ、協調、分離の定石を説明しました。ソフトウェア開発においてプロセスの影響は大きく、プロジェクトの混乱を押さえる事も、混乱を増大する事も可能です。

ツールや技法と同じように、問題を明確にした上で、定石をあてはめ、その善し悪しを検討し、その組織に会わせた実施するといった一連の手順によって、大きな効果を得られるでしょう。

しかし、そこで忘れてはいけないのは、価値を提供するのはソフトウェアだという事です。仕様変更が生じた際にその影響を狭い範囲に抑えられるか、それとも全体の見直しが必要になるかは、ソフトウェアのアーキテクチャに依存しています。

より良いソフトウェアへの配慮をした上で、 より良いツールやプロセスを導入すれば、より大きな効果が得られるでしょう。


« [#TiDD] ツール・技法の導入法 | トップページ | 対外発表する理由 #RxTstudy #seakansai »

チケット駆動開発」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#TiDD] ツール・技法の導入法 | トップページ | 対外発表する理由 #RxTstudy #seakansai »