Diberikan: Perusahaan yang menggunakan Scaled Agile Framework (SAFe) untuk mengukur pengembangan Agile di seluruh organisasi; 10 tim pengembangan digabungkan menjadi satu tim besar (Agile Release Train, menurut terminologi SAFe) untuk menghasilkan produk bersama; perlunya perencanaan triwulanan dua hari (Perencanaan PI) untuk menentukan rencana kerja tim TI untuk 3 bulan ke depan *; tiga kantor pengembangan dengan jarak antara yang paling jauh melebihi 6 ribu kilometer dan selisih waktu kerja 5 jam; pengalaman perencanaan sebelumnya yang menyiratkan penggunaan papan analog / papan tulis / stabilo / catatan tempel dan kehadiran fisik masing-masing dari semua karyawan kunci di ruangan yang sama.
* Konstruksi kelas berat ini "Rencana kerja tim TI untuk 3 bulan ke depan" mengancam untuk meningkatkan ukuran teks secara signifikan, jadi selanjutnya saya akan menggantinya dengan "komitmen". Dengan demikian, untuk menyusun dan mengadopsi rencana kerja akan "berkomitmen".
Mengapa kita membutuhkan ini?
1) Kelelahan dengan metode kerja analog. Sementara pesawat ruang angkasa membajak Ruang, dan Elon Musk membosankan terowongannya, kami, orang-orang IT, telah terus-menerus menulis dengan stabilo pada catatan tempel menempelkan mereka di papan - benar-benar ada semacam disonansi dalam hal ini, tidak ada ? Seperti itulah komitmen kami beberapa waktu yang lalu:
Ya, ini adalah selembar kertas berukuran sekitar 2 kali 5 meter, dengan setiap catatan tempel diubah menjadi tugas JIRA setelah perencanaan ...
2) Kelelahan kolega nomaden kami. Terlepas dari kenyataan bahwa kantor pusat kami terletak di negara yang agak menyenangkan dan hangat, saya terkejut mengetahui tahun lalu bahwa mereka jauh dari senang tentang semua perjalanan bolak-balik. Argumen saya “Oh well, Anda bisa bersenang-senang bersantai di bawah sinar matahari di pantai” diterima dengan tidak terlalu hangat. Ternyata tidak semua orang siap untuk perjalanan bisnis yang sering, yang sering tidak disambut oleh keluarga mereka, beberapa rekan hanya tidak tahan sepanjang waktu di udara mengingat jarak antara kantor dan frekuensi pertemuan.
3) Melibatkan lebih banyak kolega TI dalam proses perencanaan. Seperti yang jelas dari paragraf di atas, kami hampir tidak mampu untuk memiliki semua staf TI dari tiga kantor yang datang untuk perencanaan, sehingga hanya Yang Terpilih yang dipilih, jenis yang dikecualikan yang lain dari proses. Ini hampir tidak bermanfaat bagi semangat tim pada umumnya.
4) Optimalisasi biaya. Ya, ini adalah saat yang sensitif - ada cukup banyak orang-orang penting dan membuat mereka terbang bolak-balik empat kali setahun bukanlah murah.
Bagian Nol: Bekerja dengan Backlog Portofolio
Semuanya dimulai jauh lebih awal daripada perencanaan yang sebenarnya. Agar dapat bekerja secara produktif pada Komitmen selama perencanaan, Anda harus memiliki sesuatu untuk dijanjikan. Untuk memastikan ini, saya harus "memuat" pemilik bisnis dengan pekerjaan pada inisiatif yang mungkin (atau, dalam terminologi SAFe, Epics, tetapi selanjutnya saya akan menggunakan istilah yang biasa kita gunakan) sedini mungkin. Idealnya, proses ini harus sepenuhnya dipisahkan dari sifat berulang perencanaan triwulanan dan berjalan seperti Kanban sendiri. Kami menggunakan SAFe Portofolio Kanban sebagai dasar:
Kami memiliki proyek JIRA terpisah dengan tiga jenis masalah: Epos, Inisiatif Bisnis dan Inisiatif Arsitektur; serta Dewan Kanban yang sesuai. Algoritma untuk Pemilik Bisnis Inisiatif sederhana: ia menambahkan masalah ke proyek ini, dan masuk ke Backlog secara default, yang merupakan status pertama aliran Kanban kami -
Corong:
Di sini Inisiatif yang belum siap untuk Peninjauan disimpan. Pemilik Bisnis mengerjakan konten Inisiatif hingga ia merasa siap untuk langkah selanjutnya. Minimum yang diperlukan pada tahap ini adalah mengisi bidang Pernyataan Masalah, Hasil yang Diinginkan dan Ukuran Keberhasilan, serta presentasi yang sedikit lebih rinci, tetapi sederhana dan jelas. Pada tahap ini, penting untuk mengesampingkan solusi teknis dan fokus pada parameter bisnis. Ketika semua data dikumpulkan, Pemilik Bisnis memindahkan tugas ke status berikutnya -
Meninjau.Kami melakukan Ulasan setiap minggu untuk Inisiatif Bisnis dan Arsitektur. Idealnya ini adalah presentasi lima menit dengan tanya jawab selanjutnya. Sebagai hasil Peninjauan, keputusan diambil tentang apa yang terjadi pada Inisiatif selanjutnya. Itu bisa:
- dikembalikan ke Funnel untuk direvisi,
- dihapuskan tanpa kesempatan untuk kehidupan lebih lanjut (dalam hal ini saya menggunakan status Out-of-Date khusus yang disembunyikan di Dewan Kanban),
- disetujui dan dipindahkan ke tahap berikutnya - Menganalisis.
Pada tahap ini kita - Yippee !!! - Akhirnya bisa melibatkan orang-orang IT: analis, arsitek, prospek, siapa pun. Yang saya maksud dengan "kita" adalah Insinyur Kereta Api Rilis. Tetapi idealnya juga pemilik bisnis, yang telah memperoleh beberapa pengalaman dan otonomi yang diperlukan untuk melibatkan tim yang tepat dan secara mandiri meluncurkan analitik. Sekali lagi, saya menulis tentang kasus ideal di sini. Kenyataannya tingkat pengaturan diri rekan-rekan kita mengambang, dan dalam beberapa kasus mereka meminta bantuan fasilitator yang ditunjuk secara khusus, tetapi saya mencoba untuk mundur dari praktik ini.
Tujuan dari tahap ini adalah analitik pendahuluan, atau, seperti yang kita sebut, Pra-penemuan. Sebagai hasilnya kita harus mendapatkan minimum yang memungkinkan kita untuk melakukan: solusi yang diusulkan, risiko dan dependensi, persyaratan non-fungsional dan infrastruktur, peta pengguna, skema arsitektur. Selain itu, kami meminta tim untuk memberikan penilaian awal dalam poin cerita di tingkat fitur - ini akan memungkinkan kami untuk menentukan prioritas pada akhir kuartal.
Papan Kanban pribadi dibuat pada tahap ini untuk setiap Inisiatif, di mana fitur dan cerita dapat dilihat, dengan tautan awal ke iterasi tertentu, yang disediakan oleh alur kerja JIRA yang terpisah. Jadi dengan mengubah status kita dapat menetapkan masalah ke beberapa iterasi. Swimlan di Papan Kanban dikonfigurasikan oleh tim pengembangan. Karena ekosistem JIRA kami agak rumit, selama Pra-penemuan dan Penemuan kami membuat tugas-tugas dalam proyek-proyek terpisah agar tidak membuang sampah sembarangan tim:
Juga pada tahap Pra-penemuan, kami melibatkan Arsitek atau, seperti yang sering dilakukan akhir-akhir ini, orang-orang tepercaya mereka - “Duta EA”. Tugas mereka adalah untuk menyampaikan visi departemen arsitektur kepada semua peserta, untuk membantu menemukan solusi terbaik, dan akhirnya menyetujui solusi ini dengan kepala perusahaan Arsitektur Perusahaan.
Ketika semua orang yang terlibat percaya bahwa Inisiatif telah cukup dianalisis dan siap untuk langkah selanjutnya, ia dipindahkan ke status berikutnya -
Portofolio Backlog.Pada tahap ini, penting untuk melakukan penentuan prioritas WSJF (
Pekerjaan Tertimbang Tertimbang Pertama ). Untuk melakukan ini, kami memiliki pertemuan besar 3 minggu sebelum perencanaan, yang, sayangnya, hingga kini selalu berlangsung berjam-jam. Selama pertemuan ini, anggota Dewan Manajemen mengevaluasi Nilai Bisnis, Kritik Waktu, Pengurangan Risiko dan Pemberdayaan Peluang dengan bantuan poker perencanaan yang selaras-Fibonacci:
Untuk dapat melacak sejarah Inisiatif, untuk masing-masing saya menambahkan label di JIRA dengan data kuartal: 2018Q4, 2019Q1, dll.
Ke depan, izinkan saya menjelaskan semua status yang mungkin. Setelah komitmen terakhir di PI Planning, Inisiatif yang berhasil diterapkan dipindahkan ke status
Implementing , sementara mereka yang 'tidak dilengkapi' menerima status
Parked dan mungkin dipertimbangkan untuk kuartal berikutnya. Inisiatif yang disampaikan dipindahkan ke status
Selesai .
Hasilnya, kami memiliki gambar berikut di Papan Kanban:
Tentu saja, kita bahkan belum di tengah jalan, tetapi saat ini saya sudah dapat mencatat bahwa berkat implementasi Portofolio Backlog
- Pemilik bisnis telah mulai bekerja melalui Inisiatif mereka secara terperinci dan benar-benar mempersiapkan diri untuk Tinjauan.
- Ulasan menjadi lebih teliti dengan cara yang baik.
- Tim memiliki lebih banyak waktu untuk Pra-penemuan.
- Saya tidak kehilangan Inisiatif lama - Saya selalu dapat kembali ke Parked, tidak menyampaikan atau melupakan Inisiatif dan mengerjakannya lebih lanjut.
Alat yang digunakan pada tahap ini:
- Server Perangkat Lunak Atlassian Jira
- Warna Plugin untuk Jira - untuk menyoroti Inisiatif Bisnis dan Arsitektur
- Plugin 'Struktur - Manajemen Proyek pada Skala' - untuk memvisualisasikan struktur yang terbuat dari Inisiatif dan fitur milik mereka, dan prioritas WSJF mereka
- Atlassian Confluence - sumber dokumentasi internal
- Lucidchart dan plugin-nya untuk Jira dan Confluence - untuk menggambar diagram
Bagian I. Persiapan Perencanaan PI
Sebulan sebelum Perencanaan PI adalah ketika waktu tersibuk datang. Terlalu banyak hal yang perlu diperhitungkan, dan agar tidak meninggalkan apa pun, saya harus membuat Formulir Google "logistik" multipage. Izinkan saya menjelaskan tab paling penting dari Formulir ini dan kegiatan di sekitarnya.
Umpan balik Beberapa hari setelah masing-masing Perencanaan PI kami melakukan Retrospektif, yang membantu kami untuk tidak melupakan kesimpulan apa yang kami dapatkan dan bagaimana kami perlu menyesuaikan kursus. Ini merupakan bagian penting dalam hal perbaikan berkelanjutan.
Persiapan teknis. Dengan transisi ke perencanaan jarak jauh, permintaan khusus telah muncul, seperti kualitas koneksi Internet (penentuan prioritas dan optimalisasi rute untuk JIRA dan Confluence) dan kehadiran video dan audio (kami menggunakan kit Logitec Group, mikrofon Jabbra, dan headphone pribadi dalam berbagai kombinasi , kamera web, perangkat lunak Zoom untuk konferensi video).
Fasilitator. Ini adalah daftar karyawan yang bertanggung jawab atas fasilitasi di masing-masing kelompok kerja, yang menunjukkan lokasi mereka dan tautan ke saluran Zoom permanen kelompok kerja.
Hadirin Daftar lengkap semua undangan.
Daftar periksa Daftar lengkap tugas penting dengan tenggat waktu dan orang yang bertanggung jawab. Untuk memberi Anda beberapa wawasan di bawah ini Anda dapat menemukan beberapa contoh tugas paling khas dan vital yang relevan untuk masing-masing Perencanaan PI: pelatihan Fasilitator (manual pelatihan telah disiapkan dengan semua langkah yang diperlukan seperti mengorganisir tim kerja, mengatur waktu pertemuan dan mendekomposisi Inisiatif ke dalam daftar fitur); pembaruan rencana lokasi kelompok kerja untuk setiap kantor; kontrol pembaruan Velocity untuk semua tim pengembangan; memesan makanan; membuat laporan dari kuartal sebelumnya; cetakan daftar Inisiatif dan jadwal.
Bagian II. Perencanaan PI dan proses Komitmen
Setelah semua persiapan berjalan, saat ini akhirnya tiba - awal dari Perencanaan PI. Dalam dua hari kami harus menemukan semua Inisiatif, pastikan informasinya memadai dan berkomitmen. Setelah beberapa pembicaraan, kelompok kerja pergi ke tempat mereka dan mulai berbisnis. Saat ini jumlah grup didistribusikan di antara tiga kantor sebagai 4x4x2, dan pengguna jarak jauh terhubung ke grup yang diperlukan melalui saluran Zoom khusus.
Setelah Penemuan selesai pada masing-masing Inisiatif ini, fasilitator memastikan bahwa semua data yang diperlukan, seperti Kriteria Penerimaan, solusi teknis, risiko, ketergantungan, kebutuhan infrastruktur baru, tersedia dan menandai Inisiatif dengan 'IT Kotak centang Session Finished 'untuk memudahkan pelacakan kemajuan. Setelah itu kelompok kerja dapat beralih ke Inisiatif berikutnya.
Setelah selusin Perencanaan PI, perasaan berada di bawah tekanan konstan dan tekanan waktu, yang bersama kami sejak awal, telah memudar secara signifikan, dan sekarang semuanya lebih seperti bekerja seperti biasa. Pada sore hari pada hari pertama dan kedua Perencanaan, inilah saatnya untuk komitmen yang tidak tergesa-gesa sesuai dengan prioritas. Untuk melakukan komitmen, saya memiliki beberapa struktur terpisah. Yang pertama adalah struktur yang berisi daftar fitur dan cerita yang dijadwalkan untuk komitmen:
Sayangnya, struktur pada tangkapan layar ini hanya berisi tugas yang tidak sesuai dengan komitmen kuartal saat ini, sehingga sampel tidak representatif. Dalam kasus apa pun, di bidang pencarian saya dapat memilih Inisiatif yang diperlukan dalam urutan prioritas berdasarkan nomor, yang diletakkan di bidang terpisah untuk setiap fitur dan cerita, mengubah status masalah dari Direncanakan ke Komitmen dan menempatkannya ke iterasi yang diinginkan , dengan demikian berkomitmen untuk mereka:
Akibatnya, masalah akan hilang dari struktur ini dan muncul dalam yang baru, yang mencerminkan komitmen yang berkembang:
Seperti yang dapat Anda lihat pada tangkapan layar, dalam struktur ini kisah-kisah tersebut jatuh ke dalam folder tim pengembangan tempat mereka berada dan dikelompokkan berdasarkan iterasi. Di sini, saya melihat Velocity total tim dalam nama folder, dan sebagai tambahan di kolom Komitmen, komitmen berlebihan secara otomatis ditentukan dan disorot untuk setiap tim, dengan menggunakan formula khusus.
Tentu saja, jika Inisiatif prioritas pertama dan tertinggi dimasukkan ke dalam komitmen dengan mudah, segera, karena semakin banyak tim mengisi simpanan mereka sampai akhir, mungkin akan ada masalah masing-masing dengan beberapa inisiatif, setelah argumen dan diskusi tertentu, menjadi ditunda (diparkir) sebagai hasilnya.
Pada akhir proses yang cukup mudah ini, tim bersumpah untuk memberikan komitmen mereka pada bendera perusahaan (ok, tidak benar-benar) dan bergegas ke rumah mereka (well, sekali lagi, tidak benar-benar, sebagian besar mereka melarikan diri ke bar untuk merayakan).
Alat yang digunakan pada tahap ini:
- Server Perangkat Lunak Atlassian Jira
- Plugin 'Struktur - Manajemen Proyek pada Skala' - untuk memantau proses Penemuan dan selama pelaksanaan komitmen.
Bagian III. Mengkloning masalah ke dalam ekosistem JIRA yang berfungsi di Perusahaan
Sementara semua orang minum, RTE berupaya menciptakan komitmen dalam bentuk di mana ia dapat didistribusikan ke simpanan tim pengembangan dan dipantau sepanjang kuartal. Untuk melakukan ini, saya menggunakan plugin 'Bulk Clone Professional for Jira' - itu menambahkan item melakukan kloning kolektif ke menu Perubahan Massal dan memiliki fitur yang diperlukan seperti tautan kloning, memperbarui tautan antara klon yang baru dibuat, memperbarui tautan Epic, menambahkan Ringkasan awalan dan pelabelan otomatis:
Saya menambahkan status sebagai awalan, karena pada tahap perencanaan status mencerminkan iterasi penyelesaian yang direncanakan. Sebagai hasilnya, saya dapat langsung melihat dalam Ringkasan ketika kami berencana untuk menyelesaikan fitur atau cerita.
Pada awalnya, saya mengkloning semua masalah menjadi proyek Global Backlog yang terpisah, karena kami menyimpan epos di dalamnya, dan saya harus memiliki koneksi kisah epik aktual dalam tugas-tugas yang baru dikloning. Dan sudah sebagai langkah kedua, saya membuat permintaan JQL untuk setiap tim pengembangan secara terpisah dan memindahkan cerita ke dalam proyek kerja tim.
Sebagai hasilnya, saya membuat struktur yang mencerminkan Komitmen saat ini dan terdiri dari cerita-cerita akhir, yang kemudian saya gunakan untuk memonitor:
Secara umum, keuntungan dari pendekatan ini adalah sebagai berikut:
- Lebih mudah bagi seorang pria IT untuk mengetik fitur dan cerita baru daripada menuliskannya dengan stabilo pada catatan tempel.
- Banyak hal, seperti sisa kapasitas dan pembaruan WSJF tergantung pada estimasi cerita, dihitung secara otomatis menggunakan formula khusus.
- Berkat kloning, Komitmen awal dipertahankan untuk sejarah dan kami selalu dapat kembali ke sana.
- Ini menghemat waktu dan energi kita pada tahap persiapan perencanaan - penanganan kertas membutuhkan energi.
- Tentu saja, sangat menyenangkan bahwa kita tidak perlu lagi menambahkan masalah ke JIRA dengan mengetikkan catatan tempel.
Alat yang digunakan pada tahap ini:
- Server Perangkat Lunak Atlassian Jira
- Plugin 'Bulk Clone Professional for Jira'– untuk mengkloning fitur dan cerita ke dalam proyek JIRA yang berfungsi.
- Plugin 'Struktur - Manajemen Proyek pada Skala' - untuk pembuatan struktur Komitmen akhir.
Epilog
Dear Friends, tentu saja saya mengerti bahwa gambaran di atas agak dangkal, dan banyak hal dapat diungkapkan dengan cara yang lebih rinci - memantau distribusi kapasitas antara inisiatif Bisnis dan Arsitektur dan tugas-tugas operasional, menghitung formula khusus dalam struktur, mengelola risiko dan masih banyak lagi. Tetapi saya masih tidak tahu apakah topik ini menarik bagi audiens, dan jika ya, dari apa tepatnya. Jika saya melihat minat, saya akan senang untuk berbagi wawasan saya tentang topik yang relevan.
Dan satu hal lagi - sulit untuk percaya itu mungkin, tapi tetap saya benar-benar ingin menghindari butthurt terkait dengan Agile, kerangka kerja, manajer yang efektif dan "efektif" dalam komentar. Harap ingat bahwa saya menggambarkan bagian teknis dari seluruh proses dengan harapan mendapatkan minat dari orang-orang yang dekat dengan topik ini, dan saya menantikan diskusi yang relevan.
Sampai jumpa di komentar!