Apakah peningkatan besar dalam kecepatan realistis dalam lingkungan Scrum?


Manajer saya baru-baru ini benar-benar mendorong untuk menggunakan kecepatan sebagai target dan ukuran produktivitas. Kami saat ini bekerja pada kecepatan rata-rata 50 poin cerita. Manajer saya ingin kami meningkatkannya hingga 40% menjadi 70 poin cerita (tanpa peningkatan anggota tim). Jika kita tidak mencapai peningkatan ini, dia ingin kita memberikan penjelasan lengkap mengapa.

Seluruh gagasan untuk mengukur kinerja tim dengan kecepatan dan menggunakannya sebagai target tampaknya salah bagi saya, tetapi saya merasa sulit untuk menjelaskan mengapa. Ada bantuan? Mengapa ini bukan cara yang tepat untuk mengukur dan memberi insentif pada produktivitas?


19
Wow. Manajer tidak mengerti apa itu kecepatan, atau berpikir tim itu malas. atau keduanya. Pada pertemuan perencanaan berikutnya, berkomitmen untuk 70 poin dan biarkan tim memberitahunya risiko kegagalan yang akan menyebabkan
Steven A. Lowe

25
Sepertinya permintaan yang gila, sehingga saya ingin Anda bertanya kepadanya mengapa menurutnya ini mungkin - jika Anda sudah memberi 100%, apakah dia mengharapkan Anda memberi 140%? Bagaimana jika Anda hanya membuat sprint 40% lebih lama?
Jonathan Rich

20
Velocity seharusnya menjadi ukuran seberapa cepat Anda bisa menyelesaikan sesuatu. Jika kecepatan dan poin cerita Anda benar-benar akurat, ini memberi tahu Anda bahwa Anda tidak dapat menyelesaikan seluruh simpanan dengan tenggat waktu. Hal yang rasional untuk dilakukan adalah menerima kenyataan dan memotong segala sesuatu dari tumpukan atau memprioritaskan apa yang ada sehingga apa yang Anda lakukan adalah hal yang lebih penting. Atau Anda bisa mengubah tenggat waktu menjadi sesuatu yang realistis.
Michael Shaw

45
Mintalah dia untuk kenaikan gaji 40% jika Anda mencapai target tersebut, kemudian naikkan perkiraan Anda sehingga Anda mendapatkan kenaikan 40%.
mattnz

18
Bukankah itu lebih seperti meminta pelari maraton untuk tiba-tiba menjalankan lari maraton dalam 1 jam 25 menit, bukannya 2 jam?
Scroog1

Jawaban:


Yah, sangat mudah untuk meningkatkan kecepatan hingga 40% - tambahkan saja 40% lebih banyak poin ke semua perkiraan Anda dan lakukan jumlah pekerjaan yang sama.

Mengingat hal ini demikian, harus jelas mengapa menggunakan kecepatan sebagai target salah, itu hanya mendorong perkiraan yang meningkat.

Jawaban yang kurang glib adalah bahwa perkiraan Anda sudah mengasumsikan Anda berjalan secepat yang Anda bisa sambil melakukan semuanya dengan benar. Satu-satunya cara untuk benar-benar meningkatkan produktivitas hingga 40% adalah bekerja lembur atau tidak melakukan semuanya dengan benar. Kedua hal ini mempercepat dalam jangka pendek, tetapi memperlambat dalam jangka panjang. Dan jangka panjang dalam kasus ini tidak terlalu lama, sebulan di luar. Strategi jangka panjang yang optimal adalah untuk tidak pernah lebih cepat dari kecepatan berkelanjutan Anda.

Peopleware berbicara dengan fasih tentang masalah mencoba memaksa pemrogram ke produktivitas yang lebih tinggi, dan sering dikutip klasik. Tetapi secara umum tidak mudah untuk mengubah pikiran seorang manajer yang akan menempuh jalan yang Anda lewati. Proyek Anda mungkin dalam kesulitan - ini tentu saja bendera merah.


28
Saya sangat percaya bahwa tidak ada "cepat dan kotor". "Kotor" selalu membuat saya lambat - bahkan dalam jangka pendek.
Doc Brown

1
@ Paul - Saya pikir itu bagus. Tetapi saran di dalamnya sebagian besar hanya dapat diikuti oleh manajer, dan saran yang dapat mengambil manfaat darinya mungkin tidak akan membacanya. Juga tidak akan membacanya mengubah perilaku.
psr

2
Dan jika Anda setuju dan benar-benar meningkatkan kecepatan hingga 40%, itu akan terlihat bagi orang lain bahwa Anda dan tim Anda tidak bekerja sebaik mungkin. Cara profesional untuk menanganinya adalah memberikan jawaban langsung: "Tidak, tidak bisa dilakukan.". Referensi buku lain tentang itu: "The Clean Coder" oleh Robert C. Martin.
pablosaraiva


