問題タブ [agile-processes]

私たちは地理的に分散した開発チーム内にアジャイル手法を実装することを検討してきました。そのため、あなたが使用していて便利だと思った無料のオンラインアプリケーションに関する提案が必要です。

現在、これを管理するために紙のカードと壁を使用しています:)が、できれば無料のオンラインバージョンに移行したいと考えています。

以前の仕事でTargetProcessを使用しました！

私のコア要件は次のとおりです。

• ビジネスアナリストはユーザーストーリーを追加できます
• 開発者にさまざまなユーザーストーリーを割り当て、優先順位を付けることができます。
• QAチームは、さまざまなユーザーストーリーに関するテストケースを追加できます。
• プロジェクトマネージャーは、すべてのリソースの時間を追跡し、上級管理職向けのレポートを取得できます

私は、アジャイル思考ではない大規模な企業の一部である小規模なアジャイル開発チームで働いています。現在、私たちはスクラムを実践しており、時折、スプリントのコミットメントを超えています。

私の質問は、スプリントのコミットメントを超えた場合、バーンダウン チャートをどのように処理しますか? 次の 2 つのオプションが考えられます。

• y 軸を負の方向に延長し、カウントダウンを続けます
• カード/ストーリー/ワークを追加し、バーンダウン値をその分増加させ、そのワークが終了するとバーンダウンします。

私のチームにとって究極のソリューションは、ビジネスにとって明確で、開発者にとって真の価値をもたらすものです。これまでのところ、これらのソリューションはいずれも完全には機能していません。

このスレッドは私の前のスレッドのフォローアップです。実は2つの質問なので、お互いに依存しているので、気にしないでください。

私たちは仕事で新しいプロジェクトを開始しており、アジャイル技術を実際に試す絶好の機会だと考えています。いくつかの本や記事で読んだアイデアについてブレインストーミングを行い、私たちに最適なコンセプトを考え出しました。2週間の反復に続いて、次の反復で必要なものを選択するクライアントに電話をかけました。もう少し質問がありますが、自分では理解できませんでした。

最初の反復で何をしますか？

ゼロから始める場合、一般的に、最初の数回の反復で何をしますか？アプリケーションのコアをコーディングするために1か月の開発を行うだけですか、それとも事前にコーディングされた機能が制限された単純なワイヤーフレームから始めますか？通常、クライアントは何を見たいですか？動作しない光沢のあるもの、または動作する醜いもの？

クライアントとのコミュニケーション方法は？

私たちの最初の考えは、プロセスを次のようなものに設定することでした。

代替テキストhttp://img690.imageshack.us/img690/2553/communication.png

クライアント側にフォーカルポイントを設定するのは良い考えですか、それとも誤解を防ぐためにすべてのクライアントと直接通信する方が良いですか？

どんな考えでも大歓迎です！前もって感謝します。

破損したmergeinfoがあると思いますが、よくわかりません。誰かが私がどのように決定を下すか、そして問題を解決するのを助けるためにそこにどんなリソースがあるか知っていますか？

これが問題です。私のチームは最近アジャイルに移行し、異なるチームが同じソースで同時に作業する機能ブランチ（実際にはストーリーブランチ）を使用しています。ストーリーが高い準備状態を達成すると、チームはトランクにマージされます。変更の欠落、予期しない変更、および競合のため、マージには数日または数週間かかります。私たちは5〜10人のチームについて話していて、努力/解約はかなり高いようです。

人々はこのマージパターンを使用しますa）PULL-トランクからブランチへのマージ、解決、テスト、コミットb）PUSH-ブランチからトランクへのマージ、解決、テスト、コミットc）ブランチの再作成（または通常は新しいストーリーブランチの作成とそれが終わったので古いものを落としてください）

この終わりまでに、ブランチとトランクは整列しているはずです。

私たちが見ている問題：

1. トランクからブランチへのマージ中に報告されなかった変更は、後続のブランチからトランクに表示されます
2. マージ中のsvn：mergeinfoプロパティの競合
3. ファイルがありませんが、新しいファイルのローカル編集がブランチに追加され、トランクにプッシュされました
4. 着信+ローカル削除（トランクおよびブランチで削除されたファイルは競合として表示されます）

（1）起こってはならない。ブランチからトランクへのプルは、すでにトランクにあるすべての変更に対して2つを同期させる必要があります。ブランチからトランクへのマージの変更は、トランクで発生した変更です。したがって、最初のマージでは、ブランチに伝播する必要がありましたが、伝播しませんでした。これは、トランクの変更を「隠す」mergeinfoデータの破損を示しています。

（2）起こってはならない。SVNは、マージ追跡の変更を管理する必要があります。これは、mergeinfoデータの破損も示しています

（3）起こってはならない。これは、ブランチに追加された新しいファイルの場合です。トランクに追加された新しいファイルとして表示されます。これは、マージ情報データの破損も示しています。

（4）これはSVNのバグであり、修正できないと思います。それでも、これが私たちの唯一の問題であるなら、私は幸せになるでしょう

現在、接続にsvn1.6.xとsvn+sshを使用しているクライアントを備えたsvn1.5.xサーバーを使用しています。いくつかの修正が問題に影響を与える可能性があるため、最新かつ最高のSVNに移行する予定です。

それでも、mergeinfoデータが間違っているように見えます。

• すべての変更を報告しないマージ
• mergeinfoプロパティのマージでの競合

