一人のプログラマーのためのスクラム？[閉まっている]

私は非常に小さな会社で「Windowsエキスパート」と呼ばれています。この会社は、私、セールスおよびトレーニングの役割を担う機械エンジニア、および設計、開発、サポートの役割を担う社長から構成されています。

私の役割も同様に一般的ですが、主に、現在のWindowsのバージョンで製品を実行するために必要な、製品のプログラミングを設計および実装します。

ウェブキャストで提供されたスクラムパラダイムの高レベルの概要を見終えました。私の質問は、「製品の国際化とローカライズ」など、開発作業項目が通常非常に高いレベルで与えられることを考えると、製品開発へのこのアプローチについてもっと学ぶ価値があるかどうかです。

もしそうなら、スクラムを一人のプログラマーの使用に適応させることをどのように提案しますか？そのためには、クラウドベースのツールやその他のツールが有用でしょうか？

そうでない場合、一人のプログラマーが日々努力を整理するためにどのようなアプローチを提案しますか？（おそらく、質問はその単純な質問に還元されます。）

スクラムを学ぶ：はい。あなたの一般的なスキルセットに追加することについてそれを学ぶためだけに。（ただし、「スクラム禁止」のフレーバーはおそらくあなたが探しているものです...）

スクラムは優れたフレームワークですが、核となる原則は「反復（スプリント）の期間を固定すること」です。これは、割り込み駆動型の非常に小さなチームでこの作業を見たことがありません。一定の時間枠（1週間？）で真にサインアップして作業にコミットできる場合、スクラムはクールなフレームワークです。できない場合は、スクラムは他のことにうまく変換できるいくつかの優れた概念を持っているので、学ぶのにうれしいです。

バックログ-スクラムかどうか、あなたがする必要があることの優先順位リストを保持します。Excel（またはGoogle Doc Spreadsheet ...）が好きです。あなたが非常に小さなチームである場合、私は非常に小さなツールを保持します。（スプレッドシート>>ワープロ。簡単にソートできるため。）

計画とコミットの分離-抽象表記（ポイント）で計画し、一貫性を保ちます（8ポイントは4ポイントストーリーの2倍、2ポイントストーリーは4倍）数時間で。ポイントを変更しないでください。

コミットメント-コミットしたときに他の人に見えるようにし、コミットメントを果たします

レトロスペクティブ-納品後、改善できたことを振り返ります。

などなど

スクラムは、それが良い出発点かもしれないことを理解するのに十分簡単です。気に入ったら、「スクラム禁止」のバリエーションを使用することを検討します-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_3）、しかし、それはより多くの読書と掘りを伴います。

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人のSrumの賛否については何も言いませんが、1人のKanbanプルシステムは非常にうまく機能すると言います。かんばんと自動化された単体テストを組み合わせることで、生産性が向上し、「文書化」されました。どちらも本当に方法論ではありませんが、より多くのツール（そしてそれとは非常に異なるツール）ですが、どちらも私が大きなソロプロジェクトを一口サイズのピースに分割することを余儀なくされ、それぞれにもっと多くのことを成し遂げるように私に一種の儀式を与えます日。「すべてのテストを実行」をクリックして各項目が緑色になるのを見るほど満足のいくものはありません...かんばんボードの「進行中」列からカードを「テスト中」（または完全にボード外）にする以外は何もありません。

ソロでの作業の本当の問題は、複数の方法論から選択して選択することです。これは、開発者のグループ向けであり、自分に最適な方法に調整します。 最終的な目標は、説明責任、生産性、および幸せを保つことです。自分よりもうまくやる方法を誰が知っているか（ここから少し引き出して、そこから少し引き出して）。

ある時点で一人で働いていたときにこれを試しました。うまくいったことは次のとおりです。

1. ホワイトボードにすべての作業項目を配置します。私はそこにどんな傑出した仕事があったかを非常に素早く見ることができました。依存関係と閉塞があった場所。また、多くの人が私の掲示板に立ち寄って読んでくれました。そして、私たちはそれについてチャットをしていました。「オタク」が一日中何をしていたのかを理解する助けになったと思う;-)
2. バーンダウンチャートも素晴らしかった。これにはExcelを使用しました。それにより、その環境での見積もりをうまく行うことができました。それは、私がイテレーションに向かっている場所の素晴らしい概要を与えてくれました。技術者ではない私のマネージャーも、機能に関係するさまざまなものすべてとそれらがどこにあるのかを見ることができるので、これが大好きでした。
3. 毎日立ち上がる。まあ私ができる限り。毎朝、すべての作業項目とバーンダウンチャートを更新し、解決する必要のあるすべての障害を書き留めました。
4. 自動テストおよび継続的インテグレーション（MSTest / TFS）（できればTDD）は、任意の方法論を使用して開発チームを支援しますが、ここで言及する価値があります。
5. 短い反復（1週間）は、何かを提供することに集中するのに本当に役立ちました。
6. バックログを維持することは、私が新しい仕事を与えられたとき、他のすべての仕事のコンテキストでそれを配置し、製品所有者に優先順位を再設定させることができたので、素晴らしかったです。

