Haruskah pengembang (junior) mencoba mendorong proses dan praktik yang lebih baik dalam tim pengembangan / TI mereka?

Saya adalah pengembang junior yang diberi kemampuan untuk membantu membentuk proses tim saya jika saya dapat membenarkan perubahan, dan jika itu membantu tim menyelesaikan pekerjaan. Ini baru bagi saya karena perusahaan saya di masa lalu kurang lebih memiliki proses yang didefinisikan secara kaku yang berasal dari manajemen.

Tim saya cukup kecil dan agak baru (<3 tahun). Mereka kekurangan:

• kerangka kerja pengembangan perangkat lunak / manajemen kerja yang didefinisikan dengan baik (seperti scrum)
• kepemilikan produk yang kuat
• peran yang terdefinisi dengan baik (misalnya staf bisnis akan melakukan pengujian manual)
• pertemuan standup reguler
• proses pelacakan masalah terkonsolidasi (kami memiliki alat, proses ini masih dikembangkan)
• sebuah unit, sistem, regresi, atau rangkaian atau daftar pengujian manual
• dokumentasi tentang logika dan proses bisnis
• basis pengetahuan untuk mendokumentasikan kiat-kiat internal dan yang dihadapi pelanggan

Dan daftarnya berlanjut. Manajemen terbuka untuk implementasi perbaikan selama nilainya dapat dibenarkan dan membantu pekerjaan yang paling penting (yaitu pengembangan) dilakukan. Asumsi yang mendasari adalah bahwa Anda harus mengambil kepemilikan dalam implementasi, karena tidak ada yang akan melakukannya untuk Anda. Dan tak perlu dikatakan beberapa proyek di atas adalah non-sepele, tanpa diragukan lagi memakan waktu, dan jelas bukan pekerjaan pembangunan.

Apakah layak upaya pengembang (junior) untuk mencoba dan mendorong hal di atas seiring berjalannya waktu? Atau apakah yang terbaik untuk "tetap di jalur Anda" dan fokus pada pengembangan, dan meninggalkan sebagian besar definisi proses, dan optimalisasi ke manajemen?

Jawaban yang bagus sejauh ini, tetapi mereka tidak mencakup semua pangkalan.

Dalam pengalaman saya, banyak orang yang baru lulus dari perguruan tinggi memiliki pengetahuan teoretis yang luar biasa - jauh lebih baik daripada saya atau banyak senior lainnya dengan puluhan tahun membangun perangkat lunak untuk mencari nafkah.

NAMUN, dan itu NAMUN besar, pengetahuan itu tidak didasarkan pada skenario praktis apa pun. Di dunia nyata, banyak teori yang gagal, atau paling tidak harus diambil dengan sebutir garam besar seperti yang ditemukan dalam praktik untuk tidak bekerja dengan baik dalam skenario dunia nyata.

Contoh kasus: Aplikasi yang saya kerjakan sejak lama dirancang oleh ahli teori OO yang brilian, dirancang untuk mengikuti prinsip dan teori OO ke T, dengan banyak pola yang diterapkan di mana-mana.

Itu adalah desain perangkat lunak yang fantastis.

Sayangnya, ini menghasilkan mimpi buruk produksi dan pemeliharaan. Basis kode begitu besar dan kompleks sehingga tempat tidak mungkin diubah; Bukan karena sangat rapuh tetapi karena sangat kompleks, tidak ada yang berani menyentuhnya karena takut akan apa yang akan terjadi (arsitek / desainer asli telah menjadi kontraktor yang sudah lama meninggalkannya).

Ini juga berkinerja sangat buruk, justru karena struktur pola yang berlapis-lapis, dan perpustakaan kelas yang diperlukan desain. Misalnya, mengklik tombol pada layar untuk melakukan satu panggilan ke database akan menghasilkan beberapa ratus instance objek dan pemanggilan metode - semuanya atas nama memastikan sambungan longgar dan hal-hal seperti itu.

Arsitek ini adalah seorang profesor universitas dengan beberapa buku tentang topik dengan namanya. Dia tidak pernah bekerja sehari sebagai programmer pada proyek komersial.

Orang-orang dengan pengalaman praktis membangun perangkat lunak akan menyadari betapa monstrositas yang desain pasti akan mengarah pada dan mengambil pendekatan yang lebih pragmatis, yang mengarah ke sistem yang lebih mudah untuk mempertahankan dan berkinerja lebih baik juga.

Hal yang sama dapat diterapkan pada banyak hal lain yang Anda temui sebagai lulusan baru, atau memang karyawan baru di perusahaan mana pun. Jangan berasumsi bahwa karena dasar teoretis Anda memberi tahu Anda ada sesuatu yang salah atau kurang optimal sehingga tidak ada alasan yang sangat baik untuk melakukan hal itu.

Bahkan sekarang, dengan pengalaman lebih dari 20 tahun di bidang ini, saya khawatir mengkritik cara kerja perusahaan-perusahaan tempat saya bekerja. Saya akan menyebutkan secara sepintas bahwa saya perhatikan hal-hal berbeda dari pengalaman saya menjadi yang paling optimal, tetapi tidak dengan cara yang agresif. Ini sering mengarah pada percakapan yang menarik tentang mengapa hal-hal itu sebagaimana adanya. Mungkin perubahan akan terjadi dan mungkin tidak, tergantung pada apakah nilai mengubah sesuatu lebih kecil dari biayanya.

Jangan takut untuk menyarankan hal-hal yang dapat dilakukan lebih baik, tetapi selalu pastikan bahwa Anda tidak tampil sebagai anak ingusan yang tahu segalanya, tetapi sebagai rekan kerja yang berusaha dan mau tidak hanya belajar tetapi juga membantu meningkatkan proses untuk perbaikan perusahaan, bukan hanya kebenaran teoretis.

Ya tapi dengan banyak perawatan!

Biarkan saya mengklarifikasi itu.

Anda harus berusaha untuk meningkatkan kelayakhunian perangkat lunak. Jika Anda melihat kode / tim / bisnis / proyek / manajemen dan respons pertama Anda adalah mandi, maka itu tidak layak huni. Jika tanggapan pertama Anda adalah berteriak ya! ... dan kemudian mengeluh ketika Anda keluar dari kantor, maka Anda perlu membuat rumah Anda lebih layak huni. Perasaan, dan Anda akan tahu itu.

Yang sedang berkata, Anda bekerja dalam simpati yang rumit . Apa pun yang Anda lakukan kemungkinan akan salah, dan mungkin akan memperburuk keadaan setidaknya dalam jangka pendek, karena perubahan sederhana memiliki riak. Jadi pertama-tama menjadi rendah hati, saya tidak bermaksud menjadi penekan atau menerima bahwa segala sesuatu pasti buruk, maksud saya menerima kenyataan bahwa niat baik Anda akan mengubah Anda dengan kejam.

Masalah

Dengan niat baik Anda mungkin merasa bahwa perubahan besar perlu terjadi, dan saya tidak setuju bahwa situasi ini memang ada, tetapi luangkan waktu sejenak untuk memikirkannya. Sistem saat ini berfungsi, Anda dan tim Anda menghasilkan kode, mungkin lambat, mungkin menyakitkan, tetapi bekerja dan Anda semua memiliki pengalaman tentang cara melakukan ini. Anda tahu kira-kira apa yang diharapkan, singkatnya Anda adalah praktisi profesional dalam sistem ini.

Setelah perubahan besar, tidak ada seorang pun, kecuali mungkin pelaksana, yang tahu apa yang diharapkan. Singkatnya, setiap orang telah diatur ulang ke level orang baru di bagian sistem ini. Itu tidak baik. Neophytes harus mempelajari aturan baru yang membutuhkan waktu. Pada masa itu, orang baru membuat kesalahan karena tidak dipraktikkan. Kesalahan-kesalahan itu menjadi bagian dari sistem, yang sekarang Anda harus hidup dengan dan tidak ada yang dekat sekarang gemerlapan.

A Way Forward

Ada saat-saat ketika memangkas, membakar, dan membangun kembali adalah yang terbaik yang dapat Anda lakukan. Sangat menarik jika tidak ada yang dipraktekkan dalam sistem lama, karena satu-satunya hal yang hilang adalah pengetahuan yang dikodifikasikan. Jika pengetahuan ini benar-benar tidak dapat dipahami maka itu sudah hilang, dan memulai kembali adalah satu-satunya pilihan. Sebaliknya jika metode kodifikasi, atau bagaimana penggunaannya bermasalah, tetapi berfungsi, pengetahuan itu masih dapat diakses, dan mungkin layak disimpan, mungkin tidak - jangan mengambil keputusan dengan enteng.

Pilihan lain adalah bekerja dengan sistem sehingga setiap orang memiliki kerangka acuan, tetapi untuk mengubah bagian-bagian kecil dari sistem sehingga setiap orang dalam tim sadar, atau jika mereka tidak menyadari perubahan, keduanya mudah untuk dilakukan. perhatikan dan mudah dipelajari. Ini adalah dasar untuk praktik yang disebut Kaizen . Formula yang lebih berorientasi pada pengembang disajikan dalam presentasi Shaving the Golden Yak, saya sangat merekomendasikan menonton dan memikirkannya.

Jadi temukan hal kecil yang bisa diubah yang akan memperbaiki hidup Anda, dan semoga itu dari beberapa orang lain. Perbaiki atau perbaiki situasi. Ini akan memberi Anda latihan dan pengalaman dalam menerapkan perubahan. Pastikan Anda mendapatkan umpan balik: dapatkah Anda mendiskusikannya dengan lebih baik, apakah itu benar-benar berguna, apakah itu mengganggu bagian lain dari sistem. Kembangkan perasaan Anda untuk apa yang bisa dilakukan dan bagaimana melakukannya.

Sekarang tiga hal telah terjadi:

• Anda telah meningkatkan sistem,
• Anda telah memperoleh pengalaman tentang cara mengubah sistem
• tim telah melihat Anda berhasil mengubah sistem.

Sekarang pilih hal lain untuk diperbaiki, ketika pengalaman Anda tumbuh dan saat Anda menghilangkan masalah menggantung rendah, Anda akan mulai menghadapi masalah yang lebih sulit dalam sistem, tetapi setidaknya sekarang ketika Anda mengatakan kami harus mengubah X:

• Anda tahu bagaimana perubahan itu akan mempengaruhi sistem
• Anda tahu masalah apa yang akan dihasilkan (aturan apa yang perlu dipelajari ulang)
• Anda tahu beberapa cara segera untuk memperbaiki, atau memperbaiki masalah yang akan diperkenalkan oleh perubahan
• orang-orang di sekitar Anda sadar bahwa Anda memiliki pengetahuan tentang sistem, dan mampu mengubahnya dengan sukses

Ya kamu bisa. TAPI...

Kamu harus Berhati-hati.

Pada awal karir saya (sangat lama yang lalu) saya beruntung / sial untuk masuk ke proyek lama beberapa bulan sebagai "Junior".

Seperti hal pertama yang saya perhatikan, ada (OMG) tidak ada repositori kode! Semua penggabungan kode dilakukan secara manual dengan mengirim file zip satu sama lain melalui surat.

Jadi saya pergi ke manajer saya (juga baru) dan menyarankan agar kita memiliki repositori. Jawabannya adalah: Oke, aturlah ....

Jadi mengatur repositori kode, tanpa bantuan, baru di perusahaan, sekarang pengalaman yang merendahkan.

Ketika saya mengatur semuanya, (kaget) tidak ada yang mau menggunakannya. Jadi saya mencoba untuk mendorong semuanya dan untungnya manajer saya mengerti itu penting sehingga saya mendapat dukungan.

Tetapi ini menghasilkan bahwa saya tidak disukai dan sayangnya mendapat nama panggilan yang berasal dari sistem kontrol sumber.

Jadi pendapat saya tentang ini adalah, pertama-tama rasakan anggota tim Anda, apa yang menurut mereka penting untuk dibentuk selanjutnya.

Mungkin mereka juga punya daftar seperti milik Anda. Mungkin mereka sudah memikirkan semuanya dan mereka ingin melakukan "hal" itu dalam daftar. Mungkin mereka .... (terserah) ....

Seluruh tim harus disejajarkan.

Tetapi jika tidak, maka Anda masih dapat bekerja secara profesional. Dan temukan orang-orang yang berpikiran sama dan bekerja bersama bagaimana Anda pikir itu harus dilakukan. Jika ini membawa hasil yang baik, lebih banyak orang akan bekerja dengan Anda, pada akhirnya itu akan menjadi "proses".

Sama seperti dengan kode, hal yang sama untuk proses pengembangan: perbaikan berkelanjutan diperlukan.

Jadi Ya, Anda harus selalu berusaha meningkatkan, apa yang mungkin diperbaiki.

Tetapi juga ingat banyak orang yang bekerja sama dengan Anda, sudah bisa menjadi profesional, dan mereka tahu apa yang salah dan apa yang dibutuhkan.

Apakah layak upaya pengembang (junior) untuk mencoba dan mendorong hal di atas seiring berjalannya waktu?

Ya, selalu sepadan dengan usaha Anda untuk mencoba dan membuat segalanya lebih baik. Anda tahu betul masalah apa yang Anda hadapi.

Tetapi seperti yang Anda sebutkan, ada banyak masalah untuk dipecahkan dan banyak dari masalah itu tidak terlalu berharga. Dan di banyak tempat, akan ada hambatan yang tidak dapat diatasi untuk kesuksesan Anda atau orang lain yang jauh lebih baik posisinya untuk memperjuangkannya. Jadi Anda harus selalu mencoba untuk membuat hal-hal yang lebih baik, bahkan jika itu berarti memetik yang hal Anda menghabiskan waktu Anda mencoba untuk membuat lebih baik.

Karena pada akhirnya, jika Anda bukan bagian dari solusi, Anda adalah bagian dari masalahnya.

Iya. Tetapi perubahan organisasi itu sulit bahkan untuk seorang senior sehingga jika Anda benar-benar ingin membuat perbedaan lakukan dengan cara yang benar:

• Tidak selama minggu-minggu pertama: Gunakan waktu ini untuk:

  • Buat kesan pertama yang bagus. Tunjukkan bahwa Anda cocok dalam tim.
  • Pahami budaya dan politik atau perusahaan Anda. Apakah aman untuk melakukan perubahan?
  • Bangun hubungan yang baik dengan rekan kerja
  • Pelajari tentang proses, aturan, dan kebutuhan tim Anda
  • Pelajari pekerjaan Anda dan lakukan yang terbaik yang Anda bisa. Anda pasti akan cukup sibuk.

• Pilih pertempuran Anda. Dapatkan beberapa kemenangan awal : Anda mungkin tiba dengan energi untuk mengubah segalanya tetapi ini tidak realistis. Fokuslah pada beberapa buah yang menggantung rendah dan tunjukkan bahwa ide-ide Anda berhasil. Anda ingin mereka menerima peningkatan yang lebih kompleks. Dan ingatlah bahwa banyak hal lebih mudah dalam buku.

• Pertimbangkan implikasinya kepada orang lain : Saya melakukan refactor yang memengaruhi banyak file. Bahkan jika mereka memperbaiki kode saya harus sangat berhati-hati untuk menghindari mengubah penggabungan menjadi menyebalkan. Coba juga untuk melakukan dan alasan mengapa mereka tetap bekerja seperti itu. Mungkin mereka tidak dapat menggunakan Scrum karena mereka tidak memiliki tes dan, dapat dimengerti, takut untuk mendorong kode yang belum diuji ke produksi sering. Menulis tes yang dapat diandalkan bukanlah tugas yang mudah. Kode saat ini bisa sangat sulit untuk diuji. Selain itu, tim tidak boleh digunakan untuk menulis tes atau kode testeable. Basis kode saat ini mungkin sulit untuk diuji dan perlu di refactored. Mungkin perlu bertahun-tahun untuk mengubah masalah ini, tetapi setidaknya Anda dapat fokus pada penyebab utama.

• Jangan menghakimi. Jangan menuntut. Mintalah dan dengarkan dengan cermat: Ini adalah saat ketika komunikasi sangat penting dan kami, para programmer, biasanya tidak terlalu pandai dalam nuansa halus. Ada beberapa teknik untuk membantu . Sangat mudah untuk terus mendorong ide kita daripada berfokus pada jawabannya. Pertama, pastikan mereka merasa bahwa Anda telah mendapatkan poin mereka. Pahami bahwa perasaan itu penting. Apa yang dirasakan perubahan ini pada mereka? takut? kekurangan? marah? frustrasi? berharap? Malas? Bodoh? (Jangan pernah membuat orang merasa bodoh). Tentu saja Anda akan bertanya banyak pertanyaan sebelumnya dan ini akan mencegah banyak langkah salah.

• Pimpin dengan contoh : mengeluh itu mudah, membuat perubahan itu sulit. Tunjukkan hasil dan orang-orang akan mempercayai Anda. Jika mereka tidak menggunakan tes, Anda dapat menulis tes unit Anda. Jika orang tidak mendokumentasikan Anda dapat membagikan beberapa dokumen google dengan tim. Pahami bahwa "Ok, lakukan itu" adalah salah satu skenario terbaik dan kemudian Anda perlu menyampaikan. Dalam hal ini Anda harus memikirkan sumber daya apa yang akan Anda butuhkan . Contoh: beri saya contoh Amazon kecil dan dua jam dari admin untuk server Jenkins

• Keep It Small and Simple (dan Murah): Anda tidak ingin menunggu persetujuan anggaran resmi atau membuat atasan Anda berpikir bahwa Anda kehilangan waktu berharga dari programmer yang mahal. Akan bagus untuk memiliki kode perangkat lunak tinjauan ini atau mengevaluasi beberapa alat open source tetapi kami hanya akan menggunakan repo untuk saat ini.

• Dapatkan massa kritis: Kumpulkan kelompok orang yang fokus pada peningkatan kualitas. Anda bahkan dapat pergi bersama mereka ke konferensi dan meminta bantuan atau bimbingan. Peopleware menggambarkan "membangunkan fenomena raksasa" dengan basis tim yang secara harfiah memberontak terhadap beberapa praktik bodoh yang memperlambat produktivitas. Ini secara individual akan sangat berbahaya dan saya tidak akan merekomendasikan. Tetapi jika semua kelompok setuju perubahan lebih mudah.

• Berikan waktu. Setelah itu berikan suara dengan kaki Anda : Anda mungkin ingin mencobanya selama beberapa bulan hingga dua tahun. Tetapi beberapa perusahaan tidak memiliki solusi yang mudah. Beberapa tim tidak ingin berubah dan tidak memiliki insentif. Dan beberapa basis kode adalah horor murni. Jika Anda merasa bahwa Anda menentang dunia, ingatlah bahwa ada banyak tawaran dalam kumpulan pekerjaan. Anda ingin mempelajari praktik-praktik yang baik dan dalam jangka panjang Anda akan lebih baik dalam tekanan dengan upah yang lebih sedikit tetapi mendapatkan pengalaman yang akan membuat Anda lebih berharga.

Bonus: Jika Anda berhasil menuliskannya untuk CV / Wawancara Anda. Sebagai seorang Junior, Anda biasanya hanya memiliki sedikit hal untuk dikatakan dan menciptakan perubahan untuk yang lebih baik selalu merupakan pertanda baik. Anda ingin memiliki pandangan yang sangat jelas dan realistis tentang apa yang Anda lakukan secara pribadi dan apa yang berhasil dari orang lain. Bayangkan pertanyaan wawancara berikut.

• Ceritakan tentang waktu di mana Anda membuat perbedaan dalam tim.
• Ya, saya ada di suatu tempat kalau mereka memiliki kebiasaan kuno. Banyak orang tidak senang dengan itu dan produktivitas memiliki ruang besar untuk ditingkatkan. Jadi saya mengusulkan untuk membuat percobaan cepat dengan retrospektif, kami melakukan X, dan Y dan sebagai hasilnya kami memiliki hasil yang luar biasa ini terukur ".

Iya. Tetapi bukan hal-hal yang Anda sarankan.

Di luar daftar Anda, Tes Unit / Integrasi adalah satu-satunya item yang dapat membuat Anda maju.

Anda dapat mulai menambahkan ini sendiri dengan investasi waktu minimal dan menunjukkan nilai instan. Ini masalah teknis dengan manfaat yang diterima secara luas dan tidak akan memengaruhi praktik kerja orang lain. Sementara juga menambah pengetahuan Anda tentang basis kode bahkan jika hasilnya tidak diterima. Menjual dengan mudah.

Yang lain umumnya proses bisnis yang melibatkan seluruh tim atau bahkan tim lain. Anda dapat menyarankan perbaikan, tetapi akan sulit bagi karyawan junior untuk berubah dan proses mengubahnya umumnya tidak techincal dan mungkin tidak terkait dengan pekerjaan normal Anda.

Saya juga akan menyarankan hal-hal seperti, mengatur saluran pipa CI, penyebaran otomatis, versi, perpustakaan kemasan sebagai hal yang baik untuk diserang

Tergantung pada:

• berapa banyak yang Anda harapkan dari praktik yang lebih baik
• berapa banyak usaha yang harus Anda keluarkan untuk sampai ke sana
• apa peluang keberhasilan dan risiko - dari kegagalan adopsi sederhana hingga praktik baru sebenarnya mengerikan, penurunan kualitas kode, orang-orang kunci pergi, semua orang membenci Anda dan Anda harus menemukan pekerjaan lain di kota lain di mana tidak ada yang tahu nama Anda

Pada dasarnya: baik dalam tanggung jawab Anda untuk meluangkan waktu yang masuk akal mengadvokasi apa yang Anda anggap terbaik - tetapi keputusan harus menjadi tanggung jawab tim atau manajemen. Perlu diingat bahwa mengasingkan orang jarang sepadan, bahkan jika Anda berakhir dengan praktik yang lebih baik.

Jangan mulai dengan hal-hal yang paling rumit seperti Scrum. Mulailah dengan langkah semudah mungkin.

Anda tidak menyebutkan manajemen kode sumber. Apakah Anda memiliki repositori kode sumber (git, svn, cvs, ...)? Strategi untuk penandaan dan percabangan? Itu adalah langkah sederhana yang bisa dilakukan pemula. Baca masalah apa yang dipecahkan oleh langkah-langkah ini, dan bagaimana hal itu membantu perusahaan Anda mengurangi biaya (itulah yang diminati manajemen).

Langkah selanjutnya bisa berupa bangunan otomatis, setiap malam atau langsung setelah setiap check-in, misalnya dengan Jenkins. Anda juga dapat menjalankan tes secara otomatis. Dan menambahkan beberapa alat untuk mengukur kualitas kode (oh ya: mendefinisikan beberapa standar pengkodean juga merupakan langkah yang baik).

Sedangkan untuk scrum, lebih baik baca tentang "Extreme Programming" (XP). Scrum didasarkan pada banyak ide XP dan menambahkan proses formal di sekitarnya - konsep XP masih dapat digunakan tanpa proses itu.

Sarankan hal-hal, sediakan informasi latar belakang, coba meyakinkan orang lain untuk mencobanya, analisis hasilnya, ... tapi jangan berharap banyak kerja sama dari orang lain: kebanyakan orang lebih suka bertahan dengan kebiasaan buruk lama mereka. Tetapi ketika Anda tidak mencobanya, tidak ada yang akan membaik.

Anda bilang timnya cukup baru (3 tahun), jadi jika Anda tidak dapat memperkenalkan beberapa prinsip yang baik sekarang, akan lebih sulit melakukannya 10 tahun kemudian. Beberapa hal yang Anda sebutkan seperti pengujian dan sistem versi adalah beberapa di antara yang dapat Anda sarankan, tetapi jangan melemparkan saran begitu saja tanpa menekankan pada manfaatnya yang jelas dan memilih alat yang dibutuhkan tumpukan pengembangan Anda.

Pada awalnya, ajukan pertanyaan

Membaca daftar Anda, saya akan menyarankan pertanyaan-pertanyaan berikut (lihat kembali daftar Anda untuk melihat bagaimana mereka cocok):

• Bagaimana saya melihat pekerjaan apa yang diminta oleh pemilik bisnis?
• Sudahkah Anda mencoba [Scrum]?
• Siapa pemilik produk untuk ini?
• Apa perannya?
• Apa yang [peran ini] lakukan?
• Peran apa yang bertanggung jawab untuk [kegiatan ini]?
• Sudahkah Anda mencoba standup harian?
• Bagaimana cara saya mengomunikasikan halangan saya kepada anggota tim lainnya?
• Bagaimana saya mencari tahu apa yang anggota tim lain bekerja?
• Haruskah kita menaruh [ini] di alat pelacak masalah?
• Bagaimana seharusnya kita menulis [ini] di alat pelacak masalah?
• Ketika [ini] terjadi, haruskah kita menaruhnya di alat pelacak masalah sebagai [itu]?
• Bagaimana cara kita menguji?
• Bagaimana cara kita merekam tes kita untuk digunakan kembali oleh orang lain?
• Sudahkah Anda mencoba [JUnit]?
• Di mana [ini] didokumentasikan?
• Sudahkah Anda mencoba [MediaWiki]?

Ganti hal-hal dalam [kurung] yang sesuai untuk membuat pertanyaan masuk akal atau sesuai dengan prioritas Anda. Pertimbangkan penulisan ulang jika kata-kata saya tidak sesuai dengan gaya Anda.

Anda mungkin sudah mulai melakukan itu. Mendukung percakapan satu lawan satu daripada percakapan kelompok. Karena satu-satu, Anda dapat membaca dengan lebih baik apa yang dipikirkan orang lain. Apakah orang itu untuk perubahan ini? Menentangnya? Lemah? Dengan berani?

Ketika Anda baru, mengajukan pertanyaan praktis gratis. Orang seharusnya mengharapkan Anda untuk mengajukan pertanyaan. Sekalipun pertanyaan Anda secara implisit menganjurkan posisi yang mereka lawan, mereka tidak boleh marah. Mereka harus menjelaskan mengapa mereka menentang posisi itu. Saya merekomendasikan untuk tidak berdebat dengan mereka. Berdebat cenderung mengeraskan posisi lebih dari meyakinkan. Perhatikan siapa yang memiliki posisi apa dan terus maju.

Nanti, ambil langkah

Carilah cara yang Anda dan mungkin orang lain (yaitu yang Anda catat sebelumnya dengan Anda) dapat memulai perubahan yang Anda inginkan. Tidak semua orang menginginkan standup? Kenapa tidak? Mungkin Anda yang menginginkannya dapat memiliki standup sendiri. Tidak seefektif dengan seluruh tim, tetapi lebih dari yang Anda miliki sekarang.

Ketika Anda memiliki kesulitan (dan dengan asumsi Anda tidak dapat berbagi dalam standup), kirim email ke tim untuk bantuan.

Identifikasi peran apa yang seharusnya, mungkin dengan dukungan orang lain yang setuju dengan Anda. Mulai secara konsisten pergi ke orang-orang ketika pekerjaan melibatkan peran yang menurut Anda (mungkin kelompok Anda) miliki. Jika mereka mundur, minta mereka untuk mengidentifikasi siapa yang harus memiliki peran itu.

Mintalah pemilik produk (yang Anda identifikasi) untuk menulis deskripsi tentang bagaimana menurut mereka produk mereka harus bekerja sekarang dan di masa depan.

Instal kerangka uji (jika orang lain menyukai ini, buat keputusan bersama kerangka mana) dan gunakan untuk proyek Anda. Saat Anda memperbaiki bug, tulis tes. Dokumentasikan ini dalam laporan bug pada pelacak masalah (tulis tes yang menunjukkan bug, disimpan di [lokasi]). Dorong orang lain untuk menjalankan tes saat mereka melakukan perubahan. Jika tidak, jalankan tes sendiri dan kirimkan masalah ke pelacak seperlunya.

Jika Anda dapat memperoleh dukungan manajemen, instal perangkat lunak wiki atau sejenisnya dan mulailah mendokumentasikan barang-barang Anda. Jika orang-orang mengajukan pertanyaan yang menunjukkan bahwa mereka tidak membaca dokumentasi, arahkan mereka ke halaman yang relevan. Dorong mereka untuk bertanya lebih banyak jika mereka tidak memahami dokumentasi. Jika mereka terus mengajukan pertanyaan yang tercakup dalam dokumentasi, kutip dari dokumentasi saat menjawab. Pertimbangkan mendorong mereka untuk memperbarui wiki jika Anda berpikir bahwa masalahnya adalah struktural daripada mereka tidak membaca.

Saya sarankan hanya berkonsentrasi pada satu tugas pada satu waktu. Dan tentu saja hanya mendorong satu per satu. Jangan memaksakan diri. Lihat contoh mendorong lebih keras dari yang diinginkan kelompok ini. Berkonsentrasi lebih pada mengubah perilaku Anda daripada mereka. Jika cara Anda adalah cara yang benar, itu harus jelas bagi orang yang mengamati Anda. Tindakan berbicara lebih keras daripada kata-kata. Cobalah untuk tidak mengulangi diri Anda dengan orang yang sama ketika Anda mendorong. Setelah Anda menuntun kuda ke air, tinggalkan pilihan kapan atau apakah akan minum untuk yang lain.

Akhirnya, Anda akan menjadi senior

Seiring waktu, tim Anda akan mempekerjakan orang baru. Anda akan berhenti menjadi karyawan baru dan dapat menganjurkan posisi Anda dengan orang-orang baru. Bekerja bersama mereka untuk membuat perubahan. Dan Anda mungkin menemukan bahwa Anda membuat kemajuan dengan rekan setim Anda yang ada juga. Atau jika itu tidak berhasil, cari pekerjaan baru di mana mereka memiliki praktik yang lebih baik. Tidak ada terburu-buru nyata. Anda punya pekerjaan. Anda dapat menunggu beberapa saat untuk memiliki pekerjaan yang lebih baik, baik dengan meningkatkan itu atau menemukan yang lebih baik.

Jawaban singkat : Tidak, untuk semua alasan yang diuraikan dalam jawaban lain. Bahkan ketika menjadi dev menengah atau senior, biasanya lebih baik untuk mencari terlebih dahulu untuk memahami ketika bergabung dengan tim baru.

Solusi yang diusulkan :

1) setiap kali Anda melihat sesuatu yang Anda rasa harus ditingkatkan, perhatikan itu! (dalam buku catatan, dalam catatan digital ...)

2) Setelah 6 bulan, kembali ke catatan Anda dan periksa. Berapa banyak ide yang sekarang terasa tidak berguna dan tidak memadai? Kemungkinan besar, Anda menyelamatkan diri Anda dari rasa malu. Jika masih ada ide, sekarang saat yang tepat untuk memperkenalkannya, jika memungkinkan dengan mengujinya sendiri terlebih dahulu.

Terlambat menjawab, dan menyetujui banyak konten bagus di jawaban lainnya.

Saya pikir perlu disuarakan bahwa masalah utama di sini bukanlah praktik spesifik, tetapi budaya tim secara keseluruhan.

• Menciptakan perubahan budaya itu sulit .
• Terlebih lagi jika Anda dilihat sebagai "junior"

Segala sesuatu yang lain dapat mengikuti jika ada cara untuk mencapai peningkatan berkelanjutan .

Pendekatan saya untuk mencapai itu adalah:

• Proses dan prosedur yang terdokumentasi
• Retrospektif dengan tim yang tindakannya mengubah dokumentasi proses.

Saya kira jika Anda tidak memiliki sprint, Anda belum memiliki retro reguler. Yang Anda butuhkan hanyalah percakapan dengan tim, dan kemudian bertindak itu.

Anda dapat dengan mudah memulai proses dokumentasi. "Aku orang baru, apakah aku benar? Biarkan aku menuliskannya." Adalah penting untuk kemudian benar-benar mengikuti prosesnya sendiri, atau mencoba dan menelepon kami di tempat yang rusak.

Mungkin Anda mulai dengan percakapan semacam itu menjadi ad hoc dan kemudian menyarankan ritual rutin.

Mengambil pendekatan ini memungkinkan pendekatan tambahan, lembut lembut. Anda dapat menghindari tampil sebagai junior yang hal-hal yang mereka tahu itu semua dan bukannya mencoba menjadi fasilitator untuk tim yang membuat perubahan.

Beberapa pertimbangan:

• Beberapa tim memiliki proses yang buruk tetapi sebenarnya sudah tahu itu. Mereka ingin berubah dan hanya perlu sesuatu untuk mengkatalisasi itu. Tim lain benar-benar terjebak dalam cara mereka dan jauh lebih sulit untuk berubah.
• Hal yang sama berlaku untuk individu.
• Anda harus peka terhadap hal itu dan mencari tahu siapa di tim yang terbuka untuk berubah dan siapa yang tidak. Mengerti kenapa.
• Temukan kemenangan mudah.
• Buat perubahan selamat datang di tim: Temukan titik nyeri masing-masing dan coba bantu memperbaikinya.