タグ: xp

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

第6章の冒頭に、

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

という説明があって、その後に「…、機械的な作業になってしまう。…」
読書会の時にこの部分を読んで、過去に関わったプロジェクトで、テスト工程をペアで手作業で行うというなかなか残念なプロジェクトを思い出しました。のちの改修とか機能追加などを考えれば普通に自動化すべき部分だと思うのですが、リリース前のテストは手をかけて苦労することがルールみたいな感じでした。。。

さて、読書会の議論のなかで「どのプラクティスが導入しやすいのか？」という話があって、いやおそらくそういう方法から入るんじゃなくて、何に困っているかという具体的な問題の洗い出しが必要で、それに対して、じゃあこのプラクティスをやってみれば、というようなやり取りがありました。

あと、全員同席の部分。

過去の仕事場を振り返ってみると、個人スペース、もしくはオープンスペースのどちらかはありましたが、両方を使い分けるような環境はなかったと思います。あと、オープンスペースといっても、単に机が並んでいるだけのごく一般的な職場なので、本に書かれている会議室を占有する感じのオープンワークスペースというのは心に刺さる部分でした。

個人が集中して作業できる環境と、チームメンバーが集まってコミュニケーションをしながら作業できる環境。両方があるのがポイント。

そして「チーム全体」の終わりのほうにある「タスクの切り替え時間」。
いろいろ忙しくて、あれもこれもみたいな状況になるのを仕方ないとするか。いや、その切り替えにはどうしても時間がかかるので、できるだけ一つの仕事に集中できるようにスケジュールなり人員なりを調整するなど。

この回の終わりは「いきいきとした仕事」でした。
長時間働くのは良くないですね。以前は当たり前のように毎日遅くまで仕事をしていましたが、単に時間をかけてコードを書くよりも、できるだけ短時間で切り上げて、環境を整えるとか、こういう本で手法を学ぶとか、プログラミングのスキルを学ぶなど。それと、健康に配慮して体を動かすとか、そうやって生活の質を上げることで結果として仕事の成果も上がるようにしていきたいですね。

この記事は 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)を繰り返して、ストーリーとして組み立てて、テーマとして完成させるような流れ。
なので、小さなループがちゃんと回る（動く）のがポイントですね。

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