読書会

タグ "読書会" の 7 件の記事

XP本読書会最後のふりかえりのふりかえり

2018年12月25日

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

エクストリームの純度

アジャイルでもそうですが、ドキュメントを書かないことの言い訳に使われることがありますね。でもそれ以前にコミュニケーションの問題があるかもしれませんし、様々なスナップショットを大量に生産したところで時間のロスばかりであまり役に立つものではない。頑張ったことの証拠としてカサ増しにはなるかもしれませんが、それよりは成果物の品質や価値を高める方が大切。その上で必要とされるドキュメントがあれば用意するのは当然。と言いつつ、このAgile459の中でも打ち合わせのために事前にドキュメントを用意したりしていますが、それも個人が思うままにかなりの時間を割いて作ったりしているので、そのあたり、せっかくXPとか学んでいるわりに実践が伴っていなかったり、コミュニケーションが足りなかったりしています。コミュニティの運営にもこの学びを活かさないといけませんね。

オフショア開発

オフショアには権限の不均衡が伴う

とあるように、身の回りで聞くオフショアとかニアショアの案件はコストの話にしかなっていなくて、本に書かれているようなコミュニケーションとかリスペクト、単一のコードベースとは異質なもののような気がします。そうではなくて、マルチサイト（拠点の違い）をどう活かすか。メリットとしては例えば多様性と時差でしょうか。ライフスタイルの違い、物事の捉え方の違いを開発や成果物に活かす。あるいは時差を活用してうまく連携することでまさにエクストリームな開発を進めるなど。

結論

最近、働き方が問われていますが、まさにこのXPの原則そしてプラクティスがこれからの働き方に役立つと思います。今回、ふと思いついてAdvent calendarで勢いでXP本読書会をふりかえってみましたが、読み返すたびにあらたな気づきがあります。すぐに忘れているということもありますが、また折をみてXP本をふりかえってみたいと思います。

時間、設計、パターン - XP本読書会14回目のふりかえりのふりかえり

2018年12月22日

Netplan Matsuyama

Developer

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。この回のログを読んで気になった部分をピックアップ。

時間の重要性

ソフトウェアはレバレッジゲームだ

Wikipediaによると、レバレッジの言葉は「てこ(lever)」が由来なんですね。テコの原理か。なるほど。だけどわりとそうなっていないケースが多いのが残念だなぁと思いました。というのは、毎回引き合いがあるたびに1から開発して納めて、しばらくして似たような案件があっても、また最初から作り直しているような。まぁ作り直すのは良いとしても、そこから横に展開するというか、汎用的にしてみるとか、可能性はありそうだけど、努力が足りないのか、営業力？、具体的なニーズの把握？もしかすると、安易に取りかかってしまうのが問題かもしれません。その先にどうありたいか、とかの見通しなど。

XPの戦略は「常に設計する」

この考え方が大切と思いました。要件を確認して詳細まで設計しても、そこから実装を進めていくうちに設計の問題が見えてきたり、要件も変わってきたりするので、それが判明した時点で設計の見直しが常に行えるようにする。となると、ドキュメントがボトルネックになったりするので、最低限必要なものにするとか、オンラインで共有して更新可能にしておくとか、テストコードで仕様がある程度表現されていれば、テストコードのメンテナンスで対応できる部分もあったりとか。長期に渡ったり、規模が大きかったりすると、どうしてもあれこれドキュメントを増やしてしまったりしますが、成果物の品質がよくて、説明しなくても使えるようなものになっていれば、それほどドキュメントに頼ることもないのかなぁと。何というか、ドキュメントを作ることは本来の目的ではないですよね。例えば、管理のために必要、と言われれば、では何のために管理をするのでしょう。管理すること自体がボトルネックになっていて、生産性や品質を下げる要因かもしれません。それよりは、常に設計できる環境にすることで、生産性がグッと向上して品質も上がれば、それこそさっきのレバレッジゲームに乗れる状況が作り出せるかもしれません。

こうした設計の改善が共通してたどり着く先が、パターン

重複は悪、パターンと言われても、なかなか重複が取りきれなかったり。このあたり、チーム内でノウハウがあって、スマートに対応できれば良いのですが、場合によってはノウハウがあまりなかったり、学ぶ機会が少なかったり、ということもあると思います。例えばコミュニティで相談してみて勉強会、という可能性もあるかもしれません。先日開催したGDCRの中で、オブジェクト指向設計についての解説があったのですが、それを理解するまでの余裕がなかったのが残念。このようにふりかえってみると、あれもこれもまだまだ学ぶことが山積みです。

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

2018年12月21日

Netplan Matsuyama

Developer

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

スコープの管理

