Программирование против планирования [закрыто]

15

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

Можно ли все еще быть хорошим программистом, не будучи планировщиком высокого уровня?

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

MattW
источник
Если ваша должность является разработчиком, почему вы планируете? Может быть, оценка, но не план
SuperM
Да, это возможно. В этом случае ваша производительность будет сильно зависеть от того, насколько хорош ваш менеджер / руководитель команды
gnat
1
Это действительно интересный вопрос. Я не думаю, что вам нужно делать много технических спецификаций, чтобы стать хорошим старшим разработчиком - в Agile разработке многие функции новой системы или проекта проявляются. Смотрите мой ответ для получения дополнительной информации.
Робин Уинслоу,
1
Как эта цитата? «Дни кодирования могут сэкономить часы планирования» или что-то в этом роде.
Дрейк Кларрис

Ответы:

17

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

Вы должны прочитать больше о гибком планировании , вы можете найти его более подходящим для вашего мышления. Многие Agile методологии пытаются найти способы отойти от подробного, долгосрочного планирования.

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

Прочитайте Agile Manifesto и посмотрите на Scrum . Используйте метод итеративной разработки и разработки динамических систем для руководства проектом.

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

Однако, безусловно, верно, что если вы станете более старшим программистом, вы, вероятно, будете меньше программировать, но я думаю, что в Agile команде вместо того, чтобы писать больше технических спецификаций, это будет означать, что вы потратите больше времени на управление и обучение члены вашей команды и принятия архитектурных решений о коде.

Робин Уинслоу
источник
4
«Подробные долгосрочные планы проекта печально известны тем, что они обычно крайне неточны». DING DING DING +1
Райан Кинал
11

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

Блез Свонвик
источник
1
Я не против планирования работы, которую я делаю прямо сейчас / в следующие 2 недели. То есть, если то, что я собираюсь написать, включает в себя несколько частей, я не против планирования этого на высоком уровне, а затем делать это (на самом деле - это именно то, что я бы сделал). Мне не удается придумать дату месяца в будущем, а потом попытаться выяснить, почему мы не собираемся это делать. Вот где мое личное разочарование начинает достигать своего пика.
MattW
Я стараюсь не позволять этому расстраивать меня лично. Я стараюсь связывать подобные вещи с менеджерами проектов;).
Блейз Суонвик,
Добавить к комментарию Блейза. Плохие менеджеры настаивают на соблюдении графика и обвиняют команду в пропущенных «обязательствах». В этой среде графики, безусловно, разочаровывают. Хорошие менеджеры понимают, что первоначальный график является базовым предположением, а не обязательством. Они знают, что некоторые задачи займут больше времени, а некоторые - короче. Что их больше всего интересует, так это долгосрочные тренды. Например, в настоящее время мы отстаем на 20% от базового графика за 3 месяца. Это, вероятно, означает, что мы выполним на 20% больше по оставшимся аналогичным задачам. Затем они используют этот новый график для управления проектом.
Данк
9

Можно ли быть хорошим программистом, а не планировщиком высокого уровня?

Какое-то время да. Возможно ли это сделать долго? Нет.

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

Дэвид Хаммен
источник
Я запутался. Теоретически, повышение COL должно идти в ногу с уровнем инфляции. Вы предполагаете, что реальные доллары, выплачиваемые разработчикам программного обеспечения, постепенно уменьшаются? Или это повышение COL, как правило, больше, чем фактическое увеличение стоимости жизни? Я бы сказал, что большее беспокойство вызывает то, что неспособность продемонстрировать рост сама по себе считается негативной. Тем не менее, есть и другие способы продемонстрировать рост, такие как большая широта или глубина технических навыков.
Этель Эванс
1
Я должен был сказать, что повышение конкурентоспособности отрасли, а не повышение стоимости жизни. Я отредактировал свой ответ, чтобы сказать именно это. Эти конкурентные повышения в отрасли довольно приятны для молодых людей, как правило, намного лучше, чем инфляция. Стоимость жизни повышается для старых хренов. Есть проблема, когда кто-то поднимает ставку выше, чем инфляция, но навыки этого человека остаются новыми.
Дэвид Хаммен
Попался! Спасибо за разъяснения, это определенно имеет смысл.
Этель Эванс
К сожалению, я бы сказал, что со временем навык программирования становится все легче усваивать, и поэтому существующий навык инженера, не связанный с ростом, обесценивается за пределами COL.
Новая Александрия
6

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

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

Если вы довольны таким положением дел, вам больше под силу. Большинство людей становятся менее довольны тем, что больше опыта они получают.

