全員真面目で有能でいい人ばかりが毎日毎晩全力で仕事をしているのに、何ヶ月経ってもものがさっぱりでき上がらない どういう理屈なんだあれ
デスマーチの恐ろしさはヤバい
全員真面目で有能でいい人ばかりが毎日毎晩全力で仕事をしているのに、何ヶ月経ってもものがさっぱりでき上がらない どういう理屈なんだあれ
ProjectLibre
DOWNLOADED OVER 6,800,000 In 193 COUNTRIES on all 7 CONTINENTS
RedmineのBacklogsプラグインを使ってみた - Natural Software
最近、RedmineのBacklogsプラグインが流行ってるので使ってみた。 正直なところ、前から試していたけど、インストールが成功せず、動いているところを見たことが無かった。 今回は、こくぼさんに教えてもらいながら、動かすところまでできたので、画面を交えながらどんなものか見てみる。 Redmine Backlogs :: Home Redmine Backlogsセットアップ - こくぼ＠Everything is the experience. BacklogsプラグインをMac上のRedmineにインストール | 世界はどこまでもシンプルである 環境 Windows 7 32bit Bitnami::Redmine 機能 Backlogsプラグインの機能は、今わかってる範囲ではこんな感じ プロダクトバックログの管理(親チケット) タスクの管理(子チケット) リリーススプリントの管理
JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経
最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ！ ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
数千人が利用する楽天Redmineの過去と未来 #47redmine
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
SIがアジャイルやってよくならない点 - @ledsun blog
SIでアジャイルをやるとハイブリッドアジャイルやWater Scrum Fallになります。しかし以下の4点は解決はしません。SIのビジネスモデルでアジャイルが無理なのではなく、「期間と機能を固定して受注する」と変えられない点です。 営業中は、システム担当者は動くシステムを見れない*1。営業マンは見たことないシステムを想像しながら見積もるという高度なヒアリング技術が必要なまま。 開発会社とシステム担当者間で落とす機能を合意しても、「偉い」ユーザーの一声で落とした機能が復活する。多層構造*2による意思決定の遅さは残ったまま。 予算の見積もりは超過方向にしかブレない*3。（予算）見積もりのバッファ問題は残ったまま。 チームメンバによってベロシティ（開発速度）が２〜３倍は変わる。しかし単価はそれほど（４０万〜８０万）変わらない。 アジャイルといっても現時点でのSIのビジネス面へのインパクトは「少
[Agile]見積もりポーカーやった | Ryuzee.com
まぁ別にいつもやってるんだけど（笑） 僕のところでのやり方は以下の通りだ。 事前準備 専用カードではなく、トランプを使う。なんせ100円だからイタズラ書きしたって大丈夫！ カードは、A、2、3、5、8、13、ジョーカー。 予めフィーチャーを抽出して、Excelに書いておく。 その他Excelには、ストーリーポイントと備考欄を用意しておく。 Excelはその場で皆が見えるようにしておく。 メンバー同士が円卓や小さいテーブルに集まるようにする。相手との距離感が多いのは良くない。 やり方 あとは普通にやるだけなんだけど。 最小単位の1ストーリーポイントになるようなフィーチャーを探して基準規模にする。 フィーチャーの上から順に、基準規模をベースにして、その何倍程度の規模かを、トランプを同時に出すことで見積もる。 この時、ゲーム感覚で「せーのドン」とか掛け声をかけると、見積もりが楽しくなるよ。 ト
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
ホウレンソウ？ いや、その前に何かないか。：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■ある万年炎上現場でのワンシーン 「おまえ、ホウレンソウって、意味わかってるか？」 チームリーダーらしき人が怒鳴っていた。そして、鬼のような形相で部下をなじる。 「なんでお前、こんな簡単なこともできないんだ？」 たまにこんな光景を見かけないだろうか。ホウレンソウとは、言わずとしれた「報告」「連絡」「相談」の頭をとって「ホウ・レン・ソウ」と言われている。 チームリーダーは部下にホウレンソウを説く。これは絶対守るべき約束だと。しかしその前に、私はチームリーダーに「GUNDAM」を説きたい。 ■人の上に立つなら、GUNDAMくらい知っておくべし では、GUNDAMとは何だろうか。 Gorioshi （ゴリ押し） Uso (嘘) Najiru （なじる） Donaru （怒
「大丈夫」という部下の報告を信じてはいけない理由
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 「あのメンバー、仕事の進捗（しんちょく）は大丈夫かな？」 PM（プロジェクトマネージャ）なら、誰もが気になるところです。 「予定の期日に間に合います！」というメンバーの力強い返事を信じて任せていたら、完了予定日になって「実はまだできていませんでした」という相談が来て、結局対応に追われるはめになる……そんな経験はないでしょうか。 しかも、往々にしてこのようなことは1回だけでなく、何度も繰り返し起こります。一段落した時、メンバーに仕事が遅れた理由を聞いても、返ってくるのは「申し訳ありません」という平謝りと「今後はしません」という形ばかりの口約束だけ。 こんな調子じゃ、安心して仕事を任せられません。しかし、こんなふうになってしまうのには
デスマーチから生還する為に習慣付けるべき7つのポイント - ミッションたぶんPossible
先週末に2011年02月分の月報を提出したんですが、なんと勤務時間377.75h、徹夜回数8回と、オレ史上最も過酷な勤務状態だったことが判明しました。…ってまぁ集計する前から分かり切ったことではありましたが、こうやって数値化すると、あれは紛れもなくデスマーチだったんだなぁとしみじみ振り返っています。もう二度とやらねー。 さて、こんな状態で一番失いやすいのは心身の健康です。これだけ過酷な生活だとどうしても健康を害すことは防ぎきれないのですが、それでもある程度までは軽減できるだろうと確信を持って実行し続けたことがいくつかあります。その結果、オレはプロジェクト内でも1・2を争うハードな勤務形態を取りながら比較的他者より健康的にかつある程度健全な状態でデスマーチを戦い抜くこことが出来ました。 例えば、オレとその案件のチームリーダーは終盤ほぼ同じだけの稼働状況にあったのですが、最終的に健康度合いには
ヒッキーがリーダやってみた
すぺっく 仕事：ソフトウェア開発 性格：ヒッキー。 立場：特定派遣。メンバーは自社の人。人事権はない。 何の因果か、リーダーとかやるはめになったのでその経験を書いてみる。 技術的な話はない。 ■方針：プブチャラティの精神。 「任務は遂行する。部下も守る。両方やらなくちゃならないのが『幹部』のつらいところだな。覚悟はいいか？ 」 プブチャラティさん！俺やるよ！ …というわけで、尊敬するプブチャラティさんの姿勢をすべての行動の方針とした。 ■実際にやったこと。 ○作業日誌を送りつけた。 本日やった作業とともに顧客と自社の上層部に送りつけた。 われわれたはちゃんとやってますよという言い訳と、問題が発生した場合に上司に詰め腹を切ってもらうため。 ○朝会 毎朝、問題点と作業の状況を２，３分で確認した。 これで、問題点を抱え込まない状況を作り出すのと、一体感、連帯感的なものを演出した。 ○作業の目的を
高度情報処理技術者試験の論文集
Ｈ１８－問１ 情報システム開発におけるプロジェクト内の連帯意識の形成について プロジェクトマネージャには，プロジェクト目標の達成に向けてメンバが共通の意識をもち，例えば，ブロジェクト内で発生する問題の解決に全員参加の意識で取り組むように，プロジェクト内の連帯意識を形成し，維持・向上することが求められる。 通常，ブロジェクトは異なる部門や会社のメンバで構成されており，メンバの経験や参加意欲などは様々である。そのために，プロジェクト内で発生する問題についての理解や対応が異なり，メンパ間の対立やプロジェクト内の混乱に至ることもある。 このような事態を招かないためにも，プロジェケト内の連帯意識を形成し，維持・向上を図ることが重要である。 連帯意識を形成するためには，目標の共有，参画意識の向上，コミュニケーションの円滑化などの観点からの具体的な活動や仕組み作りが必要となる。 これらを通じて，自分の役
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルチームへ上手く移行するには