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

基本的にはスクラムに従って、アジャイルなソフトウェア開発を行っています。私たちはスプリントレビューを行おうとしていますが、難しいと感じています。私たちのソフトウェアは多くのデータ処理を行っており、ストーリーはしばしばこれに関するさまざまなルールを変更することについてです。 UIまたは目に見えるワークフローの変更がない場合にスプリントで発生した変更をデモするためのいくつかのオプションは何ですか？その代わり、変更は数十分または数時間かかることもある処理ジョブの微妙なビジネスルールです？

10 agile  scrum  sprint 

現在、私の現在のプロジェクトではアジャイルメソッドを使用しており、次のような大量のストーリーがあります。 アシスタントとして、お客様に払い戻しを請求し、リクエスト時にお金をもらうことができるようにしたい 顧客として、私はアイテムを受け取ることができるように購入の代金を支払いたいです。 これまでに行った方法は、すべてのスプリントで最も重要なストーリーを選択し、それをいくつかの正式な要件仕様にまとめます（同じ仕様で似ているストーリーのいくつかをグループ化します）。ストーリーによっては、画面上のボタンまたはワークフロー全体の場合もあります。 問題は、ストーリーが多すぎるため、システムのどの部分にストーリーが関連しているかがすぐには明らかにならないことです。 それは開発者の時に機能し、すべてのスプリントは開発者が何をする必要があるか、そして彼らが行う必要がある変更を概説するスペックを取得します。しかし、このストーリーリストの維持とテストに関しては、バグの追跡が非常に難しくなり、一般的には仕様のみを維持することになります。これは、画面の機能の一部がさまざまな場所で文書化されているためです。ストーリーで分割。 ストーリーに基づいた仕様を書くことは良い考えですか？ストーリーを間違った方法で書きましたか？

10 agile  documentation  requirements  user-story 

要件の変更によって「アジャイル」と定義されたプロジェクトのこの問題が発生したことはありますか？私は4週間のSprintで実行される開発プロジェクトに取り組んでいますが、これらのSprintの間には常に変更があります。それでもアジャイルとして定義されていますか？私はそれがサブアジャイルプロセスのようなものだと感じています-アジャイルプロセスの要件は、スプリントの始めに定義され、その終わりに向かってレビューされるべきです。私はこれで正しいですか？この経験を教えてください。

10 agile  requirements 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 私のチームは4人の開発者で構成されています。すべての味付けと熟練。それらの1つは、Planning Pokerで見積もりを下す前に、ストーリーの技術的な解決策を定義することを主張する、言葉の多い、意図的なチャップです。彼は、合意された技術的解決策の大まかなアイデアがないかどうかを見積もることを拒否します（これは合理的に聞こえますよね？）。 問題は、見積りセッションが終了するまでに時間がかかるということです!! あなたの経験では、プランニングポーカーをプレイするとき、このような性格をどのように扱いますか？

10 agile  planning 

ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 8年前休業。 小さなイテレーションが好きです。単体テストが好きです。コードレビューが好きです。私が気に入らないのは、ドキュメントがほとんどないかまったくないところから始めることです。私はこれで一人ですか？プロセスについて誤解しているだけですか？ どんな考えでもいただければ幸いです。

10 agile  documentation  methodology 

私たちは2人の開発者であり、新しいWeb製品開発を開始しようとしています。 どちらも無駄のないスタートアップアプローチのファンであり、継続的な導入を実践したいと考えています。 ここでジレンマが発生します-私たちは両方ともC＃/ Windowsのバックグラウンドから来ており、どちらかを決定する必要があります。 .NETとWindowsに固執することで、新しいテクノロジーの学習に時間を費やすことなく、開発に全力を尽くします。 Ruby on RailsとLinuxに切り替えます。Rubyon RailsとLinuxは、迅速な立ち上げと広大なオープンソースサポートで高い評価を得ています。マイナス面は、Ruby、Rails、Linuxの学習に多くの労力を費やす必要があることです... あなたならどうしますか？他にどのような考慮事項がありますか？

10 programming-languages  web-development  agile  startup  lean 

これは、別の質問（これ）に対するいくつかの回答とコメントから生じました。 私は主にウォーターフォールプロジェクトを扱い、アジャイルな振る舞いを取り、アジャイルについてかなり読んだアドホックプロジェクトに取り組んできましたが、「適切な」アジャイルプロジェクトに取り組んだことは一度もありません。 。 私の質問は、「後期」の概念がアジャイルで何らかの意味を持っているということです。 私の推論では、アジャイルには事前の計画はなく、最初は詳細な要件もありません。あなたは高いレベルの目標とそれに付随する想定上の日付を念頭に置いているかもしれませんが、両方が（潜在的に大規模に）変わる可能性があり、どちらも確実ではありません。 つまり、配信してユーザーが受け入れるまで、基本的に何を配信するかが正確にわからない場合、次のスプリント以降のスケジュールがない場合、どのようにして遅れることができるでしょうか。実際に意味がありますか？ （明らかに、スプリントがオーバーランする可能性があることは理解していますが、それを超えて話しています。） 明確にするために、私がそれらを見てそれらに関与したという事実に基づいて、時間どおりにウォーターフォールプロジェクト（比較的大きなプロジェクトでも）が可能であるという仮定に（個人的に）満足しています-それらは簡単でも一般的でもありませんしかし、それらは可能です。 これはアジャイルをノックすることではなく、私が理解することです。アジャイルのメリットは、期限や予算とは関係なく（または間接的にのみ）、常にスコープと関係があると見なしてきました。アジャイルは、プロジェクトチームが重要であると考える前に、実際に重要であると考えるよりも、実際に重要なことに近づきます。何でも見ました。

