タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

devManagementに関するsouskのブックマーク (5)

  • 画面設計とか外部設計とか、もうやめようよ - masayang's diary

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

    画面設計とか外部設計とか、もうやめようよ - masayang's diary
  • 特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary

    Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの29頁を読むと「特徴」がい

    特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
  • まさかの日記:MSの某氏との会話ログ

    コンピュータサイエンス系の人たちの間では、サーチのテクノロジーで人気があるのはリリバンシー、次はバーティカルサーチ。 他の要素としては、クローリングとインデキシング、クラウド系というところらしい。 サーバをグリッド化(やや死語だな)して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。 昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。 あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。 あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。

    まさかの日記:MSの某氏との会話ログ
    sousk
    sousk 2008/07/02
    実装機能一覧、自分で見積もる、時間単位、積み上げたものを消化して行くから右肩下がりのグラフになる .. (最後の詰めや機能削って工数減はよくあるが、納期遅延は一度も無い)
  • ウノウラボ Unoh Labs: Tracに QA(testing) のステータスを追加する方法

    2次元より3次元のほうが好きな hide です。 昨日のmasatoさんのエントリへのコメントで、Tracの話が盛り上がっていたので引き続きTracネタを続けます。今さらTracについての説明は必要ないと思いますが、どんなものかひと言で説明すると、BTSとWikiとSubversionリポジトリビュアーを合体したようなものです。この組み合わせ具合が絶妙で、Tracは様々なソフトウェア開発現場で使われています。有名なところでは、Ruby on Railsの開発にも使われています。 しかし、ウノウではBTSに影舞を使っています。何故かというと、標準ではTracのワークフローは次のようになっていて、testingのステータスがないからです。 最近は、ベータ・クオリティでもいいから、とにかく早くサービスを公開することが重要だという考え方が一般的になってきています。しかし、バグだらけのシステム

  • ウノウラボ Unoh Labs: 共同開発を効率よく行う方法

    尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット

  • 1