Dapatkah ruang lingkup tetap + tenggat waktu tetap + kontrak harga tetap dapat dibuat untuk bekerja dengan "gesit"?


32

Beberapa proyek yang kami jalankan secara internal menggunakan Scrum, sementara masih "memperbaiki segalanya" kepada pelanggan. Kami mengalami kesuksesan yang beragam di pihak kami (pelanggan menyukai visibilitas grafik burndown). Bisakah jenis proyek yang kami kerjakan berhasil dieksekusi menggunakan metode gesit?


17
Dapatkah ruang lingkup tetap + tenggat waktu tetap + kontrak harga tetap dapat dibuat untuk bekerja?
Carson63000

4
Bukankah ini cara untuk mengulangi: "Cepat, Bagus, atau Murah. Pilih Dua"?
Matthieu M.

3
Tidak memperbaiki antonim dari lincah?
Matt Ellen

Jawaban:


10

Yah, saya telah bekerja sebagian besar di lingkungan "lincah" (meskipun kami tidak menggunakan istilah), dan saya telah melakukan hal-hal biaya tetap. Secara umum, jumlah itu adalah biaya-plus, karena tidak ada perusahaan yang mampu melakukan semuanya secara gratis, dan persyaratan berubah dan berevolusi ketika pelanggan mengetahui dengan lebih jelas apa yang mereka inginkan.

Persyaratan awal untuk porsi biaya tetap harus dilakukan jauh lebih hati-hati daripada yang dilakukan dalam lingkungan iteratif yang khas, membuat prosesnya agak kurang iteratif. Bagian "plus" dari kontrak bisa lebih iteratif, asalkan kita telah memenuhi porsi biaya tetap lebih atau kurang memuaskan bagi pelanggan.


71

Saya ingin mengajukan pertanyaan balasan:

Dapatkah ruang lingkup tetap + tenggat waktu tetap + kontrak harga tetap dapat dibuat untuk bekerja, titik ?

Pepatah "baik / cepat / murah - pilih dua" bukan hanya lelucon rekayasa konyol. Setiap manajer proyek layak tahu apa-apa tentang Segitiga Manajemen Proyek :

Segitiga Manajemen Proyek

Anda memberi tahu kami bahwa biaya, cakupan, dan jadwal semuanya sudah ditentukan. Tidak ada ruang untuk manuver atau kesalahan. Tidak ada . Anda dapat memilih untuk melihat "Kualitas" sebagai atribut, tetapi itu bukan atribut "nyata", itu lebih seperti atribut meta yang berasal dari atribut lain (biaya / ruang lingkup / jadwal).

Masalahnya adalah ini tidak pernah terjadi dalam kenyataan selama proyek Anda sedang direncanakan dan dilaksanakan oleh manusia.

  • Persyaratan dan spesifikasi tidak pernah mencakup setiap kasus tepi kecuali mereka telah dibuat dalam detail besar oleh arsitek dan desainer yang memenuhi syarat, dalam hal ini proyek sudah setengah jadi; dan bahkan kemudian masih ada kemungkinan kesalahan.

  • Biaya tak terduga akan muncul yang mengarah pada pembengkakan anggaran. Langganan kedaluwarsa. Pabrikan menghentikan dukungan mereka untuk produk yang Anda gunakan dan Anda harus menemukan yang baru. Kontraktor per jam menaikkan tarifnya di bawah ancaman keberangkatan. Seluruh tim Anda baru saja mogok, menuntut kenaikan 10% dan satu minggu ekstra liburan.

  • Jadwal tergelincir. Masalah yang tidak terduga muncul; komponen bagan yang telah Anda gunakan selama 5 tahun berturut-turut tidak kompatibel dengan Windows 95, yang masih digunakan klien Anda. Bug yang tidak jelas pada Windows 64-bit menyebabkan gangguan UI serius dan Anda menghabiskan hampir satu minggu untuk melacaknya dan mengembangkan solusi (ini benar-benar terjadi pada saya). Pengembang senior Anda tertabrak bus dan Anda harus merekrut dan melatih yang baru. Perkiraan tanggal pengiriman Anda selalu salah. Selalu.

    Lihat Hukum Hofstadter :

    Hukum Hofstadter: Selalu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan Hukum Hofstadter.

Metode lincah adalah tentang juggling seputar biaya, jadwal, dan ruang lingkup. Sebagian besar waktu, mereka secara khusus tentang juggling di sekitar ruang lingkup dan kadang-kadang jadwal , itulah sebabnya Anda mulai dengan cerita pengguna samar-samar dan revisi rencana daripada versi lengkap. Metodologi yang berbeda menggunakan terminologi yang berbeda tetapi semuanya memiliki dasar pemikiran yang sama: Rilis yang sering dan penyeimbangan kembali jadwal dan ruang lingkup dengan setiap rilis.

Hal ini membuat tidak masuk akal dengan proyek yang (atau klaim untuk menjadi) baik lingkup tetap atau jadwal yang tetap.

Jika satu atribut proyek (biaya / ruang lingkup / jadwal) diperbaiki, saya akan memberi tahu Anda bahwa itu mungkin tidak cocok untuk metodologi tangkas.

Jika dua atribut proyek diperbaiki, maka proyek Anda jelas tidak cocok untuk metodologi tangkas.

Jika ketiga atribut diperbaiki, maka proyek Anda mungkin akan gagal. Jika itu benar-benar dikirimkan, maka baik jadwal asli secara besar-besaran fudged, atau klien telah berhasil menipu dirinya sendiri dengan berpikir bahwa Anda benar-benar memberikan apa yang dijanjikan.

Jika kontrak ini masih di atas meja, saya mendorong Anda untuk menolaknya. Dan jika Anda sudah menerimanya, semoga Tuhan mengampuni jiwa Anda.


4
+1 untuk hukum Hofstadters. Saya akan mengutipnya pada sesi estimasi berikutnya.
Chris Buckett

2
Perhatikan bahwa jika "diperbaiki" tidak benar-benar berarti tetap (seperti tersirat dalam komentar untuk jawaban Todd) maka itu mengubah lanskap sedikit, dan keberhasilan proyek sebagian akan bergantung pada membuat semua orang setuju pada definisi sebenarnya dari kata tersebut. "diperbaiki" (atau "harus" atau "diperlukan" atau apa pun kata-kata spesifik dalam kontrak itu). Jika ruang lingkup benar-benar "tetap jika kita punya waktu" , maka itu mulai terlihat lebih seperti proyek lincah. :)
Aaronaught

2
Saya menduga itulah cara manajemen bekerja dengan klien.
Chris Buckett

3
Jadwal tetap / ruang lingkup / proyek harga dapat bekerja (saya sudah melakukannya), mereka hanya membutuhkan persyaratan yang sangat solid, estimasi yang sangat baik dan seperti yang Anda katakan hal-hal ini sangat sulit dalam kenyataan. +1 untuk penjelasan yang jelas tentang bagaimana Agile pada dasarnya bertentangan dengan seluruh mekanisme harga tetap meskipun karena semua tentang trade-off (pintar) dan yang lain menghalangi kemungkinan untuk menukar apa pun.
Jon Hopkins

3
Jumlah upvote pada jawaban ini menunjukkan berapa banyak yang bekerja keras di Agile + Kekacauan harga tetap.
pembawa cincin

18

Saya suka kutipan ini:

“Scrum sangat bagus untuk ruang lingkup variabel tanggal tetap, atau" ruang lingkup tetap "(yang selalu tumbuh) tanggal variabel. Jika Anda melakukan fixed-date fix-date, saya sarankan air terjun atau RUP, yang akan membeli Anda beberapa bulan untuk mencari pekerjaan baru. ”~ Michael James


6

Tentu, selama bilah kualitas Anda tetap sangat rendah. Saya percaya pada segitiga besi tua "waktu pengiriman / kualitas / harga" di mana Anda dapat memilih dua, tetapi yang lain mengapung. Sepertinya Anda telah memperbaiki waktu dan harga pengiriman (dan juga fitur-fiturnya) sehingga satu-satunya hal yang dapat Anda berikan adalah kualitasnya.