10 agile  scheduling 

少し前、私が働いている会社は開発プロジェクトを第三者に外部委託していた。彼らはソリューションの開発にアジャイル手法を採用しました。しかし、ドキュメントを求められたとき、彼らはそれがwikiに組み込まれたり、彼らのスプリントの一部として組み込まれたりして、それが必要であるとだけ言ったでしょう。 彼らは、プロジェクトチームの1人を除いて全員がプロジェクトの完了時に出発しました。プロジェクトのwikiサイトは、年間サブスクリプションが満期になると閉鎖されました。 彼らが去ったとき、彼らは彼らと一緒に開発されたものについての知識と理解のほとんどを取りました。 だから私は2つの主な質問があります。 これはアジャイルにとっては正常ですか、それとも書きたくないという言い訳ですか？ 開発要件、設計、主要な決定、およびコンテキストを記録するためのアジャイルプロジェクトの文書化に関する業界の基準は何ですか？

10 project-management  development-process  agile 

プロジェクトマネジメントチームの間では、「機能する」とは100％完成したものと見なす必要があることを意味するというこの考え方があるようです。ほとんどのプログラマーは、常にそうであるとは限らないことを知っています。機能の一部を機能させるために別のアプローチを試みている場合、それは必ずしも最良の解決策を見つけたことを意味するわけではありません。私はよく何かをやり終えて、一歩下がって、ビジネスルールが満たされた後、自分に何ができるかを自問します。この「もっと上手にできる」時間は、タイムライン内のどこかに実際に収まるでしょうか。私は、最良のアプローチは、コードを見つけたときよりも常に（ある程度）そのままにしておくことであると考えています。これは、リリース後のリファクタリングを意味する可能性があります。しかしながら、

10 agile  refactoring  optimization  waterfall 

バックエンド開発をユーザーストーリーに垂直に分割することを計画しました。しかし、私たちのチームのバックエンドの男は、これにより彼らの仕事が見えなくなると不平を言い始めました。 私の答えは スプリントの計画とレビューのミーティングでは、関係者の前でバックエンドのタスクについて話し合い、それが見えるようにします。 プロジェクト中に高品質を維持すると、他のチームよりも起動のペースが遅くなりますが、プロジェクト中は速度が安定します。そして、速度は利害関係者に非常によく見えます。 「開発者として、ビジネスロジックをカプセル化できるように、ドメインレイヤーを用意する必要があります。」 チームを汚染する前に問題を解決するにはどうすればよいですか？ 問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の鉱夫やその他の軽蔑的な言葉を呼ぶことです。

10 agile  scrum  team  user-story 

14日間のスプリントの反復があり、新機能、いくつかの改善点、および修正すべきバグのストーリーがいくつかあるとします。また、準備が整ったときにこれらの変更をデプロイします。スプリントの終了を待ちません。 私の問題は、このように開発および保守された製品のセマンティックバージョニングを追跡する方法ですか？14日ごとにリリースされる場合は簡単ですが、バージョン番号を増やし、すべての変更を変更ログに記録します。しかし、変更が継続的にデプロイされるとどうなるでしょうか。何かがデプロイされるたびにバージョンを上げる必要がありますか？または、スプリントが終了するまで待ってから、「再開」して、実際の展開で独立して反復ごとに1回だけバージョン番号を増やす必要がありますか？アジャイルのセマンティックバージョニングのベストプラクティスは何ですか？ 編集：私のニーズをよりよく説明するために、私は最初に利害関係者の変更ログを求めています。変更がデプロイされるたびに、変更ログの新しいレコードに関心を持つことはないと思います。

10 agile  scrum  versioning 

私はシステムの所有者と私自身の両方が開発者であるシステムを書いています。現在、システムへの「要求」またはシステムの要件の唯一の情報源であり、機能に関連付けられたユーザーストーリーにそれを記録したいと考えています{1}。私の緊急の優先事項は、現在、管理可能なバックログを取得することです。ユーザーストーリーでの作業に慣れている技術仕様のレベルをキャプチャするにはどうすればよいですか。 {1}アジャイルプロジェクト管理サービスTargetProcessを評価しています。各ユーザーストーリーは親機能に関連付ける必要があります。システムは適切だと思われるので、この小さな制約は、回避するよりも私が作業したいものです。

