Подтвердить что ты не робот

Какой процесс разработки программного обеспечения должен быть у одного разработчика?

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

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

Из книг и статей я нашел много вещей, которые могут быть полезны. Как и в случае с хорошим стандартом кодирования (существует только грубое руководство по стилю, которое, на мой взгляд, несколько устарело), ​​проверки кода, TDD, модульное тестирование, база данных ошибок... Но в небольшой компании кажется, что нет ресурсов или времени для все, что не существенно. Тот факт, что я работаю во встроенном домене, кажется, делает вещи только более сложными.

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

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

Возможно ли иметь процесс разработки в таком месте?

Помогло бы это иметь какое-то управление? Что?

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

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

Может быть, кто-то работает в подобном магазине?

4b9b3361

Ответ 1

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

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

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

Решение о том, что инвестировать в авангарде в зависимости от его риска (вероятность и эффект).

Кроме того, многие лучшие практики SW действительно "лучше", как контроль версий, автоматическое тестирование (для меня я использовал его только для раннего обнаружения регрессии, поскольку я не верю в TDD в качестве движущей силы развития). Я предлагаю вам прочитать " Pragmatic Programmer, в котором представлены многие из тех техников.

Как ответить на ваши вопросы:

(1). Возможно ли иметь процесс разработки в таком месте?

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

(2). Помогло бы оно иметь какое-то управление? Что?

Менеджмент помогает, но не контролирует урод. Планируйте, что делать, когда: интегрируйте, разрешите конфликт, мертвую линию камня длиной в одну милю. И грубо держите их по графику (особенно мне нравится Scrum sprint).

(3). Возможно ли сделать качественную продукцию с небольшими ресурсами?

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

(4). Как убедить себя и других в том, что компания, которая успешно работала в течение десятилетий, должна измениться? Что было бы важно?

Укажите проблемы. Если их нет, зачем менять? Если вы хотите изменить, вы должны иметь возможность идентифицировать проблему или возможные проблемы. Укажите проблему.

Некоторые из них:

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

  • Без процесса труднее работать в стрессе.

  • Без расписания трудно определить прогресс.

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

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

Просто мой, хотя.

Ответ 2

  • Используйте Source Control для ВСЕХ
  • Разрабатывайте спецификации и начинайте подписываться перед запуском - будет сопротивление, но объясните это ради собственного блага.
  • Единичные тесты! Это больно, потому что вы просто хотите это сделать, но это спасет вас в конечном итоге.
  • Используйте отслеживание ошибок - Bugzilla или FogBugz, если вы можете себе это позволить.

Ответ 3

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

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

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

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

изменить

И как сказал lod3n, источник управления, но вы используете это уже правильно???!!?!

Ответ 4

Был там, сделал это.

Книга Планирование экстремального программирования очень помогла. Я использовал карты 3x5, застрявшие на стене. Это помогло моему начальнику узнать о моем прогрессе, помогло с оценками и планированием, и я не отставал. Игра планирования дает хорошие боеприпасы, если ожидания вашего босса нереальны.

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

lod3n абсолютно прав в отношении управления версиями.

Я пошел с итерациями в стиле XP раньше; вы можете захотеть создать отставание элементов (даже что-то простое, например, электронную таблицу или карты 3x5).

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

Ответ 5

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

Непрерывная интеграция и автоматическая сборка могут помочь даже одному разработчику.

Невозможно особо подчеркнуть рекомендацию для контроля источника.

Ответ 7

как сумасшедший, так как это звучит, я использую схватку только потому, что мне нравятся понятия спринт и отставания. Это упрощает постановку реалистичных целей. Конечно, идея мастера схватки и команды - это все, что вы, но если вы работаете над внешними проектами, где возможно, что вы можете забрать дополнительного члена команды с отставанием, вам будет легко распределить работу. Может быть, мне нравятся отставания. С scrum вам нужно будет заставить кого-то быть менеджером продукта, чтобы рассказать о функциях продукта. Контроль версий - это, вероятно, должно быть реализовано b4, даже беспокоясь о процессе разработки программного обеспечения. Я работал в компании, которая начиналась с 2-х разработчиков и занимала до 12 лет. Мы начали без контроля версий и низких стандартов кодирования. Изменения, которые вам нужно будет сделать, будут постепенными, поэтому не беспокойтесь о том, чтобы спешить, чтобы сделать 180. Задайте цель изменить одну вещь в месяц и найти сторонников ваших изменений, чтобы все стало гладко.

Ответ 8

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

Ответ 9

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

Тогда есть реальные процессы разработки. Я всегда рекомендую иметь процесс, независимо от того, насколько он мал или большой. Трюк заключается в поиске правильного процесса. У вас есть процесс сейчас - это просто специальный процесс, который, похоже, не слишком хорошо подходит для вас. Редко вы можете взять процесс разработки учебника и напрямую применить его. Что вам нужно сделать, это адаптировать процесс к потребностям вашей компании и культуре. Посмотрите на столько парадигм развития, сколько сможете, и попытайтесь найти что-то подходящее, и они начнут формировать его в соответствии с вашими потребностями. Возможно, вам придется попытаться выполнить несколько разных процессов. Возможно, процесс Personal Software станет хорошим стартовым процессом, возможно, гибким процессом, вариантом RUP? У вас есть много вариантов, попробуйте их.

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

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