1
"Perkiraanmu sudah mengasumsikan kamu akan pergi secepat mungkin sambil melakukan semuanya dengan benar" Ini mungkin asumsi yang salah. Kami selalu dapat terus meningkatkan dan mengoptimalkan. Tim tidak boleh berasumsi bahwa kecepatan stabilnya menunjukkan bahwa mereka tidak bisa menjadi lebih baik. Tetapi mereka perlu melihat seluruh proses mereka secara sistematis dan mencari perbaikan proses kecil.
Curtis Reed

Seperti yang ditunjukkan oleh komentar, permintaan itu jelas salah seperti yang telah dilakukan. Tapi dia tidak salah kalau ingin terus meningkatkan produktivitas. Sebagai aturan, itulah yang diperjuangkan manajer (dan dievaluasi) untuk.

Yang mengatakan, manajer selalu mencari untuk meningkatkan kinerja, dan Scrum dan Agile adalah tentang menjadi mudah beradaptasi. Meskipun kecepatan adalah ukuran dari kecepatan berkelanjutan Anda saat ini, Anda tidak harus berpuas diri. Scrum memiliki tempat untuk mengevaluasi dan mengubah apa yang berhasil dan tidak dalam proses Anda: retrospektif. Jika Anda memanfaatkannya dan menyesuaikan proses Anda, produktivitas (dan mungkin kecepatan) akan naik.

Jadi, apakah Anda mencari (dalam retrospektif Anda) cara untuk menjadi lebih produktif sebagai tim? Apakah ada sesuatu dalam sprint Anda yang secara teratur mengkonsumsi upaya yang tidak proporsional? Bisakah itu ditangani? Mungkin tidak akan memberi Anda kenaikan 40%, tetapi 5-10% adalah awal, bukan? Setiap sprint Anda harus mencari kemacetan dan mengatasinya. Akhirnya, Anda mungkin mendekati tujuan yang ia tetapkan untuk Anda.


7
+1: Ini adalah cara yang baik untuk menggambarkannya kepada manajer. Anda tidak dapat secara artifisial mendorong kecepatan, tetapi Anda dapat melihat kembali setelah setiap sprint dan mempelajari apa yang dapat Anda lakukan untuk menjadi sprint berikutnya yang lebih efisien.
Kevin

3
Kemungkinannya adalah menghapus overhead manajer (rapat paksa, mengisi formulir, dll) mungkin akan memberi Anda 5-10% itu dengan mudah. Tapi bagaimana cara meyakinkannya?
AviD

2
Saya pikir jawaban Anda mewakili kesalahpahaman kecepatan. Ini bukan metrik absolut, ini rata-rata yang diukur sepanjang umur proyek. Apa yang lebih titik kecepatan itu sendiri tidak mewakili pekerjaan yang dilakukan tetapi ukuran kasar dari kompleksitas. Mereka juga rata-rata sendiri, dan tugas poin rendah mungkin memerlukan lebih banyak waktu daripada yang lebih tinggi. Tampaknya tidak ada artinya meminta "lebih" dan mewakili kesalahpahaman mendasar. Manajer pada dasarnya meminta tenggat waktu tetap.
Ricardo Gladwell

3
@RicardoGladwell - Ketika saya mengatakan "permintaan itu jelas salah", saya mengakui bahwa ini adalah pemahaman yang salah tentang cara kerja poin cerita. Saya hanya menyarankan bahwa apa yang benar-benar diinginkan manajer adalah agar tim meningkatkan produktivitas, dan Scrum memang menyediakan sarana untuk melakukan itu. Juga, ada beberapa pendapat yang berbeda tentang poin cerita - kompleksitas menjadi yang paling umum Sebagian besar tim yang pernah bekerja sama dengan saya membuat mereka berhubungan dengan tingkat usaha. Tugas sederhana dengan banyak kuantitas tidak lagi dianggap sederhana.
Matthew Flynn

1
Anda memang menyebutkan bahwa peningkatan kecepatan "5-10% adalah awal" tetapi ini tampaknya berbagi kesalahpahaman manajer tentang apa yang dimaksud "peningkatan kecepatan" yang saya uraikan.
Ricardo Gladwell

TL; DR

Velocity sangat berguna untuk memperkirakan jadwal atau menghasilkan nilai perencanaan, dan juga dapat menjadi kontrol detektif yang berarti untuk menilai hambatan proses atau perubahan kapasitas tim. Namun, ini bukan ukuran produktivitas yang valid.

Ketika Velocity Bingung dengan Target Manajemen

"Velocity" adalah rentang yang mengekspresikan kapasitas rata-rata tim selama beberapa periode historis. Ini adalah analisis statistik dari kinerja masa lalu, yang kemudian dapat digunakan untuk memproyeksikan perkiraan probabilistik kapasitas kerja masa depan atau waktu siklus. Ini sangat kontras dengan "target penjadwalan," yang merupakan tujuan manajerial yang menetapkan garis waktu atau sasaran untuk tujuan perencanaan.

Manajer proyek yang gesit berpengalaman tahu bahwa penggunaan kecepatan yang tepat adalah untuk menentukan apakah tim memiliki kapasitas berkelanjutan untuk memenuhi target penjadwalan yang ditentukan manajemen. Terkadang jawabannya adalah ya, dan semua orang bahagia. Terkadang jawabannya tidak, di mana segitiga besi memaksa keputusan bisnis tentang ruang lingkup, biaya, waktu, dan kualitas.

Evaluasi Pilihan Politik Anda

Kami memiliki kecepatan rata-rata 50 poin cerita ... Saya telah diminta untuk meningkatkannya sebesar 40% menjadi 70 poin cerita (tanpa peningkatan anggota tim).

Dengan asumsi bahwa praktik estimasi Anda baik dan kecepatan Anda cukup stabil, manajer Anda tidak akan senang menyesuaikan skala estimasi atau menetapkan target manajemen yang tidak didasarkan pada kinerja historis. Seperti yang Anda tunjukkan dengan benar, ini pada dasarnya masalah kapasitas .

Batas kapasitas mungkin terkait dengan jumlah orang di tim Anda, atau mungkin merupakan batasan proses organisasi Anda. Tentu saja, menambah lebih banyak orang tidak selalu menambah kapasitas proyek yang sebenarnya; lihat Hukum Brooks untuk informasi lebih lanjut tentang kesalahpahaman umum ini.

Masalah yang Anda hadapi adalah masalah politik. Dari nada pos Anda, sepertinya manajer Anda ingin melihat peningkatan produktivitas tanpa membuat perubahan aktual pada kapasitas tim yang mendasarinya. Oleh karena itu solusinya juga bersifat politis, dan sebagian besar bersifat mendidik.

Jika Anda seorang toko Scrum, minta Scrum Master Anda untuk mengatasi masalah ini melalui saluran kerangka kerja yang sesuai. Backlog Grooming dan Sprint Retrospectives sering kali merupakan peluang memeriksa dan beradaptasi yang ideal untuk masalah khusus ini.

Jika Anda bukan toko Scrum, Anda harus memutuskan apa cara yang tepat untuk mengatasi masalah Anda di dalam organisasi Anda. Jika Anda berhubungan baik dengan manajer Anda, Anda mungkin bahkan meminjamkan salinan Agile Estimating and Planning untuk Anda berdua untuk membahas saat makan siang.

Jika semuanya gagal, bersiaplah untuk mars kematian dengan menyikat resume Anda, dan melakukan yang terbaik dari profesional Anda sampai proyek meledak. 68% proyek TI gagal ; kecuali target manajemen didasarkan pada kapasitas organisasi, target Anda mungkin salah satunya.


kualitas bukan variabel penyesuaian: itu sebabnya kita berbicara tentang besi segitiga, bukan besi persegi. Dengan kata lain, ketika seseorang mencoba untuk menurunkan "kualitas" itu menimbulkan malapetaka dalam keterlambatan (pengiriman lebih lama), ruang lingkup (fitur tidak bekerja dan dengan demikian tidak direalisasikan) ... dan sumber daya (pengembang berkembang frustrasi dan pergi). Jawaban yang bagus di samping titik menit itu.
Kriss

1
@ Kriss Quality memang bisa menjadi bagian dari segitiga. Kadang-kadang dianggap sebagai bagian dari "ruang lingkup," atau dalam beberapa segitiga itu adalah simpul aktual yang menunjukkan itu adalah kendala utama. Lihat segitiga biru di dalam Bintang PMBOK sebagai contoh nyata, atau Evolusi Model Kendala Proyek untuk beberapa perincian tentang masalah ini. Harap sampaikan ini di PMSE untuk informasi lebih lanjut.
CodeGnome

ini adalah diskusi yang sudah saya lakukan dengan sesama agonis. Singkatnya apa yang kita tidak setuju adalah bahwa PMBOK adalah sumber daya Agile yang valid. Itu berasal dengan model air terjun dan ortogonal untuk gesit. Sebagian besar kompatibel, tetapi masih ada beberapa masalah. Mempertimbangkan Kualitas sebagai variabel penyesuaian adalah satu. Seperti yang saya lihat (dan saya tidak sendirian) menggunakan (mencoba menggunakan) Kualitas sebagai variabel penyesuaian istirahat seluruh proses Agile. Tapi itu harus menjadi pertanyaan sendiri.
Kriss

