問題タブ [agile-processes]

スクラムと OpenUP ライフサイクルおよび成果物を組み合わせた方法を作成しています。また、OpenUP の分野を「プロジェクト管理」から切り離したいと考えています。生成されたメソッド サイトですぐにわからないように「非表示」にすることができます。しかし、たとえば、「リスク リスト」アーティファクトに移動すると、PM は引き続き貢献していると見なされ、リンクをクリックすると、PM 規律ページに移動します。

使用している OpenUP ライブラリから削除せずに、メソッドから完全に削除するにはどうすればよいですか?

従来のウォーターフォールでは、難解なテンプレートに従って、通常は MS-Word 文書に要件がまとめられていました。「厳密な」ウォーターフォール モデルでは、このドキュメントは要件フェーズの後に凍結され、変更管理/変更管理プロセスが管理された変更の導入を担当します。(**) [通常、ドキュメントは「生きたドキュメント」になり、最終的には「生きた悪夢」になります]

現在、私は既存のデスクトップ アプリケーションを Web に (VB 6.0 から ASP.Net に) 書き直すプロジェクトを率いています。クライアントは、書き直したいアプリケーションのベースライン バージョンを持っています。[したがって、要件は凍結されています...スコープクリープはありません]。そのまま再利用するデータモデル。移行するフロント エンド/ビジネス ルールのみ。アプリケーションを見ると、それはせいぜい 3/4 の主要な画面であり、それだけです。

一部のチーム メンバーは、新しい開発に着手する前に、すべてを文書化したいと考えています (私の意見では古い考え方です)。UI を Web に変換し、古いコードを検索し、ビジネス ロジックを記述し、自動化された単体テストを実行し、統合テストに進み、画面ごと (または機能ごとにビジネス機能) を配信するのは、比較的簡単なはずだと私や他の人は感じています。

私の質問は次のとおりです。アジャイル開発では、これを最適化しない場合、どのように「アジャイル」を維持しますか。私の意見では、詳細なドキュメントを書くことは反アジャイルです。どう思いますか？アジャイルの第一人者は、上記の問題 (既存の VB 6.0 アプリを ASP.Net に書き直すという問題) にどのようにアプローチしますか?

免責事項: 1000 ページの機能仕様の作成は、契約上の義務、政治的必要性を満たすためである可能性があり、システムは本当に複雑になる可能性があります (現在、「複雑さ」の定義は暗い土地への旅です)。

私たちはバグ追跡とリリース管理に JIRA を使用し、JIRA 内のプロジェクト管理に greenhopper を使い始めましたが、ユーザー ストーリーとそれらのユーザー ストーリー内のタスクの考え方が欠けています。ユーザーのストーリーとタスクを完全にサポートし、ユーザーにとって高速でシンプルなアジャイル プロジェクト管理ツールのような他のタスク ボードを推奨する人はいますか? 私は targetprocess を調べ始めたので、特にそれについてフィードバックがあれば、それも素晴らしいでしょう。

「継続的実装」はソフトウェア開発方法論の名前ですか? もしそうなら、それは正確には何ですか？

使用経験はありますか？

継続的インテグレーションとは何かは知っていますが、継続的実装は知りません。

背景: 今日、私は、ソフトウェア開発のコンテキストで「継続的実装」を使用している会社について (間接的に) 知りました。それは正式に定義されていますか、それともアジャイル ソフトウェア開発方法論の一部ですか?

私が見つけた最良のものは、European Journal of Information Systems の次の論文でした。

シナリオ開発と継続的実装による俊敏性

「... Volvo におけるビジネスと IS/IT のイニシアチブ ... アジャイルなアフターマーケット サプライ チェーンの開発と実装. ... プラットフォーム、Web サービス、およびインターネット経由でスペア パーツを販売するための Web ポータルを作成すること。」

アジャイルの方法論は、物事をシンプルで無駄のないものに保ち、必要になるまで複雑さや洗練を加えないようにすることを奨励しているように思えます。しかし、テクノロジーの変化のペースと量により、ますます抽象的で複雑かつ洗練されたツールとパターンを使用して、まだ経験していない (そして決して遭遇しない可能性がある) 問題を複雑な方法で解決することが奨励されています。

プロジェクトにアジャイルを実装するには、リファクタリングを行う能力が必要です。必須ではありませんが、コードのリファクタリングは優れたエンジニアリング プラクティスであることが証明されています。

RPG、RPG LE での開発 (新しいコードとレガシー コードの変更) を必要とする iSeries プラットフォーム上のアジャイル (スクラム) プロジェクトでは、リファクタリングを実装できますか? もしそうなら、それを行うためのテクニックは何ですか？

それを試した人が自分の経験を共有したり、参考文献を指摘したりすることができれば、私はそれを大いに感謝します.

他の人が自分の会社の物理的なかんばん/スクラムボードに何を使用しているかについて興味があります。機密性の高いビジネス情報のため、ボードの写真を提供できない場合があります。私はあなたのボードがどのように見えるか、そしてユーザーストーリーとタスクが典型的なスプリント/イテレーションを移動するときにどのように整理するかを調べていますか？

