タグ

ソフトウェア開発に関するyosfのブックマーク (9)

  • 開発とテストにおける慎重なオーケストレーションの重要性--ソフトウェア開発(3)

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ソフトウェア開発パラダイムの進化に伴い、ソフトウェアプロセスも進化した。そして、今日のコモディティ化されたソフトウェアには、アジャイルプロセスが非常に適している――メリーランド大学カレッジパーク校 コンピューターサイエンスの教授を務めるAtif Memon氏はこう話す。日では、ビッグツリーテクノロジーコンサルティング(BTC)と共同研究しているMemon氏に、ソフトウェア開発とテストについて寄稿してもらう。今回は1回目、2回目に続く3回目。 1. ソフトウェア開発におけるプロセス指向の視点 ソフトウェア開発のプロセス(ソフトウェア製品として正式に定義されているかどうかにかかわらず)は、ソフトウェアの新規開発または機能強化の目的で実施

    開発とテストにおける慎重なオーケストレーションの重要性--ソフトウェア開発(3)
  • 日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ

    私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日なので日側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この2つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日だとしょっちゅうです。日のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか?いくつかの事例を通じてだんだん見えてきたことは1つのことをこなすための「物量」が違うということです。

    日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
    yosf
    yosf 2016/02/15
    参考になりました
  • 自分の「ソフトウエア実現力」を測る八つの質問

    ITpro読者の皆様、明けましておめでとうございます。2016年もよろしくお願いします。 新年に相応しい話題は何かと考えた末、「自分が所属している組織の実力を自分で確かめてみる」ということを思いつきました。確かめてみて所属先に実力があると分かれば、安心して仕事に取り組めます。足りない点に気付けば手を打てます。実力があまり無いと気付いた場合、転職転身を検討したくなるかもしれませんが、むやみに危機感を煽るつもりはありません。 組織の実力を確かめる前に、組織とは何か、実力とは何かを定義する必要があります。まず、ITpro読者の皆様が所属している組織はすべて対象とします。 いわゆるユーザー企業(情報システム部門や情報システム関連会社あるいは事業部門)と、いわゆるITベンダー企業です。ITを使ってビジネスをしている企業はすべてITベンダーに含めます。先々、ユーザーとベンダーという分け方は無くなってい

    自分の「ソフトウエア実現力」を測る八つの質問
  • ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか? | Social Change!

    「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積

    ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか? | Social Change!
  • 書籍編集局ブログ|Ohmsha

    2月15日(木)に開催された「Developers Summit 2018(デブサミ)」(主催:翔泳社)にて「ITエンジニアに読んでほしい! 技術書・ビジネス書大賞2018」のプレゼン大会と投票が行われ、大関真之先生の著書『機械学習入門 ボルツマン機械学習から深層学習まで』がみごと技術書部門の大賞の栄冠に輝きました! プレゼン大会では大関先生自ら書に関する熱い熱い思いを披露していただました。このプレゼンによって「読んでみたい!」「数式が苦手だけどこのなら読める!」と惹きつけられるオーディエンスが続出!みごと大賞に選ばれることとなりました。ブラボー! 書は、おとぎ話の白雪姫に登場するお妃様と鏡の関係をなぞらえ、その問答により「機械学習とは何か」「何ができるのか」を楽しいストーリーと可愛らしくしかも的確なイラスト、そして数式をまったく用いることなく解説している画期的な内容です。 登場する

    書籍編集局ブログ|Ohmsha
  • 「進捗どうですか?」と聞かれなくて済む、カンバンとGitで始める進捗管理を自動化する方法[PR]

    ソフトウェアの開発プロジェクトには、目に見えないソフトウェアを作っているがゆえに「プロジェクトの進捗が分かりにくい」という悩みがついて回ります。 そこでプロジェクトマネージャが開発メンバーに進捗を聞いて回ることになるのですが、「ほぼ予定通りです」「3日後には終わる予定です」という報告を受けていても、いざ納期直前になって実は大幅に遅れていたことが発覚、プロジェクト炎上を始めるという例は枚挙にいとまがありません。 こうした状況を改善するには、まずはプロジェクトの進捗を可能な限り「見える化」し、問題の早期発見と対策ができるようにしなければなりません。見える化が実現することで個々のエンジニアがどのような作業にどれくらい取り組んでいて、どのような課題を抱えているのかが分かるようになります。 と同時に、「エンジニアは遅くまで残業しているみたいだけど、当に効率のいい作業をしているのか?」といった、ソ

    「進捗どうですか?」と聞かれなくて済む、カンバンとGitで始める進捗管理を自動化する方法[PR]
  • ソフトウェア開発で得た教訓22箇条 | POSTD

    1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い

    ソフトウェア開発で得た教訓22箇条 | POSTD
  • テスト駆動開発とは何か、それを気に入っているのは何故か、あなたも使うべきなのは何故か | POSTD

    ペースが速い現代のソフトウェア開発環境では、テスト駆動開発(TDD)という言葉をよく聞きます。その利点だけでなく欠点についてもソフトウェア開発コミュニティでよく議論されています。TDDについて、”自己嫌悪に陥って屈辱を味わっている者に対する非現実的で効果のない道徳教育のようなものだ”と言う人もいれば [1] 、”リファクタリングを使って迅速な設計を支援するただのツールだ”と言う人もいます [2] 。 「ダメなプログラマは全てに答えを持つが、優れたテスタは全てに疑問を持つ」 Gil Zilberfeld しかし、TDDは新たな手法というわけではありません。広く知られている最も古い文献は1957年に出版されたD.D. McCracken著の『Digital Computer Programming: The First General Introduction in Book Form, St

    テスト駆動開発とは何か、それを気に入っているのは何故か、あなたも使うべきなのは何故か | POSTD
  • ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD

    ビヘイビア駆動開発(BDD:Behavior-Driven Development、振る舞い駆動開発ともいう)を実務に沿って簡単に紹介し、ソフトウェア開発プロセスに対してこの手法がどれほど有益かを説明します。 はじめに BDDで重視しているのは、フィードバックループを最小限に短縮することです。BDDはソフトウェア開発手法の進化の中で、理論的に一歩前進したものといえます。稿ではBDDの概念と、その原型のモデルを説明します。 ソフトウェア開発者や、エンジニア部門のマネージャー職に就いている人ならば恐らく、以下の図のようなウォーターフォールモデルはよくご存じでしょう。 注釈: Waterfall model:ウォーターフォールモデル System Requirements:システム要件定義 Software Requirements:ソフトウェア要件定義 Analysis:要求分析 Progr

    ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD
  • 1