沢山の人に聞いてもらってその後も質問などで色々お話しが出来て
僕も勇気を貰いました!!
ありがとうございます!!
とりあえず資料貼っておきますね!!
で、アンケートに返事してみようのコーナー
今回は大量でした!!
ありがとうございます!!
今まで聞いていたセッションの中で1番面白かった上、とてもためになりました。プログラミングし始めてからまだ3ヶ月ぐらいしかたってない自分にとってテストは品質担保のためだと思っていました。しかし、話を聞いていて「開発するためのテスト」という考えに触れて、テストに対する考え方が少しかわりました。ありがとうございます。
こちらこそありがとうございます!!
個人的には TDD で開発するのはスキルアップの近道だと思うので
是非試してみてください!!
ナイス、個人からでも始めたい。
是非!!
少しづつ広げていきましょう!!
元気と勇気をもらいました。ありがとうございました!
こちらこそありがとうございます!!
僕も元気と勇気をもらいました!!
おもしろかったです。私も今日、勇気をもらいました。
僕も勇気をもらいました!!
聞いていたたいてありがとうございます!!
大変面白かった。来年もまたやってください。期待しています。
ら、来年ですね＞＜
まず、呼んでもらえるように精進します!!＞＜
ドワンゴおもしろそう。35才でも入れますか?
年齢制限は無いですよ!!
僕も33歳で入りましたから!!
http://info.dwango.co.jp/recruit/
勇気をいただきました。まずは個人からというのは、とても勇気が出ました。
ありがとうございます!!
個人からでも、ブログとかに書くと仲間がいっぱいいますので
孤独では無いですよ!!
今回はあくまで開発の話をしただけで、
単体テストや結合テストは別途必要だと思っています。
TDD は開発のためのテストなので、品質保証のための従来の手法が
必要無くなるとか置き換えるとかでは無いと思います。
プレゼンのツールは何?
Keynote です!!
それしか使えません＞＜
なるほどと思うことがたくさんあり、とてもためになりました。ありがとうございました!
こちらこそ聞いていただいてありがとうございます。
まだ試行錯誤の途中なので間違ってるところもあるかもしれませんが、
今後も精進しようと思います。
ペアプロもいいけどコードレビューも大事だよね
ペアを頻繁に変更しながらペアプロしていると、別途コードレビューは必要無いと思っています。
僕はどうしてもペアで出来なかった時にコードレビューする感じですかね。
ペアプロの相手に選び方などのノウハウはありますか?(技術レベルの差等)
むしろペアプロの相手はどんどん変更すべきだと思います。
僕はなるべく全パターンのペアが出来るように考えます。
楽しめました!!個人からはじめてみます。
ありがとうございます。
一緒にはじめましょう!!
説得力があっておもしろかった
楽しんでいただいて良かったです。
XPについてほぼ何も知らなかったので大変勉強になりました。
僕もあんまり知らないまま初めたので
発表資料作るときも勉強になりました。
ヨシノリだと思ってた。オリなのね。服はカツカツのリクルートスーツの方がウケルと思うよ。
リクルートスーツ持ってないんですよね ＞＜
すごくよかったです。自分もがんばってTDD導入したいと思います＞＜
導入しましょう!!
TDD は個人で今すぐでも導入できる良いプラクティスだと思います!
具体的な話が良かった。
ありがとうございます。
今後も出せる範囲で具体的な話はしたいと思います。
とても楽しい発表でした。ありがとうございました。
こちらこそありがとうございます。
「小さい」と「小い」ありましたね。
すいません＞＜ 漢字苦手で＞＜
楽しく最後まで聞かせて頂きました。ペアプロチャレンジします!
ありがとうございます!!
ペアプロ楽しいですよ!!
バーンダウンチャートが面白そう。導入してみようと思います。
見えるようになると色々発見があるので
面白いですよ!!
是非導入したら感想教えてください!
意「志」ですよ!
修正しました!!
すばらしかった。学ぶべきポイントはXPではなく和田さん、角谷さん、勉強会、とまきこむよしおりさんの意志だと思いました。素晴らしい。
ありがとうございます!
今後もドンドンまきこんでいきたいと思います。
面白かった。小ネタも多く、タイクツしなかった。
楽しんでいただけたようで良かったです!
ありがとうございます!!
テストを導入するのが難しいケースもあると思いますがどうしたらいいでしょうか?具体的には、アクションRPGを作っています
まず、なんで難しいのかを考えて、それを解決する方法を考えていく……
というように少しづつ細かくしていって解決するのはどうでしょうか?
あじゃみつんところが面白かった。糸柳
ありがとう!!
良書なので是非読んでみてくれ!!
具体的な事例が見れて良かったです。良い話だと思うので、タイトルが良かったらもっと人が集まったと思う
タイトル駄目でしたか＞＜
もっと良いタイトル出せるようにします!!
TDDに魅力を感じていますが、テストの書き方、コツなど具体例として紹介して頂きたい。
コツや具体例はプレゼンでも発表しましたが、
WEB+DB PRESS #35 がおすすめです!!
プランニングポーカーは面白そうですが開発者が一人しかいない場合はどのような法方がありますか?
開発者が１人であってもプロジェクトにかかわっている人間は他にもいると思うので、
その人たちを巻き込むのも良いと思います。
逆に１人でやらなきゃいけないとなっても、ストーリポイント出してベロシティをはかるのは有効だと思います。
テストを書いていると、テストが問題でなくコードの構造にdependしてしまってコード変更→テストコード変更になって、一体何をやってる のか自分はorzになってしまうことがあります。どうしたらいいですか?
まずは、現状をテストするテストコードを書くのが大事だと思います。
それを意識して確実に書いてからプロダクトコードの変更に入るように心掛けるようにしています。
午後一のセッションで、元気をもらいました。楽しい時間ありがとう。
僕も楽しかったです!! ありがとうございます!!
ドワンゴ入りたい!
是非!!
http://info.dwango.co.jp/recruit/
最後の提案、すばらしかったです。(個人からXPを広げていく)勇気をもらった気がします!
ありがとうございます!!
XP に限らず良いと思う事はどんどん一緒に広げましょう!!
ヨシオリさん髪ツンツンの頃の方がかっこよかったです。楽しいセッションでした
あう、髪の毛、寒いので切ってなかったのですが、もうそろそろ切ります＞＜
実体験をベースにまず導入したことがない人もわかりやすく説明されていて、話が理解しやすかった。機会を作って自分のプロジェクトでも導入できればと思う。 XPを導入できない時にそれすらアジャイルにとり組むのが真のXPだという言葉、何気に重要だと思います。もっとそういう点をブログその他でアピールしていただくとXPも広がっていくのかなと思いますよー。
XPを導入できない時にそれすらアジャイルにとり組むのが真のXPだという言葉、
自戒でもあったりします。
いつも心にとどめておきたいですね!
がんばってブログ書きます＞＜
最近、さぼっててすいません＞＜
後でまた見れるようにしてください。
up しますた!!
同じようなつまづきを経験されて、乗り越えていたので非常に参考になった。
おぉ、是非そのつまづきを問題なければ教えてください!!
とても楽しいセッションでした!!すごく勉強になりました。
ありがとうございます!!
ペアプロの実際の環境(PC構成など)を見たい。
まだペアプロ用のマシンを用意するまではいたってないので、
どちらかのマシンでやっています!!
(僕の環境はLinux + US 配列 HHK + SKK なのであまり使われないですが＞＜)
とても楽しい話し方でよかった。TDDは個人でやっているが、少し納得感が増した。
ありがとうございます。
TDD!! TDD!!
実は学生ながら生意気にも参加しました。XP、TDDなど知らないことばかりでしたが、やっぱりこの業界で仕事してみたいと思いまし た。「絶望先生」も「ジョジョ」も好きです。
全然生意気とかないですよ＞＜
是非この業界ではたらくのであればドワンゴもよろしくおねがいいたします!!
「絶望先生」勉強会もやりたいです＞＜
細かく分けて把握できるようにする?は工数見積りで実感しています。
おぉ、すでに実感されているのですね!!
やはり細かく分けるのはいいですよね!!
正直午前中は寝そうだったのが、目が覚めました!!
ありがとうございます!!
僕は発表が終ったら一気に力が抜けて寝むくなりました＞＜
タスクをTracとホワイトボードの両方で管理すると両者が合わなくなったり、めんどくさくてTreeが放置されたりしませんか?一度試そう としたことはあるのですがTrac側が最終的に放置されてしまいました
放置してしまって問題なかったのであれば不要だったと思います。
うちは、両方の利点があったりするので両方使ってますが、
どうにか 2 重管理しなくて良い方法がないかなぁと思っています。
とても面白かったです。ありがとうございます。個人からはじめて会社を変えてやろうと思います!テストってどうやって書けばいいのかいまいちわからないのですが、どこから始めればいいですか?
うちはまず、 WEB+DB PRESS #35 を写経しました。
まず体で覚えちゃうのが良いと思います。
XP導入の障壁を低くする方法がいくつか見えた気がする。
ありがとうございます!!
低くなりましたか?
結局周りのせいにして導入を道半ばであきらめていたが、意志がなかったということに気がつかされた。つきものがおちが気分です。
ありがとうございます。
JOJO のなかでも大好きな台詞です。
ペアプロは興味あるが、工数がふくらんでしまうのではという心配がある。1つのものを2人で作るのが良いのか、2つのものを2人で作る (1人1つずつ作る)のが良いのか、また、それをうまく納得させられるかなど。
まずは、不安のあるところからだけでもペアで初めてみるのはどうでしょうか?
実践していくとわかりますが、長期的にみればペアで膨らむ工数よりも、常に二人以上の目にさらされてるコードによるバグや仕様漏れの回避などの減る工数の方が多いと思います。
見た目とは違って、とても内容がある事を言っていたので、おもしろかったです。
見た目こんなですいません＞＜
楽しんでいただいたようで良かったです!!
エンターテインメントでした。最高におもしろかったです。
ありがとうございます!!!!
TDDのテストの他に、品質を担保するためのテストは別にやっているのですか?今のプロジェクトはWindowsMobileアプリかつ既存の コードが大量にあるので、TDDの導入は1番最初のハードルが高そうな感じです。
品質を担保するテストは別にやっています。
TDD の導入はハードルが高いと思われるかもしれませんが、
一気に全部のテストを揃えようとするのではなく、新しく書くところから少しづつで良いと思いますよ
TDDは何で学んだのでしょうか?→参考書などあれば教えて下さい
発表でもありましたが、id:kakutani & id:t-wada に聞いたのと
WEB+DB PRESS #35 ですね。
写経が大事だと思います。
勇気や不安といった感情的なものを丁寧に扱っているのだなと思いました。
不安があると怖いのでなるべく無くそうと思っています!!
「XPへ向かい「意志」が大切」がよかったです。
ありがとうございます!!
良い言葉ですよね!!
TDDなどプログラム開発の話をチーム運営などの話を別々にしてそれぞれの話をもっとつっこんだ形できいてみたいです。
チャンスがあったら是非!!
素直に、開発が楽しそうな職場だなと思いました。でもそれは、少しずつ作りあげていった結果なんだと教えられました。明日から何か1 つ、やってみたいです、Java-jaの温泉行きたいなー!!
ありがとうございます!!
職場楽しいですよ!!
java-ja 温泉も毎年開催する予定なのでよろしくおねがいします!!
やっぱり各デスクにホワイトボードはありますか?単一プロジェクトだから、tracなの?自分たちはtracからRedmineにのりかえたので。 スライドはどこかにUP?ありがとうございました!! @materia_x64
ホワイトボードや消せる紙とかがありますね。
Trac なのは社内標準なのとみんなが慣れてるのもあります。
スライドあっぷしました!!
XP開発って本当にいいの?使えるの?という思いを持って参加しました。内容おもしろかったです。自分の回りにXP開発しているチー ムはない状況ですが、今後の自分のためにも考え、行動したいです。
僕も最初は疑心暗鬼でした。でもやってみると楽しいですよ。
一緒に行動しましょう!!
発表めちゃ上手いですね!50分があっという間でした。XPのプラクティス、やりたいけど実戦できていなかったことも、やってみよう!と いう勇気をもらいました。質問なのですが、バーンダウンチャートはチーム全体ではなく、個人ごとに書いて貼り出しているのですか? 使い方がよくわからないですが、全体の傾向見るというより、各人の進捗を可視化する感じなんでしょうか。教えて下さい。
バーンダウンチャートは僕のいるプロジェクトではサブチーム毎に書いています。
ストーリからタスクに切りわけたタスクの理想時間でやっています。
全体の傾向を見てる感じですね。
ペアプロの意外な目的がとても参考になりました。流行らせたいテクの広め方のひとつのやり方として実せんしたいと思いました。
一緒に実践していきましょう!!
ペアプロやTDDを始めるにあたってはまず個人からというのは理解できましたが、それ以上(会社やチーム)に導入するには、まだまだ障壁があります。(ペアプロやTDDというといやな顔されたり、新しい技術のしゅうとくがめんどうなど)この壁をこえるよい方法はないでしょうか!!ジョジョ最高!!
嫌な顔をされている人に無理強いしては良くないので、
本当に少しづつやっていくのが良いと思います。
「ここが良くわかわないのでちょっと一緒にやってもらえませんか?」
とか、少しづつ一歩づつで良いと思います。
後半の話は参考になりました。にもかかわらず時間の比重が小さく残念
すいません＞＜
時間配分ちょっと駄目でしたね＞＜
XPを使ってチームを作りたいとずっと思っていました。個々人のやり方を否定はしたくないし共通のやり方を強制したくもなくみんながやりたくなるようなものがないかと探してました。今日のお話は、それにつながるような気がします。ありがとうございました。
ありがとうございます。
僕も強制するのではなく少しづつ変化していければなぁと思っています。
見積りと計画に関する話と、リーダとしての導入方法に関する手法は大変参考になりました。一般的にTDDは開発にかかる工数が、多くなる傾向にあるとお聞きしていますが、原価にインパクトがどの程度ありそうか、実体験を教えていただけると幸いです。ありがとうご ざいました。
TDD で純粋にコードが生成されるまでは工数は増えると思いますが、逆にその後のテストやコードレビューなどの工数はかなり減ると思っています。
最近は趣味のコードも TDD でやるほどなので、リリースまでの工数は逆に減るんじゃないかなぁと思っています。
実際おこなっている開発手法の話がきけて勉強になりました。
ありがとうございます!!
カミが赤い。おもしろかったです
赤いです。ありがとうございます!!
プレゼンがかっこいいです。
かっこよかったですか!? うれしいです!!
ウチでもやる!
やりましょう!!!
時間のある時にゆっくり話をしたい。
是非おねがいします!!
個人からっていうのが大事ですね。最後のまとめが良かったです。
やぱり自分が良いと感じていないと広められないと思うので、個人からは大事だと思います。
アツイ講義で胸に響きました!色んな人がいますね。
ありがとうございます。
同じ人はいないですからね!!
テンポよくてよかったです。見積を予算調達時と実装時それぞれでおしえていただけるとうれしいです。
今のプロジェクトは途中から入ったので予算調達時はわかりません＞＜
もしも次に経験出来れば発表したいと思います。
も少し時間が長いとよかったですね....
すいません＞＜
もうちょっと時間調整頑張ります＞＜
うまい。
ありがとうございます!!
つきものが落ちた気がします。ありがとうございます。
おぉ、そう言っていただけて良かったです。
こちらこそありがとうございます。
3周目の意味がよくわかりました。
はい!!
高速道路の設置です!!
以前、社内で反対された自分にとって興味深いお話でした。
反対されてしまったのですね……
でも諦めずに向かっていく意志です!!!
なんで髪が赤いんですか?
http://okyuu.com/ja/special/engineer06-yoshiori
ここに答があります!!
もうちょっと具体的な中身を聞きたかった。
すいません。
具体的にはどのへんの具体的な内容が欲しかったでしょうか?
人月見積りとSPとの違い、偉い人への説明をどのようにされていますでしょうか。
偉い人が理解してくれればそのまま説明、人月での見積りが必要であれば、チーム内では SP で運用しつつどこかでトランスレートするかなぁと思います。
映像ビジュアルがキレイ。
keynote のおかげです＞＜
「TDDが品質を担保しない」は大変腑に落ちました。有益な書籍情報ありがとうございます。
ありがとうございます!!
お役にたてて幸いです!!
お題目やmust itemの話だけでなく、「正直ベースの話」がよかった。「ペアプロきつい」って人も多いけど、何をこわがっているか、実は こわくないんだと解きほぐす話だとも思った。GJ!
ありがとうございます!!
ペアプロ楽しいですよね!!
XP等のプロセスを導入する際の、上層部の説得の仕方を教えてほしい。
上層部に理解が無かったら見せないで導入しちゃうのはどうでしょう?
まず始めることが大切だなと感じました。個人からXPを始めてみます。ありがとうございました。
ありがとうございます。
小さな事でもまず始めるのが大事ですよね!!
vimでTDDを快適に行うにはどうすればいいでしょうか?例)ソースを保存したタイミングでテストが起動するにはどうすればいい?
emacs 使いなので vim でどうすれば良いかはわかりません＞＜
File の SAVE をフックして Growl に表示とかが快適です!!
面白かった。小さく分割するのが基本ですね。
基本です!!
僕は頭良くないので大きいとわからないんです＞＜
感動した!TDDを今すぐやりたい!
やりましょう!!
TDD!! TDD!!
TDDはテスト手法と理解していましたが、誤りであり、開発手法であると認識できました。また、開発上の不安を取り除くToolでもありますね。
D は development の D! ですね!!
僕は最近は TDD でないと不安で開発出来ないです＞＜
大変参考になりました。まずは個人で導入してみようと考えます。
ありがとうございます!!
導入しましょう!!
とても楽しく聞かせていただきました。質問なのですが、TDDとDbcのかね合いについて、どのような考えをお持ちでしょうか。
すいません。Dbc は勉強してないので正直わからないです＞＜
わっしょい。
おにぎりワッショイ！！ ＼＼ おにぎりワッショイ！！ ／／ + + ＼＼ おにぎりワッショイ！！／+ + . + ／■＼ ／■＼ ／■＼ + （ ´∀｀∩（´∀｀∩）（ ´∀｀） + （( （つ ノ（つ 丿（つ つ )） + ヽ （ ﾉ （ ヽノ ） ） ） （＿）し' し（＿） （＿）＿）
プランニング、ポーカーやってみたいです!「TDDとUnitテストはちがう」目からうろこでした。自分の中でUnitTestを書くこと=TDDにいつの間にかなっていたことに気がつきました。
僕も最初、UnitTest になってしまっていて、TDD から離れてしまいました。
違うという事に気づくとそこからは早いですよ!!
とても良かったです。ドワンゴ入社したくなった!
是非!!
http://info.dwango.co.jp/recruit/
☆品質管理のためのテストは別にすべきという事ですか?自動化の中に「混ぜてやってしまえ」という意見はどう思いますか @eakeshinocla
自動化の中に入れて修正などのコストとの兼ね合いがとれれば良いと思いますが、
逆に僕は別にすべきだと思っています。
(開発中のリズムを崩さないために)
今、自分達のやっている事と重なって、共感できました。
ありがとうございます。
是非おはなしを聞かせてください!!
迫力あるプレゼンでとても楽しめました!おかし箱からTDD、アジャイル見積まですぐにでもチャレンジしたいと思いました
是非チャレンジして結果を教えてください!!
まとめが普通ではないでしょうか。3週目ならではの知見を聞きたかったです。
普通ですいません＞＜
今後はもうちょっと意識していこうと思います。
うちの会社でも出きそうな気がしました!
やりましょうやりましょう!!
是非結果を教えてください!!
会社ではコテコテの金融を相手にしているので、ウォーターフォールですが、自分PCではコッソリトイロイロ動いています。自分だけでも XP、TDDというのは、すごく気づかされました。大変おもしろかったです。パワポ(keynote?)を操作は何でしていたのですか?手元を気にされていたので、興味があります。
「コッソリトイロイロ」応援します!!
keynote は iPhone で操作していました!!
自らに能力が無いと知ったとき、道はあるのか。
僕も自分に能力が無いと自覚しています。
自覚しているからこそ才能ではなくスキルを身に付けようと思っています。
AppleRemoteではないようですが何を使っていたのですか?keynoteですよね?1400人月とかいうProjectやってるんですが、そんな ProjectでもXPできるでしょうか?Buildだけで20分かかるのでTDDだと1サイクル何分かかるか・・・
それだけ大きいと別のプラクティスが必要だと思います。
僕は勉強していないのですが、IBM などがそういった事例を紹介していますので
参考になるかと思います。
ユーザさんの意向で追加修正以外のソースの変更が認められないため、リファクタリングできません。このような状況をどう変えていけるか悩んでいます。あと、iphoneでプレゼンを再生するツールがあるんですね。いい感じなのでパクらせてください。@twmarron
リファクタリング出来ないのはキツいですね……
iPhone でのプレゼン パクってください!!
(僕もパクリなので!!)
見せ方が面白い。わかりやすい。「老言」のくだりは不要。「再利用」を意識して避ける必要はないと思う。ここにコストがかかる。 最初TDDの定義がちょっとわからなかった、テストファーストじゃないの?とかUTは入らないんだ?とか。参加して勇気が出てきた気が します。
「再利用」を避けるのではなく「再開発」を避けるのです。
「再実装」も勉強になるので避ける必要は無いと思います。
本を読むだけでは分からないような、XPの細かな実践を聞けたので良かったです。講義のやり方も他の方と大分趣向が異なり、面白かったです。
ありがとございます。
細かな実践は今後もドンドン公開していこうと思います。
プランニング・ポーカーの話が具体的に参考になった。なかなか全員のカードが揃わないこともあり、難しいと思ったこともあったので。 TDDの話がわかりやすかった。特に目的(品質ではなく開発のしやすさ)。ただ、TDDのコードを最終的にUnitTestに流用することはあ るのではと少し疑問に思った。面白かったです。ありがとうございました。
TDD を最終的に UnitTest に流用する事はあるかもしれませんが、
それはまた別の話だと思っています。
TDD の時に UnitTest やカバレッジ 100% などを気にする必要は無いと感じています。
チーム開発もほとんどなく、個人で黙々と作って行き詰っていたので、目からウロコでした。TDDとペアプロがんばってみよう。おもしろいセッションありがとうございました!
こちらこそありがとうございます!!
一緒にがんばっていきましょう!!
よしおりさんのブログ見て来ました。平日なので難しいかと思いましたが、休暇とれました。大変参考になるお話がきけて、きてよかったです、ありがとうございました。 SLowTestについて 今のプロジェクトはハドソンで1時間ごとに本体コードだけビルド、ナイトリービルドで単体テスト、結合テストをしていますが、プロジェクトが大きくなりナイトリーのビルドが1晩でおわらなくなっています。とくにDBなどを使ったテストではないのですがいい解決案がありますか?
SLowTest 問題については僕もまだ全然勉強不足なのですが、
色々研究されているようです。
もっと勉強したら公開したいと思います!!
自分がやってる(?)だろう、アジャイル開発の後押しをして下さるような内容だった。会社の人にも聞かせたい、良い内容でした。見積りは数イテレーション回さないと、1年後にできるorできないが答えられないということでしょうか?プロジェクト初期時に要求が完了するかどうかはやはり、お客様には答えられないものですか?
プロジェクト初期時に要求が完了するかどうかがわかってそのとおりに納品出来る方法があるのであればそちらを使うべきだと思います。
お客様への説明に関しては「アジャイルな見積りと計画づくり」に書いてあるので一度読んでみる事をおすすめします。
見かけによらずしっかりとした内容を話していたので少し驚きましたが、勇気をいただいたように思います。会社の中でアジャイルの流布を進める立場にいる者ですが、今回の講演をヒントにさせてもらいます。ありがとうございました。
おぉ、社内に流布してるのですね!!
是非結果を教えてください!!
ZENを取り入れられていたスライドがよかった。TDDでテストを作成している時間は最大でどれぐらいか知りたい
最大でですか……
完全に開発にくみこまれてるので計測した事はないのですが、
あまりにテスト作成に時間がかかっていたら相手にしている対象が大きすぎるんじゃないかと疑うようにしてます。
具体的な失敗例などが大変為になった。
ありがとうございます。
今後もいっぱい失敗していこうと思います。
もっと長時間話を聞きたい。
いつでも言ってください!!
一晩でも話しましょう!!
とても面白いセッションでした。今TDDを中途半端にやりはじめているのですが、「不安なところをテストする」という意味で間違っていなかったかと安心しました。世の中変えたいので、まず自分からやって広めていきます
ありがとうございます!
「不安をテストする」は僕も id:t-wada に言われて目から鱗でした!!
パワポがすばらしかったです。どうやって作ってますか?
普通に keynote でガリガリつくってます!!
おっしゃりたいことがすごく良く伝わりました。でも、原典は大事ですし、歴史も大事だと思います。(人類は間違いをくり返すので)* Googleの人が前日に「分割して統治せよ!」とおっしゃられていたことを思い出しました。
原典は大事だし歴史も大事だと思います。
ただ、それを勉強しなきゃ駄目だっていうのは僕は言いたくないなぁと思います。
品質を求めるためにやるわけではないとか、結果を求めてはいけないとか、今日話しを聴くまで少し忘れていました。思い出せて良かったです。Trac+Hudson+Sonarを社内で使い始めて最近楽しいです。テストファーストではないですが、TDDもやっているので、あらためて言っていることに感じるものがありました。
僕も良く忘れそうになるので心に留めています!!
Hudson など使うと開発の楽しさが倍増しますよね!!
「TDDで品質が向上する」の論拠がうすいと思った。品質を担保しない開発手法であることは理解できます。TDDの範囲外であるUT,品質保証はどのような方法で行っていますか?自分たちのやっていることからもう少しふみ出せば同じレベルで開発できるという「勇気」 をもらいました。
品質の向上は言葉では表現しにくく実際に感じてもらわないと共感しにくいところなのですが、説明不足ですいません。
UT,品質保証は現在はテストチームが別にいてやっていますが、本当はチームに組み込んでもっと一緒にやれたらなぁと思っています。
声もテンポも聞き易く、眠くならずに集中して聞けました。XP,TDDは良さはわかっているものの、なかなか業務に導入ができませんでし たが、本日聞いた話で少し勇気をもらえました。私の会社の部問では、なにか良くないことがあると「プロセスがプロセスが...」と文書やルールばかりが増えていっているのですが、ドワンゴ社の話を聞くとその具体策(ツールを使うなど)を展開されているようで大変良いことをしているなと感じました。また勉強会で集まる人達がいることはうらやましくも思いました。(自分の所はなかなか集まらない。集まっ ても聞きにくるだけとか。)
ありがとうございます。
たぶん、ドワンゴは文書やルールを作ってもその穴を見つけて楽をする事しか考えない人の集りなのでツール化しちゃうんだと思います。
勉強会は社内で集らないのであれば社外でやっちゃうのも手だと思いますよ!!
