Должен ли (младший) разработчик попытаться добиться лучших процессов и практик в своей команде разработчиков / ИТ?

108

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

Моя команда довольно маленькая и несколько новая (<3 лет). Им не хватает:

  • четко определенная структура разработки программного обеспечения / управления работой (например, scrum)
  • сильная собственность на продукт
  • четко определенные роли (например, бизнес-персонал будет выполнять ручное тестирование)
  • регулярные встречи
  • консолидированный процесс отслеживания проблем (у нас есть инструмент, процесс все еще разрабатывается)
  • блок, система, регрессия или набор ручного тестирования или список
  • документация по бизнес-логике и процессам
  • база знаний для документирования внутренних и клиентских советов

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

Стоит ли (младшему) разработчику попытаться продвинуться выше с течением времени? Или лучше «оставаться в полосе» и сосредоточиться на разработке, а управление процессом и оптимизацией оставить основную часть?

overflow831
источник
10
Я заметил, что один из ваших тегов - Scrum. Является ли ваша команда командой Scrum? И если так, они держат ретроспективы?
Даниил
10
Есть ли причина, по которой вы используете «они» вместо «мы»? Например, "Моя команда довольно маленькая и несколько новая (<3 лет). Им не хватает"?
Томас Коэль
40
Просто к вашему сведению, если вы работали в нескольких компаниях, вы, вероятно, уже не младший.
Кевин
11
Что заставляет вас думать, что вещи, которые вы перечисляете, «лучше», а не просто последнее потраченное время? Можете ли вы сделать разумное обоснование для каждого?
jamesqf
11
«Управление открыто для реализации улучшений [..]» , что в значительной степени не имеет значения, более важно то, открыта ли для него остальная часть вашей команды. В противном случае, вступительный взнос руководства, а не командный взнос - это путь к состязательным отношениям с остальной частью вашей команды.
Марк Роттвил

Ответы:

179

Хорошие ответы пока что, но они не охватывают все основы.

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

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

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

Это был фантастический кусок дизайна программного обеспечения.

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

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

Этот архитектор был профессором университета с несколькими книгами на эту тему. Он никогда не работал программистом в коммерческом проекте.

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

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

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

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

jwenting
источник
19
Я не мог согласиться с вашим наблюдением. Практика, безусловно, лучший способ узнать, что работает, и даже тогда всегда есть и другие.
Kain0_0
226
Если проект безумно сложен, ужасен для изменения, то это не «фантастическая часть разработки программного обеспечения».
Стив Chamaillard
85
Этот ответ звучит так, будто ООП - это совокупность знаний, которыми увлечены ученые, в то время как отрасль "знает лучше". По моему опыту, все наоборот: ученые очень мало заботятся об ООП, в то время как многие компании все еще одержимы этим. Академики склонны заниматься более вневременными, но неясными концепциями (ценность которых часто оценивается отраслью в течение десятилетий).
Теодорос Чатзигианнакис
13
Кроме того, ожидайте, что старшие инженеры будут осторожны с причудами .
Джон Ву
67
«Это была фантастическая часть разработки программного обеспечения. К сожалению, в производстве и обслуживании это было просто кошмаром». Вторая часть означает, что первая не соответствует действительности. Хороший дизайн по определению делает программное обеспечение лучше. Если теория на самом деле не работает, теория просто ошибочна, и следовать ей - ужасная идея.
jpmc26
43

Да, но с большой осторожностью!

Позвольте мне уточнить это.

Вы должны стремиться улучшить удобство программного обеспечения. Если вы посмотрите на код / ​​команду / бизнес / проект / руководство, и ваш первый ответ - принять душ, то он не пригоден для жилья. Если ваш первый ответ - кричать «ага!», А затем жаловаться, когда вы выйдете из офиса, тогда вам нужно сделать свой дом более пригодным для жилья. Это чувство, и вы это узнаете.

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

Проблема

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

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

Путь вперед

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

Другой выбор - работать с системой, чтобы у каждого была система взглядов, но чтобы изменить небольшие части системы, чтобы все в команде знали, или, если они не знают об изменении, оба легко заметить и легко учиться. Это основа практики, называемой кайдзен . Формула, более ориентированная на разработчиков, представлена ​​в презентации «Бритье золотого яка», я настоятельно рекомендую посмотреть и продумать.

Так что найдите небольшую вещь, которая может быть изменена, которая улучшит вашу жизнь, и, надеюсь, те из нескольких других. Исправьте или улучшите ситуацию. Это даст вам практику и опыт применения изменений на практике. Убедитесь, что вы получили обратную связь: могли бы вы обсудить это лучше, было ли это на самом деле полезно, расстроило ли это другую часть системы. Развивайте чувство того, что можно сделать и как это сделать.

Теперь произошло три вещи:

  • вы улучшили систему,
  • вы получили опыт как поменять систему
  • команда видела, как вы успешно изменили систему.

Теперь выберите другую вещь, которую нужно улучшить, так как ваш опыт растет и по мере того, как вы устраняете проблемы с низким зависанием, вы начнете сталкиваться с более сложными проблемами в системе, но по крайней мере сейчас, когда вы скажете, что нам нужно изменить X:

  • Вы знаете, как изменение повлияет на систему
  • Вы знаете, какие проблемы это вызовет (какие правила нужно переучивать)
  • Вы знаете некоторые непосредственные способы исправить или улучшить проблемы, которые внесет изменение
  • окружающие вас люди знают, что вы осведомлены о системе и способны ее успешно изменить
Kain0_0
источник
Много с этим согласен. Стоит подчеркнуть, что ни одна кодовая база или процедура не является идеальной; все всегда компромисс. И как бы вам ни хотелось разбросать все вокруг и начать все заново, как вы говорите, IME, как правило, гораздо лучше развиваться медленно, небольшими шагами. Таким образом, вы можете взять с собой всех и избежать потери существующих знаний. Важно знать, куда вы хотите попасть; Таким образом, вы можете определить и использовать возможности по мере их возникновения.
gidds
@gidds Я думаю, что это была моя точка зрения, лучше всего вносить небольшие изменения, о которых все знают, или, по крайней мере, очевидно, что они изменились и легко читаются. Хотя я считаю, что важно иметь в виду долгосрочную цель, чтобы помочь вам выбирать между всеми способами, которыми вы могли бы улучшить вещи, я не думаю, что всегда можно сформулировать ее, особенно для начинающих разработчиков с ограниченным опытом в работая в масштабе с людьми. Формулировать улучшения в статус-кво гораздо проще. это тебя раздражает? Да Что вы можете сделать, чтобы улучшить ситуацию?
Kain0_0
@gidds, читая ваш комментарий еще раз, я согласен, что ни одна процедура или процесс не является идеальным или даже применимым к конкретной ситуации, и, если его обработать, можно даже привести команду в худшее место, чем никогда не пытаться. При этом даже в случае успеха конечный результат обычно представляет собой компромисс между всеми конкурирующими требованиями, которым программное обеспечение и его команда должны каким-то образом удовлетворять. Это намного сложнее, если бизнес находится в регулируемой отрасли. Правительства не любят нарушителей правил.
Kain0_0
20

Да, ты можешь. НО...

Ты должен быть осторожен.

В начале моей карьеры (давным-давно) мне посчастливилось / не повезло попасть в несколько месяцев назад в качестве "Джуниора".

Как первое, что я заметил, (OMG) не было хранилища кода! Все слияния кода были сделаны вручную путем отправки почтовых файлов друг другу по почте.

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

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

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

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


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

Может быть, у них также есть список, как ваш. Может быть, они прошли через все, и они хотели сделать эту «вещь» в списке. Может быть, они .... (что угодно) ....

Вся команда должна быть выровнена.

Но если их нет, то Вы все равно можете работать профессионально. И найти единомышленников и работать вместе, как вы думаете, это должно быть сделано. Если это принесет хорошие результаты, с Вами будет работать больше людей, в конечном итоге это станет «процессом».

Так же, как и с кодом, то же самое для процессов разработки: необходимо постоянное улучшение.

Так что да, вы всегда должны стараться улучшить то, что возможно улучшить.

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

