創造性を失わずにソフトウェアプロジェクトを効果的に管理するにはどうすればよいですか？
ソフトウェア開発は本質的に創造的なプロセスであると私は確信しています。これは、アーキテクチャからコーディングまで、すべてのレベルに当てはまると私は信じています。
どうしてそう思いますか？簡単に言えば、ソフトウェア開発者は既存のものをコピーするだけでなく、何か新しいものを作成することになっているからです。それはあなたのツールボックスをつかんで、仕事に適したツールを取り出すだけではありませんが、それは間違いなく優れたツールボックスを持つのに役立ちます。
一方、ソフトウェア開発をプロジェクト管理側から見る場合、開発プロジェクトを小さなタスクに分割し、各タスクに完了すると予想される特定の時間を割り当てることが望ましいです。 （ストーリーポイントの概念があることは知っていますが、実際にはそれほど大きな違いはないと思います。結局のところ、開発者は一定の時間の後に配信することが期待されています。）
プロジェクト管理の観点からは、これらのタスクは小さくなければならないことは明らかです。誰に尋ねるかにもよりますが、理想的なタスクは30分から1日の間です。
これが私の問題です。見積もりやストーリーポイントに基づくソフトな制限であっても、ジョブの制限時間に直面したときにクリエイティブになるのは難しいと思います。制限時間が短ければ短いほど悪くなります。多くの場合、各タスクの予定時間についてあまり考えずに、実行する必要があると思うことだけを実行すると、（創造的になる自由があるので）はるかに生産的だと感じます。一部のタスクは予想よりもはるかに長くかかる場合がありますが、品質は高くなり、全体として、プロジェクトはおそらく早く終了します。
これは私の個人的な認識ですか、それとも一般的な問題ですか？後者の場合、それについて何ができますか？
編集
最初のコメントと回答を読んだ後、私は（もう一度）創造性という用語はエンジニアリングで最も評判が悪いことを思い出しました。創造的であるということは、ビジネス価値を提供しない不必要なことをすることを意味するのではありません。新しいまたは非標準的な方法で問題を解決することです。
「管理」の意味が間違っています。ソフトウェア開発のコンテキストでは、プロジェクトの管理とは、プロジェクトが必要な機能、予算、時間どおりに、許容可能な品質で進行することを意味します。
プロジェクトを一口サイズのチャンクに分割することは、上記の目標を達成するための多くの方法の1つです。そして、あなたが想像するように、それはあなたにとって最適な方法ではないかもしれません。個人的には、そのアプローチは私を侮辱します。それは、開発者である私を無責任であり、マイクロ管理されない限り、プロジェクトを適切に進めることができないとして扱います。
開発者を本当に適切に管理したい場合は、開発者が何をしているのかを理解し、プロジェクトを成功させるために必要なことを（当然のことながら）実行する意欲と意欲を持つ責任ある熟練者として扱う必要があります。あなたの主な管理責任は、プロジェクトの目標を明確に伝え、日常の管理を開発者自身に任せることです。完了したタスクの数ではなく、ソフトウェアが目標にどれだけ一致しているかに基づいて、進捗状況を追跡する必要があります。
そして、開発者自身がプロジェクトを小さなタスクに分割し、それらのタスクを追跡することが自分たちの仕事にとって有益であると考える場合、彼らはまさにそれを行います。しかし、これは飼い葉桶としてのあなたの行動とは完全に無関係であるべきです。
あなたのソフトウェア開発をビジネスの文脈で考えることをお勧めします。ビジネスの目標は利益を上げることです。利益を上げるには、企業は品質レベルを維持しながら、できる限り早く生産する必要があります。
デザインとコードを深く理解していると、多くの場合、最も単純で簡単で最速の方法がビジネスに最適であることを忘れがちですが、常にそうであるとは限りません。場合によっては、機能を完成させるために多くの配慮と創造性が必要になります。
私の提案は、見積り時にこれをすべて考慮に入れることです。これがより多くの時間を費やすことで品質が劇的に向上するか、プロジェクトの残りの部分の俊敏性が向上する重要な機能である場合は、より高く見積もることができます。見積もった時間でまともな結果を生み出すことに一貫して苦労している場合は、より高い見積りを行ってください。品質のトレードオフをプロジェクトマネージャーに提案し、意見を聞きます。タスクに取り組む早い段階で、より多くの時間がより良い結果を生み出す可能性があると考えている場合は、プロジェクトマネージャーに相談して、より良い結果が見積もりスリップに値するかどうかについて意見を求めてください。このようにして、スケジュールと品質の責任をチームの他のメンバーと共有します。
完璧な世界では、何も見積もる必要はなく、美しくエレガントなソフトウェアを作成する時間は無制限ですが、ほとんどの場合そうではなく、ビジネスニーズを最優先する必要があることを受け入れる必要があります。
見積もりは締め切りではありません。
見積もりでは、そのようなタスクの平均所要時間を指定しますが、そのタスクの詳細により、予想よりも簡単または難しくなる場合があります。
見積もりを期限として扱う場合、多くの場合、期限が守られないか、見積もりに90パーセンタイルのようなものが埋め込まれます。これにより、残りの合計作業量を見積もるのに見積もりが役に立たなくなります（合計の平均が平均の合計であるという統計から思い出せますが、合計の90パーセンタイルは90パーセンタイルの合計よりも低くなります。実際、十分に多くの大きな数の強い法則のタスクは、合計の90％パーセンタイルが平均の合計に近づくことを意味します。そのため、見積もりを合計するには、保証ではなく平均が必要です）。
プロジェクト管理はprojectの管理に関係しており、プロジェクトの作業を適切に見積もることは、タスクを見積もるよりも重要です。そのため、優れたプロジェクトマネージャーは、タスクの完了時間にかなりのばらつきを許容する必要があります。ただし、数週間または数か月にわたって、平均は推定値に近づくはずです。
私の個人的な見解では、退屈なプロジェクトは一般的なソフトウェア管理ではなく、創造性を殺します。
興味深い問題（プロジェクト）は通常、最高の状態で実行し、これまでに学んだことを利用する必要があります。退屈なシンプルなベアボーンソリューションを考えている場合は、プロジェクトがその性質のものである可能性が高いです。
わずかなデザインの違いのみで同じWebページを4回以上作成し、法的な理由によりコードベースを再利用できないと言ったとします。あなたの創造性は、設定されたタイムスケジュールではなく、タスクの繰り返しによって妨げられる可能性がはるかに高くなります。
また、クライオスタシスで考えられるようなプロジェクトのメンテナンス作業も行っていますが、これもあまり魅力的ではありません。これはコードからほこりを取り、修正してすぐに実行するのアプローチに適合します。そうすることで、これらの製品を健康に育てることができなくなります。
あなたの見解は明らかに、あなたが働いた現実に対するあなた自身の認識に由来しますが、私が描写したように、それが真実であると私が思う場合があります。通常、管理者がソリューションに必要最小限の時間以上を費やすことの価値を認めていない場合、またはソリューションが事前に決定されている場合。これらの2つの点のうちの後者は、小さな段落に値します。
ソフトウェアの創造性の性質を論じている神話の人月のいくつかの節を思い出します。それは、実装が設計者が自由に設計できる限り、低い実装レベルで創造性が可能であることを強く示唆しました。基本的に、関数を特定の方法で作成するように指示すると、定義済みの入力と出力を使用して自分で最初から作成する場合とは対照的に、関係する創造性はあまりありません。
新しい技術、パターン、テクノロジーを研究する時間は、私が高く評価するものです。多くの場合、勤務時間中に自分の仕事に関係のない何かを研究しているのを見つけることができます。ここで重要なことは、それが長期的に多くの価値を提供することが証明されていることです。発見された脆弱性、設計パターン、もはやパフォーマンスのないコードへの最適化などによるセキュリティ修正について話している。ただし、バランスを保つことが重要です。明らかに、このようにすべての時間を使い切ることはできません。
ですから、創造性を阻害するものがあると思います。それらについて私たちは何ができますか？率直に言って、ほとんどのことはプロジェクトや管理に依存しているので、意見を強調して変更を望んだり、サービスを他の場所に持っていくことができます。
ただし、最も重要なことは、それが最善の場合に非創造的なソリューションを受け入れ、それを必要とする問題にエネルギーを費やすことです。
OPを読んで、私はここに2つの質問を見ます、
- 創造性：タスクと創造性の分離は見られません。開発チームは、タスクを完了して要件を満たす方法を設定する必要があります。これにより、開発リーダーは、要件を満たすこと、および企業のコーディング基準/ポリシーを満たすことの制限内で、開発者がソリューションで創造的になる自由を与えるタスクの目標とタイムラインを定義できます。
はい、プロジェクトマネージャーと利害関係者は、責任の一部である締め切りに向かってドライブします。しかし、開発リーダーが自分の仕事を終えていれば、創造性の余地があります。そして率直に言って、結局のところ、あなたができることをできる限り迅速に行う必要がある場合があります。開発者の世界の一部。
- タスク：プロジェクトの性質上、タスクには時間の見積もりが必要ですが、タスクが任意の制限（8時間など）で細かく分解されると、深刻な問題が発生することがありました。これにより、管理できなくなったり、報告できなくなったりするタスクのモンスターリストが作成される可能性があります。作業の論理単位を表すタスクを作成する方がよい。例えば、「新規顧客入力画面のコーディング」。開発の本質は、反復があり、より多くの時間を必要とするスティッキポイントがあることです。 「顧客入力画面の必須フィールドのコードを書き込む」、「単体テストの必須フィールド」のレベルにタスクを定義し、それらを順番にリンクしようとすると、コード-テスト-デバッグ-コードの修正-テストのため、非論理的です。 ....サイクル。プロジェクトマネージャーは、Aタスクの任意のモデルに準拠せずに、論理的な作業単位について考える必要があります。
これが私の問題です。見積もりやストーリーポイントに基づくソフトな制限であっても、ジョブの制限時間に直面したときにクリエイティブになるのは難しいと思います。
ある意味、私は実際にはその逆を見つけます。私の経験では、時間制限は クリエイティブな制約 になる可能性があり、各初期要件の有用性に疑問を投げかけます。時間が足りない場合は、回避策を開発し、問題に対処するための新しく、より安価で、よりスマートな方法を見つける必要もあります。
結局のところ、品質、拡張性、または時間の範囲を犠牲にしていたかもしれませんが、本当に創造性が低かったと言えるでしょうか。
言い換えれば、創造的であるということは、必然的に多くのことを作成することを意味しますか？
技術的な創造性について編集します：それは最後の瞬間に自分で完全に即興するものであってはなりません
私のチームでは、コードの設計における「創造性」の多くは、開発者がユーザーストーリーをまとめてタスクに分解し、それらを推定しているときに発生します。この時点で、重要な詳細設計に関する技術的なディスカッションを行い、ホワイトボードのブレーンストーミングとスキーマの描画を行います。アイデアは、ランダムにタスクの見積もりを思い付かないということです。それは誰もが広く考えて合意したものです。
創造性のもう1つの大きな部分は、spikes、つまり時間制限のある技術調査および探索タスクで発生します。ここでも、時間の創造的な制約が重要な役割を果たします。それはあなたにいくつかの実用的な解決策を考え出すことに集中することを強制し、分析麻痺を軽減します。
これにより、1人の開発者がタスクを実行するときに必要とするクリエイティブの自由度が絞り込まれます。もちろん、彼らは名前を付けたいように名前を付けたり、適切と思われるようにユニットテストを設計したりするなどの自由がありますが、全体像は以前にまとめて設定されているはずです。
時間的な制約が気になる場合は、通常、プロジェクトマネージャーに全体的な状況を次のように説明します。
私はいつもできる限り速く作業しますが、速くはありません。速すぎると、追加のミスやバグが発生し、最初から注意深く作業するよりも修正に時間がかかります。つまり、私の最大の速度>> effective <<で作業することは、可能な限り最短の時間でジョブを実行することになります。そして、それがあなたのスケジュールにとって十分に速くないならば、それからスケジュールは非現実的であるか、あなたは仕事のために間違った人（私）を持っています。
（ご想像のとおり）私は常に、最後の文の方が「穏やかに」多いということに注意してください。私はここにあなたにアイデアを電報で送っています。それにもかかわらず、あなたはどういうわけかその考えを広める必要があります。
編集（「ビジネス価値」を強調した編集）
プロジェクトマネージャーの気まぐれさではなく、「物理的/社会的現実」によって厳しいスケジュールが決定される場合があります。そして、そのような場合、「創造性」とは、長い仕事を短くする方法を見つけることを意味します。以下は、私自身の経験からの2つの例です（コードやドキュメントのサンプルを含む詳細については、私の履歴書、プロフィールのホームページのURLを参照してください）。
1986年に戻って（戻って）、私はその年の中間選挙のために彼らの "電子ディスプレイシステム"を開発するのを助けるためにリードプログラマーとしてCBSと契約しました。締め切りは11月4日でした。
また、1989年にチェース銀行と契約を結び、国債（後に社債）の固定価格取引システムを開発しました。このスケジュールにはCBSよりも少し余裕がありましたが、システムにはSECのさまざまな規制変更も組み込まれており、スケジュールが満たされない場合、Chaseはいくつかの重大なペナルティを被る可能性があります。
最近のいくつかのプロジェクトは同様のスケジュールの厳格さを持っていました（しかし、私はy2kオンライン後にクライアントについては話しません）。いずれにせよ、これらすべての種類の状況には、仕事をスケジュールどおりに正しく行うための十分な創造性が必要です。あらゆる種類の「創造性」があり、ツールキットにもこれらの種類を含める必要があります。