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

私は最近、仲間の開発者とアジャイルソフトウェア開発について話し合いました。私はその原則を理解していますが、要件が絶えず変化することで、プロジェクトが永遠に続く可能性が生まれるようです。しかし、少なくとも私が働いている場所では、プロジェクトは契約であるため、完成する必要があります。 つまり、一部のプロジェクトでは顧客が不完全なアプリケーションを使用できないため、最初の反復には数か月かかる場合があります。一部のプロジェクトでは、最初に終了を定義する必要があり、それを反復に分割し、各反復後に定義を改良する必要があると思います。ただし、常にこの定義が必要です。 アジャイルソフトウェア開発が要件の変化を受け入れる場合、それがどこで終わるのかをどのように知るのですか 最終結果が常に変化する場合、どのようにプロジェクトの予算を立てることができますか？ アジャイルソフトウェア開発は、アジャイル製品というよりもアジャイルプロセスに関するものですか？

14 agile 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は最近、協同組合（有給インターンシップ）のインタビューを行っていますが、インタビューを行っている多くの企業は、スクラムやその他のアジャイル手法を使用していると言っています（スクラムが最も人気があります）。本当のアジャイルショップがあり、アジャイル手法を使用しているが、何か他のことをやっていて、アジャイルを流行語として使用していると言う場所があることを知っています。 私の質問は、これらの店を区別するインタビューで尋ねることができる質問は何ですか？ 編集：私はインターンシップを探していますが、これらの質問はすべての人に関係があると感じています。インターンシップの部分はコンテキストです。

14 agile  scrum 

私はいくつかの良いプロジェクトを導入する請負業者のために働いてきましたが、それらはすべて固定価格であり、しばしば固定時間です。 その結果、彼は常に緩い要件を引用してくれますが、機能のクリープにより大きな緊張をもたらすことはありません。 彼は最初にクライアントと価格について合意できなかった場合、彼は契約を決して得ないと主張しますが、私が懸念している限り、私はこれらの条件の下で別のプロジェクトをやりたくありません。 彼に時間単位で支払いをしてもらうために私が作ることができる議論はありますか、または私は推定であまり吸うべきではありませんか？

14 project-management  agile  freelancing 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私の現在の仕事では、要件の変更がたくさんあるように感じます。私たちは「アジャイル」ショップですので、私たちは調整することになっていると思いますが、時には変化は大きく、些細なことではありません。 私の質問は、変化のコストをどのように効果的に伝えるかです。アジャイルであるため、変更が十分に大きい場合、現在のスプリントから何かがドロップされますが、通常は次回に追加されます。私たちのモデルはSaaSであるため、最終顧客は事実上ビジネスそのものであり、彼らはn週間後にカット機能を取得することを知っています。 私は本当にそれだけ遅れたとして、通信に使用するものではありません、私は機能の除去である時に取得しようとしていますどのような推測のn週間。変更にかかるコストをビジネスに理解させるには、他にどのような方法が必要ですか？

14 development-process  agile 

私は最近、会社に入社して、Webアプリを構築するアジャイル開発プロジェクトのスクラムマスターとして働いています。 このチームは、アジャイルチームの最大規模になりそうです（来週は9を予定）。チームを2つのチームに分割する可能性について話しましたが、スタンドアップを短くすること（現時点では過度ではありません）ではなく、スプリントプランニングセッションで人々が完全に退屈しないようにすること（これもあまり長くありません）。 このプロジェクトには、高度に技術的なバックエンド開発者（非常に複雑なものなど）とUIの設計/構築/統合という2つの非常に明確な層があります。バックエンドの人たちが技術的なことを話しているとき、UIの人たちはゾーンアウトしているようです。時間を効率化するためだけにチームを分割する論理的な方法のように思えますが、コラボレーションと知識の共有を減らすことしかできないという点で、私は1つの大きな予約を持っています。2つのチームは、チームの他のメンバーが何を構築しているのかについて本当に良い考えを持っていません。 誰かがこのようなものに対処した経験がありますか？

14 web-development  project-management  agile  web-applications  user-experience 

私はExtreme Programming Explained、Second Editionを読み、第11章「制約の理論」で著者は古くて時代遅れの「プッシュ」開発モデルとXPの方法、「プル」開発モデルについて話しています。それは非常に重要な概念のように見えますが、非常に小さなパラグラフと、「滝」と反復プロセスの単なるイラストである2つの画像のみを必要とします。私は検索しましたが、本の残りの部分ではそれについてこれ以上説明しません。それについてのさらなる説明や議論もインターネットで見つけることができませんでした。 それらについての唯一の違いが、一方が「ウォーターフォール」であり、もう一方が反復的である場合、それらはなぜプッシュし、なぜプルするのでしょうか？ 誰が本当にこれら2つの違いが何であるかを理解し、いくつかの良い例を挙げていますか？

