Проект, над которым я работаю, был завершен, но я хотел бы поразмышлять об управлении огромным экспериментальным решением, принятым одним разработчиком во время разработки. Это то, что произошло:
Разработчик сильно чувствовал, что что-то не так с текущим дизайном проекта. Из-за недостаточного знания он не мог выразить, что не так. Поскольку у нас есть крайние сроки, мы не можем ни ждать, ни работать с ним над его исследованием, поскольку он не может убедить нас, что не так.
Чтобы быть конструктивным, он сказал нам двигаться дальше, пока он проводит свои исследования и экспериментирует с огромными работами по перепроектированию своего филиала SVN. Пару недель спустя он представил нам работающий, сильно переработанный (и рефакторинговый) проект, в котором он уверен, и все нам объяснил. Мы были убеждены.
Однако, поскольку мы меняли и добавляли функции на основе старого дизайна, это было так же хорошо, как мы работали над двумя отдельными проектами, и слияние SVN стало невозможным из-за большой разницы. Тогда у нас было 2 варианта.
Чтобы работать над нашей копией, нам пришлось бы перепроектировать все наши функции в соответствии с новым стандартом, а также идентифицировать все рефакторинговые материалы.
Чтобы работать над его копией, мы должны были бы сначала определить измененные функции и правильно реализовать их в его дизайне, а затем новые функции.
Мы выбрали первый вариант, так как второй вариант все еще должен был бы иметь дело с большим количеством изменений дизайна из-за измененных функций с использованием устаревших классов и тому подобного.
Было потрачено много времени, и все казалось двойным (или, возможно, тройным) усилием. Хотя оно того стоило (мы действительно уложились в срок, приложив больше усилий), вопрос в том, учитывая обстоятельства, есть ли какая-либо методология, которую мы упустили из виду, которая могла бы более правильно справиться с таким сценарием? Или то, что мы делали, было правильным решением и что это на самом деле нормальное/обычное явление в разработке?
Обратите внимание, что он тоже не был уверен в том, что делал, поэтому ему пришлось закончить все, что он делал, чтобы увидеть, как это работает, и подтвердить свое исследование, прежде чем представить его нам. По общему признанию, мы все были разработчиками-любителями, включая его, но он как бы инстинктивно знал, что не так, но ему не хватало терминологии и опыта/знания тематических исследований, чтобы правильно передать нам до его исследования. Был шанс, что его инстинкты тоже могли быть совершенно неправильными.
Ваш вопрос затрагивает множество тем, включая области архитектуры и инженерии, которые не являются вопросами управления проектами. Итак, я в основном ограничу свой ответ перспективой управления проектами.
Короткий ответ заключается в том, что вы почти всегда извлекаете уроки во время проекта, которые делают более ранний первоначальный выбор подозрительным. Ретроспективность 20/20, и это неизбежное следствие Конуса Неопределенности . Вот почему методологии итеративного управления проектами и разработки, использующие эмерджентный дизайн, обычно предпочтительнее каскадного планирования, поскольку стоимость полного редизайна часто неприемлема для типичного проекта.
В тех случаях, когда требуется редизайн, нет канонического ответа на вопрос, как это сделать; это дело каждой команды и каждого проекта, которые следует учитывать в зависимости от конкретных обстоятельств. Кроме того, сосредоточьтесь на работающем программном обеспечении, которое является «достаточно хорошим», а не идеализированным, и убедитесь, что полученные уроки используются в рабочих процессах вашей команды.
Нет ничего плохого в всплесках сюжета , ограниченных по времени , а доработка и рефакторинг обязательны для итеративной разработки. Тем не менее, принцип YAGNI и «достаточно хорошая» инженерия выступают против радикальной переделки, если только ваш продукт не соответствует назначению или накопил слишком много технических проблем , чтобы их можно было модифицировать или поддерживать.
Идеальное — враг хорошего. Если ваше программное обеспечение работает и соответствует назначению, то отказ от него в пользу чего-то лучшего только потому , что он лучше , не будет хорошим руководством проектом . До того, как ресурсы проекта будут потрачены на такое предприятие, должен быть действующий бизнес-фактор.
Хотя это немного выходит за рамки, я бы предположил, что ваши методы разработки неоптимальны. Вам следует работать с технической командой над внедрением лучших практик, таких как:
Этот список не претендует на то, чтобы быть исчерпывающим, поскольку передовая инженерная практика выходит за рамки управления проектами. Как менеджер проекта, ваша работа заключается в том, чтобы работать с командой, чтобы убедиться, что у них есть обучение, ресурсы и административный/технический контроль для эффективной доставки продукта, но то, как они это делают на техническом уровне, не является вашей проблемой. .если они не работают эффективно. Если это так, вам нужно помочь команде и заинтересованным сторонам определить более эффективный процесс.
Promiscuous Integration, что заставило меня понять, что мы могли бы иметь по крайней мере один редизайн, чтобы получить ветку от нас, поэтому он всегда экспериментирует с последними обновлениями. Technical debtтакже еще одна важная вещь, которую я узнал, что заставило меня ухмыльнуться, когда 80% списка причин соответствовали нашей ситуации.
Зеленый