
みんなExtremeプログラミングしている? 60
ストーリー by wakatono
決してWindowsXP上のプログラミングではない 部門より
決してWindowsXP上のプログラミングではない 部門より
takusi 曰く,"最近、話題のExtremeプログラミング、導入してますか?かつてのソフトウェア開発というものは、codingに入る前にいかにバグのない設計をしているかがkeyになるといわれてきた。しかし、XPではその考えの大胆な変革を求める。XPでは、変化ヲ抱擁セヨという重要なキーワードがあり、これの意味するところは、きちんとした設計をするのではなく、あとからいかに柔軟に設計を変えるにはどうすれば良いのかという視点である。 [eXtreme programming FAQ]"
「変化ヲ抱擁セヨ」、この短い言葉に集約された意味は大きい。今更XPについてオレがどうこういうことはないが、XP(に限らないが)を誤解している人は多いだろう。OOPもそうだが、単に導入するだけでソフトウェア設計/製造シーンが変わるような銀の弾丸も魔法の杖もないのだ。さて、このあたりのことも含め、プロセス改善とかで周囲への説明に苦労している方々はどのくらいいらっしゃるのだろうか?そしてどのくらいXPをしたいのか?もしくはしているのか?その心の声を聞かせてくれ。
工業製品かサービスか (スコア:3, 参考になる)
対して、ネット上のWebなどで行われるサービスのプログラムの場合は、XPは有効だと思うし、大方のサービスは、実際に動かして多くのユーザに使ってもらわないと、どうしてもわからないところが出てくるから、仕方なくXPせざるを得ない、という側面もなきにしもあらず。ましてやネット上のサービスは、サービス提供に至るまでのスピードが勝負ですから、XPはとても有効と思います。
要するに、ケースバイケースではないかと思います。
ペアプログラミング (スコア:3, 参考になる)
設計段階では2人いてもいいけど、プログラミング中に横に人がいて集中できそうにない。
以前職場の上司に話したら、「この人手が足らないときにプログラム1本に何で2人も必要なんだ」だそうです。
実際の現場で、特に大規模な開発になると、周り(特に上司)を納得させることが難しそうですね。
テストバカになる(いい意味で) (スコア:3, 興味深い)
Re:テストバカになる(いい意味で) (スコア:2, 参考になる)
ところで、GNUにはXPが話題になるずっと前から、DejaGnuってのがあったと思うのだけど、使っている人っています?
Re:テストバカになる(いい意味で) (スコア:1)
激しく同意。
僕も、XPはUnitTestから導入してみました。効果は絶大です。自動テストなのでソースの改善が自由に出来ますからね。
動いてるものは汚くてもいぢるな!」
という近視眼的な考えにとらわれる必要がなくなります。
でも、GUIやDB周りのテスト自動化は難しいッス。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:テストバカになる(いい意味で) (スコア:1)
この頃は、そうあっていいんじゃない、という事で、どのように作られているか(設計書)は軽視してます。結局の所、テスト(検証)にパスすれば製品として出荷 OK となるので。
仕様書には、やりたい事が記述されているので、どういう検証を行えばソレが実装されているかを考えます。
仕様変更が舞い込んで来た時も、どのような検証でもって、既存部に影響の無い事、追加分が実装されている事を確認できるかを考える。
初めにテストありき。自分自身 昔は、どう作ろう?という事ばかりに囚われ過ぎていたように感じます。
そんなに新しい考え方なんだろうか? (スコア:3, すばらしい洞察)
これは、まず設計を行う代わりに早い時期からプロトタイプという形で目に見える(実際に動作する)ものを作って、要求仕様と設計、プロダクトの擦り合せを行うという方法論で、XPで言う所の
比喩というのが、言葉上の比喩ではなく、実際に動くコードだという所が違いますが...
また、
オープンソースの開発ではペアプログラミングどころか、数十人、数百人という単位で一緒にプログラミングしてるようなもんだし。
という事で、XPは「新しい手法/考え方」という程の事もないような...
もちろん、これらを体系的にまとめたという意味では意義があると思うし、この方法論自体は良いと思う。
Re:そんなに新しい考え方なんだろうか? (スコア:1)
Re:そんなに新しい考え方なんだろうか? (スコア:1)
でも、こういうのを本当に徹底的にやろうと思うと、 開発者の心構えとか、開発スタイルだけじゃなくて、 上司や顧客の理解といった政治的(?)な部分が重要になってくるんじゃないかと思います。
だけど、そういう事への回答は無いままに開発者への方法論/精神論だけに終始してるような感じが...
Re:そんなに新しい考え方なんだろうか? (スコア:1)
ただ、実務の場だと情報を公開したがらない技術者が結構多いのですよね。
Re:XPできませ~ん(泣) (スコア:2, 興味深い)
あぁこれはいい。「仕事が面白くなりそう」と思い上司に相談
「人件費が二倍かかるじゃん。」 と一蹴されてしまった。
Re:ペアプログラミング (スコア:2, 参考になる)
Re:ペアプログラミング (スコア:1)
これをコーディングのすべてのフェイズで extreame に実行するのがペアプログラミングというだけで。
Re:ペアプログラミング (スコア:1)
日本であっても(というか、だからこそ?)、たとえば「私語厳禁」とか言われたらオシマイなわけです。
以前居た職場が、ある意味でそれに近い面が有ったんで、泣きました(T_T)
ええ。開発者間の"情報のやり取り"が少ないため、志気も品質も(以下略
そういう閉塞状況に対して公然とNO!を言ってくれるという意味では、XPはナイスだと感じました。
まだやったことは無いですけど、さぞHappyだろうな。
ホビープログラマですが (スコア:2, 参考になる)
テストのおかげで自分で書いたコードを信用できるようになって楽になります。(特にデバッグ時の精神衛生上いいと思う)
ただテストコードを書くことに熱中して本当の目的が果たせなかったりします。(本当のXPだったらペアプログラミングが解決してくれるのかな?)
一番よく好きな言語はC++ですが、CppUnitを使ってると、JUnitが羨ましくなります。
Re:工業製品かサービスか (スコア:2, 参考になる)
特に、PerlでCGI作った日にゃ、
・毎日がリリース
・他人のソースも見れちゃうから気に入らなければ
勝手に修正。
・ユーザにとにかく動くものを見てもらって、
気に入らないところを少しずつ直す。追加する。
ただ、、、、、WebUnitっちゅうのもあるけでど、
現実的じゃない。単体テストだけができない。
日本でも (スコア:2, 参考になる)
日本でも古くからSmalltalkコミュニティでは似たようなことが行われてたようですな。
あと、文末の「やっと日本のやり方にアメリカが追い付いてきた」というのはスバラシイ洞察(^^;
trueOne
リンクは (スコア:1, 参考になる)
Re:ペアプログラミング (スコア:2, 興味深い)
集中といっても、単に静かで他人が居なければ対象物に集中できる、とは
限らないぞ、ということなんじゃないかと憶測してます。
人それぞれかもしれませんが、「考えを、誰かに喋ってしまうと、不思議と欠点に気付いたり
改良案が浮かんだりする」って経験、ありませんか?少なくとも俺は一杯あります。
対象物のことを考えるという意味では集中を保ったまま、かつ隣人と議論(?)したとき、
不思議と思考が前進するっていう。
あ。ここでいう隣人は、"同志"であるほうが望ましいとは思います。
人形でもイイという噂も聞きます(^^;が、やっぱり志を同じくしてる人が最高でしょうね。
で、それを形にしたのが、ペアプロなんじゃないかと思います。
音楽(?)とかで最近流行の言い回しでいえば「コラボレーション」って奴かな?(^^;
コラボレーションそのものは必ずしも同志とべったりしてることを要請しはしないでしょうけど
(OpenSourceの開発なんかも分散してますね)、仕事なりなんなりで何人かが集まって集中して一本のソフトを書く
という状況ならば、せっかくだから赤^H互いに密着してたほうが効率が良いぞ、ということなんじゃないかと。
あと。
漫画「Natural」(LaLa、成田美奈子)によると、集中が研ぎ澄まされると、
対象をがっちり把握してて、かつ同時に周囲の雑事まで判る、
ということが人間にはあるとか。あれも関係あるかな?
ま、コーディングも、隣人との掛け合い漫才(笑)も、「思考の外在化」という意味では
似たようなものだという面もあるんで、いいんじゃないでしょうか。
コミュニケーション苦手な人でも、超うまい流暢なコミュニケーションがペアプロに必須とまでは
言わないんじゃないか?と邪推してるんですが、経験者諸兄、どんなもんですか?
Re:ペアプログラミング (スコア:1)
だから皆さんが考えているペアプロのようにコーダー固定じゃないです。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:ペアプログラミング (スコア:1)
だから人から見られてイヤーンってのはすぐ消えそうですね。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:ペアプログラミング (スコア:1)
バレーボールのローテーションってルール。
ポジションを次々入れ替えることを義務付けるって奴。
#最近はまたルールかわったんでしたっけ?
ん?1つの奴に拘ることが出来にくいという意味では、スラドの構成にも似ている、のか?(笑)
XPできませ~ん(泣) (スコア:1)
XPは全部を実践しないとXPとは言えないので...
それはそうと、「徹底したテスト」の具体的な内容がちょっとまだ謎なのが...テストの自動化...う~む。
Re:ペアプログラミング (スコア:1)
そもそも、ウォーターフォール型のように設計とプログラミングが段階的になっていると、ペアプログラミングってのは無理だと思う。イテレーション単位が小さく、細かな機能アップを頻繁に行うような開発体制なら、お互いにコメンテータやアドバイザとなり、アイデアが触発されるといった良い面が出てくるはず。オブジェクト指向技術は、比較的XPを適用しやすいはずだけど、現場が段階的にドキュメントなどの成果物を要求するので、それを許さないってのはあると思う。変化は悪というのが、多くの開発現場の共通認識ではないかと思う。
# 変えるなら金をくれ。変えないなら、それは仕様通り。
変化は (スコア:1)
変化が無いのは理想だけど,夢ばかり見ててもしょうがないわけで……
XPを考えナシに使おうとすると... (スコア:1)
多分、頭の切換が必要だね。
しかし、ちゃんと設計できていなくて穴だらけの仕様書をプログラマが泣く泣く補完しながらコーディングしているような現場も沢山あるから、実は救いになるのかも。
Re:XPを考えナシに使おうとすると... (スコア:1)
(しかも分量が無闇に多いし。さほど巨大なプログラムじゃないはずなのに
ダンボール箱一杯だったりとか!)、こっちの質問に真っ当な答えを
(時間内に)返せもせず、それで成果物が変(彼らの思惑と比べて。勿論それが
きっちり仕様書に反映されていたわけではない)だったらこっちにペナルティ罰金を科す、
などという駄目すぎなお客には、是非XPの爪の垢を煎じて飲ませたいんですが、
あっちは大企業(ついでにこっちは零細)なんで、こっちが言っても無理だろうな…(T_T)
CMM+IDEALをお奨めすれば如何でしょう。 (スコア:1)
「CMM認定されれば、最近話題のインドなソフト関係者の
方々と同じく、世界レベルで通用し、運が良ければ
米軍の調達時に企業連合等々の一員として参加可能な
段階までレベルアップ可能なので、御社のように主と
して上流工程をご担当される場合、是非とも取得すべき
認定資格であり、営業的な意味合いからも非常に有利
なのでご検討ください~~」
な、どっかのコンサルタントさんの口調を借りて、影響力
があって、キーマンな方を徐々に洗脳される事をお奨め
します。
要は、CMM的な取組みに参加してさえ頂ければOK。
後はCMM的なトレーナーと、CMM的な認定チェッカーな方が
厳しくトレーニング&レベル判定して頂けるので、自ずと
要求仕様書の精度が向上していくハズです。
#米国認定を取得するように、勧めるのがキモです。
...う~む、これは謀略か?、それとも世の為か?
ウォーターフォールを目の敵にしてないですよ。 (スコア:1)
別の方も仰っている通り、WEB(EC)系開発ではリリースしてからが勝負、と言うより目の前で動かないとユーザもイメージが湧かないような点もあって、先ず動かしてみよう的な取組みに向いている事に同意します。
私には根性が無いけど、誰かに実装する根性があれば、セキュリティ・プロセスの運用等にも向いている、スパイラルな手法を使用して、目的へ収束させる為の哲学的な考え方が基礎になってたります。
関西地区で興味がある方がいらっしゃれば、入門セミナの受付を下記で行っているようです。
(http://members6.tsukaeru.net/xpjug-kansai/index.html)
開発手法の複合化 (スコア:1)
ウォータフォールなプロジェクトの単体テスト工程以降に
xUnitな(存在しない言語は自作の)テストを放り込む
とかで柔軟に対応しており、自動テストの恩恵に与って
たりします。
#仕様変更ですか、ホイホイッと変更、全テスト1分、
#はい終わりました~、んぢゃお先ぃ、てな感じで...
一部では、ウォーターフォールとかCMMとかへ攻撃的な
方がいらっしゃいますが、私はCMM的なプロセス改善の
取組みも素晴らしいと思うし、こっちにも対応しようと
思いますケド、こちらも「やれるトコから...」な
世界だと感じる(成熟度レベルとか)ので、両方のイイトコ
取りしようと狙ってます。
PSPな事まで勉強が及んでませんケド、根本的には開発者
が「ラクできる」上に、「製品の品質を上げる」と言う
目的に関しては同じだろうと思ってますんで...
Re:ペアプログラミング (スコア:1)
すが、実際にやってみた人、効果のほどはいかがですか?
技術のある人が、勉強中の人に、手とり足とり指導しながら
プログラミングするというのならば、ペアでやる効果が
ありそうですが、実際の開発でどの程度効果があるのか
興味があります。
# 近くに相手が見つからないし...。
# うーむ。やっぱりちょっと他人から見られながら
# コード書くのって、なんとなく抵抗があるなぁ。
Re:ペアプログラミング (スコア:5, 興味深い)
>プログラミングするというのならば、ペアでやる効果が
>ありそうですが、実際の開発でどの程度効果があるのか
興味があります。
私も本格的な経験はないのですが、実験的に3日ぐらいやってみたところ、
* スペルミス/リソースの解放し忘れなどの単純ミスが劇的に減少する。
* 説明するのが面倒なので、意図がわかりにくいコードを避けるようになる
* 一人で作業しているよりも袋小路に迷い込む場面が減る
などの効果がありました。
ただし、作業効率的には、1人でやるときの2倍にはならないと思います。たぶん 1.5 倍程度。ただし、副作用として、デバッグやテストなど、コーディング以降の作業の工数が減っていると思うので、トータルで考えるととんとん以上の成果が得られると思います。
まぁ、多少慣れは必要だと思いますが。
Re:ペアプログラミング (スコア:2, すばらしい洞察)
効率を上げるというよりは、後の非効率の要因を取り除くという感じ。どこかで限界が来て(余計な)整理をするのではなく、最初から整理された状態にしてしまう、と。他にも、ペアの流動によるノウハウの流動・教育効果もあるだろうし、存外効率的なのではないかと思います。
Re:ペアプログラミング (スコア:1)
“ペアプログラミングはどのようにやるのですか?”
XPをちらりと知った時にも疑問に思ったのですが,ペアでプログラムをするとなるとキーボードの前にスペースが無いと思うのですが……
二人体をくっつけあっても液晶だと見えづらいし,キーボードは打ちにくいし.(勤め先だとそもそも二人並んで座るスペースが無いですし )
もしかして,学校教育用なんかに作られている,別のPCでターゲットのPCを操作するシステム等を使うのでしょうか?
勤め先ではCVS等でソースツリーを管理してるから,マルチユーザーでプログラムしてるといえばしてますけど,ペアプログラミングってそういうことじゃないですよね?
Re:ペアプログラミング (スコア:1)
ただ、マシンの前に椅子を二つならべるだけのスペースすらないのであればペアプログラミングに関係なく、プログラマの作業環境としては狭すぎる気がします。1日の大半をそこで作業するわけですから、なるべく快適な環境を整えることが重要かと。
XP の場合、部屋の中央に大きな机を置いて、そこにマシンを何台か置き、プログラミングするときはそこに行って作業するというスタイルが提案されているようです。
Re:ペアプログラミング (スコア:1)
でも,結局大きなスペースが必要なんですね……狭い日本ぢゃ1つのプログラムに二人かかるというコストよりも,場所的な問題のほうが厳しいでしょうね.
XPやるからスペースくれなんて,上司は納得しても総務が納得しないでしょうし.
Re:ペアプログラミング (スコア:1)
なんかどこかでその話題をしたら、キーボードも画面も「同一物を共有しろ」と言われた記憶が。
それが本当だとすると不思議なんですが、キーボードやキーバインドの各自の好みの問題は
一体どうするのやら?
viな人とEmacsな人とNotepad.exe(笑)な人と…
HHKでないと駄目な人とHHKじゃ駄目な人と…
誰か、真相(?)をフォローお願いします。
Re:ペアプログラミング (スコア:4, おもしろおかしい)
部署内で実験的にやった結果、二人でやってるとなぜかお菓子をかってきてだべりながらやってしまうので太ったという意見がありました(^_^;)
Re:ペアプログラミング (スコア:1)
というのも、XPのルールではなかったでしょうか。
ダイエットに命がけの人には、酷な環境なのかも(^^;
Re:ペアプログラミング (スコア:1)
-----------------
#そんなワタシはOS/2ユーザー:-)
バックとぅざフューチャー (スコア:1)
<JOKE>
ごく普通のプログラミングに従事する人がこんなことを言うとは、
フランス革命から見れば隔世の感がありますね。
それともまさか、XPは貴族のための方法論だったとか?
</JOKE>
設計?プログラミング(製造)? (スコア:1)
設計(テスト作成)→製造(プログラミング)
のループが肝かと。
実際、独りよがりなコードと設計を防止できるので
良いかと思っています。
5年目と2,3年目の人でチームにしたりすると
全体的なコードの質が向上しそうに思います。
(全くの新人では先輩の負担が重すぎます)
テクニカルでも後輩が理解できないようなコードは
ダメだって事である程度目安になりそうです。
組み込み・制御系の様にハードが絡む系列には
XPは向いていないとは思いますが。
------------------------ written by BlueJocker ------------------------
出来るものから取り入れてます (スコア:1)
-- niwaken
実践してみるためには・・・(オフトピ) (スコア:1)
決定的に不足しています。
もちろん、その提案能力も、こちら側の責任であることは
承知しておりますが。
--本題からそれます--
逆療法として、耳栓(スポンジみたいな)をして、
質問されにくい(?ペア・プログラミング拒否)のような
動きをしつつ、「質問はどんどんしなさい」状態にして、
回りの動きがどうかわるかを試してみました。
(質問が減ったら、それは・・・質問する側の問題でしょう。)
実際、電話の鳴る音や、話し声は消えませんし、
耳障りな空調の音のようなものは消えてくれて
逆に快適に感じられます。
質問の増減はどうだったか・・・
Copyright (c) 2001-2014 Parsley, All rights reserved.
ペアデバッギング (スコア:1)
10年位前(って言うかこの業界に就職してから)から良くしますけどね。
二人以上で一緒にデバッガーでソースコードを追いながらデバッグするという。
結構思い込みによるバグに見逃しに効果があります。
masamic
Re:ペアデバッギング (スコア:1)
masamic
XP のゲーム開発での導入ネタ無いでしょうか? (スコア:1, 参考になる)
> でも、GUIやDB周りのテスト自動化は難しいッス。
画面出し前なら UnitTest の導入は積極的にやってます。
でも 60 fps で動かすフレームワークの方では、
オートデモ用のキー入力テーブルを受けての
出力確認ぐらいしか自動化できていないです。
ゲーム開発で使える XP 面白ネタありませんかねぇ。
方法論としてはどうか。 (スコア:1)
XP については人によって賛否両論があると思いますが、私はある程度有用性を感じています。
XP を読んで感じたことは、方法論ではあるもののどちらかというと「変化ヲ抱擁セヨ(Embrace Change)」を中心としたデザインパターン的なカタログという感じがしました。
何が言いたいのかというと、あくまでもカタログなので、それが参考になるとはいうものの、この方法ですべてがうまくいくとは思っていません。
やっぱり「変化ヲ抱擁セヨ(Embrace Change)」といっても実際のプロジェクトでは限界があるし、リファクタリング(一応私の認識では外部的な仕様を変えずに内部を改良すること)もどこまでリファクタリングというのかという難しい問題があります。最終的には、納期とコストのバランス問題になってくるんでしょうけど。
いままで、こういう方法論で成功したものはないですし、どうしても経験的に否定的になってしまっています。
ただ、今まで方法論が成功したことが無いから方法論を作るのは意味が無いとは思っていなくて、(普及を含めて)十分使えるものになっていくことを祈っています。
Re:ペアプログラミング (スコア:2, 参考になる)
そうです。何もわかっていない上司です。
わたしが担当しているプロジェクトは小規模かつエンドユーザー相手の受託なので、XPを実践できる環境にあります。今の段階では取り入れるところから始めて、毎朝短いミーティングを行う・テストファーストを徹底する・JUnitを使用したテストの自動化・週40時間労働を守る(これが一番いいですね。)等を取り入れていますが、やっぱりペアプログラミングはなー・・・。
食わず嫌いの状態です。
ただ、会社の他のプロジェクトを見ていると、大手企業が発注し、それを下請けの何社かが入り混じって人月計算で工数を出している世界にいきなりXPを実践するのは、現状では難しいのが現実じゃないでしょうか。
前にIBMの社長が言っていたように、日本に頭数を揃えてナンボの人月計算よりも、成果物を重視する文化が育たなければ、XPを導入しても意味がないのではないのでしょうか。
食べれば美味しい? (スコア:1)
俺個人としては、隣人と掛け合いを楽しみながらプログラムするなんて、
結構自分の理想に叶ってる環境かもだなあ。
勿論漫才のネタはそのプログラムね。
あ。そういや遥か昔学生のころ、部活で学校祭なんかに出るとき、
人前でわいわい言いながらモノ作って売るのが好きだったなあ。
あ。漫画部でしたんで、モノは絵です。下手ですが(^^;
で、なんかわいわいやってるほうが、一人さびしく描いているより、
捗るし楽だしモノも良くなった(気がする(笑))し。
あんな愉快なノリ、かむばーーーっく!!って感じかも。
OpenSource開発との類似性も挙げられていますが、
つまり「バザール」なんじゃないかと想像します。わいわい。