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

私の会社の一部の開発チームはアジャイル開発手法に切り替えており、開発者の作業は、2週間の反復サイクルのため、些細なソフトウェア機能について細かい点について話し合い、プログラムするために減少しているようです。また、「開発者なら誰でもバグを修正できる」という考え方もある。私は最近、それらのチームの1つに参加し、同じ会社の別のチームから転勤しました... 開発者はソフトウェアの機能を最初（設計）から最後（実装および単体テスト）まで所有する必要があると強く感じます。アジャイルはこの考えに反しているようです。私の認識に真実はありますか、それともアジャイルの悪い実装を生きているだけですか？ 2週間の反復の間、人々は、そのサイクル中のワークロードに応じて、新しい小さな機能とバグ修正をいくらか恣意的に割り当てられます。ソフトウェアの主要な機能の責任を誰も所有していないようです。我々は追加のような、些細なものに倍の愚かな金額を費やす単一などの話、毎日スクラム、コードレビュー、で、2週間の反復中にダイアログに完了ボタンを では、アジャイルプロジェクトでは、より大きな機能をどのように管理するのでしょうか。責任は誰にありますか：個々の開発者またはチーム全体？どのようにしてマニューシャから自分自身を抽出し、より長期的な目標に焦点を当てますか？どんなフィードバックも価値があります。

8 project-management  agile  product-features  code-ownership 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 製品所有者をどのように評価しますか？より具体的には、製品所有者のパフォーマンスレビューをどのように実施しますか？製品の所有者を確認するときに、どのような品質または特性を確認しますか？

8 project-management  agile  scrum  product-owner  product-management 

最近スクラムについて読んでいます。私の理解では、スプリントが始まる前に会議が開かれ、製品のバックログから次のスプリントのバックログに何を移動するかを決定します。現在のスプリントで機能が完了すると、「Ready to QA」バケットに入れられ、この時点で混乱します。バグレポートは製品のバックログに戻りますか？このサイクルで実行する作業はすでに決定しているため、スプリントバックログに戻れないと思いますか？QAがバグを検出するとどうなりますか？どこに行くの？

8 project-management  agile  scrum 

CTO / CIOによって設定された開発チームの新しい要件の1つは、テスト駆動型の開発になることですが、開発のライフサイクルを把握していないため、ビジネスの残りの部分は役に立たないと思います。 1つのスプリント内で常に変更されました。これは、10のテストケースを書くことに時間を浪費することに苛立ち、明日は役に立たなくなります。 これらの要件の変更を回避し、開発ライフサイクルについてビジネスを教育するプロセスを設定することを提案しました。ビジネスがアイデアを得られない場合はどうなりますか？あなたならどうしますか？

8 agile  tdd 

アジャイルを使用して（TFSを使用して）新しいプロジェクトを開始しようとしています。製品のバックログに関して、「良い実践」の質問がいくつかあります。 ユーザーのストーリーを最初に追加するとき、（たとえば）「バックログ」イテレーションに入れるか、イテレーションを空白のままにしておくのが良いでしょうか？明らかに、米国での作業を開始する時が来れば、それは適切な反復バックログに移動されます。 エピックをより小さなUSに分割するとき、元のエピックは不要になったので、単に閉じますか？それとも、叙事詩の子供として新しい米国を作成する必要がありますか？（すべての子USが完了したら、エピックを閉じるのは誰かの責任です）。 最後に、製品のバックログには、ステータスに関係なくすべてのUSが表示されますか、それとも開始されていないUS（つまり、提案された「バックログ」イテレーション）のみが表示されますか？ これらの質問は生死にかかわるものではないことに気づきましたが、最初から適切に整理できるように、他の人が製品のバックログをどのように管理しているかを知っておくとよいでしょう。

8 agile 

私の現在のプロジェクトは、途中で分割された「ディスカッション」を持っています- 「このストーリーは当初考えていたよりも複雑です。再推定する必要があります」対「決して再推定する必要はありません。 "。 あなたが再推定する必要があるかどうかについて誰かが光を当てることはできますか？ 私見私はあなたが新しい要件やストーリーのために完全に新しいカードを持ち出すことができると想像しますが、戻ってバックログアイテムを再推定することは相対的なサイジングの概念を歪めているようで、バックログを「膨らませる」だけです。

8 agile  scrum  estimation 

まあ、タイトルは本当にすべてを語っていますが、少し詳しく説明すると、ランダムで通常は効果的なQA部門を担当し、XP環境での作業を学ぶことができます（もちろん、XPワークフローを習得するための学習曲線があります）。彼らは効果的になるためにより多くのプログラミングスキルを必要とするでしょうか？もしそうなら、彼らは何を知る必要がありますか？

8 agile  training  qa  extreme-programming 

