タグ

2011年6月2日のブックマーク (4件)

  • Microsoft サポート

    Copilot Pro でミーティング 最新の Copilot ファミリーのメンバーでは、上位の AI モデルへの優先アクセスが提供されます。また、Microsoft 365 Home および Microsoft 365 Family のサブスクライバーに対しては、現在日常的に使用している Microsoft 365 アプリのための AI アシスタントとなります。 Copilot Pro の使用を開始する Copilot はどこで入手できますか?

  • 特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary

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

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

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

    画面設計とか外部設計とか、もうやめようよ - masayang's diary
  • 「プログラマが体験するべき50の危険なこと」と「きのこ本」 - 日々常々

    「プログラマが体験するべき50の危険なこと」 - Togetterまとめ*1 プログラマが体験するべきではない50の危険なこと - Life like a clown はてなブックマーク - Togetter - 「「プログラマが体験するべき50の危険なこと」」 あるあるネタです。よくある危険な体験談なので、共感を得られるのも当然だと思います。ですが、単に並べるだけでは苦笑やネガディブなネタになってしまい、何も改善されません。 笑って済ませるのは悪です。そんなの皆わかってるでしょうけど、改めて「そんなもの」にしてしまわないように意識して欲しいと思うのです。どこが危険であり、どう改善するべきか。また、なぜそのような事が行われるか。そして実際体験する事になった場合の対処等に展開できたらいいなと思っています。最終目標はこれらの多くを無くす事です。こんな事、体験させるべきじゃないんです。 発端 子

    kamatama_41
    kamatama_41 2011/06/02
    いくつか普通にやってしまっていることがありました。反省しよう。