主要プラクティス – XP本読書会7回目のふりかえりのふりかえり
By 管理人
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
この時期にSlackでコミュニケーション取り過ぎの問題があって、今思えば自分の使い方も良くなかったと反省。どちらかというとプライベート寄りのチーム、仕事用のチーム、その中間的なチームに参加していて、通知を受けたり書き込んだりする時間帯の切り替えができていなかった感じです。
今でも切り替えができていないので、通知とかステータスの設定を見直してみます。
Slack 通知の仕組み
おやすみモードによる通知の一時停止
さて、まずはペアプロについて。
Agile459ではこれまでにGDCRを3回開催していて、昨年のAgile Japanサテライトではモブプログラミング、そして今年の夏にはTDDBCも開催しましたので、ペアプロの有効性についてはコミュニティの中で共通認識が持てていると思います。ただし「ペアとパーソナルスペース」に書かれているような気配りについてはこれまで意識が低かったと反省。
例えば、Wikiのまとめにも書きましたが、以前使っていたアウトドア用の腕時計。そのバンドの裏側に着け心地を良くするための皮が貼ってあり、どうやらその部分が汗臭くなっていたみたいで臭いを指摘されたことがありました。指摘されたときは分からなくて、その腕時計が故障して買い換えた時に、「あーもしかしたら腕時計のバンドの臭いで迷惑を掛けていたかも」と反省。
自分では気がつかないこともあるので、ペアで作業する際の注意点などチーム内で話し合う機会が適宜必要と思いました。
次に、ゆとり（Slack）
最近、働き方が変わってきているようで、その中で、この「ゆとり（Slack）」の考え方が重要かもしれません。
重要度の低いタスクを含めること
とありますが、これは調整のために外す（対応しない）こともできるし、比較的簡単なものでも実現することで評価につながることもあります。臨機応変に対応するためのタスク。
それと、毎日の仕事の中で集中というか効率よく仕事ができる時間は実際には割と短いものだと思います。タスクを詰め込み過ぎず、ゆとりを持って、それ以外の環境であるとか、スキルアップのための学びであるとか、そういう時間も日々確保することで、より質の高い仕事につながっていくと思います。
そして、インクリメンタルな設計。
新規に取り組んだものは、その時点で要件を満たすことができた試作レベルと割り切って、機能追加とか何らかの改修をする際に、気がついた時点でリファクタリングを進めていくことでより良いものに仕上がっていくと思います。もちろん、リファクタリングを進めるにはテストコードによる動作保証が前提になります。言い換えれば、テストコードによってシステム全体の動作確認が取れる状態になっていれば、いつでも気軽にリファクタリングに取り組むことができます。
という感じで、今日はこのあたりまで。