一人のプログラマのためのスクラム？
私は、自分自身、販売およびトレーニングの役割で働いている機械エンジニア、および設計、開発、サポートの役割で働いている会社の社長で構成される非常に小さな会社の「Windowsエキスパート」として請求されます。
私の役割も同様に一般的ですが、主に私は、Windowsのどのバージョンでも最新のものを実行するために製品で実行する必要があるプログラミングを設計および実装します。
私はウェブキャストで与えられたスクラムパラダイムの高レベルの概要を見終わったところです。私の質問は次のとおりです。私の開発作業項目は通常「製品の国際化とローカライズ」などの非常に高いレベルで与えられるので、この製品開発へのアプローチについて学ぶ時間はありますか。
もしそうなら、たった一人のプログラマの使用のためにスクラムをどのように適応させることを提案しますか？そのためには、クラウドベースなど、どんなツールが便利でしょうか？
そうでない場合、一人のプログラマーが日々の努力を整理するためにどのようなアプローチを提案しますか？ （おそらく、質問はその単純な質問に減少します。）
スクラムを学ぶ：はい。あなたの一般的なスキルセットに追加するためにそれについて学ぶためだけなら。 （しかし、その「スクラム禁止」のフレーバーはおそらくあなたが探しているものです...）
スクラムは素晴らしいフレームワークですが、コアとなる信条は「反復（スプリント）は一定の期間でなければならない」です。私は、これよりも割り込み駆動型の非常に小さなチームでこの作業を見たことはありません。本当にサインアップして、一定の期間（1週間？）で作業することができれば、スクラムはクールなフレームワークです。それができない場合...スクラムは、他のことにもうまく変換できるいくつかの優れた概念を持っているので、学ぶのに最適です。
バックログ-スクラムの有無にかかわらず、実行する必要があることの優先リストを保持します。私はExcel（またはGoogle Doc Spreadsheet ...）が好きです。あなたが非常に小さなチームであれば、私は非常に小さなツールを保持します。 （スプレッドシート>>簡単に並べ替えできるため、ワードプロセッサ。）
計画とコミットの分離-抽象表記（ポイント）で計画し、一貫している（8ポイントは約2倍の4ポイントストーリーと4倍の2ポイントストーリーです）「作業を行う」ときは、問題を再検討し、スケッチします。時間で。ポイントを変更しないでください。
コミットメント-コミットするときに他の人に見えるようにして、コミットメントを実行します
振り返り-あなたが納品した後、何がより良くできたのかを考えます。
などなど.
スクラムは、それが良い出発点になるかもしれないことを理解するのに十分簡単です。よろしければ、「スクラム禁止」バリアントの使用を検討してください- http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban 。それをサポートするために適度にアクティブなコミュニティで「十分に文書化されている」ほど私を襲うものはありません。
また、Alistair CockburnのCrystal手法（http://alistair.cockburn.us/Crystal+methodologies+main+foyerおよび http://www.Amazon.com/Crystal-Clear-Human-）もお勧めします。 Powered-Methodology-Small/dp/0201699478/ref = ntt_at_ep_dpt_ ）ですが、より多くの読み取りと掘り下げが含まれます。
XPのようなものは、特定のプラクティスの詳細を提供するので、私はこの本も読んだと思います： http://www.Amazon.com/Extreme-Programming-Explained-Embrace -Change/dp/0321278658/ref = sr_1_1？s = books＆ie = UTF8＆qid = 1304359834＆sr = 1-1
最終的な読書のアドバイス：アジャイルマニフェストに同意し、次の原則に従う限り： http://agilemanifesto.org/principles.html きちんとした形である必要があります。
個人的な推奨事項：TDDを採用（交渉不可、IMHO）バックログを維持（スクラムに従って）常に優先度に基づいてサイズと並べ替えを維持する「中断の間に行うには大きすぎる」ものを分解する小さなチャンクに優先度を設定/レビューする2つの項目が同じ優先度になります。）ビルド環境を5〜10分で（ラボ環境に）ビルド/テスト/デプロイできるようにします。顧客（内部および外部）にストーリーを完成させた結果を表示します。ストーリーが完成するまであなたの顧客は同意します。パイルの一番上からストーリーを引き出し、現在のストーリーを完了するときに作業を進めます。一度に2つ以上のアイテムを開いたままにしないでください。別の作業を開始する前に、1つの注意散漫を終了してください。自分の仕事に誇りを持ち、毎月1回、完成したすべての製品/機能をチーム/会社に見せてください。
お役に立てれば
製品のバックログ、優先順位付け、相対的な見積もり、増分配信など、スクラムで使用されているいくつかのプラクティスを使用できますが、自己組織化されたクロスファンクショナルメンバーのチームによる製品開発を管理するプロセスとしてスクラム全体を使用することは、おそらく一人のショーに行く方法ではありません。
問題は、ワークアイテムを少しずつ細かく分割できるかどうかです。ほとんどのプラクティスを使用しないと意味がありません。また、スクラムは製品の所有者/顧客との高度な協力についてです。 「ここにあなたは割り当てがあり、それが完了したら戻ってくる」のようであってはなりません。
私は1人のSrumに対して何も反対しませんが、1人のカンバンプルシステムは非常にうまく機能すると言います。かんばんと自動化された単体テストを組み合わせることで、生産性が大幅に向上し、「文書化」されました。どちらも本当に方法論ではありませんが、より多くのツール（およびそれとは非常に異なるツール）ですが、どちらも大きなソロプロジェクトを一口サイズのピースに分割することを強制し、それぞれにもっと多くのことを実行するように促す一種の儀式を与えます日。 「すべてのテストを実行」をクリックして各項目が緑色になるのと同じくらい満足できるものはありません...かんばんボードの「進行中」列から「テスト中」（または完全にボード外）にカードを移動する以外は何もありません。 。
ソロ作業の本当の問題は、開発者のグループを対象とした複数の方法から選択して、自分に最も合うように調整することです。 最終目標は、実際には、説明責任を持ち、生産的で、幸せな状態を保つことです。自分より上手にそれを行う方法を知っている人（ここから少し引いて少しずつ）。
一人で働いていた時にやってみました。うまくいったことは：
- すべての作業項目をホワイトボードに置く。私はすぐに、どのような傑出した仕事があったかを知ることができました。依存関係と妨害があった場所。また、多くの人が私の掲示板に立ち寄ってそれを読んだり、チャットをしたりしていました。 「オタク」が一日中何をしていたかを理解するのに役立ったと思います;-)
- バーンダウンチャートも素晴らしいものでした。これにはExcelを使用しました。それにより、その環境での見積もりをより良くすることができました。それは私がイテレーションでどこに向かっていたかについての素晴らしい概観を私に与えました。技術者ではなかった私のマネージャーも、機能に関係するさまざまなものすべてがどこにあるのかを見ることができるので、これも気に入りました。
- 毎日のスタンドアップ。まあ私ができる限り。毎朝、すべての作業項目とバーンダウンチャートを更新し、解決する必要があるすべての障害を書き留めました。
- 自動テストと継続的インテグレーション（MSTest/TFS）、できればTDDは、任意の方法論を使用する開発チームを支援しますが、ここで言及する価値があります。
- 短い反復（1週間）は、何かを提供することに集中するのに本当に役立ちました。
- バックログを維持することは素晴らしいことでした。新しい仕事が与えられたとき、それを他のすべての仕事のコンテキストに配置して、製品の所有者に優先順位を付け直すことができたからです。
うまくいかなかったのは：
- 自分で作業しても、志を同じくする人々とコラボレーションすることで、そのような後押しはありません。または、競争と集中の感覚は、本当に素晴らしい士気と文化を持つチームから生まれます。行き詰まったときに選ぶべき他の頭脳はないので、そのような閉塞はデイリースタンドアップのスクラムマスターによって排除することはできません。
- スクラムマスターはありません。したがって、中断を止める人はいません。いつも他のことについて質問したり、自分の流れを壊したりする人たちと、私は多くの問題を抱えていました。優れたスクラムマスターの下では、そのようなものは傍受され、乗り込むことができます。私は人に失礼なことをしたくなかったので（多分私は柔らかくて）、それが問題でした。また、スクラムマスターがなくても、簡単にプロセスから離れることができます。
おもしろい練習でしたが、やめました。スクラムのメリットは、従来のウォーターフォールチームとは対照的だと思います。しかし、あなたが一人でいるとき、両方とも一種のモットーです。コミュニケーションやコラボレーションの問題はありません-設定された作業をすすめるだけで完了です。
私は誰もがバックログを保持し、TDDを行うべきだと思います。
単一の開発者の世界で理にかなっていると思うアジャイル/スクラム/かんばんの要素：
ユーザーストーリー/アクティブバックログ項目を整理するボードを、かんばんなどのインデックスカードに配置します。
これらの原則の価値について、非開発者から賛同を得てください。
私の優先順位を変更したり、マイクロマネージメント（スプリントのポイント）を変更したりせずに、仕事に時間を割いてください。私に時間を与えて、私ができることを正確に前もって理解するように努めます。
何かが必要な場合（私はブロックされる）、私があなたのところに来て、あなたがそれを私のために分類できない場合、スプリントは異常にキャンセルされる必要があるかもしれません。 （それは単に新しい計画が必要であることを意味します。）
誰もスプリントの途中で何も変更しません。または、その場合は、スプリントをキャンセルして、新しいスプリントを作成します。これが頻繁に発生すると、生産性が低下します。
利害関係者である人々の間のコミュニケーションは、その日の開発者の成果を含め、通常のスクラムとほとんど同じことを伝える、定期的なスタンドアップ会議で発生する可能性があります。基本的に、思ったよりも時間がかかった、またはうまくいったこと、および実装計画に対して行っている調整を報告できます。 （私は4つの新しいバグを見つけてログに記録しました。これらはこのオプション機能よりも重要であるため、時間をかけて修正し、このオプション機能をプッシュするつもりです。）
私は単一の開発者として多くの仕事をしてきましたが、確かに、単一の開発者と彼の非開発者の上司/上司との間の信頼、および優れたコミュニケーションが方法論ではなく鍵となります。しかし、適切な原則に従えば、常により効果的になることができます。
私はこれについていくつかのブログを読んだことがあり、あなたの質問に役立つと思います。
最初の部分： http://www.21apps.com/agile/doing-agile-in-a-team-of-one/
2番目の部分： http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/
このブログでさらに情報が見つかるかもしれません。
私はまったく関係がありません。ちょうど私のお気に入りにあったもの。お役に立てば幸いです。
はい。また、スクラムは特別なツールを使用する必要がないことに注意してください。それは、誰もが自分の作業について話し合う単純な15分間のスタンドアップ会議にすることができます。スクラムの利点は、誰もが何が起こっているかを知っていることであり、それにより、問題が発生する前に問題を解決し、将来の問題を予測することが容易になります。
私はかんばんを試して、基本から始めることをお勧めします：視覚化と進行中の作業（WIP）の制限。
後で中止する場合でも、プロセスの俊敏性が向上します。また、かんばんは「通常の」ソフトウェア開発に適していますが、かんばん+フローベースのプロセス（反復ではなく）は、新機能の開発とメンテナンスの両方に問題がある場合、他のプロセスツールよりも優れています。
私はデビッド・アンダーソンのカンバン本の推薦を二番目にしています、そしてあなたは地元のミートアップから私のスライドを見ることができます なぜそして単純なカンバンを始めるための方法 、または crisp.se/kanban は短い紹介です。
あなたの文脈について、私はいくつかの考えを持っています：
- 可視性 が重要なので、（大規模な）画面に永続的に表示できない場合（同じ場所にある場合）、デジタルツールではなく物理的なホワイトボードを使用してください。
- 現在のプロセスから始めます
- 上流と下流のハンドオフフェーズを含む、影響範囲のみから開始します（開発の準備が整った設計済み機能などのキューになり、完成した機能が販売可能になるなど、ユーザーからのキューになります）。
- 同僚が視覚化を上流または下流に拡大することに関心がある場合は、さらに良いでしょう。おそらく、会社のバリューストリーム（またはネットワーク）全体（つまり、コンセプトからキャッシュへのバリューの流れ）を視覚化することになるでしょう。
- wIPを制限することにより、マルチタスク（！）を最小限に抑えます。仕事の流れが同僚に見える場合、彼らは理由を理解し、あなたの皿の上にあるものを簡単に見る必要があります
- 作業を3つまたは4つの作業タイプ（サービスクラス）に分けると便利です。バグ、重大な問題、厳しい期限付きの作業、期限なしの作業
- たとえば、どこかにボトルネックが発生したり、作業がブロックされたり、やや予測可能なパターンで作業が「不足」した場合など、作業の流れを観察します。これは、デジタルツールを使用する場合、長期的には簡単です。最後のスライドをいくつか参照してください。
- 段階的に作業の流れを改善する
あなたが今すぐ何かを試してみたいと思っているなら、あなたが決定を下す間、私は 個人のかんばん をあなたのそばの壁や窓や食器棚で試すことをお勧めします 私が最後にしたように週 ...
これらの回答の多くには重要な点が欠けています。
スクラムチームは、純粋にプログラマーで構成される必要はありません。
同僚の1人が「設計」/「開発」を行い、もう1人が「販売」を行います。
おそらく、「営業」の同僚が製品の所有者（プロキシ）になることができます。顧客の期待は何ですか？
他の同僚の設計と開発は、私にとってスクラムチームの規律のように聞こえます。スクラムの開発は段階的ではなく、垂直的です（要件を解決し、1つのスプリントで設計および実装します）。
3人でスクラムプロセスを実行できます。
「これ」を完了するには何が必要ですか？スクラムのスプリント計画会議は、「これ」が何であるかという質問にズームインします。製品の所有者は、それが完了したと見なされるために何を期待するでしょうか？
スプリント計画会議中に、「製品の国際化とローカライズ」が実装するのが技術的に難しい理由について、他の同僚に説明することができます。
スクラムimhoを使用する理由はたくさんあります。
次の場所にない限り
入ってくる要件を整理して優先順位を付ける手段。
イテレーションで何をコミットできるかがわかるように、かかる作業を正確に見積もる
反復と継続的改善-継続的に検査と適応を行う反復の概念は非常に貴重です。この実践は実験を促進し、継続的な学習に組み込まれます。 教会のスクラム、4ページ
ええと、毎日のスクラムミーティングを行うことはできませんが、少なくとも、今日コミットするタスクを思い出すことができます。毎日のスクラムミーティングを使用して、チームが何をしているのかを互いに同期させることができます。
スプリント後の反省-スクラムではSprint Retrospectiveと呼ばれ、各反復の最後に、反復後に何が起こったかを反省し、何が悪かったのか、どのように改善できるのか、それらを維持するためのベストプラクティスは何かを考えることができます。している
ミニマリストのアプローチをとることをお勧めします。継続的な改善により、ニーズに合ったスクラムを手に入れることができます。
スクラムは、ニーズに合わせて現在の状況に適応できない場合、スクラムではありません。
ここで他のすべての答えを読んだ後、私は単純な実用的な答えは次のとおりだと思います：
使用中のプロセス、技法、または方法を使用して、仕事をよりよくするのに役立つ何かを学びます。
今、これはあなたのタスクに-毎日-宗教的に優先順位を付けることを意味するかもしれません。
それはバックログを解決することを意味するかもしれません。
進捗状況を上司に報告することを意味する場合があります（上司が気にしていない場合でも...することは、あなたが精神的にあなたがどこにいるかを知ることができるようにするのは良いことです）。
あらゆる種類の方法や手法を使用する可能性があります。最終的には仕事が上手くできるため、夜はよく眠れます。
機能するものは（現在の状況では）機能し、機能しないものは破棄します。