Pertanyaan diposting di sini pm.stackexchange.com/questions/11489/...
kriss

Saya tidak mengerti peran apa yang dimiliki manajer Anda dalam tim Scrum? Apakah dia seorang pelatih? Apakah dia pemilik produk?

Jika dia ada di dalam tim seperti pelatih atau semacamnya (dia bekerja pada tugas pengembangan), Anda dapat bertanya kepadanya mengapa ia meremehkan produktivitasnya sendiri, karena tampaknya itu tidak berlaku untuk anggota tim lainnya. Jika dia yakin dia bisa secara pribadi mengasumsikan 30 poin cerita lebih banyak setiap iterasi, biarkan dia menunjukkannya.

Lebih mungkin: dia ada di luar tim, mungkin pemilik produk? Jika demikian dia harus mengerti membuat permintaan bodoh seperti itu dia hanya menghentikan ketangkasannya.

Aturan dasarnya adalah bahwa pemilik produk menentukan tujuan sementara tim menentukan apa yang dapat dilakukan dalam iterasi. Tidak melakukan hal itu mengarah ke lingkaran besi klasik dan terkenal: sumber daya, kecepatan, fitur. Ambil dua! Anda tidak dapat memilih mereka bertiga sekaligus (dan ingat: kualitas bukan variabel penyesuaian, mencoba mengambil jalan pintas melalui kualitas rendah akan membuat segalanya lebih buruk).

Jika dia tidak ingin mengubah tujuan saat ini, mungkin peningkatan 40% dalam produktivitas dapat dicapai dengan merekrut lebih banyak orang untuk tim? Mungkin berinvestasi dalam pelatihan lanjutan untuk beberapa anggota tim? Tim juga dapat memperoleh kecepatan dari waktu ke waktu melalui peningkatan berkelanjutan, tetapi tentu saja tidak dengan keputusan sewenang-wenang.

Mencoba mengubah kecepatan tim sama seperti mencoba mengubah ukuran ruangan. Itu bisa dilakukan, tetapi pada dasarnya Anda perlu mengganti kamar.

Apakah Anda tidak memiliki Scrum Master, atau orang lain di sekitar dengan pemahaman dasar tentang Scrum yang dapat menjelaskan hal itu kepadanya?


Dalam hal ini, manajer telah berbalik arah setelah mendapat estimasi yang jujur ​​dan setia dari tim. Manajer seharusnya berpaling kepada pemangku kepentingan dan memberi tahu mereka bahwa persyaratan mereka tidak dapat dipenuhi pada waktu yang diminta. Manajer / analis kemudian harus memprioritaskan fitur mana yang HARUS dimasukkan dan yang lainnya yang dapat menunggu (jika hanya beberapa minggu). Jika pemangku kepentingan tidak masuk akal, maka mungkin perlu manajer tingkat atas untuk terlibat, yang umumnya dapat menantang dan memerlukan serangkaian diskusi lainnya.

Jika saya berada di sepatu Anda, saya akan datang dengan kasus rinci mengapa proyek IS akan memakan waktu selama diperkirakan. Coba juga untuk mengidentifikasi item dengan pengembalian rendah. Temukan item yang tidak menambah banyak nilai dan membutuhkan upaya pemrograman yang besar dan membuat alasan untuk menghapusnya dari sprint. Juga datang dengan pendekatan berulang yang memberikan "X" pada tanggal "Y" dan memastikan itu layak, kemudian datang dengan iterasi tindak lanjut yang akan memberi mereka item yang tersisa.

Pada dasarnya, seseorang perlu memberi tahu pemangku kepentingan apa yang dapat mereka harapkan untuk diterima pada tenggat waktu dan bahwa itu mencakup sebagian besar persyaratan mereka. dan pada rilis berikutnya mereka akan memiliki item yang tersisa. Jika pelanggannya tidak masuk akal maka manajemen tingkat atas perlu dilibatkan, manajer harus dapat mewujudkannya.

Namun, jika pelanggan sudah dijanjikan, dan tidak ada yang berbicara sampai sekarang, itu akan menjadi perjuangan yang berat. Sayangnya ini bukan situasi yang tidak biasa.


1
"perkiraan jujur ​​dan setia" mungkin masalahnya.
JeffO

@ Jeffe - Bisa jadi, itu sebabnya saya merekomendasikan membuat kasus untuk membenarkan perkiraan .. ketika mereka mencoba melakukan itu mereka akan menyadari bahwa mereka meningkatkan perkiraan mereka atau bahwa mereka benar-benar tidak memiliki kapasitas
hanzolo

Sepertinya Anda menghadapi dua masalah.

