Не хватает только подписи «Информация прозвучала на правах рекламы продукта Ada… » :)
А если серьезно, то непонятно в чем мысль статьи. Как по мне здесь «смешались в кучу люди, кони...» — тут тебе и DRY и unit-тестирование и exception handling. Связь с hello world прототипами какая-то очень навязанная.
За идею и мнение конечно плюс — соглашусь, что нужно котелок включать всегда, даже в случаях copy/paste. Но вот с хорошим источником — промах.
Попробовал ради интереса на этом сайте поискать исходники или документацию — по многим «page not found» или просто сигнатура метода без каких либо обьяснений. Например, было интересно почитать как работать вот это https://devdocs.io/haxe~java/util/concurrent/executorservice#awaitTermination.
Даже предложеный пример обучения джуниоров тому как работает HashMap — и тут промах :)
1. Люди разные — не все способны принимать критику, признавать свои ошибки и т.д., не говоря уже о том, что значит слово профессионал и какой процент таких людей в команде :)
2. Мне кажется упущен главный момент «в распределенной команде», где люди зачастую и не видели друг друга в лицо и пулл реквесты — это и есть 90% общения. А если учесть, что многие большие компании имеют сотрудников не то что в разных офисах или городах, а на разных континентах. В таких случаях умение правильно комуницировать проблему — это путь к здоровой атмосфере на проекте.
Не стоит забывать, что если человек (с которым вы лично не знакомы) начинает учить жизни — мы начинаем считатать его мудаком нехорошим человеком — так работать защитный механизм на подсознании большинства людей.
Более того, никто не отменял стереотипы. Как бы вы отнеслись если бы некий Камлеш Кумар Кришна начал бы оставлять каменты типа «все не то и все не так».
Так что обеими руками за корректные каменты описанные автором.
Только основываясь на опыте Скрама, Канбан судить не берусь.
Лично в нашей команде главная метрика — успешность спринта, которая основывается на достижении поставленной в начале спринта цели.
К примеру, 8 из 10 задач в спринте крутятся вокруг внедрения нового модуля А. Цель — end-2-end реализация модуля А. Если цель достигнута (все 8 задач выполнены), значит спринт успешен. Даже несмотря на что возможно остальные 2 задачи не были стартованы.
Ориентироваться на Velocity я бы не стал. Если эта метрика растет, это не значит, что вы стали выпускать больший объем задач. Зачастую, если метрика и растет постоянно, то это показатель, что команда начинает давать более реалистичные оценки, не более того. Особенно это характерно для слаженных команд. Для команды из всех новых членов, характеристика должна постепенно улучшаться за счет повышения уровня коммуникации, более глубокие знания предметной области и т.д.
Тема рисков конечно поднята не зря, но кроме знания того, что они были, есть и всегда будут — какой-либо другой конкретики ожидать сложно.
Помнится у нас были люди на проекте, что настолько увлеклись оценкой рисков (а именно какой процент времени нужно накинуть сверх исходного естимейта), что строили мат зависимости, шкалу зависимости от затрагиваемого модуля и кучи параметров. Но по факту, скажу одно — ни к чему это все не привело. Нет единой пилюли для того, чтобы оценка была идеальной.
ИМХО, даже не знаю как можно тренироваться в этом плане.
Единственное, как по мне, решение — это максимум конструктивного диалога во время планирования. Кто-то знает лучше предметную область, кто-то технологии и практики для реализации и совместно получиться более-менее ясная картина.
В общем, это вовсе не догма. Одна из практик, сродни Agile. Кто-то следует, кто-то нет. Один предпочитает быть гибким, другой следует принципу «пиши код бл#$%ть». Важно знать, что подобное существует, а остальное уже ваше личное дело.
Оценка плохо или хорошо очень абстрактная и субъективная.
Вас устроит следующий ответ от менеджера — «Вы хорошо работали и вот вам хороший промоушен — 20 грн. Как по мне, хорошо! Все основано исходя из моего мнения и отчета вашего лида. Спасибо, следующий»
Даже если все и хорошо было с вашей стороны, почему именно такой уровень повышения? Куда идти дальше? Какие мои перспективы и что мне необходимо сделать для этого?
Все эти детали как раз и обсуждаются на review.
Еще раз повторяю — с вашим голосом должны считаться. Вы же не просто марионетка. Тимлид сказал, что все плохо, значит плохо? Так, посто смириться и жить дальше или как?
Есть многие вещи, которые могут и не знать люди, которые пишут о вас отчет, или же попросту упустить. Будь то сертификация, программа менторинга за джунами, помощь в каких-то внутрених проектах компании и куча всего прочего…
Как по мне, ответ довольно предвзятый. И налицо то, что читали по диагонали.
Если в компании все зависит от самопиара, а не от того, как успешно, например, была проведена работа на последнем проекте, были ли выполнены goals, итд, то это верный признак бардака.
Само собой, что все зависит не только от того, как красиво вы себе представите. Как мне казалось, это очевидно. Если нет, простите, в следующий раз буду детальнее выражаться. Менеджер как минимум сам имеет слабое представление о вашей работе от заказчиков, вашего тимлида и других вовлеченных лиц. НО самое главное, что я хотел донести — это то, что во всей это солянке отзывов о вашей работе, ВАШ ОТЗЫВ — НЕМАЛОВАЖЕН!
Как? Как можно оценить Ваши заслуги, если у менеджера более чем 30 человек (и это еще по-божески) «под крылом»?
Даже, если начальство и знает о всех твоих «свершениях» (что зачастую не так), то все равно это своего рода диалог, необходимый вам обоим.
Вы доказываете, что заслужили большего и обсуждаете свои амбиции и возможности. А начальник дает свой фидбек о вашей работе и показывает возможные пути по достижению ваших амбиций.
Как по мне, довольно здравая культура диалога. Без обид, ИМХО.
А если серьезно, то непонятно в чем мысль статьи. Как по мне здесь «смешались в кучу люди, кони...» — тут тебе и DRY и unit-тестирование и exception handling. Связь с hello world прототипами какая-то очень навязанная.
ахаха, вопрос дня на многих it-форумах «How we connect to Amazon Support?»)
Попробовал ради интереса на этом сайте поискать исходники или документацию — по многим «page not found» или просто сигнатура метода без каких либо обьяснений. Например, было интересно почитать как работать вот это https://devdocs.io/haxe~java/util/concurrent/executorservice#awaitTermination.
Даже предложеный пример обучения джуниоров тому как работает HashMap — и тут промах :)
2. Мне кажется упущен главный момент «в распределенной команде», где люди зачастую и не видели друг друга в лицо и пулл реквесты — это и есть 90% общения. А если учесть, что многие большие компании имеют сотрудников не то что в разных офисах или городах, а на разных континентах. В таких случаях умение правильно комуницировать проблему — это путь к здоровой атмосфере на проекте.
Не стоит забывать, что если человек (с которым вы лично не знакомы) начинает учить жизни — мы начинаем считатать его
мудакомнехорошим человеком — так работать защитный механизм на подсознании большинства людей.Более того, никто не отменял стереотипы. Как бы вы отнеслись если бы некий Камлеш Кумар Кришна начал бы оставлять каменты типа «все не то и все не так».
Так что обеими руками за корректные каменты описанные автором.
Thanks a million!
Лично в нашей команде главная метрика — успешность спринта, которая основывается на достижении поставленной в начале спринта цели.
К примеру, 8 из 10 задач в спринте крутятся вокруг внедрения нового модуля А. Цель — end-2-end реализация модуля А. Если цель достигнута (все 8 задач выполнены), значит спринт успешен. Даже несмотря на что возможно остальные 2 задачи не были стартованы.
Ориентироваться на Velocity я бы не стал. Если эта метрика растет, это не значит, что вы стали выпускать больший объем задач. Зачастую, если метрика и растет постоянно, то это показатель, что команда начинает давать более реалистичные оценки, не более того. Особенно это характерно для слаженных команд. Для команды из всех новых членов, характеристика должна постепенно улучшаться за счет повышения уровня коммуникации, более глубокие знания предметной области и т.д.
Помнится у нас были люди на проекте, что настолько увлеклись оценкой рисков (а именно какой процент времени нужно накинуть сверх исходного естимейта), что строили мат зависимости, шкалу зависимости от затрагиваемого модуля и кучи параметров. Но по факту, скажу одно — ни к чему это все не привело. Нет единой пилюли для того, чтобы оценка была идеальной.
ИМХО, даже не знаю как можно тренироваться в этом плане.
Единственное, как по мне, решение — это максимум конструктивного диалога во время планирования. Кто-то знает лучше предметную область, кто-то технологии и практики для реализации и совместно получиться более-менее ясная картина.
Вас устроит следующий ответ от менеджера — «Вы хорошо работали и вот вам хороший промоушен — 20 грн. Как по мне, хорошо! Все основано исходя из моего мнения и отчета вашего лида. Спасибо, следующий»
Даже если все и хорошо было с вашей стороны, почему именно такой уровень повышения? Куда идти дальше? Какие мои перспективы и что мне необходимо сделать для этого?
Все эти детали как раз и обсуждаются на review.
Еще раз повторяю — с вашим голосом должны считаться. Вы же не просто марионетка. Тимлид сказал, что все плохо, значит плохо? Так, посто смириться и жить дальше или как?
Есть многие вещи, которые могут и не знать люди, которые пишут о вас отчет, или же попросту упустить. Будь то сертификация, программа менторинга за джунами, помощь в каких-то внутрених проектах компании и куча всего прочего…
Само собой, что все зависит не только от того, как красиво вы себе представите. Как мне казалось, это очевидно. Если нет, простите, в следующий раз буду детальнее выражаться. Менеджер как минимум сам имеет слабое представление о вашей работе от заказчиков, вашего тимлида и других вовлеченных лиц. НО самое главное, что я хотел донести — это то, что во всей это солянке отзывов о вашей работе, ВАШ ОТЗЫВ — НЕМАЛОВАЖЕН!
Даже, если начальство и знает о всех твоих «свершениях» (что зачастую не так), то все равно это своего рода диалог, необходимый вам обоим.
Вы доказываете, что заслужили большего и обсуждаете свои амбиции и возможности. А начальник дает свой фидбек о вашей работе и показывает возможные пути по достижению ваших амбиций.
Как по мне, довольно здравая культура диалога. Без обид, ИМХО.