Bagaimana seharusnya standar dan proses perbaikan diperkenalkan ke organisasi tanpa mereka?

10

Saya telah ditugaskan untuk meningkatkan proses pengembangan perangkat lunak melalui penerapan peningkatan proses, yang kemungkinan besar akan menggunakan CMMI untuk Pengembangan, Versi 1.3 sebagai pedoman dan mengadopsi praktik terbaik secara keseluruhan atau sebagian. Apa cara terbaik untuk memperkenalkan standar dan perbaikan proses sehingga tingkat dorongan balik dan penolakan dari pengembang diminimalkan?

standards cmmi process-improvement

— rjzii
sumber

Hanya ingin tahu, apakah Anda sudah memiliki ide mengapa lebih banyak bug melewati yang diinginkan?

— Chris Pitman

2

@ S.Lott Bisakah Anda membuat kasus agar bug tidak berkurang (di sisi konsumen) tanpa standar? Pengalaman saya suatu proses dan standar sangat mengurangi apa yang dilihat konsumen pada bug ... bukan karena mereka tidak ada, mereka tidak pernah dilihat oleh pelanggan.

— Rig

@ Robz: Saya tidak bertanya apa yang Anda miliki saat ini. Saya masih mencoba memahami pertanyaan itu. "menerapkan peningkatan proses" tampaknya merupakan deskripsi paling akurat tentang apa yang Anda tanyakan. Saya menyarankan bahwa "standar" adalah istilah yang membingungkan, karena memiliki definisi formal dan Anda tidak menggunakan definisi formal itu.

— S.Lott

@Robz: "Standar Pengkodean" bukan "Standar Formal". Itu akan mengklarifikasi pertanyaan. Lagi. "Standar Formal" adalah standar W3C, Posix, ISO, IEEE, ANSI. Draft dan disetujui oleh organisasi penetapan stand yang diakui. Jika Anda berbicara tentang standar pengkodean, harap perbarui pertanyaan untuk menghapus kata "Formal" dan gunakan kata "Coding". Dengan perubahan itu, pertanyaan Anda masuk akal. Dan merupakan duplikat.

— S.Lott

"Sehubungan dengan kata-kata" standar "dalam judul bersamaan dengan proses perbaikan, kata standar tidak hanya berlaku untuk kode yang ditulis seseorang"? Apa? Ini sebuah petunjuk. Tolong jangan gunakan kata "standar" tanpa semacam kualifikasi; ini membingungkan. Jika Anda bermaksud "standar pengkodean", harap gunakan frasa itu. Jika Anda memaksudkan "standar" lainnya, harap memenuhi syarat kata "standar" dengan frasa kualifikasi untuk memperjelas apa yang Anda bicarakan. "standar" tidak jelas dan membingungkan.

— S.Lott

2

Mulai proyek peningkatan proses perangkat lunak (SPI) . Tentukan ruang lingkup dan tujuannya. Pasti akan membantu jika standardisasi memiliki tujuan dan ukuran sendiri yang berlaku untuk organisasi Anda.
Tetapkan orang yang bertanggung jawab untuk mengadopsi standar . Mungkin juga beberapa orang atau bahkan departemen dalam kasus organisasi besar. Yang penting semua penanggung jawab standardisasi adalah:
- cukup profesional untuk melihat seluruh gambar
- cukup berpengaruh untuk berurusan dengan tim dan membantu mereka untuk mengadopsi / menegosiasikan perubahan
Kembangkan pelatihan yang mencakup standar yang ingin Anda adopsi dan spesifik yang diterapkan untuk organisasi Anda. Dan ini sangat penting selama semua orang yang tidak terlatih berpotensi tahan terhadap perubahan. Misalnya, ketika saya bekerja di sebuah perusahaan besar, saya menginstruksikan semua karyawan pendatang baru tentang proses QA, CMMI, ISO dan Sistem Manajemen Kualitas. Pelatihan semacam itu wajib. Ini membantu meningkatkan pengetahuan tentang proses manajemen kualitas dan meningkatkan kesadaran karyawan mengenai masalah penting kualitas perangkat lunak.
Negosiasikan perubahan dan sesuaikan praktik yang diterima secara umum untuk kebutuhan spesifik Anda. Ini akan membantu menghindari birokrasi dan implementasi proses-proses berat yang tidak perlu dilakukan oleh siapa pun.
Menetapkan pemantauan tentang bagaimana perbaikan proses yang diterapkan didukung dan apakah mereka cukup efektif dalam organisasi Anda.

Ini juga akan membantu jika Anda akan menemukan semua orang di dalam organisasi Anda yang benar-benar peduli dengan kualitas. Kemungkinan besar, itu akan menjadi sumber daya terpenting yang membantu Anda mempromosikan perubahan dan membangun praktik yang matang.

— alternatif
sumber

6

Beberapa pemikiran dari sekolah pukulan keras:

1) Sebagian besar inisiatif peningkatan proses menghabiskan 80% waktunya untuk desain proses dan 20% untuk pendidikan dan sosialisasi. Balikkan persentase ini. Standar biasa-biasa saja yang diikuti mengalahkan yang sempurna yang tidak.

2) Identifikasi alasan yang jelas mengapa Anda meminta orang untuk mengubah cara kerjanya. Apa masalahnya bisnis? Idealnya itu menguntungkan setiap tim secara individual. Terkadang itu hanya perbaikan sistemik. Either way, buat kasing terlihat.

3) Sederhanakan, kemudian distandarisasi, bukan sebaliknya.

4) Anda tidak dapat sepenuhnya mendelegasikan ini ke PMO. Manajer langsung harus dibeli, dan kepala unit bisnis harus memutuskan ikatan ketika keluhan masuk.

5) Temukan pengadopsi awal yang ramah. Orang-orang akan mengeluh tentang berapa banyak waktu yang dibutuhkan. Anda membutuhkan seseorang yang bisa Anda tunjuk dan berkata, "hanya butuh 15 menit"

6) Untuk metrik, dorong keras untuk kuantitatif daripada kualitatif. Kalau tidak, Anda memiliki proyek yang Hijau sampai sehari sebelum Go Live, ketika semuanya tergelincir sebulan.

7) Tekankan teknik pada alat. Perencanaan yang baik lebih penting daripada Proyek MS.

8) Masukkan tingkat proses relatif terhadap kebutuhan. Setiap restoran membutuhkan proses, tetapi Nobu dan Binatu Prancis membutuhkan jenis yang berbeda dari McDonalds. Sama dengan perusahaan perangkat lunak.

Semoga berhasil!

— MathAttack
sumber

1

Jawaban yang bagus - Saya juga akan menambahkan dengan sangat hati-hati dengan proses yang Anda perkenalkan - Pastikan Anda tidak terjebak dalam melakukan apa yang terbaik untuk proses itu, bukan apa yang terbaik bagi pelanggan - yaitu prosesnya harus berfokus pada pelanggan. Juga, berhati-hatilah dengan apa yang Anda ukur - dengan definisi apa ukuran itu penting dan apa yang tidak diukur tidak penting. Ukur hal-hal yang salah (SLOC / Day, Bugs / SLOC dll) dan Anda tidak akan mendapatkan peningkatan, tetapi pengukuran akan memberi tahu Anda apa adanya.

— mattnz

1

@ mattnz - Saya tidak tahu, error / SLOC dapat menjadi metrik yang berguna jika Anda menerapkannya dengan benar. Jika seseorang mengatakan bahwa mereka rata-rata 1 kesalahan / 10 SLOC saya akan khawatir. Triknya adalah Anda harus tahu di mana bar-bar itu berada, yang bisa sulit.

— rjzii

Poin yang bagus. Orang mengoptimalkan ke metrik mereka. Jika Anda menghasilkan metrik keuangan terlebih dahulu, orang akan mengoptimalkannya dengan mengorbankan fungsionalitas atau layanan pelanggan. Ini semua tentang keseimbangan dan prioritas.

— MathAttack

1

Ukur saya dengan kesalahan / SLOC, SLOC / hari, dan Anda akan terkejut betapa verbose saya dapat membuat kode sumber saya tanpa menambahkan sesuatu yang bermanfaat. Misalnya penempatan kawat gigi, pada baris baru, selalu - semakin banyak baris semakin sedikit stat, semakin baik saya menjadi programmer, secara instan. Berikan saya ukuran APA SAJA, dan saya akan menunjukkan kepada Anda bagaimana saya bisa membuat pengukuran itu membuat saya terlihat lebih baik.

— mattnz

1

@ mattnz - Itulah tujuan dari tinjauan kode, jika seseorang membuat kode mereka secara tidak perlu untuk menyembunyikan fakta bahwa kode itu penuh dengan bug maka kemungkinan besar mereka seharusnya tidak menulis kode untuk memulai. Anda juga dapat melihat cacat per titik fungsi yang sangat sulit dipalsukan karena Anda juga melihat eksposisi dalam jumlah fungsi dengan angka turun (pertanda buruk), atau jumlahnya mulai turun saat kode menjadi lebih baik (baik tanda).

— rjzii

2

Mendasarkan upaya Anda pada CMMI mungkin merupakan ide yang baik, bahkan jika Anda tidak menjalani penilaian dan mendapatkan diaudit dan dinilai secara formal. Ada banyak literatur yang tersedia tentang CMMI , CMMI dan teknik peningkatan proses lainnya seperti Lean dan Six Sigma , dan CMMI dan pengembangan perangkat lunak tangkas . The SEI memiliki seluruh koleksi sumber daya , beberapa tersedia secara gratis, tentang berbagai aspek CMMI dan bimbingan untuk berbagai jenis organisasi.

Saya akan merekomendasikan untuk melihat secara mendalam pada pendekatan berkelanjutan untuk mengimplementasikan CMMI, daripada pendekatan bertahap. Bagi saya, ini merupakan cara yang jauh lebih efisien untuk menentukan dengan tepat di mana posisi organisasi Anda sekarang dan meningkatkan area yang menambah nilai bisnis paling banyak. Ini akan memungkinkan Anda untuk tidak hanya menyelaraskan upaya peningkatan Anda dengan tujuan bisnis, tetapi dengan cepat mencapai tonggak kemajuan dan menunjukkan efek peningkatan, meningkatkan penerimaan dari semua tingkatan.

Sesuatu yang perlu diingat, bagaimanapun, adalah bahwa perbaikan proses umumnya lebih berhasil ketika itu merupakan upaya akar rumput. Ketika perubahan proses ditentukan dari atas - oleh orang-orang, pengembang "di parit" mungkin melihat tidak tersentuh dengan bagaimana hal-hal dilakukan dalam parit - mungkin akan ada pushback, bahkan jika idenya bagus. Bersiaplah untuk ini.

Beberapa jenis kelompok proses rekayasa mungkin juga bermanfaat. Menyatukan perwakilan dari berbagai komponen dan tim organisasi yang dipengaruhi oleh peningkatan sehingga suara semua orang didengar. Ini akan mencakup tidak hanya perwakilan dari setiap peran, tetapi mungkin berbagai tim pengembangan produk. Tanpa mengetahui bagaimana struktur organisasi Anda, saya tidak bisa mengatakan dengan tepat siapa yang ingin Anda lihat, tetapi sertakan orang-orang dari setiap level organisasi dalam grup. Juga, buat diskusi dan keputusan yang dibuat oleh kelompok ini tersedia untuk organisasi untuk komentar dan mengemukakan masalah.

— Thomas Owens
sumber

Tidak yakin seberapa baik upaya mendorong upaya akar rumput akan berhasil karena sangat sedikit tim proyek yang memformalkan proses apa pun yang mengapa ini akan menjadi proses yang lebih top-down. Meskipun demikian, semua orang khawatir tentang membuat hal-hal selembut mungkin untuk mencegah upaya gagal karena kurangnya implementasi yang sebenarnya.

— rjzii

@RobZ Secara definisi, Anda tidak dapat mendorong upaya akar rumput - harus secara alami datang dari bawah ke atas. Kecuali jika tim proyek menyadari bahwa ada masalah nyata, kecenderungannya adalah untuk tidak berubah dan menentang perubahan yang dianggap buruk dalam beberapa hal (seperti membuat pekerjaan menjadi lebih rumit atau sulit, yang sering dikaitkan dengan peningkatan proses, meskipun tidak sering demikian).

— Thomas Owens

Tepat dan itulah sebabnya manajemen memformalkan sesuatu. Ada beberapa masalah dengan beberapa perangkat lunak yang telah keluar dari pintu dan mereka juga ingin mengubah budaya perusahaan dan memastikan bahwa produk yang buruk tidak berhasil masuk ke lapangan lagi.

— rjzii

@RobZ Dan ketika manajemen masuk dan menentukan tindakan, pengembang menolak. Anda tidak dapat mengamanatkan perubahan budaya dan berharap itu terjadi secara sederhana dan diam-diam. Ini proses yang panjang dan menyakitkan.

— Thomas Owens

Tidak ada yang benar-benar mengharapkan hal itu terjadi dan kami telah menghadapi perlawanan, pada titik ini kami sedang mencari cara untuk menguranginya.

— rjzii

0

Untuk setiap perubahan:

Sebut 1 perubahan dan bagaimana hal itu akan meningkatkan pembangunan.
Terapkan perubahan.
Tunjukkan peningkatan
Hapus perubahan yang tidak menunjukkan peningkatan

Jelas analisis perlu terjadi seiring waktu, tetapi tidak ada perubahan yang harus diterima sampai terbukti efektif. Itu juga mengapa saya akan menerapkan tidak lebih dari 2-3 perubahan per siklus jika tidak, Anda sering tidak dapat mengukur apakah ada peningkatan atau tidak.

Tidak ada yang menjengkelkan saya lebih dari mengikuti praktik terbaik secara membabi buta tanpa melakukan analisis untuk menunjukkan bahwa sebenarnya adalah praktik terbaik untuk lingkungan Anda. Sebuah praktek terbaik yang tidak menunjukkan perbaikan adalah di boros terbaik dan paling buruk merusak.

Semua langkah dalam proses Anda dan semua praktik dalam metodologi harus dianalisis dan terbukti bermanfaat. Jika tidak maka harus dihapus. Analisis ini harus dilakukan secara berkelanjutan terlepas dari menambah atau menghapus langkah atau praktik.

— dietbuddha
sumber