Dapatkah pengembangan perangkat lunak Agile digunakan dalam proyek yang ditentukan oleh kontrak?

14

Baru-baru ini saya melakukan percakapan dengan sesama pengembang tentang Pengembangan Perangkat Lunak Agile. Sementara saya memahami prinsipnya, tampaknya persyaratan yang terus berubah menciptakan potensi bagi proyek untuk berlangsung selamanya. Tapi, setidaknya di tempat saya bekerja, proyek harus mencapai penyelesaian karena itu adalah kontrak.

Artinya, iterasi pertama bisa memakan waktu berbulan-bulan, karena untuk beberapa proyek pelanggan tidak dapat menggunakan aplikasi yang tidak lengkap. Untuk beberapa proyek, saya pikir Anda perlu mendefinisikan selesai terlebih dahulu, maka Anda dapat memecahnya menjadi iterasi dan memperbaiki definisi Anda setelah setiap iterasi. Tetapi Anda harus selalu memiliki definisi ini.

Jika Pengembangan Perangkat Lunak Agile mencakup perubahan persyaratan, bagaimana Anda tahu di mana itu berakhir? Bagaimana Anda bisa menganggarkan untuk sebuah proyek ketika hasil akhirnya selalu berubah?

Apakah Pengembangan Perangkat Lunak Agile lebih tentang proses gesit, daripada produk gesit?

agile Verax
sumber
itu berakhir ketika Anda harus benar-benar memberikan sesuatu yang bekerja, daripada bermain-main. Pada titik itu Anda harus mulai memaksakan struktur, perencanaan, memperbaiki persyaratan dan tenggat waktu, dan mulai bekerja daripada bermain-main.
jwenting
Setiap iterasi tangkas menghasilkan produk yang berfungsi dan dapat dikirim yang dapat digunakan klien dan belajar lebih banyak. Ini berlangsung sampai mereka puas, yang sering terjadi lebih awal dari yang direncanakan. Ini menjamin bahwa produk selalu berfungsi dan memperhitungkan fakta bahwa perangkat lunak tidak pernah selesai tetapi berevolusi selamanya atau mati. Pilih saja suatu saat ketika Anda berpikir produk tersebut cukup baik dan berhenti di situ (untuk saat ini).
Martin Wickman
@ Martin Wickman: Saya mengerti ini, tetapi "produk yang dapat dikirim yang dapat digunakan klien" adalah masalahnya di sini. Jika ini masalahnya, iterasi pertama bisa memakan waktu berbulan-bulan, karena untuk beberapa proyek pelanggan tidak dapat menggunakan aplikasi yang tidak lengkap. Untuk beberapa proyek, saya pikir Anda perlu mendefinisikan selesai terlebih dahulu, maka Anda dapat memecahnya menjadi iterasi dan memperbaiki definisi Anda setelah setiap iterasi. Tetapi Anda HARUS SELALU memiliki definisi ini.
Verax
@Verax: Manifesto tangkas dibuat untuk mengelola perubahan. Jika proyek Anda tidak memiliki perubahan, maka gesit bukan untuk Anda. Akhir dari cerita.
Martin Wickman
2
@Verax: Anda harus mengklarifikasi pertanyaan Anda dan menambahkan lebih banyak konteks untuk itu. Komentar Anda menunjukkan ada lebih banyak pertanyaan. Ini juga jelas dari hasil penghitungan suara pada jawaban dan bahwa jawaban yang diterima tidak terkait dengan teks pertanyaan yang sebenarnya (dan bahkan mengatakan "dari komentar OPs ...").
Martin Wickman

Jawaban:

7

Dari Komentar OP, sepertinya dia menyukai saya bekerja untuk sebuah toko Konsultasi, di mana kami menyediakan layanan pengembangan untuk klien kami ... Saya pikir karena pada kerangka pikir inilah yang menyebabkan kebingungannya ... Jadi saya akan nyatakan fakta yang sudah diketahui tetapi tidak pernah dinyatakan.

Agile tidak kompatibel dengan pengembangan perangkat lunak yang ditentukan oleh kontrak.

  • Kontrak harus Keras, Anda membayar X kami lakukan Y. Anda ingin X + M Anda membayar kami Y + (M * N)
  • Kontrak HARUS memuaskan, (yaitu IE tidak terbuka berakhir) kalau tidak mereka tidak kontak hukum. (Ketika kontak terlibat, Anda harus melalui proses kontrol perubahan yang ketat.)

Banyak toko konsultan mengklaim Agile, mereka berbohong. Mereka hanya mengatakan itu karena Agile telah memperoleh status kata Buzz.

Agile bekerja paling baik untuk pengembangan internal di mana programmer penuh waktu, dan ada sedikit pembicaraan tentang anggaran. Hanya Time Frame dan Fitur.

Orang bodoh
sumber
Ketika saya belajar lebih banyak tentang ini, saya sampai pada kesimpulan yang sama. Kalimat terakhir Anda sepertinya benar sekali. Saya dulu bekerja untuk pemerintah dan pelanggan saya adalah agensi tempat saya bekerja, dan program harus dipertahankan selama bertahun-tahun selama ada karyawan yang menggunakannya. Saya bisa melihat gesit bekerja di sana. Sekarang saya mengembangkan sistem tertanam. Proyek berakhir ketika mesin bekerja (semua atau tidak sama sekali). Jika mesin bekerja sebagian, tidak dapat dijual - proyek gagal.
Verax
2
Sebenarnya sebuah toko konsultan yang saya bekerja selama beberapa tahun yang lalu sebenarnya memiliki sebuah makalah yang ditulis oleh seorang penganut tangkas yang menggambarkan bagaimana tangkas dapat dipasang ke dalam model layanan harga tetap.
mcottle
2
Saya harus tidak setuju dengan jawaban ini. Alasannya adalah bahwa jika Anda memiliki kontrak yang tidak terbuka, itu berarti Anda tidak ingin mengelola scope-creep (yang hampir selalu terjadi). Kontrak yang biasa saya lihat dimulai dengan: Anda membayar X, kami melakukannya Y. Mereka kemudian memiliki klausa yang menyatakan bahwa setiap perubahan ruang lingkup datang dengan harga tambahan. Selama Anda masih sangat awal tentang ruang lingkup notifyng creep (yang membutuhkan sumber daya dan waktu tambahan) maka pelanggan sebelumnya dapat bereaksi terhadap perubahan (mendapatkan persetujuan dan anggaran dari manajemen atas dll.). Maka proses manajemen itu sendiri menjadi gesit.
Spoike
Ini bukan tidak kompatibel jika kontrak untuk servis (menulis kode) sebagai lawan dari produk (perangkat lunak jadi). Agile memungkinkan untuk memperkirakan apa yang akan dilakukan di bawah anggaran apa, dan jika persyaratan berubah, anggaran juga harus berubah. Anda menginginkan fitur lain? Anda harus mengontrak 500 jam kerja lagi. Fitur creep juga harga creep, benar-benar memuaskan bagi pengembang, dan jika pelanggan bersedia membayar, siapakah kita mempertanyakan itu?
SF.
2
Ada kontrak lincah , jadi jelas jawaban ini salah menurut definisi.
Martin Wickman
20

Jika Anda berfokus untuk melakukan (apa yang Anda yakini) hal yang paling penting terlebih dahulu, maka proyek akan selesai ketika:

  • Anda telah menghabiskan uang yang Anda anggarkan.
  • Anda telah melewati waktu yang dianggarkan.
  • Anda tidak lagi ingin menambah atau mengubah apa pun.
  • Batch berikutnya dari perubahan prioritas tertinggi Anda tidak sebanding dengan biayanya.
Dale Emery
sumber
5
1. Tidak ada lagi uang - Pelanggan menghabiskan semua uang mereka untuk produk tidak berguna yang tidak lengkap. 2. Tidak ada lagi waktu - Pelanggan masih memiliki produk tidak berguna yang tidak lengkap. 3. Tidak ada yang ditambahkan - Ya benar! 4. Tidak layak - Pelanggan hanya menyerah pada proyek. --- Apa yang aku lewatkan? Ini tidak masuk akal bagi saya.
Verax
7
Untuk 1 dan 2: Jika Anda melakukan hal yang paling penting terlebih dahulu, maka ketika Anda kehabisan uang, Anda akan memiliki hal yang paling penting yang bisa Anda dapatkan dari uang tersebut. Serupa dengan waktu. Saya akui 3 jarang. Untuk 4: Berhenti bukan berarti pelanggan menyerah begitu saja. Ini mungkin berarti bahwa mereka memiliki hal-hal terpenting yang mereka inginkan dari ini, dan sekarang lebih suka melakukan hal-hal lain dengan uang mereka. Bagaimana Anda memutuskan kapan harus mengakhiri proyek lain? Kriteria apa pun yang Anda gunakan sekarang masih tersedia di proyek tangkas.
Dale Emery
1
Dale, terima kasih atas pemikiran Anda. Saya pikir ini hanya berfungsi jika pelanggan membayar untuk setiap iterasi secara individual dan menilai setiap iterasi sebagai produk itu sendiri. Saya tidak melihat bagaimana ini bisa bekerja dengan baik untuk produk dengan biaya tetap atau produk yang membutuhkan semua atau tidak sama sekali.
Verax
5
@Verax: Tidak ada yang namanya produk yang membutuhkan "semua atau tidak sama sekali". Selalu ada fitur yang hanya "menyenangkan untuk dimiliki" dan bug yang bersifat kosmetik daripada fungsional. Proyek biaya tetap adalah sukses jika hanya itu yang tersisa ketika uang habis. Metode tangkas mencoba memaksimalkan kemungkinan itu.
Michael Borgwardt
1
Tentu saja ada biaya untuk mengubah persyaratan. Jika Anda membangun sesuatu dalam satu iterasi, lalu ubah persyaratan untuk hal-hal itu di berikutnya, ada biaya untuk itu. Agile mengurangi biaya. Itu tidak menghilangkannya. Jika Anda memiliki anggaran, ingatlah anggaran saat memutuskan apakah akan menambah fitur baru atau mengubah yang sudah ada, karena tahu bahwa Anda selalu memperdagangkan salah satu dari yang lain. Anda belajar memprioritaskan dan memprioritaskan kembali, dan Anda mempelajari konsekuensinya.
Dale Emery
14

Anda berhenti ketika bisnis memutuskan mereka tidak ingin melakukan iterasi lagi. Anda akan berharap bahwa ini adalah setelah sejumlah besar nilai telah dikirimkan tetapi sebelum Anda terlalu jauh ke ranah pengembalian yang semakin berkurang.

Itu harus selalu didorong oleh "bisnis" apa pun artinya dalam keadaan Anda. Ini bisa menjadi manajemen senior dari sebuah toko pengembangan perangkat lunak atau sponsor bisnis aktual dalam lingkungan pengembangan in-house. Mereka akan memutuskan kapan biaya iterasi berikutnya melebihi manfaat dari fitur yang akan dikirimkan pada iterasi berikutnya.

mcottle
sumber
5

Tidak pernah, dan itulah keindahannya.

Proyek tidak pernah selesai . Anda mencapai rilis lain, tonggak sejarah lain, tetapi selama uang mengalir, selalu ada satu lagi fitur untuk ditambahkan, satu lagi untuk membuat lebih baik, satu lagi bug untuk memperbaikinya. Proyek akan mati ketika tidak lagi dibutuhkan, tetapi tidak akan pernah selesai. Berbeda dengan model Waterfall dengan persyaratan-> proyek-> produk-> akhir, ini adalah loop yang dapat berputar selamanya - selama Anda dibayar.

Bukan fitur bisnis yang sering disebutkan tentang teknologi ini, bukan?

SF.
sumber
2
Proyek air terjun tidak pernah benar-benar selesai, hanya lebih mungkin untuk dikirim bawa-atau-tinggalkan-itu dengan fitur-fitur penting yang hilang, membuat proyek baru yang mahal diperlukan.
Michael Borgwardt
4

Ada kesalahpahaman di sini: Agile tidak mendorong persyaratan proyek untuk berubah. Sebaliknya itu memungkinkan untuk perubahan tanpa menyia-nyiakan pekerjaan, atau mengorbankan bidang pembangunan yang penting.

Ada empat kendala mendasar untuk setiap proyek rekayasa; ruang lingkup, biaya, waktu dan kualitas. Waterfall berasumsi bahwa ini akan menjadi statis. Itu adalah asumsi yang salah; satu atau lebih SELALU ini berubah. Lingkup merayap, memangkas anggaran, dan "tidak diketahui tidak diketahui" lainnya SELALU mengganggu proyek, mengubah kendala. Waterfall tidak mengantisipasi ini, jadi ketika itu terjadi, proyek berubah dengan cara yang tidak diinginkan; fitur penting yang belum ditambahkan hilang, atau cepat dilakukan, atau rilis harus didorong kembali, atau biaya balon ketika PM melempar uang pada pengembang baru untuk masuk dan membantu menyelesaikan semuanya dengan benar.

Agile, sebaliknya, memungkinkan kendala untuk berubah, dan benar-benar mengharapkannya. Ini melakukan ini dengan melakukan pekerjaan dalam potongan kecil yang bisa digunakan, sesuai dengan prioritas pemilik, dan dengan demikian potongan tersebut idealnya segera berguna bagi pemilik proyek. Dengan demikian mengurangi eksposur ke yang tidak diketahui dengan tidak membuat rencana besar dalam jangka waktu di mana yang tidak diketahui besar. Jika timeline berubah, tim dapat ditambahkan, atau fitur yang kurang penting "dide-scoped", dan sistem yang telah dibangun oleh tim tidak terpengaruh.

Ini juga memberikan perkiraan yang lebih baik dari waktu dan biaya yang diperlukan untuk menghasilkan lingkup yang diberikan pada kualitas yang diperlukan. Orang-orang terkenal buruk dalam memperkirakan pekerjaan besar; dibutuhkan BANYAK pengalaman, dan BANYAK perhitungan di muka, untuk melakukannya dengan benar. Sebaliknya, orang umumnya adalah hakim yang baik atas apa yang dapat mereka lakukan dalam sehari, atau satu atau dua minggu. Itu dengan cepat menghasilkan kondisi mapan di mana Anda dapat memperkirakan waktu dan biaya pekerjaan yang tersisa untuk dilakukan berdasarkan kecepatan historis Anda, dengan akurasi yang cukup.

Sedangkan untuk menentukan titik akhir, Anda benar; proyek Agile BISA berlangsung selamanya. Namun demikian, SLDC tradisional juga; klien sering kembali dengan lebih banyak uang dan daftar keinginan pembaruan. Perbedaannya adalah bahwa tidak ada garis yang jelas antara "analisis", "desain", "pengembangan" dan "pemeliharaan" ketika melihat proyek secara keseluruhan; itu semua terjadi bata demi bata, sprint demi sprint. Jika suatu saat pemilik ingin menyebut proyek "selesai", mereka bisa, dan mereka akan memiliki jumlah total "batu bata" yang telah mereka bayar dalam "dinding" yang kokoh; itu mungkin tidak setinggi atau meluas sejauh yang mereka rencanakan, tetapi sudah ada di tempatnya, melakukan pekerjaan, dan dapat ditambahkan di kemudian hari dengan tingkat kehancuran minimum.

KeithS
sumber
Maaf, tetapi "Ini memungkinkan perubahan tanpa menyia-nyiakan pekerjaan," adalah kesalahan besar yang digunakan untuk meyakinkan manajemen betapa hebatnya itu. Tidakkah refactoring dan / atau mendesain ulang sistem untuk mengakomodasi perubahan tak terduga dianggap sebagai pekerjaan yang sia-sia? Di kamp air terjun itu, tampaknya tidak di kamp lincah. Juga, jika pelanggan hanya menginginkan pekerjaan yang membutuhkan waktu 2 minggu untuk menyelesaikannya, maka tidak masalah metodologi apa yang digunakan, orang dapat memberikan perkiraan yang baik. Apa yang benar-benar diinginkan pelanggan adalah berapa lama sebelum saya memiliki produk lengkap, di mana gesit tidak lebih baik daripada metode estimasi lainnya.
Dunk
1
Juga, Anda membuatnya terdengar seperti hal yang baik bahwa pemilik dapat memanggil dilakukan pada titik mana pun dan apa yang telah Anda selesaikan adalah apa yang didapatnya. IME, umumnya pelanggan ingin tahu bahwa dolar X-nya akan menyediakan seperangkat fitur tertentu sebelum ia menurunkan uang tunai. Saya tidak melihatnya sebagai keuntungan bahwa pelanggan menghabiskan setumpuk uang dan hanya mendapat setengah fitur yang mereka harapkan. Saya menganggap itu sebagai kegagalan pada bagian perusahaan berkembang meskipun mereka mungkin telah memberikan sesuatu yang mereka sebut berfungsi ....
Dunk
2
Bagaimana jika seorang pelanggan mengontrak sebuah rumah tetapi uangnya habis sebelum atapnya dipasang? Kamp lincah masih akan menyebut itu sukses. Tidak ada orang lain yang mau; khususnya pelanggan.
Dunk
1
Adapun untuk memperkirakan, tim memperkirakan apa yang dapat mereka lakukan dalam sprint, dan itu diekstrapolasi untuk membuat garis waktu untuk seluruh proyek. Sekali lagi, ini membantu melindungi pengembang dan klien. Anda dapat memasukkan apa pun yang Anda inginkan dalam kontrak, termasuk jumlah dan tanggal "untuk tidak melebihi". Itu bisa dinegosiasikan. Agile masih membantu, dengan menunjukkan kedua belah pihak dengan sangat cepat apakah kendala tersebut layak atau tidak. Dua minggu kemudian, jika sepertinya tidak akan selesai tepat waktu untuk mendapatkan uang, tim dapat ditambahkan, fitur-fitur dibatalkan, atau jadwal diperpanjang.
KeithS
1
Bagaimana jika itu melakukan hal yang sama di air terjun SLDC? Entah pengembangan akan berhenti dan klien mungkin mendapatkan basis kode dengan lubang fungsionalitas serius, atau mengantisipasi kekurangan uang / waktu, jadwal yang tersisa akan dijejalkan ke waktu yang tersisa. SELALU itu mengorbankan kualitas, dan pada akhir proyek semacam itu tim pengembangan digoreng. Juga, banyak pembengkakan biaya terjadi karena air terjun tradisional tidak menghasilkan produk sampai pengembangan selesai; yang membatasi kemampuan pelanggan untuk mengatakan "bukan itu yang saya inginkan".
KeithS
1

Itu berakhir setelah semua fitur diimplementasikan dan semua bug diperbaiki.

Jika tenggat waktu diperbaiki dan persyaratan juga ditetapkan. Maka ini tidak akan menjadi masalah. Tetapi jika tenggat waktu sudah ditetapkan, tetapi persyaratannya berubah, maka ada sesuatu yang harus Anda lakukan untuk melanjutkan proyek dengan sukses.

Harga tetap bagian 1, apa yang buruk?

Harga tetap bagian 2, Perbaiki dengan gesit!

CharithJ
sumber
Sulit untuk mengetahui kapan semua bug diperbaiki.
Martin Wickman
Mungkin "ketika semua bug yang dikenal yang layak diperbaiki diperbaiki"?
Dan Ray
@CharithJ, tautan Anda rusak. Apakah mereka masih tersedia di suatu tempat? Terima kasih.
TwainJ
1

Asumsi besar di balik pengembangan tangkas adalah bahwa persyaratan selalu berubah, apa pun metodologi yang Anda gunakan. Sekarang, tentu saja Anda dapat membuat dokumen persyaratan, membuat rencana untuk melaksanakannya, dan mengirimkannya pada akhirnya, dan sepertinya persyaratan Anda tidak berubah. Mereka mungkin tidak berubah dalam rencana Anda, tetapi dengan perubahan pasar dan pemahaman Anda dan pelanggan yang lebih baik tentang produk, persyaratan dalam hal apa yang diinginkan pelanggan akan berubah. Agile masuk dan menyarankan suatu proses yang tidak menyembunyikan perubahan-perubahan ini melalui jadwal tetap, tetapi malah membangun menanggapi perubahan yang tak terhindarkan ke dalam proses.

Ketika Anda selesai sekarang bergeser dari menyelesaikan jadwal tetap ke saat produk Anda berada di tempat di mana Anda dapat memberikan nilai bisnis yang cukup di mana pelanggan Anda dapat mengirim dan memasarkan perangkat lunak dalam keadaan saat ini. Sedang dikerjakan lebih terikat pada seberapa banyak nilai yang Anda berikan daripada bagaimana Anda mematuhi suatu jadwal.

Brian Geihsler
sumber
1
Para pendukung lincah membuat asumsi yang sangat keliru bahwa di dunia air terjun para pengembang menghilang setelah kontrak ditandatangani dan tidak pernah terdengar lagi sampai sebuah produk muncul. Cara kerjanya dalam kehidupan nyata adalah bahwa ada cukup banyak pos pemeriksaan dan banyak ulasan bahwa pelanggan dapat terlibat sebanyak yang mereka suka. Jika mereka tidak menyukai arah atau keputusan, mereka dapat meminta perubahan. Pada saat suatu produk dikirim, itu harus menjadi apa yang diinginkan oleh pelanggan sejauh pelanggan memilih untuk terlibat. Agile tidak memperbaiki ini untuk banyak proyek.
Dunk