Gitea: SCRUM backlog/sprint backlog per proyek

Dibuat pada 8 Feb 2018  ·  42Komentar  ·  Sumber: go-gitea/gitea

Saya akan senang melihat orang-orang berpartisipasi dalam masalah ini sebanyak mungkin dan mengumpulkan banyak saran dan ide.
Saya akan merasa cukup menarik untuk memiliki fitur seperti VSTS Miscrosoft (https://www.visualstudio.com/team-services/).
Belum tentu persis seperti itu, tetapi sesuatu yang sesuai dengan model proses tangkas SCRUM.
:) Selamat berdiskusi.

kinproposal

Komentar yang paling membantu

Untuk beberapa tim yang memiliki papan terintegrasi pada alat yang sama ketika masalah dibuat adalah suatu keharusan. Akan sangat berguna untuk memiliki papan seperti yang dimiliki Gitlab atau Github. Saya berpikir dengan ide tab papan/proyek terintegrasi gitea, dan saya membuat prototipe dari ide tersebut, ini didasarkan pada pendekatan Gitlab:

board-some-columns

board-many-columns

Ini tidak benar-benar berfungsi, itu hanya data yang diperbaiki, tetapi saya pikir visualnya harus mirip dengan ini. Kodenya ada di sini:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Sesuatu yang hilang adalah visual untuk membuat/memilih papan, seperti yang dimiliki Gitlab. Akan sangat berguna untuk dapat membuat papan untuk banyak tim.

Semua 42 komentar

Bisakah Anda menunjukkan fitur mana yang Anda inginkan secara khusus?

Di SCRUM pada dasarnya Anda memiliki satu Product-Backlog, yang berisi Cerita Pengguna, yang diurutkan berdasarkan prioritas atau berdasarkan nilai yang telah ditentukan sebelumnya.
Setiap Kisah Pengguna kemungkinan besar terdiri dari judul, deskripsi, dan mungkin nama untuk nilai untuk mengukur prioritas (kurang lebih seperti "masalah", tetapi diurutkan berdasarkan prioritas) serta bidang prioritas itu.
Juga bidang, yang dapat menunjukkan, apakah Kisah Pengguna diimplementasikan, dihapus (karena beberapa masalah, belum selesai atau perlu deskripsi lebih lanjut)

Di setiap Sprint (periode waktu yang ditentukan) pengembang mengambil beberapa cerita Pengguna dari Product-Backlog dan menambahkannya ke Sprint-Backlog mereka, yang selain P-Backlog juga terdiri dari (mungkin opsional) ide bagaimana pengembang ingin memecahkan masalah spesifik, yang dijelaskan oleh Kisah Pengguna yang mereka pilih. Setiap pengembang dapat melihat setiap cerita pengguna yang ditugaskan oleh pengembang lain, tetapi tidak dapat mengeditnya (mungkin hanya mengomentarinya)
Pengembang hanya dapat memodifikasi catatan solusi mereka sendiri, tetapi bukan deskripsi/judul cerita pengguna, sehingga memerlukan setidaknya dua peran (pemilik produk dan pengembang (tidak eksklusif))
Apakah dev-1 telah menyelesaikan cerita pengguna yang ditugaskan, dia dapat meminta dev-2 lain untuk menetapkan cerita pengguna (dev-2) lainnya ke dev-1 (baik, terbuka untuk diskusi pada saat ini).

Apakah sprint selesai, artinya waktunya sudah habis, mungkin ada semacam gambaran umum tentang cerita pengguna yang sudah selesai dan juga yang belum selesai.
Kisah pengguna ini harus melalui dua fase.
Yang selesai harus melalui kedua fase, salah satunya adalah tinjauan Sprint (misalnya menunjukkan kepada pelanggan perbaikan yang sudah selesai) (hanya cerita pengguna yang sudah selesai).
Fase kedua adalah retrospektif Sprint, di mana tim pengembang melihat apa yang telah selesai dan terutama, apa yang baik dalam prosesnya, dan juga cerita pengguna mana yang belum selesai dan mengapa tidak (memindahkannya ke product backlog)
(Mungkin beberapa "papan buletin" dengan informasi tentang definisi "Selesai", yang berarti kapan harus mempertimbangkan cerita pengguna sebagai selesai dan beberapa hal pengoptimalan proses)

Beberapa fungsi untuk memulai sprint baru dan mungkin berdasarkan sistem masalah normal, pemilik produk dapat mengambil saran ini dan mengubahnya menjadi cerita Pengguna, menambahkan prioritas, deskripsi lebih rinci, dll.

Saya tidak tahu apa yang lebih baik, untuk menggunakan sistem masalah yang ada dan menggunakannya sebagai masukan bagi pemilik produk untuk mengambil dari atau menggunakan barang-barang scrum secara eksklusif, tidak termasuk sistem masalah normal dan melihat barang-barang scrum sebagai masalah sendiri sistem.

TLDR :D
Secara umum perlu ada dua peran, satu menjadi pemilik produk (secara default pemilik proyek dengan kemungkinan untuk mengubah peran oleh pemilik produk/proyek pertama) dan yang lainnya sebagai pengembang.
Selain itu diperlukan Sprint, yang memiliki durasi yang ditentukan (pemilik produk?) dan beberapa mekanisme untuk memulai sprint. Memulai sprint tidak masuk akal jika tidak ada apa pun di sprint backlog, sehingga kebutuhan sprint backlog yang berisi cerita pengguna yang ditugaskan (?) (mungkin semua pengembang dapat mengubah tugas), yang tidak dapat diubah, tetapi dikomentari ( satu komentar lengket dengan sub komentar?).
Setiap pengembang harus dapat (hanya dalam sprint? atau kapan pun dia mau?) untuk mengubah status cerita pengguna dari belum selesai menjadi selesai (pertanyaannya adalah, status seperti apa yang dapat dimiliki oleh cerita pengguna?)
Ketika sprint berakhir, status "pelacak masalah" harus mengubah statusnya ke fase peninjauan, hanya menampilkan cerita pengguna yang sudah selesai (Dan hanya komentar pengembang yang lengket? tidak ada komentar? semua komentar?). (Status apa yang harus kita butuhkan? : saran: perencanaan, sprint, review, retrospektif)
Kemudian pemilik produk(?) harus dapat mengubah status ke retrospektif, di mana mungkin "papan buletin" dengan saran, pola, praktik baik, praktik buruk, dll. serta semua, cerita pengguna yang sudah selesai dan yang belum selesai harus terlihat lagi.
Setelah fase ini pemilik produk(?) harus dapat mengubah fase ke fase berikutnya, perencanaan, di mana cerita pengguna yang belum selesai harus(?) kembali ke backlog produk dan cerita pengguna yang sudah selesai diarsipkan atau dihapus (agar tidak tunjuk jari pada orang, ketika bug ditemukan setelahnya).
Dan pada tahap perencanaan tim pengembang dapat menambahkan cerita pengguna lagi ke sprint backlog mereka.
Dan setelah langkah ini, entah bagaimana sprint perlu dimulai, mungkin oleh pemilik produk.

Bersenang-senang berdiskusi (saya harap)

Cerita pengguna juga dapat memiliki semua properti yang dimiliki masalah dalam pelacak masalah normal, misalnya tag dan sebagainya.

Ini sudah dibahas di #805. Secara pribadi, saya pikir alur kerja tim mungkin sangat berbeda, dan untuk alasan ini kita tidak boleh memiliki fitur "proyek" yang mirip dengan GitHub atau GitLab, atau sistem Scrum Bitbucket. Saya tidak berpikir ada satu ukuran yang cocok untuk semua, tetapi Masalah adalah kompromi yang baik untuk proyek-proyek kecil di mana orang dapat berharap untuk tidak memiliki banyak hal untuk dilacak.

Gitea sendiri harus, sejauh yang saya ketahui, tetap berpegang pada masalah gaya GitHub/Lab dan hanya menyediakan alat untuk menanganinya menggunakan API dan webhook, atau mengizinkan orang untuk menggunakan pelacak masalah eksternal (sesuatu yang sudah kita miliki!).

@jxsl13 Saya dapat merekomendasikan Anda https://github.com/opf/openproject yang dapat bekerja bersama Gitea. Ini mendukung banyak alur kerja dan Anda dapat mengatur gitea untuk menggunakannya sebagai manajer tiket/masalah Anda (dengan mengatur url di gitea)

@sapk terima kasih, terlihat cukup menjanjikan

@sapk Saya telah menginstal proyek terbuka dan mengubah manajer tiket/masalah di Gitea tapi saya punya pertanyaan, apakah ada hubungan antara proyek terbuka dan gitea? atau hanya tautan Gitea ke OpenProject?

