Daftar Isi:
Menjadi tim pengembangan perangkat lunak yang gesit tentu memiliki arti yang berbeda bagi orang yang berbeda. Ada beberapa tingkat adopsi dalam spektrum yang sangat luas, dengan tampaknya sangat sedikit organisasi yang berpikir bahwa mereka melakukannya dengan baik. Menurut Survei Status Agile VersionOne (dirilis April 2017), 80% responden mereka mengatakan bahwa mereka "berada pada atau di bawah level yang masih dewasa". Sayangnya, tim pengembang sering kali tidak berusaha keras untuk bagian "belajar" dari pengulangan. Kami ingin segera menyelesaikan upacara Scrum sehingga kami dapat kembali menulis kode. Lagi pula, ada banyak pekerjaan yang harus dilakukan! Tetapi apakah masalah waktu coding yang tidak cukup?
Bagi banyak dari kita, pemadaman kebakaran mungkin juga secara khusus tercantum dalam deskripsi pekerjaan kita. Kami pergi bekerja setiap hari mengetahui bahwa kami harus siap untuk meluncur ke bawah tiang pada saat itu juga, mengambil topi kami, dan melompat ke atas truk. Kami menerimanya sebagaimana adanya, dan kami menganggap tidak ada yang dapat kami lakukan untuk mengatasinya. Tapi, bagaimana jika akar penyebab perjuangan kita adalah kurangnya efisiensi? Semua orang tahu betapa pentingnya melakukannya dengan lebih baik daripada perusahaan lain di sana. Kami sepertinya tidak bisa sampai di sana — kami sepertinya tidak memiliki bandwidth. Manajer menambahkan lebih banyak orang dan memperbesar ukuran organisasi mereka dan masih mengalami kesulitan yang sama. Anda tampaknya tidak dapat mengatasi kesulitan karena tim Anda tidak mengembangkan perangkat lunak secara efisien (dan Anda tidak sendirian).
Prinsip dalam Pembangunan yang Efisien
Pixabay
Lalu apa yang menyebabkan kita menjadi tidak efisien? Bagi kebanyakan dari kita, hal pertama yang terlintas dalam pikiran kita adalah kurangnya otomatisasi (pembuatan, penerapan, pengujian otomatis). “Setelah kita memiliki otomatisasi yang cukup, hidup akan menjadi lebih baik.” Sayangnya itu hanya sebagian dari solusi. Pertimbangkan efek pengerjaan ulang pada proyek Anda. Cara paling efisien untuk membangun fitur adalah dengan membuatnya sekali dengan benar dan tidak pernah kembali dan menyentuhnya lagi. Bug, refactoring, dan aktivitas serupa lainnya pada dasarnya membuka kembali pasien setelah dia meninggalkan ruang operasi dan ada risiko yang terkait dengan itu. Kita tidak bisa menghilangkan pengerjaan ulang, tapi kita harus berusaha untuk meminimalkannya.
“Tapi bukankah gesit menerima pengerjaan ulang (mis. Refactoring)?” Ini sebenarnya berhasil, karena pencipta agile memahami bahwa dua penyebab utama pengerjaan ulang adalah keadaan yang tidak terduga dan persyaratan bisnis yang berubah. Ternyata manusia sangat buruk dalam memprediksi masa depan. Pembuat konten yang gesit juga memahami bahwa penyumbang besar ketidakefisienan adalah apa yang disebut pengembang sebagai "pelapisan emas" - mengemas fungsionalitas yang menurut kami akan digunakan seseorang meskipun pengguna akhir tidak pernah benar-benar memintanya. Ini seperti daging babi untuk produk perangkat lunak Anda - buang-buang waktu. "Jangan membangun stasiun luar angkasa saat yang mereka minta hanyalah Volvo." Jadi, perusahaan dengan bijak mulai meninggalkan daging babi dan menerapkan refactoring sebagai gantinya, hanya menambahkan fungsionalitas ketika ada kebutuhan yang jelas. Tapi ketidakpastian hidup bukanlah satu-satunya pendorong pengerjaan ulang, bukan?
Detail yang terlewat pada setiap tahap pengembangan fitur pada akhirnya akan membuang waktu dan uang. Berkolaborasi secara efektif di awal akan, seiring waktu, menghemat banyak pekerjaan ulang (menangani persyaratan yang terlewat, desain yang berpandangan sempit, dll.). Kita semua memiliki titik buta, dan kita semua membutuhkan mata ekstra. Banyak tim pengembangan menerima hal ini di bagian belakang selama peninjauan kode, tetapi lebih sedikit menggunakan energi untuk berkolaborasi sejak awal saat masalah dapat diselesaikan dengan murah dan setelah investasi minimal.
Berapa kali Anda telah menerapkan fitur dan menemukan kekurangan signifikan di dekat bagian akhir yang seharusnya tertangkap selama diskusi persyaratan / desain? Ini seperti mencoba mengemudi dari Atlanta ke Montgomery dan menyadari beberapa jam dalam perjalanan bahwa Anda secara tidak sengaja mengemudi ke Birmingham. Berapa banyak waktu yang dihabiskan untuk mencoba mendapatkan kode yang tepat hanya untuk membuka pasien lagi nanti karena persyaratan signifikan terlewat? Memanfaatkan kecerdasan kolektif tentu saja akan menghemat waktu dan uang, tetapi sebaliknya, pengembang sering kali mengerjakan fitur secara terpisah.
Berkerumun secara Tradisional
Pixabay
Pengerumunan tradisional berarti bahwa tim bekerja secara kolaboratif pada cerita dengan beberapa orang yang mengerjakan fitur kecil pada saat yang sama, memperpendek putaran umpan balik dan mengurangi waktu penyelesaian keseluruhan untuk fitur tersebut (mis. Membagi dan menaklukkan). Ini pada dasarnya berkerumun dalam setiap disiplin ilmu (pengembang backend, pengembang UI, dll.). Sebelum pengembangan dimulai, pengembang UI bekerja untuk mengidentifikasi tugas independen yang dapat dilakukan secara bersamaan. Mereka membahas poin antarmuka sehingga setiap orang tahu bagaimana bagian mereka cocok dengan keseluruhan. Anggota tim kemudian dapat melanjutkan untuk menyelesaikan tugas yang ditugaskan kepada mereka dan mengumpulkan semuanya di akhir selama integrasi. Komitmen yang sering dan tinjauan kode berkala membantu memastikan bahwa semuanya tetap pada jalurnya. Pendekatan ini membutuhkan kolaborasi antara pengembang,yang membantu menghasilkan hasil akhir yang lebih baik. Kami sering memprioritaskan waktu yang dihabiskan untuk menulis kode (kode apa pun) dari waktu yang dihabiskan untuk memastikan kami tidak menulis kode yang salah. Ketika Anda mempertimbangkan waktu yang berpotensi dihemat, nilainya menjadi jelas.
Dibebaskan
Pixabay
Pendekatan lain yang berharga untuk swarming adalah memfokuskan tim sejak awal melakukan mitigasi ketergantungan untuk memfasilitasi pengembangan bersamaan di seluruh disiplin ilmu. Pertimbangkan aliran pengembangan alami fitur UI. Penguji otomatisasi (SDET) bergantung pada UI yang berfungsi untuk diuji, developer UI bergantung pada API backend yang berfungsi, dan developer backend bergantung pada konfigurasi, update database, dan build / penerapan otomatis. Jadi, pengembang UI mungkin tidak memulai pekerjaan mereka sampai API selesai dan SDET mungkin tidak memulai pekerjaan mereka sampai fitur tersebut selesai. Setiap disiplin bekerja dalam isolasi, yang menghambat kolaborasi karena orang yang Anda butuhkan untuk berinteraksi sibuk mengerjakan hal lain.Tapi bagaimana jika Anda bisa mengurangi ketergantungan lebih awal dan mengizinkan semua disiplin ilmu bekerja secara bersamaan pada fitur yang sama?
Berikut beberapa contohnya:
1. Diterapkan UI Fungsional w / Stubs
Untuk membuka blokir SDET, pengembang UI dapat memberi mereka UI yang berfungsi yang berfungsi cukup untuk memungkinkan mereka menulis pengujian. Integrasi API backend dan gaya CSS masih bisa ditunda, karena kerangka kerja pengujian otomatis seperti Selenium tidak akan peduli jika hal-hal itu belum selesai. Itu semua bisa berupa asap dan cermin. Meskipun perubahan dapat terjadi yang menyebabkan beberapa pengerjaan ulang, manfaat memulai pengujian lebih awal lebih besar daripada risikonya.
2. API Backend yang Diterapkan (stubbed, data hard-code)
Menyediakan API backend yang dapat diuji oleh developer UI memungkinkan deteksi dini masalah integrasi antara front end dan API. Terkadang Anda mengetahui bahwa API yang disediakan tidak memenuhi kebutuhan developer front end. Seluruh panggilan bisa saja hilang, tanda tangannya mungkin salah, atau struktur datanya mungkin bermasalah. Jika ada sambungan terputus, sebaiknya Anda mengetahuinya lebih awal sebelum semuanya mengeras.
3. Buat versi aplikasi dan layanan baru HelloWorld.
Jika layanan baru diperlukan (misalnya layanan mikro), buat repo dan buat versi layanan "hello world". Hal ini memungkinkan resource developer untuk memulai tugas Jenkins dan skrip penerapan sebelum layanan benar-benar dikembangkan.
Pengoptimalan ini memfasilitasi putaran umpan balik awal di mana seseorang dapat mengatakan "Saya membutuhkan sesuatu yang berbeda" sebelum pengembangan selesai pada komponen yang memerlukan perubahan.
Membungkusnya
Sangat penting bagi kami untuk mencari cara mempersingkat waktu untuk memasarkan fitur yang sedang kami kerjakan. Bisnis tidak mendapat nilai dari memiliki sekumpulan fitur yang sedang dalam proses, dan developer sangat membutuhkan fitur untuk diimplementasikan dengan cepat sehingga kerusakan dapat diatasi sedekat mungkin dengan titik injeksi. Pengembang juga sangat perlu berinteraksi satu sama lain meskipun yang mereka benar-benar ingin lakukan hanyalah menulis kode. Ini lebih baik untuk semua orang yang terlibat, termasuk pengguna akhir yang hanya menginginkan produk yang lebih baik. Jika Anda tidak memberikannya, mereka akan pergi ke tempat lain untuk menemukannya.
Mengerumuni adalah alat yang sangat berharga di kotak peralatan organisasi Anda, jika orang meluangkan waktu untuk mempelajari cara melakukannya. Ini bukan kerangka kerja atau bahkan aktivitas — ini adalah pola pikir. Untuk setiap cerita pengguna, anggota tim mengajukan dua pertanyaan kepada diri mereka sendiri:
- Bagaimana kita mengatur tugas untuk cerita ini agar beberapa orang berkontribusi sekaligus?
- Apa minimal yang harus saya lakukan untuk membuka blokir seseorang yang menunggu saya?
Bagaimana jika tim Anda dengan cepat membangun fitur bersama-sama alih-alih membangun banyak fitur secara mandiri? Mereka benar-benar dapat menanggapi kebutuhan bisnis yang berubah dan memenuhi kebutuhan bisnis ketika bisnis membutuhkannya untuk dipenuhi. Pesaing akan takut pada Anda — pelanggan akan menyukai Anda. Itu adalah resep untuk bisnis yang sukses.
© 2017 Mike Shoemake