開発方法論は、開発プロセスや成果物が体系的にまとめられたもの。
実際にプロジェクトで適用してみて、その本当の価値に気付く。
開発方法論自体はフレームワーク。
枠組みだけでは機能しない。
少し大げさな表現になりますが、プロジェクトごとにきちん と魂を注入する必要がある。
2008年7月9日水曜日
大規模プロジェクトでは「同じ言葉を、同じ意味で」 － ＠IT自�
大規模プロジェクトでは「同じ言葉を、同じ意味で」 － ＠IT自�
開発方法論は、開発プロセスや成果物が体系的にまとめられたもの。
実際にプロジェクトで適用してみて、その本当の価値に気付く。
開発方法論自体はフレームワーク。
枠組みだけでは機能しない。
少し大げさな表現になりますが、プロジェクトごとにきちん と魂を注入する必要がある。
開発方法論は、開発プロセスや成果物が体系的にまとめられたもの。
実際にプロジェクトで適用してみて、その本当の価値に気付く。
開発方法論自体はフレームワーク。
枠組みだけでは機能しない。
少し大げさな表現になりますが、プロジェクトごとにきちん と魂を注入する必要がある。
2008年6月4日水曜日
Java:WebLogic JDBC接続プールを設定してみた
WebLogic JDBC接続プールを設定してみた
接続対象のオラクル
C:\oracle\ora92\network\admin\tnsnames.ora の設定例
ORA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ora)
)
)
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/network.102/B19209-01/tnsnames.htm
2008年5月18日日曜日
An Agile Way > Scaling Agile ... ソフトウェア開発をスケールさせる（大規模対応）
An Agile Way > Scaling Agile ... ソフトウェア開発をスケールさせる（大規模対応）
ソフトウェア開発チームにも、同じような２つのスケール作戦があるのではないか、というアナロジーに気づいた。
ソフトウェア開発チームにも、同じような２つのスケール作戦があるのではないか、というアナロジーに気づいた。
・scale up ... 個人のパワーや個人間のコミュニケーションを上げてチームのパフォーマンスを上げる。
・scale out ... 人の数を増やして、チームのパフォーマンスを上げる。
2008年5月3日土曜日
リーダ役でプロジェクトに入る人の心得｜ザ・プロジェクトマ�
リーダ役でプロジェクトに入る人の心得｜ザ・プロジェクトマ�
１ 健康管理に注意し、プロジェクト期間中に迷惑をかけるような休みをとらない。
２ 会議中に一瞬たりとも気をゆるめない。居眠りなどは言語道断。
３ 準備に充分時間をかけ、「お披露目」する資料はパーフェクトなものを。
４ 作業展開は成果物の連鎖（論理的順番）を重視する。ガントチャートは二次的なもの。
５ 誰が作成するかによって、成果物の質と量が大きく異なる。人のスキルとモチベーションに着目して作業分担を。
６ 進捗状況を的確に把握し、「この状況が続いたら？」のシミュレーションを絶えず行うべし。
７ 本当の進捗状況は数値に表れない。現場の空気を肌で感じる感性を磨け。
８ 一人で把握できる範囲には限界がある。プロジェクトメンバの「気づき」を大切に
１ 健康管理に注意し、プロジェクト期間中に迷惑をかけるような休みをとらない。
２ 会議中に一瞬たりとも気をゆるめない。居眠りなどは言語道断。
３ 準備に充分時間をかけ、「お披露目」する資料はパーフェクトなものを。
４ 作業展開は成果物の連鎖（論理的順番）を重視する。ガントチャートは二次的なもの。
５ 誰が作成するかによって、成果物の質と量が大きく異なる。人のスキルとモチベーションに着目して作業分担を。
６ 進捗状況を的確に把握し、「この状況が続いたら？」のシミュレーションを絶えず行うべし。
７ 本当の進捗状況は数値に表れない。現場の空気を肌で感じる感性を磨け。
８ 一人で把握できる範囲には限界がある。プロジェクトメンバの「気づき」を大切に
トラパパ＠ＴＯＲＡＰＡＰＡ > リハビリプロジェクト : ITmedia オル�
トラパパ＠ＴＯＲＡＰＡＰＡ > リハビリプロジェクト : ITmedia オル�
リハビリプロジェクトとは、当人の完全復活を支援するために、自信回復のための配慮をしたアサインメントのことです。
留意点は以下の通りです。
１． 多大な残業やパワハラ的人材が存在するような、高ストレスなプロジェクトでないこと
２． 疲弊の原因になったプロジェクト・クライアントと異なり、また仕事内容は類似もしていないこと
３． 当該メンバーが得意な領域の仕事で、ただし多少の（ほどよい）チャレンジも混じっていること
４． このプロジェクトを通じて当該メンバーに新しく教える技術・知識が必ず１つ以上存在すること
５． 長期プロジェクトでないこと（3ヶ月以内が理想）
６． 正規アサインメントメンバー以外に後方支援メンバーが第3者的にバックアップすること
７． 当該メンバーが想定パフォーマンスを仮に出せなくても、業務を代替して成功させる自信（保証）のある案件であること
８． 高い信頼関係が構築済みの、良好な関係にあるクライアントからの依頼案件であること
９． 就業の様子がマネジメントから透明に監視できる、もしくはマネジメントが足繁くコミュニケーションできる環境にあること
１０． ちゃんとしたビジネス案件であること（正規の料金をきちんといただいての仕事）2008年4月29日火曜日
データ総研｜DRIブログ｜ITアーキテクト黒澤の日記 2006年 ｜要求定�
データ総研｜DRIブログ｜ITアーキテクト黒澤の日記 2006年 ｜要求定�: "
すると「どのような機能をコンピュータシステムで実現するかという定義ですよ」という応え。一方で、概念データモデルを作成する工程で、我々が使っている要求定義は、「情報要求の定義」すなわち、「ユーザが仕事をするにあたってどのような情報を必要とするか」です。"
大切なことは、コンピュータが組織の一員として参加したときに、既存ユーザはいままでと異なる責任をもち、異なる役割分担になることです。業務仕様を固める工程の中心は、業務課題の検討とユーザの合意形成だと思っています。
すると「どのような機能をコンピュータシステムで実現するかという定義ですよ」という応え。一方で、概念データモデルを作成する工程で、我々が使っている要求定義は、「情報要求の定義」すなわち、「ユーザが仕事をするにあたってどのような情報を必要とするか」です。"
大切なことは、コンピュータが組織の一員として参加したときに、既存ユーザはいままでと異なる責任をもち、異なる役割分担になることです。業務仕様を固める工程の中心は、業務課題の検討とユーザの合意形成だと思っています。
データ総研｜DRIブログ｜ITアーキテクト黒澤の日記 ｜標準定義域�
データ総研｜DRIブログ｜ITアーキテクト黒澤の日記 ｜標準定義域�
定義域は、標準定義域と活動定義域の２つに分類できます。
典型的な標準定義域は、日付、金額、率、数量、文、コードなどです。
活動定義域は、商品コード、取引先コードなど、実際に使われている（活動している）値の集合を表します。
定義域は、標準定義域と活動定義域の２つに分類できます。
典型的な標準定義域は、日付、金額、率、数量、文、コードなどです。
活動定義域は、商品コード、取引先コードなど、実際に使われている（活動している）値の集合を表します。
登録:
投稿 (Atom)
