カテゴリー: Agile

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

インクリメンタルなデプロイ

ここでは失敗事例が結構なまなましく語られていて、とても強い気持ちが感じられるセクションです。規模の大きなシステムで長期間にわたって開発が続く場合、期日にまとめてリリースしようとしてたいていの場合失敗する。しかも、数ヶ月とか1年が過ぎると、そもそもの要望が大幅に変わって来たり。スケジュールが大幅に遅れて、かなり無理をして新たなシステムに移行したものの、個々の機能にあれこれ問題が発覚して、そのような状況で大幅な変更とか、まぁ対応できるわけがありません。ですが、なんだかよく聞くようなストーリーです。

直前の「本物の顧客参加」にもつながりますが、部分的にでも使える状態にして、実際に使ってもらって、そのフィードバックをもとに次の機能を進めていく。その積み重ね。問題があれば、速やかに対応。日数が経過してからだと、対応にも時間がかかったりしますが、そうでなければ対応も比較的楽ですよね。そうして、ちゃんと機能するものが積み上がっていって、しかもこまめにフィードバックも得ているので、あるタイミングで大幅な変更で混乱、という事態にもなりにくいと思います。あるいは、多少大きめの変更が発生するとしても、それまでの実績があるので、その時点での変更コストが見通しやすい。

チームの継続とか縮小とか

チームを継続しながら適度なローテーション、てどうでしょう。意図してローテーションというのはあまりされていないような気もします。おそらくですが、個人のスキルに依存するばかりで、チームとしてのパフォーマンスに対する意識が低いのではないかと。対象とする分野とか業種によって、それぞれ要求されるスキルとかノウハウが異なるとは思いますが、それを固定化することがチームとか組織としてはたして良いのかどうか。例えば、ある分野で培ったノウハウを別のチームに持ち込んでみると、そこで新たな気づきにつながって、組織全体としてパフォーマンスが上がる可能性もあると思います。

コードの共有

個人の責任で追い詰めたところで何も解決しないどころか、時間のロスやモチベーション低下につながりますよね。チームでコードを共有して、チームで責任を持つと思えば、自然と個々のコードの品質も上がって、チームとしての評価も上がるはず。

といった感じで今日はこの辺で終わりにします。

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

メトリクスが気づきにつながることもある

読書会のときに「数値化できていないなぁ」と書いておきながら、今、この記事を書きながら実践できていない（放置状態）ことに気がつきました。何か方法を考えないと…

Git Webフック
このあたりを活用してみるか…
といいつつ、何もないところからスマートに行こうとして、結局何も進まないことになりそうなので、コミット履歴をもとにして、数値化できるものを手で拾うところから始めてみます。

さて、プラクティスのマッピングについて。

なるほど、気になるキーワードを書き出して、絵にしてみれば良いんですね。読書会の当時は、あまりピンときていなかったのですが、今になって腹落ちした感じです。普段だと、キーワードとか何か言葉なり文章なりを書くとしたら、こういうブログ記事でもそうですが、エディタとかで整然と書くだけで、それでは変化がなくて発見につながらない。そうではなくて、紙の上に向きや形を変えながらキーワードの関係を手で描いてみる。それを共有することでさらなる発見につながる。という感じですかね。

ところで、この一連の読書会のふりかえりをしていて思ったのですが、一度読むとなかなか自分では解釈を変えられない、というか、思い込みのまま読み過ごしてしまうことが多い、ということです。せっかく良いことが書いてあっても、勘違いしたままで、後で読み直しても、最初の解釈のままだったり。あるいは、なかなか頭に入ってこないセクションがあったとして、やはり後で読み直しても同じ感じで、そのままやり過ごしてしまうとか。もちろん自分の読解力の問題もあると思いますが、でもこういう読書会であれば「自分はこう思うんだけど…？」と投げかけてみることで違う解釈が聞けたりすると学びになりますよね。

あと、最近気になるのはアジャイルが △△ vs ○○ という構図で表現されることが多くて、アジャイル手法だと □□ だから注意しないといけない、というコメントなど。XPとかアジャイルとかの本で書かれているのは、過去の様々なプロジェクトでいろいろ問題があって、どこも同じような問題を抱えていて、それをどうやって改善してきたか、どうすればみんなが少しでも幸せになれるか、というノウハウの集大成のようなものだと思っています。もちろん、こうすれば必ずうまくいくということではなくて、状況に応じて何を適用するかという判断も必要と思います。ですが、アジャイルを否定するためのあら探しをしたところであまり生産には結びつかないと思います。もちろん、何か問題点に気がつけば対策を考えるなり改善していけば良いわけで。

それと、自分の組織やチームの中だけでは気がつかないことも多く、こういうコミュニティの中でディスカッションすることで、いろいろと気づきや改善、プラクティスにつながったりするんだと思います。

自分に言い聞かせるような感じで、なんども同じことを書いている気がしますが、ご容赦のほど。

今日はこのへんにしておきます。

この記事は 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本を読んでいくらか理解できたとしても、実践はまだまだこれからです。なかなか自分だけでは実践までたどり着けないと思うので、コミュニティに参加しながらできることを進めていきたいと思います。

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

4章のコミュニケーションについて。

どんどん成果が上がらないが時間が過ぎていく。悪循環を思い出す。
経験が浅いとコミュニケーションがうまく取れない。

与えられた仕事は自分の責任でやらないといけないと思って、ディスプレイに向かってコーディングを進めようとするものの、スキル不足や課題の理解度の問題などで一向に進まない状況。
最近であれば、バックログによる課題の管理やTDDで必要なものを小さく切り出して積み上げていくなど、仕事の進め方がずいぶん変わりましたが、昔はそのような方法を知らず、大きな課題を丸ごと完成させようともがいていたような気がします。そういうときは遠慮とかしている場合ではなくて、とにかく自分の手が進むようになるまで相談するべきと思いました。先輩はもとより後輩の新人がサクサク仕事を進めていたりすると、余計に自分で頑張らないと、と思ってしまいますが、上下関係なく、少しでも仕事の成果を出すにはどうすれば良いかを割り切って考えるべきだったのだろうと思います。

コミュニケーションを取りすぎる人がいる。

自分にも当てはまることではあるのですが、コミュニケーション重要、といってもそればかりで肝心の仕事が進まないのでは意味がなくて、程度の問題とは思います。ただ、昨年(2017)のアジャイルのサテライトで実践した Mob Programming をふりかえってみると、コミュニケーションの取りすぎも問題なくて、どちらかというと、チーム全員で議論しながらプロダクトが仕上がっていくような、そういうスタイルもあるので、コミュニケーションで問題になるのは１対１の場合かもしれません。１対１だとすべて問題、ということではなくて、１対１のコミュニケーションが長い時間続くと本筋から外れていることが多いですよね。

と書いていると、このような記事のお知らせがメールで届きました。
アジャイルなチームを改善するアイデア集「101 ideas for agile teams」で僕が学んだこと
元の記事と合わせて読んでみようと思います。