2014/9/22(月) SQLアンチパターン読書会 「シー・ノー・エビル(臭いものに蓋)」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/15394以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、
株式会社アルティネットさんではなく、今回は秋葉原の
クラスメソッド株式会社さんでした。
@yokatsuki さん、クラスメソッドさん、会場提供ありがとうございます。
参加者は12人かな。
今回は @t_wada さんが諸事情により初の欠席ということで、皆勤賞の行方は makopi23 に委ねられたのでした！
この日は22章「シー・ノー・エビル(臭いものに蓋)」がターゲットでした。
■ 発表今回は @grimrose さんが発表担当でした。
フルスクリーンは
コチラ です。
ログや例外処理に関する資料への参照や考察が入っていて、とても勉強になります。
あと、今回はJavaとScalaで検証用のコードも書かれたとのことで、そちらの紹介もありました。
コードはGitHubに公開されています。
https://github.com/grimrose/SQL-Antipatterns-22
■ ディスカッション今回もディスカッションしたいネタをみんなで付箋に書き出しました。
ちなみにクラスメソッドさんでの初ディスカッション風景はこんなカンジ。
今回は例外設計やログ設計に関するネタが多かったです。以下、個人メモ。
---
■ 契約による設計（契約によるプログラミング、DbC）- レンガ本に載っている。
- wikipedia
- コードを呼ぶ側が事前条件と不変条件を満たす義務を負うことで、呼ばれたコードはその条件が恒真であるとの前提を利益として得る。引き換えに、呼ばれたコードは事後条件と不変条件を義務として負い、呼ぶ側の利益としてこれを保証する。
■ Loan Pattern（ローンパターン）■ ログ制御- ログレベルは開発中はDebug，本番はInfoにすることが多い。
- ログはローテートさせて、バックアップも取る。
- エラーログと正常ログはファイルを分けてる。
- ソシャゲ開発はスピード優先なので、エラーを握りつぶしちゃうことがある。
- VB4時代、ログへ日時を和暦で出力している人がいた。。。
- アプリとミドルでログを分ける。
- ログを日本語で出すと文字化けすることがあったので、英語で出すようになった。
- 昔はログをターミナル経由で見ることがあって、環境によっては文字化けした。
- ログにはエラーコードだけ出して、エラーメッセージは後でエラーコードから突き合わせる、ということをやってた。
- コネクトやリトライ、リソース不足などが発生した時にログを出す設計をしてない人がいるので注意。
■ 非チェック例外の扱い- あるAPIを使っていて、そのAPIが内部で呼び出している共通部品が独自の非チェック例外（javadocに書いてない）をthrowして、呼び出し元まで突き抜けてきた。
- APIは、非チェック例外をcatchしてjavadocに書いてあるチェック例外に置き換えてthrowしなおすべき？
- それとも非チェック例外はそのまま突き抜けさせるべき？
- 非チェック例外は上に突き抜けさせて、フレームワークに処理を任せるべきでは。
■ 富士ソフトのトランザクション問題■ 例外/ログ設計に関するTIPS- APIはあんまり使われないような使い方はしない方がいい。動的型付け言語だと、それで死ぬことがある。。。
- サンプルアプリとサービス（デーモン）の開発は、例外設計がまるで違う。
- サンプルアプリはClose処理を忘れてもすぐ終わるのに対し、サービス（デーモン）は長く使われ続けるので。
- Windowsだと、ログファイルをサクラエディタなどで開くとロックがかかるので注意。
- Javaでログ出力するなら、SLF4J+Logbackの組み合わせが良い。
- 様々なログAPIにはアダプタが用意されてて、どこに寄せるかを決めないといけない。
- log4j2 とか log5j なんてのもある。
- Railsやってるとフレームワークがログを全部やってくれるので、ミドルのログとか見なくなる。
■ コネクションプーリング- 長い時間アイドル状態になると、タイムアウトで自動的に接続が切れる。
- 接続OFFを考慮していないような設計はダメ。
- 接続の生き死にの設定がどうなってるかを確認しておくべき。
- 生存確認のハートビード用SQLは、デフォルトで "select 1 from T" のようになっていることが多い。
- MySQLの"show databases;"はディレクトリを全部舐めに行くので、生存確認をそれでやるとタイムアウトで死ぬことがある。。。
- 生存確認で数秒毎にinsertやcreateを実行するDBMSもあるらしい。
- MySQLのpingは内部的に"select 1 from T"というSQLを実行しているらしい。
■ ログの整形- EclipseのDBViewerはSQLを整形して見れる。
- ログにSQLを出力する際、アプリ側でSQLを改行していると、改行したままログに出力されることがある。
- grepとかするときに、ログは１行に出ている方が良いかも。
■懇親会読書会終了後は８人くらいで「
俺の煮込屋 三蔵 岩本町店」に行きました。
リーズナブルで美味しかった～
★感想：
ログ設計や例外設計に広く話が及んで、とても勉強になりました。
あと、 @grimrose さんのスライドで紹介されてたいろんなコンテンツも、あとで読んでとても参考になった。
契約による設計、infoレベルのログは出力しない、などなど。。。
あとディスカッションで出た、ログAPIはいろんなものがあるのでアダプタで寄せる、という概念は初めて知りました。
ログや例外処理はアプリ開発で必須なので、これだけでいっぱいネタが出てきますね～
次回以降も皆勤目指しておべんきょしようと思います。
みなさんありがとーございました。
■おまけ：過去の「SQLアンチパターン読書会」ブログ1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
http://makopi23.blog.fc2.com/blog-entry-65.html2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-70.html3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
http://makopi23.blog.fc2.com/blog-entry-73.html3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-77.html4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-84.html5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-90.html6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-94.html7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
http://makopi23.blog.fc2.com/blog-entry-97.html8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-105.html9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-109.html10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-115.html11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
http://makopi23.blog.fc2.com/blog-entry-118.html12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-121.html13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-128.html14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-130.html15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-133.html16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-134.html17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-136.html18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
http://makopi23.blog.fc2.com/blog-entry-138.html19章：SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
http://makopi23.blog.fc2.com/blog-entry-140.html20章：SQLアンチパターン読書会 「SQLインジェクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-144.html21章：SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-147.html
2014/9/9(火) アジャイルサムライ横浜道場 「ユーザーストーリーを集める」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/14349以下の書籍をターゲットとした勉強会？なのです。
場所はいつもの横浜、西公会堂 2号会議室です。
参加者は16人くらいかな。通常回にしては多かったですね～
今回は道場主曰く、「ディスカッション自体が参加への障害になっていると考え、フィッシュボール形式にしてみた」とのこと。フィシュボールって単語、初めて聞いた・・・
フィッシュボールとはhttp://biz-trend.jp/kenshu/words/fishball/机を全部部屋の後ろに追いやって、全員、部屋の前に椅子を寄せあってディスカッションする形式です。
ディスカッションを始める前に @trtraki さんによる第6章「ユーザーストーリーを集める」の発表がありました。
@trtraki さんが出してくださったディスカッションのお題は以下のとおり。
その後のディスカッションでは、スタッフさんが議論内容を随時、部屋の前のホワイトボードに書いてくださいました。
取った写真を横浜道場のFacebookに投稿しようと思ったが、ホワイトボードが反射してよく読めないので、そのまんま書き起こしてみる。。。
（参加してない人が読んでも何のことやらわかんないと思います）
■ホワイトボードのメモ- 要件の洗い出し方は？
- ドラマ仕立てにして要求を出している。ユーザと直接話すこともある。
- 何が重要かを聞いて、要求を組み立ていく。その時にコスト面も話す。
---
- 企画の段階でプロダクトオーナーが入って、その人がストーリーを書き出す。
---
- ワークショップで見積もりはやってる？
- ワークショップで見積もり直す。きちんと見積もりを分ける。
- ストーリーだけだと見積もりしづらい？
---
- ユーザーストーリーに近いものを書いている。
- Whyは必ず聞いている。 → 代案を提案できる
---
- ユーザストーリのテンプレートを最初は使っている。
- 慣れてくるとシンプルなストーリーとしている。（プロダクトを理解してきたから）
---
---
---
- 企画はもっとグイグイ来て欲しい。
- 上から言われたから、というのが多い。
- 仕様書の行間が読めない。
- 「なぜ？」の深堀りは2回までが限界？
- 何故何故というより、お客さんは提案してほしいのかも？
- 「ですよね？」と聞くより「ですか？」と聞いたほうが良い。
- ある程度こちらから選択してあげるようにしている。
- 企画と開発が分断される事が多かった。これを解決していきたい。
- 交渉の余地があるとは？ → より良い手段が提案しやすい。
- 仕様書があいまいでもOK？
- テーマは、いくつかのストーリーをまとめたもの。
- エピックは、もやもやしたストーリー？（スプリント内に収まるか怪しいもの）
- INVESTの1と3と5を押さえると見積もりやすい。
- 小さくすると見積もりがしやすい。
- INVESTの4と5は関係あり。
- INVESTのValuable（価値がある）とは？
- INVESTの1と6が大切。検証が出来る。
- PKG開発で、INVESTの3が客の声でコロコロ変化した
- 目的を持ってない人
- 何でするのかを考えていないので無駄な作業をしている
- INVESTの3の価値を考えていない人
最後の振り返り
今回はいつものやりかたと違ったので新鮮でした～
スタッフさん、参加者のみなさん、ありがとーございました。
2014/9/7(日) 「『はじめてのClojure』勉強会#3」に参加してきました。
connpass
http://clj-first.connpass.com/event/8276/以下の書籍をターゲットとした勉強会なのです。
場所は渋谷ヒカリエの真横にある
電源カフェ beez（ビーズ）です。
参加者は5名です。ちなみに初参加の1名さんは英語圏の外国の方でした。
今回、私は7章の発表当番だったので写経＆スライドを作成して参加しました。テーマはTDDです。
@t_wada さんの許可を頂いて、TDDのスライドを2枚拝借させていただきました。
ちなみに私、Clojureは1ヶ月くらい前に初めて触り始めた超初心者です。
書籍「達人プログラマー」にもあるように、1年に1個、新しいプログラミング言語を習得したいなぁ、とは漠然と思っていました。
なので、たまたまTwitterのTLに告知が流れてたのを見て、ではやってみるかな～、と軽い気持ちで始めたのでした。
しかしClojure、やっぱソースコードが括弧だらけになるｗ
今回は６～８章がターゲットで、今回で一通り書籍を読み終えましたので、次回から新しい書籍をやります。
この書籍のClojureの章が次回の範囲です。私は昨日、図書館で借りてきました～
はじめてのClojure勉強会#4http://clj-first.connpass.com/event/8611/次回からは書籍だけでなく、Clojureの問題がいろいろ出題されている
4Clojure というサイトのハンズオンもやっていくそうな。こちらも実践的で面白そうです。
やっぱ新しいプログラミング言語を触るのはワクワクしますね～
2014/9/6(土) 「XP祭り2014」に参加してきました。
公式サイト
http://xpjug.com/xp2014/場所は早稲田大学理工学部です。
今年は申し込みが245名あったようで、大盛況ですね。
今年で３年連続の参加です。
ちなみに去年と今年は、関西のXP祭りも参加したのでした。（たまたまGWで実家に帰省するタイミングだったので）
そんなわけで、この日も朝から早稲田に向かうのでした。
会場に到着すると、今年も協賛各社様から提供された書籍の山が！
一昨年も去年も最後に書籍を戴けたので、今年も楽しみなのでした。
今年はどの本を戴こうかな、って優先順位を付けてみたり～
そして受付で配布される資料 その１ 「
萌えるクリアファイル」
クリアファイルの中に入っていた
萌える資料 その１
あじゃいる辞典「アジャペディア」の紹介資料だそうな。
http://agilepedia.manaslink.com/他にもアジャイル関連の資料など、
萌えるクリアファイルの中にいろいろ入ってました。
会場を見渡してみると、見知った顔もチラホラと・・・
私が参加したセッションは以下のとおり。最初のまんざい、微妙に間に合わなかった・・・
- [A-2] XP祭り実行委員からみなさんへ – 10:30～11:00 川口 恭伸さん、佐野 友則さん
- [A-3] XPの俺 / XP再考を再考する【基調講演】 – 11:00～12:00 関 将俊さん
- [B-4] アジャイルを手放して得られたこと【講演】 – 13:00～13:45 鈴木 雄介さん
- [B-5] スクラムの勘所【講演】 – 14:00～14:45 津田 義史さん
- [B-6] システムテストも自動化していこう【講演】 – 15:00～15:45 永田 敦さん
- [B-7] なぜアジャイル開発はうまくいかないのか？
- 〜ソフトウェア開発の本質とエンジニアの生き方【講演】 – 16:00～16:45 倉貫 義人さん
- [A-8] LT祭り – 17:00～18:30
- [A-9] クロージング – 18:30～19:15
以下、復習を兼ねて、当日取ったメモを書き起こしてみる。（私がブログ書くのは、自分の復習のためなのである！）
■[A-3] XPの俺 / XP再考を再考する【基調講演】 11:00～12:00 関 将俊さん
http://xpjug.com/xp2014-session-a3/この講演で「忍者式テスト」という言葉を初めて知りました。
手動テストでテスト駆動開発するにはどうすればいいのか？が着眼点のようです。
■ 忍者式テスト- ストーリー(チケット)を確認するテストケースを書く。
- このテストがパスしないと完了にならない。
- 毎日すべてのテストを手でやりなおす。
- 「本物をテストして確認しようぜ！」という思想。
■ 忍者式テストの限界- 毎日ぜんぶテストすることが難しくなった。
- そこで、「今日テストするテストケース」を以下のように抽出することとした。
- 完成してから一度もテストされてないテストケース
- 前回Failだったテストケース
- 前回からの経過時間がしきい値を超えたテストケース
- 「毎日全部やる」という基本作戦が合わなくなり、自分たちと向かい合った。
- 合わなくなったなら、変えていいんじゃん。
- テスト系は減らすの大変で、ちょっと脅迫観念があった・・・
■ Cheking vs. Testing- Checking ・・・ 既知の情報の確認
- Testing ・・・ 未知の情報を探す
- 忍者式テストはCheckingを土台にしたテスト。
- 人間がやる。
- アレンジを許す。
- テスト自動実行が逃した部分を拾う。
■ ストーリー- 最初のイテレーションで選ばれるストーリーは未熟であっても、システムの端から端まで(end-to-end)つなぐようなものにならないといけない。
- ほしいものを想像するには、end to endのものが最初にあれば、ホンモノを触って考えられる。
- 想像しやすいストーリーを早くやる。
■ 問題を見つける- 問題はほぼ結合テストで見つかる。では、どうしたら問題が見つかるか？
- 超簡単。できるだけ早く結合テストをすればいい。
- 忍者式テスト・ストーリーごとのテストがうまくいっちゃうのと関係がある。
■ 反復開発- ほしいものを考えるところから、出荷寸前までなんども結合テストをやる。
- なにもかも、上から下まで何度もやることがポイント。
- 普段、１回しかできないものを、なんどもやる。
■[B-4] アジャイルを手放して得られたこと【講演】 13:00～13:45 鈴木 雄介さん
http://xpjug.com/xp2014-session-b4/ この日、私が最もInspireされたセッション！
翌日、会社のアジャイルメンバーにスライドを共有させていただきました。
スライドの後半がアジャイル開発にフォーカスしてたんですが、アジャイルの弊害として以下2点に着眼していたのがとても興味深かったです。
- アジャイルを「言い訳」に使う
- アジャイルのダークサイドに落ちる
詳細はスライド参照。
■ アジャイルを「言い訳」に使う- アジャイルは不確実性に立ち向かうための道具である。
- より良いものを作るための「覚悟」がある人には凄く良い。
- でも、不確実性を受け入れる覚悟がない人間が使うと、自分に責任が来ないようにするための、ただの言い訳になる。
■ アジャイルのダークサイド
- 他人への傲慢や軽蔑、不確実性からの逃避、責任回避など。
- 怖いのは、アジャイルな人とダークサイドな人は、言っていることが同じな点にある。
- 無意識にやる人が多い。
- 覚悟がない人が多い。
- だからアジャイルが嫌いになった時期があった。
■ アジャイルのダークサイドに落ちないために
- まずもって「良い物を作りたい」という覚悟があること。
- その上で、どう作るかにコダワル。
- このセッションで一番言いたかった事は、「良いものを作るためにはどうすればいいか？」を問うこと。
- そうすればアジャイルで作ったかは関係ない。それが「アジャイルを手放す」ということ。
---
アジャイルを言い訳に使う。ダークサードに落ちる。これらは注意しないと本当にハマリポイントになると思います。
あと、「手法を見つけることにはこだわるけど、既存の手法で満足することはない」という言葉が印象的でした。
以下はXP祭りの１週間後のツイート。こちらも参考になります。
■[B-5] スクラムの勘所【講演】 14:00～14:45 津田 義史さん
http://xpjug.com/xp2014-session-b5/ スライドは公開されていないようですが、セッションの内容はデブサミ2014の講演「スプリントの正体」と同じらしいので、その時のスライドを貼ってみる。
津田さんの講演は何度か聞いたことありますし、著書「実践 反復型ソフトウェア開発」のDevLove読書会にも参加してたので、馴染み深い内容でした。スライドにはいくつか興味深い用語が登場してます。
■ 用語： 「バグ修正スプリント」
- バグのみを修正をするスプリントのこと。こういうスプリントを設定するのは良くない。
- それはつまり、バグだらけになる計画をしていることになる。
- ただ、前バージョンのダメ品質を直すために、最初にバグ修正スプリントを設けるのは良い。でも、やらないにこしたことはない。
■ 用語： 「ケイデンス」- 回転の速さのこと。
- ソフトウェア開発では、リリースの速さやビルドの頻度などを指す。
- 短いケイデンスが好ましい。
■ 用語： 「パントする」- 手に持っている作業から手を話して、落ちる前に蹴っ飛ばす。
■ ２つに分ける- スプリントバックログ、プロダクトバックログ
- スプリントタスク、プロダクトタスク
- このスプリントでdoneするタスクが、スプリントタスク。
- スプリントフィーチャー、プロダクトフィーチャー
- このスプリントで作る昨日が、スプリントフィーチャー。
- スプリントバグ、プロダクトバグ
- そのイテレーションで解決スべきバグがスプリントバックログ。
- でもバグをは次々に湧いて出てくるので、２つに分けるのは難しい。
- ではどう分けるのかが「トリアージ」。
■ 用語： 「トリアージ」
- 痛みのひどいものは捨てるのがトリアージ。
- 医療分野の用語で、フランスの医者が戦場で始めた。当初は非難されたが、現在は必要な活動だと認知されている。
- 時間がない状況では、早い段階で治療対象にする患者さんを分けることが大事。
- トリアージでは、深刻度が一番酷いものが一番優先度が低くなる。
- スプリント１の出口が近づいたら、今直せないバグはパントする。
- スプリントで直すと決めたのものはしっかり直す。
- 深刻度よりも大事な指標がある。バグを全部直す、ということにコダワルと、優先度は意味がなくなる。
■ 用語： 「ZTB」- ZTBはMicrosoftでは重要なプラクティスで、ゼロチケットバウンスの略称。
- あらかじめZTBの日を計画し、そこでチケットをゼロにする。
- タイムボックスの出口まで来ちゃったら出口から出ざるを得ない。
- できなかったものは次のスプリントに持ち越すしか無い。それは、そのスプリントに失敗したといいうこと。
- 失敗したら、ちゃんと分析すること。
- どうせ出口ついちゃったなら先送りするしか無い。出口についちゃってから見直すののは頭が悪いやり方。
- 出口が近づいたら見直すべき。わかった段階で見直すこと。
- チケットをゼロにすると決めたら、こだわって欲しい。
- しっかり棚卸しして、スプリントチケットをゼロにすること。
■[B-6] システムテストも自動化していこう【講演】 15:00～15:45 永田 敦さん
http://xpjug.com/xp2014-session-b6/スライドはまだ公開されていない模様。。。
12/14にシステムテスト自動化カンファレンス2014を開催するとの告知がありました。
去年の12月にもカンファレンスありましたが、Seleniumハンズオンはとても参考になった。今年も参加したいなぁ。
---
■ テスト自動化- テスト自動化研究会(STAR)のスコープはV字モデルの上の方の、受け入れテストやシステムテストが対象。
- アジャイル開発では継ぎ足す界面は派生開発のようになり、インクリメンタルな開発ではデグレードは避けられない。
- そこでテスト自動化を自動化する。自動化のメインは回帰テスト（リグレッションテスト）。
■ 価値のあるソフトウェアとは
- 価値があるソフトウェアかどうか、誰が判断するでしょうか？それはお客様。
- お客様に一番近いテストがシステムテスト。そこで見る、触る。
- エンジニアは、システムテストとか受け入れテストで、お客さんが何を見ているかを感じないとテストできない。
- なので、それらをしっかりともっていないといけない。
■ システムテストっていつやるの？- 「実践アジャイルテスト」の書籍では、「The end game」というイテレーションの外でシステムテストを実施する。
- イテレーションを複数回実施して、最後にシステムテストやって出荷する。でも、そう綺麗にいかない。
- システムテストでバグを修正すると、フィードバックがイテレーションにかからない。
- そこで、早期からのシステムテストを考えた。早期とは、Early。
- システムテストもイテレーション内で実施して、自動化できるものはしていくべき。
■ システムテストの自動化とその実施は誰がするの？- 開発者、設計者
- 意欲があるならできる。
- でも彼らの目的は、どっちかというと開発。
- 維持とか管理、保守が増えると、別働隊が必要になる。そこで評価チームの出番。
- 評価チーム
- もっと早いタイミングで評価するため、評価チームがアジャイル開発に入る。
- 評価チームが設計フェーズに飛び込む。
■ 設計リーダーの憂鬱
- 評価チームが設計に入ってくると、開発者や設計者は「いろいろ言われるのではないか」と心配してしまう。
- ドキュメントとかメトリクスとか。
- 設計に余計な負担がかかると、開発者や設計者は構えちゃう。ガードがかかり、お互いにビクビクしてしまう。
- そういうトコに対しては、マインドセット、チームビルディングを評価チームにも与えて取り入れてください。
- 評価チームがテストをしてフィードバックを返す、というサポートをするマインドセットを互いに持つことが大事。
■ テスト設計の重要性- 早期からシステムテストを実施する場合、各イテレーション終了後の時点で、システムテストできるとこは限られる。
- そのため、開発の順序性などで、テストのブロックが起きる。
- なので、テスト計画をきちんと立てないといけない。
- できるところから先にフィードバックを返していく、というのは重要なメッセージ。
- 開発側で考えている計画と、システムテスト側の計画を考えて、互いに合意していくことが大事。
- テストエンジニアが上手くみなさんと計画を調整しながら、コミュニケーションを、開発の部分から埋めていくことが大切。
- これができないと噛み合わない。お互いに効率が悪くなり、仕事が増える。
- テスト計画が噛み合ってないとバラバラになってしまう。
- うまくやれば、それが継続的にフィードバックできる。
- テストできるところがプロジェクトの最後の方で揃うので、最後にドカンとテストが増える。
- アジャイルテスティングはしっかり計画的に、設計と同期してやらないといけない。
- なので設計者とテストエンジニアのコミュニケーションが大切。高度なプロセスマネジメントが必要。
- 完全に同期するというよりは、このイテレーションではここまでに何をしようか、と目的を共有することが大事。
■ ロール- テストエンジニアやテストオートメータはテスト、測定をして、品質を見える化して、設計側にフィードバックする。
- 設計側は要求仕様情報をテスト側に共有する。
■[B-7] なぜアジャイル開発はうまくいかないのか？ 〜ソフトウェア開発の本質とエンジニアの生き方【講演】16:00～16:45 倉貫 義人さん
http://xpjug.com/xp2014-session-b7/ 倉貫さんのプレゼンはいつもユーモアがあって、しかも熱いです。
プログラマを大事にする心が凄く伝わってきて、とても共感しちゃう。
印象深かった話題をいくつか挙げてみる。
■ 脳のブレーキを壊す体験- 社外のコミュニティに参加するようになって、「自分も来るんだ」と思うようになった。
- 「自分も来るんだ」と思えるようになると、殻を破ることが出来る。スポーツの世界ではよくある。
- ただ、社内ではなかなかうまくできず、入社３年目くらいで悩み始めて、専務に相談しにいった。
- 専務からやれと言われた２つのこと。今思えばとても実感できる言葉だった。
- １．外で活動して有名になりなさい。自分の名前で仕事をとってこれるようになりなさい。
- ２．仲間を作りなさい。一人で始めたら一生、一人のままだぞ。
■ アジャイルを社内に広める裏ワザ
- 燃えているプロジェクトに放り込まれた時に、アジャイルの名前を出さずにやってみる。朝会とか振り返りとか。
- それが上手くいってから、「実はアジャイルでした」と周りに言うｗ
- 上手くいかなかったら、アジャイルだった、とは言わないｗ
■ 誰のためのアジャイルか- 大半の人は、与えられた仕事だけやりたいと思っている。説得してもキリがない。
- 人は変えられないけど、会社の仕組みは変えられる。
- 周りのひとを変えようと説得するよりも、会社の仕組み自体を変えないといけない。
■ 社内ベンチャーの開始- 内製なのでアジャイルになった。すごくうまくいった。
- 自分でマーケティングして経営してお客さんに売って、それで投資をして、という経験をした。
- この経験が凄く良かった。
- 開発だけしててもダメで、ずっと赤字で、最初はアジャイルどうこじゃなかった。
- 営業やりたくない、と去っていく人もいた。
- アジャイルよりも大事なことがあることに気づいた。
■ ビジョンとミッション- プログラマを一生の仕事にする。
- 高みを目指し続ける。
- いつまでも、いつからでも夢に挑戦できる社会にする。
- プログラマをスターにしたい.
■ なぜアジャイル開発はうまくいかないのか
- うまくいかない環境にいるからだ
- 理想を語らないと始まらない。
- 行動しないと変わらない。
- 変えるのは世界じゃない、自分だ。
- 理想を語れ。そして行動しよう。
■[A-8] LT祭り17:00～18:30
http://xpjug.com/xp2014-session-a8/XP祭りのLTタイム、毎年とても楽しみなヒトトキなのです。
通常セッションではメモ取りながら傾聴してますが、LTではメモ取らずリラックスして、のんびり話を聞きます。
去年のLTは、佐野さんのラグビーの話が印象深かったなぁ。
今年のLTの詳細は以下のブログで詳細に掲載されているので、そちらにお任せ～
横浜道場のてらひでさんと砂田さんのトーク、面白かったw
今年のLT祭りは登壇者も多く、とても楽しく勉強になるヒトトキだったのでした。
■[A-9] クロージング18:30～19:15
最後に締めのクロージング。
アジャイル関係のイベント告知タイムと平行して、参加者への書籍の配布が行われました。
XP祭り初参加者、登壇者、アジャイル経験年数、といった要素を考慮して順に書籍を選ぶ権利が与えられます。
私は今年は、ラズベリーパイの書籍を戴きました！
これは嬉しいですね。ちなみにラズパイの勉強会も先日参加したりしてるのでした。
■ 感想今年も大満足なXP祭りでした。セッションの質も高いし、何より参加してて楽しいし、元気が貰えるイベントなのである。
そして来年も是非参加したいと思うのです。
今年もなんとかブログに書いて、いろいろ復習も出来たのでした。
スタッフさん、登壇者さん、関係者さん、皆様ありがとーございました。
