トップページtech
1001コメント432KB

【XP】 Agile Process 【UP】

■ このスレッドは過去ログ倉庫に格納されています
0001 NGNG
Agile関連の議論、情報交換、質問のために使って下さい。
XPスレと補い合う感じで役立てばいいなと思います。

関連スレ
・eXtreme Programming Part.3 (XPスレッド)
http://pc3.2ch.net/test/read.cgi/tech/1023709462/l50
・Agile Alliance にあるドキュメント集
http://www.agilealliance.org/home
・Wiki本家のAgile関連ページ
http://c2.com/cgi/like?AgileProcess
・Agile Modeling(お勧め)
http://www.agilemodeling.com/

なるべくマターリでおながいします。
0348デフォルトの名無しさんNGNG
>>347
常に最前の方法を模索はするね。
xp はリファクタリングやUnitTestがIDEに統合されつつあるのでその部分だけは恩恵にあずかれそう。
プロセスとしては色々なアジャイル系をミックスして試すのがベターかな。
0349デフォルトの名無しさんNGNG
【チンコのレス】

〓〓〓〓〓
 |〓|
 |〓|
 |〓|
 (⌒⌒)
  \/
  〓
 【チンコお守りレス】このお守りを見たあなたは超超超幸せ者!
2週間以内に必ず彼氏・彼女が出来るよ!
すでにいる人は超〜ラブラブ みんなが幸せになりますように…
そのかわりこのコピペを1時間以内に、5つ別のスレに貼り付けてね・・
でないと、あなたはインポや性病になります。
0350デフォルトの名無しさんNGNG
XPのプラクティスに追加希望。
否定派にはとりあえず「ああ、もっとも、そのとおりだね」と口では言っておく。
0351デフォルトの名無しさんNGNG
xpは有効なプラクティスだけど、なんでこれをわざわざ世間に
(Role Model Soft 社の人々は) 公開したのかね。

会社のノウハウとしてとっておけば、その会社は差別的優位性を
保てたんじゃないのかと。公開してその会社は一体どういう得を
するのかね。
0352デフォルトの名無しさんNGNG
>>351
なんつーか、資本主義の弊害的な話だな〜。

公開すればよりおおくの事例を集めて手法を強化できるし、発案者としての
名声で(講演とかコンサルとかで)食っていけるとかじゃないかね。
0353デフォルトの名無しさんNGNG
>>351
マジでそう言っているんだったらかなりおめでたい。
xp を公開したことにより信頼度、知名度を手に入れただろ。
それによって客の質も数も以前より増える。
当然、貰える額も変わってくるはずだ。

一流の会社はこぞって使おうとするだろうしその会社にとっても
宣伝になりエンドに安心を売ることが出来る。

>>352みたいな個人的なことだけじゃなく、会社としても相当潤う。
0354デフォルトの名無しさんNGNG
>>351
>(Role Model Soft 社の人々は) 公開したのかね。

これってケントベックが当時いた会社名ですか?
初めて聞いた
0355デフォルトの名無しさんNGNG
たとえば競馬予想ソフト。
本当に当たるなら自分で使えばいい。
ではなぜ当たる競馬予想ソフトを売るのか?
そこにカモがいるからだ。
0356デフォルトの名無しさんNGNG
このスレの住人もカモですか?
0357デフォルトの名無しさんNGNG
とりあえず今
「アジャイルソフトウェア開発スクラム」
読んでます
0358デフォルトの名無しさんNGNG
とりあえず今
「アジャイルソフトウェア開発エコシステム」
読んでます

字ばっかし
0359デフォルトの名無しさんNGNG
アジャイルって、ろくな開発方法手法もなく、設計もせず
でたらめな開発している人たちに免罪符を与えただけの
ような気がします。

でたらめ、似非アジャイルと正しくアジャイルを適用している
プロジェクトを区別する方法を教えていただけませんか?
0360デフォルトの名無しさんNGNG
>>359
アジャイルソフトウェア宣言で示している4つの価値を重視しているかで
区別できるのではないですか?4つの価値とは以下のとおりです。
・個人と相互作用
・動作するソフトウェア
・ユーザとの協調
・変化への対応
ちなみに、これらと比較して価値が小さくなるものとして以下が挙げられています。
・プロセスやツール
・包括的なドキュメント
・契約交渉
・計画に従うこと

つまり、プロセスやツールを軽量にし、包括的なドキュメントを残さず、
詳細で長期的な契約交渉を行わず、当初の計画から外れた開発を
しているうえに、
個人の相互作用が少なく、動作するソフトウェアがなかなか生まれず、
ユーザとの協調もなおざりで、変化への対応力に乏しい
ような開発をしている場合は、似非アジャイルと呼んでいいと思います。

