- Amazon.co.jp ・本 (416ページ)
- / ISBN・EAN: 9784774132495
作品紹介・あらすじ
いつまで「派生開発」で疲労し続けますか?派生開発にはそれに適したプロセスがある!合理的なプロセスと成果物で構成された「XDDP」でデスマーチから脱却を!確実に派生開発プロジェクトを成功させる実践的方法論の登場。
感想・レビュー・書評
-
詳細をみるコメント0件をすべて表示
-
# 書評☆4 「派生開発」を成功させるプロセス改善の技術と極意 | 派生開発の極意は記録にあり!
## 概要
XDDPやUSDM,PFDなど,一部で採用されている開発手法が解説されている本だ。
ソフトウェアやシステム開発においては,新規開発と既存の資産をベースに機能修正・改良を行う派生開発の2種類が存在する。
開発手法では新規開発に焦点をあてたものが多く,派生開発を念頭に置いたものがなかった。そこで,著者が派生開発のための開発手法として,XDDP (eXtreme Dervied Development Process) を編み出した。
XDDPは以下の成果物から構成される。
* 変更要求仕様書
* トレーサビリティ・マトリックス
* PFD
修正箇所に関する情報を,仕様書としてきっちりと文書に残すことで,修正の漏れや修正箇所・方法の誤りが分かるようにしている。
また,開発の工数,変更行数などをきっちりと計測することで,生産性を計測している。
冒頭で,既存の派生開発でよく生じる様々な問題が説明されており,共感した。そして,記録を残すというやり方はいいなと感じた。
ドキュメント作成の方法がまた独特なので,クセがあるが,一度試す価値はあるかなと感じた。
ただ,書籍が冗長な記述が多いので,もう少し要点を絞ってコンパクトにできないかなと思った。文量が多いので,けっこう読むのはたいへんだった。
## 結論
2018-12にある現場の面談で,USDMという文書形式で開発文書を残すという話を聞いて,USDMという単語が気になって調べ,この本に辿り着いた。
開発資料をきっちり文書に残してトレーサビリティを確保するという考え方はいいなと感じた。
実際にこの方法を取り込むには,それなりにやり方を整理して,学ぶ必要があり時間がかかるだろう。
普段の開発でも,自分の生産性を考えることはあまりなかった。開発修了時に,変更前後のコード差分と,かけた時間で自分の生産性 (1日あたりの変更行数) を計測して,今後に役立てたいと感じた。
パーマリンク: https://senooken.jp/blog/2019/08/26/ -
前から入手してあったが、ついに読了。読んだだけですぐに成功すると思わず、粘り強くこの本に戻って、XDDPを手に入れたいと思う。
-
よくお似合いですよ
-
改善や改修に特化した開発プロセス方法が記載されている。ソフトウェアの話として書かれているが、機械や電気系の人にも役立つと思う。特に、組み込み系をやられている方は、殆どの場合、既存製品のモディファイが開発となると思われるので、参考として手にとってはいかがだろうか?
XDDPと呼ばれる筆者が考えた方法論が書かれている。背景まで丁寧に書かれているので、手っ取り早くノウハウを得たい人にはやや冗長に映るだろう。基本的に本手法の肝は、要求からの漏れチェックのための視覚化と要求からの変更内容を導く思考過程の可視化だと思った。よって、その場限りのコード改修と異なり、レビューがしやすくなる上、設計者の従来機種への理解が深まるというメリットが有るように思う。
本手法が新規設計が少ない組み込み業界の開発プロセス標準の一つとなり、多くの設計者が報われるようになることを望みたい。 -
誤字脱字が多く、口説い説明で読みづらいが、多くの知見が得られる
-
希望が見えるような気もするけど、自分の問題への適用可能性は正直やってみないと分からないなーという感覚。手法のエッセンスとバックグラウンドについては完全に同意できる。
-
ソフトウェアエンジニアリングの教科書には「新規開発をどう上手くやるか」について書いてありますが、私たちが日々格闘している「派生開発」については「保守」としてひとくくりにされ、十分な記述がありません。
もちろん、新規開発のノウハウが役立つ部分もあるのですが、筆者の清水吉男は「派生開発の現場では、時間に追われバグを見つけ次第直すという間違ったプロセス」にメスを入れています。
つまり、派生開発においては、
o 変更要求仕様書
o トレーサビリティ・マップ
o 変更設計書
を作るプロセスを提案しています。これらは、実践的で非常に役立つノウハウと思います。口語調で話が整理されていないためちょっと読みにくい点がちょっと残念です。 -
新しい手法は大人数だとなかなか受け入れてもらえないのが悩みどころ。
-
派生開発について書かれた唯一の書籍。
書いてある内容はとっても納得できて効果があるなと思っているのだが、
ちょっと内容がまとまっていない気がする。
本当に必要なところだけにすれば、半分くらいのページ数になるのでは無いだろうか?
この本をベースにして、XDDPを広める活動を起こさないと、なかなか浸透しないと思う。
でも、適用できれば手法自体はかなり効果的だと思っている。 -
・良書。久しぶりに自分でも試してみようと思ったソフトウェア開発プロセスの本。
・個人の思い込みや勘違いを防止する為に、レビュー(他者の視点=組織力)を重視する所は、ワインバーグのエゴレス方式に近い。 ≪参考≫ジェラルド・M.ワインバーグ(著)「プログラミングの心理学―または、ハイテクノロジーの人間学」
・設計に時間を掛ける事で、事前にバグを防ぎ、その結果、プログラム修正の時間は減らせるという考えは、デマルコの思想に近い。 ≪参考≫トム・デマルコ (著)「デッドライン―ソフト開発を成功に導く101の法則 」
・XDDPの成果物は下記の通り。レビュー時に他者の気付きがされ易いように工夫されている。
変更要求仕様 …(What ) どのような振る舞いを変更するか?
トレーサビリティ・マトリクス …(Where) どのモジュールを変更するか?
変更設計書 …(How ) 変更方法について記述する
-
ソフトウェアを今までどおりの作り方で作ればよし, と考えている人には多分よい本だろうと思う. ただ, 自分としてはこのやり方に与しない. このやり方は「取りあえずやるべきことをやる」のが目的であって, 既存のソフトウェアに新しい価値を追加するものではないから.
-
派生開発を実施するためのプロセスが非常に具体的・詳細に記述されている。現時点で反映していくのはややハードルが高い部分もあるがなるほどと思える点も多々あり、タイミングを見て活用していきたい。筆者がコンサルティング業務(といっても第3者的な関わり方ではなく火事になった現場に呼ばれて消火活動の現場指揮を執るような役回りが多いようだ)の中で実践されてきたプロセスを教えてくれているが故の詳細さであることが窺え、内容としては非常に現場感にあふれている。
標準的なプロセスについては一度まとめることと、現状との比較をしながらフィードバックの仕方を考えてみよう。