« 2007年10月 | トップページ | 2007年12月 »

2007年11月

2007/11/23

【JavaScript】Kanasan.JSの資料

関西.js(通称:kanasan.js)で以前開かれた時、JavaScriptのオブジェクトやプロトタイプチェーンについて、主催者kanasanが非常に分かりやすく説明してくれた。
その時の講演資料が公開されているので、メモしておく。

Kanasan.JSの資料

JavaScriptを使って分からなくなるのは、Core JavaScriptと、ブラウザ独自のオブジェクトを混乱して使っているからかな。

| | コメント (0) | トラックバック (0)

JavaScript第5版読書会#1

JavaScript第5版読書会#1へ行ってきた。
大阪で平日の夜なのに、18時半には30人以上も集まっていたよ(驚)
読書会の内容は、JavaScriptの辞書である通称「サイ本」を最初から読むこと。

3時間の議論はすごく中身が濃かった。
その時の感想をメモ。

【1】JavaScriptは、他の言語と文法が微妙に違う所を認識していないのが、バグの温床になる

変数、メソッド、オブジェクト、配列、ハッシュなど、最初から読むが、僕には退屈。
20章「HTTPによる制御」にあるAjaxを早く読みたかった。

でも、主催者のkanasanから、Ajaxでバグにはまる原因はJavaScriptの文法をきちんと理解していないからですよ、と言われた。

確かに、JavaScriptのブロックは、CやJavaと異なる。
つまり、IF文などの制御構造で定義したローカル変数は、グローバル変数に近い。

また、暗黙の型変換をすごく多用する。
よくあるパターンは、変数に「!!」を使うと論理型へ型変換する。
prototype.jsでも「!!」は良く出てくる。

【2】JavaScriptのオブジェクトは、インスタンスそのもの
  ~nullでなくundefinedがある理由

JavaScriptのオブジェクトは、ハッシュに近い。
つまり、image.width と image["width"] は同じ。
これによって、プロパティを動的にいじることが出来る。

また、オブジェクトのプロパティにfunctionを設定できる。
つまり、データと関数は同じ意味を持つ。
Ajaxでも、HTTPリクエストのプロパティへ手続きを設定する仕組みを使う。
例えば、GMailのように、ブラウザをリフレッシュせずに非同期でサーバーから最新メール情報を取得する。

JavaScriptのオブジェクトは、コンストラクタをあまり意味がない。
何故なら、必ずインスタンスがあるから。

thisオブジェクトは神様みたいなオブジェクト。
ブラウザ上では必ずオブジェクトはあるみたい。

JavaScriptでは、JavaのNullPoniterExceptionに当たるエラーとして、undefinedが良く出る。
これは、該当するインスタンスが見つからないと言う意味。

また、JavaScriptの継承は、プロトタイプチェーンと呼ぶ。
JavaやC++、Rubyの継承とは異なる。
この辺りも面白い。

【3】最近のWeb開発のトレンドがサーバーサイドからリッチUIクライアントへ移行しつつある

Ajaxが出現するまで、JavaScriptは使えない言語だった。
メモリリークは良く出るし、ブラウザ依存だし、使い勝手が悪かった。
でも、Web開発のトレンドがサーバーサイドからリッチUIクライアントへ移行しつつある今、JavaScriptは重要な意味を持つ。

Googleがやり始めたことは、リッチUIクライアントを操作する言語としてJavaScriptを使い、サーバーサイドからUIクライアントのJavaScriptソースコードを自動生成する仕組みを導入したこと。

Google Web Toolkitも発想は同じ。
Railsにある、RJSも全く同じ。

この発想は、JavaやRubyが、JavaScriptという他言語を生成するという、いわゆるメタプログラミング。

でも、サーバーサイドがクライアントよりも主導権を握るという従来のWeb開発スタイルは踏襲している。
この流れならば、リッチUIクライアントであろうとも、サーバーサイドから制御できるだろう。

Web開発のトレンドは今、JavaScriptが表舞台にいるのかもしれない。

【番外編】
JavaScript 第5版」によく出てくるリファレンス本は下記になる。
持っておくと便利かも。

| | コメント (2) | トラックバック (1)

2007/11/18

NetBeansがRuby開発環境に向いている

NetBeansでRailsの開発が出来ると聞いて、さっそくダウンロードしてみた。

DBさえ設定すれば、Railsのディレクトリやソースを自動生成してくれる。
使い勝手はすごくいい。

一番欲しかった機能は「コード補完」。