Роберт Анджейюк
источник
1
Для меня это звучит так, будто вы пошли за спиной людей, ничего не объясняя своим коллегам-разработчикам, а просто заставили менеджера сделать это. Никто не любит "этот парень". Так что, да, если у вас есть предложения по улучшению, представьте их своим коллегам, но самое главное: сможете обосновать свои предложения им. Почему это сделает вещи лучше? Как это сэкономит людям время и усилия? Есть ли недостатки у нового пути? И т.д. Если вы сможете предсказать и подготовить ответы на проблемы людей, они с большей вероятностью примут ваши предложения охотно, чем добровольно.
Алекс
2
Я не чувствовал, как будто он "пошел за спиной людей". Я сообщил о проблеме своему менеджеру, он сказал мне, чтобы позаботиться об этом, и я сделал.
Роберт Анджеюк
17
«к сожалению, получить псевдоним, полученный из системы контроля версий». LOL Я надеюсь, что вы не приняли мерзавец.
BЈовић
Git еще не было рядом.
Роберт Анджеюк
10
@ BЈовић Может быть, его называли "подрывным" ... :-)
Александр
14

Стоит ли (младшему) разработчику попытаться продвинуться выше с течением времени?

Да, это всегда стоит ваших усилий, чтобы попытаться сделать вещи лучше. Ты лучше знаешь, с какими проблемами ты сталкиваешься в конце концов.

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

Потому что, в конце концов, если вы не участвуете в решении, вы являетесь частью проблемы.

Telastyn
источник
13

Да. Но организационные изменения трудны даже для старшего, поэтому, если вы действительно хотите что-то изменить, сделайте это правильно:

  • Не в течение первых недель: используйте это время, чтобы:

    • Создайте хорошее первое впечатление. Покажите, что вы вписываетесь в команду.
    • Понять культуру и политику или вашу компанию. Безопасно ли добиваться изменений?
    • Построить хорошие отношения с коллегами
    • Узнайте о процессе, правилах и потребностях вашей команды
    • Изучите свою работу и сделайте ее как можно лучше. Вы наверняка будете достаточно заняты.
  • Выбери свои сражения. Добейтесь ранних побед : вы можете прийти с энергией, чтобы изменить все, но это нереально. Сосредоточьтесь на некоторых низко висящих фруктах и ​​покажите, что ваши идеи работают. Вы хотите, чтобы они были восприимчивы к более сложным улучшениям. И помните, что в книгах все проще.

  • Подумайте о последствиях для других : я занимаюсь рефакторингом, затрагивающим множество файлов. Даже если они улучшат код, я должен быть очень осторожен, чтобы не превратить слияния в боль в заднице. Попробуйте также выяснить причины, по которым они продолжают работать таким образом. Может быть, они не могут использовать Scrum, так как им не хватает тестов, и, понятно, они боятся часто отправлять непроверенный код в производство. Написание надежного теста - нелегкая задача. Текущий код может быть очень сложно протестировать. Кроме того, команда не может использовать ни для написания тестов, ни тестируемого кода. Текущая кодовая база может быть особенно трудна для тестирования и нуждается в рефакторинге. Может потребоваться годы, чтобы изменить эту проблему, но, по крайней мере, вы можете сосредоточиться на основной причине.

  • Не суди. Не требуй. Спросите об этом и внимательно выслушайте: это момент, когда общение имеет решающее значение, и мы, программисты, обычно не очень хорошо умеем тонкие нюансы. Есть методы, чтобы помочь . Легко продолжать настаивать на нашей идее, а не фокусироваться на ответе. Сначала убедитесь, что они чувствуют, что вы получили их очки. Поймите, что чувства важны. Что это изменение заставляет их чувствовать? страх? insuficiency? гнев? разочарование? надеюсь? Ленивый? Глупый? (Никогда не заставляйте людей чувствовать себя глупо). Конечно, вы бы задавали много вопросов раньше, и это предотвратит множество ложных шагов.

  • Подайте пример : жаловаться легко, создать изменение сложно. Результаты выставок и люди поверят вам. Если они не используют тесты, вы можете написать свои модульные тесты. Если люди не документируют, вы можете поделиться некоторыми документами Google с командой. Поймите, что «Хорошо, сделайте это» - это один из лучших сценариев, и вам нужно выполнить его. В этом случае вам нужно подумать, какие ресурсы вам понадобятся . Пример: дайте мне небольшой экземпляр Amazon и два часа от администраторов для сервера Jenkins

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

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

  • Дайте ему немного времени. После этого проголосуйте своими ногами: вы можете попробовать его в течение периода от нескольких месяцев до двух лет. Но у некоторых компаний нет простых решений. Некоторые команды не хотят меняться и не имеют стимулов. И некоторые кодовые базы - чистый ужас. Если вы чувствуете, что это вы против всего мира, помните, что в пуле вакансий много предложений. Вы хотите изучать хорошие практики, и в конечном итоге вы будете чувствовать себя лучше, имея чуть-чуть меньше заработной платы, но приобретая опыт, который сделает вас более ценными.

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

  • Расскажите мне о времени, когда вы изменили ситуацию в команде.
  • Ну, я был в месте, где у них были очень старомодные практики. Многие люди были недовольны этим, и у производительности была большая возможность для улучшения. Поэтому я предложил провести быстрый эксперимент с ретроспективами, мы сделали X и Y, и в результате мы получили этот удивительный измеримый результат ».
