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

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

7
チームを通じて能力をどのように配分すべきですか?
これを読んだ後、さまざまな能力を持つ開発者のグループ(別名ほとんどすべてのチーム)内でアジャイルチームをどのように構成すべきかについて、多くの意見の相違があるように見えました。優秀な開発者全員を自分のチームに配置し、最も優先度の高い仕事を与えるべきですか?これにより、最も重要なタスクが確実に実行されます。同時に、優先度の低いタスクのみに関係する場合でも、技術的負債を抱える「完璧ではない」チームが残ります。一方、均等に分散されたチームは、遅れている開発者を少し良くする利点がありますが、最も重い打者をやる気にさせる可能性があります。また、一連の優れたデザインパターンとひどいアンチパターンを組み合わせると、最終的にはアンチパターンの束になる可能性があります。
9 agile  team  teamwork 

7
スクラムプロジェクトのUXは誰ですか?
OK。あなたが教科書スクラムプロジェクトに取り組んでいるとしましょう。あなたは、製品所有者と協力しているスクラムマスターを手に入れました。次のスプリントはUIが重いです。コーダーが画面の作成を開始する頃には、実際に彼らがどのように見えるかを考えている必要があります。 誰がいつワイヤーフレーミングを行うのですか?製品のオーナーは?製品の所有者をサポートしている人はいますか?スクラムマスター?UXのエキスパートがいる場合、スプリントの開始後にコーダーと一緒に作業しますか、それともストーリーカードと制約のそばに座って、開発者が行っている作業をガイドして通知するワイヤーフレームとモックアップを事前に提供しますか? UXのヘルプが必要だと思いますが、どこに適用すればいいのか本当にわかりません... 編集:質問を言い換えましょう。 アジャイルプロジェクトで一貫した高品質のユーザーエクスペリエンスをどのように提供しますか?

2
スクラムでストーリーポイントを推定する最良の方法は何ですか?
プロジェクトの最初にポーカーの計画を立てる方法が好きです。各ストーリーの詳細を互いに比較して話し合うことができます。 私がこれで気付いた問題の1つは、時間の経過とともに問題ドメインでより多くの経験を積むにつれて、各ストーリー(つまり、最初は5または8の価値があったストーリー)に投票するポイントが少なくなるということですプロジェクトの今の価値があるかもしれません3。 この問題を可能な限り最善の方法で回避または対処するにはどうすればよいですか?推定するより良い方法はありますか?ストーリーは常に同じである必要がありますか、それともこのストーリーポイントは減少しますか?

