スクラムをボランティア設定にどのように適合させることができますか？

私は最近、まだ自分自身をセットアップしている若いハッカースペースに参加しました。幸いなことに、このスペースには作業が必要な内部プロジェクトがいくつかあり、作業を行うボランティアが不足していません。

これらのプロジェクトを整理する方法についていくつかの議論がありました。私の最近の専門的な経験はスクラムであったため、ソフトウェアプロジェクトにスクラムアプローチを提案することを検討していますが、それが適切かどうかはわかりません。

スクラムはフルタイムの小規模なチームでうまく機能しますが、この組織の性質は異なります。

• メンバーはボランティアです。一部はフルタイムの学生です。他の仕事はフルタイムで仕事をしています。実際の生活が優先されるため、誰からも一定レベルの貢献は期待できません。
• ほとんどすべての人がソフトウェアを作成する長年の経験を持っていますが、専門家やチームでこれほど多くのメンバーはそうしていません。
• プロダクトオーナーはいません。これらのプロジェクトの要件は、委員会によって決定されます。この委員会のメンバーも実装に取り​​組んでいます。つまり、専任の専任のプロダクトオーナーはいません。
• 期限はありません（ソフトまたはハード）。プロジェクトは完了すると完了します。

これらはかなり重要な違いですが、私は彼らがスクラムを適用するためのブロッカーになるとは確信していません。ちょっとした微調整でこのハードルを克服できると思います。

• スプリントを固定してストーリーポイントサイズを固定するが、継続時間（時間）が流動的である場合、ボランティア開発者に非現実的な配信のプレッシャーをかけることなく、繰り返しのリリースから利益を得ることができます。
• バーンダウンチャートと速度計算を捨てることができます。私が正しく理解していれば、これらは開発チームと経営陣の間の橋渡しとして機能するツールと指標です。開発者と利害関係者の両方にとって意味のある形式で進捗状況を報告するのに役立ちます。報告する人がいない（プロジェクトマネージャー、プロダクトオーナー、外部関係者がいない）ことを考えると、これを完全に削除できると思います。

微調整を必要としないメリットがあると思います。

• 要件収集会議（複数可）。全員がテーブルの周りに座って、ユーザーストーリーについて議論し、UIモックをスケッチし、製品バックログを作成します。
• スプリントの回顧展。これは、ボランティアチームとして機能する開発プロセスに集中するための興味深い方法です。

よくわからないこと：

• 毎日のスタンドアップはどのように扱われるべきですか？私たちの環境では、彼らは非常に価値があるのでしょうか。スタンドアップ式の儀式についての私の理解は、チーム全体に自然に情報を広めることでコミュニケーションを支援することです。私たちのスプリントはおそらく平均的なスプリントよりもはるかに少ない複雑さを提供する可能性があるという事実を考慮すると、他のすべてのチームメンバーの進捗状況/開発に遅れをとる必要が少なくなる可能性があります。
• 継続的インテグレーション、コードレビュー、TDDなどのXPを推進すべきですか？私はこれが多くを求めているのではないかと心配しています。人々がスクラムに精通し、チームとして働くようになれば、将来のプロジェクトでこれらの概念を取り入れたいと思うでしょう。

私の質問：

スクラムはボランティアベースの環境に適応できますか？
そして、私の計画したアプローチはこれまで正しい方向に向かっていますか？

かんばんを見てください。制約には、SCRUMよりも適切です。

編集：SCRUMは（非常に大雑把に）スプリントとセレモニーを備えた順序付けられたバックログであり、「進行中」の作業量を制御し、すべてのスプリントの最後に確実に何かを確保します。セレモニーとスプリントのリズムを捨てると、カンバンになります：順序付けられたバックログと、「進行中」の作業を直接制限し、「完了」とマークされたすべてが確実に終了することではなく、各スプリント。

アジャイルの利点は引き続き得られます：いつでもリリースできる、柔軟性、予測可能性のある程度の尺度-SCRUMはその側面を少しだけ進めますが、SCRUMのセレモニーや側面がなく、コミットメントのないゆるく分散したチームにうまく適合しません。キャッチ？セレモニーの溝を掘るにはより多くの規律が必要なので、テスト、コードの品質、進行中の現在の作業に注意を払い、バックログのトップ（人々がピックアップする準備ができているもの）が十分に精巧に作られていることを確認する必要があります。

投票ベースのバックログを作成することもできますが、ボランティア設定では、何でもやりたいことに取り組むことができます。

（そして、はい、すべてのTDD、CI、レビュー、およびピアプログラミングのアイデアは良いアイデアです）。

