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

アジャイルソフトウェア開発は、反復的かつ段階的な開発に基づくソフトウェア開発方法論のグループであり、要件とソリューションは、自己組織化された部門横断的なチーム間のコラボレーションを通じて進化します。

5
プロジェクト開始時のアジャイルメソッドとデータベース
アジャイルは初めてで、どのように始めればいいのかわかりません。アイデアは、スプリントでプロジェクトの小さな部分を作成することです。しかし、私が取り組んでいるプロジェクトにはデータベースが必要であり、データベースはプロジェクトで何でもできるようにほぼ機能している必要があります。 それでは、アジャイルプロジェクトはこれをどのように処理しますか、データベースを作成することから始めますか? たとえば、Scrumを使用している場合、ユーザーストーリーをどのように行い、データベースをテストしますか。 コードを必要とするストーリーの中で、dbの一部を実行したいですか。 「ユーザーとして登録する必要があります...」というストーリーがあるとします。このストーリーの一部としてデータベースにユーザーテーブルを作成しますか? アジャイルは、データベースの設計にどのように役立ちますか?

8
どのようにしてマネージャーにアジャイルを理解させるのですか?
反復的な開発を理解していないシニアディレクターに問題があります(アジャイルの方がずっと少ないです)。彼は、コードの行が書かれる前に、ソフトウェア設計仕様(SDS)が完全であることを主張します。彼にとって完了とは、すべての機能の詳細がそこにあることを意味します。また、元Cobolプログラマーである彼は、「モジュール」とフローチャートを見たいと考えています。これは大声で叫ぶためのJava Webアプリです! とにかく、コーディングを開始する前にSDSを100%完全にする必要はないことを示すために、彼を優しく指す簡単な場所を見つけようとしています。助言がありますか? ありがとう!

9
コードレビュー、利点は何ですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私のチームでは、正式なコードレビューは行いません。ペアプログラミングと回転ペアで十分であると考える傾向があります。 正式なコードレビューを検討する必要がありますか?利点は何でしょうか?

4
1週間のリリースサイクル:これを実現するにはどうすればよいですか?
私の会社(3年前のWeb業界の新興企業)では、製品チームに「これは危機的なパッチになりました!」と頻繁に問題があります。(皆ではありませんか?) これは、自己完結したエンジニアリングスタッフの生産性(および士気)に影響を与えます。経営陣は、これらの同日リクエストの頻度を減らす方法について考えることに時間を費やし、毎週リリースするソリューションを考え出しました。(以前は2週間に1回行っていましたが、通常は数日ほどずれていました。) 13人の開発者と6人のローカル/ 9人のオフショアテスターがいます。理論的には、他の開発者のいずれかから特定の専門知識を実際に必要とする作業が発生しない限り、4人の開発者(およびすべてのテスター)だけが偶数番号のリリースで作業します。各サイクルには、2日間の開発作業と2日間のQA作業が含まれます(さらに1日間のスコーピング/トリアージ/ ...)。 私の質問は: (a)このリリース期間の長さを経験した人はいますか? (b)このようなリリースサイクルが試みられていることを誰かが聞いたことがありますか? (c)(a)または(b)の場合、地球上でどのように機能させますか?(避けるべき落とし穴なども歓迎します。) (d)この取り組みが失敗した場合、どのように損害を最小限に抑えることができますか?

6
すぐにリリースされる機能を本番リリースに1週間おきにのみ含めるにはどうすればよいですか?
私はかなり大規模なアジャイルチームのソフトウェア開発者です(8人の開発者が1つのコードリポジトリに積極的に変更を加えています)。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。 新しいタスクを開始するとき、開発者はメインの開発ブランチ(gitを使用)から「機能ブランチ」を作成し、この新しいブランチで作業します 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します 開発者は、開発ブランチをQAブランチにマージします。 QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。 テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。 これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。 この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。 1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか?

7
アジャイルのバージョンが機能していません。チップ?
私は4人の開発者から成る小さなチームで働いています。私たちは、毎週同じ問題を継続的に提供していると思われるアジャイルのバージョンを実装しています。プロセスの改善に役立つ提案を探しています。 背景: 通常、2週間のスプリントを行いますが、各スプリントは作業を過小評価する傾向があり、スケジュールが遅れているため、マネージャーとトラブルを起こします。 私たちは、マネージャーが私たちのために作成したストーリーをタスクアウトすることで、各スプリントを開始します。時々彼もタスクを投入し、それらを推定します。ストーリーポイントは使用しません。ソフトウェアUrban Turtleを使用して、「スプリントを管理」します。これは、基本的に単なるストーリーとタスクであり、関連するバーンダウンです。スプリントの終わりにリリースする予定はありません。 発生する最も一般的な問題は、スプリントの開始時にタスクを計画することです。これは、スコープがはるかに大きいが優先度が高いことを発見するためだけであるため、さらに時間をかける必要があります。2番目に一般的な問題は、私たちの1人が技術的な問題に遭遇し、それが燃焼時間を遅らせ、障害を引き起こすことです。 私たちに提供された唯一の提案は、午前中のスタンドアップ中に予測を調整し、更新を提供することにより積極的になり、必要な余分な時間に調整できるようにすることです。 しかし、私たちが物事をしている方法には根本的に間違った何かがあるようです。おそらく、プロジェクトレベルでのマネージャーの期待とスプリントレベルでの期待との間には断絶があるでしょう。プロジェクト計画に従ってこれらのスプリントの反復を行っているため、スプリントを延長したりアイテムを延期したりすると、プロジェクト計画が台無しになります。そのため、開発者として、必要に応じて見積もりを延長することでアジャイルを実行することをお勧めしますが、スプリントを時間通りに完了させることは混乱を招きます。 これはめったにない問題ではないので、スプリントごとにこの同じ問題にぶつかるのをやめる方法について、提案が1つまたは2つあるよりも賢明なことを望んでいます。イライラします。
12 agile 

4
単一のアジャイル作業項目内の「関連」作業の処理
私は4人の開発者のプロジェクトチームに所属しています。単一の作業項目で発生する余分な作業を処理する方法については、長い間議論を重ねてきました。 この余分な作業は通常、タスクにわずかに関連するものですが、アイテムの目標を達成するために必ずしも必要なわけではありません(意見かもしれません)。例には以下が含まれますが、これらに限定されません。 ワークアイテムによって変更されたコードのリファクタリング アイテムによって変更されたコードに隣接するコードのリファクタリング チケット周辺のより大きなコード領域を再構築します。たとえば、アイテムで単一の関数を変更した場合、クラス全体を再実行してこの変更により適切に対応できるようになることに気付きます。 変更したフォームのUIを改善する この余分な作業が小さい場合は問題ありません。問題は、この追加作業により、元の特徴点の推定を超えてアイテムが大幅に拡張されることです。5ポイントのアイテムは実際には13ポイントかかる場合があります。あるケースでは、振り返ってみると80ポイント以上であった13ポイントのアイテムがありました。 これをどのように処理するかについての議論では、2つの方法が考えられます。 同じ作業項目で余分な作業を受け入れ、誤推定としてそれを書き留めることができます。これに関する議論は次のとおりです。 この種のことを考慮して、スプリントの最後に「パディング」を計画しています。 常にコードを見つけたときよりも良い形にしてください。中途半端な作業をチェックインしないでください。 リファクタリングを後で行う場合、スケジュールを立てることが難しく、完了しない可能性があります。 あなたはすでにコードの奥深くにいるので、あなたは今この仕事を処理するのに最高の精神的な「状況」にいます。後で戻ってきたときにそのコンテキストを失うよりも、今それを邪魔にならないようにして効率的にする方が良いでしょう。 現在の作業項目に線を引き、追加の作業は別のチケットになると言います。引数は次のとおりです。 個別のチケットがあると、新しい見積もりが可能になるため、実際のポイント数について自分自身に嘘をついたり、見積もりの​​すべてがひどいことを認めたりする必要はありません。 スプリントの「パディング」は、チケット要件を完了するための直接的な障壁である予期しない技術的な課題のためのものです。これは、「便利な」だけの副次的なアイテムを対象としたものではありません。 リファクタリングをスケジュールする場合は、バックログの先頭に配置してください。 それが出てきたときにいくぶん恣意的であるように思われるので、私たちが推定においてこのことを適切に説明する方法はありません。コードレビューアは、「これらのUIコントロール(実際にはこの作業項目で変更しなかったもの)は少し混乱します。それも修正できますか?」これは1時間のようですが、「このコントロールが他のコントロールと同じ基本クラスから継承するようになった場合は、この(数百行の)コードをすべてベースに移動して、これらすべてを再配線しないでください。 、カスケード変更など?」そして、それは一週間かかります。 これは無関係な作業をチケットに追加することで「犯罪現場を汚染」し、元の特徴点推定を無意味にします。 場合によっては、余分な作業がチェックインを延期し、開発者間のブロッキングを引き起こします。 追加のものが2 FP未満の場合は同じチケットに入れられ、それ以上の場合は新しいチケットにするなど、一部の人はカットオフを決定する必要があると今言っています。 私たちはアジャイルを使用して数ヶ月しか経っていないので、これをどのように処理するかについて、この辺りの経験豊富なアジャイル退役軍人の意見は何ですか?

5
ストーリーポイントで個々の能力を考慮する必要がありますか?
ストーリーの推定についての私の理解では、法律の「合理的な傍観者」の概念に少し似た、想像上の平均的な開発者の場合のように、ストーリーのサイズを推定する必要があります。つまり、ストーリーのサイズを推定するべきではありません。 例を挙げると、以前の仕事で、私はチームの一部であり、最も自信のあるRuby開発者でした。私のチームメイトは、「XがRubyでどのように機能するかわからないので、何年もかかるだろう」というような議論をして、Ruby関連のストーリーを私よりはるかに大きく見積もっています。 これに対する私の議論は、スプリント計画がチームの能力の出番であるという事実から来ています。これが正しいフォーラムです。「タスクの大半はRubyベースであり、強力なRuby開発者は1人しかいないため、このスプリントの能力は通常よりもわずかに低くなります。」推定中にこれを考慮すると、この側面が倍になります。 回答に権威ある参考文献があれば感謝しますが、単純な意見も素晴らしいでしょう。
11 agile  estimation 

6
スクラム-スプリント外で作業する開発者
スクラムチーム 3 x開発者 2 xテスター 1 x自動化テストアナリスト 開発者がテストせず、テスターが開発しないという点で、私たちは多機能チームではありません。これが問題の根本原因だと思います。 現在、2週間のスプリントを行っています。 スプリントの開始時には誰もが忙しく、開発者は開発作業を開始し、テスターはテストの準備(テストケースの作成など)を行っています。 テスターが準備を完了すると、開発作業が完了するのを待っているか、開発作業が完了して開発者がフィードバック/バグを待っています。 開発者はここでitい足を踏み入れ、現在のスプリントの範囲外にあるバックログのアイテムの作業を開始します。これにより、現在のスプリントで常に次のスプリントを開発するという奇妙な影響が生まれています。私にはこれは正しくないと思う。 経営者の観点からは、彼らは開発者が机に座って何もしないよりはむしろ仕事をすることを望んでいますが、同時に、スクラムチームの目標と焦点は現在のスプリントのみにあるべきだと感じています。私たちのチームが多機能であることを願っていますが、残念ながらそれは達成できません。テスターに​​は開発作業を行うのに必要なスキルがなく、開発者の大多数はテストが彼らの下にあるという意見を持っています。 これはスクラムの問題と見なされますか?これに対する解決策はありますか?スクラムは多機能チームでのみ機能しますか? 可能であれば、これに関する他の人々の経験を知りたいです:)
11 agile  scrum 

9
スクラムチームのインプットは何ですか?
スクラムチームは、通常のスクラムの役割で構成されています。UI / UXデザイナーはおらず、開発者は製品所有者とUI / UXを操作します。ここに問題があります。バックログを作成しようとするたびに、スプリントの開始前に正確なUI / UXデザインを定義していないため、スプリント中にUI / UXデザインを完成させようとして時間がかかりすぎます。 これは、機能の分析とアーキテクチャにも当てはまります。機能に関するすべての可能な詳細は、スプリントの開始前に開発者に提供されるべきか、それとも機能内のタスクであると考えますか?私たちはこれを経験しており、基準を持たないいくつかの未定義の機能をもたらします。
11 agile  scrum 

5
「テクニカルユーザーストーリー」はスクラムで許可されていますか?
技術的なユーザーストーリーはスクラムで許可されていますか?もしそうなら、技術的なユーザーストーリーをスクラムで書くための標準テンプレートは何ですか?同じAs a <user> I want to do <task> so that I can <goal>ですか? 私はいくつかのブログでas-a- de -veloper-is-not-a-user-storyを読んだことがありますが、スクラムはこれらを義務付けていないことも読んでいます。彼らは共有しているいくつかのブログがあるユーザーとしてシステムにユーザーストーリーを、そのようにas a <user who is not end user> i want to <system functionality> so that <some techinical thing>。それで、どれが標準ですか? たとえば、次のようなユーザーストーリーがあります。 レビュー担当者として、ホテルや食べ物の写真をアップロードして、他のユーザーが見たり気に入ったりできるようにします ユーザーとして、写真のコメントを追加して、自分の意見をよりよく説明できるようにします これら両方のユーザーストーリーには、大きな技術項目があります-画像の保存と取得 次の説明とともに、「画像の保存と取得のメカニズム」というタイトルの技術的なストーリーを追加できますか? 開発者として、ユーザーが必要に応じて画像を追加/表示できるように、画像を保存および取得するメカニズムを開発したい