アジャイル開発=手法なし、設計なし、管理なしじゃないんですけどね。
例えばXPなら重い規律をメンバーに課しています。
0361360NGNG
>>360
s/アジャイルソフトウェア宣言/アジャイルソフトウェア開発宣言/
0362デフォルトの名無しさんNGNG
>>360
>つまり、プロセスやツールを軽量にし、包括的なドキュメントを残さず、
>詳細で長期的な契約交渉を行わず、当初の計画から外れた開発を
>しているうえに、

ここまでは今のプロジェクトがそうです。でも、

>個人の相互作用が少なく、

はどういうことかわからないんですけど、

>動作するソフトウェアがなかなか生まれず、

ユーザーと協調するために、週に2回は動作するアプリのリリース
を要求されています。

>ユーザとの協調もなおざりで、

ユーザーとの協調が第一です。

>変化への対応力に乏しい

変化に対応するのはPGたちの徹夜に頼っていますがそろそれ限界です。

>ような開発をしている場合は、似非アジャイルと呼んでいいと思います。

どうなんでしょうか?半分アジャイルなんですけど、こんな状態を推奨するのが今の最先端なんですか?やっぱり単なる現状追認にそれっぽい名前与えただけみたいなんですけど。

設計なし、ドキュメントなし、管理なし(あしたまでにリリースだそれいけやれいけって管理ならありますけど)で、これだと破たんするって言うと、いやアジャイル開発ではこういうやりかたでやることを推奨しているんです。って言われて反論できません。

なんでこんな状態でよいソフトウエアが生まれ、開発者がハッピーになれるのか疑問です。
0363デフォルトの名無しさんNGNG
http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200211.month/3289.html
0364デフォルトの名無しさんNGNG
>>363

読みました。ありがとうございます。ここでやはり疑問があります。

アジャイル開発過程では、包括的なドキュメント作成は重視されない
とありますが、それでは、

顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか?
あるいは、それを設計者にどのように伝えるのでしょうか?
そして、設計結果が顧客の仕様を満たしているかどうかをどのように
判断するのでしょうか?

設計者の設計内容をどのように実装者につたえるのでしょうか?
そして、どのようにその実装結果を検証(試験)するのでしょうか?

他にも疑問は多々有り、アジャイル開発を行うことは結局実装者の
負担を増大させるばかりか、過去においてはそれが管理者等の混乱
によるものであるとみなされていたものが、現代ではアジャイル開発
でやっているからで正しいことなのであるという免罪符になっている
のではないか思っています。

そして、アジャイル開発であってなお、実装者の負担減につながる
方法を知りたいと切実に求めています。
0365デフォルトの名無しさんNGNG
>顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか?
>あるいは、それを設計者にどのように伝えるのでしょうか?

口頭、図、文章などを用いたインタビューによって。

>そして、設計結果が顧客の仕様を満たしているかどうかをどのように
>判断するのでしょうか?

XPの場合は、受け入れテストによって。顧客が作れれば最高ですが、
まずありえないので、顧客の言葉をテストに翻訳して顧客と確認する、
ということになるでしょう。

>設計者の設計内容をどのように実装者につたえるのでしょうか?
>そして、どのようにその実装結果を検証(試験)するのでしょうか?

設計者と実装者を分けている段階で、アジャイルでは無いと思われ。
実装結果を検証(試験)は、さっき作った受け入れテストと、顧客への
リリースによるフィードバックでしょうね。

>によるものであるとみなされていたものが、現代ではアジャイル開発
>でやっているからで正しいことなのであるという免罪符になっている
>のではないか思っています。

『現代では』というのが拡大しすぎだと思いますが、少なくともあなたの
会社では免罪符として用いているだけだと思います。
そして、その原因の一つが、実装者であるあなた達が、自分が強制され
ていると感じているプロセス(アジャイル)の文献すら一切調べていない
ことにあるでしょう。
ちょっと関連書籍を読んでみれば、今やっているのが実はアジャイルで
ないのは明らかなはずです。
0366デフォルトの名無しさんNGNG
>顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか?
>あるいは、それを設計者にどのように伝えるのでしょうか?
>そして、設計結果が顧客の仕様を満たしているかどうかをどのように
>判断するのでしょうか?