Borjab
источник
«Не в первые недели», я думаю, особенно в первые несколько недель, просто задавая вопросы, можно многого добиться. Вы не только узнаете о проекте и рабочем процессе, но и заставите своих коллег задуматься о том, почему X находится в Y, а не в Z, отсутствует документация, обременительные инструменты (зачем мне нужно 20 команд для интеграции моих изменений?) И т. Д.
Майкл
1
Возможно, я сказал это плохо: конечно, вы должны задавать вопросы в другие моменты, особенно в первые дни. Мое намерение, но, возможно, по общему мнению, заключается в том, что, будучи юниором, вы не «НАЖИМАЕТЕ НА ИЗМЕНЕНИЯ» в первые дни, поскольку вы можете казаться всезнайкой, и вам не хватает инструментов для чего-то столь сложного, как изменение организации
Боржаб
9

Да. Но не то, что вы предлагаете.

Из вашего списка единичные / интеграционные тесты - единственное, на чем вы можете продвигаться.

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

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

Я бы также предложил такие вещи, как настройка конвейеров CI, автоматическое развертывание, управление версиями, пакетирование библиотек в качестве хорошей вещи для атаки

Ewan
источник
6
Как младший сотрудник я предложил все это. В течение ряда лет, с некоторой помощью (и большим бай-ином), я затем успешно реализовал их. К концу я был старшим архитектором. Это может работать, и это часто стоит попробовать. ;) Однако вы должны выбрать свои сражения и знать, когда вы сталкиваетесь с тяжелой борьбой за то, что может даже не вписаться в профиль / динамику организации. В другой роли я испытал искушение пойти по тому же маршруту и ​​решил даже не затрагивать тему, потому что там это никогда бы не сработало и также не было особенно важным.
Гонки легкости на орбите
4
Модульное тестирование и непрерывная интеграция - хороший выбор для начала. Они дадут вам лучший возврат инвестиций. Не пытайтесь использовать Scrum без технических приемов, которые позволяют ему работать. Как вы можете выполнять частые развертывания, если каждый из них опасен и требует много работы от тестировщиков и системных администраторов?
Борхаб
Модульные тесты / интеграционные тесты не обязательно являются чем-то, что можно сразу начать реализовывать из-за архитектуры. Кроме того, они имеют тенденцию навязывать определенные шаблоны, которые могут идти вразрез с существующим порядком вещей. Хотя они действительно имеют значение, это не всегда легко запустить домой, как это предлагается.
NPSF3000
2

Это зависит от:

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

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

ptyx
источник
1

Не начинайте с самых сложных вещей, таких как Scrum. Начните с самых простых возможных шагов.

Вы не упомянули об управлении исходным кодом. У вас есть репозиторий исходного кода (git, svn, cvs, ...)? Стратегия тегирования и ветвления? Это простые шаги, которые может сделать новичок. Узнайте, какие проблемы решают эти шаги (и как они пытаются), и как это помогает вашей компании сократить расходы (именно это и интересует руководство).

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

Что касается scrum, лучше почитайте про «Экстремальное программирование» (XP). Scrum основан на многих идеях XP и добавляет вокруг них формализованный процесс - концепции XP все еще можно использовать без этого процесса.

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

Бернхард Хиллер
источник
0