Bagian tentang mengukur kecepatan yang mengganggu Anda mungkin adalah bahwa pengukurannya adalah biayanya . Yang benar-benar ingin Anda tingkatkan adalah nilainya . Sayangnya, mengukur nilai perangkat lunak sangat sulit dan subyektif. Namun, bahkan metrik yang tidak sempurna dan subyektif dapat berguna. Bisa jadi masalah sebenarnya bukanlah bahwa tim Anda perlu menulis lebih banyak kode, tetapi bahwa ceritanya harus lebih berharga.

Masalah lainnya adalah bahwa berdasarkan akun Anda, manajer Anda mengharapkan peningkatan 40% dalam produktivitas. Tidak disebutkan dalam pertanyaan Anda konteks permintaan ini. Ini bisa menjadi sifat yang baik jika angan-angan agar tim Anda meningkat. Atau itu bisa menjadi indikasi yang tidak terlalu halus bahwa manajer Anda percaya bahwa tim Anda berkinerja buruk.

sunting: Berdasarkan komentar Anda, situasinya terlihat buruk. Sepertinya perusahaan Anda meletakkan dasar untuk memecat Anda dan tim Anda (mungkin manajer Anda juga). Saya sarankan Anda mencari pekerjaan lain.


3
Sayangnya itu adalah permintaan serius, diutarakan sepanjang saya tidak melihat alasan mengapa Anda tidak dapat mencapai ini (tapi saya tidak akan memberi tahu Anda caranya!). Jadi implikasinya adalah bahwa dia tidak percaya mereka bekerja cukup keras atau tidak kompeten seperti seharusnya. Kemudian menjadi lebih buruk ketika saya pergi berlibur dan Pemilik Produk mengatakan kepada tim bahwa akan ada dampak serius jika mereka tidak mencapainya. Jadi saya sekarang juga memiliki tim yang sangat peduli (yang saya yakini sebagai tim yang hebat) untuk dikhawatirkan juga.
P2l

4
+1 untuk "keluar dari Dodge". Terkadang itu satu-satunya cara (meskipun semakin jarang semakin baik).
Michael

Pecat dia. Dengan kata lain, pergi ke atas kepalanya dan menjelaskan bahwa dia telah kehilangan semua kepercayaan timnya, dan menjelaskan bahwa dia tidak ada nilainya bagi bisnis. Jelaskan bahwa manajer dengan tingkat ketidakmampuan ini jauh lebih mudah untuk digantikan daripada tim di bawah ini.

Tidak ada alasan bagus untuk bertahan dengan manajer seperti itu, tetapi itu tidak berarti bahwa pengembang harus mengundurkan diri secara otomatis. Belum tentu ada yang salah dengan bisnisnya, hanya dengan individu yang satu ini. Perbaiki masalah itu.

Dan untuk mencegah penyembunyian dari manajemen tingkat atas, jelaskan bahwa ini bukan kesalahan yang bisa dimaafkan. Ini menandakan bahwa manajer yang bertanggung jawab tidak memiliki pemahaman tentang tim yang ia kelola. Itu tidak cocok untuk memperbaiki, juga tidak perlu di pasar tenaga kerja saat ini. Manajer sangat tergantikan seperti halnya pelatih olahraga. Pemilik tidak memecat tim.

Sekarang, ini mungkin terlihat seperti strategi yang dapat menjadi bumerang. Tetapi pertimbangkan: jika manajemen atas berpihak pada manajer Anda, Anda akan berada pada posisi yang kalah. Jadi, jika Anda hanya mempertimbangkan situasi di mana Anda belum dalam posisi kehilangan itu, hasilnya kemungkinan akan jauh lebih positif. Risiko sebenarnya adalah bahwa manajemen tingkat atas hanya memecat seluruh tim, termasuk manajer. Hanya Anda yang bisa memperkirakan risiko itu. Rupanya output Anda diinginkan, kalau tidak mereka tidak akan meminta lebih dari itu, tetapi pada harga berapa?


5
Dengan kata lain, angkat kedua tangan Anda ke udara, ratap, dan lempar. Sikap seperti ini tidak pernah menyelesaikan masalah. Ada banyak cara yang lebih baik untuk menangani situasi ini.
MrFox

Tidak. Menangis, atau mengamuk adalah aksi drama. Itu bisa diabaikan. Apa yang saya usulkan adalah ultimatum. Entah manajer ini pergi, atau tim pergi. Tidak ada drama, hanya logika bisnis dingin. Dia tidak cocok untuk pekerjaan itu, dan tugas manajemen tingkat atas untuk bertindak atas hal itu. Tetapi pilihan yang mereka sukai mungkin mengabaikan situasi, jika Anda mengizinkannya. Itu sebabnya Anda harus mengambil pilihan itu.
MSalters

@nathanhayfield Khas? Saya pikir tim akan terdiri dari berbagai kepribadian dan orang. Yang malas harus alamat secara individual bukan permintaan selimut kepada tim.
James Khoury

1
@MSalters Ada banyak orang di berbagai lapisan bisnis yang tidak akan memahami hal-hal tertentu. Pendekatan yang benar adalah untuk mengurangi konflik dan mendidik semua orang yang terlibat. Mungkin manajer ini tidak mengerti Agile, tetapi mereka mungkin memiliki kualitas penebusan lainnya (yang mungkin jauh lebih penting). Sebagai seorang profesional, Anda harus membuat yang terbaik dari setiap situasi dan bekerja dengan setiap jenis kepribadian - karena itu sebenarnya konstruktif dan bermanfaat dalam jangka panjang. Melakukan apa yang Anda sarankan tidak ada artinya.
MrFox

3
@ McFox: Manajer langsung seharusnya memahami penjadwalan; sebenarnya mereka adalah layer yang paling bertanggung jawab untuk itu. Anggota tim seharusnya ahli masalah dan manajemen tingkat yang lebih tinggi jauh dari tindakan. Jadi manajer ini, dalam posisi di mana ia adalah membuat klaim tentang jadwal, membuktikan dia tidak mengerti apa yang mungkin tugas yang paling penting. Jika pasar kerja ketat, mendapatkan manajer yang lebih baik mungkin menyusahkan. Tetapi hari ini Anda dapat menemukan seseorang yang lebih baik.
MSalters

Pengalaman saya adalah bahwa sangat, sangat sulit untuk meningkatkan kecepatan sebenarnya dari sebuah tim, mengingat bahwa tim, domain masalah atau tumpukan teknologi tidak berubah.

Di mana saya dapat mencapai peningkatan, itu adalah masalah:

  • membersihkan utang teknis; memastikan bahwa semuanya menjalankan versi yang benar (belum tentu terbaru!), bahwa kode tersebut diperhitungkan dengan baik, dan bahwa tidak ada redundansi dalam sistem (kode duplikat, kode yang tidak digunakan, dll.)

  • meningkatkan praktik; berpasangan jika memungkinkan (ya, saya telah menemukan bahwa meningkatkan kecepatan), meluangkan waktu untuk refactor secara agresif (ditto!), dan menjadi kejam tentang ruang lingkup dan fokus

  • menemukan dan / atau membeli alat terbaik untuk pekerjaan itu (mis. ReSharper untuk .NET bernilai emas, Airbrake, dan Splunk untuk pengembangan Ruby, dll.)

Saya setuju dengan orang lain di sini yang mengatakan bahwa manajer Anda yang meminta peningkatan kecepatan secara sewenang-wenang adalah bendera merah. Saya akan mencari pekerjaan lain sebagai prioritas tinggi.


Manajer Anda meminta (atau memberi tahu) tim Anda untuk bekerja lembur. Sementara menghilangkan kemacetan dan mendapatkan efisiensi mungkin sedikit meningkatkan kecepatan Anda, satu-satunya cara untuk mendapatkan peningkatan itu (40%) adalah dengan bekerja berjam-jam, karena Anda perlu memasukkan lebih banyak unit kerja dalam periode waktu tersebut.

Mari kita ambil skenario.

Untuk interaksi dua minggu, katakanlah 10 hari. Utopia akan menjadi 8 jam sehari, dengan titik cerita disarikan menjadi hari kerja. Jadi, dari atas, kecepatan Anda akan menjadi 8. Tapi, orang-orang relistik mungkin mendapatkan dalam 6 jam sehari dengan email, rapat, istirahat kamar mandi, dll. Jadi sekarang Anda di 6 per pengembang. Jadi baseline Anda adalah 6. Misalkan Anda ingin orang-orang bekerja lembur, sekarang ada di 10 jam sehari. Jadi, itu akan menjadi 10 poin kecepatan per pengembang.

Kecepatan Anda akan selalu berfluktuasi, mungkin rendah karena Anda harus berurusan dengan banyak bug selama iterasi itu, mungkin persyaratan hilang, mungkin seseorang jatuh sakit selama beberapa hari. Mungkin itu tinggi karena pekerjaan terlalu tinggi atau tim Anda bekerja lembur.

Tetapi jika Anda di 50 stabil, benar-benar untuk mencapai 70 akan membutuhkan jam tambahan.


Masalah dengan kecepatan adalah bahwa itu adalah variabel dependen, output terukur dari proses pengembangan Anda. Menuntut untuk meningkatkan kecepatan 40% seperti mencoba bekerja lebih cepat dengan meneriaki mobil agar lebih cepat. Kecepatan meningkat dengan memasukkan lebih banyak bahan bakar dan udara ke dalam mesin atau mendapatkan mobil yang lebih cepat, plus menemukan rute dengan lalu lintas yang lebih sedikit.

