問題タブ [agile]

の基本的な手順はAgile software development何ですか?
また、アジャイル手法を使用して新しいプロジェクトを開始するにはどうすればよいでしょうか?

誰かがアジャイルを行おうとしている場合、私はこれに JIRA / Greenhopper を使用する方法を見つけようとしています。私たちはグローバルな開発チームであるため、ここでは分散型の性質が非常に重要です。

当初はスクラムワークスを使用していましたが、チームは、JIRA とスクラムワークスに常に重複した情報があり、冗長であると考えていると不満を漏らしていました。

私たちは Greenhopper を手に入れ、それで問題が解決すると考えましたが、これに関して私が抱えている問題は次のとおりです。

1. JIRA にユーザー ストーリーの概念がない
2. Greenhopper も、ユーザー ストーリー レベルでの集計なしで「タスク」に焦点を当てています。

JIRA でこれを成功させた人はいますか、それともスクラムワークなどの他のツールに戻って、サポート チームが提起したバグに JIRA を使用することを検討する必要があります。

私は友人のビジネス用に小さなアプリを書いています。この機会に、今年の初めに行ったアジャイル プロジェクト管理トレーニングを復習しようと思いました。

私 (そして私の現在の組織だと思います!) は、次のような形をとるユーザー ストーリーの形式で要件を収集することに常に苦労してきました。

[ユーザータイプ] として [機能] が欲しい [なんらかのメリット]

私はいつも最初と最後を見逃して、機能をそのままにしておくように誘惑されます-しかし、これは古い方法で収集する要件になります!

しかし、「私はアジャイルをやっている」と言えるように、単に適合させたいわけではありません....たとえば、ユーザーにアイテムのリストを提示する必要があることがわかっている場合、その理由は自明ですね。

例えば

【店長】として【在庫一覧が見たい】のですが・・・？

[so that] 句を省略するのは通常の慣例ですか?

私は最近大学を卒業したばかりで、労働力の高齢化が進んでいる大企業で働いています。できれば両方の年齢差で働く人々の経験に興味があります。

例 これまでに遭遇した問題:

• アジャイルプラクティスとウォーターフォール
• プログラマー同士のコラボレーション vs 個性
• 早朝勤務 vs 深夜勤務

私は主にアジャイル プログラミングを学校で学びましたが、プロジェクトに参加していました (ほとんどの開発者はウォーターフォールに慣れています)。

私はプロジェクトでクラスメートや友人と協力することに慣れていますが、年配のプログラマーが自分のことをするのが好きなのを見る傾向があります。私は彼らに質問をせがむような気がします。

私はどちらかというと夜型プログラマーだと思いますが、年配の同僚のほとんどは早朝 (午前 5 時) です。

技術職での年齢差に関する経験は適合です。

参加者の 1 人がインド (+05:30) にいて、他の参加者が米国 (-06:00 と -08:00) にいる場合に、スクラムを形成することは賢明でしょうか? それでは誰にとっても快適な会議時間はありません。

AcmeCMSを作成しているとしましょう。このCMSWebアプリケーションを使用すると、サブカテゴリ（深さ無制限）を使用して無制限の数のカテゴリを作成でき、各カテゴリには0以上のコンテンツページを関連付けることができます。

したがって、このプロジェクトは、大まかに次のようになります。

フロントエンド 1.インデックスページ2.コンテンツページのリストを含むカテゴリページ3.コンテンツページ

管理コントロールパネル 1.カテゴリ（追加/更新/削除）2。ページ（追加/更新/削除/）

スキーマ設計1.テーブル2.ストアドプロシージャ3.データアクセス層

質問：バグトラッカーとWikiを使用していますが、このプロジェクトをどのように分類すればよいですか？

各セクション（フロントエンド/管理パネル）を個々のページに分割し、各ページ（またはテーマ）の簡単なユーザーストーリーを作成することを考えています。

ユーザーストーリーが完成したら、バグトラッカーに、開発する必要のある機能を表すケースのリストと、それぞれの見積もりを作成します。

このプロジェクトを適切に分解していますか？このプロジェクトを失敗させる計画の大きなギャップ（理論的にはとにかく！）

詳細な回答、おそらく私が何をすべきかについての一般的な考え、それを説明する詳細な例とその理由などを提供してください。

現在、Data-Access オブジェクトと、約 20,000 行のコードに相当する多くのストアド プロシージャとトリガーで手作業で作成された SQL を使用しています。単純な変更により、修正に数日かかる作業が発生し、締め切りが遅れる原因となっていることがわかっています。

変更には、追加データに対処するためのテーブルの変更、QA/ユーザー レポートに基づくスキーマの一般的なリファクタリングなどが含まれます。古くて遅いものを置き換えるために構築されている非常にアクティブなシステムです。

これらの変更の影響を制限するために利用可能な PHP ORM ソリューションを調べましたが、遅すぎてスキーマに対処できませんでした。「単純な」SQL の結果は、カスタム クエリよりも桁違いに長い時間がかかっており、約 0.5 秒のページ ビューが 20 秒以上かかっていました。

一般的なコンテキストで、リレーショナル データベースを使用したスキーマの進化に対処するために検討できるベスト プラクティス/戦略は何ですか?

編集：トリガーについて言及するのを忘れました。カスケード変更に依存する多くのデータがあります。ここでこのユーザーの価格を変更すると、そのユーザーの価格が更新されます。

私は、開発プロセスにスクラムを使用するチームに所属しています。現在、最近気づいたいくつかの問題に対処するために、プロセスの特定の側面を改良しようとしています。そうすることで、スクラム プロセス全般について何が好きで、何が嫌いかを探り、チームとして仕事で何を重視するかを特定できるようにします。私たちが何を重視するかを特定できれば、その価値を中心に展開する実装を考え出すことができ、新しいソリューションがチーム内に定着するのに役立つと考えています。

そうは言っても、他の人がスクラムプロセスをどのように見ているかに非常に興味があります。あなたがそれについて本当に好きだったのは何ですか？イライラしたり、オーバーヘッドが多すぎたり非生産的だと感じたりしたのは何ですか? 成功と失敗の具体的な例は問題ありませんが、議論がスクラムの落とし穴やスクラムが本当に優れている場所を中心に展開する、より大きな視点に興味があります。

考え？

私は、アジャイルプロセスを促進するためだけにコンサルタントを雇うことを含め、彼らがアジャイルとやり過ぎたように見える新しい契約を結んでいます。彼が始めているのは、私たち全員が実際に同じ部屋にいる「コアアワー」の概念です。これは本当に「コアアワー」が構成するものですか？私のラップトップを手に取ってこの共有の場所に半日行くのは非常に不便なので、私は尋ねます。私はいつも「コアアワー」とは、たとえば9時30分から4時まで、必ずしも同じ部屋にいる必要はないという意味だと思っていました。

私はいくつかのオープンソースソフトウェアを開発するための個人的なプロジェクトを始めています。これのPMプロセスとしてスクラムを使用したい（製品バックログ、優先順位付け、およびそれらを取得できる場合はバーンダウンが好きなので）が、取得できないため、完全な値を取得できないようです。最初に、私と私の協力者が特定のスプリント中に作業にコミットできる時間を保証します。

スクラムを使用することで得られるメリットは他にもありますが、バーンダウンチャートやタイムボックス化された反復などの価値を得ることができる、知らないバリエーションやトリックやテクニックはありますか？それとも私は希望がありすぎているのでしょうか？

TIA。

Regs、Andrew