タグ

2016年6月1日のブックマーク (5件)

  • 第5回 アジャイルな要求定義に求められるもの

    研究所では、アジャイル開発を素材に、より良いシステム開発のあり方を求めていきます。開発手法そのものを見直すことは、より良いシステムを作るだけではなく、開発を担当するチームが成長し、個人の満足度も高まると考えられるからです。今回は、アジャイルと要件定義の関係について考えてみます。 みなさんはもう十分に実感されているかもしれませんが、ここ最近の私は、アジャイル開発における要件定義の重要性を改めて認識するようになりました。アジャイル開発といえば、要件定義よりも「まずは作ってみる」といったイメージが強いかと思いますが、要件定義が重要な作業であることには変わりがないと考えています。 一般的に、アジャイルではユーザーが実施したいことを端的に表した「ユーザーストーリー」を作成し、開発を進めていきます。ですが、これまでの私が「それだけでは要件定義が不足している」と不安に感じていたのは事実です。 そんなと

    第5回 アジャイルな要求定義に求められるもの
    s17er
    s17er 2016/06/01
  • アジャイルを無責任に広めるのはもうやめよう

    (画像:wikimedia commons) こんな記事を見かけました。 記者の眼 – 「アジャイル嫌い」はもうやめよう:ITpro http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1 開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝するやブログなどは多く、「プロジェクトを始めよう!」となったときに、候補に上がることが多い開発手法ではあります。 しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。 私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです(ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはあり

    アジャイルを無責任に広めるのはもうやめよう
    s17er
    s17er 2016/06/01
  • 画面設計とか外部設計とか、もうやめようよ - masayang's diary

    昨日は特徴(Feature)、粗筋(Story)、脚(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう? 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え

    画面設計とか外部設計とか、もうやめようよ - masayang's diary
    s17er
    s17er 2016/06/01
  • Using MySQL/InnoDB/行レベルロック: デッドロックを回避するために、実用上最低限必須の知識 - Qiita

    デフォルトの isolation level (トランザクション分離レベル) はREAD COMMITTEDに変更するべき 内部が不透明な既存アプリケーションを変更する場合等、クリティカルな場合を除いて、InnoDBを利用する場合はデフォルトのisolation levelをREAD COMMITTEDに変更するべきである。 根拠は MySQL (InnoDB) でデッドロック検知される条件について - QA@IT ここに解説がある。 Railsでは、 以下のページに書いてあるようなモンキーパッチでデフォルト設定の変更が可能である。 Rails 4では、トランザクションにオプションを渡すことでも変更が可能である。或いは、my.cnfで設定することも可能である。しかし、これはDBレベルの話ではなくアプリケーションレイヤーの話なので、アプリケーション側で修正するのが望ましいと僕は思う。 参照:

    Using MySQL/InnoDB/行レベルロック: デッドロックを回避するために、実用上最低限必須の知識 - Qiita
    s17er
    s17er 2016/06/01
  • なぜエンジニアはマネージャーをやりたがらないのか - クラウドワークス エンジニアブログ

    最近ベイスターズが強くて毎日が楽しいクラウドワークスの安西です。マネージャー的なお仕事をやらせていただいております。やっていることはこんな感じです。 社内もそうなのですが、社外の各社さんに聞いても、エンジニアがマネージャーをやりたがらないという事案が発生しているようで、空前のエンジニアリングマネージャー不足であると勝手に認識しています(当社比)。 ということで、メンバーの力も借りつつ、なぜエンジニアはマネージャーをやりたがらないのかを考えてみました。 マネジメントとは? そもそもマネジメントとは何なのでしょうか?検索すると様々な解釈が出てきます。それぞれ微妙に違ったりしますね。 d.hatena.ne.jp 【management】経営、管理。 目標、目的を達成するために必要な要素を分析し、成功するために手を打つこと。 ビジネスにおけるマネージメントに必要な要素 1.目標、目的を明確化する

    s17er
    s17er 2016/06/01