この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
アジャイルでもそうですが、ドキュメントを書かないことの言い訳に使われることがありますね。でもそれ以前にコミュニケーションの問題があるかもしれませんし、様々なスナップショットを大量に生産したところで時間のロスばかりであまり役に立つものではない。頑張ったことの証拠としてカサ増しにはなるかもしれませんが、それよりは成果物の品質や価値を高める方が大切。その上で必要とされるドキュメントがあれば用意するのは当然。 と言いつつ、このAgile459の中でも打ち合わせのために事前にドキュメントを用意したりしていますが、それも個人が思うままにかなりの時間を割いて作ったりしているので、そのあたり、せっかくXPとか学んでいるわりに実践が伴っていなかったり、コミュニケーションが足りなかったりしています。コミュニティの運営にもこの学びを活かさないといけませんね。
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会15回目と16回目からいくつかピックアップ。
プロジェクトが停止する前に、ビルドやテスト、システムを理解するためのガイドのようなものを書いておく。まぁ、停止する前というのもいつかわからないので、プロジェクト開始に合わせて準備して、随時更新しておくのが良さそう。
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 この回のログを読んで気になった部分をピックアップ。
ソフトウェアはレバレッジゲームだ
Wikipediaによると、レバレッジの言葉は「てこ(lever)」が由来なんですね。テコの原理か。なるほど。 だけどわりとそうなっていないケースが多いのが残念だなぁと思いました。というのは、毎回引き合いがあるたびに1から開発して納めて、しばらくして似たような案件があっても、また最初から作り直しているような。まぁ作り直すのは良いとしても、そこから横に展開するというか、汎用的にしてみるとか、可能性はありそうだけど、努力が足りないのか、営業力？、具体的なニーズの把握？もしかすると、安易に取りかかってしまうのが問題かもしれません。その先にどうありたいか、とかの見通しなど。
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
ここ数年は契約の関係でスコープの調整ができるようになってきましたが、過去に関わった仕事で、スコープが調整されるケースはあまりなかったように思います。やるべき課題とスケジュールが決まっていて、とはいってもスケジュールどおりにはなかなか進まず、スコープは固定されたまま、あるいは開発の過程で次第に膨らむケースが多かったかもしれません。 数年前、あるプロジェクトに途中からお手伝いで参加しました。当初、担当の方に話を聞いてみるとあれこれ進んでいなくて、そのため取引先に状況を説明するのが難しそうな雰囲気。そこで、そのプロジェクトの中でほぼ手付かずの項目があって、ちょうど切り出すのに適当な規模だったので、その部分だけ急遽手伝ってある程度進めて、その成果物と合わせてとにかく状況をオープンにしましょうと提案。 すると、成果物の部分が取引先から予想外に良い評価をもらえたようで、それが信用に繋がってプロジェクトがうまく回り出したことがありました。そこからプロジェクトの風通しが良くなり、少しずつ成果物を積み上げていって落ち着いたようです。 いろいろ難しい状況があると思いますが、クローズにしてごまかしたところで疑心暗鬼になってお互いに不信感が募るばかりなので、とにかくオープンにして少しでも成果を出して一部分でも評価してもらえれば、そこからなんとか前に進み出すんじゃないかと思います。
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 この当時、Kindleは買ったもののどうも慣れなくて、まだあまり本が読めていない頃でした。ですが、この回の後半にある制約理論の部分で「ザ・ゴール」という本を知り、それをきっかけにKindleで本を読むようになりました。Kindleだと本の厚さを気にすることがないのでそれですんなりと読めた気がします。今もあれこれ読んでいます。といってもまだ10冊くらいですが… あと、読書会の進み具合をD3jsでグラフ化したりしていました。読書会の中での会話とか感想を話す際に、ちょっとルーズになってしまうこともあって、せっかく時間を決めて参加しているのに、なかなか先に進まない状況もあって、目標（その日に読むページ数）を決めて、その結果（読んだページ数）を記録していくことになっていました。ただ、ページ数を記録するだけでは様子がわかりにくいので、グラフ化(burn down chart)した次第です。 XP reading circle burndown chart CSV形式で日付とページ数を書いて、git pushするとグラフが更新できます。今考えると、読書会Wikiに書いたページ数をスクレイピングすればもう一段階自動化できるかも？と思ったり。あるいはWikiから読み取るのはあまりきれいに書けそうにないので、ページ数の記録は別にして、逆にページ数とグラフをWikiに表示する方が良いかも。 さて、この回の「XPチーム全体」について。 ここで解説されているそれぞれの役割ですが、これまで関わった仕事ではこのような役割を意識したことはなかったと思います。なので、良い方向に捉えれば、チームのメンバーでそれぞれの役割を意識することで、仕事の仕方に変化が生まれていろいろと改善に向かうように思います。（かなり適当… 例えば、一気にすべての役割を決めるんじゃなくて、一つの役割を決めてそのように振る舞ってみて、そこから派生していくとうまくいくのかも。まぁ、ともかくすべての役割をやらないといけない、ということではなくて、現状の問題点を洗い出して、その解決に繋がりそうな役割を立ててみる、という感じでしょうか。 そして制約理論。 ここの議論で「制約理論」が気になって、いきおいで「ザ・ゴール」と「クリティカルチェーン」を読みました。で、ボトルネックを見つけて解消して、そうすると別のところがボトルネックになって、というような話で、じゃあ例えば開発チームの中にボトルネックがあって、と言ってしまうと角が立つので…という話もあったり。スループットをあげるにはボトルネックの解消が必要というのは良いのですが、読書会の当時はそれで理解していたものの、例えば加工や部品を外部委託する場合など、もちろんコストパフォーマンスが求められるのはわかりますが、単にプレッシャーというとちょっと違うのかなぁとも思います。労働環境があらためて問われる時代になっていますし、なるべくフラットな形で良い協力関係が構築できれば良いですかね。
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 この時期にSlackでコミュニケーション取り過ぎの問題があって、今思えば自分の使い方も良くなかったと反省。どちらかというとプライベート寄りのチーム、仕事用のチーム、その中間的なチームに参加していて、通知を受けたり書き込んだりする時間帯の切り替えができていなかった感じです。 今でも切り替えができていないので、通知とかステータスの設定を見直してみます。 Slack 通知の仕組み おやすみモードによる通知の一時停止 さて、まずはペアプロについて。 Agile459ではこれまでにGDCRを3回開催していて、昨年のAgile Japanサテライトではモブプログラミング、そして今年の夏にはTDDBCも開催しましたので、ペアプロの有効性についてはコミュニティの中で共通認識が持てていると思います。ただし「ペアとパーソナルスペース」に書かれているような気配りについてはこれまで意識が低かったと反省。 例えば、Wikiのまとめにも書きましたが、以前使っていたアウトドア用の腕時計。そのバンドの裏側に着け心地を良くするための皮が貼ってあり、どうやらその部分が汗臭くなっていたみたいで臭いを指摘されたことがありました。指摘されたときは分からなくて、その腕時計が故障して買い換えた時に、「あーもしかしたら腕時計のバンドの臭いで迷惑を掛けていたかも」と反省。 自分では気がつかないこともあるので、ペアで作業する際の注意点などチーム内で話し合う機会が適宜必要と思いました。 次に、ゆとり（Slack） 最近、働き方が変わってきているようで、その中で、この「ゆとり（Slack）」の考え方が重要かもしれません。
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 第6章の冒頭に、
「プラクティスとは、XPチームが日常的に行うものである。…」
という説明があって、その後に「…、機械的な作業になってしまう。…」 読書会の時にこの部分を読んで、過去に関わったプロジェクトで、テスト工程をペアで手作業で行うというなかなか残念なプロジェクトを思い出しました。のちの改修とか機能追加などを考えれば普通に自動化すべき部分だと思うのですが、リリース前のテストは手をかけて苦労することがルールみたいな感じでした。。。 さて、読書会の議論のなかで「どのプラクティスが導入しやすいのか？」という話があって、いやおそらくそういう方法から入るんじゃなくて、何に困っているかという具体的な問題の洗い出しが必要で、それに対して、じゃあこのプラクティスをやってみれば、というようなやり取りがありました。 あと、全員同席の部分。 過去の仕事場を振り返ってみると、個人スペース、もしくはオープンスペースのどちらかはありましたが、両方を使い分けるような環境はなかったと思います。あと、オープンスペースといっても、単に机が並んでいるだけのごく一般的な職場なので、本に書かれている会議室を占有する感じのオープンワークスペースというのは心に刺さる部分でした。 個人が集中して作業できる環境と、チームメンバーが集まってコミュニケーションをしながら作業できる環境。両方があるのがポイント。 そして「チーム全体」の終わりのほうにある「タスクの切り替え時間」。 いろいろ忙しくて、あれもこれもみたいな状況になるのを仕方ないとするか。いや、その切り替えにはどうしても時間がかかるので、できるだけ一つの仕事に集中できるようにスケジュールなり人員なりを調整するなど。 この回の終わりは「いきいきとした仕事」でした。 長時間働くのは良くないですね。以前は当たり前のように毎日遅くまで仕事をしていましたが、単に時間をかけてコードを書くよりも、できるだけ短時間で切り上げて、環境を整えるとか、こういう本で手法を学ぶとか、プログラミングのスキルを学ぶなど。それと、健康に配慮して体を動かすとか、そうやって生活の質を上げることで結果として仕事の成果も上がるようにしていきたいですね。
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会の5回目は5章の後半でした。 機会と失敗はつながる部分があって、失敗とか何か問題があった場合にネガティブになるんじゃなくて良い方向に向かせるための機会ととらえることがポイント。反省も必要だけどそればかりではしんどいですし、さらに大きな問題につながる可能性もあるわけで、そうならないうちに気がつけたと思えば良いんじゃないかと。テストケースを追加してみるとか、テストの仕方を変えてみるとか、機能自体を見直してみるとか。 あと、失敗したら急いで対処するんじゃなくて、まず失敗した状況を共有。対処できたらまた共有。そうすることで落ち着いて対応できるし、時間がかかったらかかったでエビデンスにもなるし、のちの教訓とかノウハウにもつながると思います。 次に品質について。 仕事の中で品質を求めることができなくて（あきらめて）、プライベートで品質に対する欲求を満たしていたという話の中で「盆栽」というキーワードが上がって、「盆栽」といえば波平の「ばっかもーん!!」ですよね、みたいなところから脱線。まぁそれはそれで面白かったです。面白かったというか、オンライン読書会の中で一番脳が活性化した瞬間だったかもです。 で、品質と責任の部分もつながると思います。誰かの成果物の品質がどうとか、誰かに責任を押し付けたところで、プロジェクト全体としては何の解決にもならないわけで、解決にならないどころかそれこそ時間の無駄。それよりも、プロジェクトのチームとして品質を良くしていくとか、責任を共有することが大切。そうすれば信用とか期待につながりますよね。 本の内容とは少し外れますが、この頃に自分の課題として「リファクタリング」というキーワードがあって、なかなか進めることができていなかったのですが、
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会の4回目は5章の途中でした。この頃は参加者がわりと多くて、その分あまり進まなかった様子。 それと、ディスカッションのまとめもSlackのタイムラインをWikiへコピペしていたので、ログがちょっとわかりにくい。後日、記録用にHackMDを使うようになりました。 さて、自己相似性の部分ですが、あらためてその部分を読んでみると、わかりやすくて重要と思いました。 _ 四半期単位：テーマを選んでストーリー単位で組み立てていく。 _ 週単位：ストーリーを選んでテストを組んでいく。* 数時間単位：テストを書いて、実装していく。 小さなループ(TDD)を繰り返して、ストーリーとして組み立てて、テーマとして完成させるような流れ。 なので、小さなループがちゃんと回る（動く）のがポイントですね。 あと、「ふりかえり」のところにあった「ソフトウェアプロセスばかり考えている」の部分。方法論にとらわれ過ぎて、生産性に繋がらないのはよろしくないですし、開発のことを考えるのは良いけれど、管理するために資料を作らないといけないとか、プロダクトとは直接関係のない物に対してリソースが消費されるのは避けたいですね。フラットなチームとかフラットな組織であれば、そのあたりの無駄も少なくなると思います。
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 昨年(2017年)秋頃からAgile459で開催されたオンライン読書会1回目のログ。 https://github.com/agile459/reading-circle/wiki/XP2ndBook-1st-20171018 この内容をふりかえって思うのは、これまでに関わった仕事にはソーシャルチェンジという文化があまりなくて、硬直していたものが多かったということ。 もちろん仕事の種類とか現場によって様々ですが、例えば、あるプロジェクトでは仕事の進め方のルールがあって、そのルールに沿っているかどうかのチェックがあります。ルールに沿っていなければチームのリーダーから叱責されて修正を求められて、ルールを確認して修正して提出。でも、まだリーダーとしては納得のいくものになっていなくて修正を求められる。これを数回繰り返してなんとか完了。 でもですね、このやりとりってプロダクト（ソースコード）じゃなくて、プロダクトをコミットする際の関連ドキュメントやメールの文面の話だったりします。なので、（今後ほぼ使うことがないであろう）関連ドキュメントがボトルネックになって、コミットがなかなか進まない。モチベーション的にもちょっとしんどい状況なわけです。 しかも、そのようなドキュメントの不備が続くと、さらにルールが上乗せされて、足かせが二重、三重になっていきます。 で、XPを学ぶことで「あー、そういうところでものすごいリソースを消費していたんだなぁ」と感慨に浸ったりできるわけです。 管理する立場から言えば、すべてあたりまえに必要な作業、と言われるかもしれませんが、いや、だったらもっとプロダクト自体にリソースを割けば間違いなく好循環が生まれるわけで。 そういった、何かしんどいなぁとか、モチベーションが上がらないなぁ、と感じるときに、その原因に気づかされて、さらっと解決につながるような、そういう学びのある読書会でした。
旧サイト記事の移行
あけましておめでとうございます。 本年もよろしくお願いします。 昨年10月からエクストリームプログラミング(XP)の読書会に参加しています。ご興味のある方はお気軽にご参加ください。途中からでもご遠慮なくどうぞ。 次回は1月10日開催予定です。 エクストリームプログラミング読書会 第６回 教材はこちら「エクストリームプログラミング」 ふと、あとがきを開いてみました。 目についたのが、
