2011年5月24日火曜日

Team Fundation Server をつかってプロジェクトを管理してみる(5)

"You define areas to organize work items into logical, physical, or functional categories." - MSDN Library, Create and Modify Areas and Iterations"

 「エリア(区分)の設定は自由だ!」。管理するプロジェクトの性格は様々で、端的に言えばその進め方、つまりフェーズの切り方が大きく異なる。いくらスプリント単位でタスクを管理するとはいえ、レポーティングの観点では、こういったフェーズごとのマネジメントは必須になり、必然的にそれに沿ったメッシュが必要になる。それをどこで管理したらいいのかと言うのが最初から疑問ではあったのだが、それを解決するのにうってつけの項目だ。

 ちなみに、いくら勝手にオーガナイズできるといっても、それなりのガイドラインはきちんとMSDNで提示されている。 とは言っても、管理しやすく、複雑になりすぎす、適切にアクセス制限ができる、ということなので、ここは単純に、マネジメントの観点でのレポーティングに必要な大分類を、とりあえず1階層だけ設ける運用を始めることにした。



 以前ポストした様に、今回Scrumチームでハンドルするシステム開発のデリバリだけではなく、そのセールスからアフターサポートまでのライフサイクル全てをTFSでマネジメントしようとしているので、Salesのパイプライン(初期訪問、提案、見積、受注等)ステータスがレポートで見れるようにしたいというニーズがあったので、それをプロジェクトの一つに設定することにした。うーん、非常に便利だ。最初はアドインを使って追加項目を画面に設定しなければならないかと思っていたので。本当に便利。



これで「区分とイテレーション」の使い方については決まったので、スプリント(とリリース)の設定についても一段落した。さて、次にやらなければいけないのは… "Building Your Product Backlog". プロダクトバックログアイテムを作る、か…(続く)




2011年5月18日水曜日

Team Fundation Server をつかってプロジェクトを管理してみる(4)

"Sprints are time-boxed iterations of work in which your team produces a potentially shippable increment of the product being developed. Your team can decide the appropriate length for you, but most teams choose a length of time between a week and 30 days." - Microsoft How-To: Scrum for Everyone

スプリント、 なんていうぐらいだからかなり短いイテレーションを設定するんだろうなとは思っていたが、まさか最短1週間とは!スクラムの概念では、このスプリントごとに
1.スプリント計画会議を行い、その期間でやること(プロダクトバックログアイテム、以下PBI)をチームで合意して、
2.PBIを完了するのに必要なタスクを登録してこれを日々実施しつつデイリースクラムで進捗を確認し、
3.スプリントレビューを開いてクロージングする
ことが求められているので、この「ミーティングマネジメント」を効率的(短時間で、効果的)に行わないと却って生産性が低下することにもなりかねない。
今回会社では単純な開発プロジェクトの管理だけではなく、マネジメント全般にこの仕組みを用いようとしている(つまりVisual Studioを使って開発をするようなことではない作業もすべて管理しようとしている)ので、このスプリントとさらに上位にあるリリースのの区切り方は、非常に重要になる。

結局今まで、アウトプットを出すのにどれぐらいの工数とリソースが必要かを考えることに時間をかけることでマネジメントがうまくいかなかったことを踏まえて、一定の期間(リリース、スプリント)で可能なアウトプットを出すことに注力するという「発想の転換」を強いる以上、この区切り方が適当だと、結局なあなあになってしまう。

でも、とりあえず経験もないし、知恵もないから、「これがベスト」という基準もないので、まずは、1ヶ月1リリース(アウトプット導出)で4スプリントを標準とすることにした。結局1スプリント1週間。まずはやってみることにしよう。

TFSではデフォルト、1リリースに6つのスプリントがぶら下がっていて、それが4セット提供されているので、これをカスタマイズすることにする。

作成したプロジェクト名を右クリックして、[チームプロジェクトの設定]-[区分及びイテレーション]のダイアログボックスを開く。[区分]タブと[イテレーション]タブがあるので、イテレーションタブの中を適宜修正…はて、[区分]タブの中にある”Area”っていったい何に使えるんだろう。新たな疑問が…(続く)

2011年5月11日水曜日

Team Fundation Server をつかってプロジェクトを管理してみる(3)

