構成管理、変更管理、プロジェクト管理の密接な関係 - プログラマの思索
2005年に書かれた@ITの記事を読んで、この記事に書かれている内容は全てRedmine＋チケット駆動開発で実現できると直感したのでメモ。 【元ネタ】 ＠IT：意外と知らない構成管理の正体（1）第1回 ファイルバージョンの管理だけで十分ですか？ ＠IT：意外と知らない構成管理の正体（2）第2回 プロジェクトの構成要素を探す手順 ＠IT：意外と知らない構成管理の正体（3）変更管理、その正体と対策 ＠IT：意外と知らない構成管理の正体（4）構成管理とプロジェクトマネジメントの関係 構成管理は誰のためのものなのか？: プログラマの思索 (引用開始) ただ、プロジェクトは、最後にきちんと納品さえすればよいというものではないのです。いつでも、指定された時点におけるプロジェクトの結果、状態を把握できなければいけないということなのです。そこには、タスクの依存関係、成果物の依存関係、それぞれに要したコスト
チケットの使い方 - Meadow - Trac
チケットの使い方 作成されたチケットはどのように使っていくのがよいかを説明します。 筆者の個人的な見解がたぶんに含まれていますのでご注意を。 なので、ここで述べる内容に従わなきゃいけないなんてことはありません。 臨機応変に使っていきましょう。 まずはおおまかに チケットは単純で、およそ2つの状態と思ってよいでしょう new または reopened あるいは accepted などの、チケットが活きている状態 closed した、つまり完了した状態。 チケットを作成した直後は、状態として new となります。 通常のプロセスで行くと、作業担当者が acccept(担当)し、accepted 状態になります。 そして実際に作業が完了したら "resolved as 'fixed'" として、closed 状態になります。 あるいは、チケットの内容が標準外のelispパッケージによるものでme
UMLの手軽で有効な利用方法
1. はじめに オブジェクト指向モデリング言語として誕生したUML（Unified Modeling Language）は、今日、ソフトウエア業界で広く利用されています。しかし、読者の中には「UMLを使ったことが無い」または「使ってみたが効果が無かった」という方もいらっしゃるのではないでしょうか。 そこで、本連載では、UMLの導入に敷居の高さを感じている方を対象に、UMLを用いたモデル（以降、UMLモデル）の、手軽で有効的な利用方法を、筆者の経験を交えて紹介します。 なお、UML仕様に基づいた厳密で正確なモデルの作成方法や、モデル駆動開発の方法といった、敷居が高いトピックについては解説しません。もっと根本的なUMLモデルの活用方法を紹介します。 2. モデリングとモデルのメリット 2.1. コミュニケーション・ツールとしてのUML UMLモデルについて解説する前に、そもそも「モデリング」や
手順を共有していないから、改善活動が混乱する − ＠IT情報マネジメント
手順を共有していないから、改善活動が混乱する：プロが教える業務改善のツボ（3）（1/2 ページ） 業務改善の活動において「手順」は重要だが、こだわらなくてもよいところにこだわりすぎるとかえって迷路に迷い込んでしまう。今回は、「手順」のこだわるべきポイントはどこなのか？ 陥りやすいワナはどこにあるのか？ 大切なポイントをお教えしよう 第1回、第2回では、原因分析のロジックツリーを使って、「縦（深さ）」と「横（広がり）」という2つのベクトルで問題の原因（真因）を突き止め、それを除去することによって、「問題の再発を根本から防止できる」と解説しました。今回は、そうした原因分析を基に、実際に業務改善を進める際のポイントを紹介しましょう。 業務改善の「手順」より、「手順に対する共通認識」にこだわれ！ 皆さんも「これから仕事に取り掛かるぞ！」というときには、まず段取りを考えることでしょう。「段取り八分」
[Think IT] 第1回：エンピリカルソフトウェア工学を学ぶ前に (1/3)
【バグ管理の作法】 エンピリカルソフトウェア工学に触れる 第1回：エンピリカルソフトウェア工学を学ぶ前に 著者：シンクイット編集部 公開日：2007/12/5（水） エンピリカルソフトウェア工学とは Think ITの12月の特集「バグ管理の作法」では、ソフトウェア開発では避けて通れないバグに焦点をあてている。その中で、水曜日は少し学術的な内容について取り上げる。11月の「新・言語進化論」では、「仕様記述言語」について解説した。今回は「エンピリカルソフトウェア工学（Empirical Software Engineering）」について取り上げてみたい。 近年のソフトウェア開発は急激な成長をみせ、いろいろな手法や考え方が導入されつつも、さまざまな問題を抱えている。特に現在では、ソフトウェアに生産性と高品質の両方が求められており、読者の皆さんもその実現に常に追われているのではないだろうか。
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
TDDを真面目にやってみて気付いたこと - Masatomo Nakano Blog
何を今更、なことかもしれないないのだけど、もしかしたらこれを知ることでTDD(Test-driven development)をやることのハードルが一気に下がる人がいるかな、と思ってメモ。 特に、ある程度プログラマとして経験があるけど、どうもTDDは慣れないという人向き。 “TDDとは、TDD以前に脳内や機上でやっていたことをコードに落とすことに過ぎない” このことが解ってから、TDDをするのが一気に苦痛ではなくなり、むしろ楽しくなった。 TDDでなくても、コーディングをするとき、temporaryなテストコードを書いたり、目視でのチェックはしたりするものだろう。たとえば、一時的に変数の値をハードコードして挙動を変えてみて、それを目視で確認したり、printデバッグとかもその一部だ。 つまり、このtemporaryなコードや目視している部分をpermanentにするのがTDDで書くテストコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: TDDを根づかせる:導入の問題と解決策
