問題タブ [agile]

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

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

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

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

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

乾杯、

ロブ

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

上司/チームに提示する、簡単に消化できる本を探しています。

背景情報: 職場での会議では、上司/チームが、このあたりでより多くの「ベスト プラクティス」を実装する方法を熟考することがますます多くなっています。(「ここ」 = 非常に小さなアプリケーション開発ショップ。4 人の開発者)

以下は、私のチーム全体が必要だと同意した項目です。

• 夜間ビルド
• バグトラッカーの「バグ」をより小さく、より具体的な項目に分解する
• 自動テスト

私たちが直面している問題は、どのように始めるかです。

私の店が明確で具体的な計画や一連のルールを選択するだけで、他のすべてがうまくいくと信じています. 現在、私たちはあいまいで心地よいアイデアや響きの良い流行語についての議論に行き詰まっています。

TDDまたはアジャイルチーム/ショップを導くための管理スキームを実装するための明確で個別の連続したステップが含まれているお気に入りの本（またはオンラインリソース）を私に勧めてください.

TDD とアジャイル以外にも、これらの懸念に対処するパラダイムがあることは認識していますが、私自身の利益と偏見は TDD とアジャイルに向けられているため、チームの変化への欲求を利用して、その方向に「微調整」したいと考えています。 . または、私の意見に激しく反対する場合は、遠慮なく平手打ちしてください。気分を害することはありません。:)

他の人が述べているように、これらの質問は、回答者が回答ごとに 1 つの推奨書籍のみを挙げた場合に最もよく回答されると思います。

皆さん、ありがとうございました。

オンライン 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 つの大きな問題は、「見えない、気にならない」問題です。ウェブカメラ/スカイプ/電話会議の使用以外に、チームをできるだけ緊密に保つためのヒントはありますか?

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

私たちのチームには、各開発者に割り当てられた小さな増分タスクを投稿するタスクシステムがあります。

各タスクは独自のブランチで開発され、トランクにマージされる前に各ブランチがテストされます。

私の質問は次のとおりです。タスクが完了したら、このタスクで実行する必要があるテストケースを誰が定義する必要がありますか？

理想的には、タスクの開発者自身がその仕事に最も適していると思いますが、時間の無駄だとか、単にやりたくないと思っている開発者からは多くの抵抗がありました。

QAの人にやってもらうのが嫌いなのは、彼らが自分の作品を作るというアイデアが好きではないからです。たとえば、テストするには手間がかかりすぎるものを省略したり、必要な技術的な詳細を知らなかったりする場合があります。

しかし、同様に、テストケースを実行する開発者の欠点は、壊れると思われるものを除外する可能性があることです。（無意識のうちに多分）

プロジェクトマネージャーとして、自分で各タスクのテストケースを書くことになりましたが、時間に負担がかかるので、これを変更したいと思います。

提案？

編集：テストケースとは、ブランチをトランクにマージする前に、ブランチに対して実行する必要がある個々のQAタスクの説明を意味します。（ブラックボックス）

私たちはスクラムを試してきましたが、しばらくの間、アジャイル アプリケーション開発の独自のバージョンとして形式化しようとしています。これが現在のプロセスの仕組みです。現在の状態では、主な欠点が 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. チームがスプリント サイクルにあるときに、顧客から戻ってくる致命的な重大なバグをどのように予測しますか。現在、開発者はこれらのレッド アカウントの問題をサポートするために引き離す必要があり、スプリントが中断されます。

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