(UA) IT/Tech Ukrainians in Canada
-
Не ображайся синку, таке життя. Того хто сам навчився грати на кобзі як правило не беруть керувати симфонічним оркестром. Тай у сам оркестр теж щось не дуже беруть. Можна грати у переходах та на ярмарках і непогано заробляти на життя. Але щоб чогось досягнути тут - треба мати мову, знайомих, та місцевий менталітет. Це я дуже спрощено пояснюю, вибачаюсь заздалегідь.
-
щаслива ти людина, не зрозумів про що мова 😥
-
Поінти ставим всі разом. Читаєм текст таски, всі кажуть оцінку (мідл, сеньори), берем ту оцінку на яку всі погоджуються. Якщо я кажу що там 2 поінти, інший каже що 3 а мідл каже що 5 - то ставиться оцінка 5. Потім я беру ту таску, бачу що там нефіг дєлать, роблю за день і знижую оцінку з 5 до 2. Але якщо ти не хочеш так робити то можеш просто за 1 день зробити, потім 2 дня робити вид що працюєш - і теж буде норм, бо оцінка ж була 5 а ти за 3 дня зробив
-
Тобто, через те що на плануванні потребують «таку оцінку, що підійде всим» вони більше під слабших людей, бо слабші люди голосують за оцінки повище. Далі, коли сеньор бере таку «переоцінену» таску, це вже залежить від його настрою/лінивості/упоротості/чесності він зробить за стільки як оцінено (оцінено мідлом по суті) чи швидше
-
У нас на рефайнментах якщо є такий розброс (хтось каже 2, хтось 3, а хтось 5) - ми не ставимо просто найвищий, а просимо аргументувати, чому саме 5 (або 2), і в процесі обговорення краще розуміємо один одного та погоджуємочь на якусь цифру
-
Мені здається, все ж таки у вас сторі пойнти скоріше сприймаються як міра часу, що невірно. Об'єктивна складність окремого тікета не залежить від рівня розробників, і якщо є така ситуація, що хтось постійно ставить вищі бали, це може просто говорити про недостатнє обговорення тікету на рефайнменті, недостатньо детальний опис чи потенційно завеликі тікети, які треба ділити на менші. В команді, в якій є джуни, мідли і сіньйори, середня продуктивність на людину в сторі пойнтс пер спрінт все одно має бути приблизно на рівні мідла, тому що сіньйори втрачатимуть більше часу на код рев'ю та менторінг, а джуни будуть підтягуватись завдяки менторінгу, pair programming, etc
-
«Чому саме 5 а не 2» - людина відповідає «ну там же не просто 1 строчку поміняти, там же мені ще треба потестити та юніт тести написати» І все. Не поспориш. Тестити можна від забору і до обіду. Писати юніт тести теж понятіє растяжимоє - можна 2 написати, можна 20, і все це прокатить як «писав два дня юніт тести»
-
Ще скажу таку річ, сіньйор, який просто кодить швидше за інших - це не сіньйор, це стронг мід :-)
-
Тю Менторинг не повинен залежити від бажань керівництва чи наявності dedicated meetings/time slots 😊 Мідл: "а як краще оце зробити?" Сіньйор: "отак" Це не менторинг Сіньйор: "тут є декілька варіантів, оце неприйнтяне тому що ..., оце більш менш, але не дуже, тому що ..., а оцей варіант працює краще за все - ми використаємо такий-то паттерн, що дозволить нам підвищити readability/maintainability, а абстракція отак і отак суттєво підвищить reusability" Оце менторинг (хоча й дуже банальний приклад) - і для нього не треба окремі мітинги, це може і має відбуватись щоденно, тому що гарний сіньйор - це людина, до якої ти прийдеш з питанням, а підеш не тільки з відповіддю, але й з новими знаннями. Якщо когось взяли на сіньйора, а він не тягне - це має бути видно в quarterly чи якихось там review, і далі то вже задача менеджера розбиратись, що робити далі. У мене в команді, коли я був тім лідом, був випадок, коли взяли дуже язикатого чувака на міда, а він в кращому разі був середнім джуном. Зробили все можливе і неможливе, щоб його підтягнути, але - просто може це не його - не вдалося, тому просто звільнили