ドキュメント書いて、レビューやれば良いじゃん。
だれか駄目って言ってんの?
だけど、包括性にこだわり過ぎるのは良くないかもね。
そんな感じ。わかった?
0367デフォルトの名無しさんNGNG
>>366
>ドキュメント書いて、レビューやれば良いじゃん。
>だれか駄目って言ってんの?

プロマネ兼SE。

仕様書ないから、プログラム作れないって言ったら。
最初に説明してある。作れないはずはないって言われた。
0368デフォルトの名無しさんNGNG
>>365
>そして、その原因の一つが、実装者であるあなた達が、自分が強制され
>ていると感じているプロセス(アジャイル)の文献すら一切調べていない
>ことにあるでしょう。

そんなヒマありません。アジャイルプロセスでは毎日毎日地獄のような
納期に追われて、睡眠時間を削るだけです。
0369デフォルトの名無しさんNGNG
何かさ、むちゃくちゃな調理法をしてるのに
「この飯がまずいのは素材が腐ってるからだ」
って言ってるようなものだよね
0370デフォルトの名無しさんNGNG
368です。365さん、ごめんなさい。
こんなことは365さんに言うべきではないですね。せっかく親切に教えて
下さっているのに。いうべきとしたらこの方法を採用したPMになんです
けど、こうしてもらえないと開発できないと言ったらアジャイルではそう
いうやりかたはやらないと言われて、アジャイルなんてその言葉しかしら
なかったものですから、なんの反論もできず、困ってしまったのです。
それでみなさんに助けてもらって、そんなのアジャイルじゃないのに自分
の都合のいいところだけアジャイルだって言われても開発できないよって
反論したかったのです。

でも、せっかくですから、少しは勉強したいのですが、1冊だけでざっと
すぐに読めるような解説書はなにかありますでしょうか?金曜日には本屋
の開いている時間に都心に出ることができるはずなので、一冊購入してこ
ようと思います。

よろしくお願いします。
0371365NGNG
>>368
>そんなヒマありません。アジャイルプロセスでは毎日毎日地獄のような
>納期に追われて、睡眠時間を削るだけです。

だから、それはアジャイルじゃないですって。

>>370
本当に本屋に行く時間もなくて、2chする時間はあるってなら、
ここで得られる情報でも十分じゃないの?
http://objectclub.esm.co.jp/eXtremeProgramming/

それよりも、
>アジャイルなんてその言葉しかしら
>なかったものですから、なんの反論もできず、困ってしまったのです。

よく知らない方法論の名前を出されただけで反論できないんじゃ、
これから先も同じ事繰り返すだけだと思うけど。
次は「Lyeeではこうする」って言われそう。
0372デフォルトの名無しさんNGNG
362のプロジェクトがデスマってるのと、
用いてるプロセスがアジャイルかどうかっていう点との
因果関係が薄いような気がするんですけどね。
362のPMが仕切ったら、ウォータフォールでもデスマになると思う。
ウォータフォールで宿命的に発生する「予想外の」手戻りが原因で。

0373デフォルトの名無しさんNGNG
>>372
>ウォータフォールで宿命的に発生する「予想外の」手戻りが原因で。

日々、変わってゆくお客さまのご要望をシステムに取り入れるため
アジャイルでないと対応してゆけないのだそうですので、
はじめからウォーターフォールは無理だそうです。
0374デフォルトの名無しさんNGNG
>>371
>本当に本屋に行く時間もなくて、2chする時間はあるってなら、
>ここで得られる情報でも十分じゃないの?
>http://objectclub.esm.co.jp/eXtremeProgramming/

週に一回くらいは打合せのため本屋のある都心を経由するので
本屋に行く時間はあります。でもいつでもアクセスできるわけでは
ありません。

ということでご紹介いただいたサイトを見させていただきます。
0375デフォルトの名無しさんNGNG
>>373
いや、あなたのPMが仕切ったらどういう方法論でもデスマになると言っているんですが。
わかりにくいかもしれませんが、ウォータフォールは一例としてあげただけです。
0376デフォルトの名無しさんNGNG
>>371
>次は「Lyeeではこうする」って言われそう。
禿ワラタw

>>374
雑誌の特集なんかも手軽で良いかもしれない。このスレだと>>5
のJavaWorldのバックナンバーとか。2002年11月号か。一年も
昔のやつですまんが。ちょっと気持ち悪い煽り記事だけど、我慢して
読むととりあえず概要が掴めるし、キーワードも拾えると思う。

そんで用語、術語に少し馴染んだら、次はやはり定番のGoogleかな。
>>1とかにあるリンクでも良いし。ネットだけでもかなり情報あるよ。
そんで何となく分かった気になってきたら、好きなプロセスを選んで、
解説本なんかを買ってみるのも良いかも。