14 agile  development-process  extreme-programming 

いくつかの背景情報 私は社内のソフトウェア開発チームの一員です。で構成されます 5人の開発者（2〜5年の経験があり、私もその1人です） 3人の実装スタッフ（ソフトウェアの展開とトレーニングを行います） および1人のプロジェクトマネージャー。 多くの小規模から中規模のプロジェクトを開発しており、それらのスケジュールは通常重複しています。開発は次のようになります。 「クライアント」は一連の初期要件を提供します 上記の仕様に合わせてシステムを開発します システムを「クライアント」に提示する 「クライアント」は、上記のプレゼンテーションに基づいて追加の要件を提供します 「クライアント」の新しい要件がなくなるか、展開の対象日が近づくまで2〜4を繰り返します システムをセットアップして展開する これは、ほとんどの場合、期限を処理する「クライアント」であるという事実（これはプログラマーとPM.SEで私が見ているものからの赤旗です）であり、明確な開発方法論に従っていませんカウボーイコーディング、メンテナンス不可能なコード、本番環境を通過するバグなどが含まれます。それが、スクラムのようなアジャイルベースの方法論を採用することを選んだ理由です。 なぜスクラムなのか？ それは私たちのマネージャーのイニシアチブであり、現在の状況を考えると誰もがそれに同意するようです。 スクラムの問題 スクラムの一部の要素は、特にアジャイル開発者の「すべての取引」という性質に簡単に対処できない現在のセットアップと競合しています。展開チームはプログラミングの方法を知らず、開発者は平均以下のコミュニケーションとトレーニングのスキルを持っています。そして、このラインナップはすぐに変わることはありません。 質問 方法論としてのスクラムの有効性に影響しますか？補償するために他の変更を行う必要がありますか？それとも、考えを完全に捨てて、別の方法論について考える方が良いでしょうか？

13 agile  scrum  methodology 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私はかつてウォーターフォールの方法論で働いていましたが、今ではアジャイルの方法論に従っているチームにいます。彼らはそれを間違っているようです。たとえば、1日25分以上続くスタンドアップがあり、これは非常に面倒です。さらに、私は他の何よりも自分の給料を経営陣に正当化しているように感じます。 このように感じるのは間違っていますか？これは通常、スタンドアップが行われている方法ですか？

13 agile  scrum  development-methodologies  meetings 

アジャイル手法を使用してアプリケーション全体を書き直さなければならないとしたら、どうしますか？ 現在のシステムの動作に基づいて、多くのユーザーストーリーを作成できると思います。そして、それらを小さな反復で実装します。しかし、これは私たちが前方に要件を持っているという意味ではないでしょうか？ また、いつリリースを開始しますか？アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

13 agile  scrum  software  extreme-programming  rewrite 

私は、管理者がペアプログラミングのアイデアを私または別のマネージャー/開発者に引き継いだいくつかのショップで働いてきましたが、まったく後れを取ることができません。開発者の観点からは、このコーディングスタイルへの移行が有益である理由を見つけることができません。また、小さなチームのマネージャーとして利益を見ることもありません。 私はそれが基本的な構文エラーに役立ち、何かをハッシュする必要がある場合に役立つことができることを理解していますが、プログラミングループの外にいるマネージャーは、デザイナーよりもFacebookやRedditに行くのを防ぐ方法としてそれを見続けているようです設計ツール。 開発フロアの近くにいる人で、明らかに私のやり方や主題に関するwikiページからはまったく理解できない...高レベルの管理職から、スクラムやアジャイルを扱う際のペアプログラミングの利点は何ですか環境？

13 agile  scrum  management  pair-programming 

私の会社の別のチームが彼らのスタンドアップミーティングを文書化し始めますが、それは時間の無駄だと思います。私が知っている限りでは、スタンドアップミーティングはステータスレポートのためではなく、コミュニケーションのためのものです（間違っている場合は修正してください） それでは、スタンドアップミーティングを文書化する必要がありますか？

13 agile 

