タグ

ブックマーク / agnozingdays.hatenablog.com (10)

  • ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経

    牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日アジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 件に限らず批判されがちな「ウォーターフォール型開発プロセス(以下WFと記述)」だが、実際のところ皆さんそれぞれ

    ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
    satmat
    satmat 2016/06/23
  • 朝会は文字通り朝にやれ - 勘と経験と読経

    アジャイルではないソフトウェア開発プロジェクトでも一般化しつつあるプラクティスの一つに朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム)がある。正しい読み方は知らないけれど、「ちょうかい」ではなくて「あさかい」って言うのが通例のような気がする。要は毎日プロジェクトメンバーが集まって、簡単に現在の状況や問題点を共有するショートミーティングをやるということ。時間を短く保つために立ってやるため、デイリー・スタンドアップ・ミーティングと呼ばれることもある。http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ItsNotJustStandingUpの解説がお薦め。 朝会が朝会じゃなくなってしまうとき 朝会はアジャイル開発のプラクティスの一つだけど、ツールや既存の開発プロセスとも親和性が高いので導入もしやすい。日の会社社会ではもともと朝の訓示や連絡など

    朝会は文字通り朝にやれ - 勘と経験と読経
    satmat
    satmat 2014/06/06
  • いまさら「モチベーション3.0」を読んだ - 勘と経験と読経

    読書メモ。いまさらなのだけれどもダニエル・ピンクの「モチベーション3.0 持続する「やる気!」をいかに引き出すか」を読んだ。きっかけは先日ブログでも取り上げたソフトウェア開発マネージャの選書リストである。これを書いていて、未読であることに気づいて手にとった次第。なお、要旨は有名なTEDの講演で20分弱で確認できるので未見・未読であればこっちを見ておけばいいような気もする。 Andrew Tourney: 10/31 production test - concurrent upload 2 | TED Talk ソフトウェア開発エンジニアとマスタリー(熟練) 書は既存のアメとムチによる管理(=モチベーション2.0)から、「自律性」「マスタリー(熟練)」「(大きな)目的(意識)」を中心とした動機付け(=モチベーション3.0)への移行について書かれただと考えている。各論ともに興味深いのだけ

    いまさら「モチベーション3.0」を読んだ - 勘と経験と読経
    satmat
    satmat 2013/06/29
  • 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経

    書籍モニターキャンペーンに当選したので、今月末に発売予定の書籍「システム設計の謎を解く」を読み始めた。まだ全部は読み終わっていないのだけれども、設計に関して考えた事について。 システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意 作者:高安 厚思SBクリエイティブAmazon良書の予感(いま3章まで読んだところ)。 ソフトウェアの設計を「考える」 最近の風潮では(あくまで個人的感覚だが)なんというか「設計」は軽視されがちだ。 アジャイル開発のメジャー化に伴って、プログラミングを中心とした方法論やプラクティスは割りと注目されている。 SIerを中心に以前としてあるプロジェクトマネジメントや、要求管理は引き続き注目されている(ような気がする)。 他に、運用関連やテスト(プロセス)関連も割りと話を聞くような。 来はソフトウェア開発のど真ん中にあるべき「設計」に関する話題で盛り

    「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経
    satmat
    satmat 2013/05/22
  • いいアジャイルは死んだアジャイルだけだ - 勘と経験と読経

    大手ベンダーがアジャイル検定を始めるようで、これについてはいろいろな意見が出ているようだ。「これはアジャイルじゃない」というような意見もあるようだけれども、「いいアジャイル」も「悪いアジャイル」も無いと思う。むしろ「いいアジャイルは死んだアジャイルだけだ」と考えている。釣り気味のタイトルだけれども。 もし、ファストフードのような開発をアジャイル開発と呼ぶのであれば、私の中で「アジャイル」は死んだも同然です。言葉の定義なんて変わるものだし、正しい定義を振りかざしても仕方がないのはわかっていますが、バズワード化するというのは、こういうことですね。 「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change! アジャイル開発は、官僚主義的な計画駆動型のソフトウェア開発へのカウンターカルチャー的な側面があると思っている。これが一般化

    いいアジャイルは死んだアジャイルだけだ - 勘と経験と読経
    satmat
    satmat 2012/12/03
  • ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経

    最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。 以前に書いたこの記事も関連。 成功事例には興味がない - 勘と経験と読経 「ソフトウェア開発」とベストプラクティス Wikipediaで「ベストプラクティス」を引くと、こうある。 ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた

    ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経
    satmat
    satmat 2012/11/26
  • ソフトウェア開発における将来要件の扱い - 勘と経験と読経

    ソフトウェア開発におけるムダ | Ryuzee.com の記事が面白かった。別にアジャイル開発プロセスに限らず、ソフトウェア開発にはいろいろな無駄がある。身近でときどき出てくる種類のムダとして「将来の再利用性などの要件を折り込む」ということがある(「使わない機能」の一種かもしれない)。「技術的負債」の逆バージョンについて。 ソフトウェア開発における将来要件の扱い よくあるのはこういった話。 将来の機能拡張を考慮したシステムを構築するという「要求」がある。 未来の要件変更を考慮した機能設計をすることが要求される。 未来の要件変更を考慮した汎用性が求められる、といった場合もこのパターンか。 機能拡張時のコスト削減のために、将来の再利用を想定したものづくりが要求される。 アーキテクチャレベルで将来の変更を想定したり、そもそも変更しやすい設計を行うことは可能だ。しかし、上記に上げた要求に対しては「

    ソフトウェア開発における将来要件の扱い - 勘と経験と読経
    satmat
    satmat 2012/06/26
  • ソフトウェア見積もりとステップ数のこと - 勘と経験と読経

    そういえば、「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」に「ソフトウェア見積り」が入っていなかったのが気になっていた(「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」はちゃんと入っているのに)。 ステップ数見積を見積工程の成果物にすると、計画を立てずに物事を進めるということにつながりやすいので、いけませんよということです。 生産性とかアジャイルとかフレームワークとか言語とかも大事だけど、見積をちゃんとやるのはすごく成功に寄与するよ。 ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山大のブログ 以下個人的な見解。 ステップ数見積もりは思考停止ワードの一種なので、まずこの単語が出て来たらかなり注意する ステップ数見積もりを行うこと自体は悪いことじゃない。ただ、ソフトウェア規模を図る方法の一つであ

    ソフトウェア見積もりとステップ数のこと - 勘と経験と読経
  • ウォーターフォールのほうが楽だという話 - 勘と経験と読経

    わたしはまだ格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い(プロジェクトマネージャーの立場で、スクラムマスター的に推進)。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった? 「第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile

    ウォーターフォールのほうが楽だという話 - 勘と経験と読経
    satmat
    satmat 2012/04/20
  • アジャイル手法によって生産性が上がりプロジェクトは成功するか?(いいえ) - 勘と経験と読経

    ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの(わたしの)プロジェクトにも導入すべき? その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ~ソフトウエア開発を成功させる2つの鍵のバ

    アジャイル手法によって生産性が上がりプロジェクトは成功するか?(いいえ) - 勘と経験と読経
    satmat
    satmat 2012/03/05
  • 1