ちなみに入門用としてはXPは実は余り向いてない気がするんだがね。
やはり素人にはお勧めできないというか。どうせ中堅以上の技術者には
浮ついた流行に見えるだろうし、厨房には刺激が強過ぎるし。

まあデスマーチもいつかは終わるし、がんがれね。

# >>371氏のリンクに「設計の終焉?」ってあるけど、それ面白いよ。
0377デフォルトの名無しさんNGNG
>>360

>・動作するソフトウェア
を重視するけど

>・プロセスやツール
は重視しないってのはやっぱり嘘っぽい。

昔、友人と面白い映画はどうすれば作れる勝手言うのを
議論したことがある。色々話をした後で最後になって一人が
「そういう設定とかにこだわる必要ないんじゃないのかな。
べつにそういうことやらなくても面白い映画は面白いんだから
結局面白い映画を作ればそれが面白いんだよ」って。

確かにそれは事実だが、だからその面白い映画をどうすれば
作れるかを議論していたのだ。この結論ではどうすれば面白
映画を作れるのか結局わからないってことになる。

動作するソフトウエアを作ることが目的で、そのために有効な
プロセスやツールを探している人に対して、「プロセスやツール
は重要ではない。結局動作するソフトウエアを作ることが大切だ」
なんて言っても何の助けにもならない。
0378デフォルトの名無しさんNGNG
[Agile ソフトウェア開発宣言]

我々は、自ら Agile 開発を実践するとともに、
人々が Agile 開発を実践するための支援を通じて、
より優れたソフトウェア開発方法を見つけようとしている。

この活動を通じて、我々は、

人と人同士の相互作用を、プロセスやツールよりも
動くソフトウェアを、包括的なドキュメントよりも
顧客との協力を、契約交渉よりも
変化に対応することを、計画に従うことよりも

尊重するに至った。

これは、右側にある項目の価値を認めつつも、
左側にある項目の価値をより一層重視する、ということである。
0379デフォルトの名無しさんNGNG
>>378
>より優れたソフトウェア開発方法を見つけようとしている。

見つかったら教えてくれよな。

Agileっていう、優れたソフトウエア開発方法論があるわけではないわけだ。

0380デフォルトの名無しさんNGNG
>>372
それなら、別にアジャイルである必要はないのでは。
反復型ならわかるんだが。
0381デフォルトの名無しさんNGNG
>>379
agile はメタプロセスだからね
0382デフォルトの名無しさんNGNG
>>379
優れた方法論はない。
「メリット・デメリットが異なる方法論」が
たくさんできるだけ。

あとはケースバイケース(期間・人数・関係者のスキル等)で
好きな奴を選べ。

とりあえず仲間とXPやってみましたが、
「滝モデルとは別の意味で効率悪そ〜」というのが感想です。
0383デフォルトの名無しさんNGNG
>>382
> 「滝モデルとは別の意味で効率悪そ〜」というのが感想です。
濁さないで詳しくお願いします。
ついでに滝モデル利点の方も。
0384デフォルトの名無しさんNGNG
UPとRUPのちがいってなんですか?(ラショナルが考えたUPとかのレベルでなく)
0385HomaNGNG
ゔ〲〰ゔ〲〰乜勹〰ス
0386デフォルトの名無しさんNGNG
>>384
同じものでしょ。
0387デフォルトの名無しさんNGNG
では、スパイラル開発と反復型開発は?
0388デフォルトの名無しさんNGNG
>>387

http://www.atmarkit.co.jp/fjava/devs/process01/process01.html
0389デフォルトの名無しさんNGNG
で結局 382 は 383 の質問から逃げたわけ?
0390382NGNG
XPだとコードを書けない状況にされてしまう。
テストだ〜。リファクタリングだ〜。て感じで。

それが手戻りを楽にするためなのは
わかってるんだけど、
「どれだけ利用するかわからない傷害保険に
 強制的にはいらされてる気分。」
というと心情が伝わるかな?

あとペアプロでパートナーと意見を合わせるのが
かなり大変。新人とか全然違うチームの人が
ペアだと自分の考えを説明するだけで疲れる。

なのでXPをいきなり製品開発に試しても
・たぶん失敗してRUPに変えるか
・多残業するか
どっちかなんだろーな。と思った。
0391デフォルトの名無しさんNGNG
テストもリファクタリングもコード書きなんだがなあ。
やってみればわかるけど効果も明らかだし。
0392382NGNG
滝モデルの利点は
素人にわかりやすい事

