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

私のちょっとした背景-私はSCRUM（1〜2週間のスプリント）を使用したアジャイル環境内で約2年間、手動テスターです。そこで、Selenium WebDriver（Javaを使用）を使用した作業に自動化テストを導入したいと思います。 私の質問は、いつ機能を手動でテストする必要があるか、いつ自動化テスト用に変換する必要があるかです。 私は次のようなさまざまなアプローチを読んでいます。 新しいスプリントの開始時に、ユーザーストーリーを以前のスプリントの自動スクリプトに変換するか、または 同じスプリント内でユーザーストーリーを変換します。 アドバイスは非常にいただければ幸いです。前もって感謝します。

9 testing  agile  scrum  selenium  test-automation 

人々が私に潜在的に明白な質問を甘やかしてくれることを願っています。私は、毎日スクラムミーティングを行う多くの組織で働いています。一部の組織はチェックインにスクラムのみを使用することに非常に厳格です（「3つの質問」-昨日何をしましたか、今日何をしているのですか、ブロッカーはいますか）。他の一般的な傾向がある他の組織発表または詳細な技術的ディスカッション。 この記事のように、チェックインに関連しないこのようなディスカッションを許可することは誤りであるという意見を聞いたことがあります。スクラムミーティングは、スクラムマスターからの一般的な発表、技術的なディスカッションなどには使用しないでください。 これから私が目にした主な害は、会議が必要以上に長く続く可能性があることです（そして、私に関係のない詳細の議論に座ることを余儀なくされるのは面倒です）。 グループ全体に関連しておらず、「3つの質問」の一部でもないディスカッションは、スタンドアップの一部であってはならないことは明らかです。しかし、グループ全体に関連する他のアナウンスがあり、とにかく議論する必要がある場合、その時点で（個別の会議や電子メールではなく）アナウンスを行うことは有害ですか？

9 agile  development-process  scrum 

ここで私は、比較的小さな新しいソフトウェア開発プロジェクトの範囲を定め、見積もっている最中です。私は、お客様から提案されたユーザーストーリーに目を通し、それぞれに対してタスクを配置しました。見積もりと、タスクがどのように達成されるかについての簡単なメモを付けました。受け入れ基準があります。すべては世界と良くなるべきです。 予定していた作品を見ていると、何か足りない部分があることに気づきました。機能を追加できるものをセットアップするだけの初期費用がかかります。特定の1つのユーザーストーリーではなく、すべてのユーザーストーリーに属するもの。 たとえば、このアプリケーションの一部は、XMLを解析するサービスです。ユーザーの観点から見ると、XMLの内容に応じてさまざまな処理を行う必要がある特定のストーリーがあります。実際にXMLパーサー（ファイルを探し、それを読み取り、内容をどうするかを決定する前に関連データを取り出すビット）を書くことは、これらすべてのストーリーの一部です。インストーラーなどを使用してWindowsサービスにラップする場合と同様です。これは、ユーザーに直接関係のない開発者中心のタスクです。 この特定のアプリケーションのもう1つの関連する例は、このアプリの機能に役立つ貧弱なレガシーコードのブロックを取得して書き換えることです。繰り返しますが、これはユーザーに直接の結果はありませんが、必要な作業です。ユーザーストーリーに焦点を当てたプロジェクト計画の中で、この作業の計画と実行はどこで「ライブ」ですか？ 「開発者として、私はしたい...」というユーザーストーリーを書いて人々がこれを解決するのを見てきましたが、他の場所で議論されているように、これはユーザーストーリーではありません。それは開発者のものです。 私（および他の人）がオンラインでTFSのような厳密な管理フレームワークを使用してプロジェクトを計画するのを助けるために、これに対する具体的な答えを探しています。これらは、「利害関係者の物語」や、計画会議でのスクラムチームによるインフラストラクチャタスクの説明への回答で言及されている他のあいまいなメタソリューションを作成する機能を備えていない傾向があります。

9 agile  team-foundation-server  planning  user-story 

当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定の種類のプロジェクトに特定の種類のソフトウェア（またはハードウェア）を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。Jiraプロジェクトを使用して特定のプロジェクトの問題をホストし、Jiraボードを使用して異なるチームのスプリントを実行します。 私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。 したがって、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング（週に1回）でレビュー、優先順位付け、推定され、将来のスプリントでは（プロジェクト固有の問題と共に）優先順位に従って取り組みます。 優先順位付けは問題を並べ替えることで行われ、並べ替えられた問題にsortedラベルを付けます（並べ替えられていない問題を検索できるようにするため）。次に、コアコンポーネントごとに1つの課題をバックログの先頭に手動で配置して、それらを最初に処理します。一部のチームがそのような問題をスプリントに入れる場合、代わりに別のアイテムをバックログの上部に手動でドラッグする必要があります。 これはかなりエラーが発生しやすいです。基本的に、私たちが持っているのは、「未解決」と「進行中」の間の「ソート済み」と「推定済み」の追加の問題ステータスです。これをsortedラベルとボード内での位置で反映することは、かなり面倒でエラーが発生しやすくなります。（たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、数週間前の広範なディスカッションでチームが決定した可能性がある問題の順序を静かにスクランブルします。） これを実装するより良い方法は何でしょうか？

9 agile  project-management  user-story  requirements-management  jira 

私は現在、スプリント中（2週間）で、特定のユーザーストーリーの要件とUXを定義することをデザイナーに課しています。 同じスプリントで、私はこのデザインを実装します。スプリントの計画中、私はこの未定義のユーザーストーリーがどのくらいの時間を要するかについて、かなりの推測をしなければなりませんでした。 今日、ようやくデザインを受け取りました。残念ながら、設計は不完全で曖昧であり、設計よりもクライアントの要件に似ています。ただし、このことから、まだ十分に見積もっていないことがわかります。 さらに悪いことに、これは初めてではありません。最後のスプリントでは、まったく同じことが起こりました。私はそれを振り返ってフラグを立てましたが、スクラムマスターは「それはあなたのための単なる開発だ」と言うのではなく、これを解決する方法の答えがありませんでした。皮肉なことに、バーンダウンが目標に達していない場合、彼はイライラします... 今、私は彼の仕事を成し遂げるためにデザイナーに尋ねる/協力する必要があります。私は他のすべてのタスクを完了しているので、これは私を我慢するでしょう。 だから私の質問は A）スプリント計画で依存関係をどのように処理しますか？編集：ユーザーストーリーのデザイン/ UXが実装と同じスプリントで発生しても問題ありませんか B）今はどのようにスプリントにアプローチすべきですか？現在のユーザーストーリーを再推定し、バーンダウンがバーンアップに変わり、無能/非生産的と見なされるのを確認しますか？または、「デザイナーが適切なデザインを作成するのを助ける」という行に沿って、現在のスプリントに新しいタスクを追加します

9 agile  scrum  planning 

私の理解では、デイリースクラムミーティングは非常に迅速で、親しみやすい方法で開催する必要があり、すべてのチームメンバーが出席する必要があります。なぜなら、それは他の誰もが行っていることを誰もが最新の状態にすることであるからです。 そのように開催されるスクラムデイリーミーティングが好きです。 私の最新のプロジェクトでは、デイリースクラムはステータス更新会議のようなものです。立場は私たちがスクラムを保持し、適切なアジャイルを実践しているということですが。 私たちは2つの異なる国に分散したチームであり、同じ国にいる人々は同じオフィスにいません。結果として、仮想スクラムがあります。 問題は、ミーティングが常に時間どおりに開始され、実際の開始時間の前に多くの人が電話をかけるため、実際にはミーティングの最初の1秒から開始されることです。小さな遅延に対する許容度なし。 たとえば、前回電話に出たときに、会議の調整担当者が全員がオンかどうかを確認し、チームメンバーの1人がまだオンではないが、彼が電話していたと言いました。そして、チームメンバーを待たずに共有を開始するように言われました。 また、誰もが多くの会議を行っており、スクラム会議と連続していることもあるため、会議の最初または2分の間に到着したかどうかは理解できます。 デイリースクラムを練習しているチームにとってそれは正常ですか？初めてのことです。 それについて直接書誌を見つけることはできません。すべてのチームメンバーの存在が強調されますが、会議は常に同時に開始する必要があることも強調されます。しかし、私は少しの許容誤差があると想像します。 私は誰かが "5秒"遅れて到着した場合にスクラムマスターがペナルティを課すことができることを示唆している誰かをブログで読みました。私はスクラムは友好的であるはずだと思っていました、そしてそのようなペナルティを持つことは逆効果に思えます。 このような状況で推奨されるアプローチは何ですか？

