SCRUM: sebuah puisi tentang cinta dan penderitaan



Jika dia begitu baik, lalu mengapa tidak semua orang bekerja hanya sesuai dengan metodologi ini? Dan mereka yang seharusnya menerapkannya sering memamerkan ScrumTapi mengerikan. SCRUM sejati meninggalkan bekas luka, luka dan bekas luka di hatimu, dan sekarang aku akan menceritakan tentang milikku.

Nyeri scrum


Ketika saya pertama kali mencoba, saya sudah muda dan mengerti ini. Saya baru saja jatuh cinta pada buku Jeff Sutherland SCRUM: Seni Melakukan Dua Kali Pekerjaan di Setengah Waktu. Benar, menjelang akhir dia tampak sedikit fanatik bagi saya ketika dia mulai memberi tahu bagaimana metodologi membantu di sekolah dan di bidang kedokteran. Tetapi saya benar-benar belajar banyak dari Sutherland dan segera memutuskan untuk mencoba teknik ini di tim saya. Nyeri mulai terasa.

Keterlambatan dan keterlambatan dalam rapat


Bagaimana jika Anda ingin memenuhi stand-up 10 menit, dan seseorang terlambat 15 menit? Pertama, semua orang menunggunya, dan kemudian saya ingin masuk ke detail, dan standup tertunda selama satu jam. Dan jika seseorang belum mencapai pertemuan apa pun, maka dia sekarang tidak terhubung dengan peristiwa dan menanyakan semuanya lagi. Semua ini mengarah pada fakta bahwa belum ada yang mulai bekerja, tetapi semua orang sudah bosan dengan rapat yang kental. Pertama-tama, saya harus bekerja pada disiplin: tanpa penundaan, tanpa argumen, tanpa merinci. Sejujurnya selama 5-10 menit, scrum menguat, tetapi bagaimana bedanya dengan pertemuan tradisional Soviet sejak pagi?

Perselisihan, diskusi terperinci dan tujuan


Anda memberi tahu tim "kami punya waktu 5-10 menit", dan mereka memberi tahu Anda bahwa jika kami tidak menyelesaikan pertengkaran kecil ini, kami tidak akan bisa melanjutkan, dan itu akan menghalangi kita semua. Atau bahkan lebih buruk: kita perlu melihat konsep dan strategi umum, kita tidak bisa bekerja tanpanya, jadi mari kita hancurkan kotoran dalam mortar. Diperlukan sebuah strategi dan konsep umum, mereka harus dijaga sebelum mulai, jika tidak ada, maka Anda tidak harus pergi dalam siklus dan memperlambat kerja perselisihan.

Kami dihadapkan dengan kenyataan bahwa sangat sulit untuk memulai sprint tanpa memahami tujuan global perusahaan sebagai satu tim secara keseluruhan:

Scrum master: "Mari kita merumuskan tujuan sprint: terukur, dapat dipahami, dapat dicapai!"
Skeptis: β€œDan mengapa tujuan ini harus seperti itu? Di mana Anda mendapatkannya? "
... dan ada argumen selama satu jam.

Scrum master: β€œTujuan produk kami adalah untuk menghilangkan orang dari pengukuran. Mari kita nyatakan tujuan dari sprint! ”
Peppy: "Ayo buat modul mini yang akan mengambil penghitung dan menaruhnya di piring."
Skeptis: β€œYa, tidak, tapi tiba-tiba ternyata ini adalah pekerjaan tambahan, Anda perlu memahami proyek secara keseluruhan. Saya ingin mengingat seluruh proyek! ”
Scrum master menembak dirinya sendiri di mulut dengan senapan ... Saya akan

menulis lagi secara singkat kondisi untuk memulai sprint:

  1. Tidak ada penundaan
  2. Tanpa operan
  3. Tanpa menunda pertemuan
  4. Tidak ada argumen
  5. Tidak ada bagian kecil
  6. Tujuan global jelas, yang disetujui oleh seluruh tim.
  7. Ada kemauan bahwa sprint mini akan keliru, dan bahwa tujuan sprint dipilih secara salah.

Itu semua sangat menyakitkan, banyak rasa sakit!

Ingatlah seluruh proyek!


... master Scrum yang baru saja sadar dalam perawatan intensif kembali menjadi koma ...

