問題タブ [scrum]

以下の理由により、製品開発に携わるオフショア分散環境で働く従来の大規模なソフトウェア製品組織が、スクラムでのアジャイルの精神に従うことは容易ではありません。

1. 彼らの製品開発は反復的ではありません。製品エンジニアリング チームは、反復的なシステム エンジニアリングを数回繰り返した後、特定のリリースの製品要件、製品アーキテクチャ、および設計を事前かつ正式に最終決定します。これに対する変更は発生する可能性がありますが、大規模ではありません。

2. 製品エンジニアリング チームは、作成された仕様に基づいてオフショア チームがこの製品を構築するようになりました。これらの大規模なオフショア チームは、ここでは保証されていないため、反復的で経験的なモードで作業することはできません。

3. ただし、製品マネージャーは、オフショア チームによる製品開発を定期的に確認するために、短いイテレーションで段階的な納品を要求する場合があります。

4. これらのオフショア チームが、定義された正式なプロセス (経験的ではない)、管理者が管理する環境 (権限が与えられていない)、漸進的な開発アプローチ (反復的で適応的ではない) を使用してスクラムの変形に従うことができれば、彼らにとって非常に役立つでしょう。

5. この状況で実装された真のスクラム アプローチは、非常に偽善的に見えるかもしれません。ただし、従来のウォーターフォールのようなシナリオ向けのスクラムの正式な変形を彼らに提供できれば、彼らはそれを全員の利益のために使用する可能性があります。

このコンテキストについては、 scrumtales.blogspot.comのブログで詳しく説明しようとしました。

これはできますか？

従来のホワイトボードとポストイットノートを使用したスプリントがいくつかあり、プロセスをチームシステム環境に統合する準備ができています。私たちが検討しているツールの1つは、Conchangoの「チームシステムのスクラム」（http://www.scrumforteamsystem.com/en/）です。

誰かが実際のスクラムプロセスでこのツールを試しましたか？あなたの経験はポジティブでしたか、それともネガティブでしたか？あなたの意見では、ツールはライセンス料の価値がありますか？

私は約 2 か月間スクラムを使用していますが、必要な経験がすべて揃っているわけではないので、スクラムについて意見を聞きたいと思います。

私の懸念は、人々が双方の欠点について決して言わないことです。会社と労働者。クロスファンクショナル チームのメリットはわかっていますが、デメリットは何ですか? 素晴らしいエデンの園のそばに隠されているものは何ですか?

私は混乱しています。なぜなら、会社にとっては交換可能な人々の利点であり、チームにとっては、知識を持ち、経験を共有する機会が得られるからです (すべてのチームワークの利点に加えて)。

繰り返しますが、私はすべての利点を知っていますが、真ん中に普通の人がいるという理由だけで、欠点を探りたいと思います. 通常、これらの人々は知識を得るために多大な努力をします。彼らは本を買ったり、コースを購入したり、セミナーに参加したりします。

どの企業でも、誰かが他の誰よりもはるかに多くのことを知っている場合、従業員やマネージャーは、これらの一般の人々がすべての知識を共有することを必死に望み、要求することさえあります。

そしてそれは奇妙です.. これらは共産主義思想であり、私たちは資本主義社会に住んでおり、私が生まれたときからすべてが非常に競争的であり、今では人々は協力的だと言います.

スクラムとリーンの原則は、専門家の生活を台無しにする (または難しくする) 可能性がありますか?

正式なプロジェクト管理システムを必要としている 4 人の開発チームがあります。スクラムとカンバンについては大まかに理解していますが、実際に試してみるまで真に理解することは困難です。1 つを数週間試してから別のものに切り替えるという贅沢はないので、同じような状況にある誰かが、どちらがより効果的で、その理由について考えてくれることを望んでいました. また、開発を管理するための他のシステムがうまく機能した場合は、ぜひお知らせください。

