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

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

Extreme Programming Explained: Embrace Change Kent Beck による入門書。

... 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 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。

もかなり納得。

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

[ 書評 ] [ お薦めの本 ] [ コンピュータ書籍 ]

◇ Twitter やってます。この記事が気にいったらぜひ twitter.com/Naney の follower になってください。

[ permalink ]

[ 6月8日全て ]

2005年10月28日 (金)

■ ソフトウェアかんばん

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

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

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

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

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

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

B6 情報カードを使う。
- この大きさだと書くにはちょうど良さそうだが広い壁が必要になりそうだ。
エクストリーム・プログラミングのように、まずはストーリーカードを作成する。
- 今回はベースとなる仕様書の機能を実装する形。ビジネスサイドがストーリーカードを作るという体制にはできないので、開発チームでストーリーカードをおこす。
ストーリーカードからのタスクカードおこし。
- 時間の関係から、まずは優先度の高いストーリーカードを選んでこれをタスク化する。
- タスク化済みのストーリーカードは(tなどの)マークをつける。
タスクカードのカテゴリは「TODO」「DOING」「CHECKING」「DONE」の4つとする。
開発者は TODO タスクカードから1枚カードを選んで署名して DOING へ移す。
タスク作業完了後「DONE」あるいは「CHECKING」へ移す。
- 「CHECKING」はチームはタスクを受け持った人が作業完了後、チームでチェックをして欲しい時に入れられるカテゴリ。
- カテゴリ名はこれでいいかな?