3
滝に焦点を当てた人々にアジャイルプロジェクトを表す方法[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私たちのチームは、私たちの開発努力をプロジェクト計画に表すよう求められました。私たちの仕事に不満を抱いたり、提供能力に疑問を投げかけたりする人はいません。プロジェクト計画のIT牛募集に参加しているだけです。問題は、私たちがアジャイルチームであり、正式なプロジェクト計画の観点から私たちの仕事について考えたことがないことです。 私たちは次に何をしているのかについての一般的な考えを持っていますが、反復を計画するまで100%確信が持てません。これまでのところ、私たちのチームは大部分が孤立していて、私たちの方法論や測定基準を外部の関係者に提示する必要はありませんでした。私たちは、エクストリームプログラミングで採用されているほとんどのプラクティスに従います。 四半期ごとに計画する会議を開催して、四半期に向けて取り組むストーリーの概要を把握します。とは言っても、私たちのストーリーは3x5カードで文書化されており、それらが機能するイテレーションの開始時にのみ推定されます。見積もりの​​後、そのストーリーをTeam Foundation Severに文書化します。イテレーション中、ストーリーにコードを添付し、ストーリーが完了したらストーリーに完了のマークを付けます。このデータから、バーンダウンチャートと速度チャートを生成できます。最も重要なのは、反復の平均速度がわかっているため、噛む以上に噛み付かないようにすることです。 私は開発方法を変更するつもりはありませんが、ウォーターフォールに精通している人だけが理解できるレポートで開発活動を紹介したいと思います。ではアジャイルプロジェクト計画のように見えるが何をするか、ケントマクドナルドはアジャイルとウォーターフォールプロジェクト計画との違いをレイアウトする良い仕事をしていません。彼は消耗品の弾丸の違いを明記しています: アジャイルプロジェクト計画は機能ベースです アジャイルプロジェクト計画は反復に編成されます アジャイルプロジェクト計画には、時間枠に応じて詳細レベルが異なります アジャイルプロジェクト計画はチームが所有しています 違いを説明できるのは素晴らしいことですが、データを提示するにはどうすればよいでしょうか。

3
非常に短いプロジェクトのスクラム?
私はスクラムを使用していて、本当に気に入っています。ただし、私のショップは、開発作業の期間が2週間または4週間のプロジェクトに含まれています。私たちはすでにスプリントの長さを2週間に変更しました。ここの誰もが「それは1つ半のスプリントがあれば、スクラムになるでしょう」と言っています。 1年半のスプリントから多くの価値を得ることができるとは思いません。1回、2回、または1.5回の反復のみで反復的な開発プロセスの利点を得るにはどうすればよいでしょうか。

4
アジャイル開発のためのオフィス設計とレイアウト
(stackoverflowから移動) どのキーボード、デスク、明るい背景、または色付きの背景が最適であるかについて、ここで多くの議論を見つけましたが、オフィス全体のレイアウトに対応するものを見つけることができません。 私たちは約20人の従業員がもっと大きな新しい場所に引っ越す会社です。ここでは2つの主要な開発プラクティスが定期的に行われています。バックエンドの人々は、モバイルサービスの人々と協力してWebサービスを手配する必要があることがよくあります。バックエンドの人はモバイルの人の約2倍です。バックエンド開発者の約半分はいつでもオンサイトで作業しており、一度にすべてがオフィスにいることはほとんどありませんが、少なくとも5〜10のスペースを用意する必要があるため、ほとんどの場合、2つのグループはほぼ同じです。 デスク、間仕切り、そして場合によっては壁を配置して、スペースを改善する機会があります。ケータリングやマッサージのようなドットコムのフリルには現金はありませんが、長い列にたくさんの机が並ぶのを避ける計画を立てるべき時です。 Joel on SoftwareのBionic Officeは、私が昔から覚えている記事であり、いくつかの優れたアイデアがありますが、私*(さらに重要なことには、会社の所有者)は、私たちが協力しているはずの環境でのプライバシーのアイデアについて完全に販売されていません。これは、もう1つのすばらしいリンクです。究極のソフトウェア開発オフィスのレイアウトです。これを読むまで、囲われた会議室さえ覚えていませんでした。 プライベートオフィスはアジャイル開発の邪魔をしていますか?スクラムは十分な強制接触であり、誰かをバグにする必要がある場合、立ち上がってドアをノックする必要がありますか? どのデザインレイアウトを指すことができ、なぜそれらを推奨するのですか? *私は閉鎖されたオフィスにまったく反対していませんが、他の解決策も同様に実行できれば幸いです。それができない場合は、まあ、それがこの質問のすべてです。 2つの更新-2013年4月。 最初の移動は、「ファンキー」なオフィスへの移動でした。基本的には開いていますが、壁が1枚カーペット、床が半分カーペット、床が半分研磨されたコンクリートなどの奇妙な特徴があります。コンクリートの上に座っている誰もがカーペットの上にいたかったのです。それは問題ないように見えましたが、実際には私はオフィスの半分だけをカーペットに敷くことはお勧めしません。寒さを感じた人々は本当にそれを嫌っていました。スタンドアップではそれは問題ありませんでした-巨大なホワイトボードが1つの壁を占め、話したり、飛び出したりするのに十分なスペースがありました。 それから、コラボレーション、デザイン、電話、保守、および物理的なものの設置をすべて担当する別の会社(同じ所有者)が混在する非常に混雑した場所に移動しました。それは吸いました。それから私たちは新しい建物に引っ越しました、そして誰かが倉庫/産業がクールであると決めました。ガラスと磨かれたコンクリートの至る所に硬い表面。最も交通量の多いエリアの真ん中にある簡易キッチンと食器洗い機のすぐ隣にある1つの大きなテーブルを共有している開発者。電話で一日中過ごした人々の隣。それは吸音し、吸音パネルのような絆創膏にもかかわらず吸い続けました。ボードやスタンドアップ用に設計されたスペースがなく、その場所の音響特性により、ガチャガチャを超える人の声が非常に聞こえにくくなり、その感覚だけでなく、アジャイルに夢中になりました。大聖堂で叫んでいる静かな瞬間。誰も不満を聞いたことがありません。私は辞め、他の何人かをやめました。ああ、「製品の所有者」だと主張した人が面倒を見るのをやめたことは助けにはならなかった。

5
あなたのアジャイル/スクラムチームのバグワークフローは何ですか?
あなたのアジャイル/スクラムチームのバグワークフローは何ですか? これが私たちのものです:-バグが現在のスプリントのストーリーに関連している場合、それを修正します。-バグが現在のスプリントのストーリーに関連しておらず、重大でない場合は、優先順位付けのために製品オーナーに送信されます。-バグがスプリントのストーリーに関連しておらず、重大な場合は、修正します。
9 agile  bug  scrum  workflows 

5
成功したユーザーストーリーの完了数に応じてスクラムメンバーを評価することは正しいですか?
私のマネージャーがチームに「今から成功したユーザーストーリーは評価の対象となるでしょう!」 と言ったとき 私たちはショックを受けてそこに座っていましたが、それは彼が私たちに与えたいくつかのあごを落とす瞬間の1つでした:-) これはアジャイル開発方法論のすべての概念と目標を台無しにするので、それは愚かな考えだと感じました。 みなさんの考えを教えてください。そして、どうすれば彼を説得できますか?


