問題タブ [scrum]

スクラムは理論的には簡単で、実践するのは難しいですが、完了の定義を聞きたかったのです。つまり、製品に「完了」というラベルを付ける前に、製品が通過しなければならないゲート (単体テスト、コード カバレッジ > 80%、コード レビュー、負荷テスト、perf.test、機能テストなど) は何か。

こんにちは、私はスクラムの方法論に慣れていないので、環境に慣れるための助けを探しており、展開とバグ修正と再テストに費やした開発者と QA 時間を追跡するためのバケットが必要かどうか疑問に思っています。グラフに大きな影響を与える可能性があるようです。

Marc と Laura Sewell による「The Software Architect's Profession」という本 ( Amazon リンク) を読んでいて、ソフトウェア アーキテクトが古い非アジャイル BDUF アプローチの一部であるかどうか疑問に思いました。

アジャイルアプローチにおいて、ソフトウェアアーキテクトの居場所はありますか? 特にスクラムに興味があります。

ところで、私は現在、大手企業の Unix アプリケーション アーキテクトです。

乾杯、

ロブ

スクラム マスターになることで、私が従うプロセスに本当に価値を加えることができると確信していますが、私が取り組んでいるアプリケーションの領域の背景が、プロジェクトのより良い計画とスケジューリングを行うのにさらに役立つと信じています

オンライン Web プロジェクトの計画には、さまざまな手順があります。

1) 情報アーキテクチャ

• ユーザーストーリーを提供します
• ワイヤーフレームを提供

2) 設計

• ワイヤーフレームを使って素敵なデザインを開発する

3) 開発

4) テスト

アジャイルに取り組むには専任のチームが必要であることを私は知っています。しかし、プロジェクトが終了するまで、専任の IA を持つことは不可能です。プロジェクトは小規模であるため、開発者はさまざまなチームで作業しています。50 の小さなプロジェクトと 20 の新しいプロジェクトが異なるリソースを使用していることがわかっている場合、どのようにリソースを計画しますか?

また、これを支援できる便利なツールはありますか?

スクラムが実際の生活でどのように機能するか、または機能する必要があるかを理解しようとする別の質問があります。これが私が遭遇する典型的なシナリオです：

注：「プロダクトオーナー」という用語は、以下では使用されていません。これは、真の「プロダクトオーナー」（この場合はプロダクトマネージャー）が最終決定を下さないためです。DBリードは、アプリがDBとどのように相互作用するかを決定する際に、多くのことについて最終決定権を持っています。QAには、物事がどのように見えるか/機能するかについて独自のアイデアがあります。それらのアイデアはバグとして入力され、一般に（すべての人が）そのように扱われることが期待されます。

1. プロダクトマネージャーは、「XユーザーはYを実行するためにページが必要です」のようなストーリーを書きます。
2. スプリント計画会議で、ストーリーはスプリントバックログに追加されます。
3. 一部の貧しい開発者はストーリーをつかみます（または割り当てられます）。
4. 開発者は、プロダクトマネージャーに「ページをどのようにしたいか」と尋ねます。
5. プロダクトマネージャー（利用可能な場合）は、「うーん、A、B、Cを収集する必要があります」と述べています。
6. 開発者は、それがどうあるべきかについての彼の最善の推測に取り組み始めます。
7. 開発者はページをストアドプロシージャに接続しようとし、DBリーダーにいくつかの質問をします。DBリードは、「ページにもDとEが必要です。Bは必要ありません」と述べています。
8. 開発者は変更を加えてコミットします。
9. QAは「Eは混乱していると思います」と言っています。
10. 開発者は、QA、DBリード、およびプロダクトマネージャーに、最終ページがどうあるべきかについて合意してもらうために苦労する必要があります。

私の理解（スクラムの教え方によると）は、ページの要件を具体化するのは開発者の責任であるということです。私たちの環境では、上記のように、これは開発者にとって苛立たしい経験と、要件が何であるかについて統一された決定に至るすべての力を得るのを待つ間、開発者にとって多くの無駄な時間をもたらします。

2時間のタスクの要件を確定するのに、数日以上かかる場合があります。1人で十分な時間を過ごすのは難しいです-3人でさらに難しいです！

アンチスクラムであることは知っていますが、プロダクトマネージャー、DBリード、およびQAチームは、計画会議の前に会議を行い、スプリントに追加するタスクの詳細をハッシュ化する必要があるようです。（開発者が考慮される入力を持っていることはめったにありません。会議でこれを実行しようとすると、バックログ内のすべてのアイテムのすべての詳細をハッシュ化するのに、冗談ではなく1日かかる可能性があります。）

誰かがこれに対処しましたか？助言がありますか？あまり長く歩き回りたくないので、さらに詳細が必要な場合はお知らせください。

ありがとうございました！

私たち全員が、ある時点で在宅勤務者に対処しなければならなかったと確信しており、現在、私の新しいプロジェクトには、オフィスワーカーの「コア」グループとオフサイトの在宅勤務者がいるという状況に直面しています。過去の過ちを繰り返したくないので、在宅勤務者をアジャイル プロセス、つまりスクラムに効果的に統合するために、人々が過去にどのような方法を試みたかを知りたいと思います。