9 agile  scrum 

最近、私はスクラムについてかなりのことを読んで学び、とても気に入っています。ただし、解決策がわからない可能性のあるシナリオが頭の中にいくつかあります。たとえば、4人のWeb開発者（そのうちの1人はUI / UXデザイナー）のアジャイルチームを編成したいとします。このチームはスクラムの原則に基づいて活動します。 最初は、おそらくアパートを借りたり、Cookieを販売したりするなど、普通の人の中小企業のランディングページのようなプロジェクトに取り組んでいるでしょう。このような顧客は、通常、会社を雇うことを期待しているため、製品所有者ロール（IMHO）を設定できません。 、彼らにプロジェクトの全体的な目標と詳細を提供し、可能な限り関与を少なくして（多くの意思決定を含む）仕事が完了することを期待します（彼らの意見では、彼らにはもっと重要なことがあると考えています）。私は開発者/スクラムマスターの役割に従事したいとします（それは議論の余地があることはわかっていますが、チームメンバーとスクラムマスターになることはわかっています）。したがって、単に製品所有者の役割をするべきではありません。上手。 だから私の質問については：私が私の会社の事業主である場合、私も単に製品所有者になる必要があるだけですか（これらの役割にはお互いが含まれますか）？製品所有者の役割を持つ可能性のある営業担当者を雇うことはできますか？営業担当者ではなく、経験豊富な開発者の方が良いでしょうか？これは賢い動きですか？最後に、私の立場により適した別のアジャイルアプローチはありますか？ 編集：良いインプットをありがとうございました。私はいくつかのコメントを追加しました、任意の追加情報は非常に高く評価されます。

9 agile  scrum 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は最近、無駄のない開発チームを構築する方法について多くのことを考えています。最終的には、志を同じくする少数の人々と私自身の小さなソフトウェアハウスをオープンしたいと思います。目標は金持ちになることではなく、健康的な職場環境を作ることです。 これまでのところ、無駄のないチームを次のように定義しています。 小さい; 自己組織化; すべてのメンバーはQAを念頭に置く必要があります。 メンバーは複数の役割を実行できる必要があります 最後のポイントは、私が少し心配しているところです。マントラが進むにつれて... 開発者は悪いテスターを作ります。 多くの場合、開発者は自分のコードまたは同僚のコードに「近すぎ」て、品質のより高いレベルの評価を行うことを理解していますが、彼らが事実上悪いテスターであるとは確信していません。それどころか、優れた開発者の資質は優れたテスターの資質と非常に重なっていると私は考えています。 これが正しいと仮定して、私は開発者/テスターの問題を回避するさまざまな方法を考えてきましたが、私は実行可能なモデルを考え出したと思います。 私のモデルには以下が必要です： 2つ以上のプロジェクトがある小さなソフトウェアハウス 開発と配信に対するアジャイル（反復）アプローチ プロジェクトごとに1チーム すべてのチームメンバーはソフトウェア開発者になります 彼らの職務記述書には、開発、品質保証、テスト、および提供が責任として明確に記載されています これらの前提条件がすべて満たされている場合、プロジェクトは次のように編成できます（この例では、2つのプロジェクトAとBを参照します）。 すべてのチームメンバーが開発者の役割とテスターの役割を交互に行います チームメンバーがプロジェクトAの開発者である場合、チームメンバーはプロジェクトBのテスターに​​なります メンバーは、一度に1プロジェクトで作業しますので、として機能することが期待されているいずれかのDev やテスター。 ロールサイクル（二つの異なるプロジェクトで、再び）Devのような3回の反復及びテスターとして2反復で構成されてい プロジェクトチームには、常に3つの開発者と2つのテスターがいます。 メンバーの役割サイクルは、1反復だけフェーズがずれている必要があります。 これにより、チーム変更の突然の発生を最小限に抑えることができます。各反復で、2つのDevsと1つのテスターが前の反復と同じままです。 上記を考えると、次の長所と短所がわかります。 長所 会社全体にプロジェクトの知識を配布します。 チームメンバーが記述に役立つコードをテストしていないことを確認します。 フェーズが異なるロールサイクルとは、100％メンバーの切り替えを行うプロジェクトがないことを意味します。 交互の役割は退屈なプロジェクトの単調さを壊します。 短所 両方のプロジェクトのイテレーションは密接に結合されています。1つのプロジェクトが途中でイテレーションをキャンセルして再開した場合、2つのプロジェクトは同期しなくなります。これは、役割サイクルの管理を困難にします。 開発者を採用する際のヒンジは、テスターとしても活躍しています。 このアプローチについて友人や同僚と話し合ったとき、私はさまざまなレビューを受けました。一部の開発者はこのような役割を代替したいと考えていると信じていますが、他の開発者は個人的に試してみたいと言っています。 だから私の質問です： そのようなモデルは実際に機能するでしょうか？そうでない場合は、作業モデルに調整できますか？ 注： 簡潔にするために、私はDevおよびTesterの役割のみに焦点を当てました。必要に応じて、他の役割について詳しく説明します。