2
これは基本的な数独ゲームのユーザーストーリーとしてカウントされますか?
私は、アジャイルソフトウェア開発アプローチを使用して、基本的な数独ゲームのユーザーストーリーを作成しようとしています。 ユーザーストーリーの背後にある概念を理解しましたが、理解を深めるための例を得ることができるのかと思っていました。 言うでしょう 私は数独の熱心なプレイヤーとして、さまざまな難易度で複数のレベルを持ちたいと思っています。 新しいプレーヤーとして、私は基本を教えてくれるゲームの紹介レベルが欲しいです。 ユーザーストーリーとしてカウントしますか?

4
アジャイルチームのすべてのメンバーはソフトウェア開発者である必要がありますか?
私は最近、会社でアジャイル手法を使い始めました。私はアジャイルにかなり慣れていないので、アジャイルの基本原則に従って、実装方法が正しいかどうか疑問に思います。 以前は、ビジネスアナリスト、QAテスター、ソフトウェア開発者などの役割がありました。しかし現在、経営陣はこれらの役割を削除する必要があると決定し、誰もがソフトウェア開発者として働くことになります。 実際には、これは、1人のソフトウェア開発者が以前に3つの別々の役割(つまり、1人のビジネスアナリスト、1人のQAテスター、および1人のソフトウェア開発者)と同じ責任を持つことを意味します。 彼らはこれがアジャイルであるという事実で変更を正当化します。これは他の企業もアジャイルを実装する方法ですか?

5
タスクを自動化した後、反復タスクのストーリーポイントのサイズは変わりますか?
スクラムの状況は次のとおりです。 特定のタスク(バックエンドのデータテーブルの実装)は頻繁に発生します 多くの場合、テーブルには類似しているがカスタム機能があります 各テーブルの実装には約1週間かかります(8ストーリーポイント) 最終的に、チームは4週間かけて再利用可能なコンポーネントを作成します 新しいテーブルの作成はほぼ瞬時に 私の質問: 出力/複雑度が変更されていないため、新しいテーブルストーリーはまだ8ですか?それとも、労力が最小限なので1ですか? 私の研究:ジェフサザーランドとスクラムトレーニングを受けたとき、ストーリーポイントは出力を測定するため、ストーリーはまだ8であるという理解を残しました。PMはまだ同じテーブルを取得していますが、5倍速く配信されています。それは本当の速度の改善です(同じ作業を行うがより高速) しかし、私の理解が正しいことを確認したいと思います。何か助けはありますか?正式なスクラムの定義を探しています。私はscrum incのサイトを調査し、「半分の時間で2倍の作業を行うアート」を試してみましたが、私の理解が正しいか間違っているかを示すドキュメントが見つかりません。 ありがとうございました! 更新 私は本当に正式なスクラム当局による文書へのリンクを探していました。以下の答えの多くは単なる人々の意見なので、この質問は誤解を招くと思います。