Tidak ada proyek dan tidak dapat berada di kepala, karena dunia sekitar terus berubah. Semua yang ada di kepalaku hanyalah ilusi. Tidak perlu takut untuk melakukan terlalu banyak yang tidak perlu dan salah sebagai bagian dari sprint. Kami bergerak dalam langkah kecil, jadi selalu ada peluang untuk memperbaiki kesalahan. Daripada berdebat selama dua minggu, mari kita menangkap dua sprint selama ini, mari kita membuat kesalahan, menguji hipotesis dan memenangkan pertarungan!

Itulah sebabnya kami meninggalkan semua perselisihan dan demokrasi dalam perencanaan sprint. Ketika sprint dimulai, jangan berdebat - hasilnya akan segera menilai kita. Siap untuk perubahan adalah bagian dari Agile Manifesto!

Jangan katakan padaku apa yang kamu lakukan kemarin!


Ketika Anda dan tim Anda menjalankan sprint di scrum, maka Anda memiliki sisi bahwa apa yang tertinggal di belakang Anda! Terlebih lagi, seringkali saat stand-up setiap orang tertarik untuk mengatakan siapa yang melakukan apa kemarin. Mengapa demikian? Ya, karena jauh lebih sulit untuk mengatakan apa yang ingin Anda lakukan hari ini, bagaimana hal itu akan membawa Anda lebih dekat ke tujuan sprint dan apa yang menghalangi Anda.

Ngomong-ngomong, jika kita membahas hanya rencana untuk hari ini, maka praktis tidak ada yang perlu dibicarakan. Masa depan memiliki jauh lebih sedikit orang sarat dengan emosi daripada masa lalu. Sprint sedang mencari masa depan. Jika Anda mengikuti prinsip ini, stand-up akan memakan waktu tidak lebih dari 10 menit.

Kesulitan perawatan


Ketika monyet makan cukup dan bergender, mereka duduk untuk menyisir serangga dari wol masing-masing. Anggota tim, seperti mereka, menyisir tugas-tugas kecil dengan kaki dari arus umum, berusaha membuatnya sesingkat mungkin.

Seringkali ternyata tugas tersebut tidak dijadwalkan dengan benar ketika pekerjaan sudah dimulai. Tidak ada yang mau menyisir apa pun. Akibatnya, semua orang menangis dengan air mata berdarah karena terlalu malas pada awalnya. Semakin kecil tugas, semakin dapat dimengerti dan semakin sulit untuk membuat kesalahan.

Saya biasanya duduk dengan para pengembang di luar sprint dan membaca setiap cerita pengguna dengan keras dalam paduan suara.

Tim itu sendiri memilih tugas!


Tapi ini benar-benar menyebalkan. Bagaimana? Bagaimanapun, jauh lebih mudah untuk menetapkan tugas secara langsung. Seperti yang Anda tahu, Soviet, yaitu, orang-orang Rusia tidak siap untuk demokrasi, akan ada kekacauan!

Dan kemudian ternyata ada tugas yang enak dan menarik, tetapi ada yang membosankan dan rutin. Dan itu juga terjadi: ada tugas Anda, Anda berspesialisasi dalam hal ini. Dan kemudian tiba-tiba seseorang yang bukan inti mengambilnya dari bawah hidung Anda, karena sangat enak dan menarik.

Biarkan itu sangat menyakitkan bagi para manajer, tetapi ketika anggota tim memilih tugas mereka sendiri, kami mendapatkan kinerja yang lebih baik dan kualitas yang lebih baik.

... Scrum master tersenyum tanpa meninggalkan koma ...

Fungsionalitas silang


Komando pasukan khusus dapat berupa dokter, operator radio, komandan, mekanik. Tetapi bagaimana jika seseorang terbunuh? Kemudian fungsi mereka akan diambil oleh pejuang lainnya. Prinsip ini digunakan dalam tim SCRUM sehingga tidak ada "kemacetan". Jika semuanya macet di satu atau yang lain, maka seluruh tim harus berhenti dari pekerjaan mereka dan mengambil tugas yang tidak biasa bagi mereka.

Scrum membawa banyak kesakitan pada kebanggaan profesional Anda: "Saya sudah belajar selama bertahun-tahun untuk tidak mengacaukan batang tirai."

Kegagalan


Tentu saja, sprint pertama saya berakhir dengan kegagalan. Dan hampir setiap sprint pertama dengan tim baru berakhir dengan kegagalan. Paling sering, alasannya adalah bahwa tujuan sprint dirumuskan secara tidak benar. Ternyata itu tidak dapat dicapai dan tidak dapat dipahami, tim terlalu tinggi memperkirakan kekuatannya, dan sebagian besar pekerjaan dihadang oleh pelanggan.

Hal yang paling menarik adalah retrospektif dari sprint yang gagal ketika waktu habis dan tujuan tidak tercapai. Tidak, tidak, kami tidak akan memperpanjang sprint untuk hari itu, tidak, kami tidak akan bekerja di malam hari! Kami mengakui kegagalan dan kami akan menganalisis apa yang salah dengan kami, apa yang terjadi dengan sukses, dan apa yang bisa diperbaiki.

Biasanya setelah tanya jawab seperti itu, semua orang berkumpul dan sprint berikutnya super sukses. Dalam retrospektif kedua, seluruh tim mulai mendapatkan buzz nyata dari pekerjaan, dan karenanya dari kehidupan secara umum. Anda menetapkan diri Anda tujuan yang terukur, dapat dicapai, dapat dipahami, tetapi kompleks dan sekarang Anda dikecewakan oleh pencapaian mereka.

Fakta bahwa sprint akan selesai dengan hasil apa pun mengurangi kecemasan dan memungkinkan Anda untuk berkonsentrasi pada tugas-tugas lokal, dan ini meningkatkan kualitas eksekusi.

... wow, tuan Scrum kami sudah pindah dari perawatan intensif ke terapi, koma di belakang ...

SCRUM seperti nyala api, membakar Anda ketika panas


Pemadaman profesional! Scrum adalah cara terbaik untuk mempercepatnya! Jika Anda tidak mengambil istirahat setelah setiap sprint, maka semua orang akan cepat lelah, stand-up akan berubah menjadi rutinitas, dan pekerjaan akan meluncur ke sampah lengkap.

Kepuasan hidup datang ketika Anda menetapkan tujuan yang berani, berjuang, mengalami kegagalan, bangkit kembali dan mencapai hasil. Anda tidak dapat hidup dalam mode ini selamanya. Mereka menyelesaikan sprint - mengambil istirahat selama seminggu: mereka mengerjakan tugas rutin, pergi berlibur, beralih ke proyek lain, dan mendapatkan kembali kekuatan untuk pertempuran baru. Untuk jatuh cinta lagi, Anda perlu menjilat luka kecil dari pengalaman sebelumnya, dan Anda siap. Meskipun banyak yang tertarik pada poliamori, dan ini adalah polbola!

Kami menghubungkan klien ke SCRUM


Bahkan jika kliennya bukan seorang programmer, dia akan mendapatkan tinggi, saya janji! Hanya semuanya yang harus jujur. SCRUM sejati: Anda tidak dapat membuang bagian-bagian penting, mengubah segalanya menjadi ScrumBut yang tak bertuhan. Tujuan proyek, jaminan, tujuan sprint, tim memilih tugas dan memberikan penilaian, stand-up harian, retrospektif, jeda di antara sprint. Jika setidaknya ada sesuatu yang terlempar keluar dari ini, maka semuanya berhenti bekerja, dan pelanggan kecewa dengan metodologi yang fleksibel.

Jadilah seperti Sutherland, bersikap fanatik ketika Anda diberi tahu: "Oh, ini sangat merepotkan, SCRUM baik, kami akan mengusahakannya, tetapi tidak perlu mengikuti semua prinsipnya."

Seringkali anggota tim memberi tahu saya: "Bagaimana saya bisa, karena pelanggan akan melihat pekerjaan yang belum selesai dan akan bersumpah." Itulah intinya! Semakin kasar prototipe - semakin mudah untuk dikritik, semakin cepat Anda mendengar kritik - semakin sedikit waktu dan upaya yang Anda habiskan untuk pengeditan dan peningkatan!

Inilah yang dikatakan Agile Manifesto kepada kita:

Orang-orang dan interaksi - stand-up harian dengan pelanggan dan tim!
Kolaborasi dengan pelanggan juga tentang hal ini.
Kesediaan untuk berubah - semakin cepat kita melakukan perubahan, semakin baik!

Sangat cerah? Dan di mana rasa sakitnya? Ha! Di mana-mana: manajemen takut dan menunda dimulainya sprint dengan klien, khawatir bahwa klien akan melihat pekerjaan yang belum selesai. Ada pelanggan yang ingin membeli produk jadi, seperti di toko, dan mereka berpikir bahwa pengembang membutuhkan standup, bukan mereka. Dan suatu kali mereka mengatakan kepada saya: "Kami ingin semuanya fleksibel, dan harganya menjadi sulit"