導入時の難しさで比較すると
XP>縛りのキツイ滝>縛りのゆる〜い滝≒開発プロセスがない

今は小さいグループなのでゆる〜い滝でやってるんですが
そこでいきなりXPを実践するのは難しかった

逆に「ドキュメント駆動の厳しい滝モデル」でやってる人達のほうが
XPをやりやすいと思います。
0393デフォルトの名無しさんNGNG
ごめん訂正
話し合いで時間を浪費する割合が多かった

・MVCにするにはどっちのクラス構成がいいか
・テストしやすい作りはどっちかなのか
・なぜテストをするのか
・なぜリファクタリングをするのか

といった感じで毎回ペアで話あってた
0394デフォルトの名無しさんNGNG
それは単に新しいことをやったので、それに慣れるための時間がかかったということでは。
現状維持以外の何をやるにしてもそのコストは必要かと。
0395デフォルトの名無しさんNGNG
そりゃイニシャルコストは何する時にもあるし実際に382がXPだと思ってやっていたことも不慣れだから
効率の悪いテストやしなくて良いリファクタリングをしている可能性もあるわけでそれを持ってしてXPをかって
に納得して判断下されても。

382の言っているXPのデメリットには何一つ納得できる物はないよ。
せめて324位のことは言ってくれ。
0396デフォルトの名無しさんNGNG
ペアプロもうやだ…
0397デフォルトの名無しさんNGNG
>>390
「感じ」だとか「心情」だとか漠然としすぎて、それじゃ単なるボヤキの
域を出ないでしょう。
と言うか、どうもよく理解しないまま幾つかのプラクティスをいい加減に
適用したふりをして、XPをやった事にしただけのように読めちゃう。
「XPやりました」って言いたかっただけと違うのかと。

>あとペアプロでパートナーと意見を合わせるのが
>かなり大変。新人とか全然違うチームの人が
>ペアだと自分の考えを説明するだけで疲れる。

チーム内のメンバと意見を合わせるのが大変、疲れるというのを
理由にXPが失敗するというなら、じゃあ他のプロセスなら容易なのか
(或は逆に、意識合わせを端から度外視してるのか)といった疑問
が湧く。
CommunicationはExtremeValuesの筆頭でもあるはずなのに、それが
大変だからといってペアプロ批判するのは、最初から何か意識が
ズレていると言うか、分かってないように見える。
0398デフォルトの名無しさんNGNG
(続)
>なのでXPをいきなり製品開発に試しても

「いきなり」試そうとしてるのは>>390氏の勝手であって、XP自体とは
関係ないでしょうな。何事も実績や経験が足りない事は段階的で
控えめなアプローチが望ましいでしょう。

>・たぶん失敗してRUPに変えるか

失敗したXPを途中でRUPに切り換えるって適切?てか、できるの?

>・多残業するか

プロジェクト開始前に多残業って言えるのは、そういうスケジュールを
組んでいるからでは。始める前にそんな事を言う位なら、あらかじめ
その分見積もって日程を考えるべきでしょう。

それともエンドも要員も固定のプロジェクトで、XPだけが多残業を
もたらすと言ってるのかな?だとすると総工数でXPがRUPや
ウォーターフォールを上回ることになるけど、そうなの?
0399デフォルトの名無しさんNGNG
>>393

どの部分への訂正か分からないけど、

>話し合いで時間を浪費する割合が多かった

>・MVCにするにはどっちのクラス構成がいいか
>・テストしやすい作りはどっちかなのか

こういうのを時間の浪費と言うだろうか。
ベターな設計にするためにはどのみち対話が必要だろうし、書いた本人
以外は障害発生まで誰もソースを読まないような状況を避けられるし、
むしろ必要な話し合いだと思うけど。

それとも設計書を書いてレビュー、書き直して再レビュー、承認後に
設計書をクローズしてコーディング着手、書いたらソースレビュー
といった手順の方が能率的と言いたいですか?

>・なぜテストをするのか
>・なぜリファクタリングをするのか

これは事前に意識合わせしておくべき事で、ペアプロ中に蒸し返す
話題ではないでしょうな。
0400デフォルトの名無しさんNGNG
>>390
思うようにコードかけないのはまだ自分の設計能力やコーディング力が足りないから。
また、ペアプロが大変なのはしょうがない。あれは疲れる。
ただしペアを組んで同時にコードを記述することによる利点(品質、教育など)は長期的に見てプロジェクトに貢献することは間違いない。

