はじめに
アジャイル開発の現場にアサインすることになったので、事前に勉強したアジャイル関係の知識を整理しました。
雰囲気を掴む事が目的なので大雑把に書いていきます。
用語
プロダクトバックログ・・・プロダクトに追加する要求のリスト
スプリントバックログ・・・バックログ項目の1つを要求、実装、テストに切り出す。
テスト駆動開発・・・開発手法の1つ。テストコードを作成 → テストでエラーになる事を確認 → 実装 → エラーを排除 → ビルド →リファクタリング → テスト成功
デイリースクラム・・・毎日決まった時間に15分で行うミーティング。1人ずつ「昨日やった事」「今日やる事」「障害になっている事」の順に話す。スクラムマスターはメンバーの障害になっている事を取り除くのが役目。すべての状況はPOに報告する。
スコープ・・・プロジェクトで行う作業の範囲と成果に何を含めるかを定めたもの。
フィーチャ・・・ソフトウェアの機能、特徴、性能目標、見た目や使い勝手などを総称する言葉として使っている。ユーザにとっての価値を表すので非機能要件も含まれる。
職能横断型チーム・・・顧客の要望に最初から最後まで応えられるチームのこと。
インセプションデッキ・・・手ごわい質問と課題を10つ揃えたもの。プロジェクト開始前に解決しておく。
バーンダウンチャート・・・チームがどのくらいの速度でストーリーを実装しているかを一目でわかるようにした図。
心得等
・ドキュメントより動くソフトウェアを届ける。
・計画が変化するのは日常茶飯事。柔軟に対応する事が求められる。
・やる事が多すぎる場合やることを減らす。
・テストをたくさん書く。
・プロジェクトの進行中にもアーキテクチャの設計と改善を継続的に行う。
・コードベースをいつでもリリースできるようにしておく。
・やらないことリストを作る。
・プロジェクト開始時にすべての要求を集めることはできない。
・やるべきことはいつだって、与えられた資金や時間より多い。
・自分が作成しているプロダクトを自分で使ってみる（触る）。
・アジャイルのやり方は一つじゃないので、自身で工夫してやり方を模索する。
・役割がはっきりと別れていない。
・分析、設計、実装、テストの工程が独立して行われることはない。途切れることなく連続して行われる。
・チームが一丸となって成果責任を果たす。バグが見つかった際、「自分の担当じゃないから」という文言は通用しない。
・プロジェクトが始まる前にメンバーで集まってコミュニケーションを取ることは大切。
・POが積極的にプロジェクトに参加することでプロダクトの質は上がる。参加してもらえないのであれば、信頼を得るため期待に応え続ける。
・自分で考え、自分で判断し、自分で正しいと思ったことをする事ができる権限を開発メンバーに与えるべき。
・当事者意識や前向きな姿勢が求められる。
・当事者意識や前向きな姿勢が感じられない場合、POに対してデモをさせる事で「自分たちの成果に確信を持つために必要な権限」を要求してくるようになる。そこから当事者意識や前向きな姿勢に繋がる。
・職能横断型チームを構成する人材は基本的にゼネラリストが望ましい。
・アジャイルで正確な見積もりを行うのは不可能。相対的に見積もる。