タグ

仕事とManagementに関するwildcatsのブックマーク (3)

  • ページが見つかりません | 無料ブログ作成サービス JUGEM

    //次のことをお試しください ページアドレスが正しいかをご確認ください ブラウザの更新ボタンをクリックし、ページの再読み込みをお試しください

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する

    結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている(騙されているともいう)。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
  • 反復型開発における見積もりの実際:ベースとなるのはユースケース

    オブジェクト指向技術の浸透や,反復型開発の広がりなど,システム開発を巡る状況が大きく変化している。見積もり方法も,従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基的な考え方や,ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い,ソフトウエアを段階的に繰り返して開発していく「反復型開発(イタラティブ開発)」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基的な考え方やフェーズの分け方が異なるため,従来型の見積もり技法を適合できない面がある。 そこで第4部では,反復型開発における見積もりの基的な考え方と,現在,一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお,システム開発のプロセスは反復型開発において最も標準的な「統一プロセス(Unified

    反復型開発における見積もりの実際:ベースとなるのはユースケース
  • 1