通常、私はそれぞれで次のようにボードを整理する場所で働いてきました

要約すると、次のようになります。

• UC-001のタスクは、チームの1人のメンバー（Bob）によって進行中です。Todo列では、他の人が取得するタスクのリストが待機していますが、これは、作業を完了するためにボブと調整するチームの別のメンバーが取得できます。
• UC-002の場合、支払いサービスタスクが完了し、QAの自動テストハーネスが完了して、UIなしでサービスをテストできるようになりました。テストが失敗した場合、バグが発生し、支払いサービスタスクとともにQAフェーズに戻ります
• UC-003のすべてのタスクが完了し、QAの準備ができました。
• Uc-004とUC-005のすべてのタスクが完了したため、ユーザーストーリーは[完了]に移動しました。

これは、各タスク/ユーザーストーリー（付箋として表されます）と対話する人々を含む具体的なホワイトボードとして機能します。電子バージョンは、スプリント/イテレーションの前に作成され、現在の状況に対応するスプリント/イテレーションの最後にのみ更新されます。コメントや批評を歓迎します:)

私は、アジャイル開発プラクティスを採用する可能性を探っているチームで働いています。

私たちが直面している問題の 1 つは、イテレーション (スプリント) をいつ完了するかを決定することです。

機能のバックログを定義し、それらのストーリー ポイントの見積もりを作成し、最初の 30 日間のスプリントに機能 A、B、D、および F を含めることを決定したとします。スプリントの最後に到達し、A、D、および F を完了しましたが、B は 80% しか完了していません。次のことを行う必要があります。

1. 時間通りにスプリントを完了するが、機能 B を除外する (残りの作業を将来のスプリントに延期する)

2. 機能 B を完了するのに必要な時間だけスプリントを延長しますが、次のスプリントは開始しません。

3. 機能 B を完了し、次のスプリントの作業を開始するのに必要な時間だけスプリントを延長します。

4. スプリント全体を失敗させ、すべての作業をバンドルして将来のリリースの一部にします。

オプション 1 の問題点は、チームが約束したことを実行していないことです。場合によっては、リリース全体を役に立たなくする (または少なくとも実質的に価値を下げる) ことなく、機能 B を除外することができない場合があります。機能 B がないと、次のスプリントの方向性を導き出すのが難しくなる可能性があります。

オプション 2 の問題は、チームの一部のメンバーがかなりの時間アイドル状態になる可能性があることです。これにより、全体的な生産性が低下します。単体テストを追加したり、機能を磨いたりできるかもしれませんが、それに比例した価値はありません。また、チームのほとんどがアイドル状態である理由を経営陣に説明することは、政治的にも困難です。

オプション 3 は、アジャイルの精神に反しているように思われます。前のスプリントの結果が開発の次の反復を導くことを許可しないことで、次のスプリントを危険にさらすことになります。

オプション 4 は深刻なようで、オプション 1 と 3 とほとんど同じ問題があります。まず、コミットメントが完全に失われています。第 2 に、より多くの機能を後続のリリースにバンドルすると、顧客によるテストと検証が難しくなり、以前のフィードバックに基づいて将来の反復を導くことができなくなります。

私のチームは、ビルドが中断される時間を最小限に抑えることを目標としています。

継続的インテグレーションにはCruiseControl.NETを使用しています。私が知りたいのは、次の質問に答えるのに最適な方法です。

「最後の{timespan}で、{project-name}が壊れた状態で費やした時間はどれくらいですか？」

例：「過去1か月間に、プロジェクトが壊れた状態でどのくらいの時間を費やしましたか？」

この情報をある種のレポートまたはダッシュボードのどこかで利用できるようにするCruiseControl.NETの高度な機能はありますか？

または、この情報を収集するためにxmlアーティファクトファイルを解析する方法を教えてください。

製品は、リリースではなく機能として開発および提供されます。つまり、機能が完了すると、ステージングにプッシュされてから本番環境にプッシュされます。開発中の複数の機能があり、配信タイムラインが重複している可能性があります。そのため、いつでも開発データベースとソース管理には開発中の複数の機能があります。機能が完成したら、機能固有のコードとデータベースの変更のみをステージングにプッシュしたいと考えています。このプロセスは、次の理由により、エラーが発生しやすく、時間がかかることがわかっています。

• 特定の機能の DB エンティティは独立していませんが、依存しており、他の機能と絡み合っています。そのため、機能に固有のエンティティを分離するのは時間がかかり、達成が困難な場合もあります。それを行うより良い方法はありますか？
• サーバー側のコードでは、同様に機能固有のコードを分離することは、データベースと同じくらい面倒です。DB の上にレイヤー化された .NET Entity Framework と、事前に生成されたビューなどの他のパフォーマンスの最適化を使用して、機能ベースの開発をデプロイするより良い方法はありますか?

開発環境は、SQL Server 2008、.NET、ソース管理用の SVN を備えた Entity Framework で構成されています。

ここでの機能という用語は、FDD アジャイル モデルとは関係ありません。

似たような経験をした人はいますか？

どうもありがとう！