問題タブ [scrum]

成功している大規模なオープン ソース プロジェクトのほとんどは、慈悲深い独裁者スタイルの組織に従っているようです。しかし、オープンソースでのアジャイル開発の成功例があるかどうか疑問に思っていました. オープン ソースについて言及するとき、私が意味するのは、同じ屋根の下でオープン ソースを行う確立されたチームではなく、大規模なネット コミュニティ主導の開発を意味します。

1 人の開発者が 3 つの異なるプロジェクトに取り組んでいます。彼は以前、バグ修正、メンテナンス、およびいくつかの機能の実装に取り​​組んでいました。ある特定のプロジェクトでは、もう 1 人のジュニア開発者と協力しています。

私たちの会社はすべてのプロジェクトにスクラムを実装したいと考えています。

新しい開発者がチームに参加するか、開発者が変更を使用しているコンピューターを使用するたびに、開発者は、現在のプロジェクトを機能させるためにローカル開発環境をセットアップするために多くの作業を行う必要があります。SCRUMチームとして、展開とテストを含むすべてを自動化しようとしているので、私が求めているのは、ローカル開発環境のセットアップを自動化するためのツールまたはプラクティスはありますか？

たとえば、環境をセットアップするには、最初にEclipseをインストールし、次にSVN、Apache、Tomcat、MySQL、PHPをインストールする必要がありました。その後、DBにデータを入力し、さまざまな構成ファイルなどに小さな変更を加える必要がありました...この労力をワンクリックに減らす方法はありますか？

私たちは中規模のエンジニアリングショップ（10-20）です。私たちは、ユーザーが直面するストーリーの作業に優先順位を付けて構造化し、顧客を幸せにすることに長けています。しかし、靴屋の子供たちは靴を持っていません。顧客に関するものでなければ、プロセスはありません。

QA環境（この場合はかなり重い）、継続的インテグレーションシステム、パッケージングなど、開発者向けの作業を正しく優先して実行し、開発ショップを運営し続けるためのシステムを探しています。

現在、リソースは常に制限されています。私たちは、靴屋の子供たちに10足の最も素晴らしい靴と、特別な自転車靴をブーツに与えたくありません。私たちは、他の開発に適用されているのと同じ規律を持って、適切で必要な作業を行いたいと考えています。

どのシステムがあなたに適しているか教えてください：ユーザー向けではない作業に優先順位を付けて整理する方法は？シンプルでスクラムとスムーズに統合できるシステムが欲しいです。

（このテキストの上部にある赤いボックスを知っています。これは、Stack Overflowの自動質問パーサーが、これは答えられない主観的な質問であると考えていることを示しています。実行可能であることが証明されています-そしてプロセスはプログラミングに不可欠です。それで、ここに私たちのプロセスを表すいくつかの疑似コードがあります。このアルゴリズムを修正してください）。

明確にするために投稿を編集しました（元の投稿は下部にあります）。

R&D スタッフを水平 (つまり、専門分野またはコンポーネント ベース) のチームから垂直 (つまり、機能、自給自足) のチームに再編成したいと考えています。最終的には、製品のほとんどの側面で共同作業できる開発者と QA エンジニアを含む 3 ～ 4 チームになる可能性があります。ただし、資格のある DBA とテクニカル ライターは 1 人しかいません。私は 1 つのチームに DBA を配置し、最も複雑な DB 作業を必要とする機能を彼のチームに与え、DBA がいないチームにはより些細な DB 関連のタスクを与えることができます。

ただし、ほぼすべての機能でドキュメントを更新する必要があり、ドキュメントはほぼすべての機能で完了しなければならないタスクです。テクニカル ライターは 1 人だけです。残りの開発者は、母国語ではないため、ドキュメントを作成するために必要なスキルを持っていません (学習することもできません)。

縦型チームでそのようなリソースを処理するにはどうすればよいですか?

1. ライターはどのチームにも属していませんか? それは、チームが自分で「完了」することを不可能にします。
2. ライターをすべてのチームの一員にする必要がありますか? もしそうなら、どうすればすべてのチームのミーティング (毎日、計画、ふりかえり) に参加できますか?
3. 彼を 1 つのチームのメンバーにしますか? どれ？すべてのチームが平等に彼を必要としています。他のチームは彼なしでどうやって「完了」するのですか?

ありがとう、アサフ。

オリジナル：

私たちの会社は、スクラムの生き方を採用し、機能をチームに割り当て、その機能をチーム内で「完了」(つまり、完了の定義に従って) できるようにしたいと考えています。

ただし、一部のスキルは、チーム内の十分な人数が所有していないため、各チームにスキルを割り当てる必要があります (例: テクニカル ライター、DBA、統合スペシャリストなど)。

ほとんどが縦型のチームで、リソースが限られた専門家にどのように対処しますか?

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

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週間の遅延が発生します。

助言がありますか？