あと話は変わるが、ペアプロの利点で品質の向上をあげる人が多いけれども、プロジェクトの人員の入れ替わりに対応する
リスクヘッジみたいなところがマネジメント的にはもっと重要な利点だと思う。
連続徹夜で一人や二人が氏んでもプロジェクトが続行できるから。
0401デフォルトの名無しさんNGNG
実際にXPの壁となるのは「契約」と「環境」
中小企業にはツラい。
0402デフォルトの名無しさんNGNG
XPの実践に不可欠なものがあると感じている。それはカリスマプログラマだ。
それもプログラマから見たカリスマではなくて、顧客から見たカリスマね。

要するに、Kentあたりだから契約だ環境だ何だというようなことも、顧客が
言うことを聞いてくれるような気がする。根本的に彼らはXP以前から比較的
良質な顧客を捕まえてこれる状態にあったことが大きいのではないかと
思うんだよな。これをカリスマ不在のところがやろうとしたら、会社の看板か
体力が必要ということになる気がする。ところがそういう会社は組織の弊害に
囚われていてXPの導入なんて無理ってことになるんだろう。

何というか、XP導入以前にプログラマとしてすごい連中の集まりにならないと
いかんというニワトリタマゴな話になってしまう気がしているんだよな・・。
0403デフォルトの名無しさんNGNG
有名じゃないけどちゃんとXPやってる人知ってるよ?

心配する気持ちも分かるけど、そんなことないと思う。
職業人として信頼できる人間なら、別にカリスマ性は要らないでしょ。
0404デフォルトの名無しさんNGNG
>>403
402はおそらくネタでしょ。
しかし、XPの契約はなかなか難しいのも事実。
そのXPをやっている人はかなり特殊だとおもう。
「信頼」を会社の大きさで見るところが多いからね。
あと、顧客としては勘定がすぐに出ない契約は稟議が通りにくいという面があるから嫌がられる。

環境の方はまぁどうにもならないだろうね。
会社の上の人間や会社・部署の体質が全てを決めてしまうから。
入札が複数あったりする場合、営業は無理なスケジューリングで無理矢理取ろうとしたり
人員配分が無茶苦茶だったり、ISOでドキュメント死ぬほど書くような決め事がしてあったり・・・
そこまで酷くなくても大小なにかと問題があって実践が難しい。

日本という土壌にどうも微妙にかみ合わない。
出来るところだけ切り取って使うのがうまいXPの活用法かも。
とりあえず、上記に左右されないテストとリファクタリングから入っていくしかないね。
0405デフォルトの名無しさんNGNG
XPはデスマーチの入り口
0406デフォルトの名無しさんNGNG
ウォータフォールや非オブジェクト指向開発と比べればデスマーチに遭遇する確率、
デスマーチタイムにかかっている期間も短い。
0407デフォルトの名無しさんNGNG
>連続徹夜で一人や二人が氏んでもプロジェクトが続行できるから。

連続徹夜でペアプロって・・・、おっそろしいなあ。

例えば、思った通りの進捗が無くて焦った初心者XPチームが、
XPが重荷になってきて「仕方なく」何かのプラクティスを反古に
するとしたら、たぶんSustainablePace辺りが最初に捨てられそう。
そうなってくると泊り込みでペアプロとかあり得るわけか・・・
死なないまでも、各メンバの疲弊した脳内に予期せぬ感情が芽生え
たりはするかもな。
0408デフォルトの名無しさんNGNG
>>407
>死なないまでも、各メンバの疲弊した脳内に予期せぬ感情が芽生え
>たりはするかもな。

そして、二人のめくるめく夜が始まる。
0409デフォルトの名無しさんNGNG
会社でXPかRUPの開発方法試したいんだけど、みんな知らないか本で勉強中って程度
なんです。
皆さんどういう風に会社(またはチーム)に開発方法を浸透させていくんですか?
0410デフォルトの名無しさんNGNG
無理矢理型に嵌めるしかないだろう
0411デフォルトの名無しさんNGNG
何を始めるにもトップに立って先導する人間がいない限りダメ。
新しいプロセスを持ち込みたいならキミが勉強してある程度理解してから引っ張っていけ。
そういう立場にいないならそういう立場の人間を説得しろ。
0412デフォルトの名無しさんNGNG
とりあえず409は
ピアソンのXPシリーズを全巻熟読しろ
話はそれからだ。
0413デフォルトの名無しさんNGNG
>>409
XPとかRUPって正反対のように見えて、high-disciplineって事と
iterative and incrementalって事の二つの大きな共通点があるね。
high-disciplineは何とかなるかもしれないけど、I&Iはどうだろう?
まだまだiterativeどころかincrementalですらない案件も多いだろうしさ。

