【XP】Agile Process 第2イテレーション【UP】

>>9
> それよりソフトウェア技術全般でスレ建てた方が話が広がって、しかも閑散としなくて良いだろ
そんな板あったのか…

ペアプログラミング・・。
確かに黙々とキーボードの音しかしない職場より、
ペアプログラミングでコミニュケーションがある方がよいとは思うが、
自分がコードしているときに傍からあれこれ言われるのはゴメンだ。
テスト時に試験官が背後から見ているのと一緒でさ。

>>15
コードレビューで後からまとめて言われるのと
どっちがいいかってとこだね。

後から言われる方がいいね。
あれこれいうのって逆に能率落ちるんだよね。
雑談になったりする場合もあるし。

プログラムが創造的な作業だという前提でペアプロ提唱されてるんだけど、ほとんどの部分って単純作業なんだよねぇ。

えー、設計しながらやるから単純作業ではないなー

プログラミングは単調な作業だ、って言っているヤシはコーダ。

>ペアプログラミング・・。
>確かに黙々とキーボードの音しかしない職場より、
>ペアプログラミングでコミニュケーションがある方がよいとは思うが、
>自分がコードしているときに傍からあれこれ言われるのはゴメンだ。
>テスト時に試験官が背後から見ているのと一緒でさ。

ペアプロを「試験管と受験者」のメタファで表すのは、ペアプロ勘違いしてる証拠だと思う。

どちらかと言えば、「ふたりの受験者、一本のペン」の方が正しい。問題は二人で相談しながら
解くが、解答(コード)を書き込むのはペン(キーボード)を持っているほうだけ、みたいな。

"the Planning Game" の Game って、どういうニュアンス？
「遊び」じゃないよね？

計画かな

それはPlanningの方だろｗ

>>22
実施

計画ゲーム
人生ゲーム
家族ゲーム

明るい家族計画

>>22
Game Planning みたいなニュアンスだろ

方針, もくろみ

人気ないね、XP
一度経験してみたいのに

俺と や ら な い か。

か リ よ レ ぁ ラ

熊とワルツを！

ところでみんなはXPlannerとか使ってる?

XP用の椅子
ttp://www.cenqua.com/pairon/

・・・新しい考え方で仕事をするのはとても難しい。
メンバーではなく上司や顧客の教育のほうが厄介だ。
PM自ら新しい考え方で仕事をしようとしても、PMの権限は充分にあるのだろうか

まさーるさんがお亡くなりになってしまいましたね。
オレ、まさーるさんのサイト見ながら泣いちゃったよ。偉大な方を失ってしまったって。

Agile とか XP って、要求仕様作成も少しずつ完成させていくの？

XPでは、ホワイトボードにカードを貼って、適宜更新しながら仕事を進めていく形を取る。
計画ゲームは、「探検」、「コミット」、「運転」という三つの局面からなり、ユーザーと開発者の両者が参加する。
ユーザーは、「ストーリー・カード」にシステムを使ってやりたいこと、知りたいことを書く。
要求はできるだけ多く出す。
開発者側は、各カードについて、その要求を満たす機能を実現するためにはどの程度の工数（日数）が必要とされるかを見積もる。
ユーザーはストーリー・カードに優先度をつける。
両者が折り合った時点で交渉が妥結し、仕様が決まる。

＞両者が折り合った時点で交渉が妥結し、仕様が決まる。

ということは、要求仕様は最初の時点で確定してるってことだね

すみません、他スレで質問をしていた者なのですが、
テストファーストでなくて、テストプログラムが一つも用意されていない
スパゲッティコードのプロジェクトを、救済する方法は無いものでしょうか？
http://pc8.2ch.net/test/read.cgi/tech/1030721755/l20

リンク先のスレで頂いたアドバイスがあるのですが、それの実践の参考に
なりそうな資料がありましたら、お教え頂きたいのです。
プロジェクトを上司と検討し直すに当たって、自分の意見の基盤がしたいと
おもっております。

