アジャイルにおける事前合意について - arclamp
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要
「ソフトウェア開発プロジェクトをとりまく６つの誤解」は真実でもある - arclamp
「ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと」に釣られてみます。 6つの誤解は次の通り。 既にあるソフトウェアを流用した方が速く作れる ソフトウェアはハードと違って後から容易に直せる 誰が作っても中身は同じ品質になる 共通部品から先に作ることが出来る 人を増やせば一度に沢山の機能が作れる 正確な見積もりを出すことが出来る 記事の前提は"お客さんはITにそれなりに詳しい（けどプログラミングはしたことがない）情報システム部門の人"ということだと思います。 この6つは誤解しやすいし、僕もお客さんと会話する内容です。でもね、お客さんがそう感じていることも事実です。なるべく安く早く、そして変更に強いシステムを作りたいと願うことは当然のことです（もちろん予算どおりに）。 ソフトウェア開発に職人的（あるいは芸術的）要素があることは間違いありませんが、それ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp
