Di salah satu artikel sebelumnya, kami menulis tentang bagaimana seluruh perusahaan beralih ke satu pelacak berdasarkan Azure DevOps (TFS). Ini memungkinkan kami untuk membuat seperangkat aturan terpadu untuk manajemen proyek. Kami akan memberi tahu Anda bagaimana kantor proyek kami mengembangkan logika yang digunakan oleh semua tim kami saat ini.
Dengan sendirinya, satu pelacak tidak menjamin bahwa semua tim akan bekerja dengan cara yang sama. Agar hal ini terjadi, perusahaan harus memiliki pandangan yang sama tentang manajemen proyek - baik di tingkat atas, di mana manajer merencanakan pengembangan produk, dan di tingkat yang lebih rendah, di mana pengembang menyelesaikan tugas dan mengirimkan rilis ke pelanggan.
Pandangan yang menyatu seperti itu memberikan kesinambungan pengalaman. Semua proyek serupa satu sama lain, semua tim menggunakan pendekatan yang sama dan berbicara bahasa yang sama. Untuk tujuan ini, kantor proyek kami tahun lalu mengatur tentang membuat satu templat yang menggabungkan istilah umum, proses, dan pengaturan proyek default kami.
Tujuannya adalah untuk memastikan bahwa pada akhirnya setiap proyek dapat "dibaca" di pelacak dan memahami dengan jelas statusnya. Selain itu, ini dapat dilakukan baik oleh seseorang (menyesuaikan metrik ujung ke ujung untuk semua proyek, memahami di mana semuanya baik dan di mana semuanya lebih buruk), atau mesin (layanan pembentukan Catatan Rilis "memahami" tugas mana yang dengannya status dan tag yang akan disertakan dalam milis). Dan tentu saja, semua proyek yang baru diluncurkan harus dibuat sekaligus dalam aturan yang sama.
Kami sekarang telah mencapai tujuan ini. Ketika seorang manajer mengirim permintaan ke administrator untuk memulai proyek baru, dia tidak perlu menjelaskan apa yang harus ada: pengaturan dan jenis tugas apa, ke sistem mana yang akan dihubungkan. Semua yang Anda butuhkan ada di proyek sejak awal, Anda dapat segera memulai sprint, mengisi tugas, menyiapkan rencana pengembangan.
, . - , (, ..). , , .
, .
True Engineering
1. . , – .
- Epic. -, . , .
, . — « ».
– Feature, 1-3 ). Feature – -. , .
– PBI (Product Backlog Item, ), . , , – PBI. Task-, , 8 .
, , - – .
2. . PM – , , , , .
- , . , , .
, . , - .
, .
3. . :
, : , , , . .
Azure DevOps
. TFS. , , , , .
TFS Aggregator. Task- PBI. , .. Release Notes, , Release Notes.
OLAP-. , , Time-to-Market, . . , – , .
. , , .
. , , .
– -. , , TFS.
. , . , .
Tugas lainnya adalah mengatur retrospektif sprint. Menurut ide kami, sistem harus bisa menginterpretasikan dan menginterpretasikan hasil sprint: apa yang direncanakan di awal sprint, apa yang diterima di akhir, bagaimana proses pengerjaannya dan jika ada kesulitan, lalu kemana. Kemudian, dalam retrospeksi, tim tidak akan terlibat dalam analisis subjektif dari hasil mereka, tetapi akan mengevaluasinya sesuai dengan data obyektif.