Penuhi tarikh akhir anda: kaedah yang digunakan oleh pembangun untuk menganggarkan usaha

Hai semua! Terdapat sejumlah besar teori yang perlu anda ketahui untuk memulakan pembangunan perisian. Sesetengah pakar (contohnya, pembangun bahagian belakang yang menggunakan Java dan bahasa lain) mengetahui lebih lanjut mengenainya, manakala yang lain (contohnya, pembangun bahagian hadapan yang menggunakan JavaScript dan React Native) mungkin mengetahui sedikit sebanyak. Yang berkata, kedua-dua kumpulan mesti memiliki badan besar bukan sahaja teknikal, tetapi juga pengetahuan "organisasi". Pengetahuan "organisasi" ini ialah satu bidang pertindihan untuk pembangun bahagian hadapan dan bahagian belakang. Hari ini saya ingin bercakap tentang satu aspek pengetahuan organisasi bukan teknikal ini. Hari ini kita akan bercakap tentang anggaran usaha . Kerana saya hanya mempunyai pengalaman menggunakan metodologi Agile(yang dianggap paling popular), lebih khusus rangka kerja Scrum, saya akan mempertimbangkan anggaran usaha dalam konteks Scrum . Pada mulanya, saya mesti mengatakan bahawa anggaran usaha adalah sukar. Bagi saya, ia adalah salah satu aspek yang paling mencabar/tidak menyenangkan dalam tugas saya sebagai pembangun. Terdapat banyak faktor berbeza untuk dipertimbangkan yang boleh menjejaskan anggaran anda tentang usaha yang diperlukan untuk sesuatu tugas. Selain itu, rancangan pembangunan masa hadapan akan berdasarkan anggaran anda.

Bagaimana jika anda memberikan anggaran yang tidak baik?

Jika pembangun menganggarkan lebih banyak jam untuk sesuatu tugas daripada yang akhirnya dibelanjakan untuk tugas itu, kepakaran mereka mungkin diragui kerana anggaran itu sangat tidak tepat. Dalam erti kata lain, ia adalah tekaan liar. Pada masa yang sama, jika pembangun tidak menyelesaikan kerja dalam masa yang diramalkan, dia menjejaskan rancangan pelanggan untuk mengeluarkan produk atau ciri baharu. Ini adalah perniagaan, dan perniagaan adalah wang. Beberapa pelanggan akan berpuas hati dengan slip sedemikian. Malah, itulah sebabnya saya tidak suka anggaran — kerana kadangkala amat sukar untuk menentukan masa yang diperlukan untuk menyelesaikan tugasan dengan tepat.

Cara membuat anggaran masa

Sebagai peraturan, anggaran dibuat dalam jam atau titik cerita. Keutamaan peribadi saya adalah untuk melakukan proses anggaran menggunakan titik cerita . Sukar untuk disalah anggap tentang objek fizikal konkrit, tetapi titik cerita lebih abstrak sedikit. Pasukan pembangunan perisian biasanya memberikan anggaran sebagai jumlah masa: jam, hari, minggu, bulan. Anggaran masa ini berdasarkan terutamanya pada pengalaman peribadi, tekaan dan/atau gerak hati. Dalam kes ini, pembangun hanya melihat tugas itu dan menyatakan andaian mereka tentang berapa lama masa yang mereka perlukan. Akibatnya, anggaran ini sangat jarang tepat, kerana terdapat terlalu banyak faktor yang boleh mempengaruhi tempoh kerja. Itulah sebabnya banyak pasukan yang menggunakan metodologi Agile juga menggunakan titik cerita. Jom terjun!

Apakah titik cerita?

Titik cerita ialah unit ukuran untuk menyatakan anggaran jumlah usaha yang diperlukan untuk melaksanakan fungsi tertentu sepenuhnya. Iaitu, kita bercakap tentang relatifkerumitan. Pasukan memberikan anggaran dalam titik cerita berdasarkan kerumitan kerja, jumlah kerja dan risiko atau ketidakpastian. Nilai ini biasanya ditugaskan untuk membahagikan kerja dengan lebih cekap kepada kepingan yang lebih kecil, dengan itu menghapuskan kekaburan. Dari masa ke masa, ini membantu pasukan memahami perkara yang boleh mereka capai dalam tempoh masa tertentu dan membantu mereka merancang bahagian kerja berikutnya dengan lebih tepat. Ini mungkin terdengar berlawanan dengan intuisi anda, tetapi abstraksi ini sememangnya berguna: ia mendorong pasukan untuk membuat keputusan yang sukar tentang kerumitan kerja. Mari kita lihat beberapa sebab untuk menggunakan titik cerita semasa merancang:

