Halo para Penduduk! Setiap perusahaan ingin mencapai efisiensi yang lebih besar dalam pengembangan perangkat lunak, karena hal ini secara langsung memengaruhi keuntungan. Sebagian besar literatur Agile ditujukan untuk perusahaan besar dengan pertumbuhan tinggi, tetapi bagaimana jika perusahaan Anda tidak berada di garis depan TI? Kabar baiknya adalah setiap organisasi dapat meningkatkan kinerja, dan buku ini akan membantu Anda menemukan jalur dan solusi spesifik untuk mendapatkan hasil maksimal dari Agile. “Saya bukan penginjil yang tangkas. Saya seorang pendukung dari apa yang berhasil dan penentang dari apa yang menjanjikan tetapi tidak membawa hasil. Dalam buku ini, metodologi Agile disajikan bukan sebagai gerakan yang membutuhkan kesadaran yang tinggi, tetapi sebagai seperangkat metode manajerial dan teknis khusus, yang efek dan interaksinya dapat dipahami oleh setiap pebisnis atau spesialis TI.Penggemar Agile mungkin mengkritik buku ini karena tidak mempromosikan praktik terbaik Agile. Tapi inilah intinya - penekanan pada metode praktis yang telah membuktikan keefektifannya. Sejarah Agile penuh dengan ide-ide yang telah berhasil diterapkan oleh beberapa peminat di beberapa organisasi, tetapi tidak dapat digunakan oleh orang lain, ”kata Steve McConnell. Buku baru karya Steve McConnell, penulis buku legendaris Code Complete dan Software Estimation, menyatukan pengalaman nyata ratusan perusahaan. Gunakan panduan sederhana dan langsung untuk praktik Agile yang modern dan paling efektif.yang telah berhasil diterapkan oleh beberapa peminat di beberapa organisasi, tetapi tidak digunakan oleh orang lain, ”kata Steve McConnell. Buku baru karya Steve McConnell, penulis buku legendaris Code Complete dan Software Estimation, menyatukan pengalaman nyata ratusan perusahaan. Gunakan panduan sederhana dan langsung untuk praktik Agile yang modern dan paling efektif.yang telah berhasil diterapkan oleh beberapa peminat di beberapa organisasi, tetapi tidak digunakan oleh orang lain, ”kata Steve McConnell. Buku baru karya Steve McConnell, penulis buku legendaris Code Complete dan Software Estimation, menyatukan pengalaman nyata ratusan perusahaan. Gunakan panduan sederhana dan langsung untuk praktik Agile yang modern dan paling efektif.
Eksekusi proyek yang lebih efisien
Di bab sebelumnya, kami melihat cara mengatur dan mendukung pengembang saat bekerja di Agile. Bab ini membahas cara mengatur dan memelihara proses pengembangan dengan benar saat bekerja di Agile.
Sebagian besar pengembangan perangkat lunak diatur ke dalam proyek. Organisasi menggunakan berbagai macam istilah untuk mendeskripsikan konsep yang berkaitan dengan proyek, termasuk produk, program, rilis, siklus rilis, fungsi, aliran nilai, alur kerja, dan banyak lagi. ...
Terminologi sangat bervariasi. Beberapa perusahaan percaya bahwa rilis identik dengan proyek. Yang lain berpikir rilis mengacu pada perkembangan progresif, jadi mereka berhenti menggunakannya. Yang lain lagi mendefinisikan konsep "fungsi" sebagai jumlah pekerjaan yang dirancang untuk 3–9 orang dan 1–2 tahun. Dalam bab ini, yang saya maksud dengan kata "proyek" adalah jenis pekerjaan yang terdaftar, yaitu pekerjaan sejumlah karyawan untuk waktu yang lama.
Prinsip utama: ukuran proyek kecil
Selama 20 tahun terakhir, kasus paling terkenal dari penerapan Agile yang sukses dalam proyek-proyek kecil. Selama 10 tahun pertama keberadaannya, Agile sangat memperhatikan untuk menjaga proyek tetap kecil, yaitu, 5–10 orang dalam sebuah tim (misalnya, 3–9 pengembang, pemilik produk, dan master scrum). Penekanan pada ukuran proyek kecil sangat penting karena proyek kecil lebih mudah ditangani daripada proyek besar, seperti yang ditunjukkan pada Gambar. 9.1.
Capers Jones telah mendalilkan selama 20 tahun bahwa proyek kecil lebih sukses daripada proyek besar [Jones, 1991; 2012]. Saya telah meringkas sebagian besar penelitian tentang keberhasilan proyek versus ukuran dalam buku saya Code Perfect [McConnell, 2004; SPb .: Peter, 2007] dan Software Estimation: Demystifying the Black Art [McConnell, 2006].
Proyek yang lebih kecil lebih aman karena beberapa alasan. Proyek besar membutuhkan keterlibatan lebih banyak spesialis, dan jumlah hubungan antara orang-orang dalam tim dan antara tim itu sendiri meningkat dalam perkembangan non-linier. Dan semakin kompleks hubungannya, semakin banyak kesalahan yang dibuat dalam interaksi. Kesalahan interoperabilitas menyebabkan kesalahan dalam persyaratan, desain, pengkodean - secara umum, kesalahan lainnya.
Akibatnya, semakin besar proyeknya, semakin banyak kesalahan yang dibuat (Gambar 9.2). Ini berarti tidak hanya jumlah total kesalahan yang bertambah, tetapi juga ada lebih banyak kesalahan dalam proyek-proyek besar!
Semakin tinggi tingkat kesalahan, semakin rendah keefektifan strategi deteksi cacat. Ini berarti jumlah cacat pada produk jadi meningkat secara tidak proporsional.
Ini juga membutuhkan lebih banyak upaya untuk menghilangkan kesalahan. Oleh karena itu, seperti yang ditunjukkan pada Gambar. 9.3, proyek yang lebih kecil memiliki produktivitas yang lebih tinggi per orang, tetapi semakin besar ukuran proyek, semakin banyak penurunan produktivitas. Fenomena ini dikenal sebagai skala biaya.
Hubungan terbalik antara ukuran dan kinerja ini telah diteliti dan diuji secara ekstensif selama lebih dari 40 tahun. Fred Brooks membahas biaya skala dalam pengembangan perangkat lunak dalam edisi pertama bukunya The Mythical Man-Month [Brooks, 1975; SPb .: Peter, 2021]. Pekerjaan Larry Putnam dalam memperkirakan biaya pengembangan perangkat lunak mengkonfirmasi pengamatan Brooks [Putnam, 1992]. Studi model biaya pengembangan (Cocomo) secara empiris mengkonfirmasi adanya skala biaya dua kali - dalam sebuah studi dari akhir 1970-an dan dalam studi yang diperbarui dari akhir 1990-an [Boehm, 1981; 2000].
Kesimpulannya adalah untuk memaksimalkan kemungkinan proyek Agile yang sukses, cobalah untuk menjaga proyek (dan tim) tetap kecil.
Tentu saja, tidak mungkin membuat setiap proyek menjadi kecil. Bab 10, “Melaksanakan Proyek Besar dengan Lebih Efektif,” menguraikan pendekatan untuk proyek besar, termasuk saran tentang cara menurunkannya.
Prinsip Utama: Sprint Pendek
Kesimpulan alami bahwa ukuran proyek kecil lebih disukai adalah sprint tidak boleh berlangsung lama. Anda mungkin berpikir bahwa proyek kecil sudah menjadi resep untuk sukses. Tetapi sprint singkat 1-3 minggu berkontribusi pada manajemen proyek yang sukses secara keseluruhan. Ini dijelaskan di beberapa bagian berikutnya.
Sprint yang lebih pendek mengurangi jumlah persyaratan menengah dan meningkatkan daya tanggap terhadap persyaratan baru
Di Scrum, persyaratan baru dapat ditambahkan di antara sprint. Tetapi setelah sprint dimulai, Anda tidak dapat menambahkan persyaratan hingga sprint berikutnya. Ini masuk akal jika sprint berlangsung selama 1–3 minggu.
Jika siklus pengembangan memakan waktu lebih lama, maka pemangku kepentingan akan terus menerus meminta untuk menambahkan persyaratan di sepanjang jalan, sehingga permintaan untuk menunda penambahan persyaratan tidak lagi dapat dibenarkan. Jika siklus dengan model pengembangan berurutan berlangsung selama enam bulan, maka meminta pemangku kepentingan untuk menunda penerapan persyaratan baru hingga siklus berikutnya berarti pengerjaan persyaratan hanya akan dimulai pada siklus berikutnya - yaitu, di awal siklus, persyaratan ini hanya akan ditambahkan, dan kemudian Anda perlu menunggu pengiriman produk di akhir ini. siklus. Rata-rata dibutuhkan 1,5 siklus, yaitu 9 bulan.
Sebaliknya, sprint Scrum normal berlangsung selama dua minggu. Artinya, satu pihak yang ingin menambah persyaratan baru harus menunggu rata-rata tiga minggu.
Meminta pemangku kepentingan untuk menunggu 9 bulan agar persyaratan diterapkan seringkali tidak tepat. Dan tiga minggu hampir selalu tepat. Artinya, tim Scrum bekerja dengan tenang, tanpa takut akan persyaratan baru di tengah-tengah sprint.
Sprint pendek memberikan respons yang lebih besar saat bekerja dengan klien dan pemangku kepentingan
Setiap sprint menghadirkan peluang baru untuk menampilkan perangkat lunak yang berfungsi, memvalidasi persyaratan, dan menghasilkan umpan balik dari pemangku kepentingan. Dengan sprint dua minggu standar, tim memberi diri mereka kesempatan untuk menjadi lebih cepat 26 kali setahun! Dengan siklus pembangunan tiga bulan, peluang ini hanya disajikan empat kali dalam setahun. Lima belas tahun lalu, proyek tiga bulan dianggap singkat. Hari ini, jadwal seperti itu berarti Anda tidak akan dapat dengan cepat menanggapi umpan balik dari pemangku kepentingan, pelanggan, dan pasar.
Sprint singkat membangun kepercayaan pemangku kepentingan
Saat tim memberikan hasil lebih sering, kemajuan menjadi lebih transparan, sehingga kemajuan terlihat bagi pemangku kepentingan, yang membangun kepercayaan antara mereka dan tim.
Sprint pendek membantu mempercepat perkembangan melalui siklus belajar dan beradaptasi.
Semakin tinggi tingkat iterasinya, semakin banyak kesempatan bagi tim untuk merefleksikan pelajaran yang didapat, menarik kesimpulan, dan menerapkan hasilnya ke metode kerja praktis. Alasan untuk area ini sama dengan untuk daya tanggap pelanggan: apakah lebih baik membiarkan tim Anda belajar dan beradaptasi 26 kali setahun, atau hanya empat kali? Sprint singkat membantu tim Anda berkembang lebih cepat.
Sprint pendek membantu mengurangi waktu eksperimen
Dalam konteks Masalah Kusut Cynefin, masalah tersebut harus diselidiki terlebih dahulu sebelum cakupan penuh pekerjaan dapat dipahami. Penelitian semacam itu harus dicirikan sebagai berikut: "Untuk mendapatkan jawaban atas pertanyaan ini atau itu, lakukan pekerjaan sesedikit mungkin." Sayangnya, Hukum Parkinson mengatakan bahwa pekerjaan memakan semua waktu yang tersedia. Dan sampai tim mengembangkan disiplin besi, solusi dari masalah ini, jika dialokasikan satu bulan untuk itu, akan memakan waktu tepat satu bulan. Tetapi jika hanya ada dua minggu, maka solusi paling sering dari masalah tersebut membutuhkan waktu dua minggu.
Sprint pendek memungkinkan deteksi biaya dan risiko secara tepat waktu
Sprint pendek memungkinkan Anda melacak kemajuan lebih sering. Setelah hanya beberapa sprint, saat mengerjakan tugas baru, "kecepatan" tim atau kecepatan kemajuan akan ditentukan. Kemampuan untuk memantau kemajuan pekerjaan membuatnya lebih mudah untuk memprediksi waktu rilis produk. Jika pekerjaan memakan waktu lebih lama dari yang direncanakan, ini akan menjadi sangat jelas hanya dalam beberapa minggu. Sprint pendek adalah alat yang ampuh untuk tetap mendapatkan informasi. Bab 20, "Prediktabilitas yang Lebih Baik", menjelaskan lebih detail tentang ini.
Sprint Pendek Meningkatkan Akuntabilitas Tim
Jika sebuah tim bertanggung jawab untuk memberikan fungsionalitas kerja setiap dua minggu, mereka tidak memiliki kesempatan untuk bekerja dalam kegelapan dalam waktu yang lama. Dia menunjukkan hasil pekerjaannya pada rapat tinjauan sprint dan membuat laporan kepada pemangku kepentingan setiap dua minggu.
Pemilik produk lebih sering melihat hasil kerja.
Pemilik produk menerima atau menolak pekerjaan, kemajuan pekerjaan terlihat jelas. Dengan demikian, tim lebih bertanggung jawab atas pekerjaan mereka.
Sprint Pendek Mendorong Akuntabilitas
Selama beberapa generasi, tim pengembang mengalami "bintang" yang terkunci di ruangan gelap selama berbulan-bulan, dan sama sekali tidak jelas apakah pekerjaan sedang berjalan. Dalam kasus Scrum, masalah ini sudah tidak ada lagi. Setiap orang bekerja untuk mendukung tujuan tim dalam sprint, sebagai tambahan, ada kebutuhan untuk stand-up setiap hari dan membicarakan tentang pekerjaan yang telah dilakukan kemarin - Anda tidak akan dapat mengunci diri lagi. Entah pengembang mulai bekerja sama, yang menyelesaikan masalah dengan satu cara, atau tidak tahan dengan kondisi dan meninggalkan tim, yang masih menyelesaikan masalah, meskipun dengan cara yang berbeda. Dari pengalaman saya sendiri, saya dapat mengatakan bahwa hasil mana pun lebih baik daripada jika seseorang bekerja tanpa laporan selama berminggu-minggu atau berbulan-bulan, dan pada akhirnya ternyata tidak ada yang benar-benar dilakukan.
Sprint Pendek Mempromosikan Otomasi
Karena tim sering melakukan rekonsiliasi, sprint singkat dapat mengotomatiskan tugas yang seharusnya berulang dan memakan waktu. Otomasi tersebar luas dalam perakitan, integrasi, pengujian, dan analisis kode statis.
Sprint yang lebih pendek lebih cenderung memberikan rasa kepuasan.
Tim yang memberikan perangkat lunak yang berfungsi setiap dua minggu lebih cenderung merasa puas dengan pekerjaan mereka dan juga lebih mungkin memiliki kesempatan untuk merayakan pencapaian mereka. Ini berkontribusi pada rasa profesionalisme yang menumbuhkan motivasi.
Sprint pendek. Ringkasan
Secara umum, keuntungan dari sprint pendek dapat diringkas sebagai berikut: "Kecepatan pengiriman dalam segala hal membantu mengatasi volume pekerjaan." Pengiriman fungsionalitas dalam batch kecil dan irama pendek membawa banyak keuntungan dibandingkan pengiriman fungsionalitas dalam batch besar dan irama panjang.
Rencanakan berdasarkan kecepatan tugas
Unit kesulitan cerita adalah ukuran dari ukuran dan kompleksitas tugas. Kecepatan adalah ukuran kemajuan berdasarkan seberapa sering tugas diselesaikan dan diukur dalam satuan tingkat kesulitan cerita. Penjadwalan berbasis kecepatan adalah pekerjaan perencanaan dan pelacakan berdasarkan unit kesulitan sejarah dan kecepatan kerja.
Penjadwalan dan pelacakan kecepatan bukanlah bagian dari tutorial Scrum, tetapi menurut pengalaman saya, saya pikir akan menjadi ide yang baik untuk memasukkannya. Selanjutnya, saya akan berbicara tentang bagaimana Unit Kesulitan Cerita dan Perkiraan Kecepatan diterapkan.
Memperkirakan Ukuran Product Backlog
Penilaian kesulitan digunakan untuk menentukan ukuran backlog produk. Ukuran masalah dalam product backlog biasanya diperkirakan dalam satuan kesulitan cerita, dan kemudian unit kompleksitas cerita ditambahkan untuk menghitung ukuran total product backlog. Ini harus dilakukan di awal siklus rilis dan saat pekerjaan ditambahkan atau dihapus dari backlog. Ini dilakukan sejauh tim perlu diprediksi. Lebih lanjut tentang itu di Bab 20, "Prediktabilitas yang Lebih Baik."
Perhitungan kecepatan
Jumlah pekerjaan yang diselesaikan oleh tim di setiap sprint dihitung dalam satuan kesulitan cerita. Jumlah Unit Tingkat Kesulitan Cerita yang dicapai di setiap Sprint mewakili kecepatan tim. Kecepatan dihitung berdasarkan hasil setiap sprint dengan menghitung rata-rata.
Perencanaan Sprint
Tim merencanakan ruang lingkup pekerjaan per sprint, juga diukur dalam satuan kesulitan cerita, berdasarkan pengamatan kecepatan tim.
Jika tim menyelesaikan rata-rata 20 Unit Kesulitan Cerita per sprint, dan di sprint berikutnya menetapkan tujuan untuk menyelesaikan 40 Unit Cerita, maka mereka perlu menghentikan rencana mereka. Jika seorang anggota tim akan berlibur atau beberapa anggota tim menghadiri acara pelatihan, tim harus merencanakan lebih sedikit Kesulitan Cerita per sprint daripada rata-rata yang mereka lakukan. Jika tim berhasil mencapai 20 unit tingkat kesulitan dari cerita tersebut berkat malam tanpa tidur dan bekerja pada akhir pekan, batasnya juga harus diturunkan. Jika tim Anda secara konsisten dan mudah mencapai tujuan sprint, coba jadwalkan lebih banyak Kesulitan Cerita daripada rata-rata. Bagaimanapun, tim membuat perencanaan berdasarkan kecepatan aktual mereka.
Pelacakan rilis
Berdasarkan kecepatan rata-rata, Anda dapat menghitung atau memprediksi jumlah waktu yang diperlukan untuk menyelesaikan tugas di product backlog. Jika product backlog memiliki 200 unit tingkat kesulitan, dan kecepatan rata-rata tim adalah 20 tingkat kesulitan unit per sprint, maka tim akan membutuhkan 10 sprint untuk menyelesaikan semua tugas di backlog. Saya akan menjelaskan lebih lanjut tentang cara kerjanya di Bab 20, "Prediktabilitas yang Lebih Baik."
Menghitung dampak perubahan dalam proses, komposisi tim, dan perubahan lainnya
Berdasarkan kecepatan, Anda dapat melacak dampak perubahan dalam proses, komposisi tim, dan perubahan lainnya. Secara spesifik hal ini dibahas dalam Bab 19, Meningkatkan Proses Menjadi Lebih Baik.
Prinsip utama: pengiriman produk dalam irisan vertikal
Agar sprint menjadi efektif, tim perlu mengembangkan kemampuan untuk sering mengirimkan sejumlah kecil fungsionalitas. Pendekatan desain yang memfasilitasi hal ini disebut "menggunakan irisan vertikal", yang berarti melakukan perubahan pada setiap lapisan arsitektural untuk mendapatkan kenaikan atau nilai.
Irisan vertikal mewakili fungsionalitas tumpukan yang lengkap, seperti menambahkan bidang ke laporan mutasi bank atau membuat konfirmasi transaksi pengguna satu detik lebih cepat. Masing-masing contoh ini biasanya membutuhkan seluruh tumpukan teknologi untuk dijalankan, seperti yang ditunjukkan pada Gambar 1. 9.4.
Irisan vertikal cenderung membantu pemangku kepentingan non-teknis lebih memahami, mengamati, dan mengukur nilai bisnis. Mereka memberi tim kemampuan untuk merilis rilis lebih cepat dan menyadari nilai nyata produk untuk bisnis, dan mendapatkan umpan balik nyata dari pengguna.
Tim yang menggunakan irisan horizontal berisiko terjerumus ke dalam hutan untuk beberapa sprint berturut-turut, mengerjakan cerita yang mencerminkan beberapa kemajuan, tetapi tidak memberikan nilai bisnis yang terlihat.
Tim terkadang enggan menggunakan irisan vertikal, biasanya karena efisiensi yang lebih rendah. Mereka akan berargumen, misalnya, bahwa lebih efisien untuk melakukan lebih banyak pekerjaan di lapisan logika bisnis, dan kemudian beralih ke lapisan antarmuka. Pendekatan ini disebut menggunakan irisan horizontal.
Dalam beberapa kasus, dari sudut pandang teknis, mungkin lebih efisien untuk bekerja pada lapisan horizontal, tetapi efisiensi teknis seperti itu, biasanya, mengarah pada pengoptimalan bagian individual produk, yang tidak sepenting mendapatkan fungsionalitas yang berharga. Berlawanan dengan klaim bahwa menggunakan irisan horizontal mengarah pada peningkatan efisiensi, perusahaan kami menemukan bahwa saat menggunakan irisan horizontal, banyak tim dihadapkan pada kebutuhan untuk melakukan koreksi yang signifikan.
Irisan vertikal memberikan umpan balik yang lebih ketat
Irisan vertikal memungkinkan Anda dengan cepat memberikan fungsionalitas kepada pengguna bisnis, yang membantu Anda mendapatkan umpan balik cepat tentang bagaimana fungsionalitas tersebut bekerja dengan benar.
Karena irisan vertikal memerlukan pengembangan ujung-ke-ujung, anggota tim dipaksa untuk bekerja sama dalam desain dan implementasi, yang memberikan umpan balik teknis yang berguna untuk seluruh tim.
Penggunaan irisan vertikal juga mendorong pengujian ujung ke ujung, yang membantu memastikan umpan balik yang ketat.
Irisan vertikal memberikan nilai bisnis yang lebih besar
Irisan vertikal lebih dipahami oleh pemangku kepentingan yang bukan teknis, dan ini mengarah pada keputusan yang lebih baik yang dibuat oleh bisnis tentang prioritas dan urutan implementasi fungsi baru dan yang direvisi.
Karena irisan vertikal memberikan peningkatan fungsional penuh, mereka sering memberikan kesempatan untuk menyajikan fungsionalitas kerja kepada pengguna, yang meningkatkan nilai bisnis.
Penggunaan irisan horizontal mengarah pada fakta bahwa pengembang mulai memandang arsitektur sebagai produk. Dan hal ini dapat mengarah pada aktivitas pemberian penghargaan yang sama sekali tidak diperlukan untuk penyampaian fungsionalitas, dan ke metode lain yang menyebabkan penurunan nilai.
Apa yang dibutuhkan tim untuk menggunakan irisan vertikal
Menyampaikan fungsionalitas dengan irisan vertikal bisa jadi sulit. Itu tergantung pada komposisi tim, bisnisnya, pengembangan dan kemampuan pengujiannya, yang mencakup keterampilan di seluruh tumpukan teknologi.
Tim mungkin juga perlu mengubah desain dan pemikiran implementasi mereka untuk bekerja dengan irisan vertikal, yang akan berbeda dari bekerja berdasarkan komponen atau lapisan horizontal. Beberapa tim kurang memiliki keterampilan desain untuk melakukan ini dan perlu mengembangkan (dan mempertahankan pengembangan) keterampilan untuk mengatasinya.
Terakhir, tim harus menyelesaikan pekerjaan mereka dalam irisan vertikal. Pemilik produk dan tim pengembangan harus menemukan pendekatan untuk menyempurnakan backlog sehingga hasilnya adalah potongan vertikal.
Prinsip Utama: Kelola Utang Teknologi
"Hutang teknologi" mengacu pada akumulasi pekerjaan berkualitas buruk di masa lalu yang memperlambat kecepatan pekerjaan saat ini. Contoh klasik adalah basis kode yang rapuh di mana setiap upaya untuk memperbaiki bug menghasilkan satu atau beberapa bug baru. Bahkan memperbaiki kesalahan sederhana memakan waktu dan memperbaiki kesalahan tambahan.
Hutang teknis dapat mencakup kode berkualitas rendah, desain berkualitas rendah, rangkaian pengujian yang lemah, pendekatan desain yang sulit, lingkungan pembuatan yang rumit, proses manual yang lambat, dan cara lain tim mengorbankan kinerja jangka panjang demi keuntungan jangka pendek.
Konsekuensi utang teknis
Hutang biasanya terakumulasi sebagai akibat dari tekanan untuk memprioritaskan rilis jangka pendek dengan mengorbankan kualitas. Pandangan holistik dari sumber daya yang diinvestasikan dan pengembalian yang diperoleh termasuk memperhitungkan dampak hutang teknis dari waktu ke waktu.
Tim teknis dan bisnis dapat memiliki alasan kuat untuk mengakumulasi hutang ini. Beberapa rilis cukup peka waktu untuk menjamin pekerjaan tambahan di kemudian hari karena keinginan untuk menyelesaikan pekerjaan lebih cepat saat ini.
Namun, model yang memungkinkan hutang teknis menumpuk dari waktu ke waktu tanpa rencana untuk mengatasi hutang tersebut pada akhirnya akan mengurangi kecepatan tim. Tim perlu mengembangkan rencana pengelolaan utang untuk mempertahankan atau meningkatkan kecepatannya.
Kruchten, Nord, dan Ozkaya telah mengembangkan diagram yang sangat baik tentang bagaimana utang teknis muncul, apa (kemungkinan) nilai bisnis yang dimilikinya, dan bagaimana hal itu pada akhirnya menjadi lebih sebagai liabilitas daripada aset (Gambar 9.5).
Saat bekerja dari awal, tim dapat menghindari akumulasi utang teknis sejak awal. Saat melakukan pekerjaan yang telah dimulai, tim seringkali tidak punya pilihan selain bekerja dengan hutang teknis yang sudah terakumulasi. Dalam semua jenis pekerjaan, jika tim tidak bekerja dengan baik dengan hutang teknis, kecepatan akan berkurang seiring waktu.
Melunasi utang teknis
Tim yang berbeda memiliki pendekatan berbeda untuk melunasi utang teknis . Beberapa tim, untuk melunasi hutang, membagikannya dalam bentuk saham untuk setiap siklus pengembangan (sprint atau rilis). Tim lain menambahkan hutang ke product backlog atau daftar gap dan memprioritaskan hutang dan sisa pekerjaan. Bagaimanapun, fitur utamanya adalah hutang teknis dikelola secara terbuka.
Jenis hutang dan cara mengatasinya
Tidak semua hutang teknis itu sama, dan terdapat klasifikasi yang berbeda. Saya menemukan kategori ini berguna:
- Hutang yang disengaja (jangka pendek). Hutang yang didapat dari pertimbangan taktis atau strategis, seperti merilis rilis yang sensitif waktu tepat waktu.
- Hutang yang disengaja (jangka panjang). Utang berasal dari pertimbangan strategis, seperti awalnya mendukung satu platform, bukan mendukung lintas platform.
- Hutang yang tidak disengaja (itikad buruk). Hutang yang terjadi secara kebetulan karena metode pembangunan yang berkualitas buruk. Hutang jenis ini memperlambat pekerjaan baik di masa sekarang maupun yang akan datang, sehingga harus dihindari.
- Hutang yang tidak disengaja (itikad baik). Hutang yang muncul secara tidak sengaja karena kesalahan alami dalam pengembangan perangkat lunak ("Pendekatan desain kami tidak bekerja sebaik yang kami rencanakan", atau "Versi baru platform menunjukkan kekurangan desain yang serius").
- Hutang yang diwariskan. Hutang diwarisi oleh tim baru dari basis kode lama.
Tabel 9.1 menunjukkan pendekatan mana yang direkomendasikan untuk menanggapi jenis hutang ini.
Manfaat membahas utang teknis
Dalam pengalaman saya, metafora "utang teknis" telah membantu dalam memfasilitasi diskusi antara profesional teknologi dan bisnis. Para profesional bisnis umumnya tidak tahu berapa biaya untuk melunasi hutang teknis, dan teknisi umumnya tidak mengetahui kepentingan bisnis. Dalam beberapa kasus, merupakan ide yang baik untuk sengaja membiarkan hutang teknis menumpuk, dan dalam kasus lain tidak. Hutang memfasilitasi pertukaran pandangan tentang pertimbangan teknis dan bisnis, membuatnya lebih bermakna, yang meningkatkan kualitas keputusan tentang kapan dan mengapa mengambil hutang dan kapan dan bagaimana membayarnya kembali.
Bangun struktur kerja Anda untuk menghindari kejenuhan
Pandangan purist dari Agile mengasumsikan durasi sprint yang sama (dikenal sebagai "irama bersama"). Jika tim mengatasi irama keseluruhan dengan baik, tidak ada gunanya membuat perubahan. Irama bersama memudahkan penghitungan kecepatan dan faktor lain saat merencanakan sprint.
Keluhan umum saat menerapkan Scrum adalah urutan sprint yang tidak ada habisnya menyebabkan kelelahan dan perasaan berlari di roda. Dengan perkembangan yang konsisten, ada kegagalan alami dalam kinerja, terutama antar disiplin ilmu, serta keseimbangan selama periode intensitas tinggi.
Sprint yang konstan tidak menyisakan waktu untuk istirahat jika setiap sprint memang berjalan dengan kecepatan sprint.
Salah satu penangkal kelelahan setelah sprint adalah mengubah durasi sprint sesuai kebutuhan. Cara sistematis untuk melakukannya adalah dengan menggunakan pola 6x2x1, enam sprint dua minggu, ditambah satu sprint yang berlangsung satu minggu, dengan total 13 minggu, yaitu tepat seperempat.
Alternatifnya adalah menggunakan sprint yang diperpendek setelah rilis besar, pada hari libur, dan pada waktu lain ketika kecepatan tim masih belum stabil. Selama sprint selama seminggu, tim mungkin mengerjakan infrastruktur atau alat, menghadiri acara persiapan atau tim, hackathon, mengerjakan hutang teknis, mengerjakan perbaikan yang terlalu besar untuk diselesaikan dalam sprint, atau sesuatu yang lain.
Panjang irama sprint yang bervariasi konsisten dengan konsep kecepatan berkelanjutan yang digunakan di Agile. Banyak penelitian Agile menyamakan kecepatan yang stabil dengan kurangnya malam hari dan akhir pekan gratis. Tapi saya pikir ini adalah penyederhanaan berlebihan yang mengabaikan perbedaan preferensi untuk kondisi kerja orang yang berbeda. Beberapa menyarankan 40 jam kerja seminggu sebagai langkah tetap, tetapi bagi yang lain itu jalan menuju kebosanan. Secara pribadi, saya melakukan sebagian besar pekerjaan terbaik saya dalam mode ledakan - 55 jam selama dua minggu dan kemudian 30 jam selama dua minggu berikutnya. Rata-rata, ini dapat bekerja sekitar 40 jam kerja per minggu, tetapi tim yang berbeda tidak selalu memiliki 40 jam kerja. Pemahaman tentang kecepatan tetap berbeda untuk setiap orang.
Pertimbangan lainnya
Pengembangan Perangkat Lunak yang
Tidak Disain Tidak semua pengembangan perangkat lunak diatur ke dalam proyek, bahkan dengan banyak definisi di awal bab ini. Terkadang ada situasi di mana satu orang biasanya bekerja, misalnya menangani panggilan dukungan teknis, menyelesaikan masalah rilis, membuat patch, dan sejenisnya.
Pekerjaan semacam itu, tentu saja, terkait dengan pengembangan perangkat lunak dan juga cocok untuk praktik tangkas. Mereka dapat dilakukan dengan lebih efisien, kualitatif, metodis melalui penerapan metode Agile praktis seperti Lean Manufacturing dan Kanban. Namun menurut pengalaman saya, perusahaan cenderung memiliki masalah yang jauh lebih sedikit dengan jenis pekerjaan ini daripada dengan pengembangan perangkat lunak di seluruh proyek, jadi buku ini berfokus pada mengerjakan proyek daripada pekerjaan ad-hoc.
Rekomendasi
Studi:
- Tinjau sejarah total proyek. Apakah pengalaman perusahaan Anda sejalan dengan persepsi umum bahwa proyek kecil lebih mungkin berhasil daripada proyek besar?
- Jelajahi portofolio proyek Anda. Manakah dari proyek besar Anda yang dapat dibagi menjadi beberapa proyek kecil?
- , . ? ?
- , .
- , .
- . ?
- .
- , , .
- .
- [ , 1975]. -. , , .
- [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
- [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
- [ ., 2019]. Managing Technical Debt. .
»Rincian lebih lanjut tentang buku dapat ditemukan di situs web penerbit
» Daftar Isi
» Kutipan
Untuk Habitants diskon 25% untuk kupon - Agile
Setelah pembayaran untuk versi kertas buku, sebuah e-book dikirim melalui email.