Diberikan: Perusahaan yang menggunakan kerangka Tangkas Agile (SAFe) untuk skala pengembangan Agile di seluruh organisasi; 10 tim pengembangan, digabung menjadi satu tim besar (Agile Release Train, menurut terminologi SAFe), memberikan produk yang sama; perlunya perencanaan triwulanan dua hari (Perencanaan PI) untuk menentukan rencana kerja tim TI untuk 3 bulan ke depan *; tiga kantor pengembangan, jarak antara yang paling jauh melebihi 6 ribu kilometer dengan perbedaan waktu kerja 5 jam; pengalaman perencanaan sebelumnya yang melibatkan kehadiran fisik rekan kunci di ruangan yang sama dan penggunaan papan analog / papan tulis / spidol / catatan tempel.
* Konstruksi kelas berat "Rencana Kerja Tim TI untuk 3 Bulan Berikutnya" mengancam untuk secara serius meningkatkan volume teks, jadi di masa depan saya berencana untuk menulis hanya - "komentar" saja. Dengan demikian, buat dan adopsi rencana kerja - "berkomitmen".
Mengapa ini dibutuhkan?
1) Kelelahan dari metode kerja analog. Sementara pesawat ruang angkasa membajak ruang terbuka, dan Elon Musk menggali terowongan, kami, spesialis IT, terus-menerus menulis dengan spidol pada selembar kertas lengket dan memahatnya di papan - ini adalah semacam disonansi. Inilah komentar kami beberapa waktu yang lalu:
Ya, ini adalah selembar kertas berukuran sekitar 2x5 meter, dan setelah perencanaan, setiap lembar kertas harus diubah menjadi tugas di Jira ...
2) Kelelahan sesama pengembara. Terlepas dari kenyataan bahwa kantor pusat kami terletak di negara yang agak ramah dan hangat, mengejutkan saya tahun lalu saya menemukan bahwa mereka sama sekali tidak senang dengan kehidupan nomaden, dan argumen saya dalam gaya "ayolah, berenang di laut, berjemur di bawah sinar matahari ”, yang saya ungkapkan dengan tidak bijaksana, tidak diterima dengan hangat - tidak semua orang siap untuk perjalanan bisnis yang sering, rumah tangga mereka tidak selalu menyambut ini, seseorang tidak bereaksi sangat baik terhadap penerbangan yang sering.
3) Menghubungkan lebih banyak kolega dari TI ke proses perencanaan. Seperti yang jelas dari paragraf sebelumnya, kami tidak dapat mengirim seluruh kantor untuk perencanaan, oleh karena itu kami hanya mengirim yang Terpilih, sehingga tidak termasuk sisanya dari proses, yang tidak menambah nilai tambah pada moral umum.
4) Optimalisasi biaya keuangan. Ya, ini adalah saat yang sensitif - ada banyak orang penting, dan membawa mereka bolak-balik empat kali setahun adalah overhead.
Bagian Nol, atau Portofolio-Backlog
Dan itu semua dimulai jauh lebih awal - untuk bekerja dengan baik pada komentar selama perencanaan, perlu ada sesuatu untuk dilakukan. Untuk memastikan ini, saya harus "memuat" pemilik bisnis dengan bekerja pada inisiatif yang diusulkan (atau, dalam terminologi SAFe, Epicam, tetapi saya akan menggunakan istilah yang akrab bagi saya) sedini mungkin. Idealnya, proses ini harus sepenuhnya dipisahkan dari sifat siklus perencanaan triwulanan dan berjalan dengan cara kanban sendiri. Sebagai dasar, kami mengambil SAFe portfolio Kanban:
Kami memiliki proyek JIRA terpisah dengan tiga jenis tugas: epos, inisiatif bisnis, dan inisiatif arsitektur; serta papan Kanban yang sesuai. Algoritme untuk pemilik bisnis dari inisiatif ini sederhana: ia menambahkan tugas ke proyek ini, dan secara default masuk ke dalam Backlog - ini adalah status pertama kanban kami -
Corong:
Ini menyimpan inisiatif yang belum siap untuk ditinjau. Pemilik bisnis sedang mengerjakan isi dari inisiatif sampai dia merasa siap untuk langkah selanjutnya. Minimum yang diperlukan pada tahap ini adalah bidang Pernyataan Masalah, Hasil yang Diinginkan dan Ukuran Keberhasilan yang telah dilengkapi, serta presentasi yang sedikit lebih rinci, tetapi sederhana dan jelas. Pada tahap ini, penting untuk menghindari menyebutkan solusi teknis dan fokus pada parameter bisnis. Ketika semua data dikumpulkan, pemilik memindahkan tugas ke status berikutnya -
Meninjau.Kami melakukan peninjauan setiap minggu, baik untuk inisiatif bisnis maupun untuk arsitektur. Idealnya, ini adalah presentasi lima menit dengan jawaban pertanyaan selanjutnya. Hasil peninjauan adalah keputusan tentang nasib inisiatif. Dia bisa:
- kembali ke backlog untuk revisi
- hapus tanpa peluang untuk kehidupan lebih lanjut (untuk ini saya menggunakan status Out-of-Date yang terpisah , disembunyikan di papan Kanban)
- dapatkan persetujuan dan lanjutkan ke tahap berikutnya - Menganalisis.
Pada tahap ini, kita bersorak! - kita dapat menarik karyawan dari TI: analis, arsitek, prospek, siapa pun. Dengan “kami,” saya maksudkan diri saya sebagai Insinyur Kereta Api, tetapi dalam kasus yang ideal, pemilik bisnis yang telah memperoleh beberapa pengalaman dan kemandirian diperlukan untuk menarik tim yang tepat dan memulai proses analisis sendiri. Saya menulis tentang kasus yang ideal, karena tingkat pengaturan diri rekan-rekan kami mengambang, dan dalam beberapa kasus mereka meminta bantuan dalam bentuk fasilitator yang ditunjuk secara khusus, tetapi saya mencoba untuk mundur sedikit dari praktik ini.
Tujuan dari tahap ini adalah analitik pendahuluan, atau, seperti yang kita sebut, pra-penemuan. Di pintu keluar, kita harus mendapatkan minimum yang akan memungkinkan kita untuk berkomitmen: 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.
Untuk setiap inisiatif, papan Kanban pribadi dibuat, di mana, saat Anda membuatnya, Anda dapat melihat fitur dan cerita, dengan pengikatan awal untuk iterasi tertentu, yang disediakan oleh alur kerja terpisah dalam bentuk iterasi di masa depan. Di papan, tim khusus dikonfigurasikan sesuai dengan tim pengembangan. Karena ekosistem JIRA agak rumit, selama pra-penemuan dan penemuan, kami membuat tugas dalam proyek yang terpisah agar tidak mengacaukan simpanan perintah:
Juga, pada tahap analitik, arsitek terlibat dalam proses ini atau, seperti kebiasaan baru-baru ini, orang-orang yang mereka percayai adalah "Duta Besar" (Duta EA). Tugas mereka adalah untuk menyampaikan visi departemen arsitektur kepada para peserta proses, untuk membantu menemukan solusi terbaik dan, pada akhirnya, untuk mengoordinasikan keputusan ini dengan kepala arsitek perusahaan (Kepala Arsitektur Perusahaan).
Ketika tim percaya bahwa inisiatif dikembangkan dengan baik dan siap untuk langkah berikutnya, mereka memindahkannya ke status berikutnya -
Portofolio Backlog.
Pada tahap ini, langkah penting adalah melakukan prioritisasi WSJF (
Pekerjaan Tertimbang Terpendek Pertama ). Untuk melakukan ini, 3 minggu sebelum perencanaan, kami mengadakan pertemuan besar, yang, sayangnya, membutuhkan waktu berjam-jam, dan selama pertemuan ini, menggunakan skor poker Fibonacci, anggota dewan manajemen mengevaluasi Nilai Bisnis, kekritisan waktu ( Time Criticality), potensi Pengurangan Risiko dan Pemberdayaan Peluang:
Untuk dapat melacak sejarah inisiatif, masing-masing saya menambahkan label di jig dengan data pada kuartal: 2018Q4, 2019Q1, dll.
Ke depan, saya akan menjelaskan status yang mungkin berikut. Setelah melakukan, inisiatif yang berhasil diambil untuk bekerja beralih ke status
Implementing , sementara "tidak cocok" mendapatkan status
Parked dan di masa depan memiliki kesempatan untuk dipertimbangkan untuk kuartal berikutnya. Inisiatif yang disampaikan pindah ke
Selesai .
Hasilnya, kami memiliki sekitar gambar berikut di papan Kanban:
Tentu saja, kita bahkan tidak berada di tengah-tengah perjalanan, tetapi saat ini saya sudah dapat mencatat bahwa berkat penggunaan Kanban di tingkat Portofolio-Backlog
- Pemilik bisnis mulai mengerjakan inisiatif secara terperinci dan secara serius mempersiapkan tinjauan
- Ulasan menjadi lebih teliti dengan cara yang baik
- Tim memiliki lebih banyak waktu sebelum penemuan
- Saya tidak kehilangan inisiatif lama - Anda selalu dapat kembali ke inisiatif parkir, tidak terkirim atau dilupakan dan mengerjakannya lebih lanjut
Alat yang digunakan pada tahap ini:
- Server Perangkat Lunak Atlassian Jira
- Plugin Colors for Jira - untuk menyoroti inisiatif bisnis dan arsitektur
- Plugin 'Struktur - Manajemen Proyek Skala' - untuk memvisualisasikan struktur inisiatif dengan fitur-fitur yang terkait dengannya dan prioritas WSJF mereka
- Atlassian Confluence - Sumber Dokumentasi Internal
- Lucidchart dan plugin-nya untuk Jira dan Confluence - untuk charting
Bagian I. Mempersiapkan Perencanaan
Di suatu tempat sebulan sebelum perencanaan, ini adalah waktu yang panas untuk persiapan. Ada terlalu banyak untuk dipertimbangkan, dan agar tidak melupakan apa pun, Anda harus membuat tabel Google "logistik" multi-halaman. Saya akan mencoba menjelaskan tab paling penting dari tabel ini dan aktivitas di sekitarnya.
Umpan balik. Beberapa hari setelah setiap perencanaan, kami melakukan retrospektif, dan untuk menyesuaikan kursus, penting untuk tidak melupakan kesimpulan apa yang kami dapatkan dan bagaimana kami perlu menyesuaikan kursus. Ini adalah bagian penting dalam konteks peningkatan proses berkelanjutan.
Pelatihan teknis. Dengan transisi ke perencanaan jarak jauh, permintaan khusus muncul, seperti kualitas koneksi Internet (prioritas dan optimalisasi rute untuk JIRA dan Confluence) dan kehadiran televisi dan audio (kami menggunakan kit Logitec Group, mikrofon Jabbra, dan headphone pribadi dalam berbagai kombinasi, webcam, Zoom perangkat lunak untuk konferensi video).
Fasilitator. Berikut adalah daftar karyawan yang bertanggung jawab untuk fasilitasi di masing-masing kelompok kerja, yang menunjukkan lokasi mereka dan tautan ke saluran Zoom permanen dari kelompok kerja.
Hadirin. Dengan demikian, daftar lengkap semua undangan.
Daftar periksa. Daftar lengkap tugas penting dengan tenggat waktu dan yang bertanggung jawab. Untuk pencelupan yang lebih besar, saya akan memberikan beberapa contoh tugas yang paling khas dan penting yang diulangi untuk setiap perencanaan: pelatihan fasilitator (manual pelatihan telah disiapkan untuk fasilitator dengan semua langkah yang diperlukan dari pengorganisasian tim kerja, rapat waktu untuk mengeksplorasi opsi untuk solusi teknis dan untuk proses penguraian inisiatif menjadi daftar fitur) ; pembaruan rencana lokasi kelompok kerja untuk setiap kantor; kontrol pembaruan Velocity untuk semua tim pengembangan; pesanan makan siang; melaporkan kuartal sebelumnya; cetakan dari daftar inisiatif (siap sedia) dan jadwal.
Bagian II Perencanaan dan komentar
Setelah semua persiapan berjalan, akhirnya datanglah momen ini - awal dari perencanaan triwulanan. Dalam dua hari kita harus memiliki waktu untuk memilah-milah semua inisiatif, memastikan bahwa ada cukup informasi dan komitmen. Setelah beberapa pidato singkat namun mengharukan, kelompok kerja bubar di tempat masing-masing dan mulai berbisnis. Saat ini, jumlah grup didistribusikan antara tiga kantor sesuai dengan rumus 4x4x4, dan pengguna jarak jauh terhubung ke tabel yang diperlukan melalui saluran Zoom khusus.
Pada akhir penemuan masing-masing inisiatif, fasilitator, memastikan bahwa semua data yang diperlukan - seperti kriteria penerimaan, deskripsi solusi teknis, risiko, ketergantungan, kebutuhan infrastruktur baru - hadir, menandai inisiatif dengan kotak centang Selesai Sesi TI untuk transparansi kemajuan dan kelompok kerja. dapat pindah ke yang berikutnya.
Setelah selusin rencana, perasaan tegang yang konstan dan tekanan waktu sementara yang telah bersama kami sejak awal sebagian besar telah teratasi, dan sekarang suasananya lebih seperti pekerjaan yang tenang. Pada paruh kedua hari pertama dan kedua, waktunya tiba untuk komentar santai sesuai dengan prioritas. Untuk menjalankan komit, saya memiliki beberapa struktur terpisah. Yang pertama adalah struktur yang berisi daftar fitur dan jalur yang direncanakan untuk dikomentari:
Sayangnya, struktur ini mengandung sisa-sisa material yang tidak sesuai dengan komentar kuartal ini, sehingga sampel tidak representatif. Dalam kasus apa pun, dalam pencarian, saya dapat memilih inisiatif yang menarik minat saya dalam urutan prioritas berdasarkan angka, yang selama proses penemuan diletakkan di bidang terpisah untuk setiap fitur dan cerita, mengubah status tugas yang diperlukan dari Direncanakan ke Komitmen dan meletakkannya di iterasi yang tepat, dengan demikian melakukan sendiri:
Akibatnya, tugas akan menghilang dari struktur ini dan muncul di yang baru, mencerminkan komentar yang berkembang:
Seperti yang dapat Anda lihat di tangkapan layar, dalam struktur ini cerita masuk ke folder tim pengembangan tempat mereka berada dan dikelompokkan berdasarkan iterasi. Di sini, saya melihat kecepatan tim keseluruhan dalam nama folder, serta di kolom Komitmen, menggunakan rumus, overcomment untuk setiap grup secara otomatis ditentukan dan memberi sinyal kami dengan warna merah.
Tentu saja, jika inisiatif pertama dan paling prioritas masuk ke dalam komentar tanpa masalah, segera, dengan munculnya tim pertama yang telah mengisi simpanan mereka ke kegagalan, masalah dimulai dan beberapa inisiatif bukan tanpa debat, tetapi mereka harus ditunda.
Pada akhir proses sederhana ini, tim-tim di bendera perusahaan bersumpah untuk menyampaikan komentar (lelucon) dan mencarinya di rumah (juga lelucon - semua orang menyebar melalui bar).
Alat yang digunakan pada tahap ini:
- Server Perangkat Lunak Atlassian Jira
- Plugin 'Struktur - Manajemen Proyek pada Skala' - untuk memantau proses penemuan dan selama pelaksanaan komit.
Bagian III. Mengkloning tugas ke dalam ekosistem JIRA yang berfungsi di suatu perusahaan
Sementara semua orang minum vodka, RTE berupaya membuat komentar dalam bentuk di mana ia dapat didistribusikan ke tumpukan tim pengembangan dan dipantau sepanjang kuartal. Untuk melakukan ini, saya menggunakan plugin 'Bulk Clone Professional for Jira' - itu menambahkan item yang menyediakan kloning kolektif dalam menu Perubahan Massal, dan memiliki fitur yang diperlukan bagi saya sebagai tautan kloning, memperbarui tautan antara klon yang baru dibuat, memperbarui tautan epik, menambahkan awalan di header dan secara otomatis menambahkan pintasan:
Saya menambahkan status sebagai awalan, karena pada tahap perencanaan status mencerminkan iterasi penyelesaian yang direncanakan, dan sebagai hasilnya, saya langsung melihat di header ketika kami berencana untuk menyelesaikan fitur atau cerita.
Pertama, saya mengkloning semua tugas menjadi proyek Global Backlog yang terpisah, karena kami menyimpan epos di dalamnya, dan saya perlu memiliki koneksi kisah epik aktual dalam tugas yang baru dikloning. Dan sebagai langkah kedua, saya membuat permintaan untuk setiap tim pengembangan secara terpisah dan memindahkan cerita ke proyek akhir tim.
Sebagai hasilnya, saya membuat struktur yang mencerminkan komentar saat ini dan terdiri dari tugas akhir, yang kemudian saya gunakan untuk memonitor:
Secara umum, manfaat yang dihasilkan dari pendekatan ini adalah sebagai berikut:
- Mungkin terdengar klise, tetapi lebih mudah bagi seseorang dari IT untuk mencetak fitur dan cerita baru daripada menulis dengan spidol di selembar kertas yang lengket.
- Banyak hal, seperti keseimbangan kapasitas dan pembaruan WSJF, tergantung pada peringkat, dihitung secara otomatis menggunakan formula.
- Berkat kloning, pemeran asli dari komit disimpan untuk cerita dan Anda selalu dapat kembali ke sana.
- Waktu dan energi sangat dihemat untuk persiapan perencanaan - bekerja dengan kertas membutuhkan kekuatan.
- Tentu saja, sangat menyenangkan bahwa Anda tidak perlu lagi memasukkan puzzle ke dalam gira.
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 akhir.
- Plugin 'Struktur - Manajemen Proyek pada Skala' - untuk membuat struktur akhir.
Epilog
Teman-teman, tentu saja, saya mengerti bahwa uraiannya sangat dangkal, dan banyak hal dapat diungkapkan secara lebih rinci - memantau distribusi modal antara inisiatif bisnis dan arsitektur dan tugas-tugas operasional, menghitung formula dalam struktur, manajemen risiko, dan banyak lagi. Tetapi belum jelas bagi saya apakah topik ini menarik bagi audiens, dan jika demikian, apa tepatnya. Jika saya melihat minat, saya akan siap untuk mengungkapkan topik yang diperlukan.
Dan satu hal lagi - sulit untuk percaya bahwa ini mungkin, tetapi saya ingin menghindari semua masalah di sekitar Edge, kerangka kerja, manajer yang efektif dan "efisien". Harap ingat bahwa saya menggambarkan seluruh proses dengan harapan orang-orang menarik yang dekat dengannya dengan penerapan teknisnya, dan saya benar-benar menantikan diskusi yang relevan.
Sampai jumpa di komentar!