タグ付けされた質問 「meetings」

私たちのスプリント計画会議は面白くないだけでなく、実に恐ろしいものです。 会議は退屈で退屈で、永遠にかかります（1日ですが、ずっと長く感じます）。 開発者はそれについて文句を言い、今後の計画を恐れます。 私たちのルーチンはかなり標準的です（優先順位によってスプリントバックログに挿入されるユーザーストーリー>>ストーリーはタスクに分解されます>>タスクは時間単位で見積もられます>>繰り返し）、何が間違っているのかわかりません。 どうすれば会議をもっと楽しくすることができますか？ ... 詳細情報のリクエストへの応答として、さらに詳細を示します。 バックグラウンドアイテムがスプリントキックオフの前に挿入および優先順位付けされないのはなぜですか？ ユーザーストーリーは確かに優先されます。それらをタスクに分解するまで、どれだけ時間がかかるかわかりません！ここの（優れた）回答から、タスクをまったく推定すべきではなく、ユーザーストーリーのみを推定すべきであることがわかります。タスク（ストーリーではなく）を見積もる理由は、ストーリーの見積もりがひどく間違っているためです。しかし、それはまったく異なる質問の主題だと思います。 開発者が文句を言うのはなぜですか？ 会議は長いです。 会議は単調です。ストーリーごと、タスクごと、苦労（はい、苦労）にかかる時間とその内容を推定します。 タスクを見積もると、ユーザーストーリーの推定が無意味に見えます。 会議が長ければ長いほど、部屋に集中できなくなります。集中力の低い同僚ほど、会議に時間がかかります。再帰的なヘイトスパイラルが発生します。人々を集中させるために会議を2日間に分割することを検討しましたが、開発者はそれを聞きませんでした。計画の1日で十分です。これで2つになります。 私たちの問題の一部は、（より正確な推定を得るために）非常に小さな詳細になることです。しかし、おおよその見積もりをするときは、大したことはありません！ 質問を要約するには： 私たちは何を間違っていますか？ 一般的に会議をより楽しくするために、他にどのような方法がありますか？

51 agile  scrum  sprint  meetings  process-improvement 

毎日のスクラムを保持することには、次のような利点があります。 チームは互いに調整されます 誰がどの程度のタスクを実行したかを知っています バーンダウンチャートはますます完全になります タスクボードが更新されました それほど長くは続かない、15分は誰も殺さない しかし、最近（6か月間のスクラムの実装と使用後）、開発者は毎日のスクラムがあまり好きではなくなったように感じます。人々は十分な説明をせずにタスクボードを更新するだけで、退屈しているようです。何らかの理由で、私たちはそれを保持しないとき、彼らは一種の特別な幸せになることがわかります。 私はこれで何が間違っているのか分からない。チームにとって「デイリースクラム」が持つ不利な点について、どこかで言及された理由はありますか？開発者が毎日のスクラムに飽きた理由は何でしょうか？

40 project-management  scrum  meetings 

毎日のスタンドアップミーティングはどれほど価値があると思いますか（またはそうでないと思いますか）？ あなたがそれに慣れていない場合、これはスクラムの支持者の一部である毎日の会議を指します（および他のいくつかのアジャイル方法論）。アイデアは、15分のタイムボックスで毎日会議を開催し、全員が立ち向かわなければならないということです（人々がそのポイントになるように促すため）。 会議では、部屋を歩き回って各自が次のように言います。-昨日あなたがしたこと-本日あなたがすることを計画していること-進行の妨げや障害 この実践には価値があると思いますか？誰かがそれをした場所で働いたことがありますか、あなたはどう思いましたか？

40 agile  scrum  meetings  development-methodologies 

私の上司は現在、いくつかの開発標準をチームに適用しようとしているので、昨日、彼女が育てるまでほとんど順調だった標準について議論する会議がありました。 すべてのDBテーブルには、トリガーによって更新されるCreatedDateおよびLastUpdatedDate列があります。 この時点で、私たちのチームは意見の分裂に苦しみました。私たちの半分は、すべてのテーブルでこれを行うと、ほとんど利益のない大量の仕事だと思います（固定予算プロジェクトに取り組んでいるので、費用は会社の利益から得られます）。後半は、プロジェクトの支援に役立つと考えています。 私は元キャンプにしっかりといます。外部のケースによっては追加の列がサポート性を向上させることはありますが、私の意見では、最初に列を追加するために必要な作業量とメンテナンスにより、より多くの時間を費やすことになります単体テストや負荷テストなどの重要なこと。また、これらの余分な列によってORMを使用するのが難しくなることはかなり確信しています-私たちは主にC＃とOracleを使用していることに注意してください。 したがって、私の質問は2つあります。 私は正しいキャンプにいますか？私は世界的に有名なデータベーススキルを持っているとは主張していません。そのため、これは副作用がなく、簡単に追加できるものです。 標準に関する会議がスラグマッチに移行する状況にどのように対処しますか？この基準が長期的には私たちを助けてくれないということを、どうすれば本当に売れますか？

38 database  standards  meetings 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 チームメンバーが最初に彼にではなく、スクラムマスターに割り当てられている責任をとろうとする状況で、あなたは何をしますか？

22 scrum  collaboration  meetings 

プロジェクトに最近参加したプロのスクラムマスターコンサルタント[*]がいます。残念ながら、私たちは彼女の名前を知りません（彼女は私たちに自己紹介したことはありません、彼女は1日で来て、「私たちは毎日立ち上がっている」と言いました）、そして彼女は椅子a毎日のスタンドアップミーティング-私は冗談で彼女にミーティングで毎日フィードバックをするように頼んだとき、彼女は非常にf辱され、「参加せずに促進する」ことがスクラムマスターの仕事だと言った。 これはかなり反アジャイルのようです（他のアジャイルプロジェクトに取り組んでおり、チームは自己指示されていました）。これは平等主義であるはずですが、スクラム方法論でどのように機能するかはわかりません。私は彼女が一日中あまり役に立たないと思います、そしてそれがこの問題に対する彼女の防御の理由です。 スクラムマスターは、スタンドアップミーティング中に「昨日、今日、障害」という演説に参加しますか、それとも、会議の議長を務める（「促進する」）役割がありますか？ [*]彼女は自分の仕事が何であるかを実際に知らされていませんでした。

21 agile  scrum  methodology  meetings 

10人の開発者からなる私たちのチームは毎週会合を開きます。会議はかなり退屈で、特に有用ではありません。良い会議をするためにどの形式/議題を利用していますか？ ピザを提供した会議室で毎週会います。形式は、部屋を一周し、作業中のさまざまなタスクのステータスをリストし、来週のタスクについて話し合います。マネージャーは、今後数か月および1年先の今後のプロジェクトと優先事項の概要を提供します。 更新 これらの会議の目標は多かれ少なかれです-一般的なチームの構築、誰もが取り組んでいるものの知識を共有し、変化する会社のイニシアチブを誰もが認識し続けることです。仕事の割り当てを正式に「配る」ことではありません（他の方法で行われます）。

19 management  communication  meetings  team-building  team 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 で別の質問、私は、開発者が好きではないかもしれない理由について尋ねた毎日スクラム。開発者と話をして、しばらくの間毎日のスクラムを開催しないことにしました（最初の試みで試してカスタマイズしたスクラムを提供するため）。これは、開発者と直接相談した結果です。 一方、開発者を毎日調整する機会を得たり、主要業績評価指標のように作業の進捗を監視したりして、早期にアクションを起こすなど、毎日のスクラムの良い部分を失いたくありません。 毎日のスクラムに代わるものとして、開発者に次の条件で毎日のレポートを提供するよう依頼することを考えています。 特定の形式に従う必要はありません。すべての形式が受け入れられます。 作業が完了していなくても、進捗状況を聞きたいと思っています。 各タスクに費やされた時間を言及する必要はありません。 開発の障害と調整の要件に言及する必要があります。 毎日のレポートに取りつかれている必要はありません。そんなに厳しくはありません。 これにより生産性が低下すると思いますか？日報の経験はありますか？マイクロ管理を行っていないことを確認できるように、何か提案がありますか？

18 productivity  management  scrum  meetings  reporting 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私はかつてウォーターフォールの方法論で働いていましたが、今ではアジャイルの方法論に従っているチームにいます。彼らはそれを間違っているようです。たとえば、1日25分以上続くスタンドアップがあり、これは非常に面倒です。さらに、私は他の何よりも自分の給料を経営陣に正当化しているように感じます。 このように感じるのは間違っていますか？これは通常、スタンドアップが行われている方法ですか？

13 agile  scrum  development-methodologies  meetings 

私はプロジェクトに取り組んでおり、定期的（通常は毎週）の非公式の会議を開いて、プロジェクトのステータスとGUIについて話し合っています。 私はそこにいる唯一の開発者です。他の4〜5人はIT以外の経歴を持っています。 この会議にはいつもより長い時間がかかりましたが、ある時点で、私の同僚の1人がプログラムのいくつかのフィールドと、それらがどのように満たされるかについて質問しました。私は答えて、私が気付いたディスカッションで、私のプロセスは完全に間違っていると思いました。 しかし、それについて事前に話し合ってエラーを見つけたので、かなり迅速に変更できます。 このことを考えながら、開発時間を節約することに関して、会議時間の間に要因があるかどうかを自問しました。 たとえば、会議時間を1分にすると、開発時間をX分節約できます。 もしそうなら、これは私たちの会議がどれくらいの頻度でどれくらいの長さであるべきかを定義するのに役立ちます。 （明確にするために：会議の長さを大まかに決定することさえできても、より良い会議をしたくありません。会議時間と開発時間の間に関係がある場合、私は主に興味があります！質問の理由：好奇心！ ）

10 estimation  meetings 

私は、毎日のスタンドアップでのスクラムルールは、チームは昨日何をしたか、今日何をしているか、そしてそれらを妨げるものについてのみ話すべきだと言っていることを知っています。他には何もありません。しかし問題は、開発者が1日を自分のタスクに関係のない作業に費やし、それについてスタンドアップで話し合うことです。彼らが昨日やったことです！ 私の経験では、ボード上のタスクについて話し、スタンドアップに焦点を合わせ、全員のタスクに焦点を合わせ続け、見積もりを確認してレコードを毎日追跡する方がより効果的であることがわかりました。 ディスカッションをボード上のタスクに限定することは有効ですか？

10 agile  scrum  meetings 

私は、約20人の技術者がいる会社の8人のプログラマーのチームのチームリーダーです。彼らはさまざまなプロジェクトに取り組んでいます。これらのプロジェクトには、私の管理下にない他のチームの人々も含まれます。私の組織は適切なアジャイル開発を行っておらず、変更に対してある程度抵抗力がありますが、私はチーム内でスタンドアップミーティングを毎日開催しており、全員が役に立っていて、誰もが関与しており、 10〜15分。また、私は毎週、チームメンバー全員と個別のキャッチアップを行い、さまざまな一般的なトピック（技術的および非技術的の両方）と、さまざまな臨時のトピックミーティングについて詳細に話し合っています。 しかし、私が苦労しているのは、毎週のチームミーティングです。それは蒸気を失いつつあり、私は人々を興味を保つことができませんでした。 2週間または1か月の会議にする必要がある場合でも、私はまだ長い会議を開催したいと思います。目的は、スタンドアップ会議では時間を要するために行うことができないさまざまなトピックについて話し合うことでした。私からの更新には、彼らが取り組んでいる現在のすべてのプロジェクトの概要（スケジュールどおり、さまざまな遅延など）、方向の変更、将来のプロジェクト、開発プロセスの変更などが含まれます。私からの講義、そして少なくとも2人は明らかに除外され、残りはせいぜい穏やかな関心を持っています。 私は彼らに彼らの週について話すようにさせることによって人々をより魅力的にさせようとしました、しかし8人の人々でそれは長い時間がかかります（そして一部の彼らの仕事はそれほど多くを越えないため）、残りのチームのほとんどはそうします彼らの同僚がより詳細に取り組んでいることを気にしないでください（彼らはスタンドアップ中に高レベルの概要を取得します）。 だから、これらのミーティングの間、少なくとも一部の人々は非常に退屈していて、私がこれらを保持し続けるのはほとんど恥ずかしいです。それは私たちの活気に満ちた朝のスタンドアップミーティングとは全く対照的です。 人々の関心と関心を維持するために私ができることについて何かアドバイスはありますか？そして、どうすれば私からの独り言ではなく、みんなに物事を提示したり、全員を巻き込んだディスカッションを始めたりすることができますか？

10 management  team-leader  meetings 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 8年前休業。 私が取り組んでいるプロジェクトによっては、社内の利害関係者またはクライアント企業の技術管理の両方との会議にさらに出席する必要がある場合があります。 これらの会議の過程で、いくつかの質問が必然的に発生します。 あなたには答えがありません。 あなたは何らかの理由で考えたことはありません。 あなたは無関係であるか、現在の会議の範囲から完全に外れていると見なします。 どちらの場合も、これらの質問にどのように答えますか？正直でありながら権威を持ち続けるためのヒントやトリックはありますか？

10 management  meetings 

私は約3人の他の人（開発者以外）と一緒にまともな小規模プロジェクトに取り組んでいるソロ開発者です。これらの他の人々は開発以外の方法でプロジェクトに関与しており、1人は私のマネージャーでもあります。誰もがその場限りの議論にもかなりオープンです。 私のマネージャーはちょうど夢のように見えるものを私に与えてくれました-私はどの会議構造がプロジェクトに最適かを決定することを任されました。これは、会議の過負荷や無意味な会議に対処するための素晴らしい方法のようです。 今のように、大きな力には大きな責任が伴います。もし私が最終的に多くの無駄な時間をもたらす何かを提案した場合、それは私のせいです。 会議をどのように構成するかを考えるのにこれほど白紙の状態はありませんでした。私の考えは： 毎日の目標を伝え、前日の内容を確認するために、15分以下（スタンドアップミーティングと同様）の毎日の「タッチベース/ステータス更新」ミーティング。または、ホワイトボードを手に取り、自分の机に置いてこの情報を伝えることもできたようです。 特定の決定を下すため、またはチームのいずれかが持っている質問に対処するために必要に応じて会議 ...毎週の「ステータス」プロジェクト会議の必要性はないと思います。また、2番目の箇条書きで正式にスケジュールされた多くの会議が必要になるかどうかもわかりません。 私の懸念は、これらの「開発者に焦点を当てた」（つまり私）が他の人との疎外を引き起こしたり、この構造がほとんどのプロジェクトが実行されるものとはかなり異なるため、プロジェクトに対するコントロールの喪失を感じたりする可能性があることです。 1人の開発者が選択する必要のあるプロジェクト会議の構造は何ですか？ コメントへの対応： 他に貢献している人は何ですか？彼らはこのプロジェクトの対象ユーザーですか？開発の非側面（ウェブサイトのテーマと画像、DBA、QAテストなど）に取り組んでいますか？他のレベルの管理/管理？ 彼らは最終的なユーザーの一部であり、全体的なワークフローに関心があります。また、フォーム/ドキュメントのいくつかの領域にも貢献しています（その形式は開発作業に影響しません）。 他の2人のメンバーからフィードバックを得ることができますか？一部のマネージャーは、定期的に会議をスケジュールする必要があります。そうしないと、会議をスケジュールに合わせることができません。 時間を稼ぐことは今後の問題ではないようです。

8 project-management  communication  solo-development  meetings