Cara apa sing digunakake pangembang kanggo ngevaluasi tugas?

Halo kabeh! Teori sing dibutuhake kanggo miwiti pembangunan iku akeh banget. Sawetara spesialis (pangembang backend ing Jawa lan basa liyane) duwe luwih akeh, dene liyane (contone, pangembang frontend ing JavaScript - React Native) duwe kurang. Nanging, loro-lorone kudu duwe saham gedhe ora mung teknis, nanging uga kawruh "organisasi". Kawruh "organisasi" iki minangka salah sawijining titik persimpangan kanggo pangembang frontend lan backend. Dina iki aku arep kanggo pirembagan bab siji aspek non-teknis, kawruh organisasi kuwi - bab evaluasi tugas (estimasi). Lan wiwit aku makarya mung ing metodologi Agile (sing nyatane dianggep paling populer), ing subpart sawijining, Scrum , Aku bakal nimbang Assessment tugas ing konteks Scrum . Aku bakal langsung ngomong yen taksiran, uga disebut estimasi, angel. Kanggo kula pribadi minangka pangembang iki salah siji sing paling angel / aspèk undesirable proyek. Ana macem-macem faktor sing kudu dipikirake sing bisa mengaruhi penilaian tugas. Ing wektu sing padha, rencana kanggo pangembangan luwih lanjut bakal adhedhasar ramalan sampeyan.

Apa yen sampeyan ora entuk rating sing bener?

Yen pangembang mbuwang luwih akeh jam kanggo tugas tinimbang sing bakal ditindakake ing pungkasan, bisa uga dheweke dudu spesialis sing paling apik, amarga perkiraan kasebut ora akurat. Dadi ngomong, driji ing langit. Ing wektu sing padha, yen pangembang ora nandur modal ing wektu sing diprediksi, dheweke bakal mbebayani rencana pelanggan kanggo ngeculake produk / fitur anyar. Iki minangka bisnis, lan bisnis tegese dhuwit, lan sawetara pelanggan bakal seneng tusukan kasebut. Iki pancene aku ora seneng ngira, amarga kadhangkala angel banget kanggo nemtokake wektu sing tepat kanggo ngrampungake tugas.

Kepiye wektu ditaksir?

Minangka aturan, estimasi ditindakake sajrone jam utawa titik crita. Secara pribadi, aku luwih cedhak karo proses evaluasi ing titik crita . Yen jam tangan minangka barang fisik, mula ana sing bisa salah, titik crita rada babagan liya, luwih abstrak. Biasane, tim pangembangan piranti lunak menehi prakiraan ing format wektu: jam, dina, minggu, wulan. Perkiraan wektu kasebut utamane adhedhasar pengalaman pribadi, guesswork, utawa intuisi. Ing kasus iki, pangembang mung ndeleng tugas kasebut lan menehi perkiraan suwene suwene. Akibaté, padha arang banget akurat, amarga ana akeh banget faktor sing bisa mengaruhi deadline kanggo ngrampungake karya. Mulane, akeh tim sing makarya miturut metodologi Agile nggunakake titik crita. Ayo dadi tokoh metu.

Apa titik crita

Titik crita minangka unit pangukuran sing mratelakake pambiji saka total gaweyan sing dibutuhake kanggo ngetrapake area kerja tartamtu (fungsi). Sing, iki minangka kerumitan relatif . Tim nemtokake titik crita adhedhasar kerumitan karya, ruang lingkup karya, lan risiko utawa kahanan sing durung mesthi. Biasane, nilai kasebut ditugasake supaya luwih efisien ngrusak karya dadi bagean sing luwih cilik, saéngga ngilangi kahanan sing durung mesthi. Swara wektu, iki mbantu tim ngerti apa sing bisa digayuh ing wektu tartamtu lan mbantu ngrancang wilayah kerja sabanjure kanthi luwih akurat. Iki bisa uga ora cocog karo sampeyan, nanging abstraksi iki pancen migunani banget: nyurung tim kanggo nggawe keputusan sing luwih angel babagan kerumitan karya. Ayo goleki sawetara alasan kanggo nggunakake titik crita ing perencanaan:

