Работает ли ваша команда хорошо, не следуя методологии работы (например, схватке)?

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

За эти 9 лет я никогда не слышал много о методологиях разработки; например, никогда не было «мы делаем разборки», или «давайте делать гибкие», или что-то большее, чем просто мимолетная ссылка. Казалось, что все команды функционировали нормально, без особого процесса, мы просто работали свободно и, естественно, работали хорошо.

Кто-нибудь еще прогрессировал в течение долгих периодов времени, не сталкиваясь с scrum / agile / etc?

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

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

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

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

Честно говоря, если ваша маленькая команда хорошо работала без серьезных инцидентов все эти годы, не задумываясь о процессе, вы, вероятно, выполняли какую-то гибкую форму. Все гибкие процессы означают, что они соответствуют «Agile Manifesto» http://agilemanifesto.org/, в котором мало что можно сказать об итеративных, раскадровках и т. Д. Самый первый принцип гибкого подхода заключается в том, что вы предпочитаете «отдельных лиц и взаимодействие над процессами и инструментами ". Любая команда, которая хорошо работает вместе, не должна серьезно задумываться о процессе.

Различные бренды Agile (например, Scrum и т. Д.) Очень полезны, если у вас есть совершенно новая команда, которая не привыкла работать друг с другом. Они как бы создают основу для того, как создать сплоченную команду, которая, в свою очередь, создаст сплоченный продукт.

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

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

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

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

Если у вас нет проблем, чтобы решить, удачи вам.

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

Внедрение методологии (или техники), потому что это весело или потому что вы читаете этот пост в Интернете, очень опасно.

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

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

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

Всеобъемлющее навязывание новейших <insert-buzzword-here>методов работы может привести к еще большей путанице, чем ее решение. Но, как правило, может предоставить множество меток флажков, которые менеджер линии без кодирования может отметить с энтузиазмом.

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

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