公式サイト
http://xpjug.com/xp2014/
場所は早稲田大学理工学部です。
今年は申し込みが245名あったようで、大盛況ですね。
今年で３年連続の参加です。
ちなみに去年と今年は、関西のXP祭りも参加したのでした。（たまたまGWで実家に帰省するタイミングだったので）
そんなわけで、この日も朝から早稲田に向かうのでした。
XP祭りに向かっている。Scala祭はニコニコでタイムシフト予約済み。
— makopi23 (@makopi23) 2014, 9月 5会場に到着すると、今年も協賛各社様から提供された書籍の山が！
一昨年も去年も最後に書籍を戴けたので、今年も楽しみなのでした。
今年はどの本を戴こうかな、って優先順位を付けてみたり～
そして受付で配布される資料 その１ 「
クリアファイルの中に入っていた
あじゃいる辞典「アジャペディア」の紹介資料だそうな。
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祭りの１週間後のツイート。こちらも参考になります。
XP祭りで、なぜマネジメントやアーキテクチャの話からアジャイルの話をしたのか、というエントリを書きました。 「アジャイルが否定したものを見直そう - arclamp」 http://t.co/BVHkSL3QbD #xpjug
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2014, 9月 13■[B-5] スクラムの勘所【講演】
14:00～14:45 津田 義史さん
http://xpjug.com/xp2014-session-b5/
スプリントの正体 from Yoshifumi Tsuda
スライドは公開されていないようですが、セッションの内容はデブサミ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の詳細は以下のブログで詳細に掲載されているので、そちらにお任せ～
書いた！(リアルタイム更新してたけど、感想がついさっき書き上がったので)【ミッションたぶんPossible】XP祭り2014に参加してきました。 #xpjug http://t.co/pqjj3ngmKm
— Admiral Sir.Takigawa (@takigawa401) 2014, 9月 7横浜道場のてらひでさんと砂田さんのトーク、面白かったw
今年のLT祭りは登壇者も多く、とても楽しく勉強になるヒトトキだったのでした。
■[A-9] クロージング
18:30～19:15
最後に締めのクロージング。
アジャイル関係のイベント告知タイムと平行して、参加者への書籍の配布が行われました。
XP祭り初参加者、登壇者、アジャイル経験年数、といった要素を考慮して順に書籍を選ぶ権利が与えられます。
私は今年は、ラズベリーパイの書籍を戴きました！
最後のクロージングでラズパイの書籍いただきました！感謝！ #xpjug pic.twitter.com/wdH8XZ0OEL
— makopi23 (@makopi23) 2014, 9月 6これは嬉しいですね。ちなみにラズパイの勉強会も先日参加したりしてるのでした。
5/31(土) 「[初心者向け]第一回ラズベリーパイ一緒に動かしてみようじぇ～」に参加してきたのでブログ書きました。 makopi23のブログ： http://t.co/9E5clrEGim
— makopi23 (@makopi23) 2014, 6月 2■ 感想
今年も大満足なXP祭りでした。セッションの質も高いし、何より参加してて楽しいし、元気が貰えるイベントなのである。
そして来年も是非参加したいと思うのです。
今年もなんとかブログに書いて、いろいろ復習も出来たのでした。
スタッフさん、登壇者さん、関係者さん、皆様ありがとーございました。
- 関連記事
-
- 「『はじめてのClojure』勉強会#3」に参加しました
- 「XP祭り2014」に参加しました
- SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました
