QLOOKアクセス解析
ホーム   »  スポンサー広告  »  スポンサーサイト   »  プロジェクトマネジメント  »  「アジャイル開発とスクラム」を読んだので、感想とメモ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「アジャイル開発とスクラム」を読んだので、感想とメモ

「アジャイル開発とスクラム」を読んだので、感想とメモ。

スクラム開発の概要説明、導入の事例紹介とインタビューいった内容で、
・アジャイル開発ってなんだろう?
・スクラムって何だろう?
・スクラムを導入したいけどメリットは?
といった事に興味のある方にはオススメの書籍です。

特に事例紹介とインタビューについては
生々しいというか、導入時にどの現場でも発生しそうな内容が
書かれており、参考になるとともに導入時の
具体的な事例を話す際にも役立ちそうです。

以下、各章ごとの感想とメモ。

●アジャイル開発とは何か?
 アジャイル開発というとウォータフォールと比較して
 イテレーションの開発、生産性向上といった面で語られる事も
 多いように感じていますが、そこは余り重要ではなく、
 協調とコミュニケーション、顧客と開発チームのゴールの共有、
 柔軟な計画変更の考え方といった価値観が重要。

●なぜ、アジャイルなのか?
 「ゴールを共有した開発」というのが興味深い。
 従来の請負開発では、保険的な要素が強くなってしまい、
 開発側は顧客のゴールを目指すのではなく、「仕様通りに作る」ということを
 目指してしまう。これは開発のモチベーションも上がらないし、
 結果的に顧客も欲しい機能が手に入れれない事が多くなってしまう。
 実際にやるのが難しいのは、この実践には信頼関係が必要なこと。
 
●スクラムとは何か?
 未来を予見するのではなく、反復による経験で適応していく考え方は
 とてもしっくりくる。
 
 スクラムで定義されている役割は3つ。
 ・プロダクトオーナー
 ・開発チーム
 ・スクラムマスター
 とてもシンプルでこれが重要。
 テスターやデザイナー、プログラマーといった役割はない。
 この考えもいいなぁと思います。
 役割を細かくした場合のデメリットは、顧客の価値といったゴールを共有しにくくなること。

 デイリースクラム、レトロスペクティブあたりはすぐにでも導入出来る。
 実際には同じような事をやっている場合も多いと思うけど
 このように言葉の定義があると、色々と都合が良い。

●アジャイル開発の活動(プラクティス)
 プランニングポーカーは面白いですね。
 これは1つのやり方ですが、複数人による見積りはとても重要だと思う。
 三回繰り返しても決まらない場合は平均値、または最大値というのが面白い。
 現場では最小値を求められがち、担当者は最小値で見積もりがちですが、
 現実は最大値を超えることの方が多いように感じるので
 最大値を選択するというのは良い考えと思います。

 どちらの見積もりを選択しても結果、かかる工数は同じ・・と思われがちですが、
 最小工数で見積もって実際に工数が増えた場合、
 当然遅延が発生するので、本来は不要であった報告作業や、
 調整作業といった本来は不要な作業が多発し工数が余分に必要になる。

 デイリースクラムは良いですね。
 早速現場で導入したいと思います。
 簡単に見えて奥が深そうなので、少し自分の勉強と
 導入にあたってみんなが目的を共有出来る資料を作成する。

 タスクかんばんはRedmineでやろうと思ってましたが、
 やはりアナログのホワイトボードなどでの運用が早そう。
 一目でわかりやすい、細かな作業もサッと貼れる、楽しそう。
 XP祭り関西2013で紹介されていた、
 自家製の発砲スチロールのかんばんは粘着力もあって、
 持ち運びも自由で良さそうだったので、あれでいこうかな。

 ペアプログラミングはやってみたいプラクティスの1つ。
 ただ現場では費用対効果について説明しにくく導入しずらい。
 やはりコストが2倍にならない?という壁がある。
 今の現場では難しい実装がないのも1つの要因。

●リクルートの事例紹介
 「できるって言いましたよね」に代表される、発注者⇔受注者の考えから
  発生する様々な弊害。これは本当に痛感してます。
 発注者は途中の仕様変更は追加工数がかかるので、あらかじめ色々な仕様を詰め込もうとする。
 結果、不要な機能に不要な工数が使われる。
 受注者は工数不足に陥らないために、責任を問われないために
 バッファを積む、不要なドキュメントをたくさんつくる。
 
 アジャイルの価値観である「協調」によって上記の問題は解決する。
 簡単そうに見えますが、お互いの信頼がないと出来ないことなので
 実践するのは難しい。従来の発注者も今までよりも間違いなく大変になる。
 でも実践すれば欲しい機能が、少ない工数で手に入り、お互い充実感がでるはず。

 総工数をベースラインにしたスコープ管理は
 発注者には勇気のいることだが、結果的にはメリットの方が多いと思う。
 これをやるには進捗、残作業の可視化を平行にやって
 発注者と受注者でしっかり情報共有することが前提。

 MTGで持ち帰りはNG。80%ならOK回答とする。
 正し後でお互いに責めない。
 というのは良いアイデア。これが実践出来たというのはスゴいと感心。

●楽天の事例紹介
 XPの導入にあたって費用対効果が見えない・・という議論に対して、
 まずは一部導入で効果を測定、結果が良ければ広げていくというアプローチはいいですね。

 楽天のようにサービスを提供する会社と、SIerの仕事のアプローチが違う。
 サービスを提供する会社は、リリースしてからが本番。
 こういった開発はアジャイルが特に有効だと思う。
 メンバーが元気になっていった・・というのは面白いです。
 「魔の横展開」(笑。どこにもあるんですね〜

●富士通の事例紹介
 自由な座席の導入は興味深いです。
 ペアプログラミングの導入と自由な座席をやると
 コミュニケーションは促進されそう。検討してみよう。
 チームリーだの定期的なローテーションもいいかもしれない。

Comment
承認待ちコメント
このコメントは管理者の承認待ちです
承認待ちコメント
このコメントは管理者の承認待ちです
承認待ちコメント
このコメントは管理者の承認待ちです
Trackback
Trackback URL
Comment Form
管理者にだけ表示を許可する
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。