別の注意: もちろん、チームが成長する可能性があるため、適切に拡張できるシステムが必要になります。

さらに別の注意: 私たちは、Windows で 3 つの別々のソフトウェア アプリケーションに取り組んでいます。これらはすべて、私たちが作成した中央ライブラリに基づいています (つまり、4 つのプロジェクトと言えるでしょう)。

私たちは最近スクラムを仕事に採用し、コードが受け入れられた後に現れるたくさんの小さなバグで問題にぶつかっています。これには、スペルミスやその他の1行の修正などが含まれます。小さなことごとにサイズ0.5のストーリーを作成するのは、時間の無駄のように思えます。ストーリーを書き、それを指摘するのは、修正するよりも時間がかかります。スプリントごとにこれらが1つか2つしかない場合は、それらを修正するだけで、ストーリーを作成する必要はありません。ただし、アプリケーションが大きいために10個または20個以上ある場合は、スクラムでは考慮されていない開発者の時間が大幅に増える可能性があります。そもそも元のストーリーが受け入れられる前に、QAスタッフとプロダクトオーナーはもっと徹底するべきだと言うのは簡単かもしれませんが、私は

これまでに思いついたいくつかの不完全なアイデア：

• 「アプリで修正されたバグの90％」というストーリーがあり、そのスプリントで発生するバグの数と修正できるバグの数を推測し、予想されるワークロードに基づいて指摘します。
• たとえば、スプリントの最後に常に受け入れられるサイズのストーリーを用意して、できるだけ多くのバグを修正します。これには明らかに、誰もが実際に8分の仕事をしているという大きな信頼が必要です。
• バグを記録しますが、次のスプリントまでバグに取り組みません。それらは、個別にまたはグループとして指すことができます。これには、より「汚い」という利点がありますが、基本的に1時間の修正で3週間の遅延が発生します。

助言がありますか？

私はかなり小さなスタートアップで、スクラム/アジャイル開発サイクルの形式を使い始めました。

多くの点で私はスクラムを楽しんでいます。スプリントは比較的短く（2週間）、チームの進捗状況を追跡するためのバーンダウンチャートが好きです。フィーチャーボードも好きなので、次に何をすべきかを常に知っています。ボードからフィーチャーのカードを取り出し、それを完成させてから、バーンダウンパイルに入れるのは気持ちがいいです。

しかし、私たちは今、18回目のSprintリリースサイクルに入っており、少し燃え尽き症候群を感じ始めています。私が仕事や同僚が好きではないということではなく、これらのスプリントが...まあ、スプリントであるということだけです。最初から最後まで、私は文字通り、開発速度を維持するために時間と競争しているように感じます。スプリントが終了したら、1日かけて次のスプリントの機能セットと見積もりを計画し、それからまた出発します。

成熟したアジャイル/スクラム開発プロセスで働く人々にとって、これは正常ですか？それとも何かが足りないのですか？通常、スクラム環境で、割り当てられていない/追跡されていない時間に、いくつかの小さなことを実行し、頭をすっきりさせる時間がありますか？

私が働いているソフトウェア開発環境では、すべて同じ (Java) コードベース (現在は SVN を使用) で作業している開発者のグループがいます。「ビルドを壊す」ことなく、自分が構築したものをコミットしたいという人が多いことに気付きました。そのため、私は Git や Mercurial など、分岐、特にマージをより簡単にするツールに注目しています。

私が目にすることの 1 つは、開発者が「悪いコード」をコミットすると、そのコードはすべての人にとって壊れてしまうということです。これを回避するためのアイデアとして、その単一の新機能の変更セットを 1 つだけ持つ、単に現在の「マスター」である「中間の単一機能」リポジトリを持つ方法が必要です。このような「中間の単一機能」リポジトリは、メイン コード ベースの一部になる前に、自動的にテスト (コード品質、単体テスト、手動コード検査など) できます。

したがって、私が念頭に置いているワークフローは次のようになります。

