SAFe atau Scaled Agile Framework

Apa itu SAFe?

Apa itu Agile, banyak yang tahu. Semakin banyak orang yang terlibat dalam terminologi penggunaan TI. Lebih banyak untuk mendengar tentang Agile.

Tidak semua orang yang dengan percaya diri menggunakan istilah Agile untuk komunikasi, kritik, untuk itu; Untuk menyajikan tim atau perusahaan mereka dengan lebih baik, mereka memahami, misalnya, apa perbedaan antara SCRUM dan Agile; dan sering memberi tanda yang sama antara dua konsep yang berbeda ini. Tapi belum lama ini, pada 2015, SAFe juga muncul. Apa itu dan mengapa itu dibutuhkan?

Salah satu kelebihan dan kekurangan penting dari SCRUM, saya menganggap ukuran perintah yang ditentukan adalah 7 + -2 (atau 3-9 data terkini dari Panduan Scrum ) termasuk Pemilik Produk.
Tentu saja, 9 profesional kelas atas dan bermotivasi baik mampu melakukan banyak hal, tetapi kadang-kadang diperlukan untuk membangun sesuatu dengan sejumlah besar tangan, kepala, mata, dan otak pada akhirnya. Mengembang tim adalah buruk, sehingga jumlah mereka perlu ditingkatkan, dan di sini muncul masalah komunikasi antara tim, sinkronisasi pekerjaan dan SCRUM sendiri tidak menawarkan solusi apa pun untuk tugas-tugas ini. Ada upaya untuk menggunakan SCRUM di tingkat manajemen perintah SCRUM (seperti Jeff Sutherland, salah satu penulis Agile manifesto menyarankan,), ada Scrum Skala Besar, ada Pengiriman Agile Disiplin, ada lebih banyak, tetapi ada juga SAFe - Scaled Agile Framework.

SAFe adalah kerangka kerja manajemen perusahaan yang membutuhkan koordinasi pekerjaan pada beberapa proyek atau proyek terkait untuk 5 tim SCRUM atau lebih. Yaitu ini adalah suprastruktur di atas SCRUM yang memungkinkan Anda mengelola tim yang terdiri dari 100 orang atau lebih

Manfaat?

Pertama-tama, tentu saja, metodologi dibutuhkan oleh mereka yang menjualnya dan terlibat dalam pelatihan. Dave Thomas (salah satu penulis Agile manifesto) berbicara cukup baik tentang hal ini Di GOTO 2015 dalam presentasinya Agile is Dead

Kedua, departemen manajemen program. Mereka yang sebelumnya terlibat dalam manajemen proyek menerima sertifikasi PMP, menggambar grafik Gantt dan menerapkan konsep manajemen hard-soft (sisi lunak untuk kepemimpinan dan sulit untuk para pelaksana). Faktanya adalah bahwa dalam SCRUM tipikal tidak ada fungsi untuk mereka, dalam SAFe begitu. Hal yang sama berlaku untuk semua jenis arsitek. Di SCRUM tidak ada fungsi untuk mereka di SAFe - ada jalur karier.

Lebih lanjut, ini dapat bermanfaat bagi para pemilik bisnis di mana para manajer bekerja pada proyek-proyek besar yang menghabiskan banyak waktu dan tidak dapat (kadang-kadang karena alasan obyektif) membuat proyek-proyek ini mandiri.

Banyak pengembang dengan kualifikasi lebih rendah dari rata-rata sering untuk melakukan sesuatu, mereka harus secara eksponensial lebih dari para profesional yang paling berpengalaman dan termotivasi.

Seluruh industri. Karena jumlah pengembang berlipat ganda setiap 5 tahun (lihat masa depan pemrograman paman bob ), yang menghasilkan fakta bahwa pada waktu tertentu setidaknya setengah dari pengembang memiliki kurang dari 5 tahun pengalaman kerja. Jika tren tidak berubah, tetapi tampaknya tidak berubah, maka diperlukan proses yang memformalkan dan memformalkan fungsi kerja mereka, mekanisme interaksi antara peserta dan proses pada umumnya.

Esensi

SAFe adalah kue lapis dari berbagai teknik Agile. Di tingkat bawah adalah SCRUM yang hampir tradisional, dengan sprint dua hingga tiga minggu, tim yang terdiri dari 3-9 orang termasuk Pemilik Produk. Semua ritual khas, mulai dari perencanaan sehari-hari - standup dan diakhiri dengan tanya jawab secara restrospektif. Meskipun ada satu perbedaan utama. Perintah tidak lagi menjadi modul independen yang berfungsi penuh. Dan sprint berhenti menjadi periode waktu yang independen dengan siklus hidup penuh. Sprint digabungkan ke dalam Penambahan Program yang biasanya terdiri dari 5 sprint. Yaitu jika dalam SCRUM klasik kami tidak membangun apa yang disukai klien, maka kami membuat koreksi kursus di sprint berikutnya, kemudian di SAFe kami terus melangkah maju hingga akhir Peningkatan Program, dalam kasus terburuk, 4 sprint berikutnya (tentu saja saya akan melebih-lebihkan).

Di tingkat selanjutnya, kami memiliki kereta - yang disebut Agile Release Train. Ada fungsi-fungsi baru untuk mengelola 5 segmen sprint: arsitek sistem (yang memiliki arsitektur - yaitu, bukan lagi tim), manajer produk (yang mengendalikan produk, bukan Pemilik Produk, yang terakhir pergi ke PM untuk meminta nasihat) dan RTE - PMP yang sama dari dunia air terjun yang jauh. Di sini, beberapa perkembangan dari Kanban diterapkan, khususnya, papan, metode untuk menetapkan prioritas dan, secara keseluruhan, prinsip pengukuran kinerja historis tim (kecepatan) dan memproyeksikan apa yang akan dibangun pada akhir interval waktu sebagai lawan dari pendekatan dengan perkiraan dan menetapkan tenggat waktu untuk fungsional yang sudah ditetapkan ( ruang lingkup). Salah satu inovasi adalah bahwa sprint terakhir dari 5 dinyatakan sebagai organisasi dan di mana pertemuan besar diadakan (semua tim bersama-sama - dan ini adalah 100 atau lebih orang), analisis utang teknis dilakukan, rencana pengembangan arsitektur dibuat dan pekerjaan semua tim disinkronkan.

Di atas level kereta, kami memiliki koordinasi antara departemen, direktur, dan klien. Ada lebih banyak pinjaman dari Lean Agile, tetapi alat yang sama dari Kanban dipertahankan. Ini adalah analisis kelayakan ekonomi dari perubahan. Idealnya, setiap perubahan dilakukan melalui analisis pendahuluan di mana hipotesis terukur tentang perubahan yang akan datang diajukan (misalnya, jika kita membuat toko online dari pusat data ke cloud, maka dengan cepat meningkatkan kapasitas di puncak penjualan musiman kita dapat meningkatkan jumlah transaksi sebesar 10%) dan kemudian hipotesis ini dikonfirmasi baik tidak Untuk perusahaan kurang dari satu miliar dolar - ini mungkin lantai paling akhir. Rencana kerja selama 12-36 bulan dibuat di sini (hi, rencana lima tahun untuk kualitas, kuantitas, dll.)

Di atas level sistem besar adalah manajemen portofolio. Dana dialokasikan ke berbagai bidang bisnis. Manajemen portofolio ramping digunakan, dengan menggunakan strategi pengembangan perusahaan, bidang-bidang di mana Anda dapat memperoleh pengembalian dipilih. Di sini keputusan dibuat tentang membeli atau bergabung dengan perusahaan lain. Penciptaan lini bisnis baru, penutupan yang lama. Anggaran secara teratur disesuaikan dan dipindahkan (tidak seperti rencana triwulanan atau tahunan). Untuk setiap komponen portofolio, serangkaian metrik terstandarisasi dibuat dan kemudian semua dievaluasi sesuai dengan mereka. Seperti halnya pada 3 level sebelumnya, ada ritual khusus untuk sinkronisasi setiap dua minggu (biasanya) - ada pertukaran status dan indikator utama.

Dipimpin oleh seluruh strategi. Cara itu didefinisikan tidak dijelaskan oleh kerangka kerja.

Pro

1. Sejumlah besar alat yang sangat bagus (WSJF, Kanban, Gemba, dll)
2. Memformalkan dan meresepkan langkah-langkah untuk SDLC dari menulis kode (ditentukan oleh TDD) untuk melakukan pemindaian statis dan CI / CD dan beralih fitur. Apakah masing-masing praktik itu baik atau tidak adalah pertanyaan lain, tetapi setidaknya ada rencana dan semua orang mengikutinya.
3. Prosesnya dapat dipahami, dijelaskan dan diimplementasikan.
4. Setiap orang dalam kerangka proses ini menerima fungsi yang didefinisikan dengan cukup ketat.
5. Meningkatkan transparansi perusahaan bagi mereka yang bekerja di dalamnya.

Kekurangan

1. Waktu yang cukup lama untuk merespons ketidaksesuaian realitas dengan harapan
2. Sejumlah besar uang dan uang dihabiskan untuk komunikasi dan rapat
3. Solusi yang sering direkomendasikan dalam kerangka kerja sudah usang

Untuk memperkenalkan atau tidak? Saya percaya bahwa jika ada pilihan, maka tidak ada, lebih baik untuk mengurangi ketergantungan antara departemen dan proyek. Dan jika tidak ada pilihan dan Anda perlu mengelola proyek besar, maka sangat mungkin.