Я - младший разработчик, которому дана возможность помогать формировать процессы моей команды, если я смогу оправдать изменения, и если это поможет команде выполнить работу. Для меня это ново, так как мои прошлые компании более или менее имели жестко определенные процессы, которые исходили от менеджмента.
Моя команда довольно маленькая и несколько новая (<3 лет). Им не хватает:
- четко определенная структура разработки программного обеспечения / управления работой (например, scrum)
- сильная собственность на продукт
- четко определенные роли (например, бизнес-персонал будет выполнять ручное тестирование)
- регулярные встречи
- консолидированный процесс отслеживания проблем (у нас есть инструмент, процесс все еще разрабатывается)
- блок, система, регрессия или набор ручного тестирования или список
- документация по бизнес-логике и процессам
- база знаний для документирования внутренних и клиентских советов
И список продолжается. Управление открыто для внедрения улучшений, если ценность оправдана и помогает выполнить самую важную работу (а именно разработку). Основное предположение, однако, заключается в том, что вы должны стать владельцем реализации, поскольку никто не собирается делать это за вас. И само собой разумеется, что некоторые из вышеперечисленных проектов нетривиальны, без сомнения занимают много времени и явно не являются разработкой.
Стоит ли (младшему) разработчику попытаться продвинуться выше с течением времени? Или лучше «оставаться в полосе» и сосредоточиться на разработке, а управление процессом и оптимизацией оставить основную часть?
Ответы:
Хорошие ответы пока что, но они не охватывают все основы.
По моему опыту, многие люди, недавно окончившие колледж, обладают фантастическими теоретическими знаниями - гораздо лучше, чем я или многие другие пожилые люди, десятилетиями создававшие программное обеспечение для жизни.
НО, и это большое НО, это знание не основано ни на каком практическом сценарии. В реальном мире многие из этих теорий терпят неудачу, или, по крайней мере, их нужно принимать с помощью огромного количества соли, поскольку на практике оказалось, что это не очень хорошо работает в сценарии реального мира.
Пример: приложение, над которым я работал давным-давно, было разработано блестящим теоретиком ОО, спроектированным так, чтобы следовать принципам и теории ОО Т, с множеством шаблонов, применяемых повсюду.
Это был фантастический кусок дизайна программного обеспечения.
К сожалению, это привело к кошмару производства и обслуживания. Кодовая база была настолько большой и сложной, что места было невозможно изменить; Не потому, что он был особенно хрупким, а потому, что он был настолько сложным, что никто не осмелился дотронуться до него, боясь того, что произойдет (первоначальный архитектор / дизайнер был подрядчиком, который давно ушел).
Он также работал очень плохо, именно из-за многослойной структуры шаблонов и библиотек классов, которые требуются для проектирования. Например, нажатие кнопки на экране для одного вызова базы данных приведет к нескольким сотням экземпляров объектов и вызовов методов - и все это во имя обеспечения слабой связи и тому подобных вещей.
Этот архитектор был профессором университета с несколькими книгами на эту тему. Он никогда не работал программистом в коммерческом проекте.
Люди с практическим опытом создания программного обеспечения поняли бы, к чему чудовищность такого дизайна неизбежно приведет, и приняли бы более прагматичный подход, ведущий к созданию системы, которую проще поддерживать и которая также работает лучше.
То же самое может относиться ко многим другим вещам, с которыми вы сталкиваетесь как молодой выпускник или действительно новый сотрудник в любой компании. Не думайте, что из-за того, что ваша теоретическая база говорит вам, что что-то не так или неоптимально, нет такой веской причины для этого.
Даже сейчас, имея более чем 20-летний опыт работы в этой области, я с осторожностью критикую то, как все происходит в компаниях, с которыми я работаю. Попутно упомяну, что я заметил, что все отличается от того, что в моем опыте было наиболее оптимальным, но не воинственным образом. Это часто приводит к интересным разговорам о том, почему эти вещи такие, какие они есть. Может быть, изменения произойдут, а может и нет, в зависимости от того, меньше ли стоимость меняющихся вещей, чем стоимость.
Не бойтесь предположить, что дела могут быть лучше, но всегда следите за тем, чтобы вас не называли всезнающим сопливым ребенком, а скорее коллегой, который пытается и хочет не только учиться, но и помочь улучшить процессы для улучшения компании, а не только теоретическую корректность.
источник
Да, но с большой осторожностью!
Позвольте мне уточнить это.
Вы должны стремиться улучшить удобство программного обеспечения. Если вы посмотрите на код / команду / бизнес / проект / руководство, и ваш первый ответ - принять душ, то он не пригоден для жилья. Если ваш первый ответ - кричать «ага!», А затем жаловаться, когда вы выйдете из офиса, тогда вам нужно сделать свой дом более пригодным для жилья. Это чувство, и вы это узнаете.
При этом, вы работаете в сложном синтезе . Все, что вы делаете, скорее всего, пойдет не так, и, вероятно, ухудшит ситуацию, по крайней мере, в краткосрочной перспективе, потому что простое изменение имеет рябь. Итак, прежде всего, станьте смиренным, я не имею в виду стать толчком или смириться с тем, что все должно быть плохо, я имею в виду, что нужно смириться с тем фактом, что ваши благие намерения повергнут вас злобно.
Проблема
С благими намерениями вы можете почувствовать, что должны произойти широкие радикальные изменения, и я не согласен с тем, что такие ситуации существуют, но подумайте об этом. Текущая система работает, вы и ваша команда производите код, возможно, он медленный, возможно, болезненный, но он работает, и у всех вас есть опыт, как это сделать. Вы примерно знаете, чего ожидать, короче говоря, вы профессионалы в этой системе.
Хотя после радикальных изменений никто, кроме, возможно, исполнителя не знает, чего ожидать. Короче говоря, все были сброшены до уровня неофита в этой части системы. Это не хорошо. Неофиты должны выучить новые правила, что требует времени. В то время неофиты делают ошибки, потому что они не практикуются. Эти ошибки становятся частью системы, с которой вам теперь приходится жить, и ее сейчас нет, как блестяще.
Путь вперед
Временами слэш, прожиг и восстановление - это лучшее, что вы можете сделать. Это особенно привлекательно, если никто не практикуется в старой системе, потому что единственное, что теряется, это кодифицированное знание. Если это знание совершенно непостижимо, то оно уже потеряно, и начинать сначала - единственный выбор. И наоборот, если метод кодификации или то, как он использовался, проблематичен, но функционирует, то эти знания все еще доступны, и, возможно, их стоит сохранить, а возможно, нет. Просто не принимайте решение легко.
Другой выбор - работать с системой, чтобы у каждого была система взглядов, но чтобы изменить небольшие части системы, чтобы все в команде знали, или, если они не знают об изменении, оба легко заметить и легко учиться. Это основа практики, называемой кайдзен . Формула, более ориентированная на разработчиков, представлена в презентации «Бритье золотого яка», я настоятельно рекомендую посмотреть и продумать.
Так что найдите небольшую вещь, которая может быть изменена, которая улучшит вашу жизнь, и, надеюсь, те из нескольких других. Исправьте или улучшите ситуацию. Это даст вам практику и опыт применения изменений на практике. Убедитесь, что вы получили обратную связь: могли бы вы обсудить это лучше, было ли это на самом деле полезно, расстроило ли это другую часть системы. Развивайте чувство того, что можно сделать и как это сделать.
Теперь произошло три вещи:
Теперь выберите другую вещь, которую нужно улучшить, так как ваш опыт растет и по мере того, как вы устраняете проблемы с низким зависанием, вы начнете сталкиваться с более сложными проблемами в системе, но по крайней мере сейчас, когда вы скажете, что нам нужно изменить X:
источник
Да, ты можешь. НО...
Ты должен быть осторожен.
В начале моей карьеры (давным-давно) мне посчастливилось / не повезло попасть в несколько месяцев назад в качестве "Джуниора".
Как первое, что я заметил, (OMG) не было хранилища кода! Все слияния кода были сделаны вручную путем отправки почтовых файлов друг другу по почте.
Поэтому я пошел к своему (также новому) менеджеру и предложил, чтобы у нас был репозиторий. Ответ был: хорошо, организуйте это ....
Поэтому организация хранилища кода без посторонней помощи была новой для компании, и теперь это было унизительным опытом.
Когда я все это настроил, (шокирует) никто не хотел этим пользоваться. Поэтому я попытался продвинуться вперед, и, к счастью, мой менеджер понял, что это важно, поэтому у меня была поддержка.
Но это привело к тому, что мне не очень понравилось, и, к сожалению, я получил псевдоним, полученный из системы контроля версий.
Итак, мое мнение заключается в том, чтобы сначала почувствовать членов вашей команды, что, по их мнению, важно настроить в следующий раз.
Может быть, у них также есть список, как ваш. Может быть, они прошли через все, и они хотели сделать эту «вещь» в списке. Может быть, они .... (что угодно) ....
Вся команда должна быть выровнена.
Но если их нет, то Вы все равно можете работать профессионально. И найти единомышленников и работать вместе, как вы думаете, это должно быть сделано. Если это принесет хорошие результаты, с Вами будет работать больше людей, в конечном итоге это станет «процессом».
Так же, как и с кодом, то же самое для процессов разработки: необходимо постоянное улучшение.
Так что да, вы всегда должны стараться улучшить то, что возможно улучшить.
Но также помните, что многие люди, с которыми вы работаете, уже могли быть профессионалами, и они знают, что не так и что нужно.
источник
Да, это всегда стоит ваших усилий, чтобы попытаться сделать вещи лучше. Ты лучше знаешь, с какими проблемами ты сталкиваешься в конце концов.
Но, как вы упоминаете, есть много проблем, которые нужно решить, и многие из них не очень ценны. И во многих местах будут непреодолимые барьеры для вашего успеха или других людей, которые гораздо лучше подготовлены к их защите. Поэтому вы всегда должны стараться сделать что-то лучше, даже если это означает, какие вещи вы тратите, пытаясь сделать лучше.
Потому что, в конце концов, если вы не участвуете в решении, вы являетесь частью проблемы.
источник
Да. Но организационные изменения трудны даже для старшего, поэтому, если вы действительно хотите что-то изменить, сделайте это правильно:
Не в течение первых недель: используйте это время, чтобы:
Выбери свои сражения. Добейтесь ранних побед : вы можете прийти с энергией, чтобы изменить все, но это нереально. Сосредоточьтесь на некоторых низко висящих фруктах и покажите, что ваши идеи работают. Вы хотите, чтобы они были восприимчивы к более сложным улучшениям. И помните, что в книгах все проще.
Подумайте о последствиях для других : я занимаюсь рефакторингом, затрагивающим множество файлов. Даже если они улучшат код, я должен быть очень осторожен, чтобы не превратить слияния в боль в заднице. Попробуйте также выяснить причины, по которым они продолжают работать таким образом. Может быть, они не могут использовать Scrum, так как им не хватает тестов, и, понятно, они боятся часто отправлять непроверенный код в производство. Написание надежного теста - нелегкая задача. Текущий код может быть очень сложно протестировать. Кроме того, команда не может использовать ни для написания тестов, ни тестируемого кода. Текущая кодовая база может быть особенно трудна для тестирования и нуждается в рефакторинге. Может потребоваться годы, чтобы изменить эту проблему, но, по крайней мере, вы можете сосредоточиться на основной причине.
Не суди. Не требуй. Спросите об этом и внимательно выслушайте: это момент, когда общение имеет решающее значение, и мы, программисты, обычно не очень хорошо умеем тонкие нюансы. Есть методы, чтобы помочь . Легко продолжать настаивать на нашей идее, а не фокусироваться на ответе. Сначала убедитесь, что они чувствуют, что вы получили их очки. Поймите, что чувства важны. Что это изменение заставляет их чувствовать? страх? insuficiency? гнев? разочарование? надеюсь? Ленивый? Глупый? (Никогда не заставляйте людей чувствовать себя глупо). Конечно, вы бы задавали много вопросов раньше, и это предотвратит множество ложных шагов.
Подайте пример : жаловаться легко, создать изменение сложно. Результаты выставок и люди поверят вам. Если они не используют тесты, вы можете написать свои модульные тесты. Если люди не документируют, вы можете поделиться некоторыми документами Google с командой. Поймите, что «Хорошо, сделайте это» - это один из лучших сценариев, и вам нужно выполнить его. В этом случае вам нужно подумать, какие ресурсы вам понадобятся . Пример: дайте мне небольшой экземпляр Amazon и два часа от администраторов для сервера Jenkins
Сохраняйте это маленьким и простым (и дешевым): вы не хотите ждать официального одобрения бюджета, или ваши начальники считают, что вы теряете драгоценное время из-за дорогих программистов. Было бы замечательно иметь это программное обеспечение для обзора кода или оценить несколько инструментов с открытым исходным кодом, но мы пока воспользуемся репо.
Получить критическую массу: собрать группу людей, ориентированных на улучшение качества. Вы даже можете пойти с ними на конференции и попросить помощи или наставничества. Люди описывают «пробуждение гигантского феномена», когда основа команды буквально восстает против некоторых глупых практик, которые замедляют производительность. Это было бы по-настоящему опасно, и я бы не рекомендовал. Но если все группы согласны, измениться легче.
Дайте ему немного времени. После этого проголосуйте своими ногами: вы можете попробовать его в течение периода от нескольких месяцев до двух лет. Но у некоторых компаний нет простых решений. Некоторые команды не хотят меняться и не имеют стимулов. И некоторые кодовые базы - чистый ужас. Если вы чувствуете, что это вы против всего мира, помните, что в пуле вакансий много предложений. Вы хотите изучать хорошие практики, и в конечном итоге вы будете чувствовать себя лучше, имея чуть-чуть меньше заработной платы, но приобретая опыт, который сделает вас более ценными.
Бонус: если вам это удастся, запишите это для своего резюме / интервью. Будучи юниором, вы обычно мало что можете сказать, и создание перемен к лучшему - это всегда хороший знак. Вы хотите иметь очень четкое и реалистичное представление о том, что вы лично делали и чем занимались другие. Представьте себе следующий вопрос интервью.
источник
Да. Но не то, что вы предлагаете.
Из вашего списка единичные / интеграционные тесты - единственное, на чем вы можете продвигаться.
Вы можете начать добавлять их самостоятельно с минимальными затратами времени и показывать мгновенную ценность. Это техническая проблема с общепринятыми преимуществами и не влияет на другие методы работы. Кроме того, вы получаете больше знаний о кодовой базе, даже если результаты не принимаются. Легко продать.
Другие - это, как правило, бизнес-процессы, в которых участвует вся команда или даже другие команды. Вы могли бы предложить улучшения, но младшему сотруднику будет сложно изменить их, и процесс их изменения, как правило, не является техническим и, вероятно, не связан с вашей обычной работой.
Я бы также предложил такие вещи, как настройка конвейеров CI, автоматическое развертывание, управление версиями, пакетирование библиотек в качестве хорошей вещи для атаки
источник
Это зависит от:
По сути: в ваши обязанности входит потратить некоторое разумное время, отстаивая то, что вы считаете лучшим, но решение должно быть за командой или руководством. Имейте в виду, что отчуждать людей редко стоит, даже если вы в конечном итоге получите лучшие практики.
источник
Не начинайте с самых сложных вещей, таких как Scrum. Начните с самых простых возможных шагов.
Вы не упомянули об управлении исходным кодом. У вас есть репозиторий исходного кода (git, svn, cvs, ...)? Стратегия тегирования и ветвления? Это простые шаги, которые может сделать новичок. Узнайте, какие проблемы решают эти шаги (и как они пытаются), и как это помогает вашей компании сократить расходы (именно это и интересует руководство).
Следующим шагом могут быть автоматические сборки, ночью или сразу после каждой регистрации, например, с Дженкинсом. Вы также можете запускать тесты автоматически. И добавьте некоторые инструменты для измерения качества кода (о да: определение некоторых стандартов кодирования также является хорошим шагом).
Что касается scrum, лучше почитайте про «Экстремальное программирование» (XP). Scrum основан на многих идеях XP и добавляет вокруг них формализованный процесс - концепции XP все еще можно использовать без этого процесса.
Предлагайте что-то, предоставляйте основную информацию, пытайтесь убедить других попробовать, анализировать результаты, но не ожидайте большого сотрудничества с другими: большинство людей предпочитают придерживаться своих старых вредных привычек. Но если вы не попробуете это, ничего не улучшится.
источник
Вы сказали, что команда довольно новая (3 года), поэтому, если вы не можете представить некоторые хорошие принципы сейчас, это будет сложнее сделать это через 10 лет. Некоторые из вещей, которые вы упомянули, такие как система тестирования и управления версиями, относятся к числу тех, которые вы уже могли предложить, но не бросайте это предложение просто так, не подчеркивая их очевидные преимущества и выбирая инструменты, необходимые для вашего стека разработки.
источник
В начале задавайте вопросы
Читая ваш список, я бы предложил следующие вопросы (обратитесь к вашему списку, чтобы увидеть, как они подходят):
Замените слова в [скобках] соответствующим образом, чтобы вопросы имели смысл или соответствовали вашим приоритетам. Подумайте над формулировкой, если моя формулировка не соответствует вашему стилю.
Возможно, вы уже начали это делать. Любите разговоры один на один по групповым беседам. Потому что один на один, вы можете лучше понять, что думает другой человек. Этот человек для этого изменения? Против этого? Слабо? Яростно?
Когда вы новичок, задавать вопросы практически бесплатно. Люди должны ожидать, что вы зададите вопросы. Даже если ваши вопросы косвенно отстаивают позицию, против которой они выступают, они не должны сердиться. Они должны объяснить, почему они выступают против этой позиции. Я рекомендую не спорить с ними. Спор имеет тенденцию укреплять позиции больше, чем убеждает. Обратите внимание, у кого какая позиция и двигайтесь дальше.
Позже предпримите шаги
Ищите способы, с помощью которых вы и, возможно, другие (то есть те, с кем вы согласились ранее) могли начать изменения, которые вы хотите. Не каждый хочет встать? Почему нет? Возможно, те из вас, кто этого хочет, могут иметь свой собственный статус. Не так эффективно, как со всей командой, но больше, чем сейчас.
Если у вас есть препятствия (и если вы не можете участвовать в состязании), напишите команде о помощи.
Определите, какие роли должны быть, возможно, при поддержке других людей, которые согласны с вами. Начните последовательно ходить к людям, когда работа включает роль, которую вы (возможно, группа, которую вы) считаете нужной. Если они отступят, попросите их определить, кому должна принадлежать эта роль.
Попросите владельцев продуктов (которые вы определили) написать описания того, как, по их мнению, должен работать их продукт сейчас и в будущем.
Установите тестовый фреймворк (если это одобряют другие, примите совместное решение о том, какой фреймворк) и используйте его для своих проектов. Когда вы исправляете ошибки, пишите тесты. Документируйте это в отчете об ошибке на трекере проблем (написал тест, демонстрирующий ошибку, хранится в [location]). Поощряйте других запускать тесты, когда они вносят изменения. Если это не так, запустите тесты самостоятельно и при необходимости отправьте сообщения на трекер.
Если вы можете получить поддержку управления, установите программное обеспечение вики или подобное и начните документировать свои вещи. Если люди задают вам вопросы, которые показывают, что они не читали документацию, укажите их на соответствующих страницах. Поощряйте их задавать больше вопросов, если они не понимают документацию. Если они продолжают задавать вопросы, описанные в документации, приводите цитаты из документации при ответе. Подумайте о том, чтобы побудить их обновить вики, если вы считаете, что проблема была структурной, а не не читающей.
Я бы предложил сосредоточиться только на одной задаче за раз. И, конечно, только толкать по одному за раз. Не дави сильно. Посмотрите на этот пример толкания сильнее, чем хотелось группе. Сконцентрируйтесь больше на изменении своего поведения, чем на их. Если ваш путь правильный, это должно быть очевидно для людей, наблюдающих за вами. Дела говорят больше, чем слова. Старайтесь не повторять себя с тем же человеком, когда вы подталкиваете. Как только вы привели лошадь к воде, оставьте выбор, когда или нужно ли пить другому.
В конце концов, вы будете старшим
Со временем ваша команда наймет новых людей. Вы перестанете быть новым наемником и сможете отстаивать свои позиции с новыми людьми. Работайте с ними, чтобы внести изменения. И вы можете обнаружить, что вы делаете успехи с вашими существующими товарищами по команде. Или, если это не работает, ищите новую работу, где у них есть лучшие практики. Там нет никакой спешки. У тебя есть работа. Вы можете немного подождать, чтобы получить лучшую работу, либо улучшив ее, либо найдя лучшую.
источник
Краткий ответ : Нет, по всем причинам, изложенным в других ответах. Даже будучи средним или старшим разработчиком, лучше сначала попытаться понять, когда присоединяешься к новой команде.
Предлагаемое решение :
1) всякий раз, когда вы видите что-то, что, по вашему мнению, должно быть улучшено, примите это к сведению! (в записной книжке, в цифровой записке ...)
2) Через 6 месяцев вернитесь к своим заметкам и проверьте их. Сколько идей сейчас кажется бессмысленным и неадекватным? Скорее всего, много, вы спасли себя от смущения. Если некоторые идеи все еще сохраняются, сейчас самое время представить их, если это возможно, сначала проверив их самостоятельно.
источник
Поздний ответ и согласие много хорошего содержания в других ответах.
Я думаю, что необходимо подчеркнуть, что ключевой вопрос здесь - это не конкретные практики, а общая культура команды.
Все остальное может последовать, если есть средства для достижения постоянного улучшения .
Мой подход к достижению этого:
Я думаю, если у вас нет спринтов, у вас еще нет регулярных ретроспектив. Все, что вам нужно, это разговор с командой, а затем действовать.
Вы можете легко начать документирование процессов. «Я новый парень, я правильно понял? Позвольте мне записать это». Затем важно самому следовать процессу или попытаться позвонить нам, где он нарушается.
Может быть , вы начинаете с такими разговорами быть специальными , а затем предложить регулярные ритуалы.
Использование этого подхода позволяет постепенно, мягко, мягко. Вы можете не выглядеть юношей, который, как им известно, знает все это, и вместо этого попытаться стать посредником в команде, которая вносит изменения.
Некоторые соображения:
источник