Иштеп чыгуучулар тапшырмаларды баалоо үчүн кандай ыкмаларды колдонушат?

Баарыңарга салам! Иштеп чыгууну баштоо үчүн талап кылынган теория абдан кеңири. Кээ бир адистерде (Java жана башка тилдердеги бэк-эндди иштеп чыгуучуларда) бул көбүрөөк, ал эми башкаларында (мисалы, JavaScript-те фронтондук иштеп чыгуучулар - React Native) бир аз азыраак. Бирок, экөө тең техникалык гана эмес, ошондой эле "уюштуруучулук" бorмдердин чоң запасына ээ болушу керек. Бул "уюштуруучулук" бorм фронт менен бэкэндди иштеп чыгуучулар үчүн кесorшкен чекиттердин бири болуп саналат. Бүгүн мен мындай техникалык эмес, уюштуруучулук бorмдердин бир аспектиси жөнүндө - тапшырманы баалоо (баалоо) жөнүндө айткым келет. Мен Agile методологиясында (чындыгында эң популярдуу деп эсептелген) гана иштегендиктен, анын Scrum бөлүмүндө, мен Scrum контекстинде тапшырманы баалоону карайм . Мен дароо айтам, баалоо деп да аталат, бул кыйын. Жеке мен үчүн иштеп чыгуучу катары бул жумуштун эң кыйын/каалабаган аспектилеринин бири. Тапшырманы баалоого таасир эте турган көптөгөн ар кандай факторлор бар. Ошол эле учурда, мындан аркы өнүгүү пландары сиздин божомолдоруңузга негизделет.

Рейтингди туура албасаңызчы?

Эгерде иштеп чыгуучу бир тапшырманы аткарууга аягында сарпталуучу сааттан көп убакыт коротсо, анда ал эң мыкты адис эместей сезorши мүмкүн, анткени баа абдан туура эмес болгон. Мындайча айтканда, асмандагы бармак. Ошол эле учурда, эгерде иштеп чыгуучу болжолдонгон убакытта каражат салбаса, ал кардардын продукт/жаңы функцияны чыгаруу пландарына коркунуч келтирет. Бул бизнес, ал эми бизнес акча дегенди билдирет жана мындай пункцияны аз гана кардарлар жагат. Чынында, мен баалоону жактырбайм, анткени кээде тапшырманы аткаруунун так убактысын аныктоо абдан кыйын.

Убакыт кантип бааланат?

Эреже катары, баалоо саат же окуя пункттарында жүргүзүлөт. Жеке мен окуя пункттарында баалоо процессине алда канча жакынмын . Эгер саат физикалык нерсе болсо, анда жаңылышы мүмкүн болгон нерсе, окуянын пункттары бир аз башка нерсе жөнүндө, абстракттуураак. Адатта, программалык камсыздоону иштеп чыгуу топтору убакыт форматында баа беришет: сааттар, күндөр, жумалар, айлар. Мындай убакытты баалоо негизинен жеке тажрыйбага, божомолдорго же интуицияга негизделген. Бул учурда, иштеп чыгуучулар жөн гана тапшырманы карап, аларга канча убакыт талап кылынарын айтышат. Натыйжада, алар өтө сейрек так болуп саналат, анткени ишти аяктоо мөөнөтүнө таасир этүүчү факторлор өтө көп. Ошондуктан, Agile методологиясы боюнча иштеген көптөгөн командалар окуя пункттарын колдонушат. Келгиле, аны аныктап көрөлү.

Окуя пункттары деген эмне

Окуя пункту - бул иштин белгилүү бир чөйрөсүн (функционалдык) толук ишке ашыруу үчүн зарыл болгон жалпы күч-аракетти баалоону билдирген өлчөө бирдиги. Башкача айтканда, бул салыштырмалуу татаалдык . Командалар иштин татаалдыгына, иштин көлөмүнө жана тобокелдикке же белгисиздикке жараша окуянын упайларын дайындайт. Эреже катары, бул баалуулуктар жумушту майда бөлүктөргө бөлүү үчүн, ошону менен белгисиздикти жок кылуу үчүн дайындалат. Убакыттын өтүшү менен бул командаларга берилген убакыттын ичинде эмнеге жетише аларын түшүнүүгө жардам берет жана иштин кийинки багыттарын так пландаштырууга жардам берет. Бул сизге таптакыр карама-каршы сезorши мүмкүн, бирок бул абстракция чындыгында абдан пайдалуу: ал команданы иштин татаалдыгы жөнүндө катаал чечимдерди кабыл алууга түртөт. Келгиле, пландоодо окуяны колдонуунун кээ бир себептерин карап көрөлү:

• убакыт аралыгында так эмес баалоодон качууга болот;
• Убакыттын өтүшү менен баалоодон айырмаланып, кошумча чыгымдарды жакшыраак эске алса болот: команда мүчөлөрү менен кардар ортосундагы байланыштар, команданын ар кандай талкуулары жана пландаштыруу, ошондой эле күтүлбөгөн жагдайлар;
• Ар бир команда ишти башка шкала боюнча баалайт, бул алардын ылдамдыгы (упайлар менен өлчөнгөн) ар кандай болот;
• Ар бир окуя пунктун дайындоо үчүн масштабды аныктоо менен, сиз көп талашсыз упайларды тез бөлүштүрө аласыз.

