エクストリームプログラミング 第二版を読んで
最近、原因は掴めないけどSprintが上手くいかないなぁと体感。
そこでプラクティスをいくつか知っているだけで、ちゃんと読んだことのなかったエクストリームプログラミングを読んでみた。
結果としてSprintが上手くいく実感を掴めるようになったか、と言われるとよく分からない。が、チームで取り組んでみたいプラクティスや個人的に新しい発見があったので、備忘録として記録しておく。
XPの価値
XPとは何か？という問いへの答えの中で最もアツい答えは
「XPとはソフトウェア開発で人間としての欲求を満たすことである」
という答え。
創造的で達成感のあるSprintを続けていけるようになるのが幸せだと非常に共感。
よく分からないゴールを立てて、どうすれば終わるのかも分からない作業をひたすら続けるSprintは本当に苦痛。
で、苦痛を避けるため、チームの目標を達成するためにXPが重要視している価値は
・ コミュニケーション
・ シンプリシティ
・ フィードバック
・ 勇気
・ リスペクト
と記載されている。
この中で個人的に意識していきたい価値はシンプリシティ、フィードバック。
・シンプリシティ: 書籍の後半にもシンプリシティに言及しているが、XPチームは問題に対して、できるだけシンプルな解決策を提案する。
コードを書かなくて良い解決策があるなら、それが最もシンプルな解決策かもしれない。
複雑な解決策はさらに別の問題を生み出す可能性すらある。
「シンプル」の定義が難しいな、と思ったが基準もしっかり記載されていた。
・設計を理解できるかどうか
・システムの要素が情報を正確に表現できているかどうか
・ロジックや構造に重複がないかどうか
・システムの要素が最小限かどうか
問題に対して、複雑なロジックを実装した経験は山ほどある。元来コードを書くのが好きなものだから、複雑な問題を複雑に解決することに尽力しがちな自分は心に刻んでおきたい価値と基準だと思った。
・フィードバック: フィードバックを早く多く得ることで、変化し続ける環境に適応していくことができる。
個人的にこの価値について重要視できていなかったな、と感じるのはフィードバックを得た後に舵を切り直すこと、環境の変化に目を向けること。
SprintPlannningで決めた方針はSprint2日目には最適な方針ではなくなっているかもしれない、ということに気付けなかったり、実際に仕事をすると当初見積もったコストを大幅に超える可能性があることをフィードバックとして得ているにも関わらず、リプランを行おうとしなかったり。
試してみたいプラクティス
・ゆとり: 開発チームはSprint中にゆとりを自発的に持つべきだと言っている。
そうすることでオーバーコミットはなくなる。
オーバーコミットがなくなれば、約束した価値を、約束した期限に顧客に届けられるようになる。
開発チームは顧客から信頼されるようになり、チームの士気は維持され、顧客との信頼関係は良好になる。
・インクリメンタルな設計: 毎日設計に手を入れること。
できるだけ早期に詰め込めるだけの柔軟で多様な設計を作り込むのとは真逆である。
日々のフィーチャーを追加する前に、設計を見直せばフィーチャーの実装は楽になる。
とにかく機能を追加することを急いで、設計の見直しを行わなければ1年後にはフィーチャーを追加することは今の何倍も難しくなっているはず。
ただ過剰に設計を毎日作りこめ、って話ではなく、あくまでフィーチャーを追加する直前にフィーチャーを追加するために必要な設計の見直しを行おうって話だと思う。
個人的に学びのあった考え方
・制約理論: 開発プロセスの改善箇所の発見の考え方。
システム開発プロセスにはどこかに制約があると考える。制約とは作業が山積みになっているところ。
その制約の負荷を下げたり、制約となっている作業の仕事量を増加させてあげるなりして、制約となっているところに仕事が山積みにならないようにする。
そうして制約が解消したら、次に最も仕事が山積みになっているところを解消しにいく。
・設計(時間の重要性): 「インクリメンタルな設計」を日常化するための考え方。
経験を踏まえた時点が最も設計の品質が高い。何もわかっていない初期段階で設計書を想像で書いても、何一つ的中せず、不具合や無駄な複雑さを埋め込むだけ。
必要最小限の設計を繰り返すことにより、コストを抑えられる。
そして最も改善すべき設計は「重複」である。フィーチャー追加するたびに複数の同じロジックを修正することになれば、不具合は容易に発生する。
感想
プラクティスはなぜそれがプラクティス足り得るのかを理解することができる。
今後も価値、原則の章は忘れずにいたい。
価値、原則を常に念頭に、プラクティスを実践していくのみだなあと、認識した。