Методология разработки для незрелых команд
При изучении программных методологий я часто вижу отказ от ответственности в духе "Эта методология требует зрелой команды разработчиков".
Какие методологии разработки специально предназначены для незрелых команд разработчиков? Я бы предположил, что именно здесь следует начинать большинство команд.
Давайте определим незрелую команду как команду, члены которой раньше не работали вместе, работают в неизвестной среде (например, в новой компании) и которые еще не определили свои процессы и элементы управления.
4 ответа
Мои 0,02 доллара
Это не совсем тот случай, когда какие-либо методологии специально ориентированы на незрелые группы разработчиков как таковые. Однако если есть характеристика методологии, которая будет полезна для неопытных разработчиков, это будет "четко определенный процесс".
Причина отказа от ответственности ("требуется зрелая команда разработчиков"), и это почти всегда применяется к гибким методологиям, заключается в том, что они требуют дисциплины и опыта (который можно получить только при работе над проектами и обучении на ошибках), чтобы выбрать правильные шаги и сделать правильный выбор. Зрелые (читай: опытные) разработчики знают, когда безопасно (и небезопасно) срезать углы, которые неопытные разработчики могут сделать безрассудно на каждом шагу. Кроме того, опытные разработчики обладают лучшей интуицией и делают лучший выбор, а также знают, как правильно реорганизовать дизайн и код при необходимости.
Чтобы преобразовать известную цитату Бьярна Страуструпа в методологии сопоставления (для) опытных команд, вы можете получить: "Используйте опытную команду с методологией, обеспечивающей большую гибкость, и они вполне могут выстрелить себе в ногу, развернуть неопытную команду в та же методология, и они, вероятно, оторвут себе ногу ". (Извинения Бьярне и всем, кто обижен мыслью о травмах ног:)
Это помогает иметь кого-то, кто знаком с методологиями, который может выбирать, что и когда добавлять. Попытка провести полную методологию в неопытной команде, вероятно, сокрушит команду. Было бы неплохо назначить кого-то старшего для владения процессом.
Сначала я бы начал с контроля версий и продолжения процессов сборки. Это поможет определить, нарушают ли другие изменения код. Автоматизированное тестирование, привязанное к процессу сборки, займет второе место. Выбор того, что строить и когда это также важно.
На протяжении всего этого сообщения о том, что работает, а что нет, должно происходить. Измените то, что не работает, и продолжайте добавлять.
Самое сложное - производить вещи, пока это происходит.
Если у вас есть код для поддержки, вы можете начать с небольшой группы, работающей над новым кодом для разработки методологии, и распространить ее в команде.
Методология должна способствовать получению нужной информации нужному человеку, когда это необходимо. Если методология мешает генерированию рабочего кода, решите проблему.
Покажите методологии водопада для вещей, которые должны быть рассмотрены. Изучите гибкие методологии для того, чтобы рассмотреть вещи в нужное время.
Я могу только посоветовать вам настроить среду, начать работать, и ваша команда адаптируется к выбранным методологиям. Создайте небольшие циклы выпуска и корректируйте выбранную методологию в начале каждого нового цикла выпуска.
Представление обзоров кода / дизайна может быть очень ценным первым шагом. Это (если введено правильно) может развить объединение команды; может привести к "неэгоистичному" программированию; привести к обмену знаниями и обучению; и обнаружение ошибок в начале процесса, когда энтузиазм может привести к серьезным ошибкам. Как и @BillThor, я думаю, что управление версиями является ценным, но я бы предположил, что командам, как правило, нужно испытать потребность в нем, прежде чем они полностью примут его, и что это происходит только после того, как у них возникла проблема с версиями. Элемент, который полезен для моего ответа, @Bill's и @Peter's, - это способность иметь наставничество доступным. Это (в идеале) роль менеджера с опытом разработки или старшего разработчика.