Yang mengatakan, jika Anda menggunakan grafik burndown dan Anda memiliki item prioritas tertinggi dilakukan terlebih dahulu mungkin dapat diterima untuk memiliki beberapa item paling penting yang dilakukan dalam kerangka waktu yang ditentukan untuk jumlah uang yang ditentukan. Paling tidak klien Anda akan melihat bahwa Anda agak mengendalikan proses, dengan hasil pada akhir setiap iterasi dan mereka memiliki kemampuan untuk mengatakan apa yang paling penting.

Kalau tidak, saya berpikir bahwa berkomitmen untuk waktu yang tetap, set fitur, dan harga adalah bodoh dan akan mengarah pada upaya heroik yang menghasilkan kualitas yang lebih rendah dan kode yang kurang dapat dipelihara. Agile bukan debu peri sihir.


2
Begitulah cara kami menanganinya dengan pelanggan kami - biarkan ruang lingkup tergelincir dan menambahkannya di versi berikutnya. Motivator utama mereka adalah tenggat waktu dan harga. Kami tidak suka membiarkan kualitas turun - karena catatan ini dan komentar lainnya perhatikan, kami sepenuhnya menyadari segitiga - sisi bisnis memiliki pekerjaan yang menyenangkan untuk membuat pelanggan menyadari hal ini juga.
Chris Buckett

0

Harga tetap / batas waktu tetap / ruang lingkup tetap dapat dilakukan setidaknya dengan gesit seperti di air terjun.

Di air terjun, estimasi waktu tidak akurat, dan detail akhirnya diimplementasikan secara berbeda dari spesifikasi aslinya. Dengan kata lain, batas waktu / ruang lingkup tidak dapat diketahui secara pasti sebelumnya.

Dengan gesit, Anda dapat melakukan sprint zero untuk menghasilkan tumpukan cerita pengguna, dan membuat beberapa estimasi. Kemudian setuju untuk memenuhi kisah nilai untuk harga tetap, dengan tenggat waktu tetap. Ruang lingkupnya tetap dalam hal cerita nilai yang ingin Anda penuhi, dan tidak ada janji dibuat tentang cerita pengguna.

Dengan kata lain, Anda berjanji untuk memberikan apa yang penting, dan menghindari membuat janji tentang keputusan desain tertentu yang tidak terkait dengan pendapatan / tabungan / dll. bahwa proyek itu seharusnya memberikan.


Tua, tapi ... itu bisa dilakukan jauh lebih baik di Agile daripada di Waterfall, dan kemungkinan tidak akan berubah. Nol selalu akan menjadi nol. Jika satu tugas pada satu cerita bertemu satu peristiwa yang mengubah biaya atau usaha, Anda telah gagal.
EKW

0

Saya setuju dengan Bruce sampai tingkat tertentu. Meskipun saya tidak terlalu terbiasa dengan air terjun atau RUP, dan karenanya tidak dapat mengomentari itu.

Apa yang saya baca baru-baru ini, dan saya pikir dikatakan dengan sangat baik, adalah bahwa bahkan di Agile kami mengabaikan perencanaan. Sesi perencanaan menyeluruh sekali iterasi hebat - tidak itu penting - tetapi begitu pula perencanaan SELURUH iterasi.

Saya bekerja di industri hiburan, di mana segalanya terus berubah. Tim membutuhkan beberapa tingkat kelonggaran / kelonggaran yang akan memungkinkan mereka untuk "merencanakan kembali" cerita sprint dalam rangka untuk menyelaraskan dengan tujuan baru atau tujuan yang direvisi.

Saya suka ide perencanaan berkelanjutan, karena terlalu sering pengembang akan memberitahu pemilik produk untuk pergi ketika mereka sedang mengerjakan cerita mid-sprint. Ini bagus sekali jika tim Anda mengerjakan cerita yang masih valid, dan pemilik produk Anda hanya mengganggu. Tetapi dalam beberapa kasus, cerita menjadi mubazir SELAMA sprint, dan sangat penting bagi pemilik produk untuk menemukan ini, dan bagi tim untuk menyelaraskan kembali dengan tujuan / cerita yang diubah - bukankah itu tentang lincah?


2
jika Anda melakukan perencanaan konstan, maka Scrum benar-benar bukan untuk Anda. Kanban mungkin lebih tepat untuk dicoba. Tapi apa yang Anda katakan tentang Agile adalah hal yang tepat.
gbjbaanb
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.