1 人の開発者が 3 つの異なるプロジェクトに取り組んでいます。彼は以前、バグ修正、メンテナンス、およびいくつかの機能の実装に取り組んでいました。ある特定のプロジェクトでは、もう 1 人のジュニア開発者と協力しています。
私たちの会社はすべてのプロジェクトにスクラムを実装したいと考えています。
2991 次
5 に答える
12
単純なばかげたままにしておく必要があることに同意しますが、スクラム フレームワークのほとんどはここで使用できます。
プロジェクトとメンテナンス/運用作業の両方で、この方法で働いている人が何人かいました。
プロダクト オーナー/バックログ - ビジネス価値の定義と優先順位付けを担当するオーナーがまだいますよね? バックログはまだそこにあるはずです。彼がより大きなスクラム エンタープライズの一員である場合、おそらくより大きなプロダクト バックログの一部を利用する必要があります。
スクラム チーム - はい、1 人または 2 人のチームです。つまり、それは本当に自己組織化されています...しかし、それは問題ありません！デイリースクラム？はい、2 人の間で、または時々その 1 人だけの場合は、タスクと問題を検討する良い機会です。スクラム オブ スクラムまたはプロダクト オーナーに対してどのような障害を表面化させる必要があるかを考えてください。
スプリント - スプリントで作業している大規模なスクラム エンタープライズの一部である場合はなおさらですが、それがなくても良い考えです。PO に追いつき、得たものをデモンストレーションし、自分自身を活性化し、振り返り、より良くできることを確認し、次のスプリントの計画を立てる良い機会です。スクラム エンタープライズ/スクラム オブ スクラムの外で作業する場合、スコープがおそらく小さく、計画のオーバーヘッドが低いため、スプリントを通常よりも短くすることでメリットが得られることに注意してください。しかし、それは状況によって異なります。
回顧展 - はい、単独で開催できます。キラー プログラマーは、自分の作業や進捗状況を振り返り、妨げとなっているものに対して行動を起こす必要があると思います。ワークスペースにグラフを置いて、進歩を助けることもできます。
タスク ボード / バーンダウン - はい、必要です。壁の作業スペースに置くことができます。小さくてもかまいませんが、1 人でも本当に役に立ちます。GTD (Getting Things Done) が 1 人の人を助け、TB/BDC が助けないのはなぜですか? その人がプロジェクト作業を行っている場合、スプリント バーンダウンとリリース バーンダウンは多くの価値を提供します。彼が運用/保守作業を行っている場合でも、それは彼が順調に進んでいるかどうかを確認し、それに応じて関連する措置を適用する方法です.
スクラム マスター - その人は自分自身のスクラム マスターであるべきです。
コーチ - 組織にチーム/SM/PO を支援するコーチがいる場合、彼はこのスクラム セルも支援する必要があります...
要約すると、スクラム/アジャイルの根底にある価値観と原則が 1 ～ 2 人のチームにも当てはまることは明らかです。また、ほとんどのスクラムも同様に適用できることは明らかです。
質問は、関係者がどう思うかです。
経営陣、開発者、PO が全員参加し、価値観や原則が理にかなっていると信じ、改善に努めれば、うまくいくでしょう。そうでない場合は、最初に全体的な考え方が理にかなっている点に到達し、次に個々のチームに対処します...
于 2009-04-21T11:20:18.483 に答える
6
SCRUM の理想的なチームは 8 ～ 10 人です。ですから、このような小さなチームでどのように機能させることができるかわかりません。
一般に、スクラムまたはアジャイル プロセスは、管理者によって誤解されています。スクラムの成功率について読むだけで、管理職に「やりたい」という魅力が生まれます。
すべての SCRUM 実装には、次の 2 つの側面があります。
- プロセス: スタンドアップ ミーティング、ふりかえりミーティングなど。
- エンジニアリング プラクティス: 明確な要件 (ユーザー ストーリー) の作成、テストの自動化、継続的な統合など。
私見、ここであなたの経営陣はエンジニアリングの実践と（おそらく）いくつかのプロセスも楽しみにしています。
これらを少しずつ取り入れて、今よりも体調を良くすることができます. （少なくとも経営陣の目には;-)）
于 2009-04-14T10:55:49.243 に答える
4
たぶん、ここでは SCRUM はやり過ぎです。作業パッケージと基礎となるタスクに編成します。
最良の方法？シンプルにバカにしてください。多くの管理オーバーヘッドでプロジェクトを肥大化させないでください。スクラム タスクにソフトウェアを使用する必要はありません。Redmine / JIRA などの問題トラッカーは、進捗状況を追跡してタスクを割り当てるのに便利です。ただし、マグネットとメモ (タスク名) がいくつか付いたホワイトボードを使用することもできます。したがって、ボードを介してタスクを割り当てることができます ;)
于 2009-04-14T10:47:56.233 に答える
3
私の経験では、スクラムは、既存の責任を持つ数人の小さなチームのプロジェクトに関連する可能性があります。理由は次のとおりです。
- それでも、タスクのブレークアウトと詳細な見積もりが促進されます。
- スプリントはまだ設定された作業単位であり、範囲や期間を変更するべきではありません。
- 毎日のスタンドアップミーティングは、今でも定期的な議論を促しています。
- あなたはまだ反復サイクルで配信します。
- 追跡するバーンダウンチャートがまだあります。
- あなたはまだ遡及的継続的改善段階を持っています。
これらはすべて、2人のメンバーのチームまたは8人のメンバーのチームに等しく関連しています。「スクラムを実行する方法は1つしかない」とか、それを機能させるには少数の人以上が必要だと言う人に殴られてはいけません。
于 2009-05-04T22:06:45.500 に答える
2
スクラムは、ここでは間違いなくやり過ぎです。さらに、スクラムが特効薬だと考えたり、プロジェクトに実装できなくても取り残されたと感じたりしないでください。37signals の Getting Real や、物事を無駄のない状態に保つためのその他のリソースを読むと、1 人か 2 人の専門分野を超えたチームと協力することは、1 人か 2 人の関係者が意欲と能力を持っていれば、実際には非常に生産的なユニットであることがわかります。
Martin K. が述べたように: シンプルに保ちましょう。たった1人か2人で、「プロジェクト管理」などは必要ありません。がらくたを切り取って、ただそれをしてください。
(だからと言って、予算や支出を追跡して進捗状況を測定するべきではないと言っているわけではありませんが、必要のないインフラストラクチャに時間とお金を浪費してはいけません)
于 2009-04-20T20:49:01.867 に答える