10

私はリーン/かんばんにまったく慣れていませんが、過去数週間にわたってオンラインリソースを使い果たしており、適切な答えが見つからない質問を思いついています。リーン/かんばんは、それ以外の点では、すでにスクラムを使用している当社には非常に適しているようですが、その方法論の中でいくつかの制限に達しています。ここの誰かが私に良いアイデアをくれたらいいのにと思います。

私が見ているように、ウォーターフォールに対するスクラムの最大の利点の1つは、スプリントの使用です。14日ごとにすべてを準備することで、短いフィードバックサイクルが得られ、頻繁にリリースできます。ただし、リーンについて読んだことから理解したように、これにはいくつかのコストがかかります（たとえば、スプリント計画会議、チームコミットメント会議、およびスプリントの最後にすべての人に役立つものを見つけるための問題）。

リーン/かんばんはこれらの廃棄物を取り除きますが、14日ごとに放出できないという犠牲を払うだけです。それとも私は重要なポイントを逃しましたか？かんばんでは、どのようにして新しい開発タスクに取り組み、同時にリリースすることができますか？途中でしか出荷されていないものを出荷しないようにするにはどうすればよいですか？そして、どうすればそれを適切にテストできますか？

これまでの私の最高の「解決策/アイデア」は次のとおりです。

  • 頻繁にリリースせず、新しい開発タスクの不足に関連する無駄を許容します。しかし、実際には、尋ねられた質問に対する解決策ではありません。
  • ブランチで開発してから、メイントランクにマージします。内部で少なくとも2つのブランチを継続的にサポートする必要があります。
  • 一部のスマート自動ラベル付けシステムを使用して、特定の完了したタスクのみを自動的に作成し、他のタスクは作成しません。

要約すると、私の質問は次のとおりです。リーン/かんばんを使用する場合、無駄を導入せずに頻繁にリリースできますか？または、リリースはリーン/かんばんの一部ではないことがよくありますか？

私の会社に固有の追加情報：Team Foundation System＆Source Controlを使用しており、以前は分岐とマージに関していくつかの悪い経験がありました。この分野の専門知識を取り入れることで、これを解決できるでしょうか。

4

7 に答える 7

5

あなたが説明する問題は、ソース管理プログラムのようです-カンバンよりも、完成した機能を進行中の機能から分離する方法。多くのブランチを実行することに大きなペナルティを課しているようです。これは、複数のブランチのアイデアに基づいていないソース管理システムの場合です。GIT や Mercury などの分散ソース管理システムでは、すべてがブランチであり、それらを使用することは軽量です。

かんばんとスクラムに関するこのブログと、関連する実践ガイドを読んでいると思いますか?

そして、あなたの質問への答えとして、はい、カンバンで頻繁にリリースできます。

于 2009-08-07T15:19:59.210 に答える
4

かんばんが管理するように設計されているプル システムを理解する必要があります。

実行中のシステムの機能に対する顧客 (または製品所有者など) の要求が、プロセスのトリガーとなります。

The request is a signal that goes to deployment. Deployment look for a tested item with properties that match the request. If none is there, you write the tests and look at development if there is a development slot that can be used to implement something that fulfils the test. When development has done its development (maybe looking for a suitable analysis first and so on), the test does its test, and deployment deploys.

The requests going backwards through the system are permissions to start working. As soon as the request has arrived, this triggers a lot of activity, where each activity should be completed as quickly as possible. There you have your turbo deployment.

Just like the request for a car goes to the dealer who looks in the ship who signals to the car factory, who signals to the suppliers.

かんばんは、システムを通じて要求をプッシュすることではありません。最後のステップを介して入るリクエストと引き換えに、システムから機能を引き出すことです。

于 2011-01-24T11:55:40.050 に答える
1

かんばんを使用した持続的なエンジニアリングプロジェクトで毎週リリースを処理する方法は、分岐戦略を実装することでした。開発者はサンドボックスブランチで作業し、作業項目ごとに1回チェックインしました。テスターはサンドボックスで作業項目をテストします。回帰テストに合格した場合、チェックインはリリースブランチに移行されます。月曜日の正午からリリースがリリースされるまで（通常は水曜日まで、場合によっては木曜日までに、ドロップデッド日は金曜日）、リリースブランチをロックし、移行されたすべてのチェックインの回帰テストと製品の統合テストを再実行しました。すべてのテストに合格すると、リリースを削除します。

この戦略により、開発者はリリースプロセス中にブランチから凍結されることなく、問題に継続的に取り組むことができます。また、解決に1週間以上かかった問題に取り組むこともできます。チェックインおよびテスト/承認されていない場合、移行されませんでした。

