Loading...
RoYaL avatar RoYaL Trainer 6847 Точки

Предложение за процеса и изискванията за отборните проекти

Инспириран от темата за записването за Javascript apps отборните проекти, искам да изложа едни свои виждания в лицето им на предложения, как би трябвало да протече работата по отборния проект, така че ясно да се открои кой е работил и кой не и да няма субективизъм. Или както Кико каза в другата тема - да не става така, че по-силните да не оставят по-слабите да работят, а после на всичкото отгоре да излязат и да кажат, че останалите не са работили.

Минава записването. Отборите се разпределят. На всеки отбор се дава 1 ден да излъчи кандидати за "Team leader". След това на отборът се дава 1 ден да гласува за тези кандидати, като гласуването за себе си не е позволено. (Естествено има го вариантът всеки да събере един глас, тук може да се измисли нещо по-хитро?). Съответно излъчва се Team leader на отбора.

Тук трябва да има строги изисквания какъв ще е процесът, който всеки отбор трябва да следва. Основната задача, освен да пише код, на тим лидера ще е да се грижи установеният процес да работи.

Процесът, който ще предложа е инспириран от съвременните методологии за проджект мениджмънт

Нека вземем за пример, че за отборния проект след установяване на кой ще е тим лидер остават 20 дни. От тук започва да тече и deadline-а на проекта.

20 дни се разделят на ПЕТ четиридневни итерации. Първата итерация задължително е установяване на останалите роли в проекта. След като учим HQC и Unit testing предлагам за задължително да има един QA в отбора.

Останалите ЧЕТИРИ итерации трябва да са изцяло development, testing && integrating насочени.

Според изискванията на отборния проект, например, всеки член е задължен да има по 5 къмита в 5 различни дни, тим лидерът се нагърбва с тежката задача, да разпредели достатъчно продуктивни задачи на съотборниците си, така че всяка задача да изисква поне един къмит, и така до поне 5тия къмит.

Всяка задача ТРЯБВА да се логва в тракинг системата която се ползва. В случая, ако е задължително използването на Github - в тракинг системата на гитхъб (Issues таба).

На представянето на екипния проект да може да се каже за някой съотборник, че не е участвал, САМО АКО не са успели да се свържат с него или след като са успели и е добавен към колабораторите на репозиторито и са му асайннати ПЕТ или повече валидни задачи, той НЕ Е резолвнал ПОНЕ ПЕТ от тях и съответно НЯМА ПЕТ къмита в 5 различни дни (или итерации най-добре).

Ако тимлидерът не се справи с тази задача, отборът може да излъчи чисто демократично друг такъв. Ако отборният проект фейлне заради лоша организация от към тим лидер, виновни са всички - за избирането на такъв тим лидер и за неуспешното избиране на нов такъв.

За цялостното оценяване на проекта да се гледа не само крайния продукт, но и процесът на работа, след като всичко ще се траква в тикети, разпределени в итерации, да се гледа дали срокът на итерациите а спазен и други неща, които говорят за успешното или съответно неуспешното сработване на отборите.

Също така може да се види какви точно са били разпределени задачите, и дали на някого не му е разпределено просто да ъпдейтва README.md с по 1 символ на таск.

Ако смятате, че идеята с подобен проектов мениджмънт ще е трудна да се реализира заради например недостатъчно опит на участващите, предлагам да се организира кратък курс по Съвременни практики за управление на проекти, с времетраенето на Javascript OOP курса.

13
Предложения и проблеми 29/11/2014 00:52:44
kiko144 avatar kiko144 795 Точки

Здравейте и от мен! 
Много се радвам, че има такива теми и подобни предложения, защото смятам, че така все пак ще се стигне до една "идеална" система. А начина това да стане е точно ние - студентите - да даваме feedback и идеи.

Колкото до конкреното предложение - доста ми допада, но наистина има някои кусури.

  1. Какво става, ако няма кандидати за team leader? Мисля, че това ще е доста често срещано нещо. Средно има по 30 отбора на курс. Мислите ли, че има 30 човека с опит на лидери, които да могат да преценят възможностите на даден човек, да му дават задачи, които хем да го мотивират, хем да има полза за проекта? И ако да, дали те са достатъчно отговорни да го правят? Аз лично, не мисля, че бих успял, и не съм сигурен, че съм бил в отбор с човек, който би.
  2. Това с итерациите е добро, но от моят опит забелязвам, че масово всички се сещат да пишат по екипните в последната една седмица и дори и Наков да дойде да ги моли, няма да се навият.

Плюсовете според мен са:

  • Попадаш в много близка до реалната среда и добиваш някаква представа как трябва да стават нещата, което е най-ценното. 
  • Хора, които са нерешителни и не знаят какво да направят по проекта все пак допринасят за него.

Ако стигнем до един идеален SoftUni то би трябвало менторите да правят това, но ми се струва мноооого нереално, освен ако не са хора без работа :D

Въпрос до  Karlie : Според теб, ако на отборния ви проект по OOП имаше човек, който да ви натиска и ви дава задачки през цялото време, които можете да накодите, бихте ли направили по-добра игра? 

Мнение относно поста на milen8204 : Идеята е яка, но ако има точно определени роли и се знае всеки какво трябва да направи, няма ли да се изгуби Тиймуърка? Според мен проектът ще стане просто като някаква по-сложна задача от домашните.

0
Karlie avatar Karlie 438 Точки

Кико, мисля, че да, ако имахме team leader щяхме да се хванем по-рано за работа и да направим нещо по-завършено. НО, според мен, този вариант е:

- доста теоретичен. Както много хора казаха преди мен, не винаги има доброволци да са тийм лийдъри и всъщност точно това се случи при нас - нямаше някой желаещ да загуби страшно много време в разпределяне на задачи и помагане на по-слабите (ако предположим, че TL е с опит).

- по-скоро вреден за успеха. Работата по проектите никога не ми е носила толкова знания, колкото домашните. Не за първи път казвам ,че се записвам на отборна работа не за да си науча материала от курса, а за да се ориентирам как се работи по по-голям проект (да дълбаеш чуждия код, да недоумяваш какво са правили нинджите и да се научиш да не се панираш и комплексираш като се сравняваш с тях). За мен, тъй като съм начинаеща и всеки курс ми носи абсолютна нова информация, отборните проекти са нещо второстепенно. Не в смисъла на по-маловажни, а в смисъла на нещо, което идва второ. Както покрива е безспорно важен за една къща, но ако няма основи - ходи слагай покрива! Ако имаше някой, който да ме насилва да работя през целия срок на курса основно по проекта, научила-недонаучила, на изпита щях да имам по-нисък резултат. То и затова според мен хората бачкат по проекта основно в последните дни. Така е по-добре, струва ми се, всеки да си преценява силите, кога е готов и може с нещо да помогне.

(В тази връзка, браво на колегите, които са предложили на Наков за настоящия курс по JS Aps да изнесе същественото (BaaS-a) като второ домашно!)

С други думи, аз не искам да имаме назначени тийм лийдъри, още по-малко пък искам мен да ме назначат за такъв! Просто нямам време за това, а и не мисля, че е от полза. Е, ако съм на работа, няма не искам и друг решава, кое е полезно за фирмата :)

Хайде и от мен един въпрос: нали правите нещо подобно на TL  в присъствените отбори с менторите, как е там?

0
RoYaL avatar RoYaL Trainer 6847 Точки

Менторите са само теоретични тим лидери. Много от нещата, които един тим лидер трябва да изпълнява на тях по правило са им забранени. А останалите пожелателни неща, някои от тях не ги и вършат. Например първият ни ментор се отнесе много несериозно.

P.S.: Дори мешаницата по кода, в която ти се налага да се ориентираш (което смяташ за полезно, всъщност, и безспорно е, де...) може да се менажира и да е по-малко, ако тим лидерът се постарае да разпредели така задачите, че да няма някакви огромни колизии или gap-ове.

 

@Кико, всъщност огромният проблем е това сещане да се работи последните дни. Някак си ми се иска да се избегне и да се отдаде повече важност на екипните проекти. Честно казано нямам конкретно теоретическо решение как да стане. До колкото до това дали има хора с такива качества и то достатъчно много - ами може би наистина няма, но това нез начи, че няма да се развият впоследствие.

0
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.