9 agile  testing  organization 

アジャイルアプローチはに仕事を構築することである垂直ユーザーストーリーと焦点を当てたが、完全にからのアプリケーションの一部を機能実現エンドツーエンド。これはソフトウェアを構築するための新しいアプローチなので、なぜこれが横長のストーリーよりも優れているかについて多くの文献を読みましたが、このアプローチの欠点についてはあまり知りません。 私はすでにアジャイルクールエイドを飲みましたが、ケーキを垂直にスライスすることは水平なスライスよりもはるかに優れていることに同意します。ここに私が思いつくかもしれない欠点の短いリストがあります： 開発者はストーリーの開発に必要なすべてのテクノロジー（UI +サービスレイヤー+データアクセス+ネットワーキングなど）を理解する必要があるため、最初は機能の実装に時間がかかる場合があります。 全体的なアーキテクチャ設計（アプリケーションのバックボーンをクレーティングする）はこのマントラに実際には適合しません（ただし、全体的なアーキテクチャを開発/変更することはユーザーストーリーの一部であると主張する人もいます） ユーザーストーリーを垂直にスライスすることのその他の欠点は何ですか？ 注：この質問をする理由は、チームに「垂直方向」のストーリーを書き始めるよう説得しようとするためであり、可能なトレードオフを事前に提示して、彼らが勝つことができるようにしたいのです。彼らが欠点に直面しているとき、アプローチを失敗とは考えないでください。

9 agile  user-story 

現在、私たちは過去1年間、独自の製品バックログを処理する5つのスクラムチームを抱えています。各チームは独自の専用システムで作業しますが、基盤となるテクノロジーは同じ.Netです。 単一のバックログから機能ベースのチームに移行することについては、多くの議論がありました。その理由は、私たちの主要なシステムの1つにかなりの量の作業があり、その年のすべての作業を実行するのに十分な容量がないためです。もう1つの重要な理由は、ポートフォリオの変化に迅速に対応できる柔軟性が高まることです。 1つのバックログで作業するように2つのチームを変更する決定が行われましたが、開発者は他のシステムでの経験がありません。私たちがしていることの1つは、エクスペリエンスシステム開発者をチームに移すことによるクロススキルです。 私の質問は、2つ以上の異なるシステムの単一のバックログへの移行を経験したことがありますか。あなたの課題は何でしたか？それを機能させるために何をする必要がありましたか？

9 agile  scrum 

