nDiki : ソフトウェアプロジェクトマネジメント

ソフトウェアプロジェクトマネジメント - software project management

2005年5月16日 (月)

どうみても、そのままでは失敗しそうなプロジェクト

欲しい機能と完成予定日とを考えると、どう考えても無理なプロジェクトの話が出ているようだ。

真実10. 見積もりは、上層部か、マーケティング部門が実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャーが見積もることはない。結局適切な人が見積もっていないのだ。-- ソフトウエア開発 55の真実と10のウソ p.51

(Fact 10. Software estimation is usuall done by the wrong people.)

まだきちんと見積もりが行われていない。もちろんきちんと見積もるべきである。 きちんとした見積もりを見れば現状の予定は無理すぎ(というか不可能)で、期間をのばして段階的に機能を提供していくべきだということを理解してもらえるであろう。 ……理解してもらえるよね? 不可能がわかっていて無理やり走っていつか闇に葬られるよりいいよね……。

真実9. ソフトウェア開発見積もりは、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発 55の真実と10のウソ p.48

(Fact 9. Software estimation usually occurs at the wrong time.)


[ ソフトウェアプロジェクトマネジメント ]

スポンサード リンク
[ 5月16日全て ]

2005年10月26日 (水)

ナノパーセント日

ミーティングで、あるプロジェクトのスケジュール遅れが議題になった(参加していないプロジェクト)。

リクエスト側と開発側で、仕様の誤解による手戻りが大きな原因のようである。

あたりが問題か。 物理的な距離の壁はデカイ。

それから、β版リリース日がナノパーセント日(あるいはそれよりも前)であった可能性も高いように思えるが、その点はどうか。

(Naney 注:リスク図の)曲線の左側が水平になる地点が、「確率がゼロではない最初の日」である。しかし、限りなくゼロに近い。この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ。-- 熊とワルツを, p.65

自分も「これどれぐらいでできる?」と言われると、つい奇跡的最短期間を口にしがちである。 気をつけねば (もっとも、見積もりとは関係なく期日がセットされていて内容で調整ということも多いが)。


[ ソフトウェアプロジェクトマネジメント ]

[ 10月26日全て ]

2005年10月28日 (金)

ソフトウェアかんばん

naney:57031780

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

  • イテレーションの設定
  • タスクの見積もり
  • ストーリーの見積もり
  • 全体の見積もり
  • 定期的チェックタイムの設定
  • 貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]

[ 10月28日全て ]

2006年11月22日 (水)

プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトマネージャは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が~~で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

[ 11月22日全て ]

2008年6月14日 (土)

スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。

スクラッチから書き直したい理由

スクラッチから書き直したいと思う理由はだいたいこうだ。

  • もっと良くできると思うから
    • 「もっと良いやり方がある」「自分ならもっとうまく書ける」
    • 「統一されていない」「もっと汎用的にできる」
    • 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」
  • よくわからないいから
    • 「何をやっているかわからない」「どう直していいかわからない」
    • 「もう直しようがない」
    • 「作り直した方がはやい」
  • あいつのだから
    • 「あいつが書いたコードだから」

どんなプログラムでも開発が進み詳細がわかってくると、こうしておけば良かったと思う点がでてくるものだ。

さらに、他人が書いたプログラムだとよく分からない。

It's harder to read code than to write it. (プログラムというのは書くより読むほうが難しい。) -- Things You Should Never Do, Part I - Joel on Software

いっそ作り直してしまいたいと思うのはどの開発者でもあることだ。

スクラッチから書き直してはいけない理由

しかし多くの場合スクラッチから書き直すことはリスクとデメリットだらけだ。

  • 今までの投資を失うから
    • 「そのプログラムには検討・不具合修正に膨大なエネルギーが投入されている」
    • 「ユーザは今のプログラムのために学習コストをかけている」
  • 時間がかかるから
    • 「その新しいプログラムが今と同じレベルの価値を実現するまでは時間がかかりすぎる」
    • 「スクラッチし直してから投入したのでは、もはや価値を失っている可能性が高い」
  • 前轍を踏むから
    • 「どう直していいかわからないと思う時は往々にして目標がわかっていない。目標がわからずに作ったものは結局またスクラッチから書き直したくなる」
    • 「あなたが連続的にプログラムを修正できないというのなら、どちらにせよ新しく作り直したプログラムもあなたは連続的にプログラムを修正できない」(リグレッションテスト習慣はあるの? リファクタリングスキルはあるの?)

ほとんどの場合は、漸進的に今のプログラムを修正・改良していった方が得策なのだ。

スクラッチから書き直してもいい場合

そうはいってももちろんスクラッチから書き直した方が合理的な場合もある(書き直してはいけない場合も書き直した方が合理的だと思ってしまうわけではあるが)。

それは次のような場合だろう。

  • ソースコードがない場合 (ディスククラッシュした。利用する権利がなくなった)。
  • もはや開発環境も実行環境も手に入らず、移植も困難な場合。
  • 個人的な趣味のプログラムの場合。
  • スクラッチから書き直したプログラムに対して、また「スクラッチから書き直したい」という欲求にかられない自信がある場合。

本当にスクラッチから書き直した方がよい場合は止める理由はない。

さてこの記事をスクラッチから書き直したいと思う時がきませんように。

参考


[ ソフトウェアプロジェクトマネジメント ]

[ 6月14日全て ]

2008年8月14日 (木)

Joel on Software - 必読書

Joen on Software

スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。

ソフトウェアプロジェクトマネージャ・ソフトウェア開発者必読書の1つだね。

扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。

3章 ジョエルテスト

3分でできるソフトウェアチームの良さを評価する有名なテスト。

5章 やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?

仕様書の最も重要な役割はプログラムをデザインすることだ。p.51

仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。

6章 やさしい機能仕様 パート2: 仕様書とはどんなものか?

サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。

8章 やさしい機能仕様 パート4: ヒント

そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79

これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。

ルール5: テンプレートは有害である p.86

9章 やさしいソフトウェアスケジュール

ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。

「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」

あたりが参考になる。なおこの記事は Webアップデートされている。

12章 5つの世界

開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。

14章 アーキテクチャ宇宙飛行士たちに脅かされるな

抽象化ばかり考えて意味のないところまでいかないこと。

21章 報奨金有害論

つい最近うちの会社でも表彰式があったばかりなんだけれども……。

マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188

多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189

23章 人のタスク切り替えは有害であると考えられる

一つのプロジェクトに専念したいね。

人々に同時に1つより多くの作業をさせるべきではない。p.202

24章 あなたが絶対すべきでないこと PART I

スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

25章 氷山の秘密、明らかに

顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210

これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。

31章 下っ端でも何かを成し遂げる方法

多くの人は自分が下っ端だと思ってモンモンとしている。

  • 戦略1 実行あるのみ
  • 戦略2 じわじわ広めていく
  • 戦略3 優れた人間を作り出す
  • 戦略4 間抜けを無力化する
  • 戦略5 邪魔を避ける
  • 戦略6 かげがえのない存在になる

まずは不満を持つだけでなくて、個人ででも実行しようということ。


[ 読書ノート ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ]

[ 8月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.050518s / load averages: 0.21, 0.27, 0.25
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker