Это нормальная процедура разработки? - PullRequest
1 голос
/ 26 октября 2009

Сначала немного о себе. Я не опытный инженер-программист, архитектор или разработчик. За последние 5 лет я делал в основном небольшие проекты ASP и ASP.NET на C #. Я довольно хорошо разбираюсь в HTML и JavaScript. Эти проекты были выполнены, когда у меня было свободное время от других моих обязанностей, которые не были связаны с разработкой программного обеспечения. Теперь я перешел на должность разработчика программного обеспечения. Компания, в которой я работаю, не является фирмой по разработке программного обеспечения.

Сейчас я работаю над LOB-приложением Silverlight с WCF и Entity Framework. Мне дали небольшие спецификации для этого проекта, просто «сделайте приложение наподобие X, только проще, чтобы нам не пришлось за него платить», мой начальник не проверяет мой прогресс так часто, как я думаю, он должен, менеджер проекта (сотрудник) время от времени останавливается, но мы никогда не обсуждаем спецификации, архитектуру, пользовательский интерфейс или бизнес-правила. Меня в основном спрашивают, когда я думаю, что это будет сделано. Мне пришлось изучить Silverlight, WCF и Entity Framework, чтобы работать над этим проектом, и это не проблема, так как мне действительно нравится работать с этими технологиями. Проблема в том, что я единственный в компании, кто что-то знает об этом, и у меня нет наставника / начальника, чтобы обсуждать проблемы и способы их решения. Мне удалось найти одну заинтересованную сторону в компании, которая хотя бы дала мне список некоторых требований.

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

Должен ли я чувствовать себя так или я далеко от базы?

Спасибо за внимание.

Ответы [ 5 ]

8 голосов
/ 26 октября 2009

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

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

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

Это будет хаотично, без сомнения, но вы многому научитесь.

2 голосов
/ 26 октября 2009

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

В идеальном мире у каждого была бы надежная Методология Качества, которая обеспечила бы основу для реализации Проекта и внедрения систем. Это просто не реальность.

Вот несколько советов, которые помогут вам работать более эффективно:

  • Определите ваших спонсоров (людей, которые владеют продуктом) и определите преимущества высокого уровня и движущие цели бизнес-задачи, которую они стремятся решить
  • Определите ваши заинтересованные стороны (кто имеет влияние и у кого есть интерес) и заставьте их как можно больше сообщать о своих потребностях
  • Вовлекайте в процесс как спонсоров, так и заинтересованных лиц как можно больше или столько, сколько они захотят
  • Запишите, какие требования вы можете от них, через письменную форму (электронная почта)
  • Предоставить им возможность получить представление о доставке и обеспечить обратную связь
0 голосов
/ 26 октября 2009

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

"Когда это будет сделано?" вопросы лучше всего решить путем регулярного предоставления небольших частично функциональных сборок, которые вы можете использовать для получения полезной информации из движущейся цели, которая является вашим клиентом. Удивительно, как много может происходить общения, когда кто-то (ваш босс / клиент / конечный пользователь) действительно может «поиграть» с чем-то перед собой и пересмотреть то, что он действительно хочет.

0 голосов
/ 26 октября 2009

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

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

Идеальный мир лежит где-то посередине.

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

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

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

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

Удачи!

0 голосов
/ 26 октября 2009

Ваш проект, скорее всего, потерпит неудачу с точки зрения вашего босса. Потому что я уверен, что вы разрабатываете программу, которая ему не подходит. Но ты не чувствуешь себя виноватым. Это боль твоего босса (потому что ты хороший программист). Извините за столь темный пост: -).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...