Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例 - プログラマの思索
Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。 チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。 【参考】 golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log Big Sky :: コマンドラインからredmineを扱える「godmine」作った。 【1】(引用開始) SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします. 面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....et
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
アーキテクチャ設計のアンチパターン集～44のアンチパターンに学ぶDBシステム - プログラマの思索
「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載！「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ） 【本】SQLをしっかり学習したい人におすすめミック本。 | ﾌﾟﾗﾌﾟﾗ式技術系 Access流! 【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな
組織はアーキテクチャに従う、アーキテクチャは組織に従う、どちらが正しいか？ - プログラマの思索
「フレームワークを使いこなすための50問」の一節にこんな問いがある。 「組織は戦略に従う、戦略は組織に従う、どちらが正しいのだろうか？」 「フレームワークを使いこなすための50問」は経営コンサルタントのためのフレームワークに関する本なので、上記の問いは、コンサルタントが顧客へ戦略を提示時の制約条件について説明している。 その回答は「両方とも正しい。でも日本企業では戦略は組織に従うのがほとんどだ」と。 組織変革を自由に行える立場の場合、経営戦略の自由度は高い。 経営コンサルタントの好きなように、あるべき理想像に従って提示できる。 例えば、IBMが90年代に、メインフレームがWindowsパソコンなどのBPRの台頭と共に販売不振に陥った時、ハードウェアからコンサルタントやサービス事業へ転換した。 その時、40万人の従業員のうち30万人を解雇し、20万人を入れ替えた。 ハードウェア事業にいる人が
同期・非同期処理に関するアーキテクチャ - プログラマの思索
同期・非同期処理に関するアーキテクチャで良い記事があったのでメモ。 【元ネタ】 ITシステムで見られるシーケンス データベースコンサルタントのノウハウちょい見せ ダメな設計は、シーケンスが階段状ではなく、一つのオブジェクトに全ての処理を任せる「責任が肥大化したオブジェクト」がある。 特に初心者が、設計を考えずにいきなりプログラムを書いたり、システムを作ってしまう場合によく見られる。 この設計では、スパゲティコードになりやすく、一つのプログラムが千行を超えて保守しにくかったり、スケールアップや性能要件で壁にぶつかる時が多いだろう。 Webシステムは基本は、上記記事の「三角形」シーケンスに相当する。 メッセージを階段の図のように渡して、処理の結果を受け取るイメージ。 オブジェクト指向の権限移譲では、この設計手法がよく使われる。 MVC2モデルと呼ばれるように、Webシステムはオブジェクト指向と
組織や管理職が技術革新のボトルネック - プログラマの思索
とあるBlogを読んでみて、組織や管理職が技術革新のボトルネックではないか、と思った。 ラフな感想。 【元ネタ】 継続インテグレーションは強みではなくなった：柴田 芳樹 (Yoshiki Shibata)：So-netブログ 継続インテグレーションは強みではなくなった（2）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ カンファレンスは、若い人ばかり？（2）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ (引用開始) 私自身が日頃から感じていて、Jenkinsユーザ・カンファレンスの参加者による質問を聞いて再認識したことは、JenkinsなどのCIツールの導入を阻害しているは、現場のエンジニアではなく、ソフトウェア開発組織の管理職でないかということです。つまり、管理職がCIツールの導入の検討を指示して、予算（工数、機材費）を認めてくれればスムーズ
アジャイル開発を推し進めると組織を動かす政治力が必要になってくる - プログラマの思索
最近、いろんな記事を読みながら、アジャイル開発を推し進めると、アジャイルだけでは解決できない問題がどうしても残り、その問題を解決するには政治力が必要になってくるような気がしてきた。 ラフなメモ書き。 【1】アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：ITmedia オルタナティブ・ブログ 多分、チケット駆動開発は右寄りのツール寄り。 プログラマ出身で、プログラムにこだわりがある人は右寄りだろう。 逆に、プログラミングから離れて、マネジメント職に就き始めれば、自然に左寄りになる。 プロジェクトリーダーにもなれば、メンバーに的確な指示を出してチームを回す役割を周囲から期待されている。 100人月規模のプロジェクトになれば、プロジェクトマネージャとして、複数人のプロジェクトリーダーに的確な報告と指示を出しながら、プロジェクト全体をコントロールする役割を期待されて
チケット駆動開発とJenkinsの連携 - プログラマの思索
Jenkinsは単なるCIツールではなく、高機能なCron以上のツールとして使えないか、思ったことをラフなメモ書き。 【元ネタ】 Subversion, Git, Redmine, Hudson ? 今考えている連携 ≫ tune web Jenkins Gerrit Trigger Plugin の使い方 | Aiming 開発者ブログ Jenkinsで1つのジョブで複数のGitリポジトリをビルドする方法 - Hirohiroの日記 JenkinsとGitとSpockで独り継続的インテグレーション - Naoki_Rinの学習 - 補助記憶領域 Redmineチケットにタスクを書いて、GitやMercurialへコミットしたとしよう。 その後、コードレビューしてOKなら、そのパッチをtrunkへマージして、即ビルドして製品を出力するようにしたい。 その時の仕掛けとして、パッチをtrunk
【公開】AgileJapan2012講演資料「チケット駆動開発の課題と展望」 #aj12 - プログラマの思索
本日のAgileJapanでは、多くの人がチケット駆動開発の講演を聞いて下さりありがとうございました。 また、スタッフの皆様、お疲れ様でした。 AgileJapan2012講演資料「チケット駆動開発の課題と展望」をCCアトリビューションライセンスで公開します。 昨年のAgileJapanは聴衆の一人に過ぎなかったのに、今年は講演者としてメイン会場の午後1番のセッションで発表することになり、とても光栄でした。 自分としては資料をもう少し練れたかなと反省していたのですが、平鍋さんや岡山から来て下さった人から、今日の発表は良かったよ、と言われて正直ホッとしてます。 パネルディスカッションで良い議論ができたと思うのは、チケット管理で朝会やふりかえりを組み合わせて運用するのは効果的なのか？という質問があった時です。 朝会やふりかえりはプロジェクトファシリテーションのプラクティスの一つであり、僕個人の
チケット駆動開発の適用範囲 - プログラマの思索
日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。 以下ラフなメモ書き。 【元ネタ】 「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL 補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索 [#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば ユーザの力を利用するアジャイル開発: プログラマの思索 チケット駆動開発の戦略: プログラマの思索 僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。 でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。 チケット駆動開発をWF型開発に適用する場合、「チケット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
