タグ付けされた質問 「project-management」

ITプロフェッショナルは、ビジネスまたは組織のIT資産に信頼されているエキスパートです。私たちは信頼できる専門家として、IT以外のお客様が理解または認識していることが期待できるものを超えて責任を負っています。ですから、ITプロフェッショナルと彼の内部/外部の顧客との適切な関係は、使用人とマスターではなく、医師と患者の関係に近いと思います。私は正しいですか？ ここで考えるべき類推があります。患者は、彼の脚を切断する必要があると主張しています。彼の医者は反対しますが、患者は説得できません。医者は患者を満足させるためだけに脚を切断すべきですか？ 別のアナロジー。顧客は、土木技師が安全でない設計への架け橋を築くことを望んでいます。エンジニアが安全でないと説明しても、顧客は彼を信じていません。とにかくエンジニアは橋を架けるべきでしょうか？ 私はこれらの両方のアナロジーで正しい答えはノーだと思います。医療専門家とエンジニアリング専門家は、信頼できる立場にあるべきであり、患者/顧客の不承認に直面しても、彼ら自身の判断を行使すべきです。ITプロフェッショナルが決定を下す資格を持っているが、顧客がそうではない場合、同じことがITプロフェッショナルにも当てはまりませんか？

10 project-management  management  communication 

たぶん私は単純な人かもしれませんが、私が1週間にわたって目標としているタスクの壁を解読しようとすると、プロジェクトスケジュールを作成する人には、改善のためのトレーニングを受ける必要があると考えざるを得ません。基本的なプロジェクト管理。 たとえば、今日13のタスクが割り当てられ、最短の.13日（Microsoft Projectのデフォルトの時間メトリック）、および最長の.75日が割り当てられます。私は仕方がないのですが、これは10分未満の間隔での露骨なマイクロ管理スケジューリングプロジェクトだと思います。 管理の影響は、タスクのスリップ、ある時点で容量の2倍を超えるリソース割り当て、および実際の作業よりもタスクのクリアと次の作業の解明により多くの時間を費やしているタスクで明らかになっています。 プロジェクトマネージャーを説得して、より長い期間のタスクを作成し、全体像を確認するにはどうすればよいですか？

10 project-management 

少し前、私が働いている会社は開発プロジェクトを第三者に外部委託していた。彼らはソリューションの開発にアジャイル手法を採用しました。しかし、ドキュメントを求められたとき、彼らはそれがwikiに組み込まれたり、彼らのスプリントの一部として組み込まれたりして、それが必要であるとだけ言ったでしょう。 彼らは、プロジェクトチームの1人を除いて全員がプロジェクトの完了時に出発しました。プロジェクトのwikiサイトは、年間サブスクリプションが満期になると閉鎖されました。 彼らが去ったとき、彼らは彼らと一緒に開発されたものについての知識と理解のほとんどを取りました。 だから私は2つの主な質問があります。 これはアジャイルにとっては正常ですか、それとも書きたくないという言い訳ですか？ 開発要件、設計、主要な決定、およびコンテキストを記録するためのアジャイルプロジェクトの文書化に関する業界の基準は何ですか？

10 project-management  development-process  agile 

私は現在、かなり大きなWebアプリケーション（ASP.NET MVCスタック、約15万行以上のコード）の唯一の開発者/アーキテクトであり、開発の終わりが近づいています。そのため、プロジェクトを引き継ぐために何をする必要があるかについて考え始めており、将来プロジェクトを維持する必要がある人のために正しいことを確実にしたいと考えています。 プロジェクトを別の開発者またはメンテナンスの開発者チームに引き渡す準備をするときに知っておくべきことは何ですか？

10 project-management  development-process 

ソフトウェアプロジェクトに開発者を追加すると、利益が減少するポイントを説明する用語はありますか？ 高いレベルでは、プロジェクトが生産能力を発揮する開発者の数（プロジェクトの状態、追加された開発者の品質）だけがより複雑であることに気づきますが、これを繰り返しによる非技術的な管理に関連付ける方法。私は基本的に、ブルックの法則を除いて、「終末速度」のような強い精神的なイメージを引き起こす用語を探しています。

10 project-management  terminology  brookslaw 

私はシステムの所有者と私自身の両方が開発者であるシステムを書いています。現在、システムへの「要求」またはシステムの要件の唯一の情報源であり、機能に関連付けられたユーザーストーリーにそれを記録したいと考えています{1}。私の緊急の優先事項は、現在、管理可能なバックログを取得することです。ユーザーストーリーでの作業に慣れている技術仕様のレベルをキャプチャするにはどうすればよいですか。 {1}アジャイルプロジェクト管理サービスTargetProcessを評価しています。各ユーザーストーリーは親機能に関連付ける必要があります。システムは適切だと思われるので、この小さな制約は、回避するよりも私が作業したいものです。

