Berurusan dengan sprint yang gagal dan tenggat waktu


80

Banyak buku dan artikel Scrum mengatakan bahwa sprint yang gagal (ketika tim gagal menyelesaikan beberapa fitur dari Sprint Backlog) bukan sesuatu yang buruk, itu terjadi dari waktu ke waktu, dan itu sebenarnya dapat berguna jika tim belajar dari kesalahan mereka dan meningkatkan sesuatu di sprint berikut. Dan tim seharusnya tidak dihukum karena tidak menyelesaikan pekerjaan yang telah mereka lakukan.

Ini terlihat hebat dari sudut pandang pengembang, namun, katakanlah kita memiliki perusahaan perangkat lunak " Scrum-Addicts LLC " yang mengembangkan sesuatu untuk klien serius (" Money-Bags Corporation "):

  1. Manajer Scrum-Addicts menyarankan untuk membuat perangkat lunak untuk Money-Bags
  2. Mereka menyetujui daftar fitur, dan Money-Bags meminta untuk memberikan tanggal pengiriman
  3. Manajer Scrum-Addicts berkonsultasi dengan tim scrum mereka, dan tim mengatakan akan membutuhkan sprint selama 3 minggu untuk menyelesaikan semua fitur
  4. Manajer Scrum-Addicts menambahkan 1 minggu agar aman, berjanji untuk mengirimkan perangkat lunak dalam 1 bulan dan menandatangani kontrak dengan Money-Bags
  5. Setelah 4 sprint (batas waktu pengiriman), tim Scrum hanya dapat memberikan 80% fitur (karena tidak berpengalaman dengan sistem baru, kebutuhan untuk memperbaiki bug kritis pada fitur sebelumnya di lingkungan produksi, dll ...)
  6. Seperti yang disarankan Scrum, pada titik ini, produk tersebut berpotensi dapat dikirim, tetapi Money-Bags membutuhkan 100% fitur, sebagaimana disebutkan dalam kontrak. Jadi mereka melanggar kontrak dan tidak membayar apa pun.
  7. Scrum-Addicts berada di ambang kebangkrutan karena mereka tidak mendapat uang dari Money-Bags, dan para investor kecewa dengan hasilnya dan tidak mau lagi membantu perusahaan.

Jelas, tidak ada perusahaan perangkat lunak yang ingin berada dalam posisi Scrum-Addicts. Apa yang saya gagal mengerti tentang Agile dan Scrum adalah bagaimana mereka menyarankan tim harus berurusan dengan perencanaan dan tenggat waktu untuk menghindari situasi yang dijelaskan di atas. Jadi, untuk meringkas, saya punya 2 pertanyaan:

Siapa yang harus disalahkan?

  1. Manajer, karena itu tugas mereka untuk melakukan perencanaan yang tepat
  2. Tim, karena mereka berkomitmen untuk melakukan lebih banyak pekerjaan daripada yang mereka bisa
  3. Orang lain

Apa yang Harus Dilakukan?

  1. Manajer harus memindahkan tenggat waktu 2x (atau 3x) kali lebih lambat dari perkiraan tim asli.
  2. Anggota tim harus didorong untuk melakukan semua pekerjaan yang mereka lakukan untuk apa pun (dengan mengeluarkan penalti untuk sprint yang gagal)
  3. Tim harus membatalkan Scrum karena tidak sesuai dengan kebijakan tenggat waktu perusahaan
  4. Kita semua harus menghentikan pengembangan perangkat lunak dan bergabung dengan biara
  5. ???

31
Poin 3 di bawah "Harus dilakukan" mengasumsikan tidak menggunakan Scrum akan mengubah apa pun karena hanya memiliki 80% dari fitur yang siap dalam satu bulan. Itu konyol.
Doc Brown

7
@DocBrown, saya tidak bisa setuju itu konyol. Menjatuhkan beberapa kegiatan Scrum seperti retrospektif dan pertemuan demonstrasi dapat mempercepat pengembangan. Dan dalam hal kontrak yang solid ini dapat membantu mencapai tujuan akhir: memberikan sejumlah fitur pada akhir tenggat waktu.
Andre Borges

26
@AndreBorges Saran Anda untuk menjatuhkan retrospektif dan demonstrasi sama dengan menyarankan untuk mengeluarkan rem dari mobil. Tentu, rem hanya memperlambat Anda. Tapi itulah yang memungkinkan Anda untuk pergi sangat cepat.
Euforia

13
masalah yang sama masih di bawah sistem apapun - dicatat bahwa Anda dapat cukup banyak menggantikan scrum dengan setara air terjun satu dan perusahaan masih berjalan bust
jk.

6
Mungkin jika para manajer Scrum-Addicts itu lebih memperhatikan selama pertemuan "retrospektif" yang sial itu, mereka akan memiliki kesempatan untuk menginjak rem pada minggu 1 atau 2, alih-alih menonton proyek mengarah ke tebing, dan menginjak pedal gas. .
Dorus

Jawaban:


134

Saya melihat beberapa masalah manajemen mendasar dalam contoh Anda:

  • jika manajer Scrum-Addicts menandatangani kontrak "tenggat waktu keras", tetapi hanya menambahkan margin keselamatan 33% dalam situasi di mana "sistem baru terlibat", itu cukup ceroboh.

  • ketersediaan pengiriman setidaknya x% dari fitur setelah satu bulan bisa digunakan untuk menegosiasikan kontrak di mana pelanggan membayar uang setidaknya sebagian ketika ia hanya mendapatkan 80% dari fitur pada batas waktu. Kontrak all-or-nothing adalah sesuatu yang tidak menguntungkan vendor perangkat lunak maupun pelanggan - ini berarti tidak hanya 0 uang untuk vendor, tetapi juga 0 fitur untuk pelanggan. Dan metodologi pengembangan semua-atau-tidak sama sekali seperti "Waterfall" hanya akan memungkinkan Anda menulis kontrak seperti itu, pendekatan gesit menawarkan kemungkinan tambahan.

  • melihat hasil dari satu atau dua sprint pertama seharusnya membuat jelas bagi manajer bahwa tim tidak dapat memenuhi tenggat waktu. Jadi dia harus mengambil tindakan sebelumnya, dan memprioritaskan tugas dan fitur yang tersisa, atau mencoba bernegosiasi ulang dengan pelanggan sebelumnya. Sebagai contoh, manajer dapat mencoba untuk mengurangi ruang lingkup dari beberapa fitur yang tersisa, sehingga tim dapat memberikan semua fitur yang disebutkan dalam kontrak, tetapi masing-masing dari mereka dalam lingkup yang dikurangi.

Jika tugas ternyata memakan waktu lebih lama dari yang Anda pikirkan, tidak ada metodologi pengembangan yang akan menyelamatkan Anda dari itu. Tetapi pendekatan gesit seperti Scrum memberi manajemen lebih banyak peluang untuk mengendalikan apa yang terjadi dalam situasi itu. Jika mereka tidak memanfaatkan peluang itu, itu jelas kesalahan mereka, bukan kesalahan tim, bukan kesalahan "Scrum", dan bukan kesalahan pelanggan karena "ia tidak menerima ketangkasan".


47
+1 untuk "Kontrak semua-atau-tidak sama sekali bukanlah sesuatu yang tidak akan diuntungkan oleh vendor perangkat lunak maupun pelanggan" . Ini adalah hal utama tentang kontrak lincah.
guillaume31

5
Dan tentu saja 80% tidak baik untuk beberapa jenis proyek (pada akhirnya itu mungkin , meskipun tidak mungkin, gesit terlalu terbatas untuk membuat ketentuan untuk proyek-proyek tersebut). Jadi misalnya tidak ada gunanya memiliki 80% dari fitur untuk satelit Anda ketika Anda meluncurkannya, itulah sebabnya Anda tidak mengacaukan dengan kemungkinan pada proyek-proyek tersebut. Jika Anda gagal mengirim maka misi klien Anda akan gagal (atau ditunda), tidak ada yang dapat Anda lakukan dalam kontrak untuk mengubahnya.
Steve Jessop

6
@SteveJessop: Saya cukup yakin bahkan ketika Anda membangun hal yang sangat kompleks seperti perangkat lunak untuk satelit, ada prioritas berbeda untuk fitur yang berbeda, dan akan ada banyak fitur di mana ruang lingkup dapat bervariasi hingga tingkat tertentu. Tenggat waktu mungkin diperbaiki untuk situasi seperti itu, tentu saja, karena ketika Anda tidak mendapatkan roket ke ruang angkasa sampai Desember tahun depan, Anda mungkin tidak mendapatkan kesempatan kedua.
Doc Brown

6
Tetapi untuk contoh khusus ini ... tentu saja tidak ada yang akan mengirim cakrawala baru jika mereka gagal menyelesaikan kamera hardwaredriver. Tetapi bahkan untuk proyek pada skala itu saya berani bertaruh seseorang tidak akan pergi ke luar angkasa dengan setiap fitur yang mereka bayangkan.
Zaibis

6
mungkin membayar per tonggak atau fungsi juga bisa menjadi pilihan.
Bram

68

Salah satu pernyataan nilai " Manifesto untuk Pengembangan Perangkat Lunak Agile " adalah:

Kolaborasi pelanggan atas negosiasi kontrak

Fakta bahwa Scrum-Addicts LLC menegosiasikan kontrak alih-alih menjalin kolaborasi dengan pelanggan membuat saya mempertanyakan kelincahan mereka.

Satu hal yang jelas: Kelincahan harus diterima oleh SEMUA ORANG. Kelincahan tidak hanya untuk pengembang. Manajer dan pelanggan juga harus menerima nilai-nilai Agile Manifesto. Jika pelanggan tidak menerima kelincahan dan masih membutuhkan kontrak yang kaku dan kolaborasi minimal, maka jangan gunakan tangkas atau temukan pelanggan yang lebih baik.

Adalah kesalahan pelanggan mereka terkunci dalam gelembung kontrak mereka dengan pengembangan yang digerakkan oleh tenggat waktu.


9
@RubberDuck Belum ada metodologi manajemen proyek perangkat lunak yang memungkinkan fitur untuk diputuskan di muka, batas waktu yang ditentukan dan tidak terlalu mahal. Lingkup, Waktu, Uang; Ambil dua.
Euforia

8
@RubberDuck: Proyek ini sudah tidak gesit, karena persyaratannya ditetapkan. Dan perkiraannya hanya tiga minggu. Tidak ada yang buruk secara ajaib tentang air terjun yang membuatnya selalu terlambat, tidak bisa berurusan dengan persyaratan dan perubahan yang tidak jelas. Ya, saya akan menggunakan "air terjun" dalam kasus ini, atau lebih tepatnya "mari kita putuskan apa yang perlu dilakukan dan lakukan itu".
RemcoGerlich

3
@RemcoGerlich ironisnya, "mari kita putuskan apa yang perlu dilakukan dan lakukan itu" sangat gesit sendiri :-)
gbjbaanb

2
@RemcoGerlich ah, saya pikir Anda salah paham maksud saya: dalam tangkas itu tidak benar-benar tentang metode dev, tetapi kemampuan untuk melanjutkan pekerjaan, menggunakan apa pun yang Anda suka. Lagipula tentang kemajuan bukan prosedur. (mis. tim yang hanya melakukan Scrum tidak gesit, tim yang hanya melakukan gaya air terjun tetapi memodifikasinya agar sesuai dengan keadaan)
gbjbaanb

2
Saya setuju dengan Doc Brown di sini. Anda benar-benar dapat memiliki "batas waktu" tanpa mengatakan dengan tepat "untuk apa". Sangat masuk akal untuk mengatakan, misalnya, "Batas waktu kami adalah <tanggal tertentu>. Pada tanggal itu, kami akan mengirimkan apa yang telah kami lakukan." Ruang lingkup apa yang akan dikirimkan tidak tidak harus diatur dalam batu saat batas waktu dibuat. Pengembangan lincah adalah semua tentang mengelola ruang lingkup dan mengkomunikasikan kemajuan di dalam peningkatan kotak waktu, yang semuanya sebenarnya merupakan tenggat waktu mini sendiri.
Eric King

15

Siapa yang harus disalahkan?

Manajer, dept hukum, akuntan - pilih ...

Saya tahu contohnya agak dibuat-buat tetapi fakta bahwa perusahaan dapat pergi tanpa membayar sepeser pun jika mereka tidak 100% puas harus segera membunyikan lonceng alarm seperti mencampur air terjun dan pemikiran cerdas.

Pelanggan ingin memiliki kue dan memakannya - mereka senang menerima air terjun, air terjun mini, lincah, la-la-land selama mereka mendapatkan produk X sebesar $ Y berdasarkan tanggal Z.

Pengembangan tangkas benar-benar mengharuskan tim pengembangan dan pelanggan berada pada halaman yang sama dari sudut pandang metodologi. Berpikir perbedaan dalam budaya hanya akan muncul di cuci adalah angan-angan.


12

Proyek-proyek TI berurusan dengan yang tidak diketahui ; beberapa dari yang tidak diketahui ini bahkan tidak dikenal . Apa artinya?

Ambil contoh jembatan mainan untuk kereta api model Anda. Ada semua parameter yang Anda ketahui:

  • Anda tahu seberapa besar lembah itu

  • Anda tahu bahan pegunungan, ketinggian, stabilitas dll.

  • Anda tahu berapa banyak materi yang Anda butuhkan

  • Anda tahu dari "proyek" sebelumnya berapa lama Anda membangun hal serupa

Ada banyak variabel yang terlibat yang memengaruhi perhitungan Anda dalam menginvestasikan waktu luang dan uang. Tapi bisa dibilang tanpa pikir panjang, apakah sudah selesai pekan depan.

Ambil contoh ini selangkah lebih maju:

  • Katakanlah Anda tidak membangun jembatan untuk kereta api model Anda sendiri, sebaliknya Anda membangunnya untuk orang asing: pekerjaan Anda adalah membangun jembatan kereta api antara dua gunung

  • Katakanlah Anda hampir tidak memiliki informasi sebelum lanskap model

  • Informasi tentang bentang alam adalah, yaitu memiliki dua gunung, yang tampaknya tidak terlalu besar

  • Konsistensi gunung adalah antara batu dan jeli

  • Total biaya memiliki maks 10 $

  • Tempat kerja benar-benar gelap dan tidak ada peluang cahaya: Anda hanya memiliki 8 kotak yang cocok

  • Batas waktu adalah 3 jam

Itu akan menjadi analogi dengan proyek TI. Anda memiliki pengalaman dalam membangun jembatan dan mudah untuk berjalan di medan yang dikenal. Yang membuatnya sulit adalah kegelapan . Ada banyak hal yang sulit Anda prediksi: Ukuran gunung hanya diketahui setelah menyodok beberapa saat dalam kegelapan. Begitu juga konsistensi pegunungan. Dari situ Anda bisa membuat perkiraan berapa lama Anda dan berapa biayanya. Di sini yang tidak diketahui adalah hal-hal, yang tidak Anda ketahui pada awal proyek seperti medan beton dll. Tetapi ada hal-hal yang tidak dapat Anda ramalkan, bahkan dengan estimasi paling berpengalaman dan paling konservatif. Hal-hal ini adalah hal yang tidak diketahui yang menyebabkan sedikit kekacauan.

Setiap perusahaan IT harus tahu itu. Mereka harus berurusan dengan risiko proyek.

1) Ada beberapa cara untuk meminimalkan risiko (keuangan): kesepakatan dapat mencakup bahwa pelanggan membayar untuk setiap kenaikan kerja. Jadi setelah kenaikan 1 dikirimkan, tarif parsial harus dibayar. Selama Scrum-Addicts LLC memberikan, ada risiko keuangan minimal. Semakin banyak sasaran sprint yang direncanakan, semakin rendah risiko total setiap sprint. Itu berarti, jika Money-Bags Corporation menerima 80% dari kontrak, mereka setidaknya harus membayar 80% dari nilai kontrak. Jika mereka menolak untuk membayar setelah sprint yang gagal risikonya tidak setinggi menolak untuk membayar 100%.

2) Scrum-Addicts LLC memiliki masalah dengan pengembangnya

Manajer Scrum-Addicts berkonsultasi dengan tim scrum mereka, dan tim mengatakan akan membutuhkan sprint selama 3 minggu untuk menyelesaikan semua fitur. Manajer Scrum-Addicts menambahkan 1 minggu agar aman, berjanji untuk mengirimkan perangkat lunak dalam 1 bulan dan menandatangani kontrak. dengan Uang-Tas

Itu menunjukkan, bahwa a) pengembang tidak berpengalaman dengan scrum atau b) mereka melakukan scrum salah. Semakin lama tim bekerja dengan scrum, semakin baik perkiraan mereka. Jika tim membuat estimasi dan manajer menambahkan "penyangga" sebagai "keselamatan", manajer tampaknya tahu lebih baik daripada tim, yang merupakan pertanda buruk . Jika Anda memiliki tim yang berpengalaman, tidak perlu ada "manajer", tim tersebut sudah termasuk dalam estimasi. Idenya adalah, semakin banyak sprint yang tim telah bekerja bersama, semakin banyak tim tahu kekuatan dan kelemahannya dan memiliki beberapa metrik untuk membuat perkiraan yang realistis. Tentu saja ada - sebagaimana telah disebutkan - yang tidak diketahui tidak diketahuiyang cenderung membuat estimasi sulit; atau setidaknya tidak tepat. Namun dalam jangka panjang, perkiraan tersebut akan menjadi lebih baik dan lebih baik.

Siapa yang harus disalahkan?

1) Manajemen

Seperti yang dikatakan di atas: jelas ada kegagalan dalam manajemen risiko. Jika perusahaan berada di ambang kebangkrutan, perusahaan layak mendapatkannya. Jika Anda bekerja di perusahaan seperti itu: pergi!

2) Tim

Bahkan jika manajemen benar-benar bodoh, tim seharusnya berbicara menentang proyek semacam itu. Manajer yang baik harus mengetahui risikonya; tetapi pengembang yang baik harus menunjukkan risiko. Dan yang terpenting: Tim harus melaporkan lebih awal jika ada yang gagal.

Apa yang Harus Dilakukan?

Sekarang: Bawa Tas Uang ke pengadilan

Untuk masa depan: Jangan membuat kontrak seperti itu

Scrum tidak bisa disalahkan atas kegagalan manajemen. Scrum dikembangkan berdasarkan pengalaman banyak proyek TI yang gagal. Itu tidak dapat mencegah kegagalan, juga tidak bisa menyembuhkan ketidakmampuan tim atau manajemen. Ide dasarnya adalah:

  • untuk menyusun cara komunikasi (siapa yang berbicara kepada siapa kapan tentang apa)

  • untuk mendorong kegagalan pelaporan pengembang lebih awal

  • untuk membagi masalah dalam tugas dan subtugas

  • untuk menyusun waktu dan kapasitas (siapa yang bekerja saat apa)

  • untuk mendistribusikan tugas selama slot waktu

  • buat yang tak terduga sedikit lebih mudah diprediksi (perencanaan poker)

atau keseluruhan: untuk meminimalkan risiko.

Scrum adalah alat seperti palu. Apakah itu alat yang baik tergantung pada pengetahuan Anda bagaimana menggunakannya. Namun terkadang obeng lebih cocok. Terserah kamu.


1
Ada aspek lain dari Scrum yang sangat penting untuk memahami mengapa proyek ini gagal: scrum mencakup kegagalan . Diharapkan beberapa sprint pertama dari tim atau proyek baru akan gagal. Melalui proses scrum retrospektif, tim akan memperbaiki dirinya sendiri dan dalam jangka panjang menjadi akurat dalam perkiraan mereka, tetapi hanya selama mereka tetap tim yang sama mengerjakan proyek yang sama. Ketika salah satu dari perubahan itu, Anda harus sekali lagi mengharapkan beberapa kegagalan karena variabel yang mendasarinya bergeser.
Cronax

9

Pertama, "Siapa yang harus disalahkan?" adalah pertanyaan yang salah untuk ditanyakan. Menugaskan menyalahkan itu menyenangkan dan semuanya, dan mungkin akan membuat semua orang kecuali orang yang disalahkan merasa lega (dalam arti "hei, itu bukan salah saya, kata bos!"), Tetapi itu bukan penggunaan waktu Anda secara produktif. , dan dapat benar-benar kontraproduktif dan menyebabkan penurunan semangat kerja karyawan.

Cara yang lebih baik untuk melihatnya adalah "Apa yang menyebabkan keterlambatan?". Apakah itu kurang pengalaman dalam teknologi? Bug penting yang tidak terdeteksi dalam pengujian / QA? Kurang pengujian / QA? Terlalu optimis dalam estimasi? Tidak memperhitungkan estimasi tim yang tidak terlalu optimis? Seseorang tertabrak bus? Apa pun penyebabnya, pertanyaan berikutnya adalah "Bagaimana kita memastikan ini tidak terjadi lagi?". Dalam beberapa kasus (mudah-mudahan jarang), jawaban untuk itu mungkin "singkirkan begitu-dan-begitu", tetapi jika Anda mulai dari "Saya perlu menghukum siapa pun yang bertanggung jawab", Anda tidak akan melihat mayoritas kasus di mana itu bukan solusi yang tepat.

Di dalam proyek, Anda sudah tenggelam. Tenggat datang dan pergi, Anda memperingatkan pelanggan segera setelah itu jelas itu akan tergelincir (karena Anda melakukan itu, kan? Jika tidak, itu bagian dari masalah), dan sekarang itu harus ditangani tetapi dijabarkan dalam kontrak (itu sebenarnya dijabarkan dalam kontrak, kan?). Secara umum, itu harus melibatkan negosiasi dengan pelanggan bagaimana Anda akan memberikan apa yang hilang. Banyak orang suka menganggap kontrak sebagai sesuatu yang tidak dapat diubah, tetapi dihadapkan dengan salah satu dari) membatalkan kontrak dan tidak memiliki apa yang Anda beli, b) menggugat perusahaan karena melanggar kontrak dan menghabiskan banyak uang di pengadilan, dan c) menegosiasikan cara mendapatkan produk mereka dengan jumlah masalah sesedikit mungkin, sebagian besar perusahaan memilih c.

Ke depan, sebelum mengutip harga / tenggat waktu untuk pelanggan, Anda harus menganalisis risiko yang terlibat dalam tenggat waktu yang tergelincir atau pembengkakan biaya (apa penyebab yang mungkin untuk hal semacam itu? Penyebab apa yang dapat Anda mitigasi, dan yang tidak dapat dan hanya bisa Anda mitigasi harus merencanakan), dan menggunakan informasi itu untuk membantu memutuskan apa yang akan Anda janjikan. Jika ini adalah kasus di mana 100% atau tidak sama sekali, Anda pasti akan mengutip harga yang lebih tinggi dan tenggat waktu yang lebih lama, karena risikonya lebih tinggi.

Anda akan melihat bahwa saya tidak berbicara tentang Agile dalam seluruh jawaban ini. Itu karena (saya akan melupakan keterlibatan pelanggan dalam Scrum sebentar, meskipun itu sangat, sangat penting) pada titik ini tidak terlalu penting. Anda akan dihadapkan dengan masalah ini di Agile, Waterfall, atau proses pengembangan apa pun yang Anda gunakan. Ya, Agile seharusnya membantu Anda mengelola risiko dengan lebih baik, dengan membiarkan Anda melihat apakah mereka telah menjadi masalah aktual sebelumnya, dan melibatkan pelanggan dalam proses itu sendiri sehingga mereka selalu mendapat informasi, tetapi itu bukan obat mujarab.


3
-1 Titik lincah adalah bahwa banyak risiko tidak dapat diprediksi. Sebagai contoh, mereka menambahkan buffer 1 minggu jika ada masalah. Anda selalu dapat tiga kali lipat dibutuhkan, tetapi kemudian Anda kalah melawan pesaing yang tidak melakukannya. Agile harus mengadopsi mentalitas "Ini dilakukan ketika sudah selesai". Yang tidak sesuai dengan kontrak dan tenggat waktu seperti yang dijelaskan.
Euforia

3
@ Euforia Saya tidak bisa sepenuhnya setuju. Ya, intinya Agile adalah bahwa banyak risiko tidak dapat diprediksi, dan untuk itulah buffernya, saya akan berikan itu. Namun, itu tidak berarti bahwa semua risiko tidak dapat diprediksi, juga tidak berarti bahwa Anda harus pergi ke proyek yang buta, tanpa mempertimbangkan risiko yang dapat Anda prediksi.
Iker

2
@Iker Yang satu tidak menghalangi yang lain, tetapi poin dari menjadi benar-benar gesit dalam proses pengembangan adalah bahwa "Sudah selesai ketika sudah selesai" mentalitas untuk pelanggan dan tim. Tentu, selalu ada beberapa risiko yang dapat Anda prediksi, tetapi Anda tidak akan pernah berhasil memprediksi semua risiko yang mungkin terjadi dan dampak apa yang akan terjadi pada kemajuan Anda. Kecuali Anda bisa melihat masa depan. Karena itulah pekerjaan Agile memerlukan kontrak khusus, di mana Anda setuju bahwa "kami akan terus bekerja sampai uangnya habis, atau salah satu pihak tidak lagi mau atau tidak mampu, atau semua kebutuhan pelanggan terpenuhi"
Cronax

ok, saya membatalkan ini untuk penolakan langsung atas kesalahan sebagai sebuah konsep. Saya setuju bahwa menyalahkan adalah komponen yang tidak produktif yang merupakan gangguan dari kesuksesan. Mari kita ubah pertanyaannya. Mungkin kita bisa membuatnya "bagaimana kita bisa menangani ini"? "Bagaimana kita bisa mengubah ini menjadi kesuksesan bagi kita?" "Perubahan apa dari setiap pihak yang bisa menghasilkan hasil positif?" saya mungkin baik-baik saja dengan mengubah "menyalahkan" menjadi "bertanggung jawab", tetapi karena setiap proyek dengan vendor dan pelanggan adalah interaksi tim, bukankah seluruh 'tim' lingkup global yang bertanggung jawab? pertanyaan tentang siapa yang harus disalahkan kemudian menjadi retoris.
Joshua K

4

Pertama, ini adalah masalah dengan metodologi pengembangan apa pun. Setidaknya dengan sistem pengembangan berulang Anda memiliki sesuatu untuk ditunjukkan kepada pelanggan di akhir tenggat waktu, yang mungkin cukup untuk mendapatkan perpanjangan untuk menyelesaikan produk (bahkan jika pelanggan tidak membayar lagi!).

Namun, ada beberapa kasus di mana tenggat waktu adalah tenggat waktu. Bayangkan Anda sedang menulis permainan dan harus dilepaskan tepat pada waktunya untuk liburan Natal. Melakukan kesalahan itu telah membuat banyak perusahaan bangkrut!