うまくいかなかったのは：

1. 自分で作業する場合、志を同じくする人々と協力することで、そのような後押しを得ることはありません。または、非常に優れた士気と文化を持つチームから得られる競争と集中の感覚。あなたが動けなくなったときに選択する他の脳はありませんので、そのような閉塞は毎日のスタンドアップでスクラムマスターによって排除することはできません。
2. スクラムマスターはいないので、中断を止める人はいません。私は、他のことについて常に質問し、私の流れを壊す人々と多くの問題を抱えていました。優れたスクラムマスターの下で、そのようなものは傍受され、あなたは乗ることができます。私は人々に失礼になりたくなかったので（たぶん私はソフトだ）、それは問題でした。また、スクラムマスターがなくても、簡単にプロセスを離れることができます。

面白い練習でしたが、少ししてやめました。スクラムの利点は、従来のウォーターフォールチームとは対照的に見られるべきだと思います。しかし、あなたが一人でいるときは、両方とも意味がありません。コミュニケーションやコラボレーションの問題はありません。設定された作業をただすれば完了です。

誰もがバックログを保持し、TDDを行うべきだと思います。

単一の開発者の世界で意味があると思うアジャイル/スクラム/かんばんの要素：

1. かんばんなどのインデックスカードで、ユーザーストーリー/アクティブバックログアイテムを整理するボードを用意します。

2. これらの原則の価値について、非開発者から賛同を得ます。

   • 自分の優先順位を変更したり、マイクロ管理（スプリントのポイント）したりせずに作業する時間を与えてください。私に時間を与えて、私ができることを正確に事前に把握しようとします、そして私はそれをするために最善を尽くします。

   • 何かが必要な場合（ブロックされる）、私があなたのところに来て、あなたが私のためにそれをソートできない場合、スプリントは異常にキャンセルされなければならないかもしれません。（つまり、新しい計画が必要なことを意味します。）

   • スプリントの途中で誰も何も変更しません。または、その場合、スプリントをキャンセルし、新しいスプリントを作成します。これが頻繁に発生すると、生産性が低下します。

   • 利害関係者である人々の間のコミュニケーションは、毎日のスタンドアップミーティングで行われ、その日の開発者の業績を含め、通常のスクラムとほとんど同じことを伝えます。基本的に、思ったよりも長くかかった、またはうまくいったこと、および実装計画に対して行っている調整を報告できます。（4つの新しいバグを見つけてログに記録しました。これらはこのオプション機能よりも重要だと思うので、時間をかけて修正し、このオプション機能をプッシュするつもりです。）

私は単一の開発者として多くの仕事をしてきましたが、確かに、単一の開発者と彼の非開発者の上司/上司との間の信頼、および良好なコミュニケーションが方法論ではなく重要です。しかし、良い原則に従えば、いつでもより効果的になります。

私はこれについていくつかのブログを読みましたが、あなたの質問に役立つと思います。

最初の部分：http : //www.21apps.com/agile/doing-agile-in-a-team-of-one/

第二部：http : //www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

このブログでさらに情報を見つけることができます。

私は決してつながりません。お気に入りにあったものだけです。お役に立てば幸いです。

はい。また、スクラムには派手なツールを使用する必要はありません。これは、作業中のことについて全員が話し合う15分間の簡単なスタンドアップミーティングになります。スクラムの利点は、誰もが何が起こっているかを知っていることであり、それにより問題が発生する前に解決し、将来の問題を予測しやすくなります。

これらの答えの多くには、重要な点が欠けています。

スクラムチームは、純粋にプログラマで構成される必要はありません。

同僚の1人が「設計」/「開発」を行い、もう1人が「販売」を行います。

「営業」の同僚が製品所有者（プロキシ）になる可能性があります。顧客の期待は何ですか？

他の同僚の設計と開発は、私にとってスクラムチームの規律のように思えます。スクラム開発は段階的ではなく、垂直的です（鉄の要件、設計、実装を1つのスプリントで）。

