Redmine UltimateAgileStories1で書いた内容
最近、UltimateAgileStories Iteration2(UAS2)のエントリ(UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊目･･･「UltimateAgileStorie...
ソフトウェア開発
Redmine 
ソフトウェア開発 Jenkinsさんと気軽に友達になってみませんか？
今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員･･･と言うほど、色々なことをしてもらっています。使い始めるのは簡単だけど…一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後...
ソフトウェア開発 仕様凍結のつぶやきのその後
「外部設計はこれでOKですね？ハンコ押してください。これで仕様凍結します。これ以降は仕様変更になります」なんて会話をお客様にして、良い気持ちで押してくれるお客様なんていないよ。— yoh nakamura (@yohhatu) 2011年8...
ソフトウェア開発 エンドユーザの声を知る大事さ
システム開発プロジェクトでは、それを実際に使うエンドユーザと接点があるかで、満足度を高くできる可能性が大きく変わると思います。(プロジェクト規模にもよりますが)セキュリティ面やお客様内の情報システム部の存在により、直接エンドユーザと話したり...
ソフトウェア開発 変更履歴を論理的に見ておかしいと思わないのは…
仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。SEが作成するドキュメント(堅く言うと「成果物」)にはたいがい「変更履歴」を記入する欄があります。変更日や変更者、変更箇所等を書いてい...
ソフトウェア開発 ペアプログラミング―エンジニアとしての指南書[読書感想]
ペアプログラミング―エンジニアとしての指南書著者：Laurie Williams, Robert Kessler翻訳：長瀬 嘉秀, 今野 睦, テクノロジックアート今の小規模プロジェクトで、ペアプログラミングをしていました。2人チームだった...
ソフトウェア開発 仕様を縦断する視点、横断する視点
外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。そこではある要求仕様が、その該当画面(とそこで定義されている機能)...
ソフトウェア開発 プロジェクトの種々なこと
「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。1：全体像を見れない人、見ない人自分の担当分以外...
ソフトウェア開発 未来の自分を信頼し過ぎない
プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。色々な理...
ソフトウェア開発 日常の意思決定にも使えるかも…狩野分析法
にて狩野分析法というものが紹介されていました。「Agile開発で～」と書かれていますが、Agileで無い場合でも使えそうです。実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的判断...
ソフトウェア開発 ドキュメント修正の大事さ
プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。言いたいこと仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないように...
ソフトウェア開発 テーブル設計の指針(備忘録)
最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。サロゲートキーとナチュラルキー主キーの設定時に大きく2つの設計指針があります。1つは顧客マスタにおける顧...