Technical Difficulties

Menu

2025/08

📆 Published: 2024-03-03 / 📆 Last updated: 2025-08-03 🕒 History

アジャイルプラクティスガイドブックの116の手法

アジャイルプラクティスガイドブックを読んだ

116の手法

工程管理

1. WIP制限
  Work in Progressの略
1. リソース効率とフロー効率
  工数を無駄なく使うか、リードタイムを優先するか
1. インクリメンタル
  正しく動くもをの小さい単位で積み重ねていく
1. イテレーティブ
  そのときそのときで全体をみて方向を決める

実装時

1. 実装前に方針を話す

ユーザーストーリからタスクへ

1. タスク分解
1. カンバン

完了基準を明確にする

1. 準備完了の定義（Definition of Ready）
1. 完成の定義（Definition of Done）
1. 受け入れ基準（Acceptance Criteria）
1. 未完了作業（Undoneワーク）

実装方針をコメントで表現

1. 疑似コードプログラミング

ブランチ戦略

1. ブランチ戦略
1. トランクベース開発
  壊れないようメンテが必要
1. フィーチャーフラグ
  動く状態を保ったまま機能を継ぎ足す
1. 長命ブランチへの定期マージ
  GitHubだとベースブランチに追従させるオプションがある

コミットメッセージ

1. 読み手に配慮したコミットメッセージ
```
＜概要>
空行
＜本文＞
```
1. コミットを目的別に分ける
1. コミットにプレフィックスを付与する
  機能追加はfeat、バグ修正はfix、スタイル修正はstyleのように
1. コミット履歴を書き換える
  直前のコミットを修正：git commit --amend
  コミット履歴の書き換え：git rebase --interactive
  任意のコミットに修正を追加：git rebase --fixup=<commit>
1. 物語のようにコミットを並べる

ソースコードレビュー

1. ソースコードの共同所有
1. コードレビューにも積極的に参加する
1. ソースコード全体を見てコードレビューする
1. レビュアーはグループにアサイン
1. コードオーナーの設定
  GitHubではマージの際の必須レビュアー設定ができる
1. linter、formatterの活用
1. ツールの出力結果をプルリクエストにコメントする
1. 実装の着手と同時にプルリクエストを作る
1. 親ブランチを使ったコードレビューとマージ
1. レビュアー／レビュイーから伝える努力
1. プルリクエストテンプレート
1. 協働作業でソースコードをよくする
1. コードレビューのやり方を見直す
1. コメントにフィードバックのニュアンスを含める
1. 質問することで学ぶ姿勢を持つ

協働作業

1. スウォーミング他の人を巻き込む
1. ペアプログラミング
1. リアルタイム共同編集機能のある開発環境を使う
1. モブプログラミング、モブワーク

テスト

1. 検証（Verification）と妥当性確認（Validation）
1. 妥当性確認はステークホルダーと一緒に進める
1. 自動テスト
1. テストファースト
1. テスト駆動開発
1. 読みやすいテストコードを書く
  ソースコードを短くする特殊な戦略は取らずに、平易な書き方で
1. テーブル駆動テスト
  抜け漏れ防止のために組み合わせ表
1. 必要十分なテストコードを用意する
  すぐ壊れるテスト書かない
1. ミューテーションテスト
  テストコードのテスト

長期的に開発／運用できるソースコード

1. 長期的に開発／運用できるソースコード
1. リファクタリング
1. リアーキテクチャ
1. ボーイスカウトルール
  来た時よりも美しく
1. 機能の取り下げ方を身につける
1. 依存関係の自動更新

継続的インテグレーション

1. 継続的インテグレーション
1. フックスクリプト
  コミット時に動くスクリプト
1. ツールによるドキュメント自動生成

継続的デリバリー

1. 継続的デリバリー
1. CI/CDパイプライン
1. ブランチ戦略と利用環境との紐づけ
1. ブランチ保護

継続的テスト

1. テストピラミッド
1. E2Eテストの自動化
1. 継続的テスト

デプロイ／リリース

1. ローリングアップデート
  段階的にアップデート
1. ブルーグリーンデプロイメント
  新規環境を作成しリンクを切替
1. カナリアリリース
  新規環境を実験的に公開した後に切り替え
1. データベーススキーマの定義と管理
  スキーマ変更前後でソフト側がどちらでも動けるようにしておくこと
1. デプロイツール
1. ChatOps
  チャットツールからデプロイ指示
1. リリーストレイン
  リリース日程を固定にして、機能を有効化するか判断

モニタリング

1. メトリクス
  CPU使用率などヤバいことが起きたことの検知に使える
1. ログ
1. トレース
  処理の呼び出し関数と経過時間→パフォーマンス改善に使える
1. モニタリングオブザーバビリティ
  ダッシュボード化しやすいか？
1. ログレベル
  Log4Jを参考に：
  TRACE＜DEBUG＜INFO＜WARN＜ERROR＜FATAL
  TRACE：関数呼び出し履歴コンソール出力のみ
  DEBUG：デバッグ用コンソール出力のみ
  WARN：警告
  ERROR：エラー
  FATAL：致命的なエラー
1. Jsonによるログ出力
  jsonやltsvにしとくと分析しやすい

ドキュメント

1. チーム内のコミュニケーションのためのドキュメント
1. READMEファイル
  開発に関わる基本情報
1. Playbook/Runbook
  運用時の手順書
1. Diataxisフレームワーク
  実践／理論 x 学習目的／業務目的

関係者との認識合わせ

1. 関係者を揃える／ゴールを揃える／スコープを揃える
  メンバに不足ないか？ゴールの認識揃っているか？やることの取捨選択出来ているか？
1. ユビキタス言語
  共通言語
1. 実例による仕様
1. 話題が減るまで毎日話す
1. 不確実性の高いものからやる
1. コントロールできる事項は早めに決定する
1. コントロールできない事項の決定はできるだけ先送りする
1. 関係者の期待値を聞いて認識を合わせる
1. 報告フォーマットを揃える
1. 技術プラクティスを適用する余力を確保する

開発内での認識合わせ

1. 事前の設計相談
1. スパイク調査
1. Design Doc

計画の定期的な見直し

1. ユーザーストーリーの分割
1. INVEST
  Independent, Negotiable, Valuable, Estimable, Small, Testable
1. ユーザーストーリーの定期的な棚卸し

チームの基本単位

1. フィーチャーチーム
1. コンポーネントメンターを任命する
1. 会社組織とチーム体制の合わせ方

属人化の解消

1. トラックナンバー
1. スキルマップ

パフォーマンスの測定

1. 相関のあるメトリクスの組み合わせを複数見る
1. Four Keys Metrics
  リートタイム、デプロイ頻度、平均修復時間、変更失敗率

円滑なコミュニケーションのアイデア

1. ただ話す
1. トラベラー
1. Working Out Loud
  自分の作業を皆がいる場で声に出す・チャットする
1. 同期コミュニケーションを柔軟に取り入れる
1. ワーキングアグリーメント
1. オンサイトをリモートと同じ条件にする
1. コラボレーションツールの活用

認識をそろえるワークショップ

1. ユーザーストーリーマッピング
1. サイレントグルーピング
1. バーンアップチャート
1. バリューストリームマッピング

Tags: Agile

« Widnowsシェル拡張開発 GrowiをWindowsサーバで動かす »

Copyright © 2025 Fujimotok

Powered by Cryogen