いつ運行再開するかわからない状態でのアナウンスに対して腹を立てたことがない者だけが石を投げなさい

否定的な発言をする人の真意を探ろう | サイボウズ式

いい話。

絵画教室あとれす横浜-カタチのとらえ方

「封筒」という名前で紹介されているアタリのつけかたが目からうろこ。
アタリをどうとるか。軸や骨格がキモならそれで、面とかマス感とかが大事ならそちらで、という使い分けか。軸や正中線を描けば重心が正しく描けるかもしれない。面を出すには稜線に接する直線をひくところから、徐々に削り込んでいけばいいか。軸を後から引いて角度に狂いがないか見るということはあるかもしれない。

2011-01-27 DevLOVE Test DayでのRyuzeeさんの講演：テストについて考える

  • ソフトウェア開発はコンテキスト依存性が高いので、チームでよく話し合うこと
    • 対策がよく話し合うことというのがアジャイルらしくてよい
テストの目的と価値
  • 品質って何だ
    • 単にバグがないことではなく（ないにこしたことはないが）、ビジネスの役にたつこと（アウトカム指向で）
  • テスト範囲や内容の決め方
    • 範囲は、目的、ROI、リスクに依存する
    • 範囲と内容、完了条件は、どのような方法手法であっても重要
テストの手法
  • 自動化テストの要件：RISE
    • 繰り返し可能(Repeatable)：何度でも実行可能、冪等
    • 独立性(Independet)：環境、外部コンポ、テストケースの実行順序等に依存しない
    • 自己検証(Self validation)：成功失敗はプログラムが判断する
    • 簡単実行(Easy)：準備に大量の時間や人手がかからない
  • レガシープロジェクトへの導入
    • 結合テストレベルのテストを先に作る（外堀から埋める）
テストのコスト
  • 自動化テストの作成コストは高い
    • ペイするかどうかで考える。何回実施するか。作ると決めたなら、使い倒したほうがおトク。
    • 作りきりのプロダクトなのか、エンハンスがあるのか。エンハンスがあるなら、手動テストで品質を確保するコストは高いことを意識する。
テストの結果の評価
  • 第一象限での自動評価
    • テスト件数と結果、静的テスト警告件数、コードカバレージ
  • チーム活動の評価
    • コード行数の変化を見る
    • コミットの曜日、時間、人のかたより
  • テスト結果の評価はチームと顧客がする。
    • SIerの社内品質基準での画一評価は顧客にとって意味がない
    • 社内の品質管理部門には、プロジェクトの後半に重箱の隅をつついてもらうのではなく、プロジェクトの初期に要求にあわせたテーラリングを手伝ってもらう。
メモ
  • ウォーターフォールモデルの課題
    • 品質の確定が工程の後半にやっと始まる。中間生産物は動作しないので（アウトカム指向的には）テストできないから品質はまったく未知数。だけど、ウォーターフォールでは、中間生産物を静的テストして品質が確保できているとみなす。アーンドバリューならぬアーンドクオリティ。それ意味あるんかという批判。
  • コードカバレージはあるところでコスパががくんと悪くなる。この壁のあたりを目標値にするといい
  • 外注（委託）の場合、完了条件（テスト観点、評価方法、評価基準）を具体的にして合意しておくとともに、工期中いつでもチェックできる環境を用意する。

派遣で人員調達の場合も、チームのやりかたをちゃんと伝える（それができる人を採るのと、採った人にはちゃんと理解させる）

Scrum in 10 minutes by Yasunobu Kawaguchi

  • Scrumはシンプルなフレームワークとして、生成物と会議体と役割というキー要素を説明している。これが最初にあるとその後の説明が聞きやすい。あとサイクルもあってもいいかも（資料では次のページにあるけど）。
  • 役割の説明がいい。役割はロールであり、自然発生するものであり、アビリティであると。
  • 形にしばられないこと。