Monday, December 08, 2003
Saya sebenarnya agak hancus dgn user requirements capturing. Saya memang tak pandai & kurang sabar dgn pengguna yg malas utk buat keje dia spt seorang HR manager yg tak mau hasilkan company polisi & procedure dan menjadikan user requirements capturing excerice tu sebagai tempat dia throw ideas, kemudian ubah, throw lagi ideas, ubah lagi.
Shoot!! Dia sepatutnya hasilkan doc yg mengandungi polici + procedure tu dulu, dipersetujui semua pihak yg terbabit, baru handover kpd team yg kena buat sw HR tu. Tapi, dia malas dan hanya salahkan orang lain.
Malangnya, client sedemikian agak ramai. Saya belum mampu handle user sedemikian lagi. Tapi, saya kenal beberapa orang yg memang terror dlm bab ni. Mereka pandai handle orang dan mahir dlm project management on the client handling side. Utk projek yg besar dan punya client sedemikian, saya kena bergabung dgn mereka ni. Kalau tak, hancus nanti.
Kebanyakan projek memang perlu dibuat dlm satu team. Saya bernasib baik dpt rasa kedua2 situasi, sendirian dan dlm team. Saya bermula dgn jadi solo programmer buat 2 jenis payphone management system, satu bercakap dgn Tamura coin payphone guna dtmf dan satu lagi dgn payphone yg guna modem. Buat sorang2 selama lebih 2 tahun.
Kemudian bermula fasa handle team lebih 10 org 2 kali dan hanya 2 orang sekali. Memang berbeza handle team ni. Kesimpulan yg saya buat utk diri saya sendiri ialah, apabila join satu team baru utk satu projek baru, berusaha la utk memahami projek yg hendak dibuat tu, takat mana kompleknya dari segi domain nye mahupun teknologi yg nak diguna, serta time frame utk siapkan.
Berusaha la utk ketahui kekuatan dan kelemahan team members kita. Map kan kekuatan dan kelemahan mereka ni dgn projek yg hendak dibuat. Mana2 kelemahan yg ada, tampung dgn team members yg kuat dlm bhgn yg orang lain lemah. Kalau dah tak ada, kita aje la yg tampung kelemahan tersebut jika mampu.
Cthnya, utk salah satu team yg saya join beberapa tahun lepas. Mereka kena buat satu projek guna J2EE. Ramai team members yg agak lemah dlm Java, apatah lagi J2EE. Hanya seorang je programmer dari india yg agak mahir dlm Java dan J2EE (team ni ada 2 programmer india muslim dan yg selebihnya orang tempatan). Peringkat awal saya join adalah peringkat fire fighting. Saya dan programmer india ni terpaksa banyak tampung kelemahan team members, dlm mendebug code mereka dan dlm cara2 utk mereka buat module mereka.
Cut off point dlm projek ni ialah bila programmer india tu pun hadapi beberapa bugs yg dia sendiri tak boleh nak debug. Selepas saya debugkan utk dia, saya ambil keputusan utk hasilkan satu framework yg sepatutnya lebih mudah dpd J2EE tu sendiri, yet ia menggunakan J2EE secara transparent. Setelah terhasilnya framework ini dan apabila setiap team members berjaya menyiapkan module pertama mereka menggunakan framework, baru la produktiviti team secara keseluruhan meningkat akibat berkurangan dgn mendadaknya bugs2 yg J2EE related.
Satu point penting ialah continuous improvement. Bawa la masuk teknologi/tools/libs yg berbaloi utk diperkenalkan kpd team members, cthnya:
1. perkenalkan ant kpd team tersebut dan bila cairo join team ni, dia berjaya enhance kan lagi supaya boleh seamless build dan auto deploy kat tomcat utk development, dan ke iplanet utk production. framework yg ada tu membolehkan application kami run kat atas web container shj mahupun web + ejb container secara transparent.
2. perkenalkan OR mapper castor. Productivity utk buat code2 db terus meningkat beberapa kali ganda krn senang dan cepatnya nak code db access ni beserta hilang la bugs spt max cursor exceeded, etc.
3. perkenalkan electric xml yg jauh lebih senang dan power berbanding dgn parser xerces yg guna sax/dom.
Tapi, ada juga yg saya perkenalkan tu tak mendapat sambutan walaupun berbuih mulut spt junit utk buat unit test. Hancus. Hanya sekerat je yg buat sikit2. Berat betul mereka nak buat unit test.
Ni pengalaman saya je.
Shoot!! Dia sepatutnya hasilkan doc yg mengandungi polici + procedure tu dulu, dipersetujui semua pihak yg terbabit, baru handover kpd team yg kena buat sw HR tu. Tapi, dia malas dan hanya salahkan orang lain.
Malangnya, client sedemikian agak ramai. Saya belum mampu handle user sedemikian lagi. Tapi, saya kenal beberapa orang yg memang terror dlm bab ni. Mereka pandai handle orang dan mahir dlm project management on the client handling side. Utk projek yg besar dan punya client sedemikian, saya kena bergabung dgn mereka ni. Kalau tak, hancus nanti.
Kebanyakan projek memang perlu dibuat dlm satu team. Saya bernasib baik dpt rasa kedua2 situasi, sendirian dan dlm team. Saya bermula dgn jadi solo programmer buat 2 jenis payphone management system, satu bercakap dgn Tamura coin payphone guna dtmf dan satu lagi dgn payphone yg guna modem. Buat sorang2 selama lebih 2 tahun.
Kemudian bermula fasa handle team lebih 10 org 2 kali dan hanya 2 orang sekali. Memang berbeza handle team ni. Kesimpulan yg saya buat utk diri saya sendiri ialah, apabila join satu team baru utk satu projek baru, berusaha la utk memahami projek yg hendak dibuat tu, takat mana kompleknya dari segi domain nye mahupun teknologi yg nak diguna, serta time frame utk siapkan.
Berusaha la utk ketahui kekuatan dan kelemahan team members kita. Map kan kekuatan dan kelemahan mereka ni dgn projek yg hendak dibuat. Mana2 kelemahan yg ada, tampung dgn team members yg kuat dlm bhgn yg orang lain lemah. Kalau dah tak ada, kita aje la yg tampung kelemahan tersebut jika mampu.
Cthnya, utk salah satu team yg saya join beberapa tahun lepas. Mereka kena buat satu projek guna J2EE. Ramai team members yg agak lemah dlm Java, apatah lagi J2EE. Hanya seorang je programmer dari india yg agak mahir dlm Java dan J2EE (team ni ada 2 programmer india muslim dan yg selebihnya orang tempatan). Peringkat awal saya join adalah peringkat fire fighting. Saya dan programmer india ni terpaksa banyak tampung kelemahan team members, dlm mendebug code mereka dan dlm cara2 utk mereka buat module mereka.
Cut off point dlm projek ni ialah bila programmer india tu pun hadapi beberapa bugs yg dia sendiri tak boleh nak debug. Selepas saya debugkan utk dia, saya ambil keputusan utk hasilkan satu framework yg sepatutnya lebih mudah dpd J2EE tu sendiri, yet ia menggunakan J2EE secara transparent. Setelah terhasilnya framework ini dan apabila setiap team members berjaya menyiapkan module pertama mereka menggunakan framework, baru la produktiviti team secara keseluruhan meningkat akibat berkurangan dgn mendadaknya bugs2 yg J2EE related.
Satu point penting ialah continuous improvement. Bawa la masuk teknologi/tools/libs yg berbaloi utk diperkenalkan kpd team members, cthnya:
1. perkenalkan ant kpd team tersebut dan bila cairo join team ni, dia berjaya enhance kan lagi supaya boleh seamless build dan auto deploy kat tomcat utk development, dan ke iplanet utk production. framework yg ada tu membolehkan application kami run kat atas web container shj mahupun web + ejb container secara transparent.
2. perkenalkan OR mapper castor. Productivity utk buat code2 db terus meningkat beberapa kali ganda krn senang dan cepatnya nak code db access ni beserta hilang la bugs spt max cursor exceeded, etc.
3. perkenalkan electric xml yg jauh lebih senang dan power berbanding dgn parser xerces yg guna sax/dom.
Tapi, ada juga yg saya perkenalkan tu tak mendapat sambutan walaupun berbuih mulut spt junit utk buat unit test. Hancus. Hanya sekerat je yg buat sikit2. Berat betul mereka nak buat unit test.
Ni pengalaman saya je.
Comments:
Post a Comment
