Struktur Burung Cakep: aliran pengembangan

Jika Anda tidak dapat menggambarkan struktur organisasi Anda, departemen, bekerja secara umum dengan jari Anda, itu berarti Anda melakukan ini dengan tidak efisien.

Efisiensi dan transparansi tidak pernah sama. Anda dapat secara transparan melakukan hal-hal yang tidak efektif, dan secara efektif melakukan hal-hal yang tidak jelas.

Membangun struktur kerja adalah proses individu yang kompleks, dengan sentuhan keberanian. Karena kita tidak hanya membutuhkan keberanian dan refleksi (“kita bekerja secara tidak efisien, mengapa?”), Tetapi juga kemampuan untuk membuat tumpukan yang anggun.



Tumpukan yang anggun adalah kunci untuk menciptakan struktur. Tampaknya "kita tidak perlu, kita bekerja dan baik-baik saja, mengapa kita perlu lapisan tambahan", tetapi pada kenyataannya - satu lapisan yang bijaksana akan meningkatkan pekerjaan Anda ke tingkat yang baru. Itu tumpukan, tapi elegan. Sesuatu seperti injeksi ketergantungan atau menggunakan photoshop bukan cat.

Jika sekarang Anda berpikir "tidak, semuanya efektif bersama kami" - jangan berharap. Tidak efektif. Bahkan jika Anda benar-benar, sepenuhnya, tidak pernah terjebak dalam pekerjaan Anda, maka Anda hanya hidup dalam ilusi. Ini tidak mungkin. Efisiensi adalah proses sialan, bukan pemberian. Dan orang tertentu harus menyediakan proses ini. Dan lainnya - untuk mendukung. Bukan karena "mereka berkata begitu", tetapi karena semua orang akan baik-baik saja - semua orang akan bekerja karena mereka merasa nyaman dan efektif.

Singkatnya, kami menyebut gagasan kami tentang tumpukan yang anggun "burung struktur yang kurang ajar" atau "aliran pembangunan". Sekarang kami akan menggambarkannya, dan kami juga akan memakan beberapa anjing Anda dalam perselisihan.

Mengapa itu dibutuhkan?

Alur Pengembangan dirancang untuk memenuhi 4 kewajiban:

• Penataan proses
• Solusi untuk masalah
• Memberikan Umpan Balik
• Menyediakan bahasa interaksi universal

Development Flow adalah alat yang menciptakan sistem .

Sistem

Sistem terdiri dari elemen-elemen, elemen-elemen berbeda, dan "arus" melewati mereka - proses kerja. Di TI, "bicara" adalah kode, desain, dokumen, dan hal-hal lain yang kami kerjakan dan teruskan.

Sistem hilang

Jika Anda tidak tahu pada tahap apa dari Aliran Pribadi Anda, Anda saat ini (misalnya, "mengembangkan fitur"), dan tidak tahu tahap apa Anda berada dalam Aliran Umum (misalnya, yang keempat, setelah Pemilik Produk, Scrum Wizard dan Desainer), dan panggung harus mengejar Anda, apa kriteria pengembaliannya, dan banyak hal kecil lainnya ...

Atau jika Anda tahu, tetapi untuk pekerjaan Anda, Manajer Proyek harus duduk di sebelah Anda dan mengingatkan Anda apa yang sebenarnya harus Anda lakukan saat itu juga (jangan singkirkan diri Anda dari monitor, maka program-program berikut) ...

Atau jika Anda hanya merasa bahwa Anda tidak efektif ...

... maka kemungkinan besar Anda tidak memiliki Sistem.

Sistem tidak beroperasi dengan benar

Tidak semua emas yang berkilau. Tidak semua V12 berada di bawah tenda. Dan yang paling penting - tidak semua mesin bekerja dengan benar, bahkan jika sedang bepergian (halo, industri mobil tercinta).

Penting untuk memiliki sistem yang berfungsi dengan baik, karena itu adalah kepercayaan kami. Dalam karyanya, dalam karya seluruh sistem. Anda akan segera menemukan masalah, yang sebagian besar dapat Anda selesaikan.

Mesin yang berjalan memiliki suara. Dia berirama, menyenangkan. Jika ada masalah, itu didengar oleh telinga sensitif tuannya. Berderit, bersin, gangguan irama, mengetuk. Ini menghancurkan mesin secara perlahan atau cepat, dan "mesin bisnis" rusak tepat ketika Anda mengambil hipotek dolar pada uang kertas tiga rubel di dalam ring.

Dalam sistem kerja orang-orang, suara-suara ini - pelanggaran tenggat waktu, ketidakpuasan, pengurasan personel, nada rendah karyawan, melempar masalah ke departemen berikutnya - dan banyak lagi. Seorang manajer yang baik berjalan di sekitar kantor dengan pelacak lokasi super sensitif dan bukannya telinga. Dia tahu badai yang akan datang, dia merasa bahwa tekanan telah turun. Dia mendengar desahan pendek, dan memperhatikan matanya yang tertarik. Dia adalah Sistem.

Alur pengembangan: sistem

Sistem DF menyiratkan dua bagian - Aliran Umum (berfungsinya sistem secara keseluruhan), dan Aliran Pribadi (berfungsinya masing-masing bagian).

Aliran total

Sistem terdiri dari elemen-elemen yang digabungkan dalam struktur untuk mencapai tujuan yang dimaksud.
Tujuan TI adalah untuk merilis produk pada waktu yang tepat, kualitas yang tepat. Elemen sistem - peserta dalam proses: Pemilik Produk, Manajer Proyek, Master Scrum, Pengembang, Desainer, Penguji, Penulis Teknis ... Ini semua adalah elemen, dan tidak semuanya hadir sepanjang waktu. Terkadang peran digabungkan. Anda perlu menyorot elemen Anda.

Anda perlu menyorot elemen Anda. Tuliskan dan gambarkan panah aliran pertama Anda. Ini disebut Common Flow.

Pemilik → SM → Desainer, Pengembang → Penguji → Penulis teknologi

Tugasnya adalah untuk menggabungkan elemen-elemen ke dalam struktur dan menunjukkan interaksi profesional apa yang mungkin. Tidak profesional - bahwa perancang dan pemilik produk hidup bersama, tidak perlu. Itu hanya peran yang diperlukan. Pemilik tidak boleh berinteraksi dengan Desainer atau Pengembang. Hanya master Scrum. Hanya Master scrum.

Saat kami menyoroti interaksi, panah-panah ini, kami harus menunjukkan apa yang pertama berikan, dan yang kedua mengembalikannya sebagai umpan balik. Jadi sistem mulai hidup.

Pemilik → memberikan deskripsi tugas → SM

SM akan memformulasikan ulang baik untuk Pemilik maupun untuk sisanya. Penilaian tugas - perkiraan - akan berbaris sendiri. Tapi tugas SM - dari deskripsi sederhana, menerapkan tumpukan anggun, untuk membuat SUFFICIENT_DESCRIPTION. Dia akan mendiskusikan dan mendistribusikan bagian-bagian ini SEBELUM bersama tim.

SM → memberikan bagian UNTUK → Desainer dan Pengembang

DO termasuk skema, semua kemungkinan statusnya, dan banyak lagi (saya belum mau menumpuk). Semua orang mendapat bagian mereka. Tidak selalu pada saat bersamaan. Biasanya, Perancang unggul satu langkah di depan Pengembang.

Desainer dan Pengembang pada rapat umum harian ketika umpan balik dari SM mengembalikan kepadanya visinya tentang tugas. Kami memastikan bahwa kami memahami semuanya dengan cara yang sama. Dibutuhkan 25-28 detik. Dan menghemat berjam-jam.

Pengembang → setelah aliran pribadinya (lebih lanjut tentang itu nanti), meneruskan kode → ke Penguji

Pengembang memberikan kode, tester melihat bagian TO, dan memenuhi alurnya. Umpan Balik Penguji adalah untuk SM → “positif”, yaitu, bagaimana ia memahami tugas tersebut, dan untuk Pengembang → “negatif” - hanya jika rusak.

Pengembang tidak tahu bahwa kodenya diuji hingga ada masalah.

Saya pikir General Flow dirumuskan dengan benar sebagai berikut. Yang pertama memberi kepada yang kedua, proses kedua, mengembalikan umpan balik "positif" atau "negatif", bergerak lebih jauh dalam aliran Umum. Umpan balik positif adalah keyakinan bahwa semuanya berfungsi sebagaimana mestinya; umpan balik negatif - menunjukkan di mana dan apa yang salah.

Aliran pribadi

Dalam artikel ini, saya akan menguraikan aliran pribadi dari Pemilik, CM dan Pengembang, sebagai contoh. Jika Anda tertarik, maka saya akan memposting sisa pekerjaan.

Pemilik

Tujuan utama
Pernyataan masalah (backlog ← description), baca umpan baliknya

Apa selanjutnya
Ketika tugas dirumuskan oleh Pemilik, SM menjelaskannya → mengarah ke Sufficient_Description.

Umpan balik dari
SM menulis ulang tugas dan membahas tonggak penting dengan Pemilik dengan cepat, termasuk kerangka waktu.

Berinteraksi dengan
SM

SM

Tujuan utama
Terima tugas, bawa ke dalam bentuk Adequate_Description, evaluasi tugas, distribusikan, baca umpan balik

Apa selanjutnya
Mendistribusikan tugas kepada karyawan

Umpan balik dari
Desainer, Pengembang, Penguji, Tek Penulis

Berinteraksi dengan
Pemilik, Perancang, Pengembang, Penguji, penulis teknologi

Pengembang

Tujuan utama
Pengembangan fitur dan perbaikan bug. Dalam General Flow, ia menerima tugas dari SM, dan dengan bantuan aktivitas profesionalnya, ia mengimplementasikannya (aliran git, aliran rebase, aliran fitur, dll.).

Apa selanjutnya
Dia dapat membuat saran untuk modifikasi, mendiskusikannya dengan SM dan Desainer.

Umpan balik dari
CM, Desainer, Penguji

Berinteraksi dengan
SM, oleh Perancang, (penting - ia tidak dapat menghasilkan interaksi dengan Penguji)

(Dalam uraian ini, saya tidak terlalu menyukai skema ini , ini adalah presentasi saya dengan uraian yang berbeda, dan saya lebih senang bekerja dengannya. Tapi saya mengeksplorasi opsi, mencoba, mengasah, dan ternyata seperti ini.)

Dalam residu kering

Alur Pengembangan memecahkan masalah berikut:

• Penataan proses
• Memecahkan Masalah
• Memberikan umpan balik
• Memberikan bahasa universal yang belum kami ucapkan sepatah kata pun

Keuntungan utama - semua orang tahu apa yang sedang terjadi, apa yang harus dilakukan, dan tidak sarat dengan pekerjaan yang tidak perlu.

Scrum Masters memiliki banyak pekerjaan (Timlid, CTO). Tetapi seharusnya begitu, dia adalah traktor utama dalam pendekatan ini.

presentasi sangat singkat dan kering

Tetap dalam gelap atau buat struktur yang berani. Kami menawarkan burung kami, tetapi burung itu besar dan ini hanya sebagian, pada perkiraan pertama. Kami membutuhkan lebih dari kasus apa pun. Karena itu, saya bertanya kepada Anda - gantung semua anjing pada saya, saya ingin memecahkan topik yang lebih baik.

(Saya harus memotong banyak untuk mempersempit ukuran artikel setidaknya sedikit. Karena ini, saya bisa kehilangan sesuatu, tetapi saya akan segera memperbaikinya, menulis.)