タグ付けされた質問 「kanban」

非常に高いレベルの観点から見ると、私には一般に2種類のプロジェクト管理ツールがあるようです。 Fogbugz、JIRA、BugZilla、Trac、Redmineなどの従来の課題トラッカー 仮想カードボード / Pivotal Tracker、GreenHopper、AgileZen、Trelloなどのアジャイルプロジェクト管理ツール 確かに、それらは何らかの方法で重なります。たとえば、Pivo​​tal TrackerタスクをJIRAにインポートできます。GreenHopper自体はJIRA課題ベースの上に実装されます。 従来の問題追跡ツールは、アジャイルプロジェクト管理を行う企業でも使用されているようです。私の質問は、なぜ彼らはそれをするのですか？また、会社で課題追跡を使用する必要があると思いますが、それについて考えているとき、なぜそれを必要とするのか実際にはわかりません。 たとえば、Trelloの開発は、最高の課題追跡ツールの1つであるFogbugzにアクセスできる場合でも、Trello自体（この仮想ウォールを参照）を使用して管理されているようです。したがって、アジャイルPMツールの1つを使用して作業の100％をアジャイルな方法で行う場合、従来の課題トラッカーは必要ないでしょうか？

35 project-management  issue-tracking  kanban 

私のPivotal Trackerボードにいくつかの技術的負債に対処するユーザーストーリーをいくつか追加しました。それらを機能（速度レベルを維持）または雑用/バグ（速度を低下）として考慮する必要がありますか？どちらか一方を一貫してやったとしても、長期的には何の違いも生じないことは理解していますが、技術的な負債のストーリーを追加するたびに判断しなければなりません。 いくつかの考え： それらは実際にはバグではなく、何も壊しません ユーザーに影響を与えないのは低レベルの実装であるため、ユーザーは何も要求していませんが、長期的な開発を容易にします あなたもユーザに付加価値を話、などの機能を定義した場合）彼らは、ユーザーが行うすべての直接的な利益が、その後B）は表示されませんしない限り、彼らはその可能な将来の開発/メンテナンスを行うために行い、追加値を、ちょうど今ではない 私は実際に作業を行うかどうか、またはいつスケジュールするかを決定していません。プロジェクト管理ツールで技術的負債と呼ぶべきものとその理由を知るだけです。

19 project-management  agile  technical-debt  kanban 

XP（エクストリームプログラミング）、特に同じ画面に2人のプログラマーがいる部分が好きですやっています。 過去10年ほどで、XPスタイルの作業は時代遅れになり、作業方法論であるアジャイルおよび/またはかんばんが採用されたようです。どうして？XPは私にとって非常に優れた作業方法であるように思われ、プログラミングについて多くのことをしているのに対し、アジャイルとかんばんはプロセスに関するものです。

15 agile  extreme-programming  kanban 

私のチームは、日々の進行状況を追跡するためにかんばんシステムを使用しており、機能（ユーザーストーリーとしてキャプチャ）の進行状況を理解するために非常にうまく機能しています。最近までうまく機能していた機能を開発するにつれて、システム設計の出現をほぼ許可しました。過去2週間で、パフォーマンスと変更可能性の品質属性に特に関連するアーキテクチャのトレードオフについていくつかの議論がありました。 私が思うに、機能を実装してシステムを設計するときに、アーキテクチャについて暗黙的に決定を下しますが、既知の品質属性要件に関してはそれらの決定を考慮していません。これらの重要な設計上の決定がどのように行われているのかを追跡/キャプチャ/視覚的に表現できれば、チームメンバーが実装中にシステムのアーキテクチャにさらなる緊張を生じさせないようになります。そしてもちろん、より複雑なものに、私たちのボード上の機能はありません、排他的、機能的で、時には建築の複雑さを隠します！ チームのかんばんの品質属性（またはその他のアーキテクチャに関連する決定）の進捗を視覚的に追跡するにはどうすればよいですか？

13 agile  tracking  architecture  kanban  quality-attributes 

