Software Requirements Essentials（2023）をざっと読む - 勘と経験と読経
「ソフトウェア要求 第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。 「私はかつて、過去10年間でベストセラーになった要件エンジニアリングの本を10 冊を読んだことがあります。この1冊には、それらの10冊を合わせたものよりも有益な情報が簡潔に記載されています」-- Mike Cohn ここまで言われたら読むしかない。 Software Requirements Essentials: Core Practices for Successful Business Analysis 作者:Wiegers, Karl,Hokanson, CandaseAddison-Wesley ProfessionalAmazon もくじ もくじ 全体的な感想 ソフトウェア要求 第3版から何が省略されたのか 20のコアプラクティス #1: 解決策を
「Retrospectives Antipatterns」を読んだ - 勘と経験と読経
先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみた。アンチパターン好きなもので。すごい有用な本だった。 Retrospectives Antipatterns 作者:Corry, Aino,Corry, Aino発売日: 2020/11/02メディア: ペーパーバック 著者サイトはこちらのようだ。https://metadeveloper.com/ 全体的な感想 えてして「ふりかえり」のファシリテーターは孤独だと思う。特にファシリテーションすること自体を主な仕事にしている場合、「より良い
情報システムの障害状況ウォッチ（2016年後半） - 勘と経験と読経
SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。 過去に書いた関連記事は以下の通り。 情報システムの障害状況ウォッチ（2016年前半） - 勘と経験と読経 情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム - 勘と経験と読経 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経 SEC Journal最新号の入手はこちらから。 最新号とバックナンバー：IPA 独立行政法人 情報処理推進機構 情報システムの障害状況ウォッチ（2016年後半） 詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案
ソフトウェア見積もりと納期のいくつかの真実とウソ - 勘と経験と読経
ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。 ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである 論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。 この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
社内勉強会をやらない理由 - 勘と経験と読経
ときどき「社内勉強会をやってほしい」という事を言われることがあるのだけれども、基本的には断るようにしている。その理由について。 社内勉強会は言われて始めるものじゃない 「社内勉強会をやってほしい」と人に言われても基本的には断っている。こういったことを言うのは自分の上司や関連部門の偉い人に多い。言う人は、きっとこんな期待をしている。 メンバーの底上げやレベルアップ 生きた知識を現場間で情報共有する メンバー間の交流でより良い結果が得られるようになる でも実際に言われるがままに勉強会を企画しても、 人が集まらない 発表者が偏る 発表者の負担が増えていき、開催されなくなる ということになるのがわかっているから、実施しないのだ。 どうしてこんな事が起こるのかというと、単純にマーケットが小さすぎて、企画が成立しないのだからだと思っている。そもそも、コミュニティ活動を真っ当に実施できているエンジニアは
ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経
最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。 以前に書いたこの記事も関連。 成功事例には興味がない - 勘と経験と読経 「ソフトウェア開発」とベストプラクティス Wikipediaで「ベストプラクティス」を引くと、こうある。 ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた
ソフトウェア開発プロジェクトは「負ける」宿命なのか - 勘と経験と読経
「どうやったらプロジェクトの失敗を防げるか」について話していたら、後輩の一人が面白い事を言った。「システム屋は最初から負けている」。くわしく聞くと、こういうことらしい。 ソフトウェア開発プロジェクトの総予算は早い段階で確定していて、増額は困難である。 早期に全ての要求を見通すことは不可能であり、プロジェクトを始めていくとスコープは少しづつ増えていく。原価も増えていく。 プロジェクトを開始した以上、途中でバスを降りることは不可能である。収益が悪化しても走り続けるしかない。 故に、われわれシステム屋は「負ける」宿命を負っている。 いろいろとツッコミどころはあるのだけれど、想う所を整理してみたい。 じゃあビジネスアジャイルだ、ということではない アジャイル脳的な反応が容易に予測できる。 最初に大きく計画し一括で開発しようとすること自体が誤り。リスクを極小化しビジネス価値を最大化するために、アジャ
朝会を進捗会っぽくしない - 勘と経験と読経
朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。 朝会のミニ進捗会化 デイリースタンドアップ／スクラムはスクラムマスタのためのものではない そもそも朝会のようなコミニュケーションの場は特殊で、（日本人にとって）普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有（先生や上司の話を聞く）かボトムアップの報告（上司やリーダーに報告連絡）だから、放っておくと朝会もそうなりやすい。 うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わっ
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
