Blog

主要プラクティス – XP本読書会7回目のふりかえりのふりかえり

Dec 14, 2018

旧サイト記事の移行

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。この時期にSlackでコミュニケーション取り過ぎの問題があって、今思えば自分の使い方も良くなかったと反省。どちらかというとプライベート寄りのチーム、仕事用のチーム、その中間的なチームに参加していて、通知を受けたり書き込んだりする時間帯の切り替えができていなかった感じです。今でも切り替えができていないので、通知とかステータスの設定を見直してみます。 Slack 通知の仕組みおやすみモードによる通知の一時停止さて、まずはペアプロについて。 Agile459ではこれまでにGDCRを3回開催していて、昨年のAgile Japanサテライトではモブプログラミング、そして今年の夏にはTDDBCも開催しましたので、ペアプロの有効性についてはコミュニティの中で共通認識が持てていると思います。ただし「ペアとパーソナルスペース」に書かれているような気配りについてはこれまで意識が低かったと反省。例えば、Wikiのまとめにも書きましたが、以前使っていたアウトドア用の腕時計。そのバンドの裏側に着け心地を良くするための皮が貼ってあり、どうやらその部分が汗臭くなっていたみたいで臭いを指摘されたことがありました。指摘されたときは分からなくて、その腕時計が故障して買い換えた時に、「あーもしかしたら腕時計のバンドの臭いで迷惑を掛けていたかも」と反省。自分では気がつかないこともあるので、ペアで作業する際の注意点などチーム内で話し合う機会が適宜必要と思いました。次に、ゆとり（Slack）最近、働き方が変わってきているようで、その中で、この「ゆとり（Slack）」の考え方が重要かもしれません。

XPのプラクティス - XP本読書会6回目のふりかえりのふりかえり

Dec 13, 2018

Netplan Matsuyama

Developer

旧サイト記事の移行

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。第6章の冒頭に、

「プラクティスとは、XPチームが日常的に行うものである。…」

という説明があって、その後に「…、機械的な作業になってしまう。…」読書会の時にこの部分を読んで、過去に関わったプロジェクトで、テスト工程をペアで手作業で行うというなかなか残念なプロジェクトを思い出しました。のちの改修とか機能追加などを考えれば普通に自動化すべき部分だと思うのですが、リリース前のテストは手をかけて苦労することがルールみたいな感じでした。。。さて、読書会の議論のなかで「どのプラクティスが導入しやすいのか？」という話があって、いやおそらくそういう方法から入るんじゃなくて、何に困っているかという具体的な問題の洗い出しが必要で、それに対して、じゃあこのプラクティスをやってみれば、というようなやり取りがありました。あと、全員同席の部分。過去の仕事場を振り返ってみると、個人スペース、もしくはオープンスペースのどちらかはありましたが、両方を使い分けるような環境はなかったと思います。あと、オープンスペースといっても、単に机が並んでいるだけのごく一般的な職場なので、本に書かれている会議室を占有する感じのオープンワークスペースというのは心に刺さる部分でした。個人が集中して作業できる環境と、チームメンバーが集まってコミュニケーションをしながら作業できる環境。両方があるのがポイント。そして「チーム全体」の終わりのほうにある「タスクの切り替え時間」。いろいろ忙しくて、あれもこれもみたいな状況になるのを仕方ないとするか。いや、その切り替えにはどうしても時間がかかるので、できるだけ一つの仕事に集中できるようにスケジュールなり人員なりを調整するなど。この回の終わりは「いきいきとした仕事」でした。長時間働くのは良くないですね。以前は当たり前のように毎日遅くまで仕事をしていましたが、単に時間をかけてコードを書くよりも、できるだけ短時間で切り上げて、環境を整えるとか、こういう本で手法を学ぶとか、プログラミングのスキルを学ぶなど。それと、健康に配慮して体を動かすとか、そうやって生活の質を上げることで結果として仕事の成果も上がるようにしていきたいですね。

Agile459のコミュニティについて

Dec 12, 2018

Netplan Matsuyama

Developer