defを書けば勝手にendが補完される。
メソッドを書いている途中で、メソッド名を補完してくれる。

メソッド名にフォーカスを当てると、JavaDocのように、機能内容がポップアップされる。
#いわゆるJavaのメソッドにマウスポインタを合わせたときに表示される吹き出し(ホバー表示)のこと。

参照元のクラスやメソッドにも飛んでくれる。

プログラミングはEmacsやviだけで十分かもしれないが、大規模開発になると、自分たちが作ったライブラリを参照しながら書くのが普通なので、コード補完やホバー表示は重要。

更に、JRubyも入っているので、色々使えそう。

NetBeansも、EclipseやVisualStudioのような機能が揃いつつある印象を受けた。


過去のSmalltalkは、VisualAgeという統合開発環境と共に育った。
Javaも、VisualAge for JavaやEclipseという統合開発環境が出て、爆発的に普及した。

だが、Javaを作り出したSunよりも、Eclipseという統合開発環境とWebSphereというアプリケーションサーバーを持つIBMがJavaマーケットで一番儲けた。

今度は、SunがRubyをサポートして、同じような事象を狙おうとしている。

RubyもNetBeansという統合開発環境で普及するだろうか?

| | コメント (0) | トラックバック (0)

2007/11/08

ソフトウェア開発のチームビルディング

 「スーパーエンジニアへの道―技術リーダーシップの人間学」を読んで気づかされることがあった。
 思いついたことを書き連ねてみる。

1・リーダーとなる人は、技術能力とリーダーシップ能力の合いの子

 少なくとも、ソフトウェア開発チームを引っ張る人は、二つの能力を必要とする。
 リーダーシップだけでは、他人に命令するだけの手配師に過ぎない。
 また、開発者は、自分が担当したプログラムの範囲だけの部分的なシステムしか理解できない時が多い。
 
 技術能力は特に、システム全体の仕様の整合性を考える時や、仕様漏れを見抜く時、非機能用件との兼ね合いを考える時に最も必要とする。
 
2・リーダーシップは、周囲の人の力を増大させるプロセスを作り出すこと

 7つの習慣でも同じようなフレーズがあった。
 本では、発言回数の最も少ない開発者の意見が、問題の解決の糸口になったと言う例が載せられていた。
 チームのメンバーならば誰でもそのアイデアを尊重する雰囲気作りが大切なこと。
 そのアイデアから他メンバーが更に連想して、問題解決の糸口を作り出すこと。
 チームの多様性(本では有機性と呼んでいる)が大切なこと。

3・多様性とは、色んな役割の人がチームにいること

 コーチングでも人を下記の4つのタイプに分けていた。

・自己主張が強くて感情が出にくいのが  「コントローラー」
・自己主張が強くて感情が出やすいのが  「プロモーター」
・自己主張が弱くて感情が出にくいのが  「アナライザー」
・自己主張が弱くて感情が出やすいのが  「サポーター」

 実際の現場でも、ベテランだけでなく若手にも、何らかの役割がある。
 開発チームでは経験上、下記の役割を担う人がどうしても必要だと思う。

・プロトタイプを作るのが好きな「アグレッシブプレーヤー」
 このタイプは力任せにガンガン作る。
 自由奔放に書きたいらしい。

・新しい技術の検証が上手な「アーリーアダプター型プレーヤー」
 このタイプは新し物好き。
 ソフトウェア開発では必須な人。

・お手本となるプログラムがあればどんどん書いていける「ペースメーカー」
 このタイプがプロジェクトの進捗の鍵を握る。

・丁寧なテストでバグ出しするのが上手な「神の手を持つ人」
 このタイプがテストすると、神の手を持っているかの如く、必ずバグが出る。
 このタイプがシステムの品質を保障してくれる大切な人。

・プログラミングだけでなく環境構築やリリース作業もこなせる「ユーティリティープレーヤー」
 このタイプは、緊急トラブル対応や火消し役で最も活躍する人。
 運用保守で最も重宝される人。
 但し、このタイプはプロジェクト後半になるほど負荷が大きくなるので、要注意。

 開発チームは有機的な結合で出来上がるもの。
 チームビルディングはXPやPFでも重要視している。
 システム開発のチームビルディングは、他業界よりももっと特徴的な気がする。

|

2007/11/06

【告知】スターティングXP! ~XPを知ってまっか?~

◆スターティングXP! ~XPを知ってまっか?~◆