かんばんから始めて、作業項目がどれくらいきめ細かくなければならないかわかりません。WIPの選択方法に関する具体的な推奨事項はたくさんありますが、私が読んだカンバンチュートリアルのほとんどは、ワークアイテム（ボード上のカード）のサイズについてかなり曖昧なままです。 以下のための計画と見積もり、人々は多くの場合、アイテムの小型のサイズを維持することをお勧めします2-16時間を言います。同じことがかんばんにも当てはまりますか？私の計画から取締役会への1対1のマッピングは常にありますか？ ベストプラクティスや一般的な推奨事項がない場合、どの要素が作業項目の粒度の選択に影響しますか？

11 kanban 

典型的なかんばんボードを考えてみましょう： 入力、分析、開発準備、開発、構築準備、テスト、リリース準備 各列のWIP制限を指定するにはどうすればよいですか？どんな式？

10 kanban 

私はかんばんについて少し読んでいますが、要件のトピックについて少し混乱しています。 現在のプロジェクトでは、スクラムを使用しています。スプリントの最初に、BAがストーリーのウォークスルーを行い、彼女ができる限りそれを説明するセッションがあります。次に、その話を取り、レビューし、話し合い、BAに次のスプリント計画セッションのための質問を準備します。次のセッションでは、BAがすべての質問に答え、セッションは要件を理解した（ほとんどの場合）ことで終了します。 次のステップは、技術設計を作成し、ソリューション/ストーリーを開発することです。 かんばんに関​​して、私が読んだすべては、かんばんにはスプリント計画がないことを示唆しています。私の質問は、技術の要員とビジネスマンが一緒に座って（カンバンで）ストーリーの要件について話し合うときですか？プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供しませんか？ スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はどのようにストーリーを理解するのかはわかりません。

8 agile  requirements  kanban 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 始める前に、先取りの謝罪をする必要があります。 この投稿で使用している用語や語彙の一部が明らかに間違っている可能性が非常に高いため、重要な側面の一部を完全に誤って解釈している可能性もあります。私はこれが初めてなので、批判的になりすぎないでください。建設的なフィードバックを歓迎します。;） バックグラウンド 現在、200名の開発部門をマルチメソッドから「アジャイル」に移行しています。理由、理由、長所、短所は、この質問の範囲をはるかに超えています。 この開発部門には、正式に「ソリューションアーキテクト」と呼ばれる10人で構成されるアーキテクチャサービスチームが含まれています。実際には、それらはソリューションだけでなく、プロジェクトのすべての技術アーキテクチャ面（つまり、ハードウェア、ソフトウェア、セキュリティ、ガバナンスなど）をカバーする技術者です。また、開発チームに特別な機能（コードレビュー、標準ガイダンスなど）と幅広いビジネス（入札への技術的インプット、顧客の要件の事前契約技術プレビュー）を提供します。 この移行の一環として、私は、建築サービスチームが責任を負う作業活動を把握するために、かんばんボードを作成する任務を負っていました。開発/コーディングチーム用の無数のサンプルボードがありますが、アーキテクチャ用に見つけることができるものはありません。だから私は様々なソースから取って「何か」を作成しました、それについての真のフィードバックを本当に感謝します。 また、これは開始点/進行中の作業としてチームに提示されることにも注意してください。それは彼らのボードであり、私は彼らにそれを所有してほしいと思っています。 これまでのところ私はこのようなものを持っています メインボード メインボードは、すべてのアクティブ/バックログプロジェクトを保持する場所です。すべてのアクティブな作業はこのボードで行われます。これは、毎日の建築スクラムで簡単にレビューされ、毎週の終わりにさらに詳細なレビューが行われます。 ------------------------------------------------------------------------ | Evaluation | Implementation | Ad- Hoc | | Todo | Doing | Done | Todo | Doing | Done | Todo | Doing | Done | ------------------------------------------------------------------------------- Person | | | | | | | …

8 architecture  agile  kanban