アジャイル手法を使用することで実際に週 40 時間の作業を達成できる (フルタイムの) プロジェクトに取り組んだことがありますか? もしそうなら、最も価値のあるアジャイルプラクティスは何ですか?
3397 次
8 に答える
8
はい、私は最初から SCRUM で実行されたプロジェクトで 40 時間 (実際には 37.5 時間かそこらです。私の契約ではそうです) しています。それは約 2 年前のことで、初めて SCRUM を実装しました。個人的に残業が一番少ない作品で、開発中のPCゲームでもあります。金曜日にオープン ベータ版をリリースする予定ですが、今はまだ「クランチ」モードではありません。
それ以来、スクラムとアジャイルについて多くのことを学びました。私の観点からの最も価値のある教訓は、ポッドのサイズは妥当でなければならないということです...最初は 12 ～ 20 人のメンバーを持つポッドから始めましたが、まったくうまくいきませんでした。最大 10 を超えることはできません。「不安定な」タスクや「あいまいな」タスクに同意するのは簡単すぎる. そのため、ポッドのサイズを小さくし、タスクを具体的にして、製品の所有者またはサインオフをタスクに取り組む人々と一緒に取得します。
また、隔週のタスク計画スケジュールでは、すべてのプロダクト オーナーに現在のスプリントのタスク リストと優先順位について同意してもらう必要があります。新しいタスク リクエストは、その計画会議の前に発行する必要があります。そうしないと、現在のスプリントでは無視されます。スプリント。これにより、ポッド間の通信を改善する必要がありました。
于 2008-11-04T18:31:23.367 に答える
2
それに喜んで同意するスクラムと管理。
フェアスプリント計画. 自分のスプリントを交渉するときは、上からタスクを引き継ぐのではなく、チームが達成できることを選択できます。スプリントへのコミットメントを固定することで (経営陣はスプリントの途中でそれを変更することはできません)、変化する人々の気まぐれから解放されます。
プロダクト オーナーと上級管理職が協力して維持する、適切に維持され、優先順位が付けられたバックログは非常に役立ちます。必要なときに、必要な機能と関連するコストについて腰を据えて考える必要があります。彼らはしばしば機能が今必要だと言いますが、彼らが望むものを得るために他の何かをあきらめなければならないことに気づいたとき、彼らの期待はより現実的になります.
タイムボクシング。大きな問題に直面している場合は、余分な時間を費やすのではなく、スプリントから機能を削除し始めます。
アジャイルとは一言で言えば、プロセスを管理するためのサポートが必要です。
私は賢明な管理について言及しましたか？
于 2008-11-04T18:28:54.820 に答える
2
週 40 時間でタスクを完了できない場合、いくつかの原因が考えられます。
チームが次のことを確信していなかったため、これはスクラム プロジェクトの初期のスプリントで発生する可能性があることがわかりました。
- 彼らがスプリントでできる仕事の量、そして彼らが噛むことができる以上に噛むかもしれない、そして
- 作業のブロックに付与するポイントの量を正確に見積もる能力、または
- 「ポイントに相当する」作業を実行するために必要な労力。
また、割り当てられた時間内に達成できることについて過度に楽観的である可能性もあります。
その後、スクラムの悪臭のいくつかに取り掛かります。具体的には次のとおりです。
- チームが独自のワークロードを所有することは許可されていません。
- 経営陣は、スプリントで何をすべきかについての決定を無効にします
これらのいずれかが含まれている場合、あなたは次のとおりです。
- 名前だけでスクラムを行う
- 「パドルなしでクリークを上る」
最初のリストの問題を修正する以外にできることはあまりありませんが、これには経験が必要です。
2 番目のリストの 2 つのポイントを修正するには、会社がスクラムのベスト プラクティスを採用するのではなく、どのように絞め殺しているかを大幅に再考する必要があります。
HTH
よろしく、
ロブ
于 2008-11-04T18:43:37.740 に答える
2
難しく聞こえるかもしれませんが、現実的に考えてみましょう。アジャイルやその他のソフトウェア プロセスの使用は、週 40 時間とは何の関係もありません。通常、週あたりの労働時間は雇用契約で規定されており、開発者は独自の裁量で無給の追加作業を行うことができます。
魔法の治癒力を、好みのソフトウェア プロセスに帰することはやめてください。リスク管理への異なるアプローチ、異なる計画範囲、またはより良い利害関係者の関与を提供できます。ただし、奴隷制がまだ合法である場合を除き、あなたが住んでいる場所では、労働日はドアから入ったときに始まり、家に帰るときに終わります。
雇用契約に違反しないようにすることは、開発者の管理と同じくらい開発者の責任です。賭け金は、使用される方法論に関係なく、受け取る報酬の額と、見返りに提供することに同意した誠実な労働時間の額によって制限されます。
于 2008-11-05T14:15:11.370 に答える
1
そうです。
私にとって、助けになった最も重要なこと（重要度順）：
- クロスファンクショナル チーム - プログラマー、テスター、テクニカル ライター、セールス/サービス担当者が同じチームにいて、お互いに毎日 (デイリー コール) 話しているのは素晴らしいことでした。
- 通常のビルドと継続的インテグレーション
- 利害関係者および顧客に対する頻繁なレビュー/デモ。これにより、イテレーション (スプリント) の期間だけ、リスクと失われる時間が削減されます。
- デイリーコールまたはスタンドアップミーティング
于 2008-11-04T18:54:44.253 に答える
1
スクラム マスターと人事マネージャーの両方として、私は週 40 時間労働を強く支持してきました。ワークライフバランスが変化すると生産性が急速に低下するため、私は積極的にチームメンバーに 40 時間以上働くことを思いとどまらせています。深夜勤務の日の回復には、残業時間よりも長い時間がかかることがよくあります。
スクラムが適切に実行されている場合、スクラムは、イテレーションの最後に発生することが多い「詰め込み」を最小限に抑えるのに役立ちます。これは、一貫したペースを奨励する (要求する?) ことであり、ベロシティやバーンダウンなどのツールは、進行状況を計画および追跡するためにうまく機能します。
于 2008-11-04T19:51:38.150 に答える
1
私は、さまざまなアジャイル手法を実践するいくつかのショップで働いてきました。最も興味深かったのは、1 日に 4 回の「セッション」があり、その間に 20 分間の休憩をはさみ、約 1 時間半の長さでした。金曜日は Personal Dev day だったので、最後の 2 つのセッションは、自分が取り組みたいと思っていたものに関するものでした。
私たちにとって重要なことは、コミュニケーション、ユーザー ストーリーの概念の明確化、done を「本番環境」と定義すること、そして信頼でした。また、ストーリーを 1 日以内のチャンクに分割し、理想的には 1 ～ 2 回の開発セッションに分割するようにしました。通常、セッションごとにペアを他のすべてのセッションに交換しました。
現在、私は部分的に分散している 20 人以上の開発チームを運営しています。私にとって重要なテナントは、持続可能なペースです。つまり、チームが週 40 時間以上働きたくないということです。もちろん、誰かが遅くまで残業して仕事をしたい場合、それはその人次第ですが、私は一般的に、週 40 時間の速度内で仕事ができるように懸命に努力しています。
于 2008-11-04T20:59:23.893 に答える