私が探し始めるのに良い場所はありますか？

アジャイル/スクラムが答えですか? スクラムはこれをどのように処理しますか?

1 人のプロダクト オーナー、1 つのプロダクト バックログ vs 複数のプロダクト オーナーとプロダクト バックログ?

それはあなたにとってどのように機能していますか？あなたの成功失敗談を教えてください。

私は、インフラストラクチャ プロジェクト、単純な機能拡張、そして 6 ～ 7 人の開発者からなる小規模な開発チームによる大きなプロジェクトに至るまで、複数の作業待ち行列を管理するプロセスをまとめようとしています。

最近、DevOps（運用におけるアジャイル手法）について多くのことを聞いています。誰かがこのプロセスへの実際の開発者の関与のレベルに光を当てることができますか？

私たちには 2 つの異なるアジャイル チームがあり、それぞれが別々の、しかし関連するアプリケーションに取り組んでいます。
これまで、各チームは独立した方法で作業することができました (個別のコード ベース、永続ストア、スプリント、バックログなど)。最近、製品管理部門は、これらのアプリケーションをさらに緊密に統合することを決定しました。ちなみに、各チーム (QA、開発者、BA で構成される) の規模は、今後 6 ～ 12 か月で増加します。

経営陣は、アジャイル プロセスがうまく機能した (2 つのチームが可能な限り独立して作業している) ため、アジャイル プロセスをほぼそのまま維持することを決定しましたが、アプリケーションを統合する手段として、契約ベースのサービス レイヤーのアイデアを浮かび上がらせました。

各スプリントでは、他のアプリケーションとの統合が必要なストーリーが特定されます。その時点で、追加の「統合」ストーリーが他のチームのバックログに追加されます。その後、そのチームは契約を履行する任務を負います。その間、他のチームは元のストーリー作業を継続し、他のチームが実用的なサービスを作成するまでモック/フェイク サービスを代用できます。

アジャイルは KISS 哲学を説いているため、チームの何人かの人々は、このアプローチの「複雑さ」に異議を唱えています。彼らは、「過去にうまく機能した」より無駄のないシンプルな統合方法論として、ストアド プロシージャの共有を引き続き使用することを提唱しています。

私はさまざまな理由から契約ベースのプログラミングを好みますが、主な理由は、アプリケーションが提供することが期待される動作をコンパイル時に可視化できることです。また、誰がどのコードを所有しているのか、契約を破った場合に誰のコードを壊す可能性があるのか​​について、明確な境界線も得られます。ストアド プロシージャはそれを行いません。

私たちはすでにアジャイルから多くの利益を得ているので、この種のアプリの統合/同期に対処するための「アジャイルフレンドリーな」方法がすでにあると思います。コントラクト ベースの SOA レイヤーを作成することは、アジャイルの匂いテストを満たしていますか? 私が考慮していない 3 番目のオプションはありますか?

私たちのITマネージャーはITILを推進していますが、私はITILに精通しておらず、ITILがアジャイルのワークサイクルにうまく適合するかどうかを知りたいと思っていました。

私の最初の印象から、主に私たちのマネージャーが提案しているのは、すべてに対してタイムラインを設定することであり、SLAは「優先度の高いタスクはx時間以内に完了する必要がある」などと述べているため、私はノーと思います...これは開発者として罰せられますこれらのSLAを満たしていない場合。

どちらかといえば、タイムラインが速度とストーリーポイントのアジャイルな方法に基づいてエンドユーザーに予想される時間枠を交渉する交渉戦略を好みます。

アジャイル開発の実践、テスト駆動開発、継続的インテグレーションがあり、改善の余地がありますが、現在取り組んでいます。

ITILとアジャイルの方法が一緒に機能する他の経験は何ですか？

私は初心者なので、スパイラル モデルとアジャイル モデルの違いを簡単に説明してもらえますか?? 実世界の例をいくつか教えてください。スパイラルはアジャイルよりも有用であり、その逆も同様です...インターネット上で利用できるリンクが非常に多いことは知っていますが、私は初心者なので理解しにくい..簡単な言葉で説明すると大きな助けになりますか? ? 事前にサンクス...

あなたの会社がスクラムのようなアジャイル手法を使い始める前に書かれたレガシーコードの一部に取り組んでいるとしましょう。

ここで、フィールドで修正が必要なバグを発見し、その機能に関するストーリーが書かれていないとしましょう。チームの誰もが、その特定の機能が何であり、どのように動作することになっているのかを知っていますが、それに関連するストーリーはありません.

現在のスプリントでは、マーケティングとサポートが問題の処理にうんざりしているため、その欠陥に取り組む必要があります。

その欠陥がリンクされるように、振り返ってストーリーを作成しますか? 欠陥をストーリーとして再ラベル付けし、ストーリーのように見えるようにフォーマットを変更しますか? ストーリーを作らない場合、欠陥に対してポイントを獲得できますか? ストーリーを作成した場合、(ストーリーのポイントを介して) 欠陥を修正するためのポイントを獲得できますか?

この状況を処理する最善の方法は何ですか?

更新: 突然、Windows 7 64 ビットのシステムでインストール プロセスがブルー スクリーンになり始め、すべての Windows プラットフォームにアプリケーションをインストールする必要があるとしましょう。新しい問題は、サービス パック 1 などが原因で発生した可能性があります。