ウォータフォールは死滅！これからはXPで決まり！
>951
じゃあ病めますと言ってやれ
じゃあ病めますと言ってやれ
953 ：941：05/03/19 22:50:51
>>942
要求仕様書がちがちに書いてて計画ゲームなんてできっこないじゃん
発注側としてはそこまでいうからには当然完成責任もとめるから
週３５時間労働なんて許すわけないじゃん
要求仕様書書くだけで大変だったのにオンサイト顧客なんて出せるわけ
ないし、出したところでいまさら契約は変えられない
ってわけで絶対ＸＰなんて無理だと思うんだけど
要求仕様書がちがちに書いてて計画ゲームなんてできっこないじゃん
発注側としてはそこまでいうからには当然完成責任もとめるから
週３５時間労働なんて許すわけないじゃん
要求仕様書書くだけで大変だったのにオンサイト顧客なんて出せるわけ
ないし、出したところでいまさら契約は変えられない
ってわけで絶対ＸＰなんて無理だと思うんだけど
955 ：仕様書無しさん：05/03/20 13:37:38
既存のウォータフォール案件がデスマるのは
ウォータフォールの手法思想自体が悪いからではなく
ウォータフォールの思想が誤解されていて
悪い運用をされているからでもないと思う。
そんな小難しい手法論じゃなくて
ただ単に現実問題時間もカネも限られていて
更に良い環境（顧客・会社etc）で仕事できる事なんて少なくて
結果的に要求定義がきちんとできない案件が
多くなりデスマってるだけ。
（俺自身も反省する事が多いが。。）
逆に顧客と内容についてとことん話し合えて
こっちと顧客の案件定義が限りなく一致した（近くなった）
なと感じる案件は経験上ウォータフォールでやろうが
なんでやろうがデスマんない。
こりゃデスマるな奴は案件が始める前から皆感じるし
それはその案件にかかわる人達が
XPを知らないからデスマるんじゃなくて
結局ちゃんと要求定義をしてないってのが問題で
（まあここが顧客がバカだったり、営業がからんだり
時間も金もなくて結局だあだあになったり
こっちが顧客の仕事を理解できてなくて
相手のニーズを誤解しちゃってたりetcで結果的にできないんだが。）
本当の意味での要求定義がきっちり決まればXPなんて必要ない
XPは要求定義がある程度きちんとできてるのが
前提の手法論でそこにあんまり触れないからズルいよ。
そこが難しくて皆苦労してんだよ！！
ウォータフォールの手法思想自体が悪いからではなく
ウォータフォールの思想が誤解されていて
悪い運用をされているからでもないと思う。
そんな小難しい手法論じゃなくて
ただ単に現実問題時間もカネも限られていて
更に良い環境（顧客・会社etc）で仕事できる事なんて少なくて
結果的に要求定義がきちんとできない案件が
多くなりデスマってるだけ。
（俺自身も反省する事が多いが。。）
逆に顧客と内容についてとことん話し合えて
こっちと顧客の案件定義が限りなく一致した（近くなった）
なと感じる案件は経験上ウォータフォールでやろうが
なんでやろうがデスマんない。
こりゃデスマるな奴は案件が始める前から皆感じるし
それはその案件にかかわる人達が
XPを知らないからデスマるんじゃなくて
結局ちゃんと要求定義をしてないってのが問題で
（まあここが顧客がバカだったり、営業がからんだり
時間も金もなくて結局だあだあになったり
こっちが顧客の仕事を理解できてなくて
相手のニーズを誤解しちゃってたりetcで結果的にできないんだが。）
本当の意味での要求定義がきっちり決まればXPなんて必要ない
XPは要求定義がある程度きちんとできてるのが
前提の手法論でそこにあんまり触れないからズルいよ。
そこが難しくて皆苦労してんだよ！！
>こりゃデスマるな奴は案件が始める前から皆感じる
いちお同意
感じていても止められない例が多いのがアレだな
>XPは要求定義がある程度きちんとできてるのが前提の手法論
マヂで？
いちお同意
感じていても止められない例が多いのがアレだな
>XPは要求定義がある程度きちんとできてるのが前提の手法論
マヂで？
958 ：仕様書無しさん：2005/03/28(月) 12:17:31
cppunit 使っている人いる？
NUnitです
>957
当たり前だろ。何をどのようにやるべきかがわからんアホがXPやって
うまくいくと思うのか？
当たり前だろ。何をどのようにやるべきかがわからんアホがXPやって
うまくいくと思うのか？
>960
ちとﾓﾁﾂｹ
何をどのようにやるべきかがわからんアホでもうまくいくのがXPだなんて言ってないよ。
>957は
>XPは要求定義がある程度きちんとできてるのが前提の手法論
に対しての疑問符。
ちとﾓﾁﾂｹ
何をどのようにやるべきかがわからんアホでもうまくいくのがXPだなんて言ってないよ。
>957は
>XPは要求定義がある程度きちんとできてるのが前提の手法論
に対しての疑問符。
馬鹿しかいないのか...
過疎
964 ：sage：2005/05/08(日) 19:02:51
・・・スレタイが問題かな
デファクトスタンダードを単に否定しているだけだしね
デファクトスタンダードを単に否定しているだけだしね
965 ：仕様書無しさん：2005/06/06(月) 06:11:02
XP本読んだ。
・・・・・・・・・・・なんか、理想論ばっかだな。これ。
条件も限定されすぎてて適用できるプロジェクトが限られてるのも痛い。
あんなの実現できるわきゃねーだろ。シネと。
・・・・・・・・・・・なんか、理想論ばっかだな。これ。
条件も限定されすぎてて適用できるプロジェクトが限られてるのも痛い。
あんなの実現できるわきゃねーだろ。シネと。
ペアプログラムの相手が口臭かったらどうするんじゃ！
銀玉はそうそう無いって事でつよ。
とりあえずテストを自動化することから始めてみたけど、
やっぱこりゃ良いわ……と思う日々。
変更しる！って言われてから変更後に正しく動いてると確証できるまでの時間が全然違う。
それに何よりこの安心感が良いや。
ところでXPの4つの価値の中で「勇気」だけがうまくイメージできないんだけど、
誰かXPerな人説明してくれまいかのぉ。
コミュニケーションとかシンプルとかは、
「どうするか迷ったらコレを基準にしろ」と考えると分かるんだけど。
（コミュニケーションを阻害しない方法を選べ、よりシンプルな方法を選べ、と）
勇気だけはなんかしっくりこない。
やっぱこりゃ良いわ……と思う日々。
変更しる！って言われてから変更後に正しく動いてると確証できるまでの時間が全然違う。
それに何よりこの安心感が良いや。
ところでXPの4つの価値の中で「勇気」だけがうまくイメージできないんだけど、
誰かXPerな人説明してくれまいかのぉ。
コミュニケーションとかシンプルとかは、
「どうするか迷ったらコレを基準にしろ」と考えると分かるんだけど。
（コミュニケーションを阻害しない方法を選べ、よりシンプルな方法を選べ、と）
勇気だけはなんかしっくりこない。
>>969
たとえば４人で開発をしているとする。
納期ギリギリだ。
一発でテストを通さねばならない。
しかし、これまでの例でいけばその確率は６０％！
ここで使うのが「勇気」だ。
４人の勇気で確率を１０％ずつアップさせる。
そうすれば確率１００％になる。
そして最終承認（検収）だ！
たとえば４人で開発をしているとする。
納期ギリギリだ。
一発でテストを通さねばならない。
しかし、これまでの例でいけばその確率は６０％！
ここで使うのが「勇気」だ。
４人の勇気で確率を１０％ずつアップさせる。
そうすれば確率１００％になる。
そして最終承認（検収）だ！
971 ：仕様書無しさん：2005/10/07(金) 23:11:41
さっさとウォータフォールを絶滅させて
新しいソフトウェア開発手法を普及させて欲しいな
新しいソフトウェア開発手法を普及させて欲しいな
開発期間は3ヶ月
基本仕様書を作るのに2ヶ月もかかった
もう間に合わないと思ったが
なんと
Ａ君がその基本仕様書を基に、いきなりテストデータを作り始めた
さらに
Ｂ君はそのテストデータを基に、詳細設計書を書き始めた
2週間で終わった
次に
Ａ君は詳細設計書とテストデータを基にテスト仕様書を書き
Ｂ君は詳細設計書とテストデータを基にプログラムを書いた
Ａ君はテスト仕様書を書き上げると
片っ端からＢ君のプログラムをテストした
バグがいっぱい出たが
その都度Ｂ君に報告し修正させた
これも2週間で終わった
最後に結合テストを行ったが
2時間しかかからなかった
バグが一つも出なかったのだ
なんとかギリギリ間に合った
基本仕様書を作るのに2ヶ月もかかった
もう間に合わないと思ったが
なんと
Ａ君がその基本仕様書を基に、いきなりテストデータを作り始めた
さらに
Ｂ君はそのテストデータを基に、詳細設計書を書き始めた
2週間で終わった
次に
Ａ君は詳細設計書とテストデータを基にテスト仕様書を書き
Ｂ君は詳細設計書とテストデータを基にプログラムを書いた
Ａ君はテスト仕様書を書き上げると
片っ端からＢ君のプログラムをテストした
バグがいっぱい出たが
その都度Ｂ君に報告し修正させた
これも2週間で終わった
最後に結合テストを行ったが
2時間しかかからなかった
バグが一つも出なかったのだ
なんとかギリギリ間に合った
なんと
Ａ君がその基本仕様書を基に、いきなりテストデータを作り始めた
さらに
Ｂ君はその基本仕様書とテストデータを基に、テストプログラムを書き始めた
Ｂ君はテストしながらプログラムも書いた
Ａ君も片っ端からＢ君のプログラムをテストした
バグがいっぱい出たが
その都度Ｂ君に報告し修正させた
Ｂ君はその報告を基に、テストプログラムを追加し、プログラムを修正した
次に結合テストを行ったが
2時間しかかからなかった
バグが一つも出なかったのだ
最後に
Ｂ君はそのプログラムとテストプログラムを基に、詳細設計書を書き
Ａ君はテストプログラムとテストデータを基にテスト仕様書を書き
テスト結果をまとめて
なんとかギリギリ間に合った
Ａ君がその基本仕様書を基に、いきなりテストデータを作り始めた
さらに
Ｂ君はその基本仕様書とテストデータを基に、テストプログラムを書き始めた
Ｂ君はテストしながらプログラムも書いた
Ａ君も片っ端からＢ君のプログラムをテストした
バグがいっぱい出たが
その都度Ｂ君に報告し修正させた
Ｂ君はその報告を基に、テストプログラムを追加し、プログラムを修正した
次に結合テストを行ったが
2時間しかかからなかった
バグが一つも出なかったのだ
最後に
Ｂ君はそのプログラムとテストプログラムを基に、詳細設計書を書き
Ａ君はテストプログラムとテストデータを基にテスト仕様書を書き
テスト結果をまとめて
なんとかギリギリ間に合った
>>973 と >>974 は別人かな。
テストデータからテスト仕様書を作るってのは
そのテスト仕様を「行き当たりばったり」でなくすることはとても難しそうだね。きっと
脳内テスト仕様→テストデータ→テスト仕様書
という順番で出来るのかな。
そして「プログラムとテストプログラムを基に、詳細設計書を書いたり」、
「テストプログラムとテストデータを基にテスト仕様書を書いたり」するのはとても退屈だな
テストデータからテスト仕様書を作るってのは
そのテスト仕様を「行き当たりばったり」でなくすることはとても難しそうだね。きっと
脳内テスト仕様→テストデータ→テスト仕様書
という順番で出来るのかな。
そして「プログラムとテストプログラムを基に、詳細設計書を書いたり」、
「テストプログラムとテストデータを基にテスト仕様書を書いたり」するのはとても退屈だな
納品物だから作らなきゃならナインだろ>詳細設計書&テスト仕様書、成績書
まぁ最近ならなるべく自動生成する方向で
まぁ最近ならなるべく自動生成する方向で
働きたくないだけﾀﾞﾛ
ｺﾉ給料ﾄﾞﾛﾎﾞｳ
ｺﾉ給料ﾄﾞﾛﾎﾞｳ
無駄なことをして「俺は働いている」と主張することを給料泥棒といいます。
979 ：仕様書無しさん：2005/11/12(土) 12:54:46
いきあたりばったりほど効率のいい開発方法は無いんだがな。
機会主義的プログラミング
使いもしない機能を羅列したり、共通で使う機能が載ってなかったりする
糞い仕様書に従うよりはよっぽどマシ。
機会主義的プログラミング
使いもしない機能を羅列したり、共通で使う機能が載ってなかったりする
糞い仕様書に従うよりはよっぽどマシ。
980 ：仕様書無しさん：2005/12/04(日) 00:45:32
とりあえずみんな
ロバート・Ｃ・マーティンの
「アジャイルソフトウェア開発の奥義」でも読もうぜ
ロバート・Ｃ・マーティンの
「アジャイルソフトウェア開発の奥義」でも読もうぜ
プログラマを交換可能な道具としか扱わないような会社しか
ない日本の風土(横並び主義、事なかれ主義等等)では、定着
しないだろうなと最近つくづく思いまふ。
でもって海外の、そのへんの抵抗力の少ない国にﾄﾞﾝﾄﾞﾝ先に
いかれて、最後に負けるのよね。あーあ。
ない日本の風土(横並び主義、事なかれ主義等等)では、定着
しないだろうなと最近つくづく思いまふ。
でもって海外の、そのへんの抵抗力の少ない国にﾄﾞﾝﾄﾞﾝ先に
いかれて、最後に負けるのよね。あーあ。
982 ：仕様書無しさん：2005/12/04(日) 10:14:58
行き当たりばったりでプログラム作れるPCDBフロントエンドだけにしてくれ。
そんなもの、車や電車や飛行機や工場生産設備や送変電や通信基幹部や
炊飯器やエアコンや掃除機やらにつかわれたらたまらん。
寝言言ってる案件はうまくいったのを見たことがない。
構造化以前の混沌界に戻るだけ。Linux厨がパラダイムを１９７０年代に
戻すことがあるようにな。
そんなもの、車や電車や飛行機や工場生産設備や送変電や通信基幹部や
炊飯器やエアコンや掃除機やらにつかわれたらたまらん。
寝言言ってる案件はうまくいったのを見たことがない。
構造化以前の混沌界に戻るだけ。Linux厨がパラダイムを１９７０年代に
戻すことがあるようにな。
983 ：仕様書無しさん：2005/12/04(日) 10:48:00
同じプロジェクトで
Ａ社のＡ君は仕様書を書き、製造、テストも請けた
Ｂ社のＢ君も仕様書を書いた、製造、テストは外注に任せた
しかし途中、Ｂ君とその会社は契約が切れたといって逃げ出した！しかも音信不通になった！
やむなくＡ君はＢ君の作業(製造、テスト)を引き継いだが
ソースを開けてびっくり！何も書かれてないジャナイカ！
やむなくＡ君はデスマって製造、テストを終わらせた。
当然、開発期間から足がでちゃってＡ君の会社の予算は真っ赤っ赤になったとさ
Ａ社のＡ君は仕様書を書き、製造、テストも請けた
Ｂ社のＢ君も仕様書を書いた、製造、テストは外注に任せた
しかし途中、Ｂ君とその会社は契約が切れたといって逃げ出した！しかも音信不通になった！
やむなくＡ君はＢ君の作業(製造、テスト)を引き継いだが
ソースを開けてびっくり！何も書かれてないジャナイカ！
やむなくＡ君はデスマって製造、テストを終わらせた。
当然、開発期間から足がでちゃってＡ君の会社の予算は真っ赤っ赤になったとさ
985 ：仕様書無しさん：2005/12/27(火) 10:31:10
XPなんてうちじゃむりぽ。。。
986 ：仕様書無しさん：2005/12/27(火) 11:28:13
最良な開発手法は
漏れの脳内設計を独自展開する。これだけ。
無駄はゼロ。だいたい馬鹿とフェーズをあわせる事ほど
疲れるものはない。
漏れの脳内設計を独自展開する。これだけ。
無駄はゼロ。だいたい馬鹿とフェーズをあわせる事ほど
疲れるものはない。
>やむなくＡ君はＢ君の作業(製造、テスト)を引き継いだが
何の金銭的or期間的追加も無しに、
状態不明の内容を引き継ぐ事が、まず間違い。
というか、普通そんな行動とらんだろ。ｗ
何の金銭的or期間的追加も無しに、
状態不明の内容を引き継ぐ事が、まず間違い。
というか、普通そんな行動とらんだろ。ｗ
989 ：( _ 。。) _ バタ。 ◆eJlUd9keO2 ：2005/12/28(水) 00:33:05
>>988
それって、例えば次の案件ネタも見込めるとか、
ある程度でかい元請けに対して、企業判断で「投資」としてやるなら解るけど。
>>984 見る限り、なんか個人が勝手に判断しているように読める。
その辺はどうなのさ？
それって、例えば次の案件ネタも見込めるとか、
ある程度でかい元請けに対して、企業判断で「投資」としてやるなら解るけど。
>>984 見る限り、なんか個人が勝手に判断しているように読める。
その辺はどうなのさ？
>>990
そうです。実は同じエンドユーザで次の案件がすでに持ち上がっていたので
Ａ社は対応せざるを得ない状況でした。全体を通してみれば売上はありますよ。
個人の勝手な判断かはご想像にお任せします。ですが決して誇張はしてません。
その件以降、Ｂ社が完全に発注停止になったことはいうまでもありません。
そうです。実は同じエンドユーザで次の案件がすでに持ち上がっていたので
Ａ社は対応せざるを得ない状況でした。全体を通してみれば売上はありますよ。
個人の勝手な判断かはご想像にお任せします。ですが決して誇張はしてません。
その件以降、Ｂ社が完全に発注停止になったことはいうまでもありません。
992 ：仕様書無しさん：2006/01/12(木) 22:56:59
おめこ
*
埋めようぜ。
次スレ立てるほどでもなさそうだし。
次スレ立てるほどでもなさそうだし。
梅原
うめうめ
うめ〜
うめっ？
1000 ：仕様書無しさん：2006/01/23(月) 14:58:39
1000ならXPｵﾜﾀ＼(^o^)／
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。