Bekerja lebih lama tidak menambah kecepatan jika Anda mengukurnya dengan benar, katakan dalam poin fitur per jam pengembang. Ini hanya berfungsi jika Anda mengukur poin per hari dan kemudian mendefinisikan kembali apa "hari" di pertengahan pengukuran. Ini hanya memberikan ilusi kecepatan.

Peningkatan kecepatan memerlukan peningkatan variabel independen dalam proses dev; komputer dan kompiler yang lebih cepat, sistem pembangunan yang lebih efisien, proses desain yang lebih baik, pengembang yang lebih cakap, ruang kerja yang lebih baik, motivasi super-duper. Peningkatan 40% akan membutuhkan perubahan yang sangat signifikan.

Tanyakan apakah manajer Anda akan mempertimbangkan untuk menempatkan tim Anda di kantor-kantor tertutup di sekitar ruang kerja bersama, membeli perangkat keras pengembang baru, atau mempekerjakan beberapa pengembang senior yang benar-benar senior untuk membimbing tim jika itu akan memberinya 40%. Jika tidak ada sumber daya yang tersedia untuk meningkatkan input ke proses dev Anda, itu cukup banyak mengesampingkan minat tulus untuk meningkatkan. Ini membuat rekayasa balik manajer Anda untuk mencari tahu apa yang benar-benar memotivasi dirinya, yang akan menjadi topik utas keseluruhan.


Yah, saya agak terkejut bahwa jawaban lain menanggapi permintaan bos dengan serius. Seseorang yang menuntut peningkatan produktivitas 40% tidak tahu apa-apa tentang pengembangan perangkat lunak.

Saya masih menikmati membaca Phil Factor tentang topik ini:

Ada dua rute dasar ke manajemen TI. Anda dapat mempelajari perdagangan Anda melalui darah, keringat dan air mata, dan secara bertahap menaiki tangga, berdasarkan kredibilitas yang Anda peroleh dari pengetahuan teknis yang diperoleh dengan susah payah dan proyek yang berhasil. Atau, Anda bisa mengenakan setelan dan dasi yang tajam, mempelajari istilah-istilahnya, dan berbicara dengan lancar menuju ke puncak.

Kedua rute itu tampaknya sama efektifnya. Berurusan dengan trah yang terakhir tentu dapat menyebabkan beberapa saat cemas dan tidak percaya ... bahkan putus asa ... dan beberapa di antaranya didokumentasikan dalam cerita-cerita ini.

Namun, mudah untuk menjadi sedih dan pahit ketika seseorang menghadapi ketidakmampuan teknis dalam posisi kekuasaan, dan untuk menjaring semua manajer dengan kuas yang sama. Phil menasihatinya. Sebagian besar manajer bekerja keras dan berkontribusi dengan baik pada perusahaan, dan bahkan manajer yang buruk dapat dilatih hingga standar yang disyaratkan, jika Anda hanya mengikuti beberapa pedoman sederhana. Ini adalah bagian dari tanggung jawab tim Anda untuk membantu fungsi manajer Anda dengan cara yang akan menguntungkan semua orang.

Pada akhirnya, jika Anda tidak bisa melatih mereka, membuat mereka dipromosikan, atau menghindari mereka, mungkin Anda bisa belajar untuk mencintai mereka hanya karena kontribusi mereka yang tidak disengaja kepada komedi yang kaya di tempat kerja.

Saran untuk tidak menjadi "sedih dan sakit hati" adalah yang terbaik yang bisa Anda dapatkan. Jangan melawan bos yang secara teknis tidak kompeten dalam hal teknis. Dia hanya akan melihatnya sebagai serangan pribadi.


Yah saya pikir hal semacam ini tergantung pada model manajemen yang Anda berlangganan. Coaching Leader: seorang ahli yang diakui yang membuat tangannya kotor dan mengajarkan orang lain bagaimana menjadi baik, tetapi umumnya tetap "sang Guru". Direktur Kepemimpinan: "ahli" yang tahu segalanya (atau berpikir dia tahu) dan hanya memberi perintah dan memberi tahu orang apa yang harus dilakukan. Kepemimpinan oleh delegasi: mungkin bukan ahli, percaya pada keahlian mereka dan memfasilitasi Kepemimpinan yang mendukung: pemandu sorak untuk kelompok membantu membangun mereka, memotivasi, meyakinkan tim bahwa mereka dapat melakukannya dan membantu mereka mencapainya.
Curtis Reed