「この本のほとんどの読者は、ウォータフォール(WF)モデルが期待する結果をもたらさないことを知っている。さもなければ、この本を読む動機がないだろう」 - "アジャイル開発の本質とスケールアップ"(Dean Leffingwell, 2010)

 なぜアジャイルに取り組もうとするのか、と言う理由は、ある意味「アンチWF」的意思がそれ以外のもろもろの理由を上回るのかもしれない。とりあえず道具(TFS)から入ってでもアジャイル(スクラム)にチャレンジすることになったのは、開発手法、というかシステム開発プロジェクトのマネジメントがWFでは(完全にダメとは言えないまでも)制御できないことが多かったという悩みから、であることは間違いない。要は「処方箋探し」だ。

 そんなわけでTFSにScrum1.0テンプレートをアップロードし、いざプロジェクトを作成!と思ったらエラーで終了したのが前回。このポストでは「技術的観点は無視」としたけど、さすがに管理者作業であるプロジェクト作成がうまくいかないのでは対処しなくては…

イベントの説明: TF30162: グループ "Portal" からのタスク "SharePointPortal" に失敗しました
例外の種類: Microsoft.TeamFoundation.Client.PcwException
例外メッセージ: 新しいチーム プロジェクト ウィザードで、次の SharePoint Web アプリケーションにサイトを作成しようとしたときにエラーが発生しました:




うーん、どうもTFSと連携するSharePointServerのサイトを構成するところでエラーが出たようだ。権限の問題?…かと思い悩んでいたところ、結局TFSをインストールしてくれたシステム管理者の方に解決してもらった。曰く「ロケールの問題」。



詳しいことはわからないものの、どうやらこの英語版しか提供されてないScrumテンプレート特有の悪さ?だったようで、Scrumテンプレートの構成ファイル(インストールするとProgram Files(x86)フォルダにできる)のなかの”WssTasks.xml”にある languageの設定を 1033から1041にすることで解決してもらった。



ということで、プロジェクトが無事登録された。さてここから何をするかが問題。いきなりTFSを触る前にきちんと手順を確認しなくては… Scrum ... Getting started ... ! <http://visualstudiomagazine.com/articles/2010/10/01/scrum-for-everyone.aspx> 。



とりあえず、これに従ってやってみよう。まずは「”Sprint”の期間を決めてみる」っと・・・(続く)

2011年5月9日月曜日

Team Fundation Server をつかってプロジェクトを管理してみる(2)

If your team uses Scrum or other agile processes, choose the process template for Microsoft Solutions Framework (MSF) for Agile Software Development v5.0.

If your team requires a rigorous audit trail and has a formal process for change management, choose the process template for MSF for Capability Maturity Model Integration (CMMI) Process Improvement v5.0. - "MSDN,
Choose a Process Template"

説明になっているようで、説明になっていないこのプロジェクトテンプレートの選び方。本当なら、CMMIとAgileそれぞれの比較を詳細にして、さらにここにScrumも加えての評価が必要…となるわけだが、今はそこまでの時間はない。とりあえずどれか一つまずは使ってみてから次を考えよう、と言うことにした。

その選択の前提となるコンセプトは、「小さなチームにより」「イテレーティブな開発プロセスの導入により」「早期に品質の高いプロトタイプを顧客に提供し」「そのリファインを繰り返すことで」「顧客満足の高いプロダクトを提供する」(ちょっと長いか…)なので、まずは、ツールとして、

・「小さなチームにより」
・「イテレーティブな開発プロセスの導入」

というやり方に適したものがいい、ということで、実はどれをとっても開発はイテレーティブに行うことが前提のテンプレート(もはやWF的な開発プロセスは一切考慮されていない?!)なので、どれでもよくなってしまうのだが、とりあえずは”Scrum”(※)を選ぶことにした。

※因みに冒頭の「テンプレートの選択」ではCMMIとAgileについてしか説明がない。TFSがデフォルトで提供しているテンプレートがこの2つしかないから。しかし、Scrum(正確にはVisual Studio Scrum 1.0)というテンプレートもMSが無償で公開しており、すぐに導入できる。また、MSDNにもきちんと説明がある

AgileとScrum、この2つのテンプレートががどう違うのか?(そもそもScrumはOne of Agileという理解なので、なぜScrumだけ切り出されたのか?)という疑問も解決しながらいろいろ試していこうと思う。さて、公開サイトからテンプレートをアップロードしていざプロジェクトを作成!…しようと思ったらエラーが。。。(続く)









とにかく今やりたいことは、


・短期間のイテレーティブな開発により、早期にプロトを提示することを通じた

2011年5月2日月曜日

Team Fundation Server をつかってプロジェクトを管理してみる(1)

"Successful projects often have the following characteristics:
- The needs of the customers drive the project.
- The team creates a high-level plan for delivering the project.
- The team develops the product over several iterations and refines the high-level plan over time.
- The team has effective tools for adapting to changes that occur. " - "MSDN Planning and Tracking project 2010"


