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 "):
- 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 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 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 tersebut 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.
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?
- Manajer, karena itu tugas mereka untuk melakukan perencanaan yang tepat
- Tim, karena mereka berkomitmen untuk melakukan lebih banyak pekerjaan daripada yang mereka bisa
- Orang lain
Apa yang Harus Dilakukan?
- Manajer harus memindahkan tenggat waktu 2x (atau 3x) kali lebih lambat dari perkiraan tim asli.
- Anggota tim harus didorong untuk melakukan semua pekerjaan yang mereka lakukan untuk apa pun (dengan mengeluarkan penalti untuk sprint yang gagal)
- Tim harus membatalkan Scrum karena tidak sesuai dengan kebijakan tenggat waktu perusahaan
- Kita semua harus menghentikan pengembangan perangkat lunak dan bergabung dengan biara
- ???
Jawaban:
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".
sumber
Salah satu pernyataan nilai " Manifesto untuk Pengembangan Perangkat Lunak Agile " adalah:
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.
sumber
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.
sumber
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
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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.
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.
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.
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.
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.
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. 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.
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.
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.
sumber
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.
sumber
Tujuan
Saya percaya dua "metrik" berikut ini harus menjadi dasar untuk setiap keputusan bisnis:
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:
Pada akhirnya, kita harus memilih kompromi yang memungkinkan kita untuk memenuhi tujuan kita sebaik mungkin.
Beginilah cara kerjanya
baik saya pada dasarnya hanya mengatakan "gesit". Sekarang inilah alasannya:
sumber