最初に注意する違いに対処するには：

• メンバーがボランティアであることは、コミットメントを求めることができないということではありません。特にスクラムでのスプリントの期間が比較的短い場合、各メンバーは今後数週間プロジェクトにどれだけの時間を費やすことができるかを知る必要があります。チームメンバーを各スプリントごとに異なる時間だけ空けておくと、現実的なストーリーポイントの数を判断するのが難しくなりますが、スクラムが実行不可能になるわけではないため、計画は少し難しくなります。
• 製品所有者は、利害関係者が製品に対して持っているビジョン（および要件）を統合し、開発チームに伝える責任があります。統合部分は、おそらく「ステアリング」委員会によってすでにカバーされています。コミュニケーションの部分では、メンバーの1人を主要なスポークスマンとして委任することができます。その場合、すべての実用的な目的のために、製品の所有者になります。
• 外部の締め切りがないことは、スクラムにとって本当に問題ではありません。製品を完成させるためには、チームが製品に誇りを持っていることが重要です。スクラム自体には、各スプリントの自然な期限があります。

提案された適応に関して、特にボランティアと協力する場合、スプリントの長さを固定することを強くお勧めします。こうすることで、ボランティアはどの期間に自分のコミットメントを放棄しているのかを明確に知ることができます。

また、すぐにバーンダウンチャートを捨てません。また、チーム自体がコミットメントでどのように機能しているかを確認するのにも役立ちます。私はそれをチームに任せて、それらを維持するか捨てるかを決めるでしょう。同じことが速度計算にも当てはまります。特に、各スプリントで使用可能な工数が大幅に変動する場合、将来のスプリントを推定する際に（特に工数あたりの完了ポイント数を計算する場合）非常に有用であることがわかります。

毎日のスタンドアップに関しては、誰もが何をしているのか、何に問題があるのか​​（そしてそれは複雑さから独立している）を知らせるためだけに、それらはあなたの設定でまだ役に立ちます。しかし、毎日の立ち上がりを実現するのは難しいかもしれないので、そこで妥協する必要があるかもしれません。

言及したXPプラクティスは、スクラムの使用とは無関係に導入することもできますし、回顧中に提案することもできます。

誰もそれを指摘しなかったことに驚きましたが、あなたのプロジェクトはほとんどのオープンソースプロジェクトのように思えます。人気のあるオープンソースプロジェクトをチェックすると、インスピレーションが見つかるかもしれません。そして、SCRUMを忘れて、一般的なアジャイルの観点からこれについて考える必要があると思います。

アジャイルはコミュニケーションとコラボレーションに関するすべてです。アジャイルマニフェストで4点中2点がそれについて話す理由があります。

プロセスとツールを介した個人と相互作用

契約交渉を介した顧客コラボレーション

また、プロジェクトを説明する方法では、プロジェクトで作業している全員と直接顔を合わせてコミュニケーションを取ることは困難であり、アジャイルとSCRUMの両方が奨励しています。私が最初に注目するのは、チーム全体（ボランティアと製品委員会の両方）のコミュニケーションチャネルを確立することです。ウィキ、フォーラム、ビデオ会議、適切なバックログ、タスク、バグ追跡システムなどは、何が起こっているのか、何をする必要があるのか​​を誰もが確実に知るための素晴らしい方法です。

2番目に注意することは、アジャイルの技術的な部分をただブラッシングすることではありません。多くの人は、自分自身がアジャイルな仕事をするものであり、物事のプロセス面ではないと信じています。コードレビューは重要であり、プロジェクトを知っている誰かがコミット/プッシュをレビューして、十分に高い品質が維持されていることを確認することによる、ほとんどのオープンソース作業です。TDDは、あらゆるアジャイルプロジェクトに対して実際に提供されます。ボランティアが他の人のエラーや間違いを修正するために迷惑をかけることができない場合には、コードの変更が以前の機能を壊さないようにします。また、レビュアーはテストで追加された機能をテストで確認でき、それらを実行することで機能が意図したとおりに実際に機能することを確認できるため、コードのレビューも容易になります。継続的インテグレーションはTDDと同じです。

最後に、プロジェクトにフルタイムで作業する人が少なくとも数人いるべきだと思います。それらの人々には特定の役割が必要です：