• Anda boleh mengelakkan anggaran masa yang tidak tepat.
• Tidak seperti anggaran yang dibuat dalam unit masa, titik cerita membolehkan anda mengambil kira kos overhed: komunikasi antara ahli pasukan dan pelanggan, pelbagai perbincangan pasukan dan aktiviti perancangan, serta situasi yang tidak dijangka.
• Setiap pasukan akan menganggarkan kerja mereka menggunakan skala yang berbeza, yang bermaksud kapasiti mereka (diukur dalam mata) akan berbeza.
• Dengan menentukan skala untuk menetapkan setiap titik cerita, anda boleh memperuntukkan mata dengan cepat tanpa banyak kontroversi.

Bagaimana TIDAK menggunakan titik cerita

Malangnya, titik cerita sering disalahgunakan. Perkara cerita boleh mengelirukan apabila ia digunakan untuk menilai orang, mentakrifkan tarikh akhir dan sumber yang terperinci, dan apabila ia disalah anggap sebagai ukuran prestasi. Sebaliknya, pasukan harus menggunakannya untuk memahami skop/kerumitan setiap tugas dan untuk menetapkan keutamaan. Mungkin bahagian yang dianggap lebih sukar harus ditangani terlebih dahulu, supaya ia boleh dilakukan sebelum tamat pecut , mungkin mengalihkan tugas yang lebih mudah kepada kemudian. Biar saya ingatkan anda apa itu pecut dalam konteks metodologi Scrum : Tempoh tempoh masa ini ditentukan apabila pembangunan bermula dan dipersetujui antara pasukan dan pelanggan. Ini boleh menjadi tempoh dua minggu atau sebulan, atau mana-mana tempoh lain. Sebagai peraturan, anggaran usaha dibuat pada permulaan setiap pecut untuk merancang kerja yang boleh disiapkan menjelang akhir pecut, apabila kerja yang telah siap dihantar kepada pelanggan. Demo membantu anda melihat kemajuan anda dalam membangunkan produk, menerima maklum balas daripada pelanggan dan melaraskan trajektori projek mengikut visi pelanggan. Tetapi kita menyimpang sedikit. Mari kita kembali kepada anggaran. Terlalu subjektif jika hanya seorang pembangun memberikan anggaran untuk semua tugas. Jadi proses ini biasanya merupakan usaha berpasukan. Terdapat beberapa teknik yang boleh digunakan oleh pasukan untuk menjana anggaran. Hari ini kita akan melihat teknik yang paling popular: scrum poker . Teknik ini memerlukan pengurus yang akan bertindak sebagai moderator untuk scrum poker . Ini boleh jadi seseorang yang menjadi master scrum atau mungkin PM .

Apakah Scrum poker?

Scrum poker , atau poker perancangan, ialah teknik anggaran yang berdasarkan mencapai persetujuan. Ia digunakan terutamanya untuk menganggarkan kerumitan kerja di hadapan atau saiz relatif tugas pembangunan perisian. Saya akan katakan dengan segera bahawa scrum pokerialah amalan pembangunan perisian yang biasa, dan anda perlu tahu maksudnya. Ia biasanya melibatkan apl atau tapak web untuk memudahkan penciptaan kolaboratif pasukan anggaran untuk tugas tertentu. Bagaimana ini berlaku? Pasukan mengambil sesuatu daripada tunggakan (tugas baharu, beberapa fungsi) dan membincangkan secara ringkas kemungkinan perangkap dan nuansa lain yang berkaitan dengannya. Kemudian setiap peserta memilih kad dengan nombor yang menggambarkan anggaran kerumitan mereka. Oh, satu perkara lagi, apabila membuat anggaran ini, kami menggunakan nombor dalam jujukan Fibonacci dan bukannya nombor biasa. Nombor Fibonacci popular dalam poker scrum, kerana terdapat jurang yang semakin besar di antara mereka (menyerupai tahap piramid). Sesetengah tugasan akan menjadi sangat kompleks dan kami tidak akan dapat melepaskan diri dengan sejumlah kecil titik cerita. Terdapat beberapa kad luar biasa yang mempunyai makna berikut:

Bilangan titik akhir tidak diketahui

Tugas yang tidak terhingga panjang

Perlukan rehat

Kaedah anggaran yang kurang biasa digunakan:

• Saiz baju-T — S, M, L, XL
• Baka anjing — chihuahua, pug, dachshund, bulldog, dan sebagainya (secara peribadi, saya rasa ini adalah unit ukuran yang paling aneh untuk anggaran usaha =D)

Pasukan kemudian membandingkan anggaran yang diberikan oleh pembangun yang berbeza untuk tugas yang sama. Jika mereka bersetuju, maka hebat! Jika tidak, maka alasan (hujah) untuk anggaran yang berbeza perlu dibincangkan. Selepas itu, pasukan bekerjasama untuk membentuk satu anggaran yang diterima oleh semua orang, lebih kurang. Jadi mengapa poker digunakan untuk merancang projek perisian yang serius? Anda harus mengakui bahawa ini adalah pelik. Hakikatnya ialah gamifikasi seperti ini menggalakkan ahli pasukan untuk berfikir secara bebas, menjemput mereka untuk mendedahkan anggaran mereka pada masa yang sama dengan rakan sepasukan mereka. Ini seterusnya mengelak daripada mewujudkan situasi di mana sesetengah ahli pasukan bergantung pada pendapat orang lain. Jika ia tidak dilakukan dengan cara ini, maka pembangun yang kurang berpengalaman akan melihat dan menumpukan pada anggaran yang disediakan oleh ahli pasukan yang lebih berpengalaman, dan itu akan menjadikan anggaran mereka sendiri kurang berguna. Tetapi pada masa yang sama menunjukkan anggaran menjadikan ini pada dasarnya mustahil. Tawaran Atlassianaplikasi poker scrum untuk digunakan dalam proses perancangan.

Contoh anggaran usaha

Katakan pasukan anda menetapkan skala berikut untuk menetapkan titik cerita kepada anggaran: Scrum poker dimainkan untuk setiap tugas, dan anda memberikan anggaran seperti berikut:

• Anda tidak pernah melaksanakan fungsi serupa sebelum ini: +3
• Fungsi ini bersaiz sederhana: +2
• Pelaksanaannya akan menjadi sangat kompleks: +3
• Ujian penulisan untuk kefungsian akan menjadi sangat kompleks: +3

Menambah setiap komponen, anda mendapat sejumlah 11 mata cerita, tetapi tiada kad sedemikian, jadi anda mencadangkan 13. Rakan sekerja mengemukakan anggaran berikut untuk tugas itu:

• Dia telah bekerja dengan tugas yang sama sebelum ini: +1
• Fungsi ini bersaiz sederhana: +2
• Pelaksanaannya akan mempunyai kerumitan purata: +2
• Ujian penulisan untuk kefungsian akan mempunyai kerumitan purata: +2

Hasil perantaraannya ialah 7 titik cerita, tetapi nombor itu tidak wujud dalam siri Fibonacci, jadi dia menyerahkan kad dengan nombor anggaran paling banyak — 8. Ahli pasukan lain juga membuat anggaran mereka berdasarkan pandangan subjektif mereka. Kemudian semua orang menunjukkan kad mereka dan anda mendapati bahawa hampir semua rakan sekerja anda memberikan anggaran sebanyak 13, kecuali seorang pembangun yang mencadangkan 8. Dalam kes ini, dia dibenarkan bercakap untuk memberikan alasan untuk anggarannya yang lebih rendah. Katakan dia menawarkan justifikasi ini: dia pernah mengerjakan tugas yang sama, dan ia tidaklah sesukar yang disangka. Akhirnya, dia meyakinkan seluruh pasukan untuk mengubah fikiran mereka daripada 13 kepada 8 titik cerita, mengatakan bahawa dia akan membantu sesiapa sahaja yang akhirnya mengambil tugas ini. Atau mungkin dia akan melakukannya sendiri. Dalam apa jua keadaan, ia tidak Tidak kira sama ada orang lain menerima hujahnya atau tidak, kerana satu atau lain cara anggaran akan diberikan kepada tugas itu, dan pasukan akan meneruskan untuk mempertimbangkan yang seterusnya. Pada mulanya, anggaran akan menjadi tidak tepat, begitu juga dengan anggaran jumlah kerja yang anda rancang untuk dilakukan dalam tempoh masa yang akan datang (pecut). Lagipun, anggaran ini dibuat menggunakan anggaran. Selepas beberapa lama, mungkin tiga bulan kemudian, pasukan akan mula menganggarkan masa yang diperlukan untuk tugasan dengan lebih tepat, dan jumlah purata kerja yang mampu dilakukan oleh pasukan dalam larian pecut akan menjadi jelas. Tetapi ini adalah proses untuk membuat rancangan am untuk skop kerja. Ia memberi tumpuan terutamanya pada masa, tetapi dalam kes ini mungkin terdapat banyak faktor berkaitan yang berbeza. Sebagai contoh, katakan seorang pemaju pergi bercuti selama dua minggu. Anda perlu memotong sejumlah kerja yang dirancang (fungsi terancang). Atau andaikan pembangun baharu telah menyertai pasukan itu, tetapi belum mencapai kelajuan sepenuhnya, jadi anda perlu memberi masa kepadanya untuk membiasakan diri dengan projek itu melaluiproses onboarding . Ini mungkin dua minggu, berikan atau ambil masa seminggu, bergantung pada kerumitan projek. Itu sahaja untuk hari ini! Saya harap saya meningkatkan sedikit pengetahuan anda tentang anggaran usaha, aspek bukan teknikal yang diperlukan dalam pembangunan perisian. Jika anda ingin mendalami topik ini, dan butiran scrum, saya amat mengesyorkan anda membaca buku "SCRUM" oleh Jeff Sutherland. Saya tidak boleh berjanji tentang akibatnya, kerana selepas membacanya anda akan mempunyai keinginan yang menjengkelkan untuk menjadi master scrum =D