10 project-management  agile  scrum 

無数のオープンソースプロジェクトに利用できる100万のファイルシステム構造があります。モジュール、言語ファイル、ドメイン、サードパーティライブラリ、移行、国際化、バックアップ、システムの他の部分へのsyslinkなどのものが、プロジェクトのファイルシステムを編成する多くのアプローチを生み出しています。 PHP開発者として、プロジェクト間で何らかの標準化が出現し始めているのではないかと思っています。PSR-0 、我々は最終的にファイルを命名し、ロードするための標準を持っている-しかし、それシステムやそれらがどのように正気の方法で処理することができますを構成するコンポーネントの残りの部分についての私の知識に何もありません。 私たちが扱っているのはMVCだけではありません。これらのすべてを正しく処理する大規模なプロジェクトの例にはどのようなものがありますか？

10 php  project-management  code-organization  file-structure 

新しいプロジェクトを開始しようとしています（ゲームですが、それは重要ではありません）。基本的な考えは私の頭の中にありますが、詳細のすべてではありません。 計画せずにプログラミングを始めたくはありませんが、ただやりたいという衝動に真剣に取り組んでいます。私が考えることができる新しい機能がそれを必要とするというだけの理由で、アプリ全体をリファクタリングすることを防ぐために前にいくつかの計画が欲しいです。一方で、今月はやる気を失ってしまうのではないかという不安もあり、数ヶ月（暇）の予定を立てたくない。 私が探しているのは、一方を他方を支配することなく両方を組み合わせる方法です。スクラムの方法でプロジェクトを実現する必要がありますか？ユーザーストーリーを作成してから実現する必要がありますか？機能駆動型で作業する必要がありますか？（私はスクラムと古典的な「コードへの仕様」の方法でいくらかの経験があります。） 更新：「クリックダミー」から始めて、後で機能を実装するのはどうですか？

10 project-management  agile 

ソフトウェア開発者としての最初の仕事で、私のチームはアジャイル/スクラムを使用してプロジェクトのワークフローを管理しましたが、それはかなりうまくいきました。経験豊富なメンターが私を正しい方向に導いてくれました-私は彼らに大きな感謝の気持ちを抱いています。私はそこで数年間働いた後、数か月前に新しい機会に移りました。 現在の仕事に早送りします。私は大学の教授のもとで働いています。私は大学にいるので、ほとんどすべてのプログラマーは学生です（彼らは安価で豊富です！）私の上司には管理経験がありますが、ソフトウェア開発の経験はなく、ソフトウェアチームは常に上司の頭にいるわけではありません。 。これらの条件は、いくつかの非常に質の悪いソフトウェアを作成するための完璧な環境を作り出しました。ソフトウェアプロジェクトは少し悪党であるように見え、設計することを考えておらず、いくつかの本当に恐ろしい慣行を採用しています。物事が良くなることを知っています。 開発プロセスを実装して、全員を軌道に乗せ、コードの品質を向上させ、より安定したソフトウェアを展開したいと考えています。どこから始めればいいのかわからない。 私は、言うまでもなく、「スクラムを使用する」、「かんばんボードを設定する」、「アジャイルを見てください」などの回答を探していません。（アイデアは高く評価されますが）。具体的には、この作業環境の開発プロセスを実装する方法について洞察を得たいと思っています。従業員は通常、次に進む前の1〜2年の間に働き、一般的に経験が浅く、全員を含む毎日のスタンドアップミーティングをスケジュールすることはほとんど不可能です。 そのような職場では、品質、効率、コミュニケーションをどのようにして育てるのでしょうか。 更新：いくつかの回答とコメントを読んだ後、私はいくつかの追加の背景を提供すると思いました。 私は自分自身のソフトウェア開発の芸術のマスターを検討していないだろうが、私は思います、私はそれを見たときに悪いプログラミングを認識するのに十分な経験を積みました。開発者が1〜2分で作業した後、開発者が才能があるかどうかを判断できます。私は問題をスマートに解決する方法を見つける自分の能力に満足していますが、本当に経験が足りない領域は、他の開発者が関与するプロジェクト管理です（そのため、私はここですべての素晴らしい人々に助言）。 私は、このオフィスに来るすべての学生が完全な弱者であるように聞こえました。ここには悪い卵がいくつかありましたが、私が会った学生の大多数は知的で、学びたいと思っており、仕事に熱心です。一部はまだ始まったばかりで、何を知らないのか分からない。そして、それは大丈夫です。私がプログラミングを始めたとき、私は元気がありませんでした！

9 agile  project-management  development-process  management 

