CMMは、ソフトウェアの開発プロセスを「改善できる能力」を評価するものであり、高品質ソフトウェアを効率よく作ることができる「絶対的な能力」ではありません。
2008年8月15日金曜日
幻の白いカラスを追い求め、僕らはインドにたどり着く - @IT MO
CMMは、ソフトウェアの開発プロセスを「改善できる能力」を評価するものであり、高品質ソフトウェアを効率よく作ることができる「絶対的な能力」ではありません。
2008年8月13日水曜日
arai blog: ペーパープロトタイピングの実践
概要:
*いくつかの機能を持つ動的なウェブサイト
使った道具のうち重要だったもの:
*A3サイズのスケッチブック(背景兼キャンバスとして使用)
*A4サイズの厚紙
*インデックスカード(こぶりの厚紙)
*太字サインペン(黒3本、青1本)
*蛍光マーカー(緑)
*はさみ
*貼ってはがせるのり
あればあったほうがよさそうなもの:
*付箋紙(ユーザの入力用)
*シャープペンシル(下書き用)
*貼ってはがせるセロハンテープ(部品の組み合わせ用)
2008年7月25日金曜日
2008年7月23日水曜日
データ総研|DRIブログ|ITアーキテクト黒澤の日記 |一物一コー�
何を同じとし、何を別とするのですか?それが明確でなければコード値を与える対象がわかりません。」さらに続けます。「たとえば、製造計画のときは、赤の ボールペンも黒のボールペンも区別せずに、両方をまとめたボールペンというものの商品別月別製造数を決めます。物流のときは、1本のボールペンではなく何 ダースかをまとめたカートン単位のボールペンを認識します。もちろん、このとき色は区別します。会計で棚卸資産の金額を計算するときは、100円のボール ペンはすべて型番にかかわらずまとめられ、それを1つの商品と扱います。今Aさんが持っている一本のボールペンだけを扱う業務はありません。どのような状 況になれば、コードが統一されたと言えるのでしょうか?」
2008年7月9日水曜日
大規模プロジェクトでは「同じ言葉を、同じ意味で」 - @IT自�
開発方法論は、開発プロセスや成果物が体系的にまとめられたもの。
実際にプロジェクトで適用してみて、その本当の価値に気付く。
開発方法論自体はフレームワーク。
枠組みだけでは機能しない。
少し大げさな表現になりますが、プロジェクトごとにきちん と魂を注入する必要がある。
2008年6月4日水曜日
Java: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 ... ソフトウェア開発をスケールさせる(大規模対応)
ソフトウェア開発チームにも、同じような2つのスケール作戦があるのではないか、というアナロジーに気づいた。
・scale up ... 個人のパワーや個人間のコミュニケーションを上げてチームのパフォーマンスを上げる。
・scale out ... 人の数を増やして、チームのパフォーマンスを上げる。
2008年5月3日土曜日
リーダ役でプロジェクトに入る人の心得|ザ・プロジェクトマ�
1 健康管理に注意し、プロジェクト期間中に迷惑をかけるような休みをとらない。
2 会議中に一瞬たりとも気をゆるめない。居眠りなどは言語道断。
3 準備に充分時間をかけ、「お披露目」する資料はパーフェクトなものを。
4 作業展開は成果物の連鎖(論理的順番)を重視する。ガントチャートは二次的なもの。
5 誰が作成するかによって、成果物の質と量が大きく異なる。人のスキルとモチベーションに着目して作業分担を。
6 進捗状況を的確に把握し、「この状況が続いたら?」のシミュレーションを絶えず行うべし。
7 本当の進捗状況は数値に表れない。現場の空気を肌で感じる感性を磨け。
8 一人で把握できる範囲には限界がある。プロジェクトメンバの「気づき」を大切に
トラパパ@TORAPAPA > リハビリプロジェクト : ITmedia オル�
リハビリプロジェクトとは、当人の完全復活を支援するために、自信回復のための配慮をしたアサインメントのことです。
留意点は以下の通りです。
1. 多大な残業やパワハラ的人材が存在するような、高ストレスなプロジェクトでないこと
2. 疲弊の原因になったプロジェクト・クライアントと異なり、また仕事内容は類似もしていないこと
3. 当該メンバーが得意な領域の仕事で、ただし多少の(ほどよい)チャレンジも混じっていること
4. このプロジェクトを通じて当該メンバーに新しく教える技術・知識が必ず1つ以上存在すること
5. 長期プロジェクトでないこと(3ヶ月以内が理想)
6. 正規アサインメントメンバー以外に後方支援メンバーが第3者的にバックアップすること
7. 当該メンバーが想定パフォーマンスを仮に出せなくても、業務を代替して成功させる自信(保証)のある案件であること
8. 高い信頼関係が構築済みの、良好な関係にあるクライアントからの依頼案件であること
9. 就業の様子がマネジメントから透明に監視できる、もしくはマネジメントが足繁くコミュニケーションできる環境にあること
10. ちゃんとしたビジネス案件であること(正規の料金をきちんといただいての仕事)