以下、そのアドバイスの引用。
----------------------
336 ：デフォルトの名無しさん：2005/11/07(月) 23:43:57
リファクタリングは諦めて、機能仕様観点で

１．仕様を洗う
２．それに対するテストを追加する

地道にコレを少しずつ進めていく。
そうすれば、改修で正常系のデグレードを防げる確率が着実に上がる。
この際、テストも細かい異常系テストとか割り切るところは割り切る。
もっともデグレード防止に効果的だと思われる部分のみに着目して
テストを増やしていく。
幸せにはほど遠いけど、少しはマシになるんじゃないかと思う。

×基盤がしたい → ○基盤としたい

なお、前スレでお答え頂いた皆さん、ありがとうございます。
ズレなレスをしてしまってごめんなさい。

>>15
これは何？
これは何のためにやっていると質問される程度ならペアプログラミングは最適だとおもう。

否定的な事言われるとだれだって深いになるけど
質問されるだけならそれほど不快感は無い。

しつこく質問されて中断症状がおきるのはウンザリだが。
適度に適度に。即答程度でいい軽い質問なら無問題。

これは何？　と言われてすぐ答えられない
なら警告サインということを意味しているわけで
それを自覚する程度がいい。

>>30
30代以降の否定的なオッサンがこの業界に多いから
なかなか普及しないっぽい。
マ板の香具師らは年齢層が30代以降がぞろぞろ
いるが、奴らはまさにネガティブで保守的で悲観的。
奴らがXPの普及を妨害している。

営業やワンマン経営者の奴も妨害している。
奴らはXPと聞いてもまったく理解を示そうとしない。
「ただがむしゃらにやっていれば何とかなる」という考えで
その考えを部下にごり押し通すからうまくいかない。嫌われる。
XPをしたくてもワンマン経営者に支配されちゃそれすらやる暇もないのが
現実という会社も多いこと多いこと。
上からの命令を無視してXPを実践するもよしかな？
ところがチーム内に上からの命令には従順って奴が一人でもいると
うまく逝かないことも多い。

ワンマン経営者はワンマン営業が納期を短く
設定しすぎるのもXPをやりづらくしている原因の一つ。

ワンマン経営者やワンマン営業のオッサンどもは
若い頃にやったソフトウェア開発手法といえば
ウォータフォール程度しか知らない。
ウォータフォールすらやらずに独自のいちかばちか戦法で
やって来た「どうにかして切り抜ける」を繰り返してきたバカもいる。
それで自分が零細の取締役になった途端に偉くなったと勘違いして
部下に対しては手のひらを返すような態度をとるからタチが悪い。
まさにこの会社潰れるんじゃないかって匂いがしてきた。
独裁者に支配された会社はおしまいだと。
まるで北朝鮮のような会社みたいだ。金正日みたいな奴が
ワンマン社長やワンマン営業(実は取締役も兼ねてる)やってて
部下が苦しめられてXPという民主主義の実現が妨害されている
っていう構図がお似合いだ。この会社には。

それから顧客側がXPを知らずウォータフォールを
押し通すと下請け企業はXPを適用しづらくなる。
しかも顧客が独自に作った略語やその会社でしか
通用しない社内専門用語を厚かましく使ってくる。
最悪だ。変な顧客が「俺様はお客様だから神様なんだから
お前らは俺たちの言うことだけに従っていればいい」と
威張り腐るかのような態度をとるのでXPが実現しづらいともいえる。

自社のトップを教育することが出来ないのに、顧客の協力を得られるはずが無い。
他者の長年の行動習慣を変えることが出来なければ、XPは画餅に過ぎないのだよ。
ここは愚痴スレでは無いのだから、「どうすれば良いか」を全く記述しなければスレ違いで終わったしまうよ。
続きをどうぞ