Окуя пункттарын кантип колдонбоо керек

Тилекке каршы, окуя пункттары көбүнчө башка максаттар үчүн колдонулат. Окуя пункттары адамдарды баалоо, деталдаштырылган мөөнөттөрдү жана ресурстарды аныктоо үчүн колдонулганда жана жаңылыштык менен иштин бир өлчөмү катары кабыл алынганда кемчorктер болушу мүмкүн. Анын ордуна, командалар аларды ар бир тапшырмадагы иштин көлөмүн/татаалдыгын түшүнүү жана артыкчылыктарды берүү үчүн колдонушу керек. Мүмкүн, татаалыраак деп бааланган бөлүктөрдү спринт аяктаганга чейин бүтүрүү үчүн, адегенде жасалышы мүмкүн , бирок жеңилдерин кийинчерээк артка жылдырууга болот. Scrum методологиясынын контекстинде спринт эмне экенин эскертип кетейин : Бул убакыттын узактыгы команда менен кардар ортосундагы макулдашуу боюнча иштеп чыгуунун башында аныкталат. Бул эки жума же бир ай, же башка мезгил болушу мүмкүн. Эреже катары, тапшырманы баалоо спринттин акырына чейин аткарылган иштин мүмкүн болгон көлөмүн пландаштыруу үчүн спринттин башталышында жүргүзүлөт, ал эми бүткөрүлгөн жумуш заказчыга тапшырылат. Бул продуктту иштеп чыгуудагы прогрессиңизди көрүүгө, кардардан пикир алууга жана долбоордун өнүгүшүн кардардын көз карашына ылайык өзгөртүүгө жардам берет. Бирок, биз бир аз чегинебиз: келгиле, баалоого кайрылалы. Бир гана иштеп чыгуучу тарабынан тапшырмаларды баалоо өтө субъективдүү болмок. Ошондуктан, эреже катары, бул командалык иш. Команданы баалоонун бир нече ыкмалары бар. Бүгүн биз алардын эң көп колдонулганын карап чыгабыз - Scrum poker . Бул ыкма ушул Scrum покеринин лидери боло турган менеджерди талап кылат . Бул Scrum Master же PM боюнча адистешкен адам болушу мүмкүн .

Scrum Poker деген эмне

Scrum покер - же пландоо покери - макулдашууга жетишүүгө негизделген баалоо ыкмасы. Негизинен алдыдагы иштин татаалдыгын же программалык камсыздоону иштеп чыгууда чечиле турган милдеттердин салыштырмалуу көлөмүн баалоо үчүн колдонулат. Мен дароо белгилеп кетем, Scrum покер өнүгүүдө кеңири таралган практика жана сиз анын кандай жырткыч экенин сөзсүз бorшиңиз керек. Бул процесс үчүн биз, адатта, белгилүү бир тапшырманы командалык баалоону уюштурууга мүмкүндүк берген кандайдыр бир тиркемени же веб-сайтты колдонобуз. Бул кантип болот? Команда артта калган нерсени (жаңы тапшырма, функционалдуулук) алат, мүмкүн болуучу тузактарды жана аны менен байланышкан башка нюанстарды кыскача талкуулайт. Ар бир катышуучу андан кийин алардын кыйынчылык рейтингин билдирген номери бар картаны тандайт. О, жана баалоодо кадимки катарлар эмес, Фибоначчи сандары колдонулат . Фибоначчи сандары скрам покеринде абдан популярдуу , анткени алардын ортосундагы ажырым убакыттын өтүшү менен көбөйөт (пирамида деңгээлин эске салат). Эбегейсиз татаалдыгы бар милдеттер бар жана аз сандагы окуяларга жетишүү мүмкүн эмес. адаттан тыш карталар үчүн түшүндүрмө:

акыркы чекиттердин белгисиз саны

чексиз узак милдет

тыныгуу керек

Баалоонун сейрек кездешүүчү ыкмалары:

• футболка өлчөмдөрүндө - S, M, L, XL
• же иттерде - чихуауа, пуг, такшунд, бульдог жана башкалар (менин оюмча, бул көйгөйлөрдү баалоо үчүн эң кызык бирдик =D)

