TDDを行った時にぶつかった7つの壁 - Qiita
はじめに 僕が初めてTDD(テスト駆動開発)に出会ったのは2004か2005年。（どっちか忘れた。） 永和システムマネージメントさんが主催しているオブジェクト倶楽部というイベントで初めて知った。 「こんな方法でプロジェクトを管理することができるんだ！」 とかなり感嘆した記憶がある。 そんなTDDを実際に現場に導入したり、導入している現場を見て感じた事。 結果的に僕がテストコードをほとんど書かなくなったことについての経緯を書いていこうと思う。 TDDを導入すれば品質が上がると盲目的に信じている人や、TDDの導入をしている(しようとしている)現場がTDDについて一歩踏み込んで考えてもらえればと思う。 ※全文を読んで頂ければわかると思いますが、僕はTDDを批判しているわけではありません。コストに見合わない事もあると言うことを伝えるために書いてます。 TDD(テスト駆動開発)とは 平たく言うとビジ
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
QiitaやKobitoの開発フローと，それを支えるサービス一覧 - Qiita Blog
こんにちは，yaottiです． 前回はQiitaやKobitoを作る開発チームの文化について書きましたが，今回は具体的にどういうツールを使いながら開発しているのか，また開発の雰囲気などを紹介します． QiitaやKobito開発で利用しているツール，サービス一覧 Trello: 開発以外のタスクや仮説の管理Pivotal Tracker: 開発ストーリー管理GitHub: ソースコードのホスティング，レビュー，ディスカッションCircle CI: CI環境Sentry: エラーの補足&通知New Relic: パフォーマンス改善用の測定Amazon Web Services: インフラ(EC2, RDS, ElastiCache)コミュニケーションSlack: チャットQiita Team (& Kobito): テキスト共有&ディスカッションその他Mixpanel: イベント計測Goog
gdeg.jp - gdeg リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
デキるプランナー不足 島国大和のド畜生
自分の観測範囲の話だが、最近のプランナーの能力低下が目に余る。これらは本人の責任ではない。 まず、プランナーの仕事というのは、明確に規定されていない。 ゲームを作る仕事があるとして、プログラマ、デザイナー等がそれぞれが自分の仕事分を対応する。残った部分全てがプランナーの仕事になる。曖昧にも程がある。 そういう大ざっぱに「専門分野以外全部」な仕事だが、雑用というわけではなく、自己の専門分野もあるし、他の専門分野との調整も出来ないといけない。 また近年のゲームの複雑化で、やるべき事がとても増えた。 ゲームの中、プランナーがやるべきことはとても広範囲だ。 だからプランナーの能力が高ければ、その他職種の能力を引き出すし、プランナーの能力が低ければ、その分だけ他の職域に迷惑をかけ、クオリティを落とす。完成しない場合もある。 これほど重要な仕事だが、他の職域が優秀ならばヘボでもゲームは完成するし、場合
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
レベルいくつの議論をしているの？ | タイム・コンサルタントの日誌から
わたしの働くエンジニアリング業界では、プロジェクトの構造や規模感について、ほぼ国際的な常識ないし合意事項がある。我々の業界で大規模プロジェクトといったら、予算総額1,000億円以上を通常、指す。そして大規模プロジェクトを構成する種々の単位作業（Activity）の総数は、大ざっぱに3～5万程度だ。もっとも最近はプラントの大型化が進み、規模感はややインフレ気味だが、上記の数字は一つの目安になる。 ところで、Activity数が3～5万と書いたが、これはプロジェクトを構成する最下位のActivity数である。プロジェクトを作業単位に階層的に分解して管理番号をつけ、予算や要員やスケジュールをコントロールしていく基準とする手法は、現代プロジェクトマネジメントの基本である（この作業の階層構造をＷＢＳ = Work Breakdown Structure と呼ぶことは、本サイトの読者諸兄ならばよくご存
多人数プロジェクトで学んだこと - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
Pivotal Tracker: はじめかた
Pivotal Trackerをプロジェクトで使うにあたっては、アジャイル開発手法の知識が多少はあると役にたちます。エクストリームプログラミング(XP)であれば、このXPの入門記事をはじめとして、数多くの良質な記事をオンラインで見つけることができます。 ダッシュボードPivotal Trackerにログインすると、まず最初に表示されるのは自分の ダッシュボード(Dashboard)です。このページには、あなたが参加している全てのプロジェクト、最近の活動、Pivotal Trackerからの重要なお知らせが表示されます。 プロジェクトに招待されていれば、プロジェクト一覧にそのプロジェクトが表示されます。プロジェクトのリンクをクリックすると、そのプロジェクトのストーリーを表示します。新しいプロジェクトの作成は簡単です。ダッシュボードで"Create Project"ボタンをクリックし、プロジェ
はじめる! Redmine
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ このスライドの改訂版を下記URLで公開しています。 ぜひ新しいものをご覧ください。 http://www.slideshare.net/g_maeda/redmine-2015-54346755 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Redmineとは何か / Redmineがないプロジェクトとないプロジェクトの比較 / Redmineの基本 ＜更新履歴＞ 2012/05/20 第14回 山陰ITpro勉強会(4/20)とETロボコン2012 中四国地区独自勉強会での発表資料を一部修正して掲載。 http://sitw.techtalk.jp/sitwinfo/info14 http://kokucheese.com/event/index/33103/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
楽しいゲーム開発管理
@tarosite