• プロダクトオーナー：これに専任の委員会がいるのは素晴らしいことですが、この委員会の言葉を仕様やユーザーストーリーに解釈し、それらが適切に実装されていることを確認する担当者が1人いるはずです。
• コーディネーター＆スクラムマスター：この人は、プロセス全体を担当し、プロジェクトで起こっている重要なことを全員が確実に把握できるようにする必要があります。また、彼はwikiとタスク＆バグ追跡ツールを保守しています。誰かがプロジェクトについて質問がある場合、これは彼らが尋ねるべき最初の人です。
• 主な開発者および設計者：コードを最もよく知っている人。彼はコードレビューを行い、コードの品質がアジャイル開発に十分であることを保証します。

あなたが記述している方法でそれを適応させることはできず、それをSCRUMと呼ぶことはできません。しかし、私の意見では、説明したセットアップに次のようにスクラムを使用できます。

1. 反復を修正しました。進捗状況を測定できるように。これは、管理のためだけでなく、チームのパフォーマンスを「知る」ためでもあります。
2. 反復の開始時に能力を共有するようにボランティアに依頼します。すべてのチームは、メンバーがコミットしていることを必要とします。そうしないと、特定のメンバーがより専門的に行われた仕事のためにチームを離れることがあります。
3. 期限がないことは問題ありません。スクラムはそれを強制しませんが、各反復の終わりに行うことは潜在的に出荷可能でなければなりません。これにより、それまでに行ったこと（機能している）に基づいて、次に何をするかを決定できます。
4. 製品所有者がいないことも同様に機能します。ランクバックログをスタックし、作業を承認/拒否するための何らかの投票システムを使用できます。
5. 要件の収集はスクラムの一部ではありません。とにかくやりたいことができます。ただし、反復スコープの一部としてそれを含めないでください。そのための別の容量があります。そのため、反復では、要件が明確な作業のみを計画します。たとえば、チームは受け入れ基準を知っています。
6. 回顧は良いです。したがって、スクラムをそのまま開始しますが、回顧を使用して、何が機能していて何が機能していないかを確認します。
7. 毎日のステータスは必須です。これにより、チームが互いに同期する機会が与えられます。つまり、他のメンバーの成果物が利用できないためにタスクが不必要にブロックされないように、チームが努力を調整します。
8. XPは良いです。XPに基づいて、doneの厳密な定義があります。たとえば、レビューしない限りコードは入りません。より少ないことでより多くのことを..

別のアプローチをお勧めします。ボランティアを扱っているので、考慮すべきことがいくつかあります。あなたのチームはおそらく高い離職率を持ち、人生は邪魔され、人々は気を散らされます。残されたもののうち、少数は一貫して貢献しますが、あまり貢献しません。最後に、あなたは本当にハードコアなグループがプロジェクトに夢中になります。私はここであなたの労働力について多くの仮定をしています。私の評価があなたが働いている人々を反映していないと感じたら、これを無視してください。

今、あなたは多くの仕事をしていない人々がかなり自律的に働くことができるようにする戦略を必要としています。コミュニケーション中。より複雑な人々は、より複雑なアイデアの一部を統合し、洗い流す責任があります。

これにより、ワイヤーフレームとプロトタイプに焦点を絞った開発プロセスを考えるようになります。

利用可能な作業項目のプールを用意し、それらにワイヤーフレームを書くように人々に勧めることができます。これらをTracer Bullets（Pragmaticプログラマーから借用した用語）として使用して、アイデアに磨きをかけ、人々にインスピレーションを与えます。そこから成功したアイデアをプロトタイプに卒業することができます。これもまた、人々がプロジェクトについてもっと学ぶのを助けるように設計された非常に小さなプロジェクトです。その後、多数の人々によって構築された堅実なアイデアの小さなセクションがあり、もう少しアクティブなチームの一部に引き渡すことができ、彼らはそれらのアイデアをシステムに統合するために働くことができます。

かんばんはこのような状況に適していると思います。

スクラムには適合しないものがいくつかあります。タイミングやスコープの測定は不要であり、開発中のeveroyoneは会議と同じ製品ビジョンを持っています。説明責任と一貫性のある短い計画に従うことがビジネス目標です。

かんばんには、スクラムと同じ利点が多くありますが、欠点はありません。迅速なプロトタイピングが可能です。プロタイプは、会議の前に実行できます。また、変更可能なコードとリグレッションテストのTDDも提供します。ペアプログラミングでは、知識を伝達することで、初心者や非常連のコードベースを容易にすることができます。

かんばんには、独自の利点もあります。ユーザーが行うことのビジョンが並行して開発されている場合、かんばんはうまく機能します。その証拠は、中小企業プログラムの成功です。また、3人などのボランティアが少ない日でも、かんばんはうまく機能します。スクラムは、軽量であるにもかかわらず、黄色のテープが多すぎます。