タグ

スケジュールと開発に関するiwwのブックマーク (5)

  • Bus factor - Wikipedia

    The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus". It is also known as the bus problem, truck factor,[1] or bus/truck number.[citation needed] The concept is similar to the much older idea of key person risk, but considers the consequences of losing key technical exper

    Bus factor - Wikipedia
    iww
    iww 2015/08/23
    プロジェクトの要員が何人までバスに轢かれてもいいか をバスファクターと呼ぶらしい。 トラックナンバーの方で覚えていた。 lorry はタンクローリーだッ!のローリー
  • 開発チームがミーティングを嫌う理由 島国大和のド畜生

    賢明な皆さんはもうご存知でしょう。 そんなもん『仕事が増えるから』に決まってます。 例にゲーム開発を考えてみましょうか。(俺ゲーム屋だから) 世の中には会議をすると仕事が進む職種と仕事が増える職種があります。 開発は後者です。 ゲームを作っているとして、作りかけのゲームを挟んで会議したとします。 「この辺、操作性悪いよね」 「ここのUIが解り難いよね」 「ここバランス不味いよね」 偉い人は、こういうのを言うだけで、指示になります。 開発は1コ聞く度に仕事が増えます。 ぶっちゃけ現場でいじってる人間は突っ込まれる前に解っていて、今後のスケジュールで対応する予定だったりします。 しかし、『作りかけの物から完成品を想像する能力が足りない人』が、間違ったツッコミをしてソレがエライ人だったりすると、スケジュール的に無理をしてでも突っ込まないといけない(しかも入れることによって他に悪影響が出て余計にス

    iww
    iww 2013/06/19
    『「わっかりましたー!なんとかするようにガンバってみます!」  って言うだけ言って何もしなければいいんだヨ!言った人は覚えてナイヨ!』 正しい
  • [悪徳商法?支店]: エンジニアのモチベーションを根こそぎ奪う!たった7つの魔法の言葉

    1.テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 2.とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ

    iww
    iww 2013/04/09
    『日本で言う「アジャイル」は、「機能を追加しても、お金を追加で払いたくない」の言い換えに過ぎません。』
  • 締め切り駆動開発 - アンサイクロペディア

    締め切り駆動開発(しめきりくどうかいはつ, Deadline Driven Development,)は、モデル駆動開発 (MDD) やテスト駆動開発 (TDD) と並ぶ開発手法でありながら、両者よりもはるかに普及しているという特徴を持つ開発手法である。 概要[編集] 従来の開発手法では、開発途中に顧客からの仕様変更が出ることにより、手戻りが発生してスケジュールの余裕が失われ、品質低下や納期遅れにつながる問題が多発していた。 締め切り駆動開発では、スケジュールの問題に対してまったく逆のアプローチを取る。つまり、締め切りギリギリまでは開発に着手せず、顧客とのコミュニケーションに専念する。どんなに幸運でもこれ以上遅らせると炎上すると言うところまで来て、開発を開始する。この段階で次の顧客の仕事を始めたことにし、リソース消費の平均化を実現する。 締め切りをすでに過ぎているというプレッシャーを利用し

  • ゲームのデモ版の恩恵 - GAME NEVER SLEEPS

    E3とComic-Conが終わった。正直、ぎりぎりのスケジュールでプレイアブルのデモを用意しろって言われた時は、どうしようかと思った。しかしながら、いきなりえらそうに言えば、チームが成長してよかった。以下、俺の中間管理職的感想。 デモ前の状況を説明すると、いろんなパーツは入ってるけど、ゲームとして組み立てられていない状態で、チーム全体が若くてゲームをシップしたことない人が多い。俺の立場は一応デザイナだけど、チームのみんなをまとめるようなそんな感じ。実は俺もそれは初経験。 まず、俺自身が会社のいろんな都合から作らざるを得ないことを把握。これは駄々をこねてもしかたない。 次、各リードたちの説得。元々ぱつんぱつんのスケジュールを要求してる手前、デモ?ふざけんなの雰囲気まんまん。そんなところに俺が話したデモを作って幸せな理由は2つ。 その1、デモだけど、番に出てくるチュートリアルステージを丸々完

    iww
    iww 2010/10/21
    ゲームに限らず有効な考え方。
  • 1