良いシステム開発プロジェクトを実現するための鍵の一つがイテレーションである、と銘打っているところが、時代の潮流なのかと思いつつ、いまだ現場ではそれほど効果的なイテレーティブプロセスが採用されていないのではという懐疑もある。

そんな中で、新しく何かを始めるにはまず形から(ジョギングするならまずシューズ、ゴルフするならまずクラブを買い揃えないとモチベーションは上がらない)、でもないのだが、「これからのプロジェクトマネジジメント」にチャレンジするために、Microsofot Visual Studio(VS) 2010 と Team Fundation Server(TFS) を導入することになった。冒頭はその TFSを読み解くにあたって登場したMSDNの「イントロ」。
このポスト(シリーズ)では技術的な観点は「抜き」にして、プロジェクトマネジメント観点からの使い勝手にフォーカスしてみたいと思う。ということで、TFS導入の最初の難関であろうサーバ環境のインストールとか、レポートツールのセットアップとか、その辺も「抜き」。(リンクの記事がわかりやすいと思う)

ということで、さっそくTFSでのプロジェクト作成から始めようと思ったが…
そこに登場するいきなりの3つの選択肢、さて何を選ぼうか(困)。
- Visual Studio Scrum 1.0
- MSF for Agile Software Development v5.0
- MSF for CMMI Process Improvement v5.0

2010年9月15日水曜日

第5水準の指導者(経営者)

「第5水準の指導者は、成功を収めたときは窓の外を見て、成功をもたらした要因を見つけ出す。結果が悪かったときは鏡を見て、自分に責任があると考える」 - "Visionary Company 2 - Good to Great - " (2001)

自分が今指導的立場であるかどうかは問わず、キャリア形成をする上では、遅かれ早かれ、大なり小なりマネジメントのポジションを経験することになる。

その時に、最上級のマネジメント、すなわち優れた会社が偉大に(Good to Great)なり、しかもそれを継続可能にするためのマネジメントとは「徹底して謙虚で、控えめで、飾らない」ことであるといわれたら、声の大きさやカリスマ性を重んじる昨今の経営者像にとってはちょっとしたアンチテーゼだ。

「自分に与えられた成功を常に幸運と思い、なぜ幸運であったのかを考える。」「野心を自分(の成功)に対して向けるのではなく会社に向ける。」

会社、が大きすぎればチーム、でもいいだろう。「幸運にも」自分が率いたチームが成功裏に何かを成し遂げたときに、それを心から「幸運だった」と思えるかどうか、そしてなぜそう思えるかがきちんと理解できているかどうか、、、そんなことを考えることができる機会があれば、それこそ得難い「幸運な」経験になるだろう。


2010年8月29日日曜日

組織はオーガナイズされてなければいけないのか?

組織構造は目的達成のための手段である … (略) … 組織の健康を判定する基準は、構造の美しさでも明快さでも完全さでもなく、成果である。 - (Management Essential - 2001)

健康でない組織は、階層がいびつだとか、指揮系統が不明朗だとか、機動性に乏しいだとか、いろいろ言われる。組織を構成する人の数が多くなればなるほど、その度合いは大きくなるとも言われている。だから、アメーバ経営なるものものが出てきて、それに風穴を開けようとする。
ドラッガーから見ると、前者がシステム型だったりあるいは連邦分権型だったりする一方で、後者はチーム型ということになるのだろう。

いろんな現場や会社でいろんな単位の人々の集まりをみてきたけれど、それはチームと呼ばれていても決してチーム型ではなかったり、あるいは会社の大きな組織内の集まりでも決してシステム型ではなかったりしていた、と"Management"を読み返してみて思う。

組織とかチーム、ってなんだろう、という今さらながらの思い。それらの組成に多大な労力を割いても、それが最適な解なのかはその時点ではわからない。まさに「成果」のみがそれを決める。誤解を恐れずに言えば、決してオーガナイズなんてされていなくてもいい。傍から見て烏合の衆のように見えても、成果が出るときには出る、それは取り組む対象にもよるのではあろうが。

サッカー日本代表の今回の成功要因は、「意識の統一」だったと言われている。それは組織としてオーガナイズされたが故だったのか?それともただプロフェッショナルが同じ成果をただ追求することでおのずから一体化されただけのことだったのか?あまりの短期間の変容ぶりからは、それが「オーガニゼーション」の構築に腐心した末の結果だとは、受け取りにくい。さて、岡田監督は、ドラッガー、(それとももしドラ?)読んでいたのだろうか…