Apakah kaedah yang digunakan oleh pembangun untuk menilai tugasan?

Hai semua! Teori yang diperlukan untuk memulakan pembangunan adalah sangat luas. Sesetengah pakar (pembangun bahagian belakang dalam Java dan bahasa lain) mempunyai lebih banyak daripada itu, manakala yang lain (contohnya, pembangun bahagian hadapan dalam JavaScript - React Native) mempunyai lebih sedikit. Walau bagaimanapun, kedua-duanya mesti mempunyai stok yang besar bukan sahaja teknikal, tetapi juga pengetahuan "organisasi". Pengetahuan "organisasi" ini ialah salah satu titik persimpangan untuk pembangun bahagian hadapan dan belakang. Hari ini saya ingin bercakap tentang satu aspek pengetahuan organisasi bukan teknikal seperti itu - tentang penilaian tugas (anggaran). Dan kerana saya hanya bekerja dalam metodologi Agile (yang sebenarnya dianggap paling popular), dalam subbahagiannya, Scrum , saya akan mempertimbangkan penilaian tugas dalam konteks Scrum . Saya akan katakan dengan segera bahawa penilaian, juga dipanggil anggaran, adalah sukar. Bagi saya secara peribadi sebagai pembangun ini adalah salah satu aspek pekerjaan yang paling sukar/tidak diingini. Terdapat banyak faktor berbeza untuk dipertimbangkan yang boleh mempengaruhi penilaian tugas. Pada masa yang sama, rancangan untuk pembangunan selanjutnya akan berdasarkan ramalan anda.

Bagaimana jika anda tidak mendapat penilaian yang betul?

Jika pembangun menghabiskan lebih banyak jam pada tugas daripada yang akan dibelanjakan pada akhirnya, nampaknya dia bukanlah pakar terbaik, kerana anggarannya sangat tidak tepat. Jadi untuk bercakap, jari di langit. Pada masa yang sama, jika pembangun tidak melabur dalam masa yang diramalkan, dia menjejaskan rancangan pelanggan untuk mengeluarkan produk/ciri baharu. Ini adalah perniagaan, dan perniagaan bermakna wang, dan beberapa pelanggan akan menyukai tusukan sedemikian. Ini sebenarnya sebab saya tidak suka anggaran, kerana kadangkala sukar untuk menentukan masa yang tepat untuk menyelesaikan tugasan.

Bagaimanakah masa dinilai?

Sebagai peraturan, anggaran dijalankan dalam jam atau titik cerita. Secara peribadi, saya lebih dekat dengan proses penilaian dalam titik cerita . Jika jam tangan adalah sesuatu yang fizikal, maka sesuatu yang boleh disalah anggap, titik cerita adalah sedikit tentang sesuatu yang lain, lebih abstrak. Biasanya, pasukan pembangunan perisian memberikan anggaran dalam format masa: jam, hari, minggu, bulan. Anggaran masa sedemikian adalah berdasarkan terutamanya pada pengalaman peribadi, tekaan atau gerak hati. Dalam kes ini, pembangun hanya melihat tugas itu dan menyuarakan anggaran berapa lama masa yang diperlukan untuk mereka. Akibatnya, mereka sangat jarang tepat, kerana terdapat terlalu banyak faktor yang boleh menjejaskan tarikh akhir untuk menyiapkan kerja. Oleh itu, banyak pasukan yang bekerja mengikut metodologi Agile menggunakan titik cerita. Mari kita fikirkan.

Apakah mata Cerita

Titik cerita ialah unit ukuran yang menyatakan penilaian jumlah usaha yang diperlukan untuk melaksanakan sepenuhnya bidang kerja tertentu (fungsi). Iaitu, ini adalah kerumitan relatif . Pasukan memberikan titik cerita berdasarkan kerumitan kerja, skop kerja dan risiko atau ketidakpastian. Lazimnya, nilai ini ditugaskan untuk memecahkan kerja dengan lebih cekap kepada bahagian yang lebih kecil, dengan itu menghapuskan ketidakpastian. Dari masa ke masa, ini membantu pasukan memahami perkara yang boleh mereka capai dalam tempoh masa tertentu dan membantu mereka merancang bidang kerja seterusnya dengan lebih tepat. Ini mungkin kelihatan berlawanan dengan intuisi anda, tetapi abstraksi ini sebenarnya agak berguna: ia mendorong pasukan untuk membuat keputusan yang lebih sukar tentang kerumitan kerja. Mari lihat beberapa sebab untuk menggunakan titik cerita dalam perancangan:

• ketidaktepatan anggaran dalam selang masa boleh dielakkan;
• Tidak seperti menganggarkan dari semasa ke semasa, kos overhed boleh diambil kira dengan lebih baik: komunikasi antara ahli pasukan dan pelanggan, pelbagai perbincangan dan perancangan pasukan, serta situasi yang tidak dijangka;
• Setiap pasukan akan menilai kerja pada skala yang berbeza, yang bermaksud kelajuan mereka (diukur dalam mata) akan berbeza;
• Dengan menentukan skala untuk menetapkan setiap titik cerita, anda boleh mengedarkan mata dengan cepat tanpa banyak kontroversi.

Bagaimana TIDAK menggunakan titik cerita

Malangnya, titik cerita sering digunakan untuk tujuan lain. Titik cerita boleh cacat apabila ia digunakan untuk menilai orang, menentukan tarikh akhir dan sumber yang terperinci, dan apabila ia tersilap diambil sebagai ukuran prestasi. Sebaliknya, pasukan perlu menggunakannya untuk memahami kelantangan/kerumitan kerja dalam setiap tugas dan memberi keutamaan. Ada kemungkinan bahagian yang dinilai sebagai lebih sukar perlu dilakukan terlebih dahulu supaya ia boleh disiapkan sebelum tamat larian pecut , tetapi bahagian yang lebih mudah boleh ditolak semula ke kemudian. Biar saya ingatkan anda apa itu pecut dalam konteks metodologi Scrum : Berapa lama tempoh masa ini ditentukan pada permulaan pembangunan melalui persetujuan antara pasukan dan pelanggan. Ini boleh menjadi tempoh dua minggu atau sebulan, atau mana-mana tempoh lain. Sebagai peraturan, anggaran tugasan dijalankan pada permulaan pecut untuk merancang jumlah kerja yang mungkin disiapkan menjelang akhir pecut, apabila kerja yang telah siap dihantar kepada pelanggan. Ia membantu anda melihat kemajuan anda dalam pembangunan produk, menerima maklum balas daripada pelanggan dan melaraskan pembangunan projek mengikut visi pelanggan. Namun begitu, kita menyimpang sedikit: mari kita kembali kepada anggaran. Menilai tugas oleh hanya satu pembangun akan menjadi terlalu subjektif. Oleh itu, sebagai peraturan, ini adalah kerja berpasukan. Terdapat beberapa teknik untuk penilaian pasukan. Hari ini kita akan melihat yang paling banyak digunakan daripada mereka - Scrum poker . Teknik ini memerlukan pengurus yang akan menjadi seseorang seperti ketua poker Scrum ini . Ini mungkin orang yang pakar dalam Scrum Master atau PM .

Apa itu Scrum Poker

Scrum poker - atau poker perancangan - ialah teknik penilaian yang berdasarkan mencapai persetujuan. Digunakan terutamanya untuk menilai kerumitan kerja yang akan datang atau jumlah relatif tugasan yang perlu diselesaikan semasa pembangunan perisian. Saya akan ambil perhatian segera bahawa poker Scrum adalah amalan biasa dalam pembangunan, dan anda pastinya perlu mengetahui jenis binatang itu. Untuk proses ini, kami biasanya menggunakan beberapa jenis aplikasi atau tapak web yang membolehkan kami mengatur penilaian pasukan untuk tugas tertentu. Bagaimana ini berlaku? Pasukan mengambil item tunggakan (tugas baharu, fungsi), membincangkan secara ringkas kemungkinan perangkap dan nuansa lain yang berkaitan dengannya. Setiap peserta kemudian memilih kad dengan nombor yang mewakili penilaian kesukaran mereka. Oh, dan apabila menganggar, bukan siri biasa yang digunakan, tetapi nombor Fibonacci . Nombor Fibonacci sangat popular dalam poker scrum kerana jurang antara mereka meningkat dari semasa ke semasa (mengingatkan tahap piramid). Terdapat tugas yang akan mempunyai kerumitan yang besar, dan sebilangan kecil titik cerita tidak dapat dicapai. Penjelasan untuk kad luar biasa:

bilangan titik akhir yang tidak diketahui

satu tugas yang tidak terhingga panjangnya

perlukan rehat

Kaedah anggaran yang lebih jarang berlaku:

• dalam saiz baju-T - S, M, L, XL
• atau dalam anjing - chihuahua, pug, dachshund, bulldog, dan sebagainya (pada pendapat saya, ini adalah unit yang paling aneh untuk menilai tugasan =D)