じゃ、ちょっと燃料投下してみます

XPは仕事では使えない、とまでは言わないけどほとんど使えるシーンはない
理由は、XPはビジネス上のコミットメントをなにもしてくれないから
いつ製品が完成するか？と聞くと、「最短の開発期間です」としか答えてくれない。確かに
開発者の説明は”最短”であることの理由として納得してもらえるかもしれんがそれだけじゃうまく行かない
仕事なんで開発チームがいつ出せるとコミットメントしてくれないことには販売活動やサポートを行う
チームはスケジュールを組んで予算を投入して何もできない。
開発者だけではなく、考え方や仕事のやり方の違う営業やサポートのチームと一緒に仕事をしていくため
には、他チームの立場や考え方を理解する努力とコミットメントしたことをチームとして守ることが大事
営業にとっても、次の製品が”いつ出るのか？”と”どんな機能が盛り込まれるのか?”はとても重要の
はず。それを客にコミットメントしてくるわけだ
XPは最短でその情報が入手できるとしているが販売や広報の活動にも開発の用に時間や手間がかかる
作業があるということが理解できる開発者ならあまり納得させる説明になっていないことに気づくでしょう
だから、開発チームとして”期間”と”盛り込む機能”は最初に「コミットメントしてくれ」となる

もう一つ話題投入。

「NAgileで始める実践アジャイル開発 第二回 ソフトウェア開発をシンプルにする考え方のコツ」
http://www.atmarkit.co.jp/fdotnet/nagile/nagile02/nagile02_01.html

プラクティスやると同時に考え方もシフトさせていくべきかも。
「従来のやり方にあてはまらない＝アジャイルが駄目」でなく、従来のやり方＆考え方をシフトさせることに主眼があっても良いのかも。

> いつ製品が完成するか？と聞くと、「最短の開発期間です」としか答えてくれない

いつ完成するか？ではなくて、
いつまでに欲しいor何が欲しい、だろ？

おぉ。鋭い突っ込みｗ

RUP の反復計画みたいな考えかたは、 XP には無いの？

>>51
イテレーションって呼ばれてる

うーん。
なら、
>>47
みたいなことはないはずでないの？

> いつ製品が完成するか？と聞くと、「最短の開発期間です」としか答えてくれない。

これが嘘だから。FUDを「燃料」と勘違いしてるだけ。

age

>>54
じゃ、正解は何なの？

よくわからないけど、>>47をリファクタリングすると、

”期間と盛り込む機能”を最初に開発チームが「コミットメント」しなければ
ならない企業においては、”期間と盛り込む機能”を最初に開発チームが
「コミットメント」しないかぎり営業活動ができなくなる。

ってなっちゃうな。

つかXPが見積もり手法ではないって事が、なんか不満なんだろうか。

>>47もひどい日本語だが、>>57もひどいな。
まともな日本語を書けんもんかね。

XPが一番有効に働くのは、社内のシステム部が自社向けのシステムを作るときじゃないかという気がする。
ユーザーと製造者の間に利潤を目的とした契約を入れるのが、かなり無理があるシステムじゃないかと思うんだが。

佐賀

>>59
ユーザー主導（責任）で、そのサポートをするって形の契約が自然だと思う。Agileやるならね。

>>61
今の日本だと、ユーザー企業でまともな情報システム部を残しているところは少なそうな気がするが…

昔は、でかい会社のシステム部は自前で設計からコーディングまでできる人材が揃っていたから、
ベンダーとのやり取りがスムーズだったと言う話を聞くけど。

情報システム部門なんて真っ先に予算削減の槍玉にあがるしな。
大規模なシステム刷新なんて数年に1回有るか無いかだし、
その場合でもベンダに丸投げでいいじゃん、って考えの経営陣も多い。
それ以外の期間はほとんど、PC関連の雑用ヘルプだったりするしな。

と、一応社内システム部門担当な人間の愚痴でした。