アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
「要件定義書のアウトライン作成」完全マニュアル
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
