Как я могу преодолеть плохо структурированную модель разработки программного обеспечения?

11

Я присоединился к компании в настоящее время я работаю как более свежим. Из-за ограниченного числа квалифицированных специалистов по разработке программного обеспечения ГИС, а также из-за того, что я был одним из них, я был непосредственно нанят в качестве руководителя проекта.

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

Благодаря интересу, который у меня был к работе, появилась возможность, и в конце концов я стал ответственным за отдел бизнес-аналитики компании. Компания поверила в меня. Я сам изучал концепции хранилищ данных и бизнес-аналитики и успешно сочетал ГИС и бизнес-аналитику.

Также в настоящее время я работаю с двумя разработчиками над нашим инструментом BI в C # WPF, где я также иногда играю роль разработчика (что мне нравится).

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

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

picmate
источник
4
Я не уверен, что у вас уже есть, но вы обсуждали ситуацию со своими непосредственными коллегами?
Fanatic23

Ответы:

14

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

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

Построить медленно (но так быстро, как вы можете: P), стабильно и уверенно.

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

  1. Изучите хорошую систему контроля версий и изучите ее хорошо. Лично я бы рекомендовал мерзавец или мерзавец. Существует много документации по обоим.
  2. Постройте прочное ядро на практике и шаблонах . Читайте книги, читайте блоги, смотрите скриншоты с членами команды. Это придаст новый вид развитию.
  3. Изучите TDD / BDD и попробуйте применить его в новом коде , а также в старом коде, к которому вы можете прикоснуться при выполнении новой функции.
  4. Заниматься парным программированием . Две головы думают лучше, чем одна, а также 4 глаза лучше, чем 2 :).
  5. Узнайте о последних и наиболее часто используемых инструментах в сообществе языка, который вы разрабатываете в настоящее время. Узнайте о них и попробуйте включить некоторые из них в проект. Посмотрите, как они были построены, и узнайте.
  6. Используйте схватку . Итерации, истории, сюжетные моменты, препятствия - все это концепции, с которыми вам следует ознакомиться. Для меня scrum - лучший рабочий процесс для разработки программного обеспечения и управления им. Примените это и учитесь у каждого дня опыта.
  7. Учите примером . Большинство начинающих разработчиков хотят изучать новые вещи, но некоторые из них очень ленивы. В любом случае, покажите им новые вещи, которые вы изучали и применяли, и, надеюсь, это пощекочет их мозг.

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

Не ленись и не унывай. Просто учитесь на своих ошибках и пробуйте разные подходы. Это только начало!

Редактировать:

Вот некоторые ссылки и книги, которые я читал / использовал в последнее время ...

Обучение Git: Pro Git

Вот некоторые из блогов, которые я бы порекомендовал (большинство из них ориентированы на .NET):

Для книг вы можете увидеть список Buiding A Solid Programming Core на Amazon. Я также рекомендовал бы это:

Эдгар Гонсалес
источник
@ Эдгар, большое спасибо. Это круто, и я думаю, что вы объяснили, будет хорошо для меня. Поскольку я не вижу другого пути, дайте мне знать, если это нормально, чтобы принять ваш ответ как правильный и придерживаться его вслепую.
picmate
1
@ Picmate Конечно, это ваш звонок. Кроме того, при обучении на примере обязательно похвалите прогресс, достигнутый разработчиками.
Эдгар Гонсалес
@ Эдгар, конечно. Если вы знаете какие-либо полезные ресурсы, которые я мог бы использовать, пожалуйста, укажите их также для каждого пункта вашего ответа (если применимо). Кроме того, так ли способна любая хорошая фирма-разработчик продолжить разработку программного обеспечения? (поскольку у меня никогда не было возможности быть в хорошей девелоперской компании)
picmate
1
@picmate прежде всего, эти шаги не должны применяться отдельно. Они накладываются друг на друга, они не в каком-либо определенном порядке (кроме первого). Я опубликую некоторые ссылки позже в тот же день
Эдгар Гонсалес
2
@picmate. Поскольку генеральный директор не имеет технических знаний о том, что вы делаете, вы можете убедить его в том, что он знает. Например, вы можете объяснить, что, если у вас есть контроль версий, вы можете избежать потери работы и, таким образом, финансово предотвратить потерю прибыли при восстановлении утерянного кода, или, изучив лучшие практики разработки, вы можете помочь компании, будучи эффективной, таким образом сокращение времени на разработку функции.
OnesimusUnbound
6

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

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

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

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

