サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
ITmediaのブログにて、「オープンソースの注意点」なるエントリを発見した。要旨をまとめると、「オープンソースソフトウェアは開発者が自分の環境のみで開発を行ってしまう傾向があり、そのため公開されたソフトウェアを実行しようとすると環境の違いによってエラーになる場合がある。そのため、オープンソースソフトウェアを利用する場合は開発を行っている会社を調べる方が無難」ということらしい。 個人的には、開発者が個人であろうがなかろうがこのような問題は発生し得ると思うのだが、このような理由でオープンソースソフトウェアの利用が制限される/忌避されるのなら非常に残念だと思う。
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
開発者にアジャイルを強制するのは、危険信号だ（Imposing Agile Is A Very Red Flag）とマーチンファウラーが書いた。 http://martinfowler.com/bliki/AgileImposition.html 要約すると、アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。 というのだ。 チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
