読者です 読者をやめる 読者になる 読者になる

何かを書き留める何か

数学や読んだ本について書く何かです。最近は社会人として生き残りの術を学ぶ日々です。

『Effective Debugging』Item 1: すべての課題は課題管理システムを通して取り扱う

Effective Debugging

紀伊國屋から注文していた Diomidis Spinellis『Effective Debugging』が届いた。

www.kinokuniya.co.jp

Effective Debugging

とりあえず「Chapter1. High-Level Strategies」序文と「Item1: Handle All Problems through an Issue-Tracking System」を訳した。 前回の反省を踏まえ、翻訳文を公開できないので自分のための翻訳である。

項目名の通り、課題管理システムを使いましょう、という話である。以前、上長に「課題管理表をExcelで作れ」と言われた。 「Excelですか」と10回ぐらい聞き返したがExcelで作れという指示であった。 結局、プロジェクトの流れと結びついていない課題管理表など使われることもなく上長も恐らくその存在を忘れていることであろう。

筆者はGitHubなどのコードレポジトリに含まれるもの、プロプライエタリなものとしてJIRA、オープンソースとしてBugzillaLaunchpadOTRSRedmineTrac を紹介しているがどのシステムを使うかは重要ではなくすべての課題を管理することが重要だと説く。 僕の経験に照らせば、Excelだろうがそれを全面に使うべきであったか。使ううちに限界を迎えて上記のどれかに落ち着くであろうが。 ちなみに、筆者は「課題管理システムにない課題への対処依頼は拒否しろ」とまで主張している。 以前、『カンバン仕事術』を読んだときにJIRAに登録されていない課題があってカンバンで可視化できた、みたいなストーリーがあった気がしたが、それとぶつかりそうな主張である(『カンバン仕事術』に課題管理システムとカンバンの両立方法について書いてあった気がする)。

課題には正確なタイトル、問題の再現方法、優先度と重要度、ステークホルダー、環境、そしてコメントなどで進捗状況をドキュメント化することが重要であると述べている。 理由は本文に書いてある通りであるが、ステークホルダーの説明で「Acmeからの提供、25万ドル規模の顧客」のようなタグをつける話があって生々しいと感じた。

前回はMarkdownで翻訳文を書いてPandocでreStructuredTextに変換してSphinxでHTMLに変換する、というreStructuredTextを新たに覚えたくないが故の七面倒な手順を踏んでいた(さすがにすぐにバッチファイルを書いた)が、今回はCommonMarkParserを使ってMarkdownを直接SphinxでHTMLに変換した。幾分手順がすっきりできて気分がよい。