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

勘と経験と読経

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

カーゴ・カルト・ソフトウェア工学とか

そもそもソフトウェア工学が死んでいるという議論もあるかもしれないが、これとは別にカーゴ・カルト・ソフトウェア工学的な問題が拡大している実感があるので、それについて考えたことをちょっと整理してみるもの。国内で技術者教育の手法の主力となってい…

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

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

ユーザーストーリーテンプレートゾンビ

書籍「ユーザーストーリーマッピング」を読んでいたら、テンプレートゾンビの話が出てきて面白かった。テンプレートゾンビは、デマルコの「アドレナリンジャンキー」に登場するソフトウェア開発のアンチパターンのひとつだ。というわけでデマルコ本を再読し…

ユースケースとユーザーストーリー

いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる。ユースケースとユーザーストーリーについての説明がすごい腑に落ちたので勢い余って書き付けるもの。アジャイル開発プロセスとユースケースの関係について。 ソフトウェア要求 第3版に…

分散スクラム実用ガイドについて調べてみた

物理的に離れた拠点でアジャイル開発プロセスを実施すること、についてちょっと調べた際のメモ。なお、本によっては「スクラム オブ スクラムでやれば問題ない」といった乱暴な説明もあったのだが、そういった精神論はとりあえず無視。 ディシプリンド・アジ…

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

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

「アジャイルソフトウェア要求」を読んだけれど

書籍「アジャイルソフトウェア要求」の読書メモ。いわゆるエンタープライズアジャイルに関する方法論の一つであるSAFe(Scaled Agile Framework)の解説書。ソフトウェア要求の本ではあるが、事業戦略からデリバリーまでの全ての範囲を含んでいるというのが…

アジャイルソフトウェア要求の読み方を聞いてきた

書籍「アジャイルソフトウェア要求」を読み始めている。高い!厚い!重い!ということで心折れそうだったので、丁度開催されてた勉強会に参加して読み方を聞いてきたのであった。 「アジャイルソフトウェア要求」を学ぶ。 - DevLOVE | Doorkeeper アジャイル…

もしもソフトウェア開発のPMがTRPGのGMだったら

妄想妄言の類い。工程の区切りで正気度チェック!という話ではなく。InfoQで「ロールプレイングゲームのダンジョンマスタとして学んだことをアジャイルコーチングに活用する」という記事を読んで考えたことなど。ちなみに「TRPGのGM」は、「テーブルトークロ…

アジャイルコーチに関する考察

世間ではアジャイルがダメだとかダメじゃないといった話題が盛り上がっていたようだ。個人的には、アジャイルがダメかどうかは知らないけれども貴様のプロジェクトがダメなんじゃね?と思ったのだけれども、その思考は水に流すことにする。ところで話題の記…

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

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

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

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

アジャイル開発モデルは準委任契約を結べば良いという誤解

最初に注意書きを。本エントリは法務面で専門家ではない私が個人として意見見解を述べているものであり内容を保証するものではない(他のエントリもそうなのだけれども)。アジャイル開発に関する諸契約については専門家(自組織の法務部門等)に確認していただ…

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

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

サムライ・エピソードを読んだ

達人出版会から発売された電子書籍「サムライ・エピソード」を読んだ。ひとことで言えば、アジャイルソフトウェア開発に関する日本人開発者26人のエッセイ集である。とはいえ、個人的には「アジャイル部分」は引いて読んだ。普通の開発者による、普通のソフ…

アジャイルとデータモデル、DB進化設計のこと

「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のとこ…

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

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

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

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

目と耳をたくさん集める

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

弾丸が当たったときだけ弾の話をする

このブログで知ったのだけども、フレデリック・ブルックスの銀の弾丸についてWikipediaにすごく詳細なページがある。知らなかった。というわけで、今回は(みんな大好き)銀の弾丸の話。 そういえば此処にも書かれていたけれども、この本をマネージャ屋で未…

いいアジャイルは死んだアジャイルだけだ

大手ベンダーがアジャイル検定を始めるようで、これについてはいろいろな意見が出ているようだ。「これはアジャイルじゃない」というような意見もあるようだけれども、「いいアジャイル」も「悪いアジャイル」も無いと思う。むしろ「いいアジャイルは死んだ…

朝会を進捗会っぽくしない

朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれること…

アジャイル開発に求められる人材像に関する雑感

前回のエントリの反応を眺めながら、そういえば「プロジェクト・マネジャーが知るべき97のこと」でこんな事が書かれていたのを思い出した。 アジャイル開発チームのための技術者を雇うとき、どんな素質が必要だと思いますか? それは幼稚園でうまくやってい…

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

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

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

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

ディフェンシブなアジャイル開発

頭の体操。アジャイルは創発的なアプローチでソフトウェア開発の諸問題を(適したプロジェクトにおいては)解決する。従来の計画駆動開発の石橋を叩いて渡る防衛的なスタイルに比べてオフェンシブな開発と呼ぶひともいる。開発をオフェンシブにした分、開発…

インセプションデッキとプロジェクト憲章

書籍「アジャイルサムライ」で紹介されているインセプションデッキは顧客と開発者の境界を溶かすという意味で面白いツールだと思っている。PMBOKで定義されるプロジェクト憲章は、プロジェクトの全体像を明確化するという意味では重要だったけど、顧客と開発…

マネージャのいないプロジェクトはない

アジャイルで自己組織化されたチームであっても、プロジェクトマネージャやリーダーがいらないということはない。ある条件が揃った時に一時的にマネージャやリーダーが不要という状況はあるが、その状況を人工的に作り出すのは難しいし、短期的なものになる…

朝会は文字通り朝にやれ

アジャイルではないソフトウェア開発プロジェクトでも一般化しつつあるプラクティスの一つに朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム)がある。正しい読み方は知らないけれど、「ちょうかい」ではなくて「あさかい」って言うのが通…

計画的な負債管理

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

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

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

アジャイルプロジェクトマネジメント

邦訳が2005年の本。恥ずかしながらまったくのノーチェック。アジャイル開発プロセスについて網羅的に調査する必要があって、会社の先輩から紹介されたので読んだ。目から鱗が落ちた。アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の…

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

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

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

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