Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
.NET Software Engineer в GlobalLogic
  • Типові помилки в англійській у IT-спеціалістів і як їх виправляти: поради викладачів

    Если не знать этих тонкостей, есть большая вероятность того, что ваши слова будут звучать очень грубо или фамильярно для остальных собеседников. Иностранцы, которые достаточно долго работают с нашими к такому нередко уже привычные (тем более в случае общения с обычными инженерами), но почему бы не проявить вежливость вместо того чтобы звучать как пещерный человек?

  • Хватит гнать на Менеджеров и Скрам Мастеров!

    Называйте как хотите, но такой человек нужен практически на любом митинге.

  • Хватит гнать на Менеджеров и Скрам Мастеров!

    В идеальном мире — конечно, вот только в реальном мире присутствующие сами же и уводят разговор в сторону, а остальным или как-то побоку, или они боятся вмешаться в разговор (вдруг там важные дядьки-архитекторы решили пообсуждать технические детали какой-то фичи). Иммено поэтому у любого митинга должен быть лид (не обязательно тимлид/скрам-мастер/менеджер — просто один из участников который ведет митинг, обычно этот тот кто его организовал) чтобы убедиться что всем дали слово и что тема дискуссии соответствует заданной, при необходимости возвращая ее в нужное русло.

    Підтримав: anonymous
  • Хватит гнать на Менеджеров и Скрам Мастеров!

    Я к тому, что не будучи задействованным в повседневной работе команды, какие-то моменты скрам-мастер все же упустит или недооценит их влияние. Да и слушать в таком случае кого-то, кто придет и начнет сам ничего не делая учить других, как им работать, никто особо не станет...
    Совсем другое дело, когда скрам-мастер — это роль, которую выполняет кто-то в команде помимо своих основных обязанностей.

    Підтримав: anonymous
  • Хватит гнать на Менеджеров и Скрам Мастеров!

    Скрам мастеров (как отдельную должность) не люблю — мое ИМХО: если человек не работает над теми же тасками, что и команда, он никогда не будет до конца понимать с какими проблемами команда сталкивается в каждый момент времени и потому не должен указывать команде что делать.

    Скрам и другие гибкие методологии работают только когда их внедряют там, где они применимы, а не везде, просто потому что это модно, создавая при этом дичайшие гибриды которые заканчиваются головной болью для всех (но виноват почему-то оказывается Скрам, а не те, кто додумались его туда приткнуть...)

    А в остальном полностью согласна со статьей — команды часто вообще не понимают, что пишут не сферический софт в вакууме, а решают конкретную бизнес-проблему. Что есть временные и бюджетные рамки. И что кроме них над продуктом работает еще куча людей, с которыми нужно синхронизировать прогресс. У тестировщиков, кстати, с видением общей картины лучше, возможно потому что они обычно первыми страдают если с процессами что-то не так. А вот за разработчиками, к сожалению, обычно нужно присматривать, потому что имеют тенденцию увлекаться техническими аспектами работы и игнорить все остальное, при чем уровень синьорности не всегда кореллирует с пониманием [необходимости] отлаженных процессов.

  • 10 шишек на одном проекте. Опыт PM’а

    Очень интересная и полезная статья. Спасибо что поделились своим опытом — все мы набиваем шышки, но иногда они стоят дорого и возможность в чем-то их избежать учась на чужом опыте — это действительно очень ценно.

    Підтримав: Yuri Predborski
  • Програмування без негативу: як виконувати поточну роботу й зберігати спокій

    Отличная статья, и очень актуальная. Спасибо!

  • Шанувальникам Порошенко

    Хотя бы не голосовать за Порошенко

    Звучит в точности как лозунг набежавших перед нашими выборами кремлеботов: «кто угодно, только не Порошенко»...
    Предложите альтернативу, только пожалуйста аргументируйте, чем ваш кандидат лучше.

  • Токсичность IT-сообщества мешает его же развитию?

    Если интересно ИТ, то он начнёт сначала, если интересно только бабло в ИТ, то он задаст вопрос откуда начать, чтобы по-быстрее начать косить.

    И топики в духе второго в последнее время участились на ДОУ...

    Підтримали: Dmitry, anonymous
  • Чому майже нікому в Україні не потрібен agile і що з цим робити

    Уличенных в проповедывании Cкрама там где он не нужен. Но начала бы я с тех кто путает Agile и Scrum...

    Підтримав: Artem Bykovets
  • Чому майже нікому в Україні не потрібен agile і що з цим робити

    Agile как религию продают только сертифицированные скрам-мастера. Я лично обеими руками за сожжение их самих как еретиков раздувающих из адекватного подхода к разработке (которому множество людей, в том числе здешних хейтеров, следуют сами того не осознавая) целое таинство, что в свою очередь порождает множество недоразумений и мифов.

  • Чому майже нікому в Україні не потрібен agile і що з цим робити

    Что за компании/проекты, насколько хорошо они закрепились на рынке прежде чем начали экспериментировать с Agile? Какая вообще была ситуация на рынке для этих компаний/проектов? Как в них был изначально налажен процесс и какой фреймворк они пытались при этом внедрить? Что имено пошло не так — процесс не работал, или сотрудники даже не попытались ему следовать?
    Без контекста и подробностей с тем же успехом можно сказать что неудачи произошли, к примеру, из-за лично вас — так как вы и ваши друзья там работали. Но это же звучит как бред, не так ли?

    Вот основная часть Agile манифеста:

    Люди и взаимодействие важнее процессов и инструментов
    Работающий продукт важнее исчерпывающей документации
    Сотрудничество с заказчиком важнее согласования условий контракта
    Готовность к изменениям важнее следования первоначальному плану

    То есть, не отрицая важности того, что справа,
    мы всё-таки больше ценим то, что слева.

    Где здесь хоть что-то про необходимость ритуалов и множества митингов на которых присутствует и скучает вся команда?

    Есть случаи когда обвешанный ритуалами фреймворк Scrum пытаются внедрить там, где подробная документация и планирование наперед наоборот критически важны — и это действительно катастрофа. Но в большинстве случаев ситуация не такая суровая, и для меня Agile (не Scrum или Kanban!) это просто синоним здравого смысла.

    Я видела команды успешно применяющие Agile и работала в таких, причем на легаси проекте. Процессы были адаптированы под нас и так, как нам было комфортно работать и приносить стабильный результат, без скрам-мастера и с минимумом митингов.

  • Чому майже нікому в Україні не потрібен agile і що з цим робити

    «Заказчик хотел совсем не то..» — это когда нет чётких договорённостей о том, как будет выглядеть конечный результат.

    А вам часто попадались заказчики которые знают в подробностях, как конечный результат должен выглядеть?
    Многие решения приходится принимать в ходе разработки.

    Сама по себе парадигма/методология решит этот вопрос?

    А сам по себе кодинг?
    Agile разработка подразумевает коммуникацию.

  • Чому майже нікому в Україні не потрібен agile і що з цим робити

    Может стоит просто начать работать ?

    ... и пилить абстрактный софт в вакууме, решающий сокровенные мечты пишущих его кодеров, а не бизнес-задачу. Потому что в какой-то момент окажется, что коммуникации не налажены, заказчик хотел совсем не то, а релиз был нужен на вчера.

    Хватит путать понятия: Agile разработка — это следование методологии, которая ставит людей и результат выше процессов (как раз то, о чем вы говорите когда хотите просто работать, а не просиживать кучу времени на бесполезных митингах «потому что так надо»). Смысл такого подхода не в том, чтобы слепо следовать определенному процессу, а в том, чтобы учиться на своих ошибках и адаптировать процесс под проект и команду. Ничего особенного в этом нет — это просто здравый смысл.
    Scrum/Kanban — это фреймворки, и они очень нишевые. Есть случаи в которых они работают идеально, но часто на волне хайпа их пытаются применять тех условиях, для которых они не предназначены, и потому от них там будет только вред. Но они могут быть полезны поначалу как стартовая точка, с которой можно начать пересмотр процессов для каждого конкретного проекта и команды.

  • Как часто в компаниях есть тренажерный зал?

    Ну, я уж точно не эксперт по стероидам и не хочу иметь к ним никакого отношения :D

  • Как часто в компаниях есть тренажерный зал?

    Мне кажется такие монстры уже не особо парятся о том насколько здоровую еду они едят — главное побольше белка и калорий

  • Унылая слишком серьезная команда

    как показывает практика, без нас никак

    Но это не ваша заслуга. Так происходит только потому, что многие компании сначала пытаются экономить на постоянных сотрудниках, а потом, когда сроки начинают поджимать, срочно ищут новых людей, предлагая космические рейты...
    Особенно прикольно когда берут контрактора на полгода на большой легаси проект (где как минимум полгода обычно нужно чтобы только начать более-менее понимать как там все взаимосвязано) и поручают большую важную фичу. Через полгода контрактор уходит, а результат его «работы» достается основной каманде на поддержку.
    Спойлер: качество кода второстепенно — хорошо, если оказывается что фича вообще работает и проект сломан меньше чем в 3 разных местах.

    Підтримали: Oleksiy Antonov, anonymous
  • Унылая слишком серьезная команда

    Человеку если насрать на качество — это не зависит от формы трудоустройства и не кореллирует с «серьезностью»

    Речь не о стремлении к качеству — человек может на полном серьезе работать 8+ часов непрерывно и верить что пишет хороший код и что серьезность делает его офигенным профессионалом, но в реальности писать говнокод просто потому, что с такой работой мозг закипает.
    Если работать как вышеописанный контрактор и дико овертаймить, то тут еще добавляется стресс, падает способность адекватно соображать и гробится здоровье, потому что мы все люди, а не роботы. И толку работодателю от такого контрактора?

    отключается при проблемах или высоких нагрузках.

    В этом случае отключается оно у всех, даже тех кто шутить любит. Но высокие нагрузки не постоянно — если постоянно, то бежать надо с такой работы.

    Підтримали: Andriy Loboda, Bot Bot
  • Унылая слишком серьезная команда

    контракторы, пашущие по 200-250 часов/мес.

    Угу, видела я код таких контракторов. И участвовала в разгребании (длинной в полгода) последствий их найма для проекта ...
    И как тут уже писали ниже:

    У мене навпаки склалося враження, що чим серйозніша людина, то більший шанс на те, що вона насправді пише рідкісне лайно.

    Мой опыт указывает на то же самое.

    Підтримали: anonymous, Oleksiy Antonov
  • Унылая слишком серьезная команда

    Это вопрос рабочей морали, в оплачиваемое работодателем время заниматься работой — а не шуточками в чатиках и гонянием кофеёв с сошиалайзингами по столовкам.

    Не проблема по трем причинам:
    1) Человек не может продуктивно заниматься умственной деятельностью 8 часов подряд, в лучшем случае часов 5, и то с перерывами.
    2) Общение на нерабочие темы это часть процесса тимбилдинга, который в свою очередь улучшает отношения в команде и делает ее более слаженной и продуктивной.
    3) Если совесть до сих пор неспокойна, то это фиксится нахождением в офисе дольше 8 часов, компенсируя время, проведенное за «нерабочими» занятиями. Я, к примеру, живу далеко от офиса так что по будням свободного времени остается 2-3 часа из-за работы, это все равно слишком мало и так что когда я прихожу позже то разницы особой не чувствую. Еще можно уйти домой раньше и поработать по удаленке... Короче, возможностей много, но смысла работать так долго обычно нет, почему — см. пункт 1.

    Підтримав: anonymous
← Сtrl 1... 34567...25 Ctrl →