当たり前だけど、開発部隊の外部、特に顧客関係のマネージメントや
契約形態について権限をもってる人達との協調は必須でしょう。
契約以前の段階で、見積書とか作業計画表とかがウォータフォール
前提になってる場合、後から反復型にすると話が違うって事になるしさ。

とりあえず営業担当者に、ウォーターフォール型のプロセスが唯一の
選択肢って訳じゃない事を認知してもらうのが最初だろうね。
話はそれからかな。
0414デフォルトの名無しさんNGNG
>>414
確かに顧客の理解なしにやるのはSE失格だね。
0415デフォルトの名無しさんNGNG
●●●マスコミの 「盗聴/盗撮」 は許されるの?その6●●●    http://natto.2ch.net/mass/kako/1000/10003/1000393251.html
783 名前: 郵便屋 投稿日: 01/10/12 07:22 ID:eqc3p.xc
>だからさー、ドラマや小説のネタにして誰にどういうメリットがあるの?

メリットがあるかないか、というより、嫌がらせや脅しが目的だろ。
嫉妬や妬みのようなくだらない理由で嫌がらせする人っていっぱいいるよ。
普通はありえないと思うだろうけど。
変な不祥事が連発しておこることが事件に取り上げられてるけど。
世の中くだらない個人的感情で仕事をする馬鹿な人がいっぱい、いるんだろうと思う。

969 名前: 文責:名無しさん 投稿日: 01/11/04 13:30 ID:nZuvB+Z1
>>951
関係者というのは、盗聴された私と親しい間柄にある人や、知人のことです。
たとえば家族とか、電話で話した人、家で話題にした人、友人等です。
家族が知人と電話で話した内容がネタになった事があったり、知人の名前が
ドラマに使われたりします。

970 名前: 967 投稿日: 01/11/04 13:52 ID:v3mAO06V
>>969
あるね。最低だな。最近じゃ不治てれびとか。業界内の遊び感覚でやってると思うね。
0416デフォルトの名無しさんNGNG
>>412
ピアソンshineハケーン
0417デフォルトの名無しさんNGNG
>>414
再帰を理解できずにやるのはSE失格ってことでつか?
0418デフォルトの名無しさんNGNG
Fine scale feedback
 1. TestDrivenDevelopment
 2. PlanningGame
 3. WholeTeam
 4. PairProgramming
Continuous process rather than batch
 5. ContinuousIntegration
 6. DesignImprovement
 7. SmallReleases
Shared understanding
 8. SimpleDesign
 9. SystemMetaphor
 10. CollectiveCodeOwnership
 11. CodingStandard
Programmer welfare
 12. SustainablePace
0419デフォルトの名無しさんNGNG
板違いすれ違いだったらごめんなさい

よく「人月で計算するのはよくない」とききますが、ではどういう風に見積もるんですか?
0420デフォルトの名無しさんNGNG
匹月
0421デフォルトの名無しさんNGNG
>>420
ありがとうございます。ちなみに「匹」は犬でしょうか?
0422デフォルトの名無しさんNGNG
>>419
見積もりなんか人月で良いんじゃね?別に。
ユースケース一個につきいくらとか、どうせできる訳ないし。
つか怒られるじゃん。

人月で困るのは、管理だろ。
0423デフォルトの名無しさんNGNG
Function Point
0424デフォルトの名無しさんNGNG
おまえら、工数の見積もり技術ないのかよ...。
人に頼るな。

あとプロセスの設計というのも忘れるな。
だからレビューが大事なんだぞ。
0425デフォルトの名無しさんNGNG
>>424
どうやって勉強するの?良い本でもあればしえてくれよ
0426デフォルトの名無しさんNGNG
>>419

人月で表すのは別に悪くないが、人月は足し算できないから計算できない。
例えば、1人月の作業と、2人月の作業を合わせても3人月になるかどうかは
それぞれの作業の内容と「人」を誰にするかによる。
逆に言えば、1人月+2人月=3人月になるように作業を分割して人を割り振って
いれば、人月で計算しても構わない。
0427デフォルトの名無しさんNGNG
Function Pointは実際有効なのかな
0428デフォルトの名無しさんNGNG
>>425
勉強するんじゃないんだよ。
製造プロセスがどれだけ時間がかかるか精度良く調査しておくんだよ。
だから、先回りしておくんだよ。

