まず2012~2020年ぐらいの日本のSIerだと、エクストリームプログラミングを取り入れるのは難しいので
もしエクストリームプログラミングを読んで実践している環境にいきたいのであればWeb業界で自社サービスを持っているようなところが良いかなというのが最初の感想です。
なぜ2012~2020年ぐらいのことなのかというとSESでいろんな現場を見てきて、その後Web系に転職したためです。ただ、いろんな現場で「テストコード書かないんですか?」と質問をすると「そこまでの技術がない」や「テストコード書いて何になるの?」という回答をされることもありました。もちろんすべてのSIerはテストコードを書いていないわけではありませんが、あくまでそういう現場のほうが多かったということです。
SIerの場合、特に納期の問題であったり、テストコードの有無だったり、見積もりの見積もりの見積もりの見積もりの見積もりに時間がかかったりと課題が多いです。
こちらの本です。Amazonのリンクをペタッと。
エクストリームプログラミングで必要な要素
それは「誠実性」です。
車の運転とサービス開発
- 常に注意する
- 道を間違えたら修正する
車の運転ができるようになるまで、目的に辿り着くことができるようになるまでには、上記の2つを意識する。
事故が起こらないように注意する。交通ルールに順守する。そして人間は失敗する生き物なので道を間違えたら軌道修正する。
サービスの開発もこれと同じで要件、設計、技術、世界情勢、ビジネス、自分のチームなどは常に変化する
今すぐ変わることもあれば未来に向けてゆっくり変わるものもある。サービスはこの変化に対応できるようになる準備をしておくことが大切。
そのためにはチーム・組織作りがキーになる。
以下を向上させていくこと。
- チームの能力
- コミュニケーション
- 生産性
これを向上させる際に必要なものは心理的安全性だったりするという個人の感想。
価値・プラクティス・原則とは
- 価値とは問題解決をするための深い理解・経験・知能
- プラクティスは実現するために必要な技術
- 原則価値とプラクティスのギャップを埋める
プラクティスは色々あり、状況によってベストプラクティスは変わってくるけれどそもそもいろんな方法を知らないとわからないから学んでどんどん試すことが大切。価値はプラクティスに目的という意味をつける。ただ、価値ってまぁまぁ抽象的なもの。原則は俯瞰した全体的なルールみたいなものなのかもしれない。
ここは「本を読んでいるだけではXPは伝わらないと思うので、実際に経験をしてくださいね。」ということを伝えたいらしい。仮説と検証を繰り返し脇見恐怖症を克服した私もとりあえずいろんなことに挑戦して経験はたくさんした。まずは挑戦して経験を積みかさねていこう。
エクストリームプログラミングの価値の考え
価値とはひとりひとりの重要な感覚。
知ったかぶりをする人は良くトラブルを起こすと書いてあってこの前実生活で知ったかぶりをする後輩がいてトラブル起こしていたなぁということを思い出した。それは置いといて。
コーティングにおいてはチームの共通のスタイルがその後価値をもたらす。メンテナビリティのお話かな。
価値の重要な5個の要素があるとのこと。
コミュニケーション
問題が発生しているときにだいたいは他のひとが経験していることも多い。そして権限を変えれば解決できることもあるが権限が変えるひとにまで気軽にコミュニケーションができないチームや組織はちょっとしんどい。
シンプリシティ
無駄に複雑になりすぎないこと。要件も不要になったら削除するという簡単なこと。そのためには他のチームも巻き込んでコミュニケーションをとることがやっぱり大切。
フィードバック
一時的な完成ではなく改善をすることが目的。そのためにはフィードバックが大切。アイディア・コード・テストコード・それらの結果のフィードバックはしてもらった方が良い。そしてコミュニケーションも必要になってくる。さらにシンプリシティによって複雑ではないもののほうが本質的なフィードバックを受けることが可能。
勇気
問題が発生したときに解決するための行動を起こす際に勇気が必要となる。勇気だけで行動すると設計が崩れてしまうこともある。ただ、勇気をもって行動する際に「価値」が合わされば、その行動は正しいものとなる可能性は高くなる
リスペクト
サービスに関わるチームメンバーにはだれだれが優れ、だれだれが劣っているなどの考えは必要なく、誰しも平等に接することが重要。みんな良いところもあるし、悪いところもある。ウィークポイントをついて攻撃しまくる、いじめをする人間性のメンバーは正直必要ない。
エクストリームプログラミングの原則
- 人間性
- 安心して生活をおくるようにできること。管理職は特に読んでほしい
- 経済性
- ビジネスのニーズにそった開発をしていること。サービスを開発するうえでどこで利益が発生するかのタイミングなどが書かれている
- 相互利益
- 現在の自分、将来の自分、顧客の利益、新しいメンバーへの保守コスト削減という利益。テストファーストがここでは鍵になる
- 自己相似性
- 経験は違うとはいえ、まずは自分の今までの手法をやろう。ただしその手法はテストを先に書くことをすすめている
- 改善
- 完ぺきではなく日々改善をすることが大事。「docを完璧にしてからレビュー出してこい」と後輩ちゃんが前のプロジェクトでパワハラおじさんに言われたらしい。そのプロジェクトは炎上してたなぁ
- 多様性
- みんな似た考えのほうが居心地が良い。ただ、新しい視点や考え方が必要なので多様性があったほうが良い。その際に衝突が起こるかもしれない。衝突はあっても良いが心理的安全性がやっぱり重要になってくる
- ふりかえり
- 1週間、2週間、1ヶ月単位でも良いのでKRPTをやろう。何かイベントが発生したときも必ず振り返り再発防止をしよう
- 流れ
- 安定した流れをつくろう。そのためには1日1回はデプロイして細かくフィードバックを得よう
- 機会
- 問題を機会と考え、様々な手法で解決していこう。ペアプロとかおすすめ。いろんな経験を得ることができる
- 冗長性
- これを減らすことで信頼を得よう。欠陥は複数の視点で解決しよう。テストフェーズが明確に・・・
- 失敗
- うまく成功できない場合はとりあえず失敗しよう。失敗から得られるものはたくさんある
- 品質
- 高品質を目指そう、高品質を実現できる理解を深めていこう
- ベイビーステップ
- 人間もいきなり大きく変わろうとすると恒常性バイアスがかかって行動できないが小さく行動して積み重ねることで変わっていける。サービスは小さく変更していくことでリスクを軽減できる
- 責任の引き受け
- 責任と権限の関連について書かれている、今2022年時点で勤めている会社の課長は「なにかあったらXXさんのせいにしよ」と平気で言ってくるので、その考えを持っているかたが管理職となると・・・XPは実現できなさそう、転職しよ←
主要プラクティス
プロジェクトのチーム内で利用するプラクティス。
すごくざっくりまとめると
- 全員でコミュニケーションをとることができる場
- 全員が物理的にも心理的にも安全性の高い環境で開発ができる場
- 視覚的にプロジェクトの状況が15秒ぐらいで理解できるカンバンなど
- 無理せずリラックスした状態で生産性の高い間だけお仕事をする
- ペアプロはペアを尊重し程よく人と交流を持ちつつプライバシーを守ろう
- ペアプロ時、異性間だと尊重がない場合は詰むので配置はしっかり考えよう
- ユーザーストーリーは作ったらすぐに見積もり短くつくろう、名前をつけよう
- 開発は先にテストコードを書こう、詳細設計になるから
- 週のはじめに一週間分のみんなのスケジュールをみんなで確認しよう
- 3ヶ月毎の大きな計画をまとめて立てて、振り返る時間をつくろう
- いつでも次期開発に回せるような優先度の低いタスクも持たせよう
- 自動でビルド、テストコードがすべて完了する時間を短くしよう
- サービスの本番環境へのデプロイする道を整備しよう
- テストコードを先に書こう、のちのちリファクタも楽になる
- 毎日設計に手を加えよう日々ドメインは変化する
プロジェクト全員でこの章を読みながら、いろいろと決めていくと楽しそうだなぁという感想です。
導入プラクティス
サービスの運用がはじまってからのお話。主要プラクティスというベースがないと成り立たないのでご注意を。
- 実際のお客様からもフィードバックの声をいただこう
- 継続的にデプロイは行うが小さな単位でやろう
- 信頼関係のあるチームの継続に力を入れよう
- チームの縮小を行い、別プロジェクトにも旅立たせよう。会社から離れさせるわけではない
- 根本原因をみつけよう。なぜなぜ分析やどうして?を繰り返して見つけよう考える力も育つ
- コードを共有していろんな人のPRを見よう、気になったらIMHOでコメントしてみよう
- いろんな会社が複数のブランチで開発すると最後マージ大変になるのでできるだけ少なくしよう
- 毎日、定時デプロイしよう
エクストリームプログラミングのチーム全体
メンバーには各役割が与えられており、ここでは役割を持つメンバーがどんな働きをしているのかが書いてある
私が経験している部分は以下
- アーキテクト
- テスター
- テクニカルライター
- ユーザー
- プログラマー
- 人事
どこまでも保守運用でリファクタするの楽しい人間なのでより責任のかかる業務は行っていないように見えるけれど、どれも責任重大。ただ、権威効果は弱いかもしれない。「プロジェクトマネージャーの経験あります!」のほうが権威効果は強い。と言っても、いつもプロジェクト炎上して休出だらけのチームとかを見ていたりすると「プロジェクトマネージャー」と言っているだけ、に見えなくもない。ダークトライアドのナルシシズムのマネージャーがそんな感じだった。横道それましたすみません。
人事というワードが出てくるので、採用担当者もエクストリームプログラミングのこの章の役割だけは読んでほしい。
あとは本当にメモ程度ですが大切なこと
- 制約は地図「仕様 => 設計 => コード => テスト」
- 小さく改善していこう
- お客様の声にしっかり耳を傾けて参考となる情報を得よう。
- 失敗から学ぶことが多い
ミニマリズムも「不要なものを捨てて必要な物のみの最小限で生きていく」みたいなニュアンスがあります。
「持たない暮らし実験」というものは「エクストリームプログラミング」のテストファーストに似ています。家を契約して何もない状態から物を2~3ずつ買うことができるという制約をつけて暮らし始めます。
そうすることで「必要な物がない、必要な物を買う」を繰り返して結果300個ぐらいのもので落ち着きます。
さらに300個の物から使わなくなったものを捨てて、既存の物をアップデートすると、もしかしたら代用できるかもしれないと同じ機能の物をまた捨ててを繰り返します。実生活でエクストリームプログラミングの概念を少し触れていると思いました。
エクストリームプログラミングの感想とミニマリズムを多少紐づけてこの本の感想は以上です。