XPが日本に上陸してはや7年が経ちました。
しかし、「XP」という言葉は知名度が向上したものの、「XP」という開発手法の採用事例はまだまだ少ないように感じます。

そこで、再び原点に立ち戻り、今一度XPについて考える場を設けたいと思います。
「XP」を知らない方、或いは、「XP」についてもっと知りたい方、是非ご参加下さい。

今回のイベントをきっかけに、「XP勉強会」を定例開催して行きたいと考えています。

◆内容◆
■開催日時
日時:2007年11月30日(金) 19:00~21:00
場所:大阪産業創造会館(産創館) 大阪市中央区本町1-4-5
詳細は、ご案内メールにてお知らせ致します。

■XPJUG関西スタッフによるスピーチ
XPを職場で実践されているスタッフが、初心に帰って「XP」について語ります!!
3名のXPerに熱く語って頂きます!!

■ワークショップ「ペアドロー」
もはや「XP」の代名詞とも言える「ペアプログラミング」。
このペアプログラミングを疑似体験できる「ペアドロー」を行います。

◆参加人数◆
先着順30名までと致します。
参加費は無料です。

◆懇親会◆
イベント終了後、懇親会を開催致します。
4000円~5000円程度の見込みです。
懇親会につきましては、各自実費をご負担願います。

◆申し込み◆
こちらからお申し込み願います。

◆主催◆
XPJUG関西

| | コメント (0) | トラックバック (0)

2007/11/04

Mavenで開発ライフサイクルを制御する

Mavenを使う時があり、「Apache Maven 2.0入門 Java・オープンソース・ビルドツール 」を参考にした。

Mavenを実際に使ってみて、概念や経験を整理してみる。

【1】Mavenとはビルドツールの標準テンプレートである

 MavenはJavaのビルドツールである。
 Antも同様だが、Mavenの特徴は汎用ビルドツールのテンプレート版みたいなもの。

 Mavenには下記の主要な概念、仕組みがある。

1-1.アーティファクト

 Mavenによって作られるプロジェクトの成果物を指す。
 一般には、JAR、WAR、EARファイルなどのコンポーネント。
 他に、JavaDoc、JUnitテストレポート、DJUnitレポート(カバレッジのレポート)も含まれる。
 
1-2.POM(Project Object Model)

 ビルドするための情報(メタデータの構造)が定義されたファイルのこと。
 普通は、pom.xmlというファイル名で作られる。
 Mavenは、pom.xmlに書かれた依存ファイル、成果物の定義を参照して、リリース用モジュールをビルドする。
 Antのbuild.xmlに相当する重要なファイル。
 
 この中で重要なタグ情報や仕組みは、下記である。

1-2-1.artifactID
 成果物のファイル名を指す。

1-2-2.groupID
 アーティファクトを作成した組織のID。
 Javaで言うパッケージ空間に相当する。

1-2-3.dependency
 アーティファクトを作るために必要な依存ライブラリを定義する。
 普通は、WebフレームワークのJARファイルやJacartaCommonライブラリが定義される。

1-2-4.version
 アーティファクト(ビルドしたモジュールや依存ライブラリ等)のバージョンを指す。
 グループID、アーティファクトID、バージョンによって、モジュールやライブラリは一意に識別され、かつ作られる。
 ビルド時は、このバージョンが最も重要な意味を持つ。

1-3.依存関係の解決
 Mavenは、依存ライブラリのグループID、URL、バージョンを指定しておくと、ネット上からダウンロードして関連付けてくれる。
 他に、開発時に共有ライブラリを自作して、依存関係を定義することも出来る。
 この仕組みのおかげで「マルチプロジェクト」という概念も実現される。

 Mavenは最終的に、「artifactId-version-拡張子」(例:app-1.0.1.jar)という形のリリースモジュールを作るために存在すると言い切ってよい。
 
【2】Mavenは、ソフトウェア・ファクトリー・ツールである

 IBMの記事「EclipseでMavenを生かす」にMavenの特徴が非常に洗練されて紹介されている。

Mavenは、末端ながらソフトウェア・ファクトリー・ツール・ファミリーに属するものです

ソフトウェア・ファクトリーは、次の3つの概念を中心に構成されています。

1・スキーマ。
 アプリケーションを構成する様々な成果物の構造と、それらの相互動作を記述するメタデータを提供します。
2・1つ以上のテンプレート。
 スターター・キットと、アプリケーション構築に必要なもの全てを提供します。
3・拡張可能開発環境(extensible development environment)。
 コンポーネントの設定、カスタム化、組み立てに使われます。