0429デフォルトの名無しさんNGNG
因みに、開発/研究/未踏案件と製造案件は別にして考えてくれ。

ファンクションポイントもいいけどユースケースからでも算出できるだろ。
精度良くやれば。
0430デフォルトの名無しさんNGNG
>>428
勉強はいるだろ。
とりあえずFPの本でもよめば?

あとは、データを蓄えて、予測。
精度が高いデータである必要はない。
精度が高いデータをとるのは工数がかかるからな。
必要な精度で。

という意味では428の精度が「良い」という表現がいいな。
0431デフォルトの名無しさんNGNG
>>427
システムが複雑で無いなら有効
複雑なら、非線形で必要工数が増えていくので無効
0432デフォルトの名無しさんNGNG
人月以外の単位か・・・
予想総成果物の文字数なんかが、客観的で良さげだな。
あと文字数から打鍵数を割り出して、キーダウン一回の
平均エネルギーを掛けたら、ジュールとか使えちゃうな。
うわ、なんか我ながら凄え科学的。
カコイイ、俺。
0433デフォルトの名無しさんNGNG
さりげなく答えたつもりが誰も反応してくれない可哀想な>>423
0434デフォルトの名無しさんNGNG
ファンクションポイントについて素人向けに簡潔に説明してくれ
0435デフォルトの名無しさんNGNG
>>434
機能ごとにポイントをつけて、その合計で見積もる方法。

参照系は3ポイントで5画面=15ポイント
更新系は10ポイントで3画面=30ポイント
あわせて45ポイントで、1ポイント10万円として450万円とか見積もる。
0436デフォルトの名無しさんNGNG
>>435
計算しやすそう。
だけどそれはボリ杉じゃないの?
0437デフォルトの名無しさんNGNG
>>435
人月と本質的にどう違うのか、よく分からない。
尺貫法とメートル法みたいに、単位だけの違い?
てかそもそも、あまり変わらないって事の説明なんだろうか。
あと、そのポイントって四則演算が適用できるのかな。
0438デフォルトの名無しさんNGNG
>>437
人月は見積もりの結果で、FP法はそれを出す根拠を
ざっくり体系化したものじゃないかな。
0439435NGNG
>>436
ぼり杉かどうかは、作るものによって違うでしょ。
1ポイントがいくらになっても構わない。
画面がどういう単位かもわからないわけだし。

>>437
線形かってこと?
過去のデータに近い規模であれば線形とみなせる、ってことじゃないのかな。
どんな見積もり方法も、過去のデータと近い内容・規模であることが前提だと思う。

人月は単位であって、方法論ではないからね。
0440デフォルトの名無しさんNGNG
どっちにせよ経験則から適当に出すだけで、根拠は頭の中にしかないけれど、
数値や式があるとそれっぽく見えて読んだ方もなんとなく納得できるってことかと。
0441デフォルトの名無しさんNGNG
>>435
帳票系は何ポイント?
0442デフォルトの名無しさんNGNG
>>439
>線形かってこと?

ポイントと人月が、係数一個で交換可能な単なる比例なら、あるファンクションを
評価するのに最初から人月を単位としても結局同じだろうと思った。つまり
>>419(俺じゃないけど)の問いには、「FP法を使うなら人月でもOK」って言えると。

ただ、ちょっとググってみたら、言語にも環境にも依存しないって謳ってる
のが分かった。そもそも抽象度が違うって事で自己解決したよ。
0443デフォルトの名無しさんNGNG
見つけたんで、ついでに貼っとくか。

『Dr.ユースケースの “ユースケース人生相談”
ファンクションポイントとユースケースには
どんな関係があるんですか? 』
http://www.atmarkit.co.jp/fjava/devs/redge10/redge10.html

タイトルはふざけてるけど、中身はまとも。てか、やや難解。
0444435NGNG
計算結果が人月になるのはかまわないが、人月で計算するのはよくない。
0445435NGNG
ひさしぶりにFPの本手に取ったけど、直接的には見積もりの方法ではなくて、機能性の計測のための方法論のようだ。
0446デフォルトの名無しさんNGNG
>>444
御意。
人月の扱いの難しいところは、一旦人月に換算したら、
その人月を逆に変換してはいけないところでしょう。
人月の単位に落とした時点で、対象の複雑性や依存性等の
情報が抜け落ちてしまうから。
まあ、そういう情報を抜いて、単純に表せるのが人月の良い所
なんだけど。
0447435NGNG
>>446
結局人月というのは、金額の単位なんだよね。
■ このスレッドは過去ログ倉庫に格納されています