• estimasi ora akurat ing interval wektu bisa nyingkiri;
• Ora kaya ngira-ngira wektu, biaya overhead bisa dianggep luwih apik: komunikasi antarane anggota tim lan pelanggan, macem-macem diskusi lan perencanaan tim, uga kahanan sing ora dikarepake;
• Saben tim bakal ngetung karya ing skala sing beda-beda, tegese kacepetan (diukur ing poin) bakal beda;
• Kanthi nemtokake skala kanggo nemtokake saben titik crita, sampeyan bisa kanthi cepet nyebarake poin tanpa akeh kontroversi.

Carane ora nggunakake titik crita

Sayange, titik crita asring digunakake kanggo tujuan liyane. Titik crita bisa cacat nalika digunakake kanggo ngira-ngira wong, nemtokake tenggat wektu lan sumber daya, lan nalika salah dijupuk minangka ukuran kinerja. Nanging, tim kudu nggunakake kanggo ngerti volume / kerumitan karya ing saben tugas lan kanggo prioritas. Bisa uga bagean-bagean sing dianggep luwih angel kudu ditindakake dhisik supaya bisa rampung sadurunge pungkasan sprint , nanging sing luwih gampang bisa ditindakake maneh. Ayo kula ngelingake sampeyan apa sprint ing konteks metodologi Scrum : Suwene wektu iki ditemtokake ing wiwitan pangembangan kanthi persetujuan antarane tim lan pelanggan. Iki bisa dadi periode rong minggu utawa sasi, utawa periode liyane. Minangka aturan, estimasi tugas ditindakake ing wiwitan sprint supaya bisa ngrancang jumlah karya sing bisa rampung ing pungkasan sprint, nalika karya rampung dikirim menyang pelanggan. Iki mbantu sampeyan ndeleng kemajuan ing pangembangan produk, nampa umpan balik saka pelanggan lan nyetel pangembangan proyek miturut visi pelanggan. Nanging isih, kita nyimpang sethithik: ayo bali menyang perkiraan. Ngevaluasi tugas dening mung siji pangembang bakal subyektif banget. Mulane, minangka aturan, iki kerja tim. Ana sawetara teknik kanggo penilaian tim. Dina iki kita bakal katon ing paling digunakake - Scrum poker . technique iki mbutuhake manager sing bakal dadi wong kaya pimpinan iki Scrum poker . Iki bisa dadi wong sing duwe spesialisasi ing Scrum Master , utawa PM .

Apa Scrum Poker

Scrum poker - utawa planning poker - iku sawijining technique evaluasi sing adhedhasar tekan persetujuan. Utamane digunakake kanggo netepake kerumitan karya ing ngarep utawa volume relatif tugas sing kudu ditanggulangi sajrone pangembangan piranti lunak. Aku bakal Wigati langsung sing Scrum poker laku umum ing pembangunan, lan temtunipun kudu ngerti apa jenis kewan iku. Kanggo proses iki, kita biasane nggunakake sawetara jinis aplikasi utawa situs web sing ngidini kita ngatur penilaian tim babagan tugas tartamtu. Kepiye kedadeyan iki? Tim njupuk item backlog (tugas anyar, fungsi), sedhela rembugan bisa pitfalls lan nuansa liyane gadhah. Saben peserta banjur milih kertu kanthi nomer sing nuduhake tingkat kesulitan. Oh, lan nalika ngira, dudu seri biasa sing digunakake, nanging nomer Fibonacci . Nomer Fibonacci dadi populer ing scrum poker amarga longkangan antarane wong-wong mau mundhak liwat wektu (kaya tingkat piramida). Ana tugas sing bakal duwe kerumitan gedhe banget, lan sawetara titik crita ora bisa digayuh. Panjelasan kanggo kertu sing ora biasa:

nomer ora dingerteni saka endpoints

tugas dawa tanpa wates

butuh istirahat

Cara estimasi sing luwih langka:

• ukuran kaos - S, M, L, XL
• utawa ing asu - chihuahua, pug, dachshund, bulldog, lan liya-liyane (menurutku, iki minangka unit paling aneh kanggo ngevaluasi tugas =D)

