下記祭りに参加したので個人的メモで振り返る
TDDハンズオン
スライドはこちら
TDDにおけるテストは、所謂品質保証のためのものとは目的が異なる
開発促進、設計行為を目的としている。
また、開発ツールとしての側面が強い。
testingとcheckingの二種類のテストがある
Checkingはブラウザやコマンドの実行確認。
Testingは様々な入力パターンの網羅、セキュリティやパフォーマンス、QAなど。
TDDに関する論文
調査に協力したエンジニアの半数が、総合的な工数が減少すると答えた。
実装時間は増加するものの、デバッグ時間が減るためである。
テスト駆動開発の本はか読んでおくとベター
TDDの目的は動作するきれいなコードを書くこと、そこを履き違えてはいけない。
動作する汚いコードをきれいにリファクタするための命綱として、テストが存在している。
発表者のTDD使用感
- コードが研磨されていく感覚がある。
- テストがあることで、面倒なデバッグが減った。
- 仕様を早い段階から深く考えることができるようになった。
Q&A
Q
TDDをどうやって導入したか
A
自分の責任範囲で始めて、いい感じに回り始めたら周りに伝達という具合で始めた。
周りに伝えてやっていくというより、自分がお手本になってやっていけば良い。
発表者のブログポスト
俺達の新人教育
永和システムマネジメントさんの新人教育についてのセッション。
新卒の人を育てるにあたってどういうことをしているかが参考になる。
新人の教育って一対一が適切なんだなと実感。
対談形式の講演はあまり見たことがなかったため新鮮に見えた。
スライドはこちら
俺達のプロジェクト再生計画
スライドはこちら
信頼貯金が大事
信頼貯金が少ないと、大したことのない問題が大きくなりすぎてしまう。
技術の問題を人で解決する
仲が悪いチームだと言いたいことを言えないため、心理的に安全な環境を構築する。
そのために下記のようなこと行を行った
- 二ヶ月に一度の面談
- 分報
- 相談文化
などなど
分報
分報は、各人が情報を気軽に流しているため、新しい情報のキャッチアップとして使えることがある。
また、誰かが何らかの問題にハマっているときに早期解決が可能となるため、問題が大きくなりすぎない。
エンジニアプロダクトオーナーは強い
コードもいじれるので、影響範囲がわかるため、恐れずに変更が可能。
スケジュールの察しがつくため、早い段階からテスト可能。
Agile2016の報告セッション
アトランタで開かれたAgile2016の報告セッション。
参加ハードルの高い海外のカンファレンスの情報をこういった形で聞けるのはありがたい。
モダンアジャイルの4条件
アジャイルマニフェストを、これまで培われたプラクティスをもとに再定義し、バージョンアップしたもの。
- 人々を最高の状態にする
- 素早い試行と学習
- 継続的に価値を届ける
- 安全を前提とする
安全性
安全性というのは、プロダクト的意味と精神的意味の二通り存在する。
プロダクトな安全性は、カンバンやCIなどでカバーする。
精神的な意味ではBlameless Cultureを意味する。
恐怖で縛られた文化では何も埋めないし、良いものも適切に評価されない。
Googleで最も需要視されているのがこのBlameless Culture。
素早い試行
大量で迅速なのフィードバックを通じて成長する。
リーンな考え方。
フィードバックを支えるのが、心理的安全性。
モブプログラミング
チーム全員で行うペアプログラミング。
大きなスクリーンを用意して、コードを書くドライバが一人、それ以外の人は全員ナビゲータとしてコーディングを見ている。
一つの問題に対して、チーム全員でコミュニケーションを取れるのが強み。
NASAの管制室のようなものだそうだ。
個人的まとめ
心理的安全性
心理的安全性という言葉をかなりのセッションで聞いた気がする。
高速に開発するためには個々人が自由に意見を言える環境が必要ということか。
チームでやる以上、仕事におけるコミュニケーションは必須だ。
コミュニケーションの質を高めることは、それに付随する様々なタスクの効率を上げることにつながるのかもしれない。
コミュニティへの参加
こういったコミュニティ活動に参加することで、社外の先輩エンジニアの話を聞けたり、自分と同じことをしている人の意見を聞けたりするので、非常に良かった。
聞ける話は色々で、OSS税の払い方に関するTIPSだったり、仕事に関する話だったり色々。
仕事で忙しいと言い訳をしてたが、社外で色々話を聞くことの必要性を痛切に感じる。
今後もなるべくコミュニティ活動は続けていこうと思う。
来年のXP祭りは最低でもLTかなにかで参加したい。