当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定の種類のプロジェクトに特定の種類のソフトウェア（またはハードウェア）を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。Jiraプロジェクトを使用して特定のプロジェクトの問題をホストし、Jiraボードを使用して異なるチームのスプリントを実行します。 私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。 したがって、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング（週に1回）でレビュー、優先順位付け、推定され、将来のスプリントでは（プロジェクト固有の問題と共に）優先順位に従って取り組みます。 優先順位付けは問題を並べ替えることで行われ、並べ替えられた問題にsortedラベルを付けます（並べ替えられていない問題を検索できるようにするため）。次に、コアコンポーネントごとに1つの課題をバックログの先頭に手動で配置して、それらを最初に処理します。一部のチームがそのような問題をスプリントに入れる場合、代わりに別のアイテムをバックログの上部に手動でドラッグする必要があります。 これはかなりエラーが発生しやすいです。基本的に、私たちが持っているのは、「未解決」と「進行中」の間の「ソート済み」と「推定済み」の追加の問題ステータスです。これをsortedラベルとボード内での位置で反映することは、かなり面倒でエラーが発生しやすくなります。（たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、数週間前の広範なディスカッションでチームが決定した可能性がある問題の順序を静かにスクランブルします。） これを実装するより良い方法は何でしょうか？

9 agile  project-management  user-story  requirements-management  jira 

私は最近、ソフトウェア開発のアジャイルプラクティスに興味を持ちました。それ以来、多くの記事で、これらのプラクティスにより全体的なコストを削減できることを指摘しました。 その背後にあるロジックは通常、次のようになります。要件が変更された場合、この変更を次のスプリントバックログに反映できます。これにより、新機能の設計と実装が時間的に近いため、コストの削減につながります。後で要件を変更する必要があるほど、その要件を満たすためにコストがかかるという有名なルールに従って、コストは下がります。 しかし、中規模から大規模のソフトウェアプロジェクトは複雑です。要件が突然変更されても、その要件を満たすためにシステムの他の部分に触れる必要がないわけではありません。多くの場合、アーキテクチャを大幅に変更する必要があります。つまり、古いアーキテクチャに依存していたすべての機能を再実装する必要があります。したがって、コスト削減の全体的な要点はここではなくなります。もちろん、新しい要件がシステムの新しい独立した部分を必要とする場合、それは問題ではなく、古いアーキテクチャが成長するだけなので、再考して再実装する必要はありません。 そしてその逆。ウォーターフォールを使用していて、新しい要件を導入する必要があることに突然気付いた場合は、デザインを変更できます。既存のアーキテクチャを変更する必要がある場合は、再設計します。それが本当にそれを台無しにせず、システムの新しい部分を導入するだけなら、あなたは行ってすべての仕事をします、ここでは問題ありません。 そうは言っても、アジャイル開発の唯一の利点は、スプリント間で機能を完全にビルドできることだけであるように思えます。多くの人やプロジェクトにとって、これは重要ではありません。さらに、アジャイルはソフトウェアアーキテクチャ全体で悪い結果を招くように見えます。機能が相互に平手打ちされるため、アジャイルチームは機能が機能するかどうかではなく機能が機能することのみを気にします。これは、システムが時間とともに複雑になると、アジャイル開発の実践により、製品アーキテクチャ全体の混乱が実際に増大し、最終的にコストが高くなります。なぜなら、ウォーターフォールにより、アーキテクチャを完成させることができるからです。あなたが何かを解放する前に。 明らかに、多くの人が実稼働環境でアジャイルを使用しているので、どこかで間違っているに違いありません。

9 project-management  architecture  agile 

現在、私の職場では、さまざまなWebアプリケーションのすべての機能とバグを管理するためにFogBugzを使用しています。 Webアプリケーションの1つに新しい機能を追加すると、新しいケースが作成されます。たとえば、「CSVアップロードフォームの作成」です。 次に、私が費やした時間を記録してケースに取り組みます。このケースが完了したら、それを解決すると、ケースオープナー（通常はプロジェクトマネージャー）に割り当てられ、ケースマネージャーがケースを閉じます。 この機能にバグがある場合、プロジェクトマネージャーがケースを再度開き、バグの箇条書きリストを付けてケースを割り当てます。 私の意見では、これらの箇条書きのバグは個別のバグケースとして開く必要があると思います。そうすることで、追跡が容易になり、元の機能ケースのメモが散らからないようになります。 私のマネージャーは、機能に費やされた合計時間をすべて1つの場合に計算する方が簡単であると述べることに同意しません。 さらに、機能の参照番号が1つしかないため、クライアントの混乱が少ないと考えています。ただし、これは元のケースの完了後なので、バグは別のケースとして処理する必要があることを強調します。 バグは新しいケースとして再開する必要があると私は言っていますか？そして、これを管理するそれぞれの方法の長所/短所は何ですか？

9 project-management  development-process  issue-tracking 

