アジャイルを駆動するために実際にやってみたことの個人的なメモ
以下に実施したものと、また実施していないものを記載する。
スクラムやリーンまたXPに共通するアプローチもしくはそのプラクティスに依らず、アジャイルに取り組むにあたり共通的に実施されるアプローチ。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 進捗状況及び課題が日々共有される。 | 意識しないと惰性になる。チーム及びメンバが「リスク」が「リスク」がと言い始める。 | なし。 | 報告のやり方常にはカイゼンしていく必要がある。 |
本当の「リスク」って何ですか？をメンバに認識させる必要がある。
良くある例として、スケジュールが遅れる場合、「スケジュールが遅れることがリスクではない」。
「スケジュールが遅れる要因は何か？」＝「それがリスク」だということを理解させる必要がある。
組織や文化の問題に目を向けさせる必要性がある。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 短期一定期間の行動や判断のカイゼンと反省を行える。 | 多少時間が奪われること位。 | なし。 | 振り返り自体のカイゼンは大きな効果があるため、やり方自体をチームやメンバのレベルに合わせて変化させる必要がある。 |
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| チーム及びプロダクトの方向性の中長期的な修正と調整に役立つ。 | 人出しのエンジニアなど「思いがない」メンバには効力を発揮しない。 | チームの解散 | 現実問題としてPOもしくはリーダー級にしか役に立たないことも多い。 |
TBD
星取表とは「カイゼン・ジャーニー」に書かれていた内容。
スキルマッピング一覧とも言える。
自分個人としては他のメンバを含めた「スキル一覧」という形で、スキルの依存性を分析している。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| チームメンバのスキルマップが可視化されることで、ヒト依存（ヒーロー／ヒロイン）を排除するための分析が可能となる。 | なまじ可視化される分、メンバ間のスキル格差が生まれるとコンプレックスを生む原因となり、スキルマップを埋める努力をしなくなる傾向がある（諦める）。 | チームの解体。スキルアップするメンバの固定化 | 突出するメンバが出て来た場合、そのメンバは星取表に乗せない方が良いであろう。それ以外は以下に記載。 |
通常のビジネスにおいては各メンバの「スキルや広さや深さ自体は実はあまり問題にならない」
開発メンバはどのスキルセットでも「プロダクト開発に貢献できているか」という指標が、PO及び開発チームにとっては非常に重要だからだ。
上記の意図に沿うものであるならば、「個人依存を無くす」という用途で運用するべきだけのもの。
アジャイルにおいて運用が難しい、プラクティスの１つであろう。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| タスクのバッチサイズが読めない時やチームメンバが工数見積になれていない場合、見積スキルの向上や心理的安心感の形成に役立つ。 | メンバ全員のワークロードが奪われる。馴れ合いになる可能性がある。 | マイグレーション案件にはあまり向かないため。 | やるのであればプランニングポーカー用のカードを買った方が良い。 |
ゲーム感があるので、チーム形成期にメンバの親睦を図るためにもやってみても良いと思う。
上記タスクはユーザーストーリーであることもある。
TBD
書籍「エラスティックリーダーシップ」から知見を得たやり方。
「サバイバルモード」「学習モード」「自己組織化モード」に分類され、それを意図的に運用してみた。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| プロダクト開発のマイルストーンとスコープを強制的にFitさせられる。 | チームの学びは無くなる。 | チームの解散 | 別になりたくてサバイバルモードになるわけではない。 |
個人として経験したプロダクト開発の開発チームは2年間かけても、「自己組織化モード」には到達しなかった認識。
SES（人出しエンジニア）で構成されたチームでは到達出来きないのでは？と思う時がある。
全体のマイルストーンが押してくるとヒーロー／ヒロインが自然もしくは意図的に表れて、サバイバルモードとして火消しになる。
その段階で学習モードは失われる。
TDB
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 全行程の作業を分析することにより、リリースまでの作業工程が可視化される。ムダを分析出来る。 | 特に初回は分析に時間と人が多いに割かれる。 | マイクロソフトで一度やったきりで定着しなかったため。一度可視化されてそれで満足してしまったのであろう。 | バリューストリームマッピングは辞める理由がないと考える。定期的な見直しが必要な認識。 |
とある顧客企業のアジャイル黎明期にやったアプローチ。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 作業や進捗の流れが手軽に可視化出来る。 | 他のITツールと２重管理になる可能性があるため、使い分けの考慮が必要。 | VSTS[Azure DevOps]を導入したため。 | 支援している顧客の文化がホワイトボードが使用不可であったため、泣く泣く廃止。（プロジェクトもしくはプロダクト開発で専用で使用できるホワイトボードがない。。） |
アナログは非常に重要。
バリューストリームマッピング＋アナログのカンバンは必要不可欠な認識。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| プロダクトマネージャーなどが後から集計をかけ分析するには役立つ。 | 他のITツールと２重管理になる可能性があるため、使い分けの考慮が必要。 | VSTS[Azure DevOps]を導入したため。 | 顧客文化としてホワイトボードが使用不可であったため、泣く泣く廃止。 |
ITツールのカンバンは後から分析をかけるのには、良いがリアルタイムの可視化が弱い。その点ではいつでも見れるアナログのカンバンはサイコーである。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 仕掛かり作業を軽減させられる。 | リーン的にはなし。 | チームの解散。 | WIP制限をかけるということはカンバン（リーン）のアプローチであり、スクラムのアプローチではなくなる。 |
WIP制限を取り入れるのであれば、最終的には一個流し（シングルピースフロー）を目指した方が良い。
但し、上記は緊急スイムレーンが無い場合に限りである。
継続的インテグレーション[CI]の範囲は、ソースコードをプッシュもしくは定期的にビルドすることとし、
そのビルドの成否判定とそれに伴う通知、またテストコードの自動実行またその成否とそれに伴う通知までとする。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 常にビルド可能であることが保たれる。ソースコードのマージ時間を短縮する。バリューストリームを向上させる。 | 採用するCIツールにより、それなりに癖がある。 | なし。 | 今の時代必須の認識。学習コストは許容せざるを得ない。 |
継続的デリバリー[CD]の範囲は、ビルドされたアーティファクトからDcoker Imageを作成後、
KubernetesのマニュフェストもしくはKostamizeのYAMLを使用しKubernetesクラスタへデプロイするまでとする。
上記は実際にはステージング環境への自動デプロイと本番環境へのリリースワークフローを挟んだデプロイとなることが多い。
※上記リリースワークフローとは本番環境へデプロイする前に、最終的にプロダクトオーナーなどによるリリース判定などによるヒューマンプロセスを指し示す。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 常にビルド可能であることが保たれる。ソースコードのマージ時間を短縮する。バリューストリームを向上させる。 | 採用するCIツールにより、それなりに癖がある。 | なし。 | 今の時代必須の認識。学習コストは許容せざるを得ない。 |
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 環境構築がコードに落ちるので、再帰的に実行可能。導入手順書とが不要となる。再帰的に実行可能。 | 以下に記載。 | なし。 | ここは頑張らないといけないところ。幸せになれない。 |
メリット：
特にクラウドやKubernetenの場合、何時でも作れて何時でも壊せるということに安心感が芽生える。
デメリット：
AWSのCloud FormationとAzureのARM templateのJSONは触る気（編集する）が起きない。触るとなると普通に死ねる。
k8s/Istioの場合、YAML地獄となる。そのためにKostomizeなどを採用したくなる。そしてk8s関連で採用する技術がまた１つ増える。
Ansibleの場合、ベストプラクティスなディレクトリ構成などを採用することでk8のデメリットを軽減可能。
Terraformが使えるのであれば、少し人に優しくなる。但し上記JSONとYAMLから書き直すことになるので、そこは根性が必要。
AnsibleやTerraformでInfrastructure as code書く前に、TDDとしてtestinfraでテストコード書いて、
「Infrastructure as codeでもTDD出来るよね」ってアプローチ。
XPの要素はあるが、リーン的な効力が強いのでこちら側にカテゴライズする。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| Infrastructure as codeで構築した環境をテストコードでテスト出来る。 | なし。敢えて言えば色々なPython SDKを使いこなせる技術スキルは必要。 | チームの解散 | 所詮、人がやる作業は絶対ミスがある。それを検出できるのは大きい。 |
Excelなどで作る「XXX設計書」や「XXXパラメータシート」みたいなものからオサラバ出来る可能性がある。
Excelなどで作るインフラやミドルウェアの「単体テスト仕様書及び結果報告書」みたいなものからオサラバ出来る可能性がある。
testinfraで書いたテストコードはDSL（ドメイン固有言語）っぽくなるので、そのテストコードから日本語への置換プログラムを作れば、環境変更などのW/Fに乗せれる日本語文章になるのでは？と推測している。
スクラムのプラクティスで実際に実施したものは以下となる。
前述の「デイリースタンドアップMTG」と同様。
TBD
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| なし。 | なし。 |
TBD
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| なし。 | なし。 |
前述の「振り返り」と共通とする。
XPのプラクティスで実際に実施したものは以下となる。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 確実にテストコードが生まれるため、そを使用した再帰テストが可能になる。 | 特にはないが、テストコードを記載する粒度を見極める必要がある。 | なし。 | 継続的インテグレーションと大きく関連する。 |
完全なテストファーストな開発スタイルでなくとも、テストコードがあることでいつでもテストが実行でき、テストがパスするのは開発者に良いリズムをもたらす。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| プロジェクトへの途中参加者や経験の浅いメンバを早く戦力にするのに役立つ。レビューのワークロードを軽減させる。ハマりの軽減。 | 1人辺りの生産性と比較するとという話がある。組むペアのメンバの固定化。 | 常時やるものとしていないため、必要に応じて実施。 | 以下に記載。 |
「高スキル」＋「高スキル」のメンバの組み合わせは互いの気づきの中で良い循環をもたらす。
「高スキル」＋「低スキル」のメンバの組み合わせはスキルの向上をもたらす。
「低スキル」＋「低スキル」のメンバの組み合わせは効果が出ない。
「心理的安心感」の元、組むペアのメンバが固定化し始めた場合、おそらくそれは良くない兆候なので一旦１人での作業に戻し、それでもペアで作業したいのかをベロシティなどを分析し決定した方が良い。
過去ペアプログラミングにより、生産性が1人作業と比較し下がったかどうかを分析したが、下がることはなくほぼ同じだったいう結果が出た。
おそらくレビューのワークロードが減ったことが大きい。
生産性の議論もあるが、数字として表現出来ないが知識が共有される効果の得られた。
リモートワークでペアプログラミングを実施する分にはパーソナルスペースが保たれるため、問題ないという開発メンバもいるという報告もある。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 知識が開発メンバ全員に一度に共有されるため、コミュニケーションコストが無くなる。 | 知識が共有される反面ドキュメントを書かなくなる傾向がある。 | 常時やるものとしていないため、必要に応じて実施。 | 以下に記載。 |
新技術への取り組みや、複雑な機能の設計と実装など局所的に使用する分には良い効果や結果が出ることが、実施した結果として分かっている。
「心理的安心感」が最も発揮されるアプローチでもある。
マイクロサービスアーキテクチャを採用しているプロダクト開発の場合、運用フェーズでは多くのドキュメントが必要となるが、それらのドキュメント作成を作らないもしくは後回しにする傾向が実際に結果として現れた。
※マイクロサービスアーキテクチャとして必要となる「REST API仕様」「サービス間連携の可視化」「CI/CDパイプライン」「Kubernetesのマニュフェスト」などが全てのITツールで可視化出来ていれば問題はないが、通常は一度に準備出来ないため、そのためにもドキュメントは必要となる。
開発チームの開発スタイルを全てモブプログラミングで実施する場合、開発メンバ全員がそのスタイルを受け入れ、かつプロダクトオーナーの了承が必要であろう。
パーソナルスペースを重視し、１人での作業を好むメンバがいる場合、無理に参加させると逆効果になるので、そのメンバは１人で作業させた方が良い。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| 新しい技術などの検証にあたり、各々で調査し検証したけっかをチームへフィードバックすることで目的に対して素早く結果を得られる。 | 基本的に出来ないメンバは置いてけぼり。知識の共有はない。そのため後でフィードバックする必要がある。 | 常時やるものとしていないため、必要に応じて実施。 | 以下に記載。 |
モブプログラミングとは異なり、各メンバが色々と調べた結果を１人の実際に手を動かすメンバへフィードバックするスタイルに現実的にはなる。
上記で調査した内容や上手く行った結果をその場でドキュメントに書くなど役割分担も必要になってくる。
総じて、メンバの作業の入れ替えや作業量のコントロールなども難しいため、時間配分をコントロールするタイムキーパーがいた方が良い。
これを使用するユースケースは「全く触ったことのない未知の技術の検証」など非常に限定的な場合となる。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| なし。 | なし。 |
自分個人としては、未実施であるがこのプラクティスを推薦したものでもあるため、経過として記載する。
| メリット | デメリット | 辞めた理由 | 備考 |
|---|---|---|---|
| ディスカッション対象が選別され、MTG時間を短縮させる。 | なし。 | なし。 | ゲーム感覚でやれるので、開発チームに公表とのこと。 |
カネが出ないとこのアプローチは実施出来ない。
以上