5
各スプリントの開始時の早期サブタスク
アジャイル/スクラムを使用している新しいチームに参加しました。開発プロセスは次のとおりです。 1)開発者は各スプリントの前に各ストーリーを確認し、重要なことを見逃さないようにします。ワークフローにはそのための正式な状態があります。 2)スプリントのキックオフ中に、チーム全体が各ストーリーにかかるストーリーポイント数の見積もり(ポーカープランニング)を行います。 3)最後に、各スプリントが開始された直後に、各開発者は割り当てられたすべてのストーリーを、各ストーリーを開始する前のサブタスクとは対照的に、時間の見積もりとともにサブタスクに熱心に分解する必要があります。 最後のステップの主な論点は、ストーリーの実装に予想よりも時間がかかるかどうかを発見し、スクラムマスターにスプリント期限の欠落の潜在的なリスクについて警告することです。 しかし、主に次の理由により、この逆効果になります。 目的が大まかな見積もりを提供することである場合、ストーリーポイント(ステップ#2)は仕事をするものです。それ以外の場合、なぜストーリーポイントに悩まされるのでしょうか?-早めにサブタスクを実行します。 目的が正確な推定値を提供することである場合、これは有害と見なされるヒューマンタスクスイッチで説明されている内容の明確な例です。これは、特に、大規模プロジェクトで既存のチームに参加し、何をする必要があるかを理解するのに最大50%の時間がかかる新​​しい開発者の場合に当てはまると思います。ストーリー#1、次にストーリー#2、#3などの詳細を取得する必要があります。これにより、大量の情報が大量に生成されます。 また、そのような慣行は「本による」と言われていますが、これについて議論するつもりはありません。誰でもそのような実践への参照を提供できますか?これがスクラム聖書で明確に定義されているかどうか、および/または多分余分な洞察を提供しますか?
11 agile  scrum 

2
「クリーンコード」の実践は本当にクリーンで便利ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は現在、大企業でインターンシップを行っており、ソフトウェア配信構造の多くの変更を受けています(アジャイルに移行)。 過去数ヶ月で、私はこの宗教的なClean Code慣習への執着と 、開発者にとって聖書のような本であることに気付きました。 さて、クリーンなコードの最も重要な機能の1つは、わかりやすい名前付けと厳密なリファクタリングに基づいた自明のコードです。これにはno commentingルールが続きます。 このクリーンなコードは、コードの保守と改善を容易にする長期的な投資であることを理解していますが、...これは本当に大騒ぎに値するのでしょうか? Clean Codeでの経験や、私があまりにも保守的すぎるのか、それとも一時的な傾向であるのか、誰でも意見を共有できますか。

6
スクラムスプリントの追加の美容機能をどのように処理する必要がありますか?
私はスクラム文書を読んでいて、スプリントのタスクは「潜在的に出荷可能」でなければならないと言っています。 これが何を意味するのか混乱しています。Sprint 1の目標が「ユーザー登録フォーム」だったとします。 何かを出荷する準備をするために、どのくらい詳細を追加する必要がありますか?例えば: 派手なスタイリングなしでフィールドを持つシンプルなフォームを表示し、完了マークを付けることができます 完了マークとしてクライアント側の検証を行うことができますが、サーバー側もオプションまたは両方です また、jQueryの便利なツールヒント、ホバーオーバー、キャプチャ、色、フォームのラベルを追加することもできます。 次に、画面にエラーメッセージを表示する方法についてのスタイリングがたくさんあります 私は1つのトピックで無限に行うことができます。それで、それをどのように分割し、私はそれを出荷準備完了と考えることができます。 または、エラー、ポップアップ、またはライトボックステキストをサブタスクとして表示し、それらをスプリントとして配置するなど、できるだけ小さいものをそれぞれ記述する必要がありますか。これにより、プロジェクト全体で数千のタスクが発生します。 Internet Explorerで動作するものとFirefoxで動作するものがあれば、それらをタスクとして分割する必要があります。それらに時間を費やす必要があり、その時間にマネージャーがあなたに何をしたかを尋ねられたとき、私は伝えるべきタスクはありませんが、実際にはそれらはすべてユーザー登録の一部です

7
物理的なアジャイルボードは「常に」電子ツールよりも優れていますか?
どのアジャイルツールを使用するかについての質問が出てくるたびに、「チームの会話をより良く生成する大きな目に見えるボードの利点を失うため、電子ツールを使用しないでください」と答える人が常にいます。 これは常に当てはまるのですか、それとも電子ツールがより良い選択である状況はありますか?各アプローチの長所と短所は何ですか?
11 agile  tools 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.