読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ウォーターフォール型開発プロセスの有効性

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から…

WFとアジャイルと超高速開発・・・

ソフトウェアの開発プロセスの比較記事?を読んだ感想というかメモ書き。なお詳細が書かれていると思われる「ユーザー企業ソフトウェアメトリックス調査2015」は未刊行なので、うわべを見ての野次馬コメント。 ウォーターフォールとアジャイル開発はどちらが…

CCPMを使って組織にアジリティを注入するのは冴えたやり方

先日公開された「NTTデータはどうやってCCPMを導入したのか?」という資料を見ての感想。アジャイルという言葉を前面に持ってこずに、しかし結果として主にスクラムを中心としたプラクティスを現場に注入している(ような気がする)。CCPMを使って組織にアジリ…

「仕様がわからない」と「仕様が決められない」は意味が違う

TL上で目についたこのスライド「ウォーターフォール開発/スパイラル開発/アジャイル開発 お金と契約にまつわる本当の話」を見ながら考えたこと。「仕様がわからない」ことと「仕様が決められない」ということは違う。この二つは区別しなければいけないと思…

チケット駆動開発は「ソフトウェア開発と真剣に向き合う本」

先日発売された書籍「チケット駆動開発」をやっとのことで読み終えた。大変興味深い本だったのだが、仕事の状況などにかまけて通読するのに妙に時間がかかってしまった。ソフトウェア開発のコミュニケーションに関するプラクティスに関する本と捉えていて、…

顧客レビューのうまいやり方

お客様から発注されたソフトウェアを請負で開発する場合に悩ましいのが、顧客(発注者)レビューの扱いだ。そもそもソフトウェアの設計をレビューすること自体が難しいアクティビティである。その難易度に加えて、ソフトウェア開発の専門家ではない顧客(発注者…

Pivotal TrackerをWater-Agile-Fall的に使えるかの実験(Part.1)

プロジェクトの管理ツールとして、Pivotal Trackerがちょっと気になっている。このツールは所謂アジャイル開発プロセス向けに提供されていると理解しているのだけれども、個人的にはプロジェクトにはアジャイルもウォーターフォールも無いと思っている。とい…

日本型ソフトウェアファクトリーこそ真の敵

最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォー…

目と耳をたくさん集める

TwitterのTLを流れていたコトバをキャッチした。なるほど、と思う。 Hiroki Omae (pigeon6): 耳と目は、たくさん集めたほうが情報の量が増える。上手くやれば品質も向上する。「頭」をたくさん集めると、成果物の品質は、そこに集まった最低の人間が決定する…

ウォーターフォールのほうが楽だという話

わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い(プロジェクトマネージャーの立場で、スクラムマスター的に推進)。いくつかのプロジェ…

ソフトウェア開発における多能工の問題

ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェク…

計画的な負債管理

ソフトウェア開発プロジェクトは、ちょっとした問題によって打ち倒されてしまう事がある。少しずつ状況が悪化し始めると雪ダルマ式に問題が山積して、最後には破産する。立て直すことも可能だけれども、できれば破産させないほうがいい。破産する前にやれる…

アジャイル手法によって生産性が上がりプロジェクトは成功するか?(いいえ)

ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの(わたしの)プロジェクトにも導入すべき? その判断はちょっと待ったほうが…

てにをは症候群とその処方箋

ソフトウェア開発プロジェクトでは、ソフトウェアを作る以外に、ドキュメントも作成する。仕様書とか設計書と呼ばれるものがそれで、ソフトウェアが満たすべき条件などが書かれている。なぜこういったドキュメントを書くのかというと、ソフトウェアそのもの…

Water-Agile-Fall:スケジューリングに関するプラクティス

アジャイル開発プロセスのスケジュールに関する考え方が素晴らしい。 一定の期間(スプリント、イテレーション)に可能な範囲のタスク(ストーリー、フィーチャー)を詰め込み、遂行する。 それぞれのタスク毎に終了条件が明確。基本的には「ソフトウェアが…