Mavenの基本的な目標というのは、ビルド・プロセスを標準化することであり、またCBTD(code-build-test-deploy)のサイクルに品質と再現性をもたらすことです

 上記の通り、開発ライフサイクルとは、下記の流れになる。
 Mavenは、ビルド~リリースの作業を自動化してくれる。

1.コーディング

2.ビルド

3.テスト

4.デプロイ(リリース)

 ソフトウェアファクトリーはMSが提唱している概念の一つ。
 不勉強なのでソフトウェアファクトリーを完全に理解していないけれど、Mavenがやろうとしていることは、ソフトウェア製造工場の作業の理想形なのだろう。

【3】Maven以前のビルドプロセスを振り返ってみる

 ソフトウェアの歴史は、プログラミングだけでなくビルドの歴史でもある。
 古くはアセンブラからC、C++に至るまで、ビルド作業は最も重要な作業の一つ。
 リリースしてシステムを動かすために必須だから、プログラミングよりもはるかに大事かもしれない。
 
 Javaの歴史もビルド作業の変遷という視点から眺めることが出来る。
 
3-1.僕が初めてJavaプログラムを書いた時、サーバーへJSPやpropertiesのようなテキストファイル、Classのようなバイナリファイルを、手作業でディレクトリに配置していた。
 当然、Classファイルは100個以上にのぼることもあり、リリース作業手順書を詳細に作る必要があった。

 他には、JSPは初めて実行すると初めてコンパイルされるため、表示に時間がかかる状況があり、わざわざJSPだけをリコンパイルするツールも数年前まであった。

 また、リリース後には必ずWebSphereやWebLogic、Tomcatを再起動しなくてはならない。
 つまり、リリース作業が10分間と言えどもシステムが止まってしまう。
 その間、お客の業務は止まるのだから、限られた時間でしかリリースできない。
 そのためにアナウンスが必要だったり、非常に手間がかかる。
 だから、リリース作業には細心の注意が必要だった。

3-2.じきに、JARファイルやWARファイルでソースを固めて、手作業でアップロードするようになった。

 この利点は、アプリケーションサーバーを再起動した時に、勝手にデプロイ(配置)してくれること。
 でも、以前デプロイしたモジュールに上書きされない時があるので、手作業で以前のデプロイモジュールを削除することをしていた。
 
3-3.それから、Antを使ってビルドするようになった。
 build.xmlにビルドに必要な作業情報を全て書き込めば、勝手にコンパイルしてくれる。
 しかも、「ant clean」のコマンドを使えば、過去にコンパイルしたモジュールも削除して、リコンパイルできる。
 classファイルを手作業でアップロードしていた頃に比べると雲泥の差があった。
 
 でも、Webシステムが大規模化して依存ライブラリが増えるに従い、バージョン管理が非常に難しくなってきた。
 古いライブラリをバージョンアップしたいのに、一度動かしたシステムの依存ライブラリをバージョンアップして動作しなくなったらどうするのか?
 また、色々な環境(開発テスト環境、受入テスト環境、本番環境)ごとにbuild.xmlを作り、ソースコードを管理するのはまだまだ手作業の部分が多く、危険が多い。

【4】Mavenによるバージョン管理で「要件から仕様化するプロセス」を制御する

 Mavenは、ビルド作業のテンプレートとも言える。
 ビルド作業の決まりごとを守れば、設定を極力減らすことができる。
 ビルド作業でも、「Convention over Configulation」という概念が出てくる!

 とりわけ僕がMavenを使ってみて最も威力があると感じたことは、「バージョン管理」。
 
 オープンソースのアプリケーションに「開発(リリース)履歴」があるけれど、その内容を強力に管理できる。
 
 管理者の視点から見ると、バージョンと機能を1対1に紐づけることが可能になる。
 つまり、pom.xmlにリリースする機能ごとにバージョンを付けることで、デグレを防げるだけでなく、新規開発と運用保守のモジュールを平行して開発するのが以前よりもはるかに容易になった。
 
 仕様さえ固められれば、「この新しい機能をいつリリースするのか?」の場合はバージョンを1個増やした新規バージョン、「このバグはどのバージョンで直すか?」の場合はマイナーバージョンアップで管理すればいい。
 いつでも以前のバージョンに戻すことが出来る。

【5】Mavenは開発プロセスのフレームワーク(テンプレート)になりうるか?

 Mavenによるバージョン管理で初めて、CMMに出てくる構成管理や要件管理をイメージできたように思う。
 仕様さえ固めれば、ビルドしたモジュールを機能単位に制御できる。

 また、実際にMavenを使うと、JAR(WAR)というコンポーネントが単なる物理ファイルだけでなく、人や作業を含む1プロジェクトの成果物の概念まで昇華される印象を持った。
 というのも、開発者と成果物は1対1にマッピングできるから(N対1、1対Nもあるが)。

 自分が作ったモジュールにバージョンを付けるという意味は、自分がその成果物の最終責任を負うことを意味する。
 つまり、「何を修正したのか」という機能内容がバージョンに含まれていて、そのコンポーネントの品質と仕様、他コンポーネントへの依存関係も、その人が全て把握していることになる。
 その意味では、pom.xmlにバージョンを付ける事ができる人は、非常に大きな権限と責任を持つことになる。

 このようにして、コンポーネントと開発者がリンクされることで、コンポーネントの依存関係に従って、UMLの配置図がプロジェクト組織の依存関係とマッピングできる。
 つまり、共有ライブラリよりも画面に近いサブシステムの方が多くの依存関係を持つ。
 共有ライブラリのバージョンが上がると、画面に近いサブシステムもバージョンアップせざるを得なくなること。

 Mavenを使うと、自社の開発プロセスを標準化できる可能性がある。
 
 とはいえ、Mavenを使いこなせたレベルとは言えず、以前よりも開発がスムーズになったわけでもない。
 でも、Mavenを使って、以前のプロジェクトと大きく異なると感じたことは二つ。
 
 一つは、以前よりももっと大規模なシステム(モジュール)を作れるようになったこと。
 もう一つは、開発プロセスのボトルネックが、プログラミング工程ではなく、要件から仕様へ落とす設計やプロジェクト管理の工程に移ってきたこと。
 
 MSでは、開発者やテスト担当者よりもビルド担当者の方が大きな権限を持つと聞いた。
 Mavenによるビルド作業はまだ研究の余地があるように思う。

| | コメント (0) | トラックバック (0)

2007/11/03

【JavaScript】Kanasan.JSに行ってきた

土曜の午後にKanasan.JS(関西.js)へ行ってきた。
コミュニティの趣旨は「皆でprototype.jsのソースコードを解読しよう!」というもの。
Kanasan.JS」でしか告知していないのに、25人も集まった(衝撃!)
どうやら殆どの人はTwitterを通じて知ったらしい。

わざわざこのコミュニティのために東京(!)からはるばる来た人もいたよ!

約3000行のうち300行しか解読できなかったけれど、奥深い議論が出来て楽しかった。
楽しかった感想を徒然に残す。

【1】プロトタイプチェーン~クラスとインスタンスの区別はない

 JavaScriptのオブジェクト指向は、Java等とは異なり、プロトタイプベースと呼ばれる。
 継承の概念がOOとプロトタイプでは大きく異なる。
 その仕組みをプロトタイプチェーンと言われるらしい。
 
 OOでは、型を継承する。
 プロトタイプは、型を継承せず、親クラスのインスタンスを内部に持つ。
 つまり、プロトタイプオブジェクト配下のメンバーは、プロパティみたいなもので、他のプロパティをコピーして作られる。

 コンストラクタは、OOのコンストラクタではないため、すごく使いにくい。
 だから、initilizeを使う。
 JavaScriptのインスタンス生成はRubyのinitializeに近い。
 
 皆の議論を聞くと、Javaで知っているオブジェクト指向と微妙に異なる点が面白かった。

【2】prototype.jsはRuby on Railsの影響を強く受けている

 参加者から「ProtoTypeは、Railsの影響を強く受けている」という話を聞いて驚いた。
 Railsの開発者がPrototypeの開発チームにも入っているらしい。

 実際、prototype.jsには、文字列のライブラリを再定義しているのだが、そこに出てくるgsubなどは、Rubyのライブラリに非常に近い。
 特にArrayはそうですよ、と。

 Ruby on Railsは、JavaやPerl、PHPなどのWebフレームワークに大きな影響を与えているが、まさかJavaScriptまで影響を及ぼしているとは思ってもみなかった。

