nDiki : エクストリーム・プログラミング

エクストリーム・プログラミング - Extreme Programing (XP)

rimage:ISBN:0201616416

... This is an absolute truth of software development. The requirements are never clear at first. Customers can never tell you exactly what they want. (p.19)

スポンサード リンク

2004年6月8日 (火)

ソフトウエア開発 55の真実と10のウソ読了

いろいろ考えさせられる本。

ウソ5 - ソフトウエアには、もっと開発方法論が必要である。

というのはかなりドキっとさせられる。開発方法論が駄目だとどうすればいいのか。 (状況に応じて)自分なりのパターンを作って適用していくのも意味がないのか。 毎回毎回うんうん唸ってその場限りの作戦を立てなければならないのか…。

よく読むと

筆者の意見は、小文字の m の methodology は善である。 大文字の M の Methodology は悪であり、使う場合は相当の注意を払うべきだ。

とあり、なるほどと。

アジャイル開発エクストリーム・プログラミングに対する話も随所で述べられていて興味深い。

真実23 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。

もかなり納得。

技術者もそうだが、ぜひ上層部の人たちに読んでもらいたい。 「見積もり」とか「要求仕様」とか「保守」とか。


[ 読書ノート ] [ お薦めの本 ] [ コンピュータ書籍 ]

スポンサード リンク
[ 6月8日全て ]

2005年10月28日 (金)

ソフトウェアかんばん

naney:57031780

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

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

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

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

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

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

まずはこれでスタート。

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

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

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

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

[ 10月28日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

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

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

follow us in feedly

月別インデックス
Process Time: 0.048548s / load averages: 0.50, 0.50, 0.44
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker