Redmineチケットの担当者を固定にする手法はWBS駆動に凝り固まり過ぎ - プログラマの思索
RedmineとWBS駆動の相性の悪さについて、一つの意見を聞いたのでメモ。 【参考】 チケット駆動開発がWF型開発と相性が悪い理由: プログラマの思索 EVMとバーンダウンチャートは本質的に違う: プログラマの思索 TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索 イテレーションの考え方は締め処理と同じ: プログラマの思索 何故チケット駆動開発はタスクやイテレーションの変更に強いのか？: プログラマの思索 【1】とある人から、RedmineとWBS駆動の相性の悪さの意見を聞いた。 その人曰く。 Redmineでは、チケットの担当者がどんどん変わっていくように運用すべきなのに、WF型開発に凝り固まっている人は、チケットの担当者を固定して作業を管理しようとする。 だから、プロジェクト管理をチケット管理に
プロダクトマネジメントとプロジェクトマネジメントまたはプロダクトマーケティング - ikeike443のブログ
Inspiredという本があって、数年前からWeb上で翻訳が進んでいたのは知っていた。 しばらく忘れていて、先ほどたまたま確認したら既に2年前に翻訳が終わっていた。 http://inspiredjp.com/toc/ この本にはソフトウェア企業に務めている人であれば誰でも悩むようなことが書かれている。 プロダクトマネジメントとプロジェクトマネジメントの違い、プロダクトマネージャーの重要性と不在、特にプロダクトマーケティングの不在。アジャイル開発との関係。カスタム開発*1とパッケージソフトあるいはインターネットサービス開発の違い。アジャイル開発はもともとカスタム開発の問題解決のために考案されているためか、プロダクトマネジメントについての考慮が抜け落ちている件、などだ。 僕もまだ読んでいる最中なんだけど、この話題はとても興味があり、悩みも多い。 プロダクトマネジメントとプロジェクトマネジメン
技術知識だけではダメ--ITマネージャーに必要な10の管理スキル
技術的知識は、ITマネージャーに必要なスキルの一部に過ぎない。チームをサポートし、問題を予測して解決し、政治的な問題が生じた時にはそれを阻止する能力も不可欠だ。 ITプロフェッショナルは、管理スキルというものに反発する傾向がある。多くの人は管理スキルのことを、本当にする必要がある仕事をしないで、オフィスに座っていることだと見なしている。しかし管理スキルは、IT業務を成し遂げる上で重要な役割を果たしている。そうしたスキルは、自分の部下が仕事をできるようにすることと、仕事が先に進むようにビジネスユーザーとの政治的な問題を解決することの境界線上を常に歩いているITマネージャーにとって、絶対必要なものだ。 この記事では、すべてのITマネージャーが取るべき管理的なアクションを10項目紹介する。 1. 予算獲得のために果敢に戦う 事業価値が必要とされる、価値のあるプロジェクトが経営幹部に認められなけれ
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Redmineを全員で使ったらカオスになった話
タスク管理のツールとしてオープンソースのRedmineを使っていた。エンジニアだけで使っているうちは特に問題はなかった。エンジニアが10数名、全員でも40人規模の会社なので全員の作業を見える化したいよねという話が上がって全員でRedmineを使い始めることになった。そして何が起きたか。 プロジェクトが乱立した エンジニアであれば「プロジェクト」は単位は大体想像がつくと思う。しかしながらツール上ではその単位でプロジェクトは作られなかった。「正規のプロジェクト」の小規模な機能追加であっても「○○対応プロジェクト」と銘打たれツール上にプロジェクトが作成された。 「〜対応プロジェクト」「〜導入プロジェクト」「〜検討プロジェクト」「〜プロジェクト」・・・どんな言葉にもプロジェクトを付ければ”プロジェクト”にできるんだということは新鮮ではあったし、勉強にもなった。（そもそも”プロジェクト”って何だ？）
有能なウェブエンジニアをウェブディレクターにすることについて - 下林明正のブログ
ありがちな話なのでこのことについてふと考えることが多い。 最初に断っておくと特に結論はなく、ケースバイケースで考慮するべきというのが僕の考え。 それを踏まえて、先ずは良い点について考えてみる。 一番もっともらしい理由は、他のエンジニアが納得しやすいこと。一番戦闘力の高いエンジニアがエンジニア長になって皆を束ねていくという世界観。若く猛ったエンジニアも従ってくれるけど、石器時代っぽい。 次点として、システムの実装を把握しているのであまり滅茶苦茶なことにはなりづらく、安心して任せられるということ。 それ以外にありがちなものとしては、人的コストの圧縮も考えられる。人件費もそうだけど、頭数が1つ増えるだけでコミュニケーションパスは爆発的に増加していくのでコミュニケーションコストの削減にも繋がる。 次に悪い点について考えてみる。 これはまさにピーターの法則そのもので、組織の構造的な欠陥を示している。
人員を増やさず，より多くのソフトウェアを提供するには
ソフトウェア製品やサービスに対するニーズの増加に伴って，企業の開発能力を向上させるための方法が求められている。多くの企業が選択するのは，人員の追加によるスケールアップだ。このアプローチに対して一部の人々が疑問を持ち，人員を増やすことなく，より多くのソフトウェアを提供する方法を提案している。 Robert Martin氏は"Horders of Novices (初心者の集団)"というブログ記事で，少数の専門家チームによるソフトウェア開発を提案する。 これ以上，初心者を増やす必要があるのですか？ 大して能力のない連中をさらに投入したところで，優れたソフトウェアが早く開発できるものでしょうか？ ソフトウェアの問題は，本当にマンパワーだけの問題なのですか？ コーディングはレンガ工事と同じなのですか？ 左官工の数が多ければ多くのレンガを積めるように，コーダが多数いれば，コードも多く書けるでしょう
昔ながらの「片手間に書くJavaScript」の限界 - mizchi's blog
Javascriptを使うのをやめろ：Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの本職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー
Shibu's Diary: コードを書くときに心がけていること
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 コードを書き続けるためにやってること(by Voluntas) なんか流行っているので乗ってみます。 趣味コード 趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に
Amazonの現役マネージャーが語る新人・無経験のマネージャーが犯しがちなミスとは？
By Fernando de Sousa 企業の部署や部門の管理者を指す「マネージャー」は、さまざまな能力が求められる役職です。「マネージャーになって最初の数週間で犯してしまった3つ(以上/以下)のミスとは？」という質問がQ＆Aサイト「Quora」に投稿され、多くの現役マネージャーが返答しているほか、Amazonで現役のゼネラルマネージャーを務めるイアン・マカリスター氏も、自らの失敗談や、同僚の新人マネージャーとの勤務経験によって「新人・無経験のマネージャーが犯しがちなミス」を語っています。 Management: What are common mistakes that new or inexperienced managers make? - Quora http://www.quora.com/Management/What-are-common-mistakes-that-new
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
【デブサミ2014】13-A-5 レポート 「成功と失敗の狭間に横たわる2つのマネジメント」
『アジャイルサムライ』や『SCRUM BOOT CAMP』などの書籍が続々と世に出て読まれるようになり、また勉強会や各種イベントでも『スクラム』を題材にしたものが数多く開かれ、さまざまな議論が各地で積み重ねられてきました。関西大阪方面で、数多くの組織をスクラムマスターとして渡り歩いてきた中村氏もその一人。本稿は『マネジメント』の観点から、氏が取り組んできたことや直面した課題、工夫した点について事例を交えて講演したセッションのレポートです。 ビジネスを円滑に進めるための2つのマネジメント 中村氏は冒頭、『マネジメント』という言葉の定義について参加者に問い掛けました。『特定の誰かだけでなく、全員が何らかのマネジメントに関わることが大事』とした上で、2つの『マネジメント』について話し始めました。 1つは『期待マネジメント』。中村氏はこれについて『関係者が互いに持っている期待を明らかにし、適切に調
テストエンジニアのモチベーションを上げるにはどうすればいいか （後編） JaSST'14 Tokyo
ソフトウェアの開発に関わるエンジニアの中でも特殊なスキルを持つテストエンジニア。そのテストエンジニアをマネジメントする上で、彼らのモチベーションを上げるにはどうすればいいのでしょうか？ ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム 2014 東京」（JaSST'14 Tokyo）が、3月7日と8日の2日間、東洋大学 白山キャンパスで開催され、その基調講演に英国コンピュータ協会のStuart Reid（スチュアート・リード）氏が登壇しました。 （本記事は「テストエンジニアのモチベーションを上げるにはどうすればいいか （前編） JaSST'14 Tokyo」の続きです） ダニエル・ピンクのMotivation 3.0 2010年に発表されたダニエル・ピンクのMotivation 3.0では、モチベーションには3つの要素、やりがい、自主性、目的
テストエンジニアのモチベーションを上げるにはどうすればいいか （前編） JaSST'14 Tokyo
ソフトウェアの開発に関わるエンジニアの中でも特殊なスキルを持つテストエンジニア。そのテストエンジニアをマネジメントする上で、彼らのモチベーションを上げるにはどうすればいいのでしょうか？ ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム 2014 東京」（JaSST'14 Tokyo）が、3月7日と8日の2日間、東洋大学 白山キャンパスで開催され、その基調講演に英国コンピュータ協会のStuart Reid（スチュアート・リード）氏が登壇しました。 リード氏はソフトウェアテストの国際標準であるISO/IEC/IEEE29119シリーズを作成している会議体の議長を務め、また英国コンピュータ協会のソフトウェアテスト研究グループの長でもあります。ソフトウェアテストの分野で国際的にも著名なリード氏の講演を、ダイジェストで紹介します。 私がこの業界に入って
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
アジャイル開発とWF型開発をハイブリッドにしたマネジメント・デザインパターン - プログラマの思索
アジャイル開発を日本風にアレンジしたプロセスをマネジメント・デザインパターンとして説明した記事があったのでメモ。 【参考】 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 【1】WF型開発とアジャイル開発には、それぞれの特徴があり、適用の問題点がある。 WF型開発は、仕様変更に弱く、無駄なドキュメントが多い。 アジャイル開発は、変化に強く、スピード重視で開発できるが、従来のプロセス手法と発想を変えないといけないので、実現しづらい。 上記の記事によれば、各プロセスの特徴は、「WFが形式知の作成を行うことで、開発体制と開発工程を管理する手法」「(アジャイル開発は)フォーカス管理の最適化」。 つまり、WF型開発
生産性が高いエンジニアを評価するための２つの仕組み - レベルエンター山本大のブログ
仕事ができるプログラマって、できないプログラマに比べて「１０倍」も生産性が高い。とか言う話がありますよね。 僕も体感的に、本当にできるエンジニアは本当に生産性が５倍とか１０倍とか変わることを見てきました。 でも開発の現場では「残業しまくってる」ほうが、なんだか仕事してるように見えてしまう。 そんな中で久々にこの記事を目にしました（漫画なので1分ぐらいで読めます）。 ■「残業しないで帰るSEってやるきないんじゃない？」 http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=000800 2006年の記事ではありますが、こういう話って普遍的なので古くもありませんね・ 残業しないで定時に帰れるって評価するべきだし、残業をせず家庭を大事にする社風にしたい。 すごく生産性が高いっていうエンジニアを評価したい。 でも残業してるのって分かりやすいから評価さ
リーダーの仕事って何だろう？
こんにちは、松坂です。 「キャリアアップとは異なるキャリアの話」というコンセプトの下、前回は私が新卒のころの出来事を取り上げました。集団生活が苦手な大学生が、新卒で中堅の（わりとクラシックな風土の）システムインテグレーター（SIer）に入社し、独特の文化に馴染むために悩んだ話を書きました。会社はビジネスを目的とする組織なので、細かい規範や文化にはそれなりの背景があり、一つ一つ追いかけていけば、何となく筋道が分かる、ということでした。 今回はリーダーの話 今回はリーダーという職務について書きます。 リーダーという言葉は、会社によって使われる範囲が異なるのでなかなか難しいのですが、ここではプレーイングマネージャー的な意味で、現場サブリーダーからプロマネくらいまでを含みます。 私は子どものころ「協調性がありません」と通信簿に書かれていた口です。また、就職して1～2年はプログラマーとして小さなプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアの負債を扱う
