Модели жизненного цикла программного обеспечения для веб-разработки

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

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

Сейчас в офисе просто хаос. Вчера я получил массу смеха от менеджера проекта, сказавшего ему: «Наш процесс — это звук хлопка в ладоши». Мы отчаянно нуждаемся в процессе, но мы не знаем, что делать. Все придерживаются обратного подхода, желая получить инструмент, который подскажет им, как что-то делать, когда мы должны сначала собрать требования.

Мы магазин всего 9 человек. Нам нужно уметь работать быстро. Какие хорошие модели разработки программного обеспечения сейчас являются отраслевыми стандартами? Все остальные делают это, поэтому нам нужно учиться, этот магазин занимается созданием сайтов с 1995 года. Где я могу найти хорошие ресурсы по передовому опыту? Мы магазин LAMP.

РЕДАКТИРОВАТЬ: я также должен добавить, что мы хотели бы добавить процесс на существующие веб-сайты. Таким образом, мы не строим новые проекты, на что всегда ориентированы эти модели. Мы поддерживаем 10-летние монстры сайтов (окей, 3-5 лет, но клиенты старше) и продолжаем их работу, постепенно добавляя новые функции. Может ли что-то из этого помочь там?


person tkotitan    schedule 25.11.2009    source источник


Ответы (6)


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

http://en.wikipedia.org/wiki/Agile_software_development

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

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

РЕДАКТИРОВАТЬ (в ответ на вопрос редактирования): ДА! Agile определенно поможет вам с обновлениями и улучшениями существующих проектов, а также с возможными выпусками рефакторинга. Это все включено.

~md5sum~

person Nathan Wheeler    schedule 25.11.2009
comment
+1 за то, что все должны быть на борту, иначе это не сработает. руководство И разработчики. - person kenwarner; 25.11.2009
comment
Приятно иметь своих существующих разработчиков на борту, но их можно заменить, если они не хотят сотрудничать, и, кроме того, я не встречал хороших разработчиков, у которых были бы проблемы с работой по гибкой методологии. К сожалению, вы не можете уволить своего босса. Архитектор решений, где я работал, отвечал за выбор используемой методологии, и, хотя он был хорошим парнем, я не думаю, что он смог бы решить тест FizzBuzz менее чем в 3000 строк кода на C#. Он утверждал, что ему нравится Scrum, и что мы БЫЛИ гибкими, но мы были больше похожи на какой-то сломанный водопад. Водопад без воды, может быть... - person Nathan Wheeler; 26.11.2009

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

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

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

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

**Например, ** Если вам нужно добавить страницу на существующий сайт, возможно, создайте руководство по процессу (поскольку каждая страница будет отличаться, как и клиент). У вас может быть процесс, аналогичный следующему: 1. Соберите проблемы клиентов, требования, идеи, ожидания и т. д.: (Собеседование по требованиям) 2. Идентификация существующих стандартов/реализации 3. Перечислите все задачи, необходимые для завершения добавления страницы 4 ● Создайте сложную структуру разбивки работ (WBS) и график/крайний срок для каждой задачи 5. Создайте систему управления ходом выполнения (это новый процесс, который необходимо разработать) 6. Делегируйте задачи/конечные сроки/команды и т.д. 7. Наладьте общение в команде. 8. Проанализируйте/протестируйте ход выполнения. 9. Скорректируйте задачи/WBS/график на основе установленных методов Agile/Scrum.
10. Повторяйте до тех пор, пока не будет выполнено/удовлетворено требованиям.

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

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

Чтобы любой из ваших процессов был эффективным, вам нужно будет сообщить своей команде, что работает, не работает или что работает, но нуждается в улучшении. Вот некоторые инструменты, за которые я получил высокую оценку: 1. Slack dot com: это инструмент управления командным проектом. 2. G Suite: это платный набор приложений, но вы можете так же легко использовать Gmail, Google Drive, Google Sheets, Docs, Calendar, Hangouts, Google + и другие их бесплатные инструменты.
3. Trello dot com : это крутая доска для совместной работы, которую я использую с друзьями для своих проектов. У вас могут быть личные доски или общие доски: календари, команды, подключения по электронной почте, напоминания и т. д. Мне очень понравился этот инструмент сайта.

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

Наконец, управление проектами — сложная задача, но тот, кого вы наняли, должен был помочь вам с этой дилеммой. Тем не менее, вот несколько сайтов, которые могут помочь вам в управлении собственными проектами: 1. PMI dot org: это институт управления проектами. Даже если вы не являетесь руководителем проекта и не хотите им быть, здесь вы найдете действительно полезные идеи и советы для всех, кто занимает руководящую должность и курирует логистику проектов.
2. SDLC PM: Это все еще PMI.org, но эта ссылка относится к вашему вопросу. 3. Projectmanager.com: инструменты для управления проектами. Здесь также есть ссылка с дополнительными ресурсами.

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

-ОдриЛин

person Audrey Lin    schedule 09.10.2017

Agile и Экстремальное программирование (XP) работают хорошо. У меня также есть хороший опыт работы с Rational Unified Process (RUP).

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

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

person Justin Niessner    schedule 25.11.2009

Ажиотаж Agile. Мне нравятся принципы, лежащие в основе Lean, корни которого лежат в Agile-сообществе.

person Marius Burz    schedule 25.11.2009

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

РЕДАКТИРОВАТЬ: Так же, как и что-то еще, есть ли у вас это на месте:

  • Тестирование. Есть ли у вас автоматизированные тесты?
  • Непрерывная интеграция — знаете ли вы об этом? Использовать его вообще?
  • Контроль версий — есть ли у вас ветки и процедуры или регистрации?
  • Методология разработки - Ad hoc или менталитет "Просто делай то, что работает"?
  • Среды. Существуют ли среды разработки, тестирования и производства?
person JB King    schedule 25.11.2009
comment
нет, смех был искренним, потому что он знает, что я прав. Процесса буквально нет. Каждый руководитель проекта занимается своим делом. Мы разговариваем друг с другом и выполняем работу, а потом тушим пожары. Настоящий хаос. - person tkotitan; 25.11.2009
comment
Хоть какая-то работа делается. Я могу себе представить, что в некоторых местах ничего не делается из-за того, что все указывают пальцем на то, по чьей вине ничего не делается. - person JB King; 25.11.2009
comment
Да, но бывают дни - нет - недели, даже месяцы, когда я готов убить время на простои! :) Но ты прав. В моем офисе царит невероятный дух сотрудничества, никаких обвинений, мы просто работаем вместе, чтобы решить проблему и помочь клиентам. Я никогда не видел ничего подобного. - person tkotitan; 25.11.2009

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

person Pasta    schedule 25.11.2009