Андан кийин команда бир эле маселеге ар кандай иштеп чыгуучулар тарабынан берилген бааларды салыштырат жана алар макул болушса, сонун! Эгерде андай болбосо, анда баалоодогу (аргументтердеги) айырмачылыктардын себептерин талкуулоо зарыл. Ушундан кийин, биз чогуу бир баага келе алабыз, аны менен баары макул болот, плюс же минус. Ооба, эмне үчүн покер олуттуу программалык камсыздоо долбоорун пландаштыруу үчүн колдонулат? Кантсе да, бул кандайдыр бир кызык. Чынында, мындай геймификация команда мүчөлөрүн өз алдынча ой жүгүртүүгө үндөйт, алардан өз натыйжаларын командалаштары менен бир убакта көрсөтүүнү суранат. Бул өз кезегинде команданын башка мүчөлөрүнүн көз карашына көз карандылыктан качат. Болбосо, азыраак тажрыйбалуу иштеп чыгуучулар тажрыйбалуу топтун мүчөлөрүнүн баалоолорун карап, аларга таянышат, бул алардын өз баалоонун пайдалуулугун жокко чыгарат. Бирок натыйжалардын бир эле учурда ачылышы менен бул иш жүзүндө мүмкүн эмес. Scrum Poker пландоо колдонмосунун мисалы Atlassianдан .

Тапшырманы баалоонун мисалы

Сиздин команда окуя пункттарында баалоо үчүн белгилүү бир шкала аныктады деп элестетип көрөлү: Scrum Poker тапшырманы аткарууда башталат жана сиз аны төмөнкүдөй баалайсыз:

• Сиз буга чейин ушул сыяктуу функцияларды ишке ашыруу менен иштеген эмессиз - +3
• орто тапшырманын функционалдуулугу - +2
• тапшырманы ишке ашыруу жогорку татаалдыкка ээ - +3
• Бул функция үчүн жазуу тесттеринин жогорку татаалдыгы - +3

Натыйжада, сиз 11 сюжеттик упай аласыз, бирок андай карта жок болгондуктан, сиз 13 сунуштайсыз. Дагы бир кесиптешиңиз тапшырманы баалайт:

• буга чейин ушундай көйгөй менен иштеген - +1
• орто тапшырманын функционалдуулугу - +2
• тапшырманы ишке ашыруу орточо татаалдыкка ээ - +2
• Бул функция үчүн жазуу тесттеринин орточо татаалдыгы - +2

Натыйжада, ал 7 окуя упай алат, бирок Fibonacci сандарында мындай нерсе жок, ал мүмкүн болушунча жакын саны менен картаны жайгаштырат - 8. Башка команда мүчөлөрү, тиешелүүлүгүнө жараша, өздөрүнүн субъективдүү көз караштарынын негизинде баа беришет. Андан кийин, сиз өз натыйжаларыңызды көрсөтөсүз жана дээрлик бардык кесиптештериңиз 13 деген баа бергенин билесиз, ага 8 берген бир иштеп чыгуучудан башкасы. Бул учурда ага сөз берилет жана ал жүйөөлөрдү келтирет. Жана алар, мисалы, мындай: ал мурда бир эле маселе менен иштеген жана бул көрүнгөндөй кыйын эмес, акырында ал команданын калган мүчөлөрүн чечимди 13төн 8ге өзгөртүүгө көндүрөт. ким бул милдетти колго алса, ошону чечет, жардам берерин айтат. Же, акыры, ал муну өзү жасайт. Ал эми жалпысынан алганда, анын аргументтерин башкалар угабы же укпайбы, бул маанилүү эмес, анткени тигил же бул тапшырмага рейтинг ыйгарылат жана команда кийинкиси менен таанышууга өтөт. Биринчи жолу эсептер так эмес болуп калат, ошондой эле сиз кийинки убакыт аралыгында (спринт) жасоону пландаштырган ишиңиздин көлөмүнө баа берүү туура эмес болот. Анткени, бул эсептөөлөр так эсепке негизделген. Бир нече убакыттан кийин, болжол менен үч ай, команда тапшырмаларды так баалай баштайт жана бир спринтте команда бүтүрө ала турган жумуштун орточо көлөмү көрүнүп калат. Бирок бул иштин көлөмүн жалпы пландаштыруу, бул убакыт жөнүндө көбүрөөк, жана бул учурда таасир этүүчү көптөгөн ар кандай факторлор болушу мүмкүн. Мисалы, иштеп чыгуучулардын бири эки жумага эс алууга кеткен. Башкача айтканда, пландаштырылган иштердин белгилүү бир көлөмүн чийип салышыңыз керек (пландалган функция). Же командага жаңы иштеп чыгуучу келди, бирок ага толук ишенүүнүн кереги жок, анткени... сиз onboarding деп аталган долбоорго көнүү үчүн талап кылынган убакытты эске алышыңыз керек . Бул долбоордун татаалдыгына жараша эки жума, плюс же минус жума болушу мүмкүн. Ушунун баары бүгүнкү күндө, мен сиздин бorмиңизди көйгөйдү баалоо сыяктуу техникалык эмес бөлүгүндө бир аз жакшырттым деп үмүттөнөм. Эгерде сиз бул темага, ошондой эле Scrum деталдарына тереңирээк кирүүнү кааласаңыз, мен сизге Жефф Сазерленддин "SCRUM" китебин окууну сунуш кылам. Мен кесепеттерге кепилдик бере албайм, анткени андан кийин сизде Scrum Master болууну тажатма каалоо пайда болушу мүмкүн =D