Вы сказали, что команда довольно новая (3 года), поэтому, если вы не можете представить некоторые хорошие принципы сейчас, это будет сложнее сделать это через 10 лет. Некоторые из вещей, которые вы упомянули, такие как система тестирования и управления версиями, относятся к числу тех, которые вы уже могли предложить, но не бросайте это предложение просто так, не подчеркивая их очевидные преимущества и выбирая инструменты, необходимые для вашего стека разработки.

Биллаль Бегерадж
источник
0

В начале задавайте вопросы

Читая ваш список, я бы предложил следующие вопросы (обратитесь к вашему списку, чтобы увидеть, как они подходят):

  • Как узнать, какую работу запрашивают владельцы бизнеса?
  • Вы пробовали [Scrum]?
  • Кто является владельцем продукта для этого?
  • Какие роли там?
  • Что делает [эта роль]?
  • Какая роль отвечает за [эту деятельность]?
  • Вы пробовали ежедневный прием?
  • Как мне сообщить мои препятствия остальной части команды?
  • Как узнать, над чем работают другие члены команды?
  • Должны ли мы поместить [это] в инструмент отслеживания проблем?
  • Как мы должны написать [это] в инструменте отслеживания проблем?
  • Когда [это] происходит, мы должны поместить это в инструмент отслеживания проблем как [это]?
  • Как мы тестируем?
  • Как мы записываем наши тесты для повторного использования другими?
  • Вы пробовали [JUnit]?
  • Где [это] задокументировано?
  • Вы пробовали [MediaWiki]?

Замените слова в [скобках] соответствующим образом, чтобы вопросы имели смысл или соответствовали вашим приоритетам. Подумайте над формулировкой, если моя формулировка не соответствует вашему стилю.

Возможно, вы уже начали это делать. Любите разговоры один на один по групповым беседам. Потому что один на один, вы можете лучше понять, что думает другой человек. Этот человек для этого изменения? Против этого? Слабо? Яростно?

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

Позже предпримите шаги

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

Если у вас есть препятствия (и если вы не можете участвовать в состязании), напишите команде о помощи.

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

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

Установите тестовый фреймворк (если это одобряют другие, примите совместное решение о том, какой фреймворк) и используйте его для своих проектов. Когда вы исправляете ошибки, пишите тесты. Документируйте это в отчете об ошибке на трекере проблем (написал тест, демонстрирующий ошибку, хранится в [location]). Поощряйте других запускать тесты, когда они вносят изменения. Если это не так, запустите тесты самостоятельно и при необходимости отправьте сообщения на трекер.

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

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

В конце концов, вы будете старшим

Со временем ваша команда наймет новых людей. Вы перестанете быть новым наемником и сможете отстаивать свои позиции с новыми людьми. Работайте с ними, чтобы внести изменения. И вы можете обнаружить, что вы делаете успехи с вашими существующими товарищами по команде. Или, если это не работает, ищите новую работу, где у них есть лучшие практики. Там нет никакой спешки. У тебя есть работа. Вы можете немного подождать, чтобы получить лучшую работу, либо улучшив ее, либо найдя лучшую.

mdfst13
источник
+1; один из лучших ответов с множеством хороших идей.
Кит
0

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

Предлагаемое решение :

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

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

Offirmo
источник
0

Поздний ответ и согласие много хорошего содержания в других ответах.

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

  • Создавать культурные изменения сложно .
  • Тем более, если вы видели как "младший"

Все остальное может последовать, если есть средства для достижения постоянного улучшения .

Мой подход к достижению этого:

  • Документированные процессы и процедуры
  • Ретроспектива с командой, действия которой являются изменениями в документации процесса.

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

Вы можете легко начать документирование процессов. «Я новый парень, я правильно понял? Позвольте мне записать это». Затем важно самому следовать процессу или попытаться позвонить нам, где он нарушается.

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

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

Некоторые соображения:

  • У некоторых команд плохой процесс, но на самом деле это уже известно. Они хотят измениться, и им просто нужно что-то катализировать. Другие команды действительно застряли на своем пути и их намного сложнее изменить.
  • То же самое касается отдельных лиц.
  • Вы должны быть внимательны к этому и выяснить, кто в команде открыт для перемен, а кто нет. Понять почему.
  • Найдите легкие победы.
  • Приветствуйте изменения в команде: найдите их индивидуальные болевые точки и постарайтесь помочь их исправить.
Кит
источник