1. 開発者は新しい機能を作成し、これをローカルで毎日コミットします。
2. しばらくすると、開発者は終了し、変更セット全体を送信して「メイン」リポジトリに統合します。
3. 継続的インテグレーション システムは、現在の「マスター」を取得し、変更セットを適用してコードをチェックし (マージの競合、PMD、Findbugs など)、単体テストを実行し、コーディング スタイルをチェックします。
4. CI システムが「悪いコード」と判断した場合、開発者には理由が通知され、開発者は言及された問題を修正する必要があります。この場合、メイン リポジトリは変更されません。
5. CI システムが「十分である」と判断した場合、コードは「主任開発者」または「コード レビュー担当者」に届き、選択されたソリューションを検査して承認または却下されます。
6. 承認された変更セットはメイン リポジトリに含まれ、すべての開発者がリベース/マージできるようになります。

この種のワークフローについていくつか質問があります。

• これは実際にうまくいくと思いますか (つまり、これは良いアイデアですか、それとも本当に頭がおかしいものですか)?
• 以前にこのような作業をしたことがある人はいますか? 長所と短所は何でしたか？
• そのようなワークフロー (またはこのアイデアのバリエーション) を最小限の時間で開始できるようにする「すぐに実行できる」スクリプト/手順/ツール/... はありますか?

ありがとう。

背景メモ:

私は約 13 年前に会社で開発者として働いていました。彼らは社内で同様のワークフローを構築し、2 つのナイトリー ビルドを行っていました。

1. 「本番」バージョン: メイン コード ベース
2. 「シニア バージョン: すべての変更されたファイルのすべての新しく送信されたバージョンを含むメイン コード ベース。

これはすべて SCCS (lock-edit-unlock モデル) ベースであったため、「頻繁にコミット」する方法がなく、コードの変更やその他すべての厄介な影響によるデッドロックが発生しました。私が探しているのは、主に、当時使用していたものの良い点と、今日のはるかに優れたツールを使用していることです。

最近、職場で、ある人が自分でコードに取り組んでいると、他のチーム メンバーがそれを見て、「あれは醜い、扱いにくい、書き直す必要がある」という問題に遭遇しました。それ"

実際、最近、私自身、(関連する) 機能を追加できるように、前の週に書いたものをリファクタリングする必要がありました。

ペアプログラミングがそのための方法であることはわかっていますが、私たちのチームはバラバラです (メンバーは 3 人です)。現在、私たちのチームはかなりのプレッシャーにさらされているため、ピア レビューを行う時間は本当にありません (ただし、ペア プログラミングを行うことはできますが、タスクの見積もりにそれを見積もることが許可されているためです)。

貧弱なコードが生成されることで、これらの問題を克服する方法を人々がどのように提案するかについて、私はただ興味があります.

アジャイル開発プロジェクトに取り組んでいる場合、ユーザー ストーリー/ユース ケースなどの時間の見積もりにどのように組み入れますか? プロジェクトで使用されているなじみのないテクノロジーについて、新しい開発者をトレーニングするのにかかる時間?? 他のマネージャーはこれをどのように処理しますか?

もちろん、私の質問は、問題の技術がプロジェクトを成功させるために必要であると考えていることを前提としています...あるいは、技術的負債の一部を返済していると見なすこともできます!

私たちはソフトウェア開発会社です。スクラムを導入しました。
問題は、開発者が他の多くの企業のようにスクラム スプリントにフルタイムを費やすことができないことです。彼らは、SCRUM プロジェクトのタスクのうち、多くの非開発を行わなければなりません!
私はそれを読みました：スクラムはパートタイムの開発者を許可していません

それで、これについてあなたの経験は何ですか？
スクラムは、SCRUM スプリントに焦点を当てた開発タスクにのみ時間を費やす開発者がいるチームにのみ適した方法ですか?

御時間ありがとうございます