Harganya sulit, tugasnya fleksibel


... di tempat ini master Scrum sudah melakukan scrum dari rumah sakit dari jarak jauh.
Tunggu, apakah itu benar-benar mungkin? Para ilmuwan masih memperdebatkan hal ini ...

Tunjukkan pada saya pengembang yang tidak akan takut dengan pernyataan seperti itu. Di kepalanya, prospek perbudakan seumur hidup segera lahir. Direktur Jenderal, dengan kata-kata ini, membayangkan kebangkrutan perusahaan dan keruntuhan bisnis. Apakah ini rasa sakit utama?

Ternyata Anda dapat membuat harga yang sulit bagi pelanggan dengan tugas yang fleksibel! Kami memperbaiki uang, mengevaluasi tugas dan memahami mana yang sesuai dengan anggaran dan mana yang tidak. Di sini, tentu saja, Anda berjalan di sepanjang bilah pisau. Klien akan berdebat dengan penilaian tugas individu, dan manajer akan mencoba untuk memberikan penilaian, bukan pengembang. Ini hanya dapat dilakukan jika semua orang setuju dengan prinsip: siapa pun yang melakukan evaluasi. Untuk prinsip ini, Anda harus berjuang keras dengan manajemen dan pelanggan.

Proyek skala besar


Beberapa orang berpikir bahwa kebahagiaan dan kebahagiaan ada dalam proyek besar.
Beberapa orang bodoh membodohi diri mereka sendiri, saya kira
Mereka tidak membodohi saya.
Saya tahu itu tidak benar. Saya tahu itu tidak benar.
Proyek skala besar hanyalah kebohongan yang berakhir dengan wajah biru. Menurut statistik, sebagian besar proyek kecil bertahan.
Untuk membalikkan dunia, tim kecil sudah cukup.

Biasanya proyek skala besar yang sukses adalah serangkaian yang kecil keren. Hal utama adalah produk yang berfungsi, seperti yang dikatakan oleh manifes. Mari kita tidak mengejar skala, tetapi mulai dengan yang kecil, tapi cepat, fleksibel dan bekerja.

Semakin besar perusahaan, semakin besar proyek, semakin sedikit fleksibilitas yang mereka miliki. Itulah sebabnya SCRUM berfokus pada proyek kecil yang dapat dilakukan dalam satu sprint dari 1 hingga 3 minggu dan sebuah tim kecil dari 2 hingga 7 orang.

Pada saat yang sama, tim yang sangat besar dan tugas yang sangat besar masih dapat dilakukan sesuai dengan metodologi yang fleksibel, untuk ini Anda perlu memotong semuanya menjadi tugas kecil dan tim kecil.

Dalam residu kering:


  1. Pekerjaan scrum sakit.
  2. Penting untuk bekerja di Scrum, karena menang dijamin.
  3. Anda harus mengikuti metodologi dengan jelas dan fanatik tanpa menyelinap ke ScrumBut - ini adalah yang paling sulit dan menyakitkan.
  4. Kami melibatkan klien dan manajemen dalam SCRUM secara maksimal, ini tidak sesakit kelihatannya.
  5. Kami memotong semua proyek skala besar menjadi yang kecil, meskipun ini sangat menyakitkan.

Sumber kesenangan:


  1. Manifesto untuk Pengembangan Perangkat Lunak Agile
  2. Apa itu ScrumBut?
  3. Lagu SCRUM HURTS

Penjelasan untuk rasa sakit, terutama untuk Masha:


Rasa sakit biasanya karena Anda harus mengubah semua yang Anda terbiasa. Rasa sakit tersebut menyebabkan perasaan kehilangan kendali dan proses yang tidak dapat dikendalikan ketika Anda mempercayakan tugas favorit Anda kepada anggota tim dan takut mereka akan membanjiri proyek. Rasa sakit datang ketika Anda menginjak tenggorokan lagu Anda sendiri dan memecah proyek-proyek skala besar.

Rasa sakit berlalu ketika tugas-tugasnya sangat kecil, dan bahkan fakapa yang ganas dari para peserta tidak membanjiri seluruh proyek. Menjadi lebih mudah ketika Anda berhenti khawatir dan menyebarkan jerami pada seluruh proyek segera, ketika Anda bersantai dan memotong satu tugas sekaligus.

All Articles