Get best of the week

Proyek Ajile simultan (di bawah penjara) dan Air Terjun

Ada banyak kerangka kerja yang telah teruji dan siap pakai untuk mengatur alur kerja, di mana metode dan prinsip dijelaskan dengan baik. Jika kita merakit mobil, gunakan Kanban, siapkan kue - Lean, kembangkan situs web khusus - PMBoK. Penting untuk mempertimbangkan bahwa setiap proyek adalah unik dan membutuhkan adaptasi pendekatan, tetapi secara umum, untuk kasus Anda, kemungkinan besar sudah ada solusi yang cukup berguna. Membangun proses untuk diri saya sendiri, saya mengambil sedikit dari segalanya.

Dulu


Dia bekerja di sebuah startup. Satu produk, satu tim kecil, tidak ada batasan waktu yang ketat. Digunakan Scrum dan Kanban dalam bentuk paling murni, sehingga untuk berbicara. Kami menuliskan tugas-tugas di Trello dan menyeretnya ke 4 papan: ide, kita perlu melakukannya, di tempat kerja, sudah siap. Untuk membahas kemajuan pekerjaan, mereka menelepon setiap hari, dan seminggu sekali mereka merencanakan tugas untuk sprint berikutnya. Semuanya seperti yang dimiliki orang.

Telah menjadi


Setelah sedikit mengubah arah pengembangan, saya mencari pengalaman baru di sebuah studio web. Di sana, pertama-tama, dia terkejut dengan fleksibilitas bekerja dengan klien, dan, jika tanpa sarkasme, kurangnya sistem apa pun.

Untuk menunjukkan gambaran besarnya, saya akan memberikan contoh yang sangat sederhana.
Pelanggan A: Saya perlu mengembangkan halaman arahan untuk acara tanggal ini dan itu.
Manajer Proyek (MP): oke, kami akan melakukannya pada tanggal tertentu.
Pelanggan B: segera lakukan perubahan berikut pada situs.
MP: OK, tambahkan sesegera mungkin.

Selanjutnya, MP menyetujui estimasi untuk pelanggan A, menulis tugas ke pelacak, membuat proyek terpisah dan papan yang tidak terkait. Memberitahu tim apa yang harus dilakukan. Pengembang mulai memotong, dan setelah selesai, manajer menunjukkan hasilnya kepada pelanggan.

Entri dalam sistem terlihat seperti ini:
gambar

Masalah


Pendekatan pemeliharaan cukup logis, tetapi masalah berikut muncul:

  • Kurangnya koneksi yang terlihat antara
    tugas-tugas pelanggan dan tim .Tugas bisnis biasanya ditemukan dalam tabel, dan didekompilasi di Jira. Ketika seorang pengembang menulis metode API lain, untuk memahami siapa yang akan menggunakannya, Anda harus pergi ke manajer dan mengklarifikasi lagi.

  • Desainer prioritas yang salah melaporkan penyelesaian tata letak yang prematur (ya, ini juga terjadi). Dia bertanya: apa yang harus dilakukan selanjutnya? MP menetapkan tugas proyek keempat, yang pertama dalam daftar. Pada akhirnya, ia menyadari bahwa tugas keempat dari proyek pertama lebih penting.
  • Tidak ada representasi visual dari ruang lingkup pekerjaan.Tugas
    dalam proyek yang berbeda. Tidak ada yang ingin menyimpannya di kepala atau mencari katalog. Lebih mudah, ketika saya selesai, untuk bertanya: apa yang harus dilakukan selanjutnya?
  • Distribusi muatan yang tidak merata berdasarkan waktu dan karyawan.
    Jelas apa yang dilakukan Vasya dan Petya saat ini, lebih sulit untuk mengatakan siapa yang akan sibuk setelah 2 minggu dan apakah tugas mereka akan setara.
  • Saat merencanakan waktu penyelesaian, tugas dari proyek lain tidak diperhitungkan. Kami
    diminta untuk mengubah tautan di situs. Oh, mudah, ayo kita lakukan hari ini. Kemudian manajer ingat bahwa ada bug super kritis di situs lain. Akibatnya, perubahan tautan, menurut pelanggan, tim membentang selama seminggu.

Mungkin dalam contoh ini dengan suntingan dan halaman arahan tidak terlihat menakutkan, karena semua ini mudah diingat, tetapi dalam praktiknya mungkin ada 5 proyek pada saat yang sama dengan 40 tugas di masing-masing. Banyak proyek datang dari manajer lain. Papan, jenis tugas, metodologi di dalamnya dipilih sesuai dengan suasana hati mereka.

Konversi Melon


Untuk membuat sistem, pertama-tama perlu membawa data ke format tunggal. Mengubah massa entitas yang ditransfer ke saya, saya berhasil sampai pada konsep berikut:

gambar

Saya pikir semuanya jelas dari gambar, tetapi ada nuansa kecil yang terkait dengan implementasi di Jira. Mari kita menganalisis setiap entitas menggunakan contoh.

Dengan konsep proyek, semuanya tidak ambigu baik di benak masyarakat dan Atlassian. Ini adalah urutan tindakan yang bertujuan memperoleh hasil dalam waktu yang terbatas. Misalnya: untuk mengembangkan situs web, untuk mendukung aplikasi untuk seumur hidup, untuk membuat perusahaan periklanan.

Epik (rilis)- Potongan besar proyek yang terisolasi: akun pribadi, keranjang, katalog produk. Di sini ketidaksepakatan sudah mulai. Jira memiliki entitas - epik, tetapi saya masih menggunakan rilis.

Faktanya adalah bahwa untuk menerapkan struktur yang benar, perlu memiliki 3 tingkat bersarang, Jira pada saat penulisan artikel memiliki 2 + 1 (sejarah dan tugas berada pada level yang sama). +1 adalah sub-tugas, saya tidak memperhitungkannya, karena ia membawa fungsi komplemen daripada bersarang karena kurangnya fleksibilitas dan ikatan yang kuat dengan induk.

Alih-alih rilis, Anda bisa menggunakan komponen atau sprint, tetapi untuk tujuan saya mereka terlihat kurang berhasil. Untuk alasan yang sama, epik digunakan untuk merekam cerita.

Sejarah (epik) dalam struktur ini adalah tugas bisnis (keinginan pelanggan). Tugas- tindakan yang dapat dimengerti untuk menyelesaikan masalah bisnis.

Juga, beberapa penghitung dan bidang ditambahkan ke entitas. Yang paling penting dari mereka adalah skala untuk menilai kompleksitas tugas dari 1 hingga 10 di unit yang sewenang-wenang (story point).

Pembuatan sistem


Ada data, maka Anda perlu memutuskan dalam bentuk apa dan bagaimana menampilkannya. Saya membuat proyek umum untuk tim dan menulis kueri JQL untuk menarik tugas dari semua proyek kami ke dalamnya (kueri itu mudah dibuat di bagian masalah). Menambahkan papan Kanban dan status yang sesuai dengan proses teknis kami untuk itu: Backlog → Untuk melakukan → Melakukan → Memeriksa → Menguji → Mencocokkan → Selesai.

Gambaran berikut ternyata:

gambar

Sekarang semua tugas melalui siklus produksi tunggal, yang cukup universal (Anda tidak dapat menguji desain, tetapi segera transfer ke perjanjian). Dalam hal kegagalan pada tahap apa pun, komentar ditambahkan ke tugas dan dikirim kembali ke Kepada. Setiap tugas memiliki tautan yang terlihat ke proyek, riwayat klien (epik) dan epik (rilis).

Menggunakan kueri JQL yang sama dengan plugin BigGantt (atau lainnya) untuk Jira, tugas dapat dilihat dalam bentuk bagan Gantt. Ubah waktu tunggu, tenggat waktu, daftarkan dependensi, lihat beban pada pemain. Ciutkan tugas dalam sejarah, riwayat dalam epos, mis. memvisualisasikan peta jalan atau rencana kerja terperinci.

Bagian administratif


Dari metodologi, Lean digunakan (urutan tindakan ditentukan, sementara kemungkinan pelaksanaan paralel tugas tetap), Kanban (tugas beralih dari spesialis ke spesialis, hambatan mudah diidentifikasi). Dari Scrum mengambil pertemuan harian untuk mempertahankan pemahaman tentang siapa yang melakukan apa. Mereka juga menilai kompleksitas tugas-tugas baru dalam poin cerita. Saya ingin, tetapi tidak dapat menggunakan sprint, karena pelanggan terkadang mengubah prioritas tugas, dan tidak mungkin lagi untuk mengatur jumlah pekerjaan setelah dimulainya sprint.

Setelah pertemuan, tugas diprioritaskan dalam jaminan, pelaksana ditugaskan, dan ditransfer ke Aktivitas. Pengembang membuat cabang di BitBucket, tugas secara otomatis beralih ke Melakukan. Setelah selesai, "pengembang" transfer ke Review, artis beralih ke pengembang lain. Jika semuanya baik-baik saja, "resensi" membuat penggabungan dan kode ada di server pengujian. Jira mengirimkan tugas ke penguji. Setelah verifikasi, QA mentransfernya ke manajer. Itu menunjukkan pelanggan. Pelanggan puas - kode dikirim ke server pertempuran di bawah pengawasan ketat dari tes otomatis harian.

Terima kasih untuk otomasi seperti itu, terima kasih kepada insinyur devops kami. Saya baru saja mengonfigurasi perubahan status dan pelaksana untuk acara dari git. Ini dilakukan dalam pengaturan proses bisnis, jika Anda bekerja di dalam ekosistem Atlasia. Dan ketika menggunakan GitLab, Bitrix, Redmine harus mengotak-atik.

Solusi


Mari kita lihat apa yang berhasil kami capai:

  • Kurangnya hubungan yang terlihat antara tugas pelanggan dan tim.
    Tugas bisnis dicatat dalam Jira sebagai cerita (epik), mereka dapat dilihat dengan persentase penyelesaian dan pada grafik Gantt. Pengembang, melakukan tugas, melihat cerita mana yang dimilikinya, dapat pergi dan membaca deskripsi.
  • Prioritas yang salah
    Perancang, setelah menyelesaikan tugas sebelumnya, mengambil yang baru dari bagian atas daftar Aktivitas, di mana mereka diprioritaskan oleh rasio poin cerita ke biaya (tugas bisnis dalam rubel).
  • Tidak ada representasi visual dari lingkup pekerjaan.
    Tugas dalam satu proyek. Setiap anggota tim melihat bagaimana mereka bergerak di sepanjang papan Kanban, pekerjaan umum. Apa yang telah dilakukan dan apa yang masih harus dilakukan.
  • Distribusi muatan yang tidak merata berdasarkan waktu dan
    staf.Gantt chart memungkinkan Anda merencanakan pekerjaan pada horizon yang panjang (dengan pembaruan yang konstan). Ada proyeksi pada pemain. Itu bisa dilihat ketika pelaksana memiliki 2 tugas sekaligus, sementara seseorang tidak memilikinya.
  • Saat merencanakan waktu penyelesaian, tugas dari proyek lain tidak diperhitungkan.
    Menambahkan tugas baru ke proyek apa pun, itu dapat dilihat di simpanan umum. Prioritas sehubungan dengan tugas-tugas lain ditetapkan untuknya dalam satu metrik tunggal.

Rencana


Beberapa proses dikurangi atau diotomatisasi, tetapi lebih banyak lagi yang tersisa dalam rencana:

Pembuatan estimasi waktu & materi proyek


Melakukan setiap tugas, karyawan mencatat waktu di dalamnya. Mengetahui tingkat per jam dari setiap orang, posisinya, faktor koreksi (dengan berapa banyak untuk dikalikan dengan memperhitungkan biaya perusahaan), Anda dapat menghasilkan tabel dengan daftar pekerjaan dan biaya.

Penyelesaian otomatis antara manajer


Jika saya memiliki tugas, tetapi tidak ada sumber daya yang cukup untuk menyelesaikannya, saya meminta manajer lain untuk kontraktor. Ketika tiba saatnya untuk membuat laporan, saya membawa sebagai pengeluaran, jam-jam karyawan yang dihabiskan ke dalam rencana saya dan sebagai penghasilan ke dalam rencana manajer lain.

Setiap bulan saya harus meningkatkan semua pekerjaan, memeriksa dengan manajer, memperbanyak dan mengurangi tanpa kreatif. Jika semua karyawan beralih ke format data tunggal (cara melakukan proyek di Jira), semua perhitungan akan mungkin dilakukan tanpa campur tangan manusia.

More articles:


All Articles