私の最初の懸念は、在宅勤務者が「毎日のスクラム」ルーチンを破る最初の人になることです。そして、人間の本性がしばしばそうであるように、一度それが壊れると、再開して人々を軌道に戻すことは困難です. スクラムは、毎日のスクラムに参加できなかったり、遅刻したりした人に対して、ささやかな楽しい「罰則」を課すことを推奨しています。たとえば、瓶に数ドルを寄付して、後でプロジェクト終了パーティーなどでビールを 1 ケース購入するなどです。これは明らかに、オンラインで実施するのが難しいものです。

在宅勤務者のもう 1 つの大きな問題は、「見えない、気にならない」問題です。ウェブカメラ/スカイプ/電話会議の使用以外に、チームをできるだけ緊密に保つためのヒントはありますか?

また、異なるタイムゾーンからの在宅勤務者への対処はどうですか? 現時点では、幸運にもこの問題は発生していませんが、将来的には発生する可能性があります。他のチームはこの問題にどのように対処しましたか?

私たちはスクラムを試してきましたが、しばらくの間、アジャイル アプリケーション開発の独自のバージョンとして形式化しようとしています。これが現在のプロセスの仕組みです。現在の状態では、主な欠点が 2 つあります。あなたが同様のアプローチを持っているかどうか、そしてコミュニティが私たちが現在持っている障害に対する実用的なヒントを持っているかどうかについて意見を求めたい.

• スクラム チーム = 開発者 4 名、QA 2 名、テクニカル ライター 1 名、PO(PM) 1 名、スクラム マスター (エンジニアリング ディレクター) 1 名
• リリース = 3 スプリント
• スプリント = 2 週間

PO と顧客は、ユーザー ストーリーと関連する承認基準の製品バックログを作成します。
各反復の開始時の 1 週間のスプリント計画

• Day 1# スプリントのバックログを見積もり、優先順位について合意する
• 2 ～ 5 日目 # スクラム チームは、ストーリーについて話し合い、スプリント バックログの各ストーリーの詳細に取り組みます (ストーリーの詳細を取得し、プロセス フローがある場合は、適用する UE ガイドラインを特定し、UI アイテム/フィールド/ウィジェットの詳細とその特定のものが必要な場合の動作、受け入れ基準の理解、およびテストの作成)
• 2 週間のスプリントと 15 分のデイリー スクラム
• 3週間のサイクルを繰り返す

これには、次の 2 つの大きな欠点があります。

1. 春の計画週で議論される詳細は効果的に取り込まれず、wiki に記録されます。スクラムでそのような詳細をキャプチャするための標準的な形式がないため、多くの場合、毎日のスクラムで時間が無駄になったり、ストーリーの詳細をさらに理解するためにその後の会議が必要になります。スプリント計画において、機能的にかなり複雑な製品のストーリーの詳細を把握する最良の方法は何ですか? 問題のほとんどは、詳細なモックがないと画面/フィールドをどのようにレイアウトするかを開発者が決定できない UI に関連しているようです。
2. チームがスプリント サイクルにあるときに、顧客から戻ってくる致命的な重大なバグをどのように予測しますか。現在、開発者はこれらのレッド アカウントの問題をサポートするために引き離す必要があり、スプリントが中断されます。

これを改善する方法について何か意見はありますか?

私は努力を複製するのが好きではありません。ただし、物理的なカード ウォールとオンラインの「電卓」 (Excel、いくつかのスクラム ツール) またはオンラインのカード ウォール (Mingle など) の両方でアジャイル イテレーションの進行状況を追跡することには利点があることがわかりました。

チーム スペースの物理的なカード ウォールは、カードの状態と本能的なつながりを提供することを発見しました...そして何かを終えたときにカードを物理的に動かすことは、オンラインでは真似できないレベルの満足感を提供します。私はカードを感じることができます...そして人々は私が何かを動かすために壁まで歩いているのを見ることができます.

オンライン ツールは、リモートで共有し、進行状況を計算するための優れた機能を提供します (たとえば、Mingle では、組み込みツールを使用して、実際のデータからバーンアップまたはバーンダウンを自動的に計算し、それらを手動で行うための多くの管理時間を節約できます)。 ）。

アジャイルの実践者が私のように 2 つのトラッキング メディアを維持している場合、物理的な壁の利点を「オンラインでできる... なぜカード ウォールでやりたいのか?代わりは？"。

私はデザイン会社の技術部門で働いています。XP を使用して、部門のソフトウェア開発を管理しています。私は、スクラムについて説明し、クライアントのプロジェクト作業を管理するためのより広い文脈でスクラムが適切かどうかについて簡単なプレゼンテーションを行うよう求められました。

スクラムは、グラフィック デザイナー、情報アーキテクト、コンテンツ エディター、ユーザー エクスペリエンス エンジニア、Web デザイナー、およびソフトウェア開発者を含む部門横断的なチームに適用されます。

スクラムはこの種のチームにどのような利点をもたらすでしょうか?