2
アジャイルユーザーストーリーの共有開発タスク
私のチームは、次のプロジェクトでVisual Studio Team Servicesを使用します。アジャイルツールを使用すると、次のようにユーザーストーリーとタスクを階層的に整理できます。 エピック>機能>ユーザーストーリー>タスク/バグ 高校生とアドバイザーのためのStudent Org(クラブ)管理システムを設計しているとしましょう。学生とアドバイザーはクラブに参加したり、役員になったり、イベントを企画したり、お知らせを送信したりできます。 アナウンス機能を例に見てみましょう: ユーザーストーリー: 学生として、自分が所属しているクラブのお知らせを読んで、スケジュールの変更を認識したいと思っています。 アドバイザーとして、自分が所属しているクラブの告知を読んで、スケジュールの変更を認識したいと思っています。 アドバイザーとして、所属するクラブに通知を送信して、生徒がスケジュールの変更を認識できるようにしたい 管理者として、すべての学校のクラブにアナウンスを送信して、スケジュールの矛盾を認識させることができます。 等 これらが適切に記述されたユーザーストーリー(そうではない可能性があります)であると想定すると、開発チームとこれらの項目を開発タスクに分割するために座るときに混乱します。複数のユーザーストーリーの一部を単一の開発タスクでカバーできます。たとえば、お知らせのプロパティを定義するだけで、UIからDBまでのすべてのレイヤーのCRUDアクションを生成するツールがあります。したがって、いくつかの「送信」および「読み取り」ユーザーストーリーの部分は、単一の開発ステップで完了します。 私が読んだことから、各ユーザーストーリーは他のユーザーストーリーから独立している必要があり、それは理にかなっています。ただし、ユーザーストーリーのそれぞれが「UIとDBを生成する」タスクを共有しています。これは、この方法で(カスタマイズする前に)ベ​​ースレベルのUIを作成するためです。ユーザーストーリーごとに「UIとDBを生成する」タスクを書くべきではありません。冗長性が高すぎます。しかし、ユーザーストーリーを開始する前に完了する必要がある「UIとDBを生成する」タスクの記述方法がわかりません。 私の許可システムにも同様の混乱があります。Student、Adviser、Adminなどのさまざまなアカウントタイプがあり、すべて[お知らせ]ページにアクセスできますが、ページ内の機能は異なります(このアイデアは上記のユーザーストーリーでキャプチャしました)。アクセス許可システムを他の機能で使用できるようにモジュール化することもできますが、「モジュール化されたアクセス許可システム」を作成するタスクをどこに書き込むかわかりません。 このユーザーストーリー全体が混乱しているようです。はい、それはシステムの機能をキャプチャするのに最適ですが、開発タスクを通して考えるとなると、私はそれに頭を抱えているようには見えません。どんなアドバイスでもいいでしょう。 TL; DR:あるユーザーストーリーで行うプログラミングの一部は、他のユーザーストーリー(アクセス許可システムなど)のプロジェクトの他の場所で使用できます。この可能性を説明するために、ユーザーストーリーのタスクを作成/整理するにはどうすればよいですか?

2
「進化的ソフトウェアアーキテクチャ」は矛盾ですか?
私の理解では、進化的アーキテクチャは、アーキテクチャを簡単に変更できるようにすることです。現在、アーキテクチャーは多くの場合、後で変更するのが難しいため、早期に正しく取得する必要があるものとして定義されています。 これはどのように組み合わされますか?進化的アーキテクチャとアーキテクチャの量を最小限に抑えることの間に違いはありますか?

5
かんばんを使用する場合、チームはいつ要件について話し合いますか?
私はかんばんについて少し読んでいますが、要件のトピックについて少し混乱しています。 現在のプロジェクトでは、スクラムを使用しています。スプリントの最初に、BAがストーリーのウォークスルーを行い、彼女ができる限りそれを説明するセッションがあります。次に、その話を取り、レビューし、話し合い、BAに次のスプリント計画セッションのための質問を準備します。次のセッションでは、BAがすべての質問に答え、セッションは要件を理解した(ほとんどの場合)ことで終了します。 次のステップは、技術設計を作成し、ソリューション/ストーリーを開発することです。 かんばんに関​​して、私が読んだすべては、かんばんにはスプリント計画がないことを示唆しています。私の質問は、技術の要員とビジネスマンが一緒に座って(カンバンで)ストーリーの要件について話し合うときですか?プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供しませんか? スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はどのようにストーリーを理解するのかはわかりません。

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