ここ数年は契約の関係でスコープの調整ができるようになってきましたが、過去に関わった仕事で、スコープが調整されるケースはあまりなかったように思います。やるべき課題とスケジュールが決まっていて、とはいってもスケジュールどおりにはなかなか進まず、スコープは固定されたまま、あるいは開発の過程で次第に膨らむケースが多かったかもしれません。数年前、あるプロジェクトに途中からお手伝いで参加しました。当初、担当の方に話を聞いてみるとあれこれ進んでいなくて、そのため取引先に状況を説明するのが難しそうな雰囲気。そこで、そのプロジェクトの中でほぼ手付かずの項目があって、ちょうど切り出すのに適当な規模だったので、その部分だけ急遽手伝ってある程度進めて、その成果物と合わせてとにかく状況をオープンにしましょうと提案。すると、成果物の部分が取引先から予想外に良い評価をもらえたようで、それが信用に繋がってプロジェクトがうまく回り出したことがありました。そこからプロジェクトの風通しが良くなり、少しずつ成果物を積み上げていって落ち着いたようです。いろいろ難しい状況があると思いますが、クローズにしてごまかしたところで疑心暗鬼になってお互いに不信感が募るばかりなので、とにかくオープンにして少しでも成果を出して一部分でも評価してもらえれば、そこからなんとか前に進み出すんじゃないかと思います。

テスト：早めに、こまめに、自動化

あとでまとめてテストしようとすると、テスト自体にとてもコストがかかるのと、どうしても欠陥が残ってしまうということ。さらに欠陥を取り除こうとしてもコストが増えるばかり。逆に、こまめにテストを実施していれば、欠陥も起こりにくいしそれほどコストもかからない。あと、プログラマー目線でのテストと、顧客目線でのテストによるダブルチェックが重要というお話。ダブルチェックといっても、テストの工程を分けるんじゃなくて、まとめてテストできるように自動化が必要、という感じでしょうか。

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

2018年12月20日

Netplan Matsuyama

Developer

この記事は 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チーム全体」について。ここで解説されているそれぞれの役割ですが、これまで関わった仕事ではこのような役割を意識したことはなかったと思います。なので、良い方向に捉えれば、チームのメンバーでそれぞれの役割を意識することで、仕事の仕方に変化が生まれていろいろと改善に向かうように思います。（かなり適当… 例えば、一気にすべての役割を決めるんじゃなくて、一つの役割を決めてそのように振る舞ってみて、そこから派生していくとうまくいくのかも。まぁ、ともかくすべての役割をやらないといけない、ということではなくて、現状の問題点を洗い出して、その解決に繋がりそうな役割を立ててみる、という感じでしょうか。そして制約理論。ここの議論で「制約理論」が気になって、いきおいで「ザ・ゴール」と「クリティカルチェーン」を読みました。で、ボトルネックを見つけて解消して、そうすると別のところがボトルネックになって、というような話で、じゃあ例えば開発チームの中にボトルネックがあって、と言ってしまうと角が立つので…という話もあったり。スループットをあげるにはボトルネックの解消が必要というのは良いのですが、読書会の当時はそれで理解していたものの、例えば加工や部品を外部委託する場合など、もちろんコストパフォーマンスが求められるのはわかりますが、単にプレッシャーというとちょっと違うのかなぁとも思います。労働環境があらためて問われる時代になっていますし、なるべくフラットな形で良い協力関係が構築できれば良いですかね。

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

2018年12月14日

Netplan Matsuyama

Developer

旧サイト記事の移行

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

重要度の低いタスクを含めること

とありますが、これは調整のために外す（対応しない）こともできるし、比較的簡単なものでも実現することで評価につながることもあります。臨機応変に対応するためのタスク。それと、毎日の仕事の中で集中というか効率よく仕事ができる時間は実際には割と短いものだと思います。タスクを詰め込み過ぎず、ゆとりを持って、それ以外の環境であるとか、スキルアップのための学びであるとか、そういう時間も日々確保することで、より質の高い仕事につながっていくと思います。そして、インクリメンタルな設計。新規に取り組んだものは、その時点で要件を満たすことができた試作レベルと割り切って、機能追加とか何らかの改修をする際に、気がついた時点でリファクタリングを進めていくことでより良いものに仕上がっていくと思います。もちろん、リファクタリングを進めるにはテストコードによる動作保証が前提になります。言い換えれば、テストコードによってシステム全体の動作確認が取れる状態になっていれば、いつでも気軽にリファクタリングに取り組むことができます。という感じで、今日はこのあたりまで。

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

2018年12月9日

Netplan Matsuyama

Developer

旧サイト記事の移行

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

【質問紹介】#Csharp #ASPdotNET #MVC #EntityFramework
Q. MVCの考え方がいまいち噛み砕けないので教えて頂きたいです。

⇒https://t.co/gvJSesTvDJ

— teratail【テラテイル】 (@teratail) September 4, 2018

このコメントがすごく良いヒントになって、仕事のタイミングと重なってリファクタリング進行中です。読書会に参加したことで、そういう課題意識を持てたし、継続的に考えることで実践にも繋がったと思います。

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

2018年12月8日

Netplan Matsuyama

Developer

旧サイト記事の移行

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