2011/10/29_レビュー祭り( #review_fes )

Kazu SUZUKI @kz_suzuki

東洋大学@白山。みなさん会場設営中。ありがとうございます！#review_fes

Kazu SUZUKI @kz_suzuki

入り口に、英語で話している人多数で怯えた。グローバルな祭。 #review_fes

Kazu SUZUKI @kz_suzuki

細川さんを捕捉！ #review_fes

suzuki shingo @giantneco

今日参加する勉強会はなんか門外漢っぽいのでついていけるかどうかちょっと不安 #review_fes

close_yutori @kimukou2628

#review_fes レビュー祭り 参加中・・。 http://t.co/o7tRmMq1

close_yutori @kimukou2628

#review_fes レビューはみんな遣っているけど＝＞うまくいっている実感がない ＜＝原因は？） ・レビューの自由度の高さ ・かちかちの処と自由な所 等色々とあるとのお話

close_yutori @kimukou2628

#review_fes 「レビューの方法に関する良い方向の切っ掛けを作っていきたい 」 という趣旨で開催したとのこと

ゆとり🇺🇦 @megascus

#review_fes 遅刻ちゅう

close_yutori @kimukou2628

@kyon_mm USTはなさげですね・・。自分も凄いイベントだと思うのでちょっと残念かも～ #review_fes RT うらやま

ゆとり🇺🇦 @megascus

#review_fes 迷いちゅう

close_yutori @kimukou2628

自分も凄く迷いました＞＜（10分以上RT @megascus: #review_fes 迷いちゅう

close_yutori @kimukou2628

#review_fes 「アジャイルインスペクション ワークショップ」 講演開始中～

close_yutori @kimukou2628

#review_fes レビューの目的） ・レビューの本は結構多くない ・ドキュメントの欠陥を発見する＜これが共通して書いてある ＝＞工夫する（チェックリスト：20～50くらい）凄く多い人：500くらい～＜登壇者の方は400個ぐらいを経験したことがあるらしい

close_yutori @kimukou2628

#review_fes 欠陥・・早いうちに探そう＜＝これがレビューの一番も目的 テストと同じ感じ） ・限られた時間の中（テスト設計、実施） ＝＞バグは0に出来ない ＜＝取り除いた保証をすることが出来ない、網羅的に抽出することは難しい

close_yutori @kimukou2628

#review_fes 観点に関して） ・自分が居る立場によりフィルタリングかかかってしまう 例）開発者、テストエンジニア、営業、保守 それぞれの立場の観点

close_yutori @kimukou2628

#review_fes テスト計画） ・今回何を遣るか ・今回何を重視するのか

close_yutori @kimukou2628

#review_fes レビューをちゃんとやっていこうとは？） ・反省会、分析会で ＜＝レビューが不十分でした ＝＞要求仕様書（上流ドキュメントの）：A4を40ページぐらい （2日ぐらいで読む＝＞担当割り振り＝＞1週間ぐらい＜ページ1枚10分）

close_yutori @kimukou2628

#review_fes 1ページあたりの要求仕様書の読むレベルが少ないと＝＞バグ件数が指数的に上がる ＝＞15-20分が理想とは本には書いてあるけど・・・（CHECKING RATE

close_yutori @kimukou2628

#review_fes 工数がないときにどこの工数が削られるか） ・要求仕様レビュー ・テスト工程 ＜＝スマホ開発なんかまさにそうですね・・。バグあっても速く出すのが重視みたいな・・

close_yutori @kimukou2628

#review_fes アジャイルインスペクションの目的） ・はじめから高品質なドキュメント（仕様書、要求書）を作る 具体的にどうすれば？） サンプリング＝＞ロギング＝＞修正＝＞サンプリング の繰り返し

close_yutori @kimukou2628

#review_fes ・サイクルは3回ぐらい回す ・重要なのはサンプリングです ＜－ルールを3つに絞り込んだだけでもかなり出てくる

ゆとり🇺🇦 @megascus

#review_fes るーるか。確かに。レビューの時の指摘は同じようなのが多い。

close_yutori @kimukou2628

#review_fes ドキュメントを書く意義） ・仕様＝＞文書化表現＝＞他の人に伝える為に作る 最低限押さえること） ・ココだけはマストを明確化する ・曖昧じゃないか（曖昧じゃない所を探す）、明確か

close_yutori @kimukou2628

#review_fes 曖昧と不明確） ・日本語自体が曖昧な表現が多い 「曖昧」定義） 例）「ドラゴンズに勝って欲しい」 ・ドラゴンズファン：ドラゴンズに ・巨人ファン：巨人にもかって欲しい を包括してしまう

close_yutori @kimukou2628

#review_fes 「句読点の数＝＞曖昧さの評価に使える」 ＝＞自信がない、複数の意味を含ませている ＜＝「多義文」 ・書く人 ・読む人 が複数の意味を感じてしまう＝＞結構危険