Bagaimana saya bisa mengatasi model pengembangan perangkat lunak yang tidak terstruktur dengan baik?

Saya bergabung dengan perusahaan saat ini saya bekerja lebih segar. Karena terbatasnya jumlah orang yang ahli dalam pengembangan perangkat lunak SIG, dan karena saya adalah salah satu dari mereka, saya langsung direkrut sebagai Manajer Proyek.

Saya cukup mahir dengan Java dan GIS, dan saya telah melakukan penelitian yang memotivasi diri pada layanan berbasis lokasi, tetapi tidak dengan manajemen proyek dan pengembangan perangkat lunak terstruktur. Itu satu tahun setelah kelulusan saya sebagai Geologi khusus dan selama tahun sebelumnya saya bekerja sebagai akademisi di Universitas.

Berkat minat yang saya alami di tempat kerja, kesempatan muncul, dan akhirnya saya bertanggung jawab atas departemen Intelijen Bisnis perusahaan juga. Perusahaan itu percaya pada saya. Saya sendiri mempelajari data pergudangan dan konsep BI dan berhasil menggabungkan SIG dengan BI juga.

Juga saya saat ini bekerja dengan dua pengembang di alat BI kami di C # WPF, di mana saya juga memainkan peran pengembang di kali (yang saya suka).

Saya berusaha sangat keras untuk mengadopsi metodologi pengembangan perangkat lunak yang baik dengan manajemen proyek yang gesit, tetapi itu tidak terlalu berhasil. Juga, meskipun saya percaya pada kode yang dirancang dengan baik sejauh menyangkut produk, karena kurangnya pengetahuan teknis yang dimiliki CEO saya (yang berada tepat di atas saya), saya biasanya tidak mendapatkan jumlah waktu yang diperlukan untuk melakukannya. Waktu yang dibutuhkan sangat ditingkatkan oleh kurangnya keahlian yang kami miliki dalam bahasa pengkodean khusus secara keseluruhan juga (misalnya WPF berlawanan dengan Java). Juga tidak ada sistem pengendali versi di tempat juga.

Saya sangat muak dengan hal-hal yang terjadi karena tidak terstruktur dan saya menemukan sebagian besar waktu saya berpikir daripada bekerja bagaimana cara membuat sesuatu terstruktur. Saya harap kalian dengan pengalaman profesional yang baik akan dapat membantu saya mengatasi situasi ini.

Kami memiliki masalah yang sama (tanpa detail teknis, tentu saja) di perusahaan tempat saya bekerja sekitar dua tahun yang lalu.

Anda hanya perlu melakukannya selangkah demi selangkah. Jangan mencoba untuk mengadopsi pengembangan perangkat lunak tangkas dengan terburu-buru. Ada banyak hal untuk dipelajari dan diterapkan. Jangan biarkan kurangnya keahlian untuk menjatuhkan Anda juga.

Bangun perlahan (tapi secepat yang Anda bisa: P), dengan mantap dan pasti.

Saya akan merekomendasikan langkah-langkah selanjutnya (untuk melakukan ini, Anda mungkin beralih dari manajemen ke pengembangan untuk sementara waktu, tetapi itu akan baik-baik saja)

1. Belajar yang baik sistem kontrol versi , dan belajar dengan baik. Secara pribadi saya akan merekomendasikan git atau lincah. Ada banyak dokumentasi tentang keduanya.
2. Bangun inti yang kuat pada praktik dan pola . Baca buku, baca blog, tonton screencast bersama anggota tim. Ini akan memberi angin baru bagi pembangunan.
3. Pelajari TDD / BDD dan cobalah untuk menerapkannya dalam kode baru , serta dalam kode lama yang mungkin Anda sentuh ketika melakukan fitur baru.
4. Lakukan pair programming . Dua kepala berpikir lebih baik dari satu, dan juga 4 mata lebih baik dari 2 :).
5. Cari tentang terbaru dan paling umum digunakan alat dalam komunitas bahasa yang sedang Anda berkembang. Pelajari tentang mereka dan cobalah untuk memasukkan beberapa dari mereka dalam proyek. Lihat bagaimana ini dibangun dan pelajari.
6. Gunakan scrum . Iterasi, cerita, poin cerita, hambatan adalah semua konsep yang harus Anda kenal. Bagi saya, scrum telah terbukti sebagai alur kerja terbaik untuk pengembangan dan manajemen perangkat lunak. Terapkan dan pelajari dari pengalaman setiap hari.
7. Ajarkan dengan contoh . Sebagian besar pengembang pemula ingin mempelajari hal-hal baru, tetapi juga beberapa dari mereka sangat malas. Bagaimanapun, tunjukkan pada mereka hal-hal baru yang telah Anda pelajari dan terapkan dan semoga itu akan menggelitik otak mereka.

Juga, jika mungkin, pekerjakan konsultan hanya agar ia dapat memeriksa prosesnya dan memberikan nasihat yang lebih baik.

Jangan malas atau berkecil hati. Belajarlah dari kesalahan Anda dan cobalah berbagai pendekatan. Ini baru permulaan!

Edit:

Berikut adalah beberapa tautan dan buku yang telah saya baca / gunakan belakangan ini ...

Belajar git: Pro Git

Ini adalah beberapa blog yang akan saya rekomendasikan (kebanyakan dari mereka adalah .NET berorientasi):

• Blog Java
• Blog Karl Seguin dan seri Yayasan Pemrogramannya.
• CodeBetter.com
• Berpikir Kode
• Los Techies
• Bersihkan Coder
• Dan juga tautan ini ke pertanyaan stack overflow.

Untuk buku, Anda dapat melihat daftar Buiding A Solid Programming Core di amazon. Saya juga akan merekomendasikan ini:

• Kode Bersih
• Pengembangan, Prinsip, Pola, dan Praktek Perangkat Lunak Agile
• Hampir semua buku dari The Pragmatic Bookshelf

Sebagai manajer, tugas Anda adalah mendapatkan waktu yang dibutuhkan untuk menyelesaikan proyek dengan benar. Saat mendekati CEO, pastikan Anda memiliki semua angka yang mendukung Anda dan alasan mengapa estimasi sama panjangnya. Adalah tanggung jawab Anda sebagai manajer untuk membuat CEO memahami mengapa perlu n jam / hari / minggu untuk menyelesaikan tugas yang diberikan. Ini kadang-kadang bisa sulit, tetapi saya belum bertemu seorang CEO yang ingin perusahaannya gagal dan saya yakin jika Anda memasukkannya ke dalam istilah-istilah semacam itu (jika semuanya gagal), ia mungkin mengubah nadanya.

Jika CEO tidak mau memberi Anda waktu yang dibutuhkan untuk menyelesaikan tugas, maka IMHO, bersiaplah untuk pindah ke pekerjaan lain atau bersiap-siap untuk pawai kematian berkelanjutan. Sebagai upaya terakhir, jelaskan kepada CEO kelelahan yang tidak diragukan lagi datang dari harapan yang tidak realistis.

Karena itu, Anda juga perlu memastikan bahwa pengembang Anda memberi Anda perkiraan yang akurat (sangat sulit, hampir tidak mungkin tanpa desain teknis yang tepat dilakukan, yang juga harus ada di suatu tempat).

Agile tidak baik di semua domain pengembangan. Bekerja untuk beberapa jenis proyek, gagal total pada yang lain. Anda mungkin harus mencoba beberapa metodologi berbeda sebelum Anda menemukan satu yang berfungsi dengan baik .

Dapatkan pengaturan kontrol versi . Sungguh, dibutuhkan 5-10 menit untuk menyiapkan Git, beberapa menit lagi untuk menurunkan operasi dasar dan satu atau dua hari membaca untuk mendapatkan konsep yang lebih maju.

Hmm, tidak yakin apakah saya bertemu Anda di sebuah acara Agile / XP di Toronto - ini terdengar akrab

Sepertinya Anda perlu istirahat. Ambil akhir pekan yang panjang, mabuk jika mau, dan lupakan pekerjaan selama beberapa hari.

Tenangkan dirimu. Mengajari diri sendiri itu baik, dan hanya karena metodologi tidak bekerja dengan kepribadian yang terlibat, tidak berarti Anda melakukan kesalahan, dan itu bukan kegagalan pribadi.

Ada situs (beta) pm.stackexchange.com, ditargetkan pada Manajemen Proyek, Anda mungkin mendapatkan beberapa saran / dukungan yang berguna di sana - tetapi dengan segala cara, simpan pertanyaan di sini juga.

Pindah ke hal-hal teknis:

tidak ada versi yang mengendalikan sistem di tempat

Masukkan satu sebagai prioritas utama Anda. Saya lebih suka sistem terpusat seperti SVN (Subversion) daripada git / mercurial, karena laptop curian tidak akan memiliki banyak sejarah secara lokal. Terutama penting jika sesuatu yang super-rahasia (seperti kata sandi dan ssh-keys) diperiksa secara tidak sengaja. Tapi, ini masalah selera. Tidak ada yang membuang waktu lebih banyak daripada bug dari 'kontrol versi manual' - misalnya mengembalikan kode ke apa yang Anda pikirkan sebelumnya.

Semoga berhasil

Sepertinya Anda memiliki beberapa masalah: 1. Berkomunikasi dengan manajemen senior non-teknis sehingga mereka akan mendukung program peningkatan Anda; dan 2. Mengemudi program peningkatan untuk sukses.

Bagian tersulit dari nomor 1 hanyalah mengingat bahwa manajemen senior sering kali tidak akan tertarik pada perincian apa yang sedang Anda kerjakan. (Jika ya, mereka akan melakukannya sendiri daripada menyerahkannya kepada Anda!) Kedengarannya seperti rintangan besar adalah 'mengapa' dan Anda mungkin ingin melihat CMM 1.1 untuk deskripsi manfaat bisnis dari peningkatan proses program. Apakah Anda menggunakan CMM atau sesuatu yang lain untuk benar-benar meningkatkan proses Anda tidak masalah untuk diskusi ini, hanya data dari studi Carnegie-Mellon yang menunjukkan organisasi yang lebih dewasa menghasilkan proyek lebih cepat dengan lebih sedikit variasi dalam waktu pengiriman.

Ada banyak jalan menuju sukses pada perbaikan proses, semuanya cenderung sangat panjang. Pengalaman dengan CMM menunjukkan bahwa dibutuhkan 8 hingga 10 tahun untuk beralih dari level 1 ke 5. Pengalaman dengan 6 sigma menunjukkan bahwa setiap iterasi memberikan beberapa peningkatan tetapi perlu beberapa iterasi untuk menghilangkan sebagian besar masalah potensial dan, pada saat Anda mulai 6 sigma kualitas, pekerjaan dilakukan sepenuhnya berbeda tanpa harus mengambil risiko mencoba mengganti semuanya sekaligus.

Jika ada pendekatan peningkatan kualitas yang biasa digunakan dalam industri Anda, luangkan waktu untuk mencoba melihat bagaimana itu berlaku untuk perangkat lunak dan menggunakannya sehingga seluruh perusahaan mendengar tentang sesuatu yang sudah mereka kenal dan mendukung. Kita dapat berbicara selama berjam-jam tentang alat dan praktik perangkat lunak tertentu tetapi CEO non-perangkat lunak akan mengabaikannya dengan cepat. Bicara tentang praktik standar industri dan dia akan bersemangat karena Anda berbicara bahasanya. Bicara tentang perangkat lunak dalam istilah umum industri dan dia akan mulai mengajukan pertanyaan yang relevan untuk lebih memahami tantangan Anda dan rencana Anda untuk membuat hasil perusahaan lebih baik.

Anda tidak akan menang setiap meminta dukungan dengan cara ini, Anda mungkin akan mendapatkan tampilan kosong jauh lebih sedikit dan lebih banyak kemenangan sekalipun!

Semoga beruntung, Tuan!

Semua saran Anda memang masuk akal dan cara untuk masuk di banyak perusahaan. Tetapi mereka tidak universal, terutama dengan tim yang tidak berpengalaman. Alasan mereka tidak adalah karena mereka memerlukan sejumlah pekerjaan untuk pengaturan dan pemeliharaan - bahkan kontrol versi - yang banyak orang akan anggap sebagai taruhan meja untuk proyek perangkat lunak apa pun. Karena mereka membutuhkan pekerjaan, mereka juga perlu memberikan manfaat. Dan mungkin memang demikian halnya dalam situasi khusus Anda, mereka tidak melakukannya! Atau setidaknya orang-orang yang ditugaskan membuat keputusan tidak melihat manfaatnya!

Seperti yang telah ditunjukkan orang lain, Anda perlu:

• Coba adopsi praktik pada gilirannya. Jangan mencoba semuanya sekaligus karena akan membuat orang kewalahan.
• Anda perlu mengetahui urutan yang baik untuk ini. Saya akan mulai dengan kontrol versi. Pergilah dengan yang lebih mudah juga. Begitu orang mulai percaya bahwa Anda membuat keputusan yang baik dan mereka melihat manfaatnya, mereka akan lebih cenderung untuk melakukan perubahan yang lebih berisiko.
• Bangun kasus yang kuat mengapa sesuatu perlu diimplementasikan. Dengan 2-3 pengembang yang terus membuat kemajuan terlihat oleh pengguna akhir, sulit untuk membenarkan mengadopsi metodologi pengembangan yang lebih rumit misalnya. Anda akan dilihat sebagai fokus proses daripada fokus pada hasil.
• Ingat-ingatlah siapa yang perlu Anda yakinkan. Para devs? CEO?