Untuk metode gesit yang harus menyelesaikan sejumlah fitur pada tanggal tertentu, scrum mungkin bukan metode terbaik untuk digunakan (karena saya selalu menemukan bahwa scrum membuat dev menjadi lebih lambat dan tidak memungkinkan cukup kelincahan untuk mengubah proses ketika dibutuhkan.

Apa yang Anda butuhkan, terlepas dari metodologi, adalah untuk mengatur simpanan fitur yang diperlukan untuk memberikan visibilitas kemajuan. Kemajuan berdasarkan per-sprint tidak cukup baik, Anda tidak akan tahu apakah Anda memenuhi target akhir. Jadi metodologi gaya kanban akan lebih baik: atur semua fitur di sebelah kiri, dan kerjakan melalui sistem untuk menunjukkan kemajuan hingga selesai.

Itu memusatkan pikiran orang pada apa yang masih perlu dilakukan dengan cara yang tidak ditangani Scrum, dan memungkinkan orang selain tim pengembang untuk melihat apa yang tersisa dan apakah Anda cenderung memenuhi target (dan dengan demikian mengelola harapan pelanggan lebih awal , atau atur bonus lembur itu sebelum dibutuhkan).

Scrum adalah sistem yang membuat selamanya, mendefinisikan dan memperbaiki sesuatu. Sama sekali tidak cocok untuk pengembangan semacam ini. Orang lain dapat mengelola sytle ini dan masih mempertahankan konsep pengembangan berulang, Kanban adalah satu seperti itu, Crystal yang lain. Tetapi yang penting untuk dipahami adalah bahwa jika Anda mengikuti Scrum dengan religius, Anda tidak gesit. Setiap sistem Agile sejati harus dapat berubah untuk mengatasi masalah-masalah khusus ini, itu sebabnya ia disebut gesit pada awalnya, ini tentang menyelesaikan apa yang perlu dilakukan, dan jika tenggat waktu tetap adalah bagian dari itu, maka Anda harus menjadi faktor dalam cara Anda bekerja.


6
"Game ready for christmas" bisa menjadi posterchild untuk Scrum. Kirimkan 80% yang telah Anda selesaikan, jual sisanya sebagai DLC. Itu bukan situasi hipotetis yang dibahas di sini, di mana batas waktu menetapkan waktu dan ruang lingkup, dengan penalti 100% untuk pengiriman sebagian.
MSalters

2
@Pemutar yang Anda asumsikan permainan berfungsi sama sekali, bahwa 80% mungkin tidak ada fitur yang dapat ditambahkan nanti, tetapi melanggar fungsionalitas atau menabrak bug. Itu tidak harus berupa permainan, bisa berupa perangkat lunak apa pun yang perlu dikirim untuk batas waktu yang pasti, dan tidak berubah (karena bahkan Apple tidak dapat menunda Natal!)
gbjbaanb

6
Itulah premis dasar Scrum! Fungsionalitas yang rusak tidak masuk hitungan. Jika Anda berasal dari latar belakang Waterfall, Anda akan menemukan bahwa Scrum karenanya memprioritaskan perbaikan bug daripada menambahkan fitur baru. "80% selesai" berarti ada level yang hilang, bos yang hilang, dll.
MSalters

1
@ gbjbaanb Dengan alasan itu, sesuatu bisa dilakukan 99,9% tetapi masih tidak berfungsi karena langsung crash saat startup.
user253751

@ Imibis tapi itu benar. Hal-hal seperti gim cenderung tidak meninggalkan fitur sampai akhir, sebagian besar gim harus diimplementasikan agar keseluruhan bisa berfungsi - selagi Anda bisa mengeluarkan beberapa fitur (dan saya tahu gim yang telah melakukan ini) mereka tidak menambahkan fitur secara bertahap. Jadi bos yang hilang akan menjadi permainan yang rusak. Saya hanya memilih game sebagai contoh karena cenderung (terutama sebelum pengiriman internet) sebagai contoh tenggat waktu yang sulit.
gbjbaanb

4

Paradigma pembangunan tidak selaras dengan paradigma kontrak. Idealnya, cara kontrak ditulis akan berubah, tetapi itu tidak mungkin terjadi. Namun, bahkan jika Anda menjatuhkan scrum, Anda masih akan memiliki kejutan dan tenggat waktu yang terlewat (hanya saja Anda kemungkinan besar nanti karena Anda melakukan semua desain di muka dan itu semua salah !!).

Dengan atau tanpa perubahan bagaimana kontrak ditulis, Anda mengirimkan apa yang sudah Anda dapatkan . Kemudian penuhi kontrak dengan memakan siklus waktu pengembangan untuk menyelesaikan fitur yang belum selesai.

Apakah baik bahwa Anda gagal memberikan semua yang Anda janjikan pada hari yang Anda janjikan? Tidak, tetapi pelanggan Anda akan jauh lebih bahagia jika Anda dapat mengirimkan sesuatu yang bekerja tepat waktu, kemudian mengirimkan sisanya dengan cepat daripada jika Anda hanya terlambat dan tidak punya apa-apa untuk diberikan kepada mereka.


3
Ya, kadang-kadang pelanggan lebih bahagia jika tim memberikan setidaknya sebagian fitur kerja, tetapi tidak selalu demikian. Saya berbicara tentang kasus ketika (1) produk tidak berguna bagi pengguna akhir kecuali 100% fitur diterapkan (misalnya, memerlukan sertifikasi mahal yang perlu dilakukan hanya ketika semuanya selesai) atau (2) pelanggan adalah perusahaan sekolah tua dengan pendekatan "serba bisa": jika produk tersebut tidak 100% siap kami menganggapnya gagal, putuskan kontrak dan tembak semua orang yang bertanggung jawab.
Andre Borges

2
Pelanggan akan selalu lebih senang melihat kemajuan dalam cara kerja perangkat lunak. Sertifikasi mahal dapat menunggu hingga produk memenuhi kepuasan mereka. Melepaskannya ke klien tidak berarti mereka harus merilisnya ke publik. Dalam kasus 2, benar-benar tidak ada pilihan selain meminta tim hukum / penjualan Anda menulis kontrak yang lebih baik. Jujur saja, masalah Anda akan sama, jika tidak lebih buruk, dengan air terjun di sana.
RubberDuck

2
@AndreBorges Tentunya pelanggan akan lebih senang melihat 80% fitur daripada melihat 0% fitur? Paling tidak dengan cara itu, pelanggan tahu produknya banyak dilakukan.
user253751

@immibis, jika Anda mengatakan itu, itu berarti Anda sudah cukup senang untuk menghindari beberapa pelanggan 'aneh' dalam pekerjaan Anda. Ada beberapa perusahaan besar yang terkait dengan pemerintah yang canggung yang memberlakukan persyaratan kontrak yang tidak terlalu masuk akal, tetapi jika Anda menginvestasikan semua sumber daya Anda ke dalam tugas mereka dan berhasil, mereka membayar uang serius yang dapat mengangkat perusahaan kecil Anda terlalu tinggi. Namun, jika Anda gagal, Anda mungkin menemukan diri Anda mencari pekerjaan baru. Ini adalah risiko yang bersedia diambil sebagian orang.
Andre Borges

2
Persis! Karena birokrasi internal dan kurangnya staf manajemen yang berpengalaman, kadang-kadang lebih mudah bagi perusahaan besar untuk mempertimbangkan tenggat waktu yang gagal sebagai "eksperimen yang tidak berhasil" dan membatalkan proyek sama sekali, daripada melakukan upaya lebih lanjut dalam mencoba berkomunikasi dan menegosiasikan ulang ruang lingkup. Sedih, tapi benar :(
Andre Borges

1

Banyak buku dan artikel Scrum mengatakan bahwa sprint yang gagal (ketika tim gagal menyelesaikan beberapa fitur dari Sprint Backlog) bukan sesuatu yang buruk, itu terjadi dari waktu ke waktu, dan itu sebenarnya dapat berguna jika tim belajar dari kesalahan mereka dan meningkatkan sesuatu di sprint berikut. Dan tim seharusnya tidak dihukum karena tidak menyelesaikan pekerjaan yang telah mereka lakukan.

Cara Anda "menghukum" perilaku semacam ini adalah dengan membatasi jumlah pekerjaan yang tidak dapat diselesaikan orang pada sprint berikutnya. Peluang untuk mengerjakan hal-hal keren menghilang. Hadiah untuk melakukan pekerjaan yang baik adalah lebih banyak pekerjaan.

Ini terlihat hebat dari sudut pandang pengembang, namun, katakanlah kita memiliki perusahaan perangkat lunak "Scrum-Addicts LLC" yang mengembangkan sesuatu untuk klien serius ("Money-Bags Corporation"):

Manajer Scrum-Addicts menyarankan untuk membuat perangkat lunak untuk Money-Bags. Mereka menyetujui daftar fitur, dan Money-Bags meminta untuk memberikan tanggal pengiriman. Manajer Scrum-Addicts berkonsultasi dengan tim scrum mereka, dan tim mengatakan akan memakan waktu 3 minggu. sprint lama untuk menyelesaikan semua fitur Manajer Scrum-Addicts menambahkan 1 minggu untuk aman, berjanji untuk mengirimkan perangkat lunak dalam 1 bulan dan menandatangani kontrak dengan Money-Bags Setelah 4 sprint (batas waktu pengiriman) tim Scrum hanya dapat memberikan 80% fitur (karena tidak berpengalaman dengan sistem baru, kebutuhan untuk memperbaiki bug kritis pada fitur sebelumnya di lingkungan produksi, dll ...) Seperti yang disarankan Scrum, pada titik ini, produk berpotensi dapat dikirim, tetapi Money-Bags membutuhkan 100% fitur, sebagaimana disebutkan dalam kontrak. Jadi mereka melanggar kontrak dan tidak membayar apa pun.

Scrum-Addicts berada di ambang kebangkrutan karena mereka tidak mendapat uang dari Money-Bags, dan para investor kecewa dengan hasilnya dan tidak mau lagi membantu perusahaan.

Jika pada hari Senin saya bertaruh Anda $ 100 hujan akan turun pada hari Kamis dan hujan tidak turun sampai hari Jumat Anda berhak mengambil uang saya. Jika, alih-alih kesempatan untuk bertaruh, yang Anda inginkan adalah ramalan cuaca maka kami membutuhkan kontrak yang memungkinkan saya memberi Anda ramalan yang diperbarui pada hari Selasa.

Jelas, tidak ada perusahaan perangkat lunak yang ingin berada dalam posisi Scrum-Addicts. Apa yang saya gagal mengerti tentang Agile dan Scrum adalah bagaimana mereka menyarankan tim harus berurusan dengan perencanaan dan tenggat waktu untuk menghindari situasi yang dijelaskan di atas.

Pikirkan MENGAPA MB ingin mengambil bola mereka dan pulang. MB tidak menuntut pekerjaan dilakukan dalam sebulan sejak awal. SA menjanjikan 100% fitur penting dalam satu bulan dan tidak memberikan. SA menetapkan tenggat waktu bukan MB. SA bahkan secara sewenang-wenang menambahkan satu minggu ke tenggat waktu. Jadi mengapa ini tenggat waktu?

Kadang-kadang ketika bersaing untuk perusahaan perangkat lunak kerja menyerah pada godaan untuk pamer dan menjanjikan bulan. Profesional dengan cermat menentukan apakah bulan bahkan diperlukan. Yang merupakan kebutuhan lebih penting untuk MoneyBags? 100% fitur atau produk yang berfungsi dalam waktu satu bulan? Apakah mereka tahu apa yang benar-benar kritis? Apakah ada beberapa acara mendatang yang menetapkan tenggat waktu yang sulit?

Jika saya Scrum-Addicts sedang merundingkan kontrak ini, saya ingin tahu lebih banyak tentang kebutuhan bisnis Money-Bags dan menyusun kontrak untuk memberikan fleksibilitas sebanyak yang dapat diterima Money-Bags. Saya akan mengajari mereka bagaimana proses tangkas bekerja sehingga mereka tahu apa yang diharapkan dari kami.

Dengan cara ini daripada mengharapkan semuanya tiba-tiba bekerja dengan sempurna dalam sebulan mereka akan mengharapkan untuk mengevaluasi pengiriman pertama dalam 1 hingga 2 minggu.

Jadi, untuk meringkas, saya punya 2 pertanyaan:

Siapa yang harus disalahkan? Manajer, karena itu tugas mereka untuk melakukan perencanaan yang tepat
. Tim, karena mereka berkomitmen untuk melakukan lebih banyak pekerjaan daripada yang bisa dilakukan orang
lain

Siapa pun bisa menghentikan parodi ini sebelum kita punya waktu sebulan.

Saya bisa menyalahkan Money-Bags Corp karena merekrut tim yang jelas-jelas mewakili proses air terjun yang gesit. Kontrak itu sendiri menjelaskan bahwa ini tidak gesit. Perencanaan untuk dilakukan dalam sebulan tidak membuatnya gesit.

Jika Anda bersikeras bahwa gesit, gesit dengan hanya satu sprint yang panjang sebulan. Yang, ya, saya tidak akan merekomendasikan karena itu, sekali lagi, hal yang sama dengan air terjun.

Apa yang Harus Dilakukan?

Bagaimana dengan tangkas? Memberikan sesuatu setiap sprint? Dapatkan umpan balik sebelum batas waktu? Sprint selama seminggu? Bagaimana kalau menegosiasikan ulang kontrak kejam itu tepat saat Anda mencurigai tenggat waktu lebih berbahaya daripada bersembunyi dan berdoa? Paling tidak Anda bisa berhenti membuang-buang waktu untuk proyek yang hancur dan menemukan pelanggan yang lebih masuk akal.

Manajer harus memindahkan tenggat waktu 2x (atau 3x) kali lebih lambat dari perkiraan tim asli.

Pengganda tenggat waktu sama bermanfaatnya dengan menyetel jam tangan Anda 15 menit lebih awal sehingga Anda tidak akan pernah terlambat. Anda hanya bisa membodohi diri sendiri begitu lama sebelum Anda menyadari apa yang Anda lakukan.

Perkiraan awal salah. Cobalah untuk menangkap betapa salahnya. 5 minggu, memberi atau mengambil beberapa minggu adalah ungkapan sederhana yang memungkinkan Anda mengungkapkan seberapa tidak pasti tanggal penyelesaiannya. Daripada mencoba menebak secara akurat, Anda menebak betapa liarnya tebakan Anda. Lakukan beberapa pekerjaan nyata dan dapatkan beberapa data nyata. Kemudian Anda dapat mulai membuat taksiran dengan rentang yang lebih sempit. Satu hingga dua minggu adalah banyak waktu untuk melakukan ini.

Anggota tim harus didorong untuk melakukan semua pekerjaan yang mereka lakukan untuk apa pun (dengan mengeluarkan penalti untuk sprint yang gagal)

Anggota tim harus didorong. Gagal, berkomitmen, atau sebaliknya. Daripada membangun konsekuensi buatan seperti hukuman atau bahkan bonus (wortel dan tongkat) penelitian telah menunjukkan bahwa orang yang melakukan pekerjaan kreatif seperti pemrograman merespons paling baik jika memberikan tiga hal: Otonomi, Penguasaan, dan Tujuan.

Daniel Pink berbicara tentang hal ini dengan TED . Pembicaraan tentang motivasi tidak gesit tetapi saya dengan mudah melihat bagaimana memetakan poin-poin ini menjadi gesit:

Otonomi - Saya ingin mengarahkan hidup saya sendiri - Biarkan saya memilih pekerjaan dari jaminan.
Penguasaan - Saya ingin menjadi lebih baik dalam hal yang penting - Umpan balik pelanggan.
Tujuan - Saya ingin menjadi bagian dari sesuatu yang lebih besar dari diri saya - Tim kolaboratif.

Tim harus membatalkan Scrum karena tidak sesuai dengan tenggat waktu perusahaan. Kebijakan Scrum dapat mencapai batas waktu lebih akurat daripada air terjun. Mengingat batas waktu scrum dapat memenuhi itu. Mungkin memenuhi hanya dengan 1 dari 47 fitur tergantung pada waktu, fitur, dan keterampilan tetapi dapat memenuhi itu.

Proyek lincah dapat ditata sedemikian rupa sehingga setiap malam saat tim pulang, ia siap dikirim. Ini tampak konyol kecuali jika Anda menganggap pengiriman meminta pelanggan untuk menguji dan memberikan umpan balik. Semakin cepat itu terjadi semakin cepat Anda dapat melakukan penyesuaian. Ini mencapai setiap tenggat waktu yang mungkin. Hanya saja tidak setiap fitur. Tapi itu mengarahkan Anda ke fitur yang penting.

Kita semua harus menghentikan pengembangan perangkat lunak dan bergabung dengan biara

Benar, seperti mengunci saya di ruangan yang jauh dari kehidupan nyata akan membuat saya menulis kode KURANG.

Saya telah mengedit jawaban ini hingga ukurannya. Jika Anda penasaran baca riwayat sunting.


Saya hanya ingin berasumsi Anda bermaksud sprint bukan backlog - Maksud saya tepat apa yang saya tulis dalam pertanyaan: backlog sprint
Andre Borges

orang yang melakukan pekerjaan kreatif seperti pemrograman merespons paling baik jika memberikan tiga hal: Otonomi, Penguasaan, dan Tujuan - ini bisa menjadi topik besar untuk spekulasi sendiri, tetapi kenyataannya adalah bahwa sayangnya banyak pekerjaan pemrograman menjadi kurang kreatif dan lebih rutin (tugas-tugas yang membosankan, tumpukan tech tetap dan set feture, kontrak yang ketat). Oleh karena itu, dalam banyak kasus wortel dan tongkat berfungsi dengan baik.
Andre Borges

@AndreBorges Anda benar, saya memikirkan tumpukan produk. Baru-baru ini saya telah bekerja dengan alat yang menyebut sprint backlog sprint dan produk backlog backlog. Anda menangkap saya kalah dalam pertarungan untuk menjaga kosa kata saya tidak menjadi hak milik.
candied_orange

Pemrograman @AndreBorges tidak akan pernah menjadi isian amplop. Ini benar-benar masalah lilin. Alasannya adalah karena masalah berulang dapat diselesaikan dengan kode yang sama yang memecahkan masalah pertama. Meskipun demikian manajemen dapat masuk ke pola pikir di mana mereka berpikir kreativitas adalah masalah yang harus dihilangkan. Saya sudah bekerja dan lari dari beberapa toko ini. Mereka tidak memelihara orang baik. Mereka tidak menghasilkan perangkat lunak yang bagus. Pengembang adalah pengrajin. Mencoba mengubahnya menjadi pekerja jalur perakitan hanya akan merugikan Anda. Pekerjaan saya bukanlah membalik telur. Ini untuk memastikan bahwa telur dibalik.
candied_orange

0

Setiap orang harus gesit. Apa pun yang Anda putuskan, akan terlihat, siapa yang melakukan apa, bagaimana, kapan, di mana, dan mengapa oleh semua pihak. Pelanggan gesit, manajemen, dan pengembang.

Anda tidak dapat memberikan tanggal pengiriman terlalu jauh ke masa depan. Anda memberi perkiraan.

Seseorang perlu mengelola harapan klien. Alasan mengapa Anda tidak terlalu khawatir tentang kehilangan beberapa sprint adalah karena Anda menyesuaikan diri agar seluruh proyek tidak ketinggalan. Jika Anda sampai pada kesimpulan setelah satu atau dua sprint bahwa Anda tidak akan selesai memenuhi "tanggal pengiriman", saat itulah Anda memberi tahu klien.

Sekarang apa yang ingin kamu lakukan? Singkirkan fitur yang tidak Anda butuhkan atau pindahkan tanggal. Jika Anda bisa tepat waktu, Anda akan melakukannya. Jangan ragu untuk membawa kabar buruk.

Siapa tahu, pada beberapa proyek, Anda dapat mengirim lebih cepat.

Anda tidak bisa gesit jika klien tidak mau.


0

Tujuan

Saya percaya dua "metrik" berikut ini harus menjadi dasar untuk setiap keputusan bisnis:

  • adalah pekerjaan yang menguntungkan (untuk klien)
  • apakah kita bekerja seefisien mungkin

Ini sangat universal. Tentu saja itu menjadi lebih rumit dengan sangat cepat, misalnya, pekerjaan yang menguntungkan adalah tentang produk yang melakukan hal yang benar, pengguna dapat menggunakan produk, produk yang dipasarkan dengan benar, dll. - untuk banyak dari ini " Scrum-Addicts LLC "tidak memikul tanggung jawab.

Isu

Kontrak tidak berfokus pada tujuan yang diuraikan di atas. Ada klausul "semua atau tidak sama sekali" - selesaikan semuanya dan dibayar, atau selesaikan apa-apa dan jangan dibayar. Namun, ini tidak secara langsung berhubungan dengan nilai yang sedang dibuat. Kelemahan lain yang mengikuti: sekarang kita perlu menghabiskan waktu & uang meyakinkan dan memverifikasi bahwa kontrak sedang diikuti. Kenapa kita ingin menghabiskan uang ini? Bagaimana memastikan kontrak dipenuhi bantuan ketika persyaratan telah berubah sementara itu dan kami telah menemukan bahwa perangkat lunak yang dipesan tidak menciptakan nilai apa pun? Hanya ada lebih banyak uang mengalir sia-sia! Sekarang, tentu saja, ada alasan untuk perilaku ini:

  • Secara budaya kita terbiasa berbelanja untuk hal-hal seperti itu. Kami mengharapkan berbelanja untuk perangkat lunak seperti halnya untuk mobil: pilih konfigurasi, diberi harga dan tenggat waktu, dan sangat tidak senang jika keduanya tidak terpenuhi.
  • kami ingin mengurangi risiko dan akuntabilitas
  • kami ingin stabilitas, ini membantu perencanaan dan membuat kami merasa lebih baik (dan juga klien kami, yang merupakan aspek penting!)

Pada akhirnya, kita harus memilih kompromi yang memungkinkan kita untuk memenuhi tujuan kita sebaik mungkin.

Beginilah cara kerjanya

  • memiliki kontrak untuk layanan & pekerjaan alih-alih untuk produk
    • harus dapat diakhiri dengan pemberitahuan yang relatif singkat
  • bekerja sama erat untuk memastikan efisiensi optimal
  • melibatkan semua pihak yang diperlukan, baik dari " Scrum-Addits LLC " dan " Money-Bags Corporation " - sebuah "titik kontak" yang menyalurkan semua informasi tidak akan berfungsi di sini

baik saya pada dasarnya hanya mengatakan "gesit". Sekarang inilah alasannya:

  • Proses & kontrak dioptimalkan untuk menghabiskan banyak uang di Goal mungkin
  • Anda harus memercayai kontraktor untuk melakukan pekerjaannya, dan tidak perlu menginvestasikan banyak uang untuk memverifikasi bahwa ia siap bekerja.
  • kemampuan menggugat kontraktor Anda jika harapan / kontrak Anda tidak terpenuhi biasanya tidak membantu, karena melakukannya akan lebih mahal daripada hanya menjatuhkannya. Beberapa masalah utama di sini adalah waktu-ke-pasar. Anda kemungkinan besar akan kehilangan jauh lebih banyak uang / bisnis dengan pergi ke pengadilan daripada yang akan Anda dapatkan.
    • pada akhir hari Anda hanya perlu menanggung risiko sendiri.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.