私はスクラムとTDDに取り掛かっていますが、いくつかの混乱があると思います。フィードバックについてお聞きしたいと思います。バックログにユーザーストーリーがあり、TDDの一部として開発を開始するために、これまでの要件が必要であるとしましょう。 プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任を負うべきだと言うのは本当ですか？ 受け入れテストは形式的である必要があるため、上記は正しいと思います。テストとして使用できるだけでなく、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。 私が後でこれらの受け入れテストを受けて、それを私の要件として使用すること、つまり、それらが（TDDを介して）実装する一連のユースケースであることも本当ですか？私は混乱をあまり作りすぎていないといいのですが、それが今私が考えている現在の流れです。 更新 当初の意図は不明確だったので、言い換えます。TDDの使用中にユーザーストーリーをコードに変換するスクラムフローの詳細を知りたい。 開始点は明らかです。ユーザーはニーズ（または製品としてのユーザーの代表）を表面化します。これは、既知の形式で1〜2行の短い説明であり、製品のバックログに追加されます。 春の計画会議がある場合、ユーザーストーリーはバックログから取得され、開発者に割り当てられます。 開発者がコードを作成するには、要件が必要です（特に、要件はテストの派生元であるため、TDDで必要です）。 いつ、誰が、どの形式で要件がコンパイルされますか？ 私が頭に浮かんだのは、製品とQAが受け入れテストを介して要件を定義することです（私はFitNesseまたはソートを使用して自動で考えていますが、それは私が考えるコアではありません）同時に2つの目的を果たすのに役立ちます： 彼らは「完了」を適切に定義しています。 それらは、開発者にテストの派生元を提供します。 これらがいつ記述されたかはわかりませんでした（スプリントが選択される前に追加情報が届くか、ストーリーが選択されないため、繰り返しの間に開発者がスタックを待機する可能性があるため、これは無駄になります）。 ..）

8 agile  scrum  tdd  requirements  acceptance-testing 

私は小さな製品ベースの会社で働いています。既存の製品をゼロから書き直そうとしています。開発にはアジャイル手法を採用する予定です。私の質問は、プロジェクトの開始前でも既存の製品を書き直しているので、すべての要件があるので、アジャイルの世界に飛び込む価値はありますか？すべての要件を事前に用意しておらず、段階的に要件を取得する場合、アジャイルの方が便利ではありませんか？ 次に、アジャイルに移行した場合、データベースを設計するためのベストプラクティスは何でしょうか。最初のイテレーションで、ログインシステムを作成したとしましょう（ユーザーはログイン、ログアウトなどができます）。他のテーブルを気にすることなく、Usersテーブルを作成する必要があるだけですか？そして、他のテーブルは私たちの製品が進歩するにつれて進化するでしょうか？

8 project-management  agile  development-methodologies 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 特定の国でしか利用できない特定の知識があるため、私たちのスクラムチームは地理的に分割されています（私が知っているのは理想的ではありません！）。つまり、たとえば7人のメンバーからなる1つのチームには、ある都市にビジネスパーソンがおり、別の都市に2人の開発者、別の都市に2人の開発者、別の都市に2人のQAがいます。 このタイプのグラフィカルに分散したチームを管理する方法について何か提案はありますか？ベストプラクティスはありますか？ スタンドアップはどのように行うのですか？スカイプビデオ経由？私たちは人々が6週間ごとに旅行することを保証していますか？タスクボードをどのように実行しますか？事実上またはビデオを介して？この設定ではかんばんがうまく機能しますか？

8 agile  scrum 

私は、開発チームの規模を繰り返し削減している会社で働いており、以前の10人のチームは、製品ごとに1人の開発者（および5つの製品間で共有された2、3人のテスター）になりました。私たちは以前、かなり大きなプロセスを要し、大企業からのスピンオフであり、その多段階ウォーターフォールプロセスを継承していました。 ソフトウェアを十分な速さでリリースしていないこと、およびこれがプロセスの障害である可能性が高いことが経営陣から判明しました（90％の人員の損失はおそらく助けにはならなかったものの、それが原因である可能性があります）。設計ドキュメントの作成などに時間を費やさないようにするために、アジャイルプロセスに移行するよう強く求められてきました。 アジャイルへの切り替えが一人のチームで役立つかどうかについて私はちょうど興味があると思います。多くのメリットは、チームメンバー間の可視性の向上とコミュニケーションの向上から得られると私は理解していましたが、私は自分のしていることを理解しており、マネージャーもそうです。とにかく製品をテストする人がいないので、私はすでにTDDを行っています。 TL; DRバージョン：私が本当に求めていることは、1人の「チーム」でアジャイルを実装できますか、それから何かメリットがあると思いますか、それとも通常、大規模なチームにとってより効果的なものですか？

8 agile  team 

多くの場合、TDDを使用する利点は「長期的な」利益と見なされます。コード全体がより適切に構造化され、テストが容易になり、全体として顧客から報告されるバグが少なくなります。 しかし、TDDを使用することの短期的なメリットはどこにありますか？実際に弱くて簡単に測定できるものはありますか？ 長期的な利益が測定可能である場合、明らかな（または定量化によっては明らかではない）短期的な利益を得ることが重要ですか？

8 agile  tdd 