プロジェクトの新しいバージョンでかんばんを実行している場合は、同様の戦略を使用しますが、関連するすべてのチェックインを「機能」としてグループ化し、機能が完了したら機能をまとめてリリースブランチに移行してから、追加のユニットを実行しますその機能を備えたリリースをドロップする前に、リリースブランチで/ Integration / Acceptance/Regressionテストを実行します。かんばんの重要な概念は進行中の作業を制限することであるため、チームが一度に1つの機能で作業するように制限する場合があります（これはおそらく複数の作業項目/ユーザーストーリーになります）。

于 2009-11-25T10:59:20.010 に答える
1

これにはソース管理だけではありませんが、TFS の選択によって制限が生じます。2004 年に Burton プロジェクトが構想されたとき、Microsoft はアジャイル、ましてやリーンに注意を払っていませんでした。しばらくの間、それはあなたの最も弱い機械的リンクになるでしょう。あなたのハックルは、TFS 実装のポスターチャイルドとして Microsoft コミュニティに提供された後、CodePlex が Mercurial を独自に採用したことによって引き起こされたはずです。

ここでより顕著な問題はワークデザインです。これには、機能を実装するために選択する順序 (作業スケジュール)、優先順位付けと遅延のコスト、および作業項目の形状とサイズが含まれます。

スクラムは一般的に、非技術的な「プロダクト オーナー」が自分の関心事のみに基づいて作業スケジュールを決定できると解釈されます。この道をたどると、一緒に仕事をする機会を逃して、多くの無駄を生むことになります。一緒に属する仕事は、プロダクト オーナーの希望だけで決まるわけではありません。技術的および労働力 (スキル) の機会も考慮に入れる必要があります。

最も生産的な方法で作業を行うには、作業自体をそのように設計する必要があります。これは、Lan 製品開発チームでは、非技術者ではなく、製品、顧客、チームに近い、トヨタが「高い技術力」と呼ぶ人物によって決定が下されることを意味します。 .

この役割は、スクラムの提案とはまったく対照的です。リーン チームのチーフ エンジニアは、自分自身 (または自分自身) が顧客の声であり、プロダクト オーナーの役割は不要です。

スクラムの「プロダクト オーナー」は、ソフトウェア開発組織における未熟な役割の認識ですが、一貫して無駄を回避する持続可能なソリューションとはほど遠いものです。「ソフトウェア アーキテクト」の役割も不十分な場合が多く、一部の開発者サブカルチャーでは、アーキテクトが仕事から離れすぎていることがあります。

継続的な展開の問題は、テクノロジとツールによって部分的にしか解決されません。組織の問題にも目を向けてください。おそらく、スクラムの目的を、組織に無期限に役立つものではなく、ウォーターフォールからの移行アプローチとして考えてみてください。

于 2010-07-12T00:28:04.630 に答える
1

私が管理しているチームはかんばんを使用しており、約 2 週間ごとにリリースしています。何をメインライン コード ブランチに統合するか (テストの合格、顧客の承認など) に厳密な場合、Kanban を使用するといつでもリリースできます。これを行うには、システム内を移動するストーリーが相互に依存していないことを確認する必要がありますが、私のチームでは、通常は問題ありません。作業の大部分は、関連のないいくつかのバグ修正で構成されるメンテナンスを伴います。 / リリースごとの機能。

于 2009-08-23T23:49:20.713 に答える
0

どうすればいいですか：

次の段階のパイプラインがあります

  1. やり残し
  2. TODO
  3. 進行中（開発およびクイックテスト）
  4. コードレビュー
  5. テスト（厳密なテスト）
  6. 統合テストと一般的な受け入れテスト
  7. 配備

各ストーリーは、最新バージョンに基づいてブランチとして開発され、デプロイ段階を終了します。次に、統合テストの準備の一環として統合されます。

QAはコードレビュー段階から抜け出し、任意のペースでリリースを準備できます。毎週およそ1回のリリースのペースがあると思います。

gitから「master」ブランチを削除し、コードレビュー段階の前にマージを行わないことで、コードをリリースに「こっそり」入れる可能性がないことを確認しました。これは、興味深い副産物として、以前は隠されていた多くの作業を視覚化することを余儀なくされました。

于 2011-03-07T22:27:42.290 に答える
0

ソース管理には、PERFORCEを強くお勧めします。これにより、他のブランチからの変更の分岐と統合が比較的簡単になり、これまでに見たソース管理に最適なインターフェイスが提供されます。

継続的インテグレーションも役立ちます。つまり、大規模で潜在的に困難なマージではなく、毎日よりも多くの小さなコミットが行われます。CruiseControlのようなツールは、悪いコミットによってソースが壊れたときにハイライトするのに役立ちます。また、全員が多くの小さな変更を行う場合、競合する変更はまれになります。

また、リーン、スクラム、かんばんなどに従わないようにアドバイスしたいと思います。近すぎる。自分で問題を解決し、指導ではなく指導のためにこれらのアイデアを探してください。問題の詳細には、最適な管理のためにある程度の柔軟性が必要になる可能性があります。

于 2009-11-19T20:51:33.023 に答える