色々なものが絡み合って火をふくと思うのですが、強いてあげれば、
・顧客の仕様(文章も絵もあった)を正確に理解できず、こういう場合はどうするか、などといった確認を怠った。
ー>仕様を各メンバがなんとなくしかわかってない(全くわからないわけではない)。
・コーディング規約が破られる。他に、iTempなんてネーミングを付けてくれる人が出始める。
>仕様を各メンバがなんとなくしかわかってない(全くわからないわけではない)。
今 まさにこんな状態です。 可能な限り方向性を変えて行きたいと思います。(立場が弱くて…)
>・コーディング規約が破られる。他に、iTempなんてネーミングを付けてくれる人が出始める。
これは もう少し先ですが、注意します。
10人のプロジェクトの場合だと確かに危険ですね>全く文章にしない項目がある。
これが許されるのはXPがちゃんとワークする、かなりできるプログラマが4名程度のチームでかつ対象がWebアプリのように開発サイクルが速いものに限られるでしょう。つまり「拳と拳で語り合う(ソース読んでお互いに理解している)」状況だけです。
それに付随して、危険な予兆は例えば
これでお互いの意思の疎通ができなくなり、各人が思い込みで作業を進めることになるでしょう。
自分の、ではないんですが、ソース管理・用件管理・進捗管理が全くまともに行われていないプロジェクトを見たことがあります。どれが最新の正しいソースかもわからない状態でもう悲惨の一語でしたね。たとえ管理ツールを使っていてもモジュールなどを更新するときのルールを決めておかないといとも簡単にこういう状況に近いところまで落ちます。
なんか、当たり前のことなんですが、始める前にこういう決め事をちゃんとしておくかしておかないか、というのが大事かと思います。
ご回答ありがとうございます。
>10人のプロジェクトの場合だと確かに危険ですね>全く文章にしない項目がある。
やはりそうですか…
>忙しいんだからということでミーティング(会議体)が行われなくなる、…
今は逆に会議ばかりです。議題に関係なく10人全員が参加しており、関係のない人は時間を無駄にしていますが、それを口にすることができにくい状態です。
また、その会議は、ゴールもアジェンダも存在せず、何が決定したのかが曖昧になり、効率はよくありません。時間も平気で5,6時間続くことがあり、それが週に3回ほどあります。
>作業の記録が残らない
上記に述べたように、会議で決定した内容が残りません。(残ったとしても一部。また残しただけのものもある)
>なんか、当たり前のことなんですが、…
私としては理想のシステムを作ることは諦めました、理想の1割でもいいと思うことでストレス管理できることを学びました。
私のできる範囲で少しでも「当たり前」に持っていく努力はしているところです。
例えば議事録ドリブンを始めました。
「ゴール」って書くだけで、あんまりいい顔されないのが悲しいですが…
メンバー間の仲が悪いわけではありません。
逆に仲が悪くならないように、上の人(または声の大きな人)に遠慮しているという状態です(私や一部の人は提案はしますが、却下されるとそれ以上強く言わないという状態)。
でもデスマーチになって、笑いがなくなって、人と人が憎み合うようにならないか怖いです。
愚痴ばかりですみません。私ができる範囲で改善します。
1.私がチーム内で改善点を提案できないのは、経験が少ないため(上流工程や実装技術)、
なので、システム開発・プロジェクト管理を徹底的に学ぶ。これによって自信をつけて、冷静に改善策を提案する。(交渉力も学ぶ)
2.効率の良い方法を少しずつ取り入れる(会議の進め方など)
以上です。愚痴になりました。すみません。
経験年数が浅いので大きな事は言えませんが、自分の思うところを。
当然、工程にもよると思いますが、上流工程でいえば顧客との打合せにおいて、
下流工程では設計SEとプログラマにおいて、
業務や仕様の理解がお互いに進まないと、デスマーチになる恐れがあると思います。
この点において最も大事なところは、仕様や業務への理解を曖昧にしないことですね!
という意味では、プロジェクト内のコミュニケーションはとても重要です。
そこでつまづくと、デスマーチの可能性がかなり高まってしまうと思います……。
また、単純に「納期」までの時間も重要な要素だと思います。
あまりに短納期での開発のせいで、私はデスマーチに突入した経験があります。
適正なスケジュール引き、定期的なレビューからリスケジュールを繰り返すことで、
うまくプロジェクトマネジメントを行う必要があると思います。
大変だと思いますが……応援しています!
>この点において最も大事なところは、仕様や業務への理解を曖昧にしないことですね!
おっしゃるとおりだと思います。
>また、単純に「納期」までの時間も重要な要素だと思います。
納期まではまだ時間がありますが、着実に遅れてきています。
今なら、まだ間に合いますので何とかします。
詳細は、回答番号2に返信してありますので、もしよければご覧頂き、お気付きの点があればおっしゃって下さい。
デスマーチとは
予定の開発期間を過ぎても、まだまだ終わらないプロジェクトのこと。エドワード・ヨードンは、著書の中でデスマーチの定義として4つの項目を挙げています。
* 1.与えられた期間が、常識的な期間の半分以下である。
* 2.エンジニアが通常必要な半分以下である。
* 3.予算やその他のリソースが必要分に対して半分である。
* 4.機能や性能などの要求が倍以上である。
前兆ではありませんが、間違いなくデスマーチなのは
「納期遅れの挽回対策」として「ソフト開発者が増員される」場合です。
プロジェクト途中で人を増やすと、新しく来た人に説明の手がとられて逆に効率が下がります。上の人の顧客に対する言い訳に過ぎないのです。
デスマーチの予感としては、担当者の能力(経験)不足な場合がありますね。開発案件ではなく社内システムの開発でしたがデータベースの設計一つ見ても背筋がゾワゾワしました。正規化以前の話で案の定デスマってます。
デスマーチが発生するのは「納期は固定なのに仕様が決まらず」ずるずると開始が送れた場合に良く発生します。
>デスマーチとは
これを見ますと まだデスマーチではありませんね。
>「納期遅れの挽回対策」として「ソフト開発者が増員される」場合です。
これもまだありません。
これからどうなるかですね…
詳細は、回答番号2に返信してありますので、もしよければご覧頂き、お気付きの点があればおっしゃって下さい。
心配ですね。
ソフトウェアは目に見えないので、さまざまなステークホルダーに無理なスケジュール、予算を押し付けられても反論することが難しく、現場ではいやな雰囲気がただよい不安はつきないと思います。
デスマーチの始まりを語れるほど経験はありませんが...
・打ち合わせや会議が増える
・結局なにも決まらなかった打ち合わせや会議が増える
・スケジュールがない(不明確、あっても形だけ)
・スケジュールがあっても明確なマイルストンがない
私の貧弱な経験より下記を参照するのが良いと思います。
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
>・打ち合わせや会議が増える
>・結局なにも決まらなかった打ち合わせや会議が増える
>・スケジュールがない(不明確、あっても形だけ)
>・スケジュールがあっても明確なマイルストンがない
全部該当します。危険…
デスマーチ本は週末に必ず読みます
詳細は、回答番号2に返信してありますので、もしよければご覧頂き、お気付きの点があればおっしゃって下さい。