最近、私は（スクラムを使用した）アジャイルプロジェクトに関与していて、各スプリントの最後にチームが開発者「MVP」とQA「MVP」を指名し、チーム。次にMVPは、小さな金銭的報酬と無料のランチ、およびトロフィーを彼の机に表示するために受け取ります。これまでのところ、この報酬システムを使用して2つのスプリントを達成しました。 これから私が見る良いことは次のとおりです： より多くのバグが修正されました（これは上級管理職が見たいものであり、彼らが望む方向への数の変化です） 各「チーム」のMVPが認識され、自尊心が高まります（または自我の高まりですか？） （少なくとも開発者の観点から）そのようなことをするのに悪い面をいくつか考えていることに気づきました。 バグ修正の品質が低下するほど、その数に非常に関心がある開発者が数人います。ある領域の修正により、別の領域で回帰が発生しています。 バグ数を増やすために、「より簡単でより速い」バグを厳選している開発者が数人います。私はここで悪いのは良いことだと思います。 より高い優先度（多くの場合、「修正するのがより困難/より長い」に関連する）の​​欠陥は、実際にはより低い優先度になります。 ブロッキングの欠陥は、通常より時間がかかり、QAとのより多くの調整を必要とするため、適時に対処されません。 開発チーム内のチームの側面が失われました。開発とQAが一体となって機能するチームの側面も改善されていませんが、以前と比べてあまり変わっていません。 バグ修正を超えて作業したり、その数に向けて作業したりすることは、簡単に認識/追跡することはできません。 私は、チームがそれぞれをどのように処理するかに応じて、上記の「悪い」のそれぞれにある程度対処できると信じています。 私の質問は、スプリントごとにMVPを認識しているこのようなものをうまく成功させた人はいますか？もしそうなら、あなたはその成功に何が貢献したと思いますか？

9 agile  scrum  teamwork  motivation 

プロトタイプのネイティブモバイルアプリ（最初はiOSとAndroid）、およびこれらのアプリが通信するためのWebベースの管理インターフェイスとAPIの開発を伴うプロジェクトに着手しようとしています。既に作成されたストーリーのリストがありますが、それらの多くは次の形式になっています。 As a mobile user I want to be able to view a login screen so that I can sign into the app これが単一のプラットフォームを対象にしている場合、問題は発生しません。ただし、複数のプラットフォームを対象としているため、これらを「Androidユーザーとして」などに複製する必要があるかどうかは不明です。これは重複のように見えますが、プラットフォームごとに個別に完了する必要がある作業です。 これは、私たちがネイティブに行った最初のモバイルプロジェクトです。以前はPhonegapで、すべてのストーリーを「モバイルユーザーとして」にまとめました。これは本質的にネイティブコードでラップされたWebベースのアプリだったので、それほど問題にはなりませんでしたが、完全にネイティブなアプリは別の球技だと私は意識しています。

9 agile  mobile  user-story 

スクラムとは何かについての議論で、アジャイルのことを完全に誤解しているのかもしれません。スクラム（確かにアジャイルプロセスと見なされます）は、TDD、ペアプログラミング、CI、リファクタリング、その他の開発者中心のテクニックやプラクティス（今まで）アジャイルの心臓部です。今、私は困難に直面しています！ 1）スクラムは、開発者がアジャイルプラクティスを行うかどうかにとらわれませんか？ 2）自動テストを利用しないチームにスクラムを実装できますか？リファクタリングを実行しないか、アジャイルプログラミングの実践に準拠していませんか？

9 agile  scrum  process 

さまざまなソースで行われた定義の例を見ると、通常、次のような点が含まれています。 コード完成 単体テストの実行 ピアレビューまたはペアリングされたコード チェックインされたコード ドキュメントが更新されました … 私たちのチームにも同様のリストがありますが、これらのポイントが非常に明白であるため、これらの手順のいずれかをスキップすることは誰にも起こらないため、誰もそれを確認することはありません。つまり、それが主にアジャイルプロセスに移行するチームのためのツールであるのか、それを取り除くだけではいけないのかと考えていました。 一方、多くの文学は、すべての高性能チームが完了の強い定義を持っていると主張しています。この種のヒントは、ここで改善する機会を逃す可能性があることを示しています。 では、成熟したチームの完了の強力な定義の例は何ですか？一般的にどのような点が含まれていますか？

9 agile  development-process 

開発されたアプリケーションの領域について、メニューから項目を削除する要求が出されました。 これは小さなことですが、スクラムでどのように扱いますか？ユーザーストーリーを使用して、機能を追加するのではなく、削除することに慣れています。 だから私の質問は、私はこれのためにユーザーストーリーを作成する必要がありますか？それとも、これに対処するより良い方法がありますか？

9 agile  scrum