ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014
ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 ソフトウェアがビジネスの成否を握る時代に、ソフトウェアの品質はどう定義されるのか。9月10日から12日の3日間、東洋大学で開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2014」（SQiP 2014）基調講演では、東京海上日動システムズ顧問 横塚裕志氏が登壇。「ビジネスが変わる…品質が変わる」と題し、ビジネスがソフトウェアによって作られていく時代のソフトウェア品質について、新たな考え方が提唱されました。 そしてこの新しいソフトウェア品質に基づくと、従来のIT業界におけるビジネスモデルやマインドを大きく変える必要があることも説かれています。 基調講演の内容をダイジェストで紹介します。 ビジネスが変わる…品質が変わる 東京海上日動システム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
R・ストールマンの提案「ソフトウェア特許問題の解決策は、範囲にあり」
