Я учусь на последнем курсе бакалавриата, изучаю программную инженерию. Модуль 1 для моего последнего года состоит из проекта разработки примерно на 6 месяцев.
Я совершенно новичок в этом уровне управления проектами или даже продолжительности.
В прошлом году на промышленном размещении самое долгое время, которое занимал личный проект, составляло 23 дня, мне предоставили спецификацию для индивидуального «дополнения» и вернули решение с подробным описанием проведенного мной тестирования.
Мне любопытно, действительно ли определение подхода, который я хочу использовать заранее, так важно, поскольку я никогда не использовал конкретный «фирменный» подход?
Если мне действительно нужно объявить методологию и подход, ни один из них, похоже, не имеет точки, в которой они определяют, что они могут быть не самыми подходящими. Я скорее подниму руки и скажу: "Хорошо, xyz не сработал для меня. Я попробую это...", чем застряну в серии приращений, итераций, блок-схем и не сделаю на самом деле большую часть моего времени.
PS Похоже, что в SO нет тега «домашняя работа», чтобы указать, что это связано с учебным проектом.
Это не просто важно, это необходимо. Невозможно спланировать свой проект, то есть определить, кто вам нужен, что вам нужно, когда вам это нужно, сколько это будет стоить, сколько времени это займет у вас, если у вас нет метода атаки.
Простая аналогия: если вы хотите путешествовать по стране, можете ли вы это сделать, если еще не определились со способом передвижения? Если вы хотите увидеть страну на машине, вам пригодится билет на самолет. Если вам нужно пересечь страну за несколько часов, пешие прогулки не вариант. Если вы хотите по-настоящему ощутить атмосферу Средней Америки (или где бы вы ни жили), делать это на эшелоне полета 350 не стоит.
Миссия диктует методы, диктует план, диктует ресурсы.
Однако метод нельзя применять без рассмотрения. Вы не берете предписанный метод, размещаете его на стене и говорите: «Все, идите и делайте это». Метод должен быть адаптирован к вашей миссии и среде. По сути, так развиваются методы и находят новые методы. Хорошее правило: НИКОГДА не реализуйте метод так, как это предписано.
Вы поднимаете важный вопрос: что происходит, когда ваш метод работает не так, как вы думали. Невероятно сложно (читай, кажется невозможным) отказаться от выбранного вами подхода, когда вы уже в нем. Это искажение невозвратных издержек, когда мы склонны придерживаться чего-то из-за уже сделанных инвестиций. Невозвратные затраты никогда не должны быть одним из ваших критериев, но почти всегда таковыми являются. Можете ли вы представить себе, как вы идете к своему клиенту и говорите ему, что метод, который вы предложили за 1,5 миллиона долларов назад, не работает, и вам нужно двигаться в другом направлении? Это случается и является правильным деловым вызовом, но невероятно трудным и рискованным.
Так что выбирайте свой метод мудро и после серьезных критических размышлений. Измените его, чтобы он соответствовал миссии и окружающей среде. И будьте достаточно гибкими, чтобы отказаться от него, если вы ошиблись в суждениях или другие факторы мешают успеху.
«Хорошо, xyz у меня не сработал. Я попробую это ...», вместо того, чтобы застревать в серии приращений, итераций, блок-схем и не использовать свое время по-настоящему.
Обратите внимание, что ваш комментарий о том, что xyz не работает, я попробую .... является одной из величайших концепций, связанных с итеративной разработкой и планированием. Не бойтесь застрять в заранее определенном плане проекта. Наслаждайтесь изменениями, если это необходимо, настраивайте свой процесс, вносите изменения, чтобы они были быстрее и эффективнее.
Каждый проект имеет корректировки курса на протяжении всего срока его действия. Тем не менее, вы хотите уменьшить количество исправлений и их размер. Вы также хотите сбалансировать количество новых вещей, которые вы пробуете.
Люк
Дэвид Эспина
Люк