Настройте контроль версий . На самом деле, настройка Git занимает 5-10 минут, еще несколько минут, чтобы завершить основные операции, и один-два дня чтения, чтобы получить более продвинутые концепции.

Демиан Брехт
источник
1

Хм, не уверен, что встретил вас на мероприятии Agile / XP в Торонто - звучит знакомо

Похоже, вам нужен перерыв. Возьмите длинные выходные, напитесь, если хотите, и забудьте о работе на несколько дней.

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

Существует (бета) сайт pm.stackexchange.com, предназначенный для управления проектами, вы можете получить там полезную консультацию / поддержку - но, конечно же, оставьте здесь вопрос.

Переходя к техническому материалу:

нет системы контроля версий

Поместите один в ваш главный приоритет. Я предпочитаю централизованные системы, такие как SVN (Subversion), а не git / mercurial, потому что украденный ноутбук не будет иметь такой большой истории локально. Особенно важно, если что-нибудь сверхсекретное (например, пароли и ssh-ключи) было зарегистрировано по ошибке. Но это вопрос вкуса. Ничто не тратит больше времени, чем ошибки «ручного управления версиями» - например, возвращение кода к тому, что вы думаете.

Удачи

Фил Лелло
источник
Привет, спасибо за ответ, и, вероятно, это не я встретил тебя в Торонто. Я нахожусь в этой должности почти полтора года. Как вы думаете, я теряю время без успеха?
picmate
0

Похоже, у вас есть несколько проблем: 1. Общение с нетехническими руководителями, чтобы они поддержали вашу программу улучшения; и 2. Управление программой улучшения для достижения успеха.

Самая сложная часть первого номера - просто помнить, что высшее руководство часто не будет интересоваться деталями того, над чем вы работаете. (Если бы они были, они бы делали это сами, а не передавали бы вам!) Похоже, что большое препятствие - это «почему», и вы, возможно, захотите взглянуть на CMM 1.1 для описания бизнес-преимуществ улучшения процесса. программа. Вне зависимости от того, используете ли вы CMM или что-то еще для фактического улучшения вашего процесса, в этом обсуждении не будут иметь значения, только данные из исследования Карнеги-Меллона, которые показывают, что более зрелые организации быстрее реализуют проекты с меньшими колебаниями времени доставки.

Есть много путей к успеху в улучшении процесса, все они, как правило, очень длинные. Опыт работы с CMM показывает, что для перехода с уровня 1 на 5 может потребоваться от 8 до 10 лет. Опыт работы с 6 сигмами показывает, что каждая итерация дает некоторое улучшение, но для устранения большинства потенциальных проблем требуется несколько итераций, и к тому времени, как вы доберетесь до 6 сигм качества, работа ведется совершенно по-другому, не рискуя попытаться заменить все сразу.

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

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

Удачи, сэр!

кас
источник
0

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

Как уже отмечали другие, вам необходимо:

  • Попробуйте принять практики по очереди. Не пытайтесь все из них сразу, потому что это ошеломит людей.
  • Вы должны выяснить хороший заказ для этого. Я бы начал с контроля версий. Тогда иди с более легкими. Как только люди начнут верить в то, что вы принимаете правильные решения, и они увидят преимущества, они с большей вероятностью примут более рискованные изменения.
  • Создайте солидное обоснование того, почему что-то должно быть реализовано. С 2-3 разработчиками, которые постоянно делают прогресс видимым для конечных пользователей, трудно оправдать принятие более сложной методологии разработки, например. Вы будете рассматриваться как процесс, а не результат.
  • Имейте в виду, кого вам нужно убедить. Разработчики? Генеральный директор?
Хория Коман
источник