Pertanyaan saya adalah karena saya tidak tahu apakah ada cara untuk menghubungkan masalah gitea saya dengan tugas proyek terbuka (kode gitea, jumlah masalah yang sama di gitea dan proyek terbuka).

Terima kasih untuk balasan Anda!

Mungkin untuk menautkan lebih erat antara openproject dan gitea melalui api, tetapi saya tidak tahu siapa pun yang melakukannya (dan mungkin memerlukan beberapa penyesuaian untuk gitea atau kode openproject).
Saya menggunakannya sebagian besar untuk melakukan manajemen proyek tingkat lanjut selain dari kode yang dihosting di gitea.

Saya suka pendekatan Gitlab yang memungkinkan untuk membuat "papan" scrum/kanban dari label dan mengubahnya menjadi tampilan yang berbeda ... tidak ada yang benar-benar berubah, itu hanya tampilan yang berbeda, tetapi IMHO yang sangat berguna.

Untuk beberapa tim yang memiliki papan terintegrasi pada alat yang sama ketika masalah dibuat adalah suatu keharusan. Akan sangat berguna untuk memiliki papan seperti yang dimiliki Gitlab atau Github. Saya berpikir dengan ide tab papan/proyek terintegrasi gitea, dan saya membuat prototipe dari ide tersebut, ini didasarkan pada pendekatan Gitlab:

board-some-columns

board-many-columns

Ini tidak benar-benar berfungsi, itu hanya data yang diperbaiki, tetapi saya pikir visualnya harus mirip dengan ini. Kodenya ada di sini:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Sesuatu yang hilang adalah visual untuk membuat/memilih papan, seperti yang dimiliki Gitlab. Akan sangat berguna untuk dapat membuat papan untuk banyak tim.

@rudineirk Apakah Anda dapat mengerjakan ini?

Saya ingin melihat ini terjadi juga! Ini akan memungkinkan banyak tim kecil untuk secara langsung dan terutama bekerja dengan gitea alih-alih berjuang dengan alat eksternal dan mungkin sulit untuk menyiapkan seperti Taiga.io, dll.
Dengan alat eksternal, hal-hal seperti menautkan komitmen ke masalah, dll. sepertinya tidak mungkin, itu adalah bonus besar dari pendekatan ini! (Mampu menyebutkan ID masalah di komit Anda untuk membuatnya muncul di masalah/tiket itu cukup keren :)

Saya sangat tertarik dengan fitur ini karena tim kami saat ini menggunakan https://taiga.io/ tetapi nilai sebenarnya adalah memiliki pelacak masalah terintegrasi dengan fungsi perencanaan kanban/scrum.

Saya pikir ada banyak hal yang bisa dipelajari dari implementasi GitHub yang awalnya persis seperti gitea. Implementasinya cukup umum untuk memungkinkan pengguna menggunakannya untuk scrum dan kanban meskipun ia tidak tahu apa itu sprint. Jika orang dapat menentukan kolom dan menarik dan melepas kartu, mereka kemungkinan besar akan menemukan cara untuk melakukan perencanaan dengannya.

Mengajukan persetujuan saya di sini bahwa papan gaya Kanban akan sangat baik. Belum ada yang menyebutkan Zenhub, yang menyediakan beberapa fitur ini (dan lebih banyak lagi) "di atas" Github.

Berikut adalah hal-hal yang menurut saya akan sangat berguna:

  • Tampilan masalah Kanban – tampilan ini hampir seluruhnya merupakan UI, mungkin akan memerlukan beberapa interaksi DB untuk melacak kolom dan urutan masalah dalam kolom)
  • Bagan Gantt – Gitea sudah menyediakan tanggal jatuh tempo dan dependensi serta tonggak, yang berarti semua data ada untuk menghasilkan bagan Gantt, saya pikir ini akan menjadi fitur yang sangat membantu. Ada perpustakaan seperti putri duyung atau React Google Charts yang tampaknya memiliki biaya integrasi yang masuk akal. Perhatikan bahwa #7405 akan membantu untuk ini juga.
  • Tonggak Pencapaian Organisasi – Ini mungkin yang paling mudah untuk diterapkan, tetapi seperti halnya kami memiliki fitur "Masalah" ( /issues ) di bagian atas Gitea, fitur Tonggak Pencapaian akan menyenangkan. Dengan kata lain, jika saya dapat melihat semua pencapaian yang terkait dengan saya, itu akan sangat keren. Saat ini, saya hanya dapat melihat pencapaian dalam satu proyek.

