QLOOKアクセス解析
ホーム   »  プロジェクトマネジメント
Category | プロジェクトマネジメント

スポンサーサイト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スポンサーサイト

[書評]ソフトウェア見積り 人月の暗黙知を解き明かす

だいぶ以前に読んだ本なのですが、最近見積もりで色々と考える事が多くなり
改めて「ソフトウェア見積り 人月の暗黙知を解き明かす」を読んでみました。

この本の優れていると思う点は現場で実際に有用な
見積りのポイントについて多く記載されているところです。
見積り手法などについても記載はありますが、
ステークスホルダーが求める見積とは?や、
過去プロジェクトの実績からの考察など、とても現実的な視点でのアドバイスが多くあります。

本の中でも記載されていますが、
「サイエンスとしての見積り」ではなく「アートとしての見積り」を重点に記載されています。
面白い表現ですね。

以下、気になった部分の紹介とコメント。
また数年後に見直すと違う観点が出てるんでしょうね。楽しみです。

見積りを求められた時は、実際に見積りを行うのか、ターゲットの達成方法を
たずねられているのかを判断すること

見積りにとって重要なのことは、完璧なまでに正確であることより、
有用な情報を提供することである

非常に良くあることと思います。「見積りして欲しい」という要望について
何が求められているか?をしっかり判断することはとても重要です。
スケジュールを優先したい場合、予算は気にしないのでフル機能を搭載したい場合、
決められた予算・スケジュールで優先度に従い機能を搭載したい場合・・・
色々なケースがあり、それぞれで見積り/計画提示の内容が変わってきます。
それを理解せずに単純に工数を積み上げ、スケジュールを引くことはやってはいけないこと。
大体のステークスホルダーからは「ビジネスの分からない奴」と思われてしまうと思います。

ソフトウェアには偏りのない見積りという問題はない。業界のデータは、
ソフトウェア業界には過小見積りの問題があることを明確に示している。』

これ、ホントにそう思うのですが意外にそういう意見を聞かないです。
ほとんどのプロジェクトが予算やスケジュールを超えているのが現状だと思います。
問題だと思うのは、上位層の考えとして、例えば50人月の予算要求があった仕事であれば
30人月の予算でスケジュールを組んでおく。出来ればラッキー、遅れたとしても
もともとの50人月で終わるだろう・・という考えが多い事です。
実際にはそうはならないです。
無理をして組んだスケジュールで遅延が発生していった場合、
ある特定チームの遅れによってモジュール結合が遅れて、その待ちによって
遅延が拡大したり、品質低下によるロスが起きたり、遅延が出れば
余分な報告工数などが増えたり・・・とまともな計画をしていれば
不要であった工数がどんどん増えて行きます。結果ほんとは50人月で終わっていた仕事も
60人月、70人月かかって終わってしまう事になります。
しかしこれをステークスホルダーに理解してもらうのは難しかったりします。

その他色々あるのですが、ややこしい数式のお話は少なく
『考え方』や『仕事に対する姿勢』について色々と勉強になる本でお気に入りです。

見積りというとお金のお話が先にきてしまい、ユーザーと敵対関係になりがちですが
お互いのゴールはプロジェクトの成功であり、その視点から考える事の重要性を思い出させてくれます。


「ゲーム開発プロジェクトマネジメント講座」の資料を読んで・・・

スクウェア・エニックスのオープンカンファレンスのプログラムで
「ゲーム開発プロジェクトマネジメント講座」というのがあったらしいのですが
その資料がとても良く出来ており勉強になったので資料のメモと感想。
来年書籍が出るようなので是非購入したいと思います。

資料はコチラ↓
http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf

内容も良いと思いますが資料の見せ方もうまく、とても分かりやすい資料で
見せ方の勉強にもなりました。

以下は内容についての感想。


「プロジェクトとは不確実なものである」という前提を受け入れて
『制御』することが大事・・という部分は本当にそうだと思います。
大規模プロジェクトになればなるほど見積りの不確実性は高くなり、
予想するとうことは不可能になります。
「不確実」という前提で考えれば、色々な仕掛けをしておくことが出来ますが
まだまだそういった考えは少ないように思います。
「完全に安全」の前提で考えて問題発生した場合の事を考えていなかった
原発の事を少し考えました。