ほとんどのアジャイルメソッドの基本的な要点は、機能が開発され、テストされ、多くの場合リリースされるまで、「完了」しないことです。これは、スクラムプロセスの「スプリント」など、時間の短いターンアラウンドで発生するはずです。 アジャイルの共通部分はTDDでもあり、テストが最初に行われると述べています。 私のチームは、多くの特定の描画などを行うGUIプログラムに取り組んでいます。テストを提供するために、テストチームは、少なくともテストしようとしていることを実行しようとする何かを処理できる必要があります。この問題を回避する方法は見つかりませんでした。 基本的に不可解なインターフェースをターゲットにしたソフトウェアを書こうとした場合、非常に苦労することになるので、それらがどこから来ているのか非常によくわかります。動作はかなり明確に規定されていますが、自動化に関してさまざまなUI要素を操作する正確なプロセスは、機能に固有すぎて、テスターが自動化スクリプトを記述して、存在しないものを駆動することはできません。たとえできたとしても、多くのことが後で仕様から欠落していると判明します。 私たちが行うことを検討したことの1つは、人間が「自動化」できるように、ユースケースの観点から説明した、実行する必要のある一連のステップのようなテスト「スクリプト」をテスターに​​記述させることでした。これは、開発者が機能を作成したり、他の誰かが検証したりすることで実行できます。テスターは後で機会を得たときに、主に回帰の目的で「スクリプト」を自動化します。しかし、これはチームに追いつくことにはなりませんでした。 チームのテスト部分は、実際にはかなりの差で遅れています。これが、人間が実行する「スクリプト」を開発するための明らかに余分な時間が発生しなかった理由の1つです。開発者に追いつくために危機に瀕しています。それらを待っていた場合、何も実行されません。それは本当に彼らのせいではありません、彼らはボトルネックですが、彼らは本来あるべきことをしていて、できるだけ速く働いています。プロセス自体はそれらに対して設定されているようです。 非常に多くの場合、テスターが最終的に確認したバグを修正するために行った作業を1か月以上前に戻す必要があります。私が何かをしたいのは醜い真実です。 では、この失敗のカスケードを解決するために他のチームは何をするのでしょうか？テスターを私たちの前に置いて、どのようにしてスプリントで実行する機能のテストを書いて、その間に親指をいじる必要がないようにすることができますか？現在のところ、アジャイル定義を使用して機能を「完了」させるには、開発者を1週間作業させ、次にテスターを2週間作業させ、開発者が思いついたすべてのバグを修正できるようにする必要があります。過去数日間。それが妥当な解決策であると私が同意したとしても、それは起こりません。より良いアイデアが必要です...

8 agile  testing  development-process  tdd 

同じ機能を複数の役割で共有する必要があるユーザーストーリーがいくつかあります。私はこれらの物語をこのように書き始めました： Role-AまたはRole-BとしてAction-Xを実行すると、Event-Yが発生するはずです。 これは、ユーザーストーリーでその概念を表現する正しい方法ですか、それとも役割ごとに1つのストーリーに分割する必要がありますか？

8 agile 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 こんにちは、 私の職場環境には問題があります。私たちのITチームは機敏性を高めようとしていますが、実際にビジネスから賛同を得ているわけではありません。彼らは毎日のスタンドアップとスプリントのレビューに参加し、スプリントの計画を支援しますが、その後（大部分は）連続的な開発スタイルに進む前に、プロジェクトのために4か月の要件収集を行います。スプリントの目標は、「リリースにXX％近づく」などです。 ITチームにとって、彼らはスプリントを一種の死の行進に変えました。スプリントを1日終了し、翌日新しいスプリントを開始します。スプリント間で行われる反映や変更はありません。 これまでアジャイル方法論を実行したことがないので、私はそれらについて非常に快適な紹介をしていません。だから私の質問は： 1）リフレクション、イントロスペクション、変更などを行うには、スプリントの間に時間（おそらく1週間程度）が必要ですか？それとも、背中合わせのスプリントが標準なのでしょうか？ 2）アジャイルなビジネスパートナーがいないアジャイルチームが生き残る可能性はありますか？そうでない場合、必ずしも俊敏なマインドセットではないにしても、ビジネスを反復的な方向に進めるためのいくつかの移行方法論やヒントがありますか？ 3）チーム全体がすべてのスプリントに参加する必要がありますか？1人のスプリントにほぼ20人のプログラマーがいますが、完全に異なるプロジェクト（通常は3〜5人のチーム、時にはそれよりも大きいチーム）に取り組んでいます。単一のスプリントを使用するのは正常ですか、それとも複数の独立したスプリントを管理する必要がありますか？複数のスプリントを同時ロックステップで維持しようとしているのでしょうか、それともそれらのタイムテーブルを重複させて柔軟にする必要がありますか？ どんな考えやアドバイスも大歓迎です。SOから質問をするのは今回が初めてなので、これらの種類の質問を表現するより良い方法があるかどうかを知らせてください（FAQはかなり役に立ちましたが、完全にフォローしているとは限りません）。ありがとう！

8 project-management  agile