約一年半前、私はアジャイル開発をしていると主張する職場に入りました。私が学んだことは、この場所はいくつかのアジャイルプラクティス（毎日のスタンドアップ、スプリントの計画、スプリントのレビューなど）を採用しているが、原則（ジャストインタイム/十分に良いメンタリティ、失敗を早期に公開する、リッチなコミュニケーション）を採用していないことです。 私は今、チームをより機敏にすることを任されており、開発者とビジネスチームから完全に賛同できることを確信しています。パイロットプログラムとして、15か月の要件収集を完了し、110ページの分析と設計ドキュメント（「石で書かれた」と見なされる）があり、最後にアクセスできないプロジェクトが与えられました。ユーザー（実際に製品を使用しないユーザーのマネージャーで構成される委員会のみ）。 私は小さく始めて、最初の5つのスプリントに期待される成果物のリスト（将来のスプリントは未定義のまま）、最初のスプリントの目標のリストを与え、最初のスプリントの目標を満たすのに十分なユーザーストーリーを取得するためにA＆Dドキュメントを分析しました。 それ以来、彼らはなぜすべてのスプリントのすべての要件がないのか、なぜ私が3番目のスプリント（もっと重要だと考えているが最初のスプリントの成果物に基づいている）の作業に着手していないのかと尋ねてきました。 2つのスプリント）そして、私のITチーム全体が忙しい作業または私たちとは無関係であると考えるさらに多くのドキュメントを求めています（ユーザーマニュアルを前に書く、すべてのスプリントのすべてのデータフィールドを前にドキュメント化するなど） 「前払い」作業）。 これは私にとって新しいプロジェクトマネージャーとしてはかなり大雑把でしたが、ストーリー管理のスクラムバン、ペアプログラミング、顧客に受け入れテストを（要件ドキュメントの一部として）提供してくれるなど、効果的に実装した改善点があります。 。 だから私の質問は： 抵抗力のあるビジネスに変更をより効果的に導入するにはどうすればよいですか？ ビジネスにアジャイルの利点を示すためにIT側に導入できる他のプラクティスはありますか？ 文書化の負担は私たちを苦しめています-ビジネスはそれをリスクとしてではなくリスク管理戦略としてまだ見ています。文書化の懸念と要求を緩和するために何ができるか（具体的には、文書化の量とそのすべてに対する事前のニーズ）。 私たちは私たちのビジネスとは別の建物にあり、約3ブロック離れています。彼らは、プロジェクトに参加している人に、同じ場所に他のプロジェクトに取り組むことはできません。建物。" 彼らは私たちがいつもそこに行って質問をまとめることを期待しています。そうすればすべてを一度に尋ねることができ、その人の時間を「絶え間ない中断」で無駄にしないでください。彼らからより豊かなコミュニケーションを得るために私たちは何ができるでしょうか？ 追加のアドバイスもいただければ幸いです。 ありがとう！

9 project-management  agile  waterfall 

現在の職場ではかなりストレスの多い状況（私の意見では）を扱っています。 私たちは新しいプロジェクトの開発を開始し、いくつかの要件を取得して実装し、「ビジネスアドバイザー」と呼ばれる人（ビジネス要件を知っているがプログラムを使用しない人）に見せます。その人は顧客の視点からアプリケーションを評価し、それをテストすることになっています。 ここに「プロセス」がどのように見えるか： ビジネスアドバイザーは、Windowsメッセンジャーで1〜2時間、上司と夕方話し合います 翌日、その会話のコピーをメールで受け取ります。私はそこからタスクを選択し、報告されたバグをチェックすることになっています（これは多くの場合、バグではなく、テストが不十分で、過去の施設を忘れています）。 私は変更を実装し、実装が受け入れられ、1〜2週間で、彼らが望んでいないことが判明しました（5分間ソフトウェアを見た可能性のあるクライアントと話し、変更を提案しました）-新しい変更を行う必要があります 誤解しないでください。要件が変わる場合があることを理解しています。気が動転するのは、職場で変更が発生する頻度と、「管理」がいかに簡単かによって、新しい要件が与えられたり、既存の機能に根本的な変更が加えられたりすることです。 同時に厳しい締め切りに取り組んでおり、ソフトウェアを進めるのではなく、サークルを運営しているという印象を受けます。 この状況への対処方法を教えてください。これは通常の状況であり、私はそれについて過敏になっていますか？

9 project-management  software 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 自分が最上級の開発者であり、チームの他のほとんどが数年後輩である新しいチームでどのように自分自身を扱いますか。チームの前の仕事は、あなたを含め、他の誰もがこれまでのキャリアで成し遂げたことはありません。 経営陣はチーム全体の生産性の向上を要求し、上級開発者として責任があります。 このような状況で切り札を出すためのヒントはありますか？明らかに、チーム全体が学ぶ時間を必要とし、チームの新しいことを忘れないようにしましょう。ただし、期限も前倒しです...

9 project-management  productivity  product-management