イテレーションの表現でミサイル制御と迷路を例にされていましたが
とても分かりやすかったです。今後は周りに説明する時に引用します。
アジャイルとウォーターフォールの融合は同意。
自分自身が経験した感覚からいうと、大規模プロジェクトでは
この2つを融合させた運営がうまくいくのではないかと思っています。
大きな計画と戦略、細かなイテレーションどちらも大切です。


「商品の価値空間」の表現は面白かったです。
私はSIer的な仕事が多いのですがどうしても「開発側の視点」というのが強くなります。
しかし、今後は「商品の価値」という視点でものごとを考え、提案することが出来ないと
仕事はなくなっていくと思っています。
「プログラムとお金を結びつけること」というのが今後特に大事と思っているのですが
そういった事を考えるのにこういった図を使うのは良いなぁと思いました。


見積もりについて。
2点見積もりはとても有効な見積もりと思います。
私も良く複数の開発者に見積もりを依頼して補正します。
「パーキンソンの法則」、「学生症候群」は開発者のPDCAを
しっかり行う事で回避できると思います。
私の場合は細かく日報で数値報告をしてもらう事でカバーしています。
デイリーで作業進捗を確認しグラフ化するとごまかしが利かなくなるので有効です。
見積もりポーカーは見積もり精度向上よりも
その説明をお互いに聞く事でナレッジ共有やスキル向上に良いのではないかと思いました。
今度やってみようと思います。



週報、週定例は私の現場も同じような感じで運用しています。
これに日報が加わり、基本的にはデイリーでCheckとActionを行います。
週間だと手遅れだったり、無駄が多くなったりするので。
ただ、まとめた結果はメンバーではなくお客様にしか報告していないので
この紹介例のようにメンバーへの発信も情報共有という点で良いなと思いました。


スプリント振り返りというのは良い案だと思いました。
私が関連するプロジェクトではフェーズ毎/プロジェクト毎の振り返りはありますが
それだとスパンが長くなってしまうこともあり、
メンバがいなくなっていたり、問題点を忘れていたり・・・と
デメリットが多いです。やはり鮮度の高いうちに振り返りを行うことは
とても重要だと思うので取り入れたい内容です。


見積もりの難しさ

永遠のテーマですが「見積もり」についてです。

現在担当プロジェクトの振り返り作業を実施しており生産性の確認も行っているのですが
何を持って生産性が高いとするのか、低いとするのかが非常に難しいです。
ここが難しいということはパラメータがぶれるということで、次回の同様のプロジェクトの
見積もりも難しいという事です。

今回ですと既存システムのカスタマイズ対応だったのですが
LOCベースで生産性を確認すると前プロジェクトの半分程度の生産性になります。
しかし修正画面数や、修正クラス数といったパラメータで見てみると40%程度の改善が見られます。

LOCベースで生産性が低くなっている要因は前プロジェクトが新規案件であったのに対し
今回はカスタマイズ案件であり、影響範囲に比べ修正コード数が少なかった事が要因ですが
これだけ見方によって生産性に違いがあるということは、見積もりのパラメータを間違えると
とんでもない事になるということでもあります。

私の見積もり手法は、現在の現場ではお客様がLOC法をベースとされていることもあり
・積算法、WBS法
・LOC法
・過去プロジェクトの実績値
をMixした見積もり手法を取っていますが、この弱点は上記の見積もりパラメータを何にするか?
で何倍もの開きが出てしまう事です。
非常にやっかいですが今の現場ではもう少しお付き合いが必要そうです。

では、どうあるべきか?を考えましたが個人的にはやはりFP法が現在Betterな選択であると思っています。

・ユースケースに対して見積もりを行うので顧客との価値に乖離が少ない
 ユースケースが複雑な場合、見積もりも大きくなるが納得感がある。
・言語や設計に依存しない

が主な推薦理由です。
とはいっても顧客の価値が少なくても実装は大変・・・という場合もあるし・・
などと思っていた時もあるのですが、良く良く考えてみるとそういった場合は
ソフトウェアの設計がまずい場合が多いです。

なので基本的にはユースケース単位で見積もりを行い、
ユースケースの価値に対して実際のコストが多い場合は、そのソフトウェアは顧客の要求に
マッチしていない事が考えられるので設計を見直す・・のような流れが妥当ではないかと思いました。

少なくとも現在においてはLOC法は不適切ではないかと思います。
どちらかというと少ない行数で大きな価値を出せるソフトウェアの方が魅力的です。
LOCでステップ数が大きいと工数が大きくなる見積もりをしていると
そのプロジェクトではあまり創造性がでてこないんじゃないかなぁと思います。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。