【3】最近のWeb系の技術はJavaScriptが熱い

 僕が今回の催しに興味を持った理由は、最近のWeb系システムでは業務ロジックよりも、Ajaxを使ったUIプログラミングの方が要求されるスキルが高いから。
 今、技術革新がサーバーサイドのJavaからフロントエンドのJavaScriptへ移りつつある気がする。
 更に、prototype.js、jquery.jsは、Railsの影響を受けているのも興味を引く。

 恐るべしRails。

 主催者のkanasanは非常の物腰の柔らかい方で、人望が集まりそうな人。
 次回もやりましょう、と声が上がった。
 
 関西でもJavaScriptが熱くなるかな??

| | コメント (0) | トラックバック (0)

2007/11/02

Webベースのプロジェクト管理

 最近、プロジェクト管理の手法が急激に変化しつつあるのを感じる。
 以前は、ExcelやMS Projectで進捗管理や要件管理をプロジェクトリーダーが取り仕切り、メンバーに節目ごとに展開していた。
 そこでよく出る症状として、プロジェクト全体の進捗や各メンバーの役割がメンバーに見えにくいことがあった。
 だから、「見える化」と称して、XPやPFの手法が使われた。

 最近は、Trac(Python)Redmine(Ruby on Rails)のようにWikiベースのFreeのプロジェクト管理ツールを導入するケースが多くなった。
 その特徴や感想について書いてみる。

【1】TracやRedmineの特徴は下記があるように思う。

1・Wikiに、技術上のアイデア、開発環境の構築方法、リリース作業手順、日報などを書き込み、皆で情報共有する

2・カレンダーにプロジェクトのマイルストーン、各自の作業納期を書き込み、皆で情報共有する

3・各自の作業をタスク(Tracならチケット)に作業ステータスや作業期間を記入し、管理者だけでなく皆で情報共有する

4・タスクに見込みの作業期間を入れられるので、ガントチャートを自動生成できる(!)
 バーンダーンチャートを生成するプラグインもあるらしい。

【2】普通の使い方は、下記が多いだろうと思う。

1・タスク(Tracならチケット)に管理者が作業内容と作業期間、担当者を決める。

1-1.マイルストーンごとにタスクを管理すると、見た目上も管理しやすくなる。
1-2.コンポーネント単位に担当者を決めておくやり方もある。

2・開発者は毎朝、自分が担当のチケットを作業して、終わったらCloseしていく。
2-1.Closeしたらメール送信するなどの機能などもある。

3・特に結合テスト以降のフェーズでは、、、
3-1.テスト担当者がバグ出しした現象をチケットに、画面のキャプチャやログをアップロードして、どんどん書き込む。

3-2.担当する開発者は、チケットを見て修正し、コミットする。
  CVS又はSubVersionのコミットコメントにTracチケットNoを貼り付けると、コミットログからTracチケットへリンクが張られる機能もある。

3-3.テスト担当者は、バグが修正されていたらCloseしていく。

【3】実際に使ってみた印象では、開発者には受けがすごくいい。

 理由の一つは、自分のタスクが全体のどの部分を占めているのか、すぐに分かること。
 更に、プロジェクトの現状がTracのチケットやカレンダー、ガントチャートによって末端のメンバーも分かるから。
 Wikiベースなので、不明点は検索すればよいし、各自が持っている仕様や技術をWikiにどんどん書き込めば情報共有も簡単。

 管理者にとっても、要件から仕様へ落とした後、タスクと担当者を紐付けるフェーズで使える。
 更に、Tracチケットの発行数、作業未完了の個数から、残工数を計測できる。
 また、要件とTracチケット、そしてTracチケットに紐づいたコミットログから、仕様漏れやソースのデグレを未然に防ぐことも可能になる。

 実際は、うまく活用し切れていない面も多い。
 Tracチケットを発行しすぎて、アサインする担当者が不明のチケットばかりになってしまい、なかなかバグフィックスできない時もある。
 ガントチャートやバーンダーンチャートも、日々変化するプロジェクトに追いつけなかったりする。
 
 でも、Webベースのプロジェクト管理は「見える化」をすごく意識している。
 うまく使いこなせば、以前よりも生産性が高くなるはず。

 特にRedmineの場合、Railsなので、インストールがすごく簡単。
 更にRubyやRailsの知識があれば、簡単にカスタマイズも出来る。

【4】昔ながらの強権的な密室主義のプロジェクト管理手法はもう限界に近づいている。
 XPやPFのような人間系の手法だけでなく、開発プロセスを補完するような環境作りもプロジェクト管理では大事。
 
 未だ発展途上のWebベースのプロジェクト管理手法は研究する価値があると思う。
 

| | コメント (0) | トラックバック (0)

« 2007年10月 | トップページ | 2007年12月 »