ITSと開発プロセスのマッピング - プログラマの思索
@yusuke_kokuboさんが分かりやすい記事を書かれていたのでメモ。 【元ネタ】 Issue Tracking Systemの利用パターン - こくぼ＠Everything is the experience. 【1】RedmineやTracのようなITSは高機能でとても柔軟なため、いろんな状況で使い道がある。 チケット駆動開発の発端はTracのチケット管理であり、テスト工程のタスク管理をToDoリスト代わりに使う発想から生まれた。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 更に僕は、Redmineにチケット駆動開発を適用したらアジャイル開発が自然に運用できた経験をした。 そして、IT業界に限らず、営業・製造業・製薬業・情報システム部門などの色んな立場の人達がタスク管理だけでなく課題管理や要件管理
bitbucketとTortoisehgは最強だ - プログラマの思索
@kaorun55さんのBlogのやり方で、bitbucketとTortoisehgを設定したら、bitbucketのMercurialリポジトリと連携できた。 ありがとうございます。 【元ネタ】 WindowsでTortoiseHg 2.xとbitbucketを使う - かおるんダイアリー BitBucket と TortoiseHg で快適分散型バージョン管理生活 - さよならストレス Gitユーザのための、Bitbucket+Mercurial経由でのデプロイ方法 ? blog.udzura.jp 渋日記: Bitbucket買収？そもそもそれ何？という人のためのBitbucket紹介 bitbucketの使い方メモ - 記憶は削除の方向で Windows での Mercurial/Bitbucket の使い方（クイックスタート） - Usagi Project ちょっとはまったのは
ReviewBoardでプレコミットレビュー - プログラマの思索
岡本さんがReviewBoardの素晴らしい記事を掲載されていたのでメモ。 【元ネタ】 Review Board | Take the pain out of code review Review Boardならコードレビューを効率良くできる！ (1/3) - ＠IT InfoQ: Review Board - コードレビューをオンラインで ReviewBoard 釣られて使ってみた | tsuyuki.makoto Rietveldでレビューしよう @ val it: α → α = fun 徒然さめざめ Redmine Hack! reviewboardとの連携 ReviewBoardのインストール方法: プログラマの思索 ReviewBoard 釣られて使ってみた | tsuyuki.makotoには下記のように説明されている。 (前略) Tracのような感じなのかと思っていたけれど
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
プロマネに必要な技術とは？ - プログラマの思索
以前読んでいた興味深い記事 ｢プロマネの鍵、貸します」 「プロマネに必要な三要素」を掘り出した。 この記事の内容がようやく腑に落ちるレベルまで辿り着いたので、自分の数少ない経験を交えながら、プロマネに必要とされる技術について考察してみる。 【１】経験から得たリスク感覚～リスク管理 管理職で働く人は、必ずリスク管理のスキルを持っている。必要条件といっていい。 リーダーと呼ばれる人は、チームメンバーを見て、お客さんを見て、スケジュールを見て、コストを見て、リスクを嗅ぎ取るのがうまい。 ＩＴ業界はリスク管理が甘いように思う。 どのプロジェクトでも、初めての技術、初めての業務をシステム化する時がすごく多い。 再利用できるライブラリやフレームワークがなく、いつも最初からスクラッチで作り始める。 同じ業界の業務経験があっても会社が違えば業務は大きく異なるのが普通だから、いつも最初から要件のヒアリングか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