SEや他のサイトでこの「アジャイル開発」に関するすべての記事を読むとき、私がいつも疑問に思っていたことが1つあります。 「従来の」ソフトウェアエンジニアリングでは、 ユーザーの要件を収集し、 これらの要件に基づいて仕様を作成し、 それを顧客に渡し、これまでに行った作業の代金を請求します。 実装コストを見積もることができるように（大まかな）技術設計を行います。 ユーザーに実装の価格を提示し、 顧客が仕様に署名してオファーを受け入れるまで待ちます。 設計、実装、テスト、 ビル。 プロセス中に要件が変更された場合、希望する変更のオファー（価格付き）を送信します（または、変更が小さい場合は無料で行います。顧客は好きで、顧客はあまり頻繁に行いません）。 。 では、頻繁な要件の変更がプロセスの一部であるアジャイルプロジェクトでは、これは（財務的に）どのように機能しますか？ 設計変更ごとにオファーを書いていますか？（これはかなり面倒ではないでしょうか？） または、固定価格について交渉し、顧客が要件を頻繁に変更しないことを望みますか？（リスクを伴う可能性があります。プロジェクトの完了を受け入れる前に、この機会を利用して新しい機能を何年もリクエストする顧客を知っています。） または、必要な合計時間に対して顧客に請求するだけですか？（事前にコストを知らない顧客にとっては危険です。）

13 agile  business  financial  changes 

スプリントで多数のユーザーストーリーを計画しており、1つの候補ストーリーがチームに何かを提供する外部プロバイダーに依存している場合。たとえば、オンラインサービスプロバイダーが新しいAPI呼び出しをシステムに追加したり、システムなどでテストアカウントを有効にしたりします。 あなたはそれが「もうすぐ」来ることを知っています。 あなたは先に行くと、彼らはあなたがあなたの物語を完了するための時間が必要であるものを提供します望んでスプリントに話を追加してくださいまたはあなたはそれが可能な状態になりますし、あなたがしても、すぐに始めることができます知っているとき、あなたは次のスプリントまで待つんできるだけ早く話を始めないことを意味します。 前者が依存関係のために失われた「未学習」のストーリーポイントをどのように処理するか？部分的なクレジット（eek！）またはあごにそれを取る。

13 project-management  agile  scrum  planning 

私は仕事を辞めて（他の国に移動するために）JavascriptとHaskell（いくつかのpython）でプログラミングすることがほとんどでした。人々は客観的で、ポジティブで、数学的でありながら、たくさんのことを成し遂げたので、私はそれが本当に好きでした。これは本当にプロフェッショナルなショップでした。 現在、私はAgile / XPショップで働いています。これは良いことですが、テクノロジーとライブラリーの選択に関しては、私たちはプロではないかもしれません。ソフトウェアを書くための私たちのアプローチは少し未熟で構造化されていないように感じます。私は私が提供された本を読もうとしていますが、彼らはこのスタイルを奨励しているようです（ugh）。多くの場合、Gitハブからライブラリを選択して、レビューなしで使用します。 たとえ一人の小さな仕事であっても、常に誰かと仕事をすることを強いられます。些細な反例によってルールを破ることができる場合でも、すべてに対して少し「速い」ルールがあるようです（その反例をあげるのを間違えて、口頭で攻撃されました）。これは州では普通ですか？この独断をどのように処理しますか？

13 ruby  haskell  agile 

私が働いている会社は、一時的に多くの人に滝の「喜び」を経験したアジャイルプロジェクト管理戦略に向かっています。これの鍵は、厳しい納期を守ることとは対照的に、機能を提供することに重点を移すことです。 開発プロセスとクライアントの関係は、アジャイルを通じて培われた反復リリースによって確実に改善されましたが、プロジェクトの資金調達戦略に同じ理論的根拠を適用することはいくぶん困難になっています。クライアントは、アジャイルのような概念に慣れていないことが多く、「準備ができたら準備ができている」と彼らが考えるものに大きな懸念を表明しています。 アジャイルプロジェクトの資金調達に関する人々の考えや経験を聞きたい 編集： 私は、アジャイル手法の長所と短所を私に説明するように人々に求めているのではなく、アジャイルは「準備ができたら準備ができます」と同等であると信じていないことを強調したい、これはアジャイル開発プラクティスを提唱する際に私が携わったクライアント/ビジネス。 私が興味を持っているのは、ビジネスクライアント/関係に定着している「従来の」ウォーターフォール予算編成方法と、より進歩的な開発手法との対立を解決した経験と、その進化をサポートするために採用した予算戦略です。

13 agile