Tidak diragukan lagi, masing-masing akan menjadi fitur tersendiri. Mungkin utas gabungan ini perlu dipecah menjadi fitur/komponen individual?

Sunting: seseorang sedang mengerjakan zenhub seperti plugin Chrome untuk gitea di https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@adelowo memiliki cabang di sini yang mungkin ingin dikunjungi orang. Saya cukup berharap untuk apa yang dia retas.

Saya ingin melihat lebih banyak alat tipe PM masuk ke gitea mengingat kesederhanaan hosting sebuah instance, namun saya akan sangat senang hanya untuk dapat melakukan papan kerja di gitea selama tahun depan atau lebih. Saya pikir jika orang ingin memukul PM dengan keras, mereka dapat beralih ke taiga atau alternatif sekarang dan menjadi _cukup bahagia_.

Yup, perbedaannya bisa dilihat disini https://github.com/go-gitea/gitea/compare/master...adelowo :kanban_board?expand=1

@adelowo kapan kita bisa melihat PR ?

Dalam waktu sekitar 8-10 hari

@adelowo saya mendapat 500 jika mencoba mendapatkan _localhost/user/project_ /projects (dengan menu Anda):

2019/09/12 10:30:44 ...ers/repo/projects.go:62:Projects() [E] GetProjects: no such table: project

sepertinya database bootstrap belum berfungsi @ versi e7cf2b77afe50b5818c52405364faf3c914b9e63

Itu aneh migrasi ada di sana. Bisakah Anda menjalankan gitea migrate ?

https://github.com/adelowo/gitea/blob/kanban_board/models/migrations/v95.go

Tidak ada yang istimewa yang ditampilkan:

2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column email_notifications_preference db default is ''enabled'', struct default is 'enabled'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column passwd_hash_algo db default is ''pbkdf2'', struct default is 'pbkdf2'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column diff_view_style db default is '''', struct default is ''
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column theme db default is '''', struct default is ''

Tetapi:

# sqlite3 data/gitea.db .schema | grep proj
CREATE TABLE `repository` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `owner_id` INTEGER NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `description` TEXT NULL, `website` TEXT NULL, `original_url` TEXT NULL, `default_branch` TEXT NULL, `num_watches` INTEGER NULL, `num_stars` INTEGER NULL, `num_forks` INTEGER NULL, `num_issues` INTEGER NULL, `num_closed_issues` INTEGER NULL, `num_pulls` INTEGER NULL, `num_closed_pulls` INTEGER NULL, `num_milestones` INTEGER DEFAULT 0 NOT NULL, `num_closed_milestones` INTEGER DEFAULT 0 NOT NULL, `num_projects` INTEGER DEFAULT 0 NOT NULL, `num_closed_projects` INTEGER DEFAULT 0 NOT NULL, `is_private` INTEGER NULL, `is_empty` INTEGER NULL, `is_archived` INTEGER NULL, `is_mirror` INTEGER NULL, `is_fork` INTEGER DEFAULT 0 NOT NULL, `fork_id` INTEGER NULL, `size` INTEGER DEFAULT 0 NOT NULL, `is_fsck_enabled` INTEGER DEFAULT 1 NOT NULL, `close_issues_via_commit_in_any_branch` INTEGER DEFAULT 0 NOT NULL, `topics` TEXT NULL, `avatar` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL);
CREATE TABLE `issue` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `repo_id` INTEGER NULL, `index` INTEGER NULL, `poster_id` INTEGER NULL, `original_author` TEXT NULL, `original_author_id` INTEGER NULL, `name` TEXT NULL, `content` TEXT NULL, `milestone_id` INTEGER NULL, `project_id` INTEGER NULL, `priority` INTEGER NULL, `is_closed` INTEGER NULL, `is_pull` INTEGER NULL, `num_comments` INTEGER NULL, `ref` TEXT NULL, `deadline_unix` INTEGER NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `closed_unix` INTEGER NULL, `is_locked` INTEGER DEFAULT 0 NOT NULL);
CREATE INDEX `IDX_issue_project_id` ON `issue` (`project_id`);

Bekerja untuk saya, thx - berikut beberapa masalah kecil:

Prioritas Tinggi:

  • [ ] Pindahkan Masalah antar Papan
  • [x] tambahkan Proyek ke Edisi saat ini
  • [x] lihat proyek