Pasukan itu kemudian membandingkan anggaran yang diberikan kepada masalah yang sama oleh pembangun yang berbeza, dan jika mereka bersetuju, bagus! Jika tidak, perlu dibincangkan sebab-sebab perbezaan penilaian (hujah). Selepas ini, kita boleh bersama-sama membuat anggaran tunggal, yang semua orang, tambah atau tolak, akan bersetuju. Nah, mengapa poker digunakan untuk merancang projek perisian yang serius? Lagipun, ini entah bagaimana pelik. Malah, gamifikasi sedemikian menggalakkan ahli pasukan untuk berfikir secara bebas, meminta mereka menunjukkan keputusan mereka pada masa yang sama dengan rakan sepasukan mereka. Ini, seterusnya, mengelakkan pergantungan pada pandangan ahli pasukan lain. Jika tidak, pembangun yang kurang berpengalaman akan melihat dan bergantung pada penilaian ahli pasukan yang lebih berpengalaman, yang akan menafikan kegunaan penilaian mereka sendiri. Tetapi dengan pembukaan serentak keputusan, ini pada dasarnya mustahil. Contoh aplikasi penjadualan Scrum Poker adalah daripada Atlassian .

Contoh penilaian tugas

Mari bayangkan bahawa pasukan anda telah mengenal pasti skala tertentu untuk penilaian dalam mata cerita: Scrum Poker bermula pada tugas, dan anda menilainya seperti ini:

• anda tidak pernah bekerja dengan pelaksanaan fungsi yang serupa sebelum ini - +3
• kefungsian tugasan bersaiz sederhana - +2
• pelaksanaan tugas mempunyai kerumitan yang tinggi - +3
• kerumitan tinggi ujian penulisan untuk fungsi ini - +3

Hasilnya, anda mendapat 11 mata cerita, tetapi memandangkan tiada kad sedemikian, anda menawarkan 13. Seorang lagi rakan sekerja anda menilai tugas itu:

• bekerja dengan masalah yang sama sebelum - +1
• kefungsian tugasan bersaiz sederhana - +2
• pelaksanaan tugas mempunyai kerumitan purata - +2
• kerumitan purata ujian penulisan untuk fungsi ini - +2

Akibatnya, dia mendapat 7 mata cerita, tetapi tidak ada perkara seperti itu dalam nombor Fibonacci, dan dia meletakkan kad dengan nombor yang paling hampir mungkin - 8. Ahli pasukan lain, sewajarnya, memberikan anggaran berdasarkan pandangan subjektif mereka. Seterusnya, anda menunjukkan keputusan anda dan mendapati bahawa hampir semua rakan sekerja anda memberikan anggaran 13, kecuali seorang pembangun yang memberikannya 8. Dalam kes ini, dia diberi alasan dan dia memberikan alasan. Dan mereka, sebagai contoh, adalah seperti ini: dia bekerja sebelum ini dengan masalah yang sama, dan ia tidak sesukar yang mungkin kelihatan, dan pada akhirnya dia meyakinkan ahli pasukan yang lain untuk menukar penyelesaian mereka dari 13 kepada 8 cerita mata, mengatakan bahawa dia akan membantu sesiapa yang mengambil tugas ini akan memikirkannya. Atau, pada akhirnya, dia akan melakukannya sendiri. Dan secara umum, tidak kira sama ada orang lain mendengar hujahnya atau tidak, kerana satu cara atau yang lain, penilaian akan diberikan kepada tugas ini, dan pasukan akan beralih untuk membiasakan diri dengan tugas seterusnya. Pada kali pertama, anggaran akan menjadi tidak tepat, begitu juga dengan anggaran jumlah kerja yang anda rancang untuk lakukan dalam tempoh masa berikutnya (pecut). Lagipun, anggaran ini dibuat dengan tepat berdasarkan anggaran. Selepas beberapa lama, kira-kira tiga bulan, pasukan akan mula menganggarkan tugas dengan lebih tepat, dan purata jumlah kerja yang boleh diselesaikan oleh pasukan setiap pecut akan kelihatan. Tetapi ini adalah perancangan umum skop kerja, ia lebih kepada masa, dan dalam kes ini mungkin terdapat banyak faktor berbeza yang mempunyai kesan. Sebagai contoh, salah seorang pemaju pergi bercuti selama dua minggu. Iaitu, anda perlu memotong sejumlah kerja yang dirancang (fungsi terancang). Atau pembangun baharu telah datang ke pasukan, tetapi anda tidak perlu bergantung sepenuhnya kepadanya, kerana... anda perlu mengambil kira masa yang diperlukan untuk menyesuaikan diri dengan projek, dipanggil onboarding . Ini mungkin dua minggu, tambah atau tolak seminggu, bergantung pada kerumitan projek. Itu sahaja untuk hari ini, saya harap saya telah meningkatkan sedikit pengetahuan anda dalam bahagian bukan teknikal pengetahuan seperti anggaran masalah. Jika anda ingin mendalami topik ini, serta butiran Scrum, saya amat menasihati anda untuk membaca buku "SCRUM" oleh Jeff Sutherland. Saya tidak boleh menjamin akibatnya, kerana mungkin selepas itu anda akan mempunyai keinginan yang menjengkelkan untuk menjadi Master Scrum =D