Embedded Files
第5章 典型的なプロセスの移行(P73)
5.1 軽量プロセスを探す(P74)
「進捗を測ることや、欠陥を追跡すること、テストを計画することは依然として重要」
「また、組織品質モデルに合うように準備することも必要」
なるほど。（ヤマモト）
5.2 指標(P74)
「指標は使い方によってはチームに方針をもたらし、目標に向かって進捗を測ることができ」る、と。なるほどなるほど。（ヤマモト）
5.2.1 リーン指標(P74)
P.74 「リーン指標の基礎は、「コンセプトからキャッシュへ」の期間です。つまり、顧客のフィーチャ要求からソフトウェアを提供した期間です。この指標は「サイクルタイム」と呼ばれます。」 リーン本ではリーン指標という言葉は使われていませんね。あと、「サイクルタイム」という言葉は重要ではなく、リーンで重要視されているのは「バリューストリームマップ」であり、それを元にカイゼンに繋がるのが、待ち行列理論をベースとした「サイクルタイム」の短縮であると思います。 (Ｙｏｕ＆Ｉ)
5.2.2 なぜ指標が必要か？(P75)
「指標を・・よい理由があります。一方悪い理由もあります」の意味がわからない。「理由」でなく「指標の収集・追跡の悪い例(運用)」ならなんとなくわかる(あな）
P75「よい指標を・・とんでもない方法で使う」の意味がわからない。P77L5にも関係?(あな)
P.75 「道から外れかけていると教えたり、または順調に進んでいるとフィードバックを与えたりする時、指標は収集する価値があります。」
P.75 「個別の指標に注目することより、ゴールやゴールに向かおうとする姿勢に注目するべき」。（ヤマモト）
P.76 「バーンダウンチャートはを含む指標は、罰則の形式や責める元ネタに使うべきではありません」 よく言われる事だけど、自分は結果に対して何か言われた事が無いですね。そもそも指標を使っていないだけかもですが。 (Ｙｏｕ＆Ｉ)
P.76 「覚えておかなければいけないことは、指標は動機付けに使うべきで、チームの士気落とすためではない」「指標ではなく目標に向かえ」 指標が目標になりそうなものですけどね。 (Ｙｏｕ＆Ｉ)
5.2.3 指標でやってはならないこと(P77)
結局何をやってはいけないの？
個人やチームの業績評価に指標を使うのは出来ればさける．使う場合は統計情報を正しく理解する．
コード行数や欠陥発見数を合計数や密度といった単純な方法では使わない．
という認識で OK? （いじゅういん）
→評価ができなかったり動機づけできない指標を使っていけない(P76)を繰り返して書いているのでは？(あな）
5.2.4 コミュニケーションの指標(P77)
P.77 「可視化」 TPSだと「見える化」。この前「見える化」という言葉が気持ち悪い「可視化」で良いでしょ。とTwitterで呟いている方がいた。 (Ｙｏｕ＆Ｉ)
P.77 欠陥発見数が規模に対して少なすぎる場合、「テストケースの妥当性を疑うべし」と言われたことがあります。
これは、テストの観点に漏れが無いかをいちど振り返ってみよう、という意味ですが、各種指標の適切な活用の仕方について、この章では具体的には
触れられていないようです。（岩井）
5.2.5 指標の投資収益率（ROI）(P78)
5.3 欠陥の追跡(P79)
P.79 「欠陥追跡システムでまだ欠陥を追跡していますか？」 欠陥追跡システムを欠陥追跡以外の目的で使い始めたら本末転倒である。 (Ｙｏｕ＆Ｉ)
5.3.1 なぜ欠陥追跡システム（DTS）を使うのでしょうか？(P79)
DTS: Defect Tracking System だそうです．（いじゅういん）
P.80 「知識ベース」 欠陥情報を残す目的の1つは、これですね。 (Ｙｏｕ＆Ｉ)
P.81 「顧客支援」 リリースでの修正内容は気になりますね。 (Ｙｏｕ＆Ｉ)
P.82 「反復期間の後に発見されるのでなければ、バグは欠陥として数えられるべきではないと考えています」 ウチの職場でもそうですね。ITSとBTSを分けて利用する形です。 (Ｙｏｕ＆Ｉ)
P.83 「リーンの原則に従えば、この欠陥のリストは無駄です。」 この訳は・・・。リスト自体が無駄なのか、リストに挙がった欠陥が無駄なのか。後者だと思いますけど。 (Ｙｏｕ＆Ｉ)
P.82 トレーサビリティ（追跡可能性）
（スペルミスのようなものを除いて、）発見された欠陥がテストケースに紐付かない場合、次回以降のテストケースの改善に使用することもあるのでは？（岩井）
5.3.2 なぜDTSを使うべきでないのか？(P82)
『バグ追跡システムは単なる「隠れた積み残し作業」(secret backlogs) だといういうことです。』
どういうことですか? （いじゅういん）
5.3.3 欠陥追跡ツール(P83)
使いやすさはすごく需要．5.3.2 にもあるように DTS への入力は無駄な作業のひとつなので，より簡単に入力・操作ができるものにするべきです．
普段とても使いにくいツールを使用しているため特に実感しています．（いじゅういん）
P85リサの話は相変わらず何がいいたいかがわからない。日本語訳がへたすぎる。
保守費を払っていなかったDTSの新バージョンが使いやすそうだったので、保守費を払ってバージョンアップしたと言っている？それって安くすんで操作性が変わないなんてあるのか？新規購入より決裁を通しやすいだけな気がする。(あな）
P.85 「間違ったツールを選んでしまったら、すぐに使用をやめて、代わりのツールの調査を始めましょう。」 ムリ、ゼッタイ。新規にツールを導入するだけでも大変なのに、そのツールが駄目だから、別ツールをホイホイ導入することは難しいと思います。 (Ｙｏｕ＆Ｉ)
5.3.4 集中を保つ(P85)
下から３行目 「混乱のもう１つの大きな原因は、・・」 いつ混乱が議題になっていたのか？ 実務の混乱を言っているのか一般プロセス論の議論の混乱を言っているのか？
「品質プロセスで問題となるのは欠陥追跡の他にはテスト関係の文書作成がある。」程度の意味か？(あな)
5.4 テスト計画書(P86)
5.4.1 テスト戦略vs.テスト計画書(P86)
P.86 「テスト戦略：この文書は参照文書として使われ、またプロセスが変更された時のみ更新されることが必要です。」 何をテストするかテスト方針をまとめた感じ。 (Ｙｏｕ＆Ｉ)
P.87 「テスト計画書：テスト計画を語ればトレーサビリティを語るようになります。」 プロジェクト毎に作成するものだけど、テストにはトレーサビリティ以外のものは含まれないのか？ (Ｙｏｕ＆Ｉ)
テストとトレーサビリティの関係が自分にはわかりません(というかシステム開発でのトレーサービリティがよくわかりません)（あな）
5.4.2 トレーサビリティ(P87)
P.87 「アジャイルプロジェクトでは、この制約はありませんし、機能は小さく、よく定義されたステップで作っています。」 アジャイルでやる場合は、トレーサビリティを使わない。それ以外の方法で顧客要求を満たしている事を確認する。 (Ｙｏｕ＆Ｉ)
5.5 既存のプロセスとモデル(P88)
5.5.1 監査(P88)
「監査の情報提供やコンプライアンス対応に必要ならば、ストーリーを書いて...計画を立てましょう。」つまり必要ならばアジャイル開発のフォーマット（＝ストーリー）に書いて実施しましょうということですね。（ヤマモト）
5.5.2 フレームワーク、モデル、標準(P89)
「改善策を展開する活動にタスクカードを使いましょう」ここでもアジャイル開発のフォーマットを利用することが提唱されています。（ヤマモト）
P.91 「ソフトウェア開発プロセスモデルの中で、アジャイル開発以上に規律が求められるものはほとんどありません」？？？確かにアジャイル開発する上で規律というか念頭に置くべきルールは色々とあると思いますが、コレをやったらアジャイルだ。というのはないですよね。 (Ｙｏｕ＆Ｉ)
下から４行目「標準は単純に目標に対してどれだけ進んだかを計ることができる」P92L1「改善する方法の標準」 意味がわからない。目標に対して計るのは指標では？
この場合の標準って何を指しているの？図５－２みたいなの？（あな）
5.6 まとめ(P92)
P.92 「SAS 70監査」初めて耳にした言葉でした。 (Ｙｏｕ＆Ｉ)
4 番目の「■欠陥追跡システムは、コミュニケーションツールとしてあまりにも頻繁に使われていて、不要なバグ情報が入力され追跡されていることは無駄であると考えられています。」
要するに「欠陥追跡システムはコミュニケーションツールではないし、本当に必要なものだけを入力すべきだ」という認識で大丈夫ですか? （いじゅういん）
一番最後「チームに必要なのは・・」 はまとめの文章としては賛成しづらい。品質監査の枠組みは対外的にも非常に重要であり、枠にとらわれない作業はまずいと思う。
チームに必要なのは、品質プロセスの監査要求にこたえる成果物をいかに効率的に(手抜きで、もしくは日常作業の一部として）作るよう、うまい監査計画を監査チームに作ってもらう(もしくは、開発チームの成果物を監査成果物と認めてもらう）よう業務調整をすることだと思う。(あな)
Page updated
Google Sites
Report abuse