3人でスクラムプロセスを行うことができます。

「これ」を完了するには何が必要ですか？スクラムのスプリントプランニングミーティングは、「これ」とは何かという質問に焦点を当てています。製品所有者は、それが完了したと見なされるために何を期待していますか？

スプリントプランニングミーティングでは、「製品の国際化とローカライズ」を実装するのが技術的に難しい理由について、他の同僚にコンテキストを伝えることができます。

スクラムimhoを使用する理由はたくさんあります。

かんばんを試してみて、基本から始めることをお勧めします：視覚化と進行中の作業（WIP）の制限。

後で中止しても、その過程でより機敏になります。また、かんばんは「通常の」ソフトウェア開発に適していますが、新しい機能の開発とメンテナンスの両方の状況がある場合、かんばん+フローベースのプロセス（反復ではなく）は他のプロセスツールよりも優れています。

デビッドアンダーソンのかんばんの本の2番目のおすすめです。また、簡単なかんばん、またはcrisp.se/kanbanを短いイントロで始める理由と方法について、地元の交流会のスライドを見ることができます。

あなたのコンテキストのために、私はいくつかの考えがあります：

• 可視性が重要であるため、（同じ場所にいる場合）（大きな）画面に永続的に表示できない場合は、デジタルツールよりも物理的なホワイトボードを使用してください
• 現在のプロセスから始めます
• アップストリームおよびダウンストリームハンドオフフェーズを含む影響範囲のみで開始します（開発者向けに設計された機能、または完成した機能、販売準備が整ったユーザーからのキューなど）
• 同僚が上流または下流の視覚化を拡大することに関心がある場合は、さらに良いでしょう。会社のバリューストリーム（またはネットワーク）全体、つまり、コンセプトからキャッシュへの価値の流れを視覚化することになるかもしれません
• WIPを制限することにより、マルチタスク（！）を最小限に抑えます。仕事の流れが同僚に見える場合、彼らはその理由を理解し、あなたの皿に何があるかを簡単に見る必要があります
• 多分、3つまたは4つの作業タイプ（サービスクラス）に作業を分割すると便利です。バグ、重大な問題、厳しい締め切りのある仕事、締め切りのない仕事
• 作業の流れを観察します。たとえば、どこかでボトルネックが発生したり、作業がブロックされたり、ある程度予測可能なパターンで作業に「飢えている」場合です。デジタルツールを使用する場合、これは長期的には簡単です。前回のスライドを参照してください。
• 作業の流れを段階的に改善する

今すぐ何かを試してみたい場合、今日、あなたが決断を下しながら、先週やったように、あなたのそばの壁、窓、または食器棚に個人的なかんばんを試してみることをお勧めします...

ここで他のすべての答えを読んだ後、私は簡単な実用的な答えは次のとおりだと思います：

使用中のプロセス、技術、または方法を使用して、仕事をより良くするのに役立つ何かを学びましょう。

今、これはあなたの仕事を優先することを意味するかもしれません-毎日-宗教的に。

バックログを解決することを意味する場合があります。

上司に進捗状況を報告することを意味する場合があります（上司が気にしなくても...それを行うことは、あなたが現在いる場所を精神的に把握できるようにすることは良いことです）。

最終的にはより良い仕事ができるため、あらゆる種類の方法やテクニックを使用できます。

（現在の状況では）動作するものを実行し、動作しないものを破棄します。

以下を用意していない限り

• 入ってくる要件を整理して優先順位を付ける手段。

• 実行される作業を正確に推定して、反復でコミットできることを把握します。

• 反復と継続的な改善-継続的に検査と適応を行う反復の概念は非常に貴重です。この実践は実験を奨励し、継続的な学習に組み込まれます。教会のスクラム、4ページ

• まあ、あなたは毎日のスクラム会議を行うことはできませんが、少なくともあなたが今日コミットするタスクを思い出すことができます。毎日のスクラム会議を使用して、チームが互いに何をしているかを互いに同期できるようにします。

• スプリント後のリフレクション-スクラムでは、スプリントレトロスペクティブと呼ばれ、各反復の終わりに、反復後の出来事を振り返り、何が間違っていたのか、どのように改善できるのか、それらを維持するためのベストプラクティスは何かを考えることができますやる

ミニマリストのアプローチを取ることをお勧めします。継続的な改善により、ニーズに合ったスクラムを作成できます。

スクラムは、ニーズに適合できず、現在の状況に適応できない場合、スクラムではありません。