10 project-management  agile  scrum 

新しいプロジェクトを開始しようとしています（ゲームですが、それは重要ではありません）。基本的な考えは私の頭の中にありますが、詳細のすべてではありません。 計画せずにプログラミングを始めたくはありませんが、ただやりたいという衝動に真剣に取り組んでいます。私が考えることができる新しい機能がそれを必要とするというだけの理由で、アプリ全体をリファクタリングすることを防ぐために前にいくつかの計画が欲しいです。一方で、今月はやる気を失ってしまうのではないかという不安もあり、数ヶ月（暇）の予定を立てたくない。 私が探しているのは、一方を他方を支配することなく両方を組み合わせる方法です。スクラムの方法でプロジェクトを実現する必要がありますか？ユーザーストーリーを作成してから実現する必要がありますか？機能駆動型で作業する必要がありますか？（私はスクラムと古典的な「コードへの仕様」の方法でいくらかの経験があります。） 更新：「クリックダミー」から始めて、後で機能を実装するのはどうですか？

10 project-management  agile 

一方、アジャイルアプローチは、互いに責任を持ち、プロジェクトの共同所有権を受け入れる緊密なチームを強調します。 一方、企業は契約プログラマーを使用して、実際の従業員を解雇することなく資金調達の山と谷を管理できます。資金が不足している場合、請負業者はチームの完全に統合されたメンバーであっても（そして従業員がそうではない場合であっても）、最初に実行します。企業はまた、請負業者を限られた時間だけ維持することを好みます。これは、一部の請負業者が正社員として雇用される可能性があるため、多少緩和されます。 したがって、従業員と請負業者が混在するアジャイルチームを持つことと、それに伴う大幅に異なるステータスに根本的な矛盾があるかどうかについての私の質問は？ 編集：答えは、私がよく直面している緊張を表現しなかった可能性があることを示しているので、別のショットを撮らせてください。 私は正社員です。アジャイルアプローチ（少なくともここで実装されている）を使用すると、正社員と請負業者の両方のすべてのチームメンバーを、まとまりのあるチームの同等のメンバーと見なすことができます。請負業者に対する企業のアプローチは、私がそれらを過度に執着してはいけない使い捨てのリソースであると見なすように私を励ます。 他の人がこの緊張をどのように解決したか知りたいです。

10 agile  management  freelancing 

ソフトウェア開発者としての最初の仕事で、私のチームはアジャイル/スクラムを使用してプロジェクトのワークフローを管理しましたが、それはかなりうまくいきました。経験豊富なメンターが私を正しい方向に導いてくれました-私は彼らに大きな感謝の気持ちを抱いています。私はそこで数年間働いた後、数か月前に新しい機会に移りました。 現在の仕事に早送りします。私は大学の教授のもとで働いています。私は大学にいるので、ほとんどすべてのプログラマーは学生です（彼らは安価で豊富です！）私の上司には管理経験がありますが、ソフトウェア開発の経験はなく、ソフトウェアチームは常に上司の頭にいるわけではありません。 。これらの条件は、いくつかの非常に質の悪いソフトウェアを作成するための完璧な環境を作り出しました。ソフトウェアプロジェクトは少し悪党であるように見え、設計することを考えておらず、いくつかの本当に恐ろしい慣行を採用しています。物事が良くなることを知っています。 開発プロセスを実装して、全員を軌道に乗せ、コードの品質を向上させ、より安定したソフトウェアを展開したいと考えています。どこから始めればいいのかわからない。 私は、言うまでもなく、「スクラムを使用する」、「かんばんボードを設定する」、「アジャイルを見てください」などの回答を探していません。（アイデアは高く評価されますが）。具体的には、この作業環境の開発プロセスを実装する方法について洞察を得たいと思っています。従業員は通常、次に進む前の1〜2年の間に働き、一般的に経験が浅く、全員を含む毎日のスタンドアップミーティングをスケジュールすることはほとんど不可能です。 そのような職場では、品質、効率、コミュニケーションをどのようにして育てるのでしょうか。 更新：いくつかの回答とコメントを読んだ後、私はいくつかの追加の背景を提供すると思いました。 私は自分自身のソフトウェア開発の芸術のマスターを検討していないだろうが、私は思います、私はそれを見たときに悪いプログラミングを認識するのに十分な経験を積みました。開発者が1〜2分で作業した後、開発者が才能があるかどうかを判断できます。私は問題をスマートに解決する方法を見つける自分の能力に満足していますが、本当に経験が足りない領域は、他の開発者が関与するプロジェクト管理です（そのため、私はここですべての素晴らしい人々に助言）。 私は、このオフィスに来るすべての学生が完全な弱者であるように聞こえました。ここには悪い卵がいくつかありましたが、私が会った学生の大多数は知的で、学びたいと思っており、仕事に熱心です。一部はまだ始まったばかりで、何を知らないのか分からない。そして、それは大丈夫です。私がプログラミングを始めたとき、私は元気がありませんでした！

9 agile  project-management  development-process  management