Manajer Anda telah salah memahami penggunaan kecepatan. Ini bukan metrik dan bukan target. Tujuannya adalah kalibrasi beban kerja tim per sprint.
Jika Anda memikirkannya, kecepatan Anda muncul dari tebakan terbaik, yang Anda ukur kembali setelah setiap sprint. Biasanya seiring berjalannya waktu, ia harus menjadi agak stabil. Tapi itu tidak mengubah fakta bahwa itu adalah produk sampingan dari apa yang sebenarnya dilakukan tim Anda: menciptakan nilai bagi pelanggan Anda.

Alasan mengapa salah menggunakannya sebagai target dan / atau metrik adalah karena hal itu akan menjadikannya metrik kesombongan. Ini akan terlihat bagus di atas kertas, tetapi tidak akan mencerminkan apakah produk Anda memenuhi kebutuhan pelanggan Anda atau tidak. Dan itulah yang paling penting (saya harap).


sejauh yang saya tahu, ini sudah dijelaskan dalam jawaban lain : "rentang yang mengekspresikan kapasitas rata-rata tim selama beberapa periode historis. Ini adalah analisis statistik kinerja masa lalu, yang kemudian dapat digunakan untuk memproyeksikan perkiraan probabilistik dari beban kerja masa depan kapasitas atau waktu siklus ... "
agas

@gnat bagian dari itu ya, meskipun jawaban itu tidak mengatakan apa-apa tentang menggunakan kecepatan sebagai metrik kesombongan, yang masih penting, karena bagi banyak manajer melakukan hal-hal bodoh berdasarkan nomor proxy. OP mengatakan dia merasa itu salah, tetapi tidak bisa menjelaskannya. Saya merasa bahwa istilah metrik kesombongan (dari The Lean Startup) menawarkan penjelasan yang bagus.
Stefan Billiet

Mengenai pengalaman saya dan langsung ke intinya.

Pertama, Anda dapat mengembang perkiraan tetapi itu tidak berarti Anda melakukan lebih banyak.

Kedua (premis: tanpa menggembungkan, hanya fokus dalam kecepatan tim),

Cobalah untuk menemukan keterampilan di dalam tim Anda. Apakah mereka mengerjakan yang terbaik? Apakah Anda memerlukan arsitek sistem untuk membuat keputusan sulit mengenai pembangunan aplikasi dan hal-hal rumit? Bagaimana tim menghabiskan upaya mereka? Mereka menghabiskan waktu meneliti solusi untuk masalah mereka, refactoring, membuat keputusan bisnis atau apa?

Apakah mereka nyaman, fokus, dan diperkirakan? Apa yang terjadi selanjutnya untuk mereka?

Ini bukan "saya didorong pada batas" ... itu lebih seperti pertanyaan untuk seluruh tim "Apakah kita berada di batas?" dan "Bagaimana kita bisa mendorong batas?" ...

Saya telah memimpin tim berkinerja tinggi (untuk konstruksi dan / atau migrasi pertama) ... motivasi tim adalah kunci keberhasilan ... dan merencanakan bagaimana dasar aplikasi akan menjadi sangat penting. Kadang-kadang saya atau tim mendapatkan peran Arsitek Sistem dan memutuskan bagaimana dan ke mana "benda" itu harus pergi.

Terkadang ketika saya melihat bahwa tim saya kehilangan efisiensi, saya mencoba untuk istirahat dan mengundang mereka keluar untuk minum bir, atau sesuatu yang mereka sukai. Ini menyelesaikan setiap konflik dan pada hari berikutnya mereka fokus lagi.

PENJUALAN...

Jika jelaskan alasan Anda tidak dapat meningkatkan kecepatan, gunakan ROI.

Scrum fokus pada apa yang paling penting bagi klien. Secara teoritis tugas yang paling menguntungkan.

Jika masalah Anda adalah tentang menjual upaya pengembangan, apa yang menurut Anda menjual apa ROI dari upaya pengembangan bukannya langsung mengkonversi poin cerita ke "harga". Jika Anda dapat membuktikan bahwa tim Anda bekerja dengan ROI tinggi, siapa yang akan menanyai Anda? Juga, setiap tim memiliki batasnya jika tim telah menemukan "ukuran kenyamanan" -nya, coba sedikit demi sedikit peningkatan bulan, jika mereka tidak dapat menyelesaikan semua tugas ini adalah (mungkin) batasnya.

Tunjukkan riwayat tugas, pendapatan laba (jika tersedia), titik cerita yang telah Anda gunakan, dan tunjukkan bahwa PRODUKTIVITAS BUKAN UPAYA TIM adalah perhitungan yang ditentukan oleh tim untuk mengevaluasi kompleksitas dan mungkin waktu untuk mendapatkan sesuatu Selesai

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.