- [x] buat proyek

Prioritas Sedang:

  • [ ] Ikon proyek (ATM sama dengan MergeRequest)
  • [ ] buat Masalah saat melihat proyek
  • [ ] pilih proyek saat membuat Masalah

Prioritas Rendah:

  • [ ] ganti nama Papan
  • [ ] tambahkan Papan
  • [ ] hapus Papan
  • [ ] pindahkan Papan
  • [ ] masukkan Label | Milestone di samping Pencarian
  • [ ] cari Masalah untuk menambahkannya ke Proyek (belum diuji)

Masalah dapat dipindahkan di seluruh papan sekalipun.

Terima kasih untuk daftar ini. Proyek sekarang dapat dipilih saat membuat masalah. Mohon tarik terbaru

https://github.com/go-gitea/gitea/commit/c55d44e0233f46094fbebd33feac82e5072e1ba7

Saya telah mengirimkan PR di https://github.com/go-gitea/gitea/pull/8346

Masalah dapat dipindahkan di seluruh papan sekalipun.

tidak disimpan, reload ulang ke Uncategorized


Proyek sekarang dapat dipilih saat membuat masalah.

Tidak menampilkan daftar proyek

Hmm, saya akan melihat lagi. Mari kita pindahkan diskusi fitur ke PR sehingga semuanya ada di satu tempat.

Terima kasih

komentar bernilai nol: tidak sabar menunggu ini terjadi, :shipit: :rocket: :four_leaf_clover:

Tolong bantu untuk mencoba #8346 dan berikan lebih banyak saran.

Apakah ada pembaruan tentang masalah ini? (Sudah sebulan sejak posting terakhir.)

EDIT: Saya tidak menyadari bahwa beberapa orang (seperti @storrgie) dapat tersinggung oleh orang-orang yang tertarik dengan pekerjaan mereka. Saya tidak bermaksud menyinggung siapa pun.

@tinxx Anda juga:

  • membangun PR yang ditautkan tepat di atas dan memberikan umpan balik dalam PR yang sebenarnya
  • mencari cara untuk memotivasi orang secara finansial untuk mengerjakan ini (misalnya hubungi @adelowo secara langsung untuk donasi atau lakukan sesuatu seperti bountysource untuk mendapatkan lebih banyak perhatian)

Anda tidak menuntut pekerjaan yang harus dilakukan ketika Anda tidak berkontribusi secara finansial atau intelektual, itu beracun di open source.

Jetbrains baru saja merilis versi baru YouTrack dengan integrasi gitea

@adelowo ada kabar?

Saran lain sementara itu: kanboard

Ini bukan permen mata (di luar kotak) tetapi cepat dan menawarkan fitur yang cukup untuk menjadi sangat berguna.

Penanya: Silakan lihat PR. Sepertinya tidak terlalu jauh :wink:

Iya @gsantner . Hanya beberapa perbaikan UI yang tersisa. Yang harus saya dapatkan akhir pekan ini

@adelowo ada berita kapan ini akan tersedia?

@zuhairamahdi rencananya akan dirilis pada 1.12.0. lihat PR #8346 untuk lebih lanjut.

Apakah ada Minat yang memiliki masalah pada banyak proyek dan/atau papan?

https://github.com/go-gitea/gitea/pull/8346#issuecomment -617175388

Saya suka pendekatan Gitlab yang memungkinkan untuk membuat "papan" scrum/kanban dari label dan mengubahnya menjadi tampilan yang berbeda ... tidak ada yang benar-benar berubah, itu hanya tampilan yang berbeda, tetapi IMHO yang sangat berguna.

Saya juga kehilangan fitur ini. Akan lebih bagus jika label masalah akan diperbarui ketika Anda memindahkannya ke jalur/papan proyek yang berbeda. Mengubah label dan dengan demikian memindahkan masalah antar jalur dengan referensi yang dapat ditindaklanjuti dalam pesan komit (yaitu Fixes #1 ) juga akan berguna.

@0xC4N1 Silakan kirim masalah baru, saya pikir kami dapat memiliki lebih banyak peningkatan pada fitur ini.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

cookiengineer picture cookiengineer  ·  3Komentar

thehowl picture thehowl  ·  3Komentar

internalfx picture internalfx  ·  3Komentar

BNolet picture BNolet  ·  3Komentar

Fastidious picture Fastidious  ·  3Komentar