アジャイルサムライ（要約） その２
１．アジャイルなプロジェクトのあり方
- 役割分担をはっきりさせない。個人によって強みもあるが得意分野に固執させない。（アナリスト、UXデザイナ、プログラマ、テスター・・）
- ソフトウェアの開発工程を１度限りで終わらせるのではなく、スプリント単位のように連続的な取り組みとする（分析、設計、実装、テスト）
- 品質保証など成果責任はチームで持つ。（縦割り組織にしない）
２．チームをアジャイルにするためのコツ
- １．同じ仕事場で働く
- チームが分散している場合もあるが、プロジェクトが始まる段階での数日間は集まって一緒に食事を取ったり冗談を言ったりする事で高いパフォーマンスが得られる。 その後はSkypeやビデオチャットを活用しても同じ仕事場にいるかのように働ける。
- ２．積極的に深く関わる顧客の存在
- ビジネス側の人と開発者はプロジェクトを通して日々一緒に働かなければならない。その為には自分で動きお客さんとの信頼関係を築き巻き込んでいく。 （一例として、「これから２週間でお客様の問題を解決します！」と宣言してみる。許可は求めなくてよい。２週間後どうやって解決したのかを報告。これを3,4回繰り返してみる）
- ３．自己組織化
- 自己組織化とは、目標に対して一歩下がった視点からチームで客観的に考える。この際に自らのエゴを押し出し過ぎないようにチームで力を合わせるという事。 その為には、個人が当事者意識を持ち、肩書きを気にせず動くソフトウェアを提供することに注力する。他の誰かの指示を待つような人はメンバーにふさわしくない。
- ４．成果責任と権限委譲
- 成果責任を果たすためには権限が開発チームへと適切に委譲されなければならない。自分達で判断し自分で実行できるだけの権限を与えること。成果責任を実感させるためには開発したものを顧客にデモする事が一番の近道。
- ５．職能横断型チーム
- 顧客の要望に最初から最後まで応えられる開発チームのこと。これを実現するには開発チームに幅広い専門知識とスキルが必要となる（プログラマで言えばフロント、バックエンドどちらかに偏らない）
３．アジャイルな役割
基本的には何を作るべきか分かってる人（顧客）、それを作る事のできる人（開発チーム）がいるだけ。
メンバーにどの役割が割り当てられるかは気にしないが、各役割によって果たされる仕事は以下となる。
- １．アジャイルな顧客
- ・何を作るか決める（ユーザーストーリーを作る）
- ・優先順位をつける（技術的な部分は開発チームから提案）
- ・スコープについて判断（機能の削除、納期の延期、予算追加など）
- ２．アジャイルなアナリスト
- ・ユーザーストーリー作成の補助
- ・ストーリーの分析（モック、プロトタイプの作成）
- ・必要な調査をスプリント毎にやり遂げる
- ３．アジャイルなプログラマ
- ・ユーザーストーリーを動くソフトウェアにする
（テストをたくさん書く、アーキテクチャの設計/改善を継続的に取り組む、常にデプロイできるよう心がける） - ・チームメンバーと作業工数を見積もる
- ・技術的な判断を下す
- ４．アジャイルなテスター
- ・ユーザーストーリーテスト（受け入れテスト）を書くのを手伝う
- ・ストーリーの動作確認
- ・テストの全体像を考える（探索的、性能、負荷、セキュリティ）
- ・テストの自動化、不具合発見を手伝う
- ５．アジャイルなプログラムマネージャー
- ・現状の把握（常に着地点を気にするが、何をすべきかなんて指令は下さない）
- ・進捗報告
- ・現状のチームの障壁を取り除く（継続的な計画の立案、改善）
- ６．アジャイルなUXデザイナー
- ・ペルソナの考慮
- ・絵コンテ、ペーパープロトタイプ、コンセプトデザインの作成
- ・使いやすく、利便性の高い、魅力的な体験を顧客に提供することに注力
- ７．その他の役割
- ・DB管理、システム管理、インフラ管理ほか上記以外の役割も全て開発チームの役割
- ・新しいチームを軌道に乗せるスクラムマスターがいると非常に助かる。（但し専任でなくともよい）
４．チームメンバーを探すコツ
- ゼネラリスト（プログラマならフロントからバックまでどこでも担当可能、アナリスト、テスターならどちらも安定してこなせる）
- あいまいな状況に抵抗がない人
- 我を張らないチームプレーヤー
0 件のコメント:
コメントを投稿