旧サイト記事の移行

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。私自身、Agile459のコミュニティに参加して8年ほどになります。おもに @kkd 氏が中心となって、県外から講師を招いてセミナーを開いたり、Agile Japanのサテライトを開催したり、読書会（アジャイルサムライ、エクストリームプログラミング）を開催したりしています。参加するまではアジャイル開発についての知識がなく、キーワードとしては知っていたかも知れませんが、どう実践するとかそういうノウハウがない状態でしたが、毎年の様々なイベントの中で少しずつですが、自分の知識として身について、仕事の中で実践できるようになってきました。今の時代に対しては、自分の進歩のスピードに多少（？）問題があるかも知れませんが…(^^; 少し残念なのは、その年々で参加者が入れ替わっていく感じで、継続して参加している運営スタッフもそれぞれ興味分野が違ったりするので、なかなかコミュニティとしての運営がまとまらない状況があります。例えば特定のプログラミング言語や技術に特化したコミュニティだと、わりと継続的にあるいは定期的に勉強会が開催されるようになってきてはいますが、アジャイルというキーワードだと、対象とする範囲が広すぎるのか、具体的な必要性が見えにくいのか、内容によってはたくさんの参加もあるのですが、イベントが終わると一気に疎遠になってしまう感じがします。前のエントリー今年(2018)のAgile459のふりかえりの最後の部分にも書きましたが、自分の仕事の中ではなかなか変えることができない、あるいは気がつかないことが、外のコミュニティに参加することで気がついて改善につながったりすることもあると思います。仕事の進め方とか、開発方法とか、日常の仕事の中で何か疑問に感じるけれど、何となくそのままやり過ごしていることなど、もしあればAgile459のコミュニティに参加して議論してみると、何か発見があるかも知れません。あと、コミュニティの運営ですが、8年も経つとウェブサイトまわりもいろいろと変わってきて、見直しが必要な時期になっていると思います。ただ、これも仕事や家庭とは別の活動になるので、なかなか時間を取って進めるのは難しい。それと、中に時間が取れる人がいたとしても、その人ばかりが手をかけてしまうと、その人じゃないとわからない（弄れない）状況になってしまって、時間とともに破綻してしまう可能性もあります。このあたりも、せっかくのアジャイルのコミュニティーなので、うまくチームとして回せる環境を作ることができればと、ぼんやりですが考えています。

XP本読書会5回目のふりかえりのふりかえり - 機会とか品質とか責任とか

Dec 9, 2018

Netplan Matsuyama

Developer

旧サイト記事の移行

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会の5回目は5章の後半でした。機会と失敗はつながる部分があって、失敗とか何か問題があった場合にネガティブになるんじゃなくて良い方向に向かせるための機会ととらえることがポイント。反省も必要だけどそればかりではしんどいですし、さらに大きな問題につながる可能性もあるわけで、そうならないうちに気がつけたと思えば良いんじゃないかと。テストケースを追加してみるとか、テストの仕方を変えてみるとか、機能自体を見直してみるとか。あと、失敗したら急いで対処するんじゃなくて、まず失敗した状況を共有。対処できたらまた共有。そうすることで落ち着いて対応できるし、時間がかかったらかかったでエビデンスにもなるし、のちの教訓とかノウハウにもつながると思います。次に品質について。仕事の中で品質を求めることができなくて（あきらめて）、プライベートで品質に対する欲求を満たしていたという話の中で「盆栽」というキーワードが上がって、「盆栽」といえば波平の「ばっかもーん!!」ですよね、みたいなところから脱線。まぁそれはそれで面白かったです。面白かったというか、オンライン読書会の中で一番脳が活性化した瞬間だったかもです。で、品質と責任の部分もつながると思います。誰かの成果物の品質がどうとか、誰かに責任を押し付けたところで、プロジェクト全体としては何の解決にもならないわけで、解決にならないどころかそれこそ時間の無駄。それよりも、プロジェクトのチームとして品質を良くしていくとか、責任を共有することが大切。そうすれば信用とか期待につながりますよね。本の内容とは少し外れますが、この頃に自分の課題として「リファクタリング」というキーワードがあって、なかなか進めることができていなかったのですが、

XP本読書会4回目のふりかえりのふりかえり - 自己相似性とか

Dec 8, 2018

Netplan Matsuyama

Developer

旧サイト記事の移行

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会の4回目は5章の途中でした。この頃は参加者がわりと多くて、その分あまり進まなかった様子。それと、ディスカッションのまとめもSlackのタイムラインをWikiへコピペしていたので、ログがちょっとわかりにくい。後日、記録用にHackMDを使うようになりました。さて、自己相似性の部分ですが、あらためてその部分を読んでみると、わかりやすくて重要と思いました。 _ 四半期単位：テーマを選んでストーリー単位で組み立てていく。 _ 週単位：ストーリーを選んでテストを組んでいく。* 数時間単位：テストを書いて、実装していく。小さなループ(TDD)を繰り返して、ストーリーとして組み立てて、テーマとして完成させるような流れ。なので、小さなループがちゃんと回る（動く）のがポイントですね。あと、「ふりかえり」のところにあった「ソフトウェアプロセスばかり考えている」の部分。方法論にとらわれ過ぎて、生産性に繋がらないのはよろしくないですし、開発のことを考えるのは良いけれど、管理するために資料を作らないといけないとか、プロダクトとは直接関係のない物に対してリソースが消費されるのは避けたいですね。フラットなチームとかフラットな組織であれば、そのあたりの無駄も少なくなると思います。