Irama Penghantaran Tanpa Tersangkut dalam Perancangan

Jumaat pukul 4:30 petang. Anda membuka kalendar, mengira blok mesyuarat yang berwarna biru, dan menjumlahkannya. Sembilan jam minggu ini. Perancangan sprint pada Isnin. Penghalusan pertengahan sprint pada Rabu. Satu retro yang bertukar menjadi sesi perancangan lain pada Khamis. Tiga sesi anggaran yang anda jadualkan kerana tiket tidak "bersedia." Dan pasukan menghantar satu ciri sahaja.

Ia bukan pun ciri yang anda rancangkan. Seorang IC kanan dalam pasukan anda menyedari sesuatu yang jelas rosak pada Rabu pagi, membuka PR sebelum waktu makan tengah hari, dan menggabungkannya sebelum standup pada Khamis. Perkara yang tiada siapa yang menganggarkan skopnya, tiada siapa yang menetapkan nilainya, tiada siapa yang meletakkan pada papan.

Anda berfikir: pasukan saya menghantar walaupun ada perancangan saya, bukan kerananya.

Jika senario itu terdengar biasa, panduan ini adalah untuk anda. Saya telah membimbing EM melalui corak ini, dan pembaikannya bukan "perancangan yang lebih baik." Pembaikannya adalah lebih sedikit perancangan, yang disusun secara berbeza, dengan satu isyarat sebenar yang benar-benar anda perhatikan.

Mengapa Perancangan Memakan Minggu Anda (dan Tidak Membaiki Apa-apa)

Kira-kirakan. Enam jurutera, perancangan dua jam setiap dua minggu, ditambah penghalusan pertengahan sprint satu jam, ditambah retro satu jam. Itu 24 jam-jurutera setiap sprint hanya dalam perancangan formal. Tambah persediaan EM (biasanya 3 hingga 4 jam setiap sprint), persediaan tech lead (2 jam), dan penghalusan tiket async dalam urutan Slack (tidak terkira). Anda membelanjakan setara dengan minggu penuh seorang jurutera kanan, setiap dua minggu, untuk perancangan.

Apa yang anda beli dengan itu? Dalam kebanyakan pasukan yang pernah saya lihat, ia membeli anggaran yang tersalah sebanyak 3 hingga 4 kali ganda, backlog yang disusun semula keutamaannya setiap minggu juga, dan item tindakan retro yang tiada siapa yang memilikinya menjelang Rabu.

Soalan sebenar bukan "bagaimana kita merancang dengan lebih baik?" Soalannya ialah "untuk apa sebenarnya perancangan itu?" Ringkaskan ia. Perancangan menghasilkan tiga perkara yang diperlukan pasukan: senarai pendek tentang apa yang perlu dilakukan seterusnya, pemilik yang dinamakan, dan rasa bersama tentang apa yang berisiko. Segala-galanya yang lain adalah pertunjukan semata-mata.

Perangkap itu ialah upacara perancangan terasa produktif. Anda meninggalkan bilik dengan papan sprint yang diisi. Ia kelihatan seperti kerja berlaku. Tetapi papan sprint yang diisi tidak menghantar kod. IC yang menulis PR menghantar kod. Setiap jam yang anda simpan seorang jurutera dalam mesyuarat perancangan adalah sejam yang mereka tidak membentuk masalah atau membuka PR.

Perancangan sebagai Spike, Bukan Upacara

Inilah framing semula: perancangan adalah spike. Siasatan yang pendek dan berfokus dengan input dan output yang jelas. Bukan upacara berulang. Bukan blok kalendar yang ditakuti.

Satu jam. Sekali seminggu. Kehadiran seluruh pasukan adalah pilihan, EM dan tech lead diwajibkan.

Contoh agenda yang pernah saya gunakan bersama tiga pasukan yang berbeza:

• 0 hingga 10 minit, apa yang dihantar, apa yang tidak. Tinjau papan minggu lalu. Tiada menyalahkan. Hanya status. Jika sesuatu tidak dihantar, namakan sebabnya dalam satu ayat: "dihalang dalam semakan," "skop lebih besar daripada yang disangka," "diganggu oleh insiden." Itu sahaja.
• 10 hingga 25 minit, apa yang dihalang. Apa sahaja yang duduk lebih daripada 48 jam tanpa pergerakan. tech lead dan EM membuat keputusan: buka halangan sekarang, hapuskan, atau eskalasikan. Keputusan, bukan perbincangan.
• 25 hingga 50 minit, 5 hingga 7 tiket seterusnya. Bukan keseluruhan sprint. Lima hingga 7 perkara seterusnya. Untuk setiap satu: pemilik, selera kasaran (kecil/sederhana/besar), dan satu risiko yang mungkin meletup. Tiada story points. Tiada Fibonacci. Tiada planning poker.
• 50 hingga 60 minit, soalan terbuka. Apa sahaja yang dibimbangkan oleh sesiapa yang tidak muat di atas. Letak dalam tulisan jika tidak dapat diselesaikan dalam 10 minit.

Itu sahaja. Pasukan yang saya bekerja bersama dalam organisasi kejuruteraan 40 orang mengurangkan perancangan daripada 8 jam seminggu kepada 1 jam menggunakan sesuatu yang serupa. Daya pemprosesan mereka meningkat, bukan menurun, dalam bulan pertama.

Bahagian yang paling sukar adalah disiplin untuk meninggalkan bilik apabila jam telah tamat. Ada soalan terbuka? Tuliskan, bawa ke luar, putuskan secara async. Jangan panjangkan mesyuarat. Mesyuarat berakhir pada jam itu, setiap kali, atau semuanya runtuh kembali menjadi upacara.

Perdebatan Shape Up 6 Minggu berbanding Sprint 2 Minggu

Ada perdebatan yang telah lama berlangsung dalam pengurusan kejuruteraan tentang kadens: sprint 2 minggu (berperisa Scrum) berbanding kitaran shape-up 6 minggu (model Basecamp dari "Shape Up"). Saya akan jimatkan anda daripada perang keagamaan.

Gunakan kitaran 6 minggu apabila kerja anda berbentuk ciri. Anda mempunyai 3 hingga 6 minggu skop yang bermakna dan terdefinisi dengan baik. Pasukan boleh komited kepada satu pertaruhan besar, mengusahakannya dengan sengaja, dan menghantar sesuatu yang penting. Shape Up bersinar di sini kerana selera (masa maksimum yang anda akan habiskan sebelum memotong skop) sudah dibina ke dalam model.

Gunakan sprint 2 minggu apabila kerja anda bersifat reaktif. Eskalasi pelanggan, insiden infrastruktur, kejuruteraan sokongan, kerja platform di mana permintaan datang lebih pantas daripada yang boleh anda rancang. Sprint 2 minggu memberikan gelung maklum balas yang lebih ketat dan membolehkan anda menyusun semula keutamaan tanpa ia terasa seperti pembalikan strategi.

Ujian yang jujur: tanya pasukan anda soalan ini tanpa pemanasan. "Adakah anda lebih suka komited kepada satu pertaruhan besar selama 6 minggu, atau 5 pertaruhan kecil dalam 2 minggu?" Pasukan yang berbeza memberikan jawapan yang berbeza. Kedua-duanya adalah sah. Jawapan yang salah adalah mencampurkan keduanya. Menjalankan sprint 2 minggu dengan kerja berbentuk 6 minggu bermakna setiap sprint terasa seperti kegagalan separa, dan menjalankan kitaran 6 minggu pada kerja reaktif bermakna kitaran itu diganggu oleh insiden pelanggan pada minggu ke-2 setiap kali tanpa gagal.

Pilih satu. Komit selama satu suku tahun. Nilai semula.

Kependaman Tiket-ke-PR: Isyarat Sebenar

Lupakan velocity points. Lupakan "carta burn-down yang sebenarnya carta burn-up kerana kita terus menambah skop." Ada satu nombor yang memberitahu anda sama ada irama penghantaran anda berfungsi: kependaman tiket-ke-PR.

Definisi: masa berlalu dari apabila tiket diberikan kepada seorang jurutera hingga apabila mereka membuka PR pertama untuk tiket itu.

Itu sahaja. Tiada story points. Tiada anggaran. Hanya dua cap masa.

Jika nombor itu adalah 4 hari atau lebih untuk tiket yang anda angggar sebagai tiket 5 hari, perancangan anda rosak. Bukan kerana jurutera itu perlahan. Kerana tiket itu tidak cukup dibentuk untuk dimulakan. Mereka menghabiskan hari 1, 2, dan 3 untuk mengetahui apa yang sebenarnya dimaksudkan oleh tiket itu, apa yang dalam skop, apa yang tidak, dan apa yang perlu dilakukan apabila mereka menemui lorong yang tidak terjangka. Itulah perancangan yang meresap ke dalam pelaksanaan.

Bagaimana keadaan yang baik kelihatan: kependaman tiket-ke-PR median di bawah 24 jam. p75 di bawah 48 jam. p90 di bawah 5 hari. Jika taburan anda mempunyai ekor yang panjang (beberapa tiket duduk pada 10 hari atau lebih), itulah tiket yang memakan sprint anda dan ia adalah yang perlu disiasat.

Bina carta itu sekali, dalam alatan apa sahaja yang anda gunakan. Linear, Jira, dan Shortcut semuanya mendedahkan data ini melalui API mereka. Tarik ia setiap minggu. Perhatikan mediannya. Apabila ia naik, perancangan telah merosot. Apabila ia turun, sesuatu sedang berfungsi.

Corak "Dianggar 3 Hari, Mengambil 11"

Setiap EM pernah melalui ini. Tiket dianggar pada 3 hari. Sebelas hari kemudian, ia masih dalam semakan. Jurutera itu tidak malas. Tiket itu tidak dibentuk.

Ini bukan masalah anggaran. Anggaran yang lebih baik tidak akan membaikinya. Kerja itu adalah samar-samar apabila ia memasuki sprint, dan "samar-samar ditambah saya akan fikirkan sambil berjalan" adalah cara tiket 3 hari menjadi 11 hari.

Pembaikannya adalah sesi pembentukan 30 minit sebelum tiket memasuki sprint. Dijalankan oleh tech lead atau IC kanan. Outputnya adalah dokumen pembentukan pendek yang merangkumi empat perkara:

1. Dalam skop. Tingkah laku atau keupayaan spesifik yang kita bina. Konkrit, bukan abstrak.
2. Bukan dalam skop. Dua atau tiga perkara yang nampaknya berkaitan tetapi kita secara eksplisit tidak melakukan. Ini adalah bahagian yang paling penting. Tanpanya, skop merangkak masuk setiap kali.
3. Lorong yang tidak terjangka. Risiko yang diketahui: "ini mungkin memerlukan menyentuh perkhidmatan pengesahan, dan jika ia berlaku, kita berhenti dan skop semula." Menamakannya lebih awal bermakna jurutera tidak menghilang ke dalamnya selama seminggu.
4. Selera. Masa maksimum yang akan kita habiskan sebelum kita memotong skop atau mengeskalasinya. Bukan anggaran. Satu bajet.

Tiga puluh minit. Satu dokumen. Tiket yang keluar daripada pembentukan adalah 4 hingga 5 kali lebih mungkin untuk dihantar hampir dengan seleranya berbanding yang tidak. Saya telah melihat ini bertahan merentas pasukan 6 orang dan pasukan 60 orang. Kiraan masa pelaburan itu jelas.

Penganggaran Hutang Teknikal: Peraturan 20%

Dua puluh peratus daripada setiap sprint pergi kepada hutang teknikal. Bukan "jika ada masa." Bukan "kita akan lakukannya suku tahun depan." Peruntukan yang komited, dinamakan, dan merupakan item baris.

Jika anda melangkau ini, hutang bertambah. Menjelang suku tahun ketiga kelajuan penyampaian anda adalah separuh daripada apa yang ada, dan tiada siapa yang dapat menjelaskan sebabnya dengan tepat. Ujian yang selalu gagal memerlukan tiga percubaan untuk lulus. Penghijrahan yang sepatutnya sementara 18 bulan lalu. Perkhidmatan yang tiada siapa tahu cara untuk menggunakan kecuali seorang jurutera yang hampir mengambil cuti bersalin.

Dua puluh peratus bukan nombor ajaib. Ia adalah ambang di bawahnya hutang terkumpul lebih cepat daripada yang anda boleh bayar. Sesetengah pasukan memerlukan 30% semasa tempoh penyusul. Sesetengah pasukan boleh berjalan pada 15% jika pangkalan kod mereka benar-benar muda. Di bawah 15%, anda meminjam daripada kelajuan penyampaian suku tahun hadapan anda dan anda akan merasakannya.

Cara memilih hutang mana yang perlu dibayar, mengikut urutan keutamaan:

1. Kesakitan yang menghadap pelanggan. Bug yang pasukan telah bekerja mengelilinginya tetapi pelanggan masih menghadapinya. Isu prestasi yang muncul dalam tiket sokongan. Sentiasa yang pertama.
2. Kesakitan yang menghadap pembangun. Ujian yang lambat, persekitaran pembangunan tempatan yang rosak, ranjau penggunaan. Apa sahaja yang merugikan pasukan sejam seminggu atau lebih.
3. Pembersihan teoritikal. Pemfaktoran semula yang akan terasa baik tetapi tidak mempunyai fungsi pemaksa. Keutamaan terakhir. Bersikap jujur tentang sama ada ini tergolong dalam sprint langsung.

Jadikan 20% kelihatan pada papan. Tandakan tiket dengan "hutang-teknikal." Laporkan peratusannya dalam spike perancangan mingguan anda. Jika sprint jatuh di bawah 20% tiga minggu berturut-turut, itu adalah tanda amaran.

Corak Membuka Halangan: SLA Semakan PR dan Kalendar Keputusan

Dua mekanisme khusus yang menggerakkan jarum lebih daripada sebarang perubahan perancangan:

SLA Semakan PR. Semakan pertama dalam masa 4 jam semasa waktu bekerja. Bukan panduan. Komitmen yang menghalang. Jika PR duduk tanpa disemak selama 4 jam atau lebih, penyemak yang ditugaskan meninggalkan apa yang mereka lakukan dan menyemaknya. Ini kedengaran keras. Ia berfungsi.

Pasukan yang pernah saya lihat mengamalkan ini menghantar 2 hingga 3 kali lebih banyak daripada sebelumnya, dan sebabnya mudah: PR yang duduk dalam semakan selama 2 hingga 3 hari bermakna jurutera beralih konteks kepada sesuatu yang lain, kemudian beralih konteks semula apabila semakan tiba, kemudian beralih konteks sekali lagi untuk menangani maklum balas. Setiap peralihan memakan 30 hingga 60 minit masa produktif sebenar. SLA 4 jam meruntuhkan gelung itu.

Kalimat yang saya akan letak dalam perjanjian bekerja pasukan anda, kata demi kata:

Semakan pertama dalam masa 4 jam semasa waktu bekerja, kecuali apabila seorang jurutera berada dalam blok berfokus yang ditandakan lebih awal. Semakan menghalang kerja lain, termasuk tiket aktif penyemak sendiri. Semakan hanya dengan komen dikira. Jangkaan adalah maklum balas, bukan kelulusan.

Kalendar Keputusan. Satu slot 30 minit setiap minggu di mana EM dan tech lead memutuskan segala-galanya yang sedang menunggu. Keputusan senibina. Pilihan vendor. Keputusan "Adakah kita patut menggunakan pustaka A atau pustaka B?" Mana-mana soalan yang telah duduk dalam urutan Slack selama lebih daripada 48 jam.

Tanpa ini, keputusan berlarutan selama berminggu-minggu. Jurutera bertanya sekali, mendapat "biar saya fikirkan," dan soalan itu mati dalam urutan. Kalendar keputusan membuat komitmen awam: menjelang Jumaat pukul 11 pagi, soalan itu mendapat ya, tidak, atau "kita perlukan 30 minit lagi untuk melihatnya." Tiada lagi gelung "saya akan kembali kepada anda."

Kedua-dua mekanisme bersifat mekanikal. Mereka tidak memerlukan perubahan budaya atau roadshow mendapatkan persetujuan. Anda komit kepada mereka pada Isnin dan mula menjalankannya pada Selasa.

Bila Perlu Mengeskalasinya (dan Apa Sebenarnya Makna "Eskalasi")

Kebanyakan EM menyalahgunakan perkataan "eskalasi." Mereka fikir ia bermakna pergi kepada bos anda apabila sesuatu sedang terbakar. Itu bukan eskalasi. Itu kemas kini status dengan langkah tambahan.

Eskalasi adalah menjadikan keputusan yang tidak kelihatan menjadi kelihatan kepada orang yang tepat.

Tiga pencetus untuk eskalasi sebenar:

1. Skop lebih besar daripada selera. Anda membentuk tiket untuk selera 1 minggu. Jurutera kini memberitahu anda ia adalah masalah 3 minggu. Keputusan (adakah kita masih melakukannya? adakah kita memotong skop? adakah kita mengeluarkannya ke suku tahun depan?) berada di luar pasukan. Eskalasikan.
2. Kebergantungan pada pasukan lain menghalang anda selama 2 hari atau lebih. Anda telah bertanya. Anda telah membuat susulan. Tiada yang bergerak. Eskalasikan kepada EM pasukan lain, dengan permintaan yang spesifik dan tarikh akhir yang spesifik. Bukan "boleh anda bantu kami?" tetapi "kami memerlukan jawapan ya/tidak sama ada pasukan pengesahan boleh mengutamakan ini menjelang penghujung hari Khamis."
3. Keputusan senibina memberi kesan kepada lebih daripada pasukan anda. Anda akan memperkenalkan pangkalan data baharu. Corak pengesahan baharu. Pendekatan penggunaan baharu. Jika radius kesan adalah lebih besar daripada pasukan anda, eskalasikan ke atas supaya keputusan itu dimiliki pada tahap yang betul.

Templat eskalasi 3 baris yang berfungsi dalam Slack atau e-mel:

Keputusan diperlukan: [soalan spesifik, dibingkaikan sebagai ya/tidak atau pilih-satu-pilihan]
Mengapa sekarang: [apa yang dihalang, siapa yang terjejas, apa kos menunggu]
Tarikh akhir: [bila anda perlukan jawapan, dengan tarikh dan masa yang spesifik]

Itulah keseluruhan templat. Tiga baris. Tiada perenggan latar belakang. Jika penerima memerlukan konteks, mereka akan bertanya. Kejelasan itu sendiri adalah yang membuka halangan.

30 Hari Pertama Irama Baharu Ini

Jangan melancarkan semua ini pada hari Isnin. Cara terpantas untuk kehilangan kepercayaan pasukan adalah mengumumkan model operasi baharu dan meminta mereka mengikutinya sebelum mereka melihat mana-mana daripadanya berfungsi.

Pelancaran 30 hari yang bertahan:

Minggu 1: Hapuskan satu mesyuarat berulang. Pilih yang tidak disukai sesiapa. Penghalusan pertengahan sprint, mungkin. Batalkan. Perhatikan apa yang rosak. Biasanya tiada apa. Jika sesuatu rosak, anda telah mempelajari apa yang sebenarnya dilakukan oleh mesyuarat tersebut.

Minggu 2: Lancarkan spike perancangan 1 jam baharu. Jalankan sekali. Hantar nota pendek kepada pasukan yang menerangkan format baharu dan sebabnya. Selesaikan satu jam itu. Berpegang kepada kotak masa.

Minggu 3: Ukur kependaman tiket-ke-PR. Tarik data daripada alatan anda. Buat carta. Jangan kongsikan lagi. Lihat sendiri selama seminggu supaya anda memahami bagaimana taburan anda sebenarnya kelihatan.

Minggu 4: Semak data bersama pasukan dan sesuaikan. Bawa carta itu. Tanya: "Apa yang kita lihat? Apa yang mengejutkan kita? Apakah satu perkara yang akan kita ubah?" Biarkan pasukan menyuarakan pendapat. Sesuaikan irama berdasarkan apa yang mereka katakan.

Menjelang hari ke-30 anda akan menggantikan 6 jam atau lebih perancangan dengan 1 jam, mengukur satu isyarat yang penting, dan memberikan pasukan irama yang boleh mereka pertahankan. Anda juga akan mendapat masa anda kembali. Gunakan ia untuk melakukan kerja yang sebenarnya dibayar oleh EM: membentuk masalah, membuka halangan kepada orang, dan mengembangkan jurutera anda.

Senario petang Jumaat dari awal artikel ini? Dalam 60 hari anda tidak akan mengenalinya. Kalendar anda akan mempunyai satu blok perancangan, satu blok kalendar keputusan, dan banyak ruang kosong. Pasukan anda akan menghantar lebih banyak. Dan IC kanan yang dahulunya menghantar perkara walaupun ada proses anda akan menghantar perkara kerananya.

Ketahui Lebih Lanjut

• Penerangan Tugas Jurutera Perisian Bertaraf Staff
• Menjalankan 1:1 yang Ditunggu-tunggu oleh Kakitangan Bawahan Langsung Anda
• Menetapkan Matlamat untuk Pasukan yang Tidak Mahu