Skip to content

Blog

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

旧サイト記事の移行

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

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

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

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

旧サイト記事の移行

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

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

旧サイト記事の移行

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

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

旧サイト記事の移行

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

XP本読書会3回目のふりかえりのふりかえり

旧サイト記事の移行

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会の3回目は4章から5章あたりでした。 このあたりで思いつくのは人間性(Humanity)の達成感について。 以前、VBとかC#で業務用アプリを開発していた頃、設計書を読みながらプログラムを書き進めていたわけですが、リビジョン管理やTDDができていない頃で、ソースコード中にコメントを書いて、今日はこの辺までできてこのあたりが未実装とか、プロジェクトフォルダをzipに固めてファイル名に日付を入れてアーカイブとして残したりとか、よろしくない仕事の仕方でした。 そういうやり方だと、最終的にプログラムが完成するまで、ただただ不安な状況が続きます。「〇〇の機能ができていない」とか「△△はどうやって実装すれば…?」とか、そういうモヤモヤしたことがたくさんあるまま、中途半端な状態で切り上げて帰る日々。 完成に近づいて、一通りテストができる状態になって、やっとそういうモヤモヤした雰囲気から少し解放される感じです。なので、仕事の中で達成感を感じることがとても少ない状態でした。 それが、アジャイル開発を学ぶようになって、さらにTDDを経験することによってずいぶんと仕事の仕方が変わりました。比較的小さい単位で課題を設定して、テストコードを書いて実装して red -> green を繰り返す。課題が完了したら commit(push) して close して次の課題へ。 こういうサイクルで仕事ができるようになったので、greenにするとかcloseするタイミングで都度達成感を感じることができます。課題管理の中で、必要になりそうな技術資料などメモっておくこともできますし、テストコードを仕様書と思えば、ソースコード内に必要以上にコメントを書くこともありません。 もちろん、完成にたどり着くまでのプレッシャーとかストレス的なものは多少ありますが、それよりも従来と違って、日々の仕事の中でサイクルを回した分だけ小さな達成感を得ることができるので、気持ちよく仕事を終えることができますし、翌日のモチベーションにも繋がります。 さらに、テストコードで何がどこまでできているかがすぐにわかるので、翌日とか翌週とか時間をおいてもスムーズに作業を続けることができます。以前のやり方のままだったら、今頃どうなっていたんだろうと。おそらくコードを書くのは難しくて、他の仕事をしていたと思います。 とはいえ、まだまだ仕事の仕方について改善できることはいろいろあると思いますし、XP本を読んでいくらか理解できたとしても、実践はまだまだこれからです。なかなか自分だけでは実践までたどり着けないと思うので、コミュニティに参加しながらできることを進めていきたいと思います。