Грязный маленький секрет, что никто не очень хорош в долгосрочном планировании и оценке. Лучшие планировщики - это те, кто знает об их ограничениях, так что, хотите верьте, хотите нет, но вы впереди. Получите некоторое обучение по учету неопределенности в оценке. Посмотрите на такие методы, как планирование на основе фактических данных или разборки, которые основаны на исторических данных, чтобы показать, насколько точны ваши оценки. Вы будете счастливее в долгосрочной перспективе, если у вас будет больше влияния на вашу работу.

Карл Билефельдт
источник
«Грязный маленький секрет, что никто не очень хорош в долгосрочном планировании и оценке». Разве это не правда! +1 только за это. Даже с хорошей историей, есть много чисел, которые нужно вырвать из ясного голубого неба, потому что следующий проект никогда не будет точной копией любого предыдущего проекта. Если бы это было так, мы могли бы повторно использовать весь код как есть и покончить с ним как можно скорее. Всегда есть что-то новое, и прошлые результаты не всегда являются хорошим индикатором того, какие усилия необходимы для этого нового материала.
Дэвид Хаммен
Хорошо - возможно, разочарование (и даже эго ) - это больше, чем мне нужно управлять. Если я не смогу слишком сильно себя избить и просто поправлюсь со временем (вместо того, чтобы говорить «мне не нравится это делать») - я буду лучше в долгосрочной перспективе. Я плохо себя чувствую, когда делаю это плохо - но кажется (основываясь на ответах здесь), мне лучше научиться делать это хорошо, если я хочу остаться работать инженером-программистом. Я ценю мысли каждого. У меня действительно нет никого в моей компании, чтобы учиться этому - поэтому услышать это от всех здесь - огромная помощь!
MattW
3

Можно ли быть хорошим программистом, а не планировщиком высокого уровня?

Краткий ответ: Да, это возможно.

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

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

Юсубы
источник
1

Да и Нет, ваши ответы.

С одной стороны, вас подталкивают к управлению проектами. ИМО, у всех хороших программистов есть некоторая способность к управлению проектами, но это разные навыки. Способность планировать на долгосрочную перспективу улучшает вашу способность общаться с фактическим управлением проектом. Так что «нет», вы не можете быть хорошим программистом без способности планировать на длительный срок.

При этом управление проектами - это другой набор навыков, который обращается к аспектам, которые связаны, но отличаются от программирования. Так вот, где «да» вступает в игру. Вам не нужно быть менеджером проекта, чтобы быть великим программистом.

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


источник
1

Планирование и Bungie-Boss

У Дилберта много поводов про босса. Наши проблемы и ожидания в отношении планирования могут быть как причиной, так и следствием лидерства. Мой опыт работы в компании из списка Fortune 100 заключался в том, что через год ушли все, кто начинал год в качестве руководителя проекта. Возможно, это было связано с проблемой планирования. Не уверен, что ваш прежний лидер оставил по этой причине, но когда ваша роль требует от вас, вы должны составить план с обязательством, если он не выполняется, часто результатом является выход из-за предельного срока.

Организационный контекст планирования

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

Планирование является важным инструментом. Не пренебрегай этим. Не поймите меня неправильно.

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

Простой пример планирования - не должно быть о программном обеспечении ...

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

Стать лучшим планировщиком

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

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

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

SLIM - это метод, изобретенный Путнэмом после работы в GE и других компаниях над проектами DoD в 1970-х годах. SLIM является влиятельным, и его компания QSM предлагает сертификацию, которая, кажется, вытекает из созданного ими инструмента. В зависимости от того, принял ли ваша компания их инструмент, он может не иметь никакой ценности или иметь высокую стоимость.

Стив Макконнелл (автор Code Complete) также написал книгу об оценке программного обеспечения, а его компания Construx преподает два класса для кредитов PDU , которые аккредитованы в Институте управления проектами. У меня есть его книга, и если бы я хотел узнать об этой теме в классе, я бы, вероятно, выбрал Construx. Они также проходят обучение Scrum и проводят различные оценки Scrum, аккредитованные через Scrum.org.

Другим источником, который мог бы обеспечить отличную академическую подготовку по оценке программных проектов, была бы группа Барри Бёма в USC , основанная на их обширной работе над конструктивным моделированием затрат COCOMO и COSYSMO, которая использовалась в НАСА и других крупных подрядчиках для оценки очень крупных проектов. Я не уверен, что я действительно верю в COCOMO, но мне нравится эмпирическая работа, которую они проделали, чтобы соотнести влияние масштабов и стоимостных факторов на продолжительность графика.

Я также нашел главу из учебника, изданного О'Рейли, в котором кратко обсуждаются основные методы оценки программного обеспечения, включая Уоттса Хамфриза ПРОБЕ и игру по планированию Кента Бека. PROBE включает в себя понятие, что инженеры отслеживают метрики по собственной продуктивности, а затем применяют их для своей части назначения в новых проектах. Planning Game очень тесно сотрудничает между разработчиками и другими заинтересованными сторонами.

DeveloperDon
источник