Tim banjur mbandhingaké prakiraan diwenehi kanggo masalah padha dening pangembang beda, lan yen padha setuju, apik! Yen ora, perlu kanggo ngrembug alesan kanggo beda penilaian (argumen). Sawise iki, kita bisa bebarengan teka menyang taksiran siji, kang saben wong, plus utawa minus, bakal setuju. Inggih, kok poker malah digunakake kanggo rencana proyek lunak serius? Sawise kabeh, iki piye wae aneh. Nyatane, gamifikasi kasebut nyengkuyung anggota tim supaya mikir kanthi mandiri, njaluk supaya nuduhake asile bebarengan karo kanca-kancane. Iki, ing siji, ngindhari katergantungan ing views saka anggota tim liyane. Yen ora, pangembang sing kurang pengalaman bakal katon lan ngandelake penilaian anggota tim sing luwih berpengalaman, sing bakal negate kegunaan penilaian dhewe. Nanging kanthi mbukak asil bebarengan, iki pancen ora mungkin. Conto app jadwal Scrum Poker saka Atlassian .

Tuladha pambiji tugas

Bayangake manawa tim sampeyan wis nemtokake skala tartamtu kanggo evaluasi ing titik crita: Scrum Poker miwiti tugas, lan sampeyan ngevaluasi kaya iki:

• sampeyan durung tau nggarap implementasine fungsi sing padha sadurunge - +3
• fungsi saka tugas medium-ukuran - +2
• implementasine saka tugas wis kerumitan dhuwur - +3
• kerumitan dhuwur saka tes nulis kanggo fungsi iki - +3

Akibaté, sampeyan entuk 11 poin crita, nanging amarga ora ana kertu kasebut, sampeyan nawakake 13. Kolega liyane ngevaluasi tugas kasebut:

• nggarap masalah sing padha sadurunge - +1
• fungsi saka tugas medium-ukuran - +2
• implementasine saka tugas wis kerumitan rata-rata - +2
• kerumitan rata-rata tes nulis kanggo fungsi iki - +2

Akibaté, iku 7 TCTerms crita, nanging ora ana ing nomer Fibonacci, lan sijine kertu karo nomer paling cedhak - 8. Anggota tim liyane, miturut, menehi prakiraan adhedhasar views subyektif. Sabanjure, sampeyan nuduhake asil lan nemokake yen meh kabeh kolega menehi perkiraan 13, kajaba siji pangembang sing menehi 8. Ing kasus iki, dheweke diwenehi lantai lan menehi alasan. Lan padha, contone, kaya iki: sadurunge makarya karo masalah padha, lan iku ora angel kaya koyone, lan pungkasanipun convinces liyane saka anggota tim kanggo ngganti solusi saka 13 kanggo 8 crita. TCTerms, ngandika sing bakal bantuan sapa njupuk ing tugas iki bakal tokoh metu. Utawa, ing pungkasan, dheweke bakal nindakake dhewe. Lan umume, ora preduli manawa wong liya ngrungokake bantahane utawa ora, amarga kanthi cara siji utawa liyane, rating bakal ditugasake kanggo tugas iki, lan tim kasebut bakal sinau babagan sing sabanjure. Kaping pisanan, prakiraan bakal ora akurat, uga perkiraan jumlah karya sing bakal ditindakake sajrone wektu sabanjure (sprint). Sawise kabeh, prakiraan kasebut digawe kanthi tepat adhedhasar perkiraan. Sawise sawetara wektu, kira-kira telung sasi, tim bakal miwiti ngira-ngira tugas kanthi luwih akurat, lan jumlah rata-rata karya sing bisa ditindakake tim saben sprint bakal katon. Nanging iki minangka perencanaan umum ruang lingkup kerja, luwih akeh babagan wektu, lan ing kasus iki bisa uga ana macem-macem faktor sing duwe pengaruh. Contone, salah sawijining pangembang lunga ing liburan rong minggu. Yaiku, sampeyan kudu nyabrang sawetara karya sing direncanakake (fungsi sing direncanakake). Utawa pangembang anyar wis teka ing tim, nanging sampeyan ora perlu ngetung kanthi lengkap, amarga ... sampeyan kudu njupuk menyang akun wektu sing dibutuhake kanggo ngganti menyang project, disebut onboarding . Iki bisa dadi rong minggu, plus utawa minus seminggu, gumantung saka kerumitan proyek kasebut. Semono wae kanggo dina iki, muga-muga sampeyan bisa nambah kawruh babagan kawruh non-teknis kayata estimasi masalah. Yen sampeyan pengin luwih jero babagan topik iki, uga rincian Scrum, aku menehi saran supaya maca buku "SCRUM" dening Jeff Sutherland. Aku ora bisa njamin akibat, amarga mbok menawa sawise sampeyan bakal duwe kepinginan ngganggu kanggo dadi Master Scrum =D