Как вы создаете программный процесс для проекта?

13

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

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

development-process specifications

— Томас Оуэнс
источник

Хороший, быстрый, дешевый процесс - когда проект отстает, сокращайте процесс.

— ChuckCottrill

2

Как это получилось?

— Роберт Харви

10

Я бы посоветовал вам взглянуть на гибкое программирование.

Вариантов много, но они имеют много общего:

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

Хорошее место для начала было бы MSF Agile или Scrum .

— Кит
источник

7

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

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

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

— Томас Оуэнс

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

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

— Томас Оуэнс

1

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

— ColinYounger
источник

1

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

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC - единственная система CI, о которой я знаю, которая делает push-репозиторий, а не pull, что означает (теоретически) больше не сломанные сборки!

1

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

— Джонно Нолан
источник

0

Ознакомьтесь с этими статьями о непрерывной интеграции для программирования на .NET с использованием MSBuild, CruiseControl.NET, FxCop, NUnit, NCover и Subversion ...

Из окопов разработки программного обеспечения

— Зак Петерсон
источник

1

@Zack: мы не используем .NET программирование. Я ищу общий совет, который можно использовать в любом проекте, используя любой стек технологий. Такие вещи, как выбор модели, реализация этой модели и так далее.

— Томас Оуэнс