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

エクストリームの純度

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

と言いつつ、このAgile459の中でも打ち合わせのために事前にドキュメントを用意したりしていますが、それも個人が思うままにかなりの時間を割いて作ったりしているので、そのあたり、せっかくXPとか学んでいるわりに実践が伴っていなかったり、コミュニケーションが足りなかったりしています。コミュニティの運営にもこの学びを活かさないといけませんね。

オフショア開発

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

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

結論

最近、働き方が問われていますが、まさにこのXPの原則そしてプラクティスがこれからの働き方に役立つと思います。

今回、ふと思いついてAdvent calendarで勢いでXP本読書会をふりかえってみましたが、読み返すたびにあらたな気づきがあります。すぐに忘れているということもありますが、また折をみてXP本をふりかえってみたいと思います。

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

この回のログを読んで気になった部分をピックアップ。

時間の重要性

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

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

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

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

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

重複は悪、パターン

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

この記事は 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 のエントリーです。

XP本読書会の5回目は5章の後半でした。

機会と失敗はつながる部分があって、失敗とか何か問題があった場合にネガティブになるんじゃなくて良い方向に向かせるための機会ととらえることがポイント。反省も必要だけどそればかりではしんどいですし、さらに大きな問題につながる可能性もあるわけで、そうならないうちに気がつけたと思えば良いんじゃないかと。テストケースを追加してみるとか、テストの仕方を変えてみるとか、機能自体を見直してみるとか。

あと、失敗したら急いで対処するんじゃなくて、まず失敗した状況を共有。対処できたらまた共有。そうすることで落ち着いて対応できるし、時間がかかったらかかったでエビデンスにもなるし、のちの教訓とかノウハウにもつながると思います。

次に品質について。

仕事の中で品質を求めることができなくて（あきらめて）、プライベートで品質に対する欲求を満たしていたという話の中で「盆栽」というキーワードが上がって、「盆栽」といえば波平の「ばっかもーん!!」ですよね、みたいなところから脱線。まぁそれはそれで面白かったです。面白かったというか、オンライン読書会の中で一番脳が活性化した瞬間だったかもです。

で、品質と責任の部分もつながると思います。誰かの成果物の品質がどうとか、誰かに責任を押し付けたところで、プロジェクト全体としては何の解決にもならないわけで、解決にならないどころかそれこそ時間の無駄。それよりも、プロジェクトのチームとして品質を良くしていくとか、責任を共有することが大切。そうすれば信用とか期待につながりますよね。

本の内容とは少し外れますが、この頃に自分の課題として「リファクタリング」というキーワードがあって、なかなか進めることができていなかったのですが、

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

⇒https://t.co/gvJSesTvDJ

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

このコメントがすごく良いヒントになって、仕事のタイミングと重なってリファクタリング進行中です。

読書会に参加したことで、そういう課題意識を持てたし、継続的に考えることで実践にも繋がったと思います。

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

XP本読書会の4回目は5章の途中でした。この頃は参加者がわりと多くて、その分あまり進まなかった様子。
それと、ディスカッションのまとめもSlackのタイムラインをWikiへコピペしていたので、ログがちょっとわかりにくい。後日、記録用にHackMDを使うようになりました。

さて、自己相似性の部分ですが、あらためてその部分を読んでみると、わかりやすくて重要と思いました。

• 四半期単位：テーマを選んでストーリー単位で組み立てていく。
• 週単位：ストーリーを選んでテストを組んでいく。
• 数時間単位：テストを書いて、実装していく。

小さなループ(TDD)を繰り返して、ストーリーとして組み立てて、テーマとして完成させるような流れ。
なので、小さなループがちゃんと回る（動く）のがポイントですね。

あと、「ふりかえり」のところにあった「ソフトウェアプロセスばかり考えている」の部分。方法論にとらわれ過ぎて、生産性に繋がらないのはよろしくないですし、開発のことを考えるのは良いけれど、管理するために資料を作らないといけないとか、プロダクトとは直接関係のない物に対してリソースが消費されるのは避けたいですね。フラットなチームとかフラットな組織であれば、そのあたりの無駄も少なくなると思います。

明日はアジャイルサムライ読書会に参加予定。
ということで、たまには予習をしながらブログを書いてみるなど。

まず最初に、文書化の難しさ。

大量のドキュメントを作ったところで、時間が経てばやりたいことも変わってくるし、人が書いた文書を正しく理解するのは難しい。あるいは文書で他人に正確にものごとを伝えるのもなかなか難しい。

「要件」を信じない。

要件定義にかかれている項目のうち80%は必須ではない？
（参考文献　XPエクストリームプログラミング入門　第2版）
必ず実現しないといけないことと、そうでないことの切り分けをしないまま「要件」としてまとめてしまっているので、本筋が見えにくい、という感じかな。

そこで「ユーザーストーリー」

インデックスカードに書き出す。
フィーチャーの本質となるキーワードを書く。
わかりやすくシンプル。
ぱっと読んでおいしいと思えるもの。

「6つの要素」

Independent, Negotiable, Valuable, Estimatable, Small, Testable

ユーザーストーリー vs 要件定義書・仕様書

「要件定義」はそれを作る時点での情報を固定化してしまうところを問題視している感じ。
それにくらべてユーザーストーリーは柔軟で無駄がない。

ユーザーストーリーの「テンプレート」

だれのためのストーリーで
なにをしたいのか
なぜそうしたいのか

そして「ストーリー収集ワークショップ」の開催

フィーチャーリストの作成。
ワークショップでは開発チームと顧客が一緒になってユーザーストーリーを書く。

と、こんな感じの内容です。

先週末の9月1日にアジャイルサムライ読書会#7に参加しました。内容はインセプションデッキの後半（5.2～5.5）でした。

5.2「夜も眠れなくなる問題は何だろう？」
　プロジェクトが進みだすと、不安なことがあっても口に出しにくかったり、質問しにくい雰囲気になったりしますよね。どうしようもなくなって「実は…」となるよりは最初からそういう要素を洗い出して明記して共有すること。

5.3「期間を見極める」
　開発プロジェクトの期間は6ヶ月以内がのぞましい。もちろんあらゆるプロジェクトが6ヶ月でできるわけではないが、3ヶ月あるいは6ヶ月といったできるだけ短い期間におさまるように分割して計画を立てる。

5.4「トレードオフ・スライダー」
　あらゆるプロジェクトは次の4つのフォース（力）によって統治される。

1. 時間
2. 予算
3. 品質
4. スコープ

言い替えれば大きく4つの制約があるということ。
この時間、予算、品質を動かすことができないとすれば、調整可能な要素はスコープ（範囲）のみ。
「どれも最優先」とか「これとこれは同じレベル」というのは禁止。
このルールによって諦めるものを明確にすることができる。
あと、上記の4つ以外でプロジェクトの重要な要素をスライダーの項目に追加する。
顧客と共にスライダーを設定する。

5.5「何がどれだけ必要なのか」
期間、メンバー、予算。
この部分はいろいろ議論がありました。
そもそもメンバーは社内で手が空いている人で、おのずと決まっているとか、
予算も期間も決まった後でアサインされて、そこから作業規模を洗い出したところでどうにもならない、など。
日常の仕事を考えれば、確かにそのような状況が一般的かも知れませんが、
新たなプロジェクトに対してチームを編成することを考えると、果たしてそれでプロジェクトがうまく行くのか。
まったくリソースが足りてないところで、無理やりチーム編成をして進めてしまっているのではないか。
とても考えさせられる内容でした。
単価の話もしました。その場では「上流だったらこれぐらいかなぁ」という話もありましたが、後で考えてみると上流とか下流という時点でアジャイルではないようにも思いました。

さて、次回のアジャイルサムライ読書会は10月6日（土曜日）の予定です。
http://agile459.doorkeeper.jp/
随時 #agile459 というハッシュタグでTwitterで情報が流れていますのでよろしければご利用ください。

それと補足の資料。

読書会の中で「そもそもウォーターフォールって…?」のような議論があったので、
前にForkwellで見かけた記事を貼っておきます。
“History of Waterfall”