問題タブ [scrum]

以下は、スクラムに関するウィキペディアの記事が、デイリー スクラムについて述べていることです。

会議は時間通りに始まります。多くの場合、遅刻に対してチームが決定した罰があります（例：お金、腕立て伏せ、首にゴム製のチキンをぶら下げるなど）。

それは良い習慣だと思いますか。また、過去にどのような自己罰が効果的でしたか?

Schwaber＆Beedleの「スクラム」本（および私が読んだ他のスクラム文献）は、スプリントの終わりまでにリリース可能な製品を手に入れることに焦点を当てているようです。確立されたサイトのWeb開発（少なくとも私たちの場合）は、（さまざまなサイズの）「拡張機能」と多くの小さな「修正」の開発で構成されています。スプリントの最後にのみ（Webに）デプロイすると、大規模な拡張機能の展開が遅くなりますが（おそらく良いことです）、小さな拡張機能と修正の展開は劇的に遅くなります（つまり、バグが長く続く）。

ミッドスプリントの展開はスクラムで異端的ですか？私たちの場合、スプリントも適用できますか？私はスプリントを完全に誤解しましたか？

Let’s say product X is worth 10 story points. Development starts in sprint Y, but is not completed in time. What do you with the story points when calculating sprint Y’s velocity?

Would you:

a. Allocate 0 story points for sprint Y and 10 points for the sprint it is eventually completed in;

b. Determine the story points for the remaining work (let’s say 3) and allocate the difference to sprint Y (7 in our example); or

c. Something else?

Thanks in advance!

現在、私たちのチームは、掲示板と Excel スプレッドシートを組み合わせて使用​​して、タスクを追跡し、バーンダウン チャートを作成しています。バックログは、封筒に入ったインデックス カードに保管されます。

これは、利害関係者が同じ場所にいる場合にうまく機能します。ただし、近いうちに地理的に離れた 2 つの場所にスクラム チームを配置する予定です。Sharepoint を活用して、スクラムの成果物 (バックログ、バーンダウン チャート、ベロシティなど) に関するコミュニケーションを支援する方法のベスト プラクティスを探しています。

その目的のためにSharepointをどのように活用しましたか?ベストプラクティスと潜在的な落とし穴は何ですか?

シーンを想像してみてください。企業はアジャイル開発にスクラム手法を使用することを考えています。彼らはチームシステム用のスクラムを実装しており、誰もがそれに非常に満足しています。ただし、企業は開発コストを活用したいと考えており、タスクの実行にかかる時間を含めるようにスクラムバックログ作業項目テンプレートを変更するように求めています。開発者が生産的な作業IEに費やした時間、新機能の追加に費やした時間を知る必要があるという考えです。

ビジネスの一部の人々（私を含む）がこれに関して抱えている問題は、あなたが何かに費やした時間の浪費を記録することは、スクラムの目的を打ち負かすことです。リード開発者の観点から知りたいのは、これだけ多くの作業を行うための時間がこれだけあるということです。タスクの残り時間を記録し、目標の達成か​​らどれだけ離れているかを確認できます。

多分私はポイントを逃していますか？教えてください。しかし、誰かが私たちが何かをするのに費やした正確な時間を記録せずに働くことができる方法を知っていて、それでもお金を投資する人々を喜ばせるなら、あなたの答えは大いにありがたいです。

私はしばらくの間アジャイルをやっているオフィスで働いています。私たちはプロジェクト管理にスクラムを使用し、XPのエンジニアリングプラクティスを組み合わせています。それはうまく機能し、私たちは常にレッスンを学び、プロセスを洗練しています。

テストの通常の方法について説明し、これをどのように改善できるかについてフィードバックをもらいたいと思います。

TDD：最初の防衛線 私たちは単体テストについて非常に信心深く、開発者も包括的なテストを作成し、常にモックでSUTを分離するのに十分な経験を積んでいると思います。

統合テスト 私たちが使用する場合、統合テストは基本的に、モックを使用しない単体テストと同じです。これは、単体テストをすり抜けたいくつかの問題をキャッチする傾向があります。これらのテストは、テストを意味のあるものにするためにシステムが特定の状態に到達する必要があるため、通常、スペックフレームワークのbefore_eachおよびセクションで多くの作業を行うため、読みにくい傾向があります。after_each

機能テスト 通常、これは構造化された手動の方法で行います。かっこいいSeleniumとWindmillで遊んだことがありますが、少なくともまだそこにはありません。

他の誰かがどのように物事をしているのか聞きたいです。統合テストまたは機能テストが十分に行われていれば、もう一方は無視できると思いますか？

私の会社の人々は、単体テストを多くの余分な作業と見なしており、既存の機能テストよりもメリットが少ないと考えています。単体テストと統合テストは価値がありますか? テストを念頭に置いて設計されていない大規模な既存のコードベースに注意してください。

スクラム方式で動作します。プロダクトオーナーが、ユーザーがWebサイトのコンテンツを検索できる新しい機能を望んでいると仮定します。

合計作業は8ポイントで、これらはユーザーストーリーになります。

• ユーザーは検索語を入力できます（0ポイント）
• 検索結果はユーザーに表示されます（8ポイント）

開発者の進捗状況について、より多くの洞察を得たいと思います。しかし、私はこれらの話をこれ以上分解することはできません。

しかし、私は物語を書き直すことができました。これらの話は技術的な話なので、私は気が進まない。

• 検索テキストボックスを追加（0ポイント）
• データベースにインデックステーブルを作成する（0ポイント）
• データABCが変更されたときにインデックステーブルが更新されていることを確認してください（3ポイント）
• データXYZが変更されたときにインデックステーブルが更新されていることを確認してください（2ポイント）
• データベースから結果を取得する（1ポイント）
• 検索結果ごとに正しいURLを作成する（2ポイント）

これらの状況にどのように対処しますか？

開発チームでスクラムを使い始めた方へ: 従来のチームを維持したり、新しいチームを結成したりしましたか? 私たちの組織では、データベース、製品開発、およびフロントエンド開発者 (単純化されています!) に分かれています。

他の人が実際にスクラムのためにチーム構造全体を再編成したのか、それとも「古い」チームの 1 人などを組み合わせて専用のプロジェクト (?) チームを結成したのかに興味があります。