Agile (SCRUM, XP, FDD,...), Waterfall, RUP,... Почему бы маленькая компания не удосужилась принять ее в первую очередь. Почему бы не просто взломать каждый проект до завершения (с обычным размером команды 1 ~ 2).
Я готовлю короткую презентацию против аргумента, но хотел бы услышать, что все думают.
О, мой любимый тип вопроса. Всякий раз, когда появляется SDLC, соответствующий ответ всегда: "Это зависит!":) Я ненавижу этот ответ так же, как и все, поэтому давайте копаем глубже.
Если ваши проекты управляемы одним человеком и очень коротки (т.е. < 3 месяца), то формальный процесс, вероятно, имеет смысл. ПРИНЦИПЫ некоторых из процессов важны, но большая часть церемонии может быть удалена. Например, в способе Agile-y я все равно буду отслеживать карты с техническими историями (одно предложение или около того), истории пользователей (предложение или два), задачи и т.д., Поэтому я бы не бросил мяч ни на что, Я не буду делать итераций обязательно, просто катясь. Если вы знаете, что у вас есть жесткая дата для бета-версии/предварительного просмотра/независимо от того, вы можете запланировать свою волну, выбрав приоритет карт, которые вы работаете в неделю-неделю.
Одним из преимуществ процесса SOME является то, что вы, вероятно, оставите некоторые артефакты планирования/управления (незавершенные карты, отставание и т.д.), поэтому, если вам или кому-то еще нужно возобновить разработку в проекте, вы можете легко выбрать его для резервного копирования.
Проект 6mo и более с 2 или более людьми должен определенно иметь какой-то процесс, чтобы вещи не становились слишком хаотичными и не синхронизировались между членами команды. Здесь важны резервные копии, а также карты задач и подотчетность.
Все это, кстати, относится к управлению/процессу проекта. Даже в команде из 1 человека я все равно буду использовать контроль источника, непрерывную интеграцию, TDD и т.д. Это необходимо для качественного программного обеспечения, независимо от того, какой процесс вы используете для назначения задачи.
"взлом" - это процесс разработки, это просто не тот, который легко отслеживается или прогнозируется!
точкой процесса является согласованность и предсказуемость
Если проект "взломать" проваливается, это происходит:
"lazy programmers, they should work harder""next time I will really do unit testing" или "we should have taken *this* tools or *that* language...""Bye everybody, I'm leaving"И если запущенный проект "взломать" задерживается, менеджеры склонны добавлять в проект больше людей. Из там есть слово: "I need this baby in a month send me nine women!"
Сложная задача - адаптировать существующий процесс к вашей компании и команде:
Консистенция - это ключ. Если вы переходите от проекта к проекту, просто "взламываете", тогда потребуется сотруднику (или, особенно, новому сотруднику) больше времени, чтобы ускорить выполнение проекта, чем при наличии стандартов и соглашений. Неважно, какие стандарты/методология вы выбираете, пока вы выбираете тот, который будет работать для вашей команды, и используйте его последовательно.
Независимо от того, осознаете ли вы это, у вас уже есть процесс разработки. Самый важный момент в изучении широкого мира процессов - это узнать, что другие нашли способы сделать свою работу более продуктивной. Может быть, вы тоже можете!
Совершенствование процесса - основа процесса. Принятие процесса - это обучение системному совершенствованию, чтобы улучшения не трясли работу на куски.
Тот факт, что у вас есть только два человека в команде, не является препятствием для входа. Я использую принципы Lean и канбан даже в проектах, которые я делаю как команда одного человека. Я могу извлечь из этого выгоду, потому что я узнал от них, и от этого узнал, что мой разум был открыт для того, чтобы быть более продуктивным, чего я раньше не понимал.
Если вы уже чувствуете, что у вас нет ничего, что можно улучшить, вам, вероятно, не нужно смотреть в процессы за пределами того, что вы уже делаете. Если вы действительно так себя чувствуете, постарайтесь подробно наблюдать за своим эмоциональным состоянием, когда вы держите мысли в своем уме, исследуя процессы развития. Если у вас есть даже мельчайший момент стресса, когда вы это делаете, вы можете отступить от восприятия работы, а не от преимуществ обучения от работы и изучения других. Такая присущая психологическая отдача не является чем-то необычным, но ее редко полезно при столкновении с осмысленным вопросом.
Вы используете программный процесс для управления временем и ресурсами в проекте. "Взлом" отлично подходит для проекта одного человека, где вам все равно, что то, что вы производите, является чрезмерно бюджетным, доставляло прошлое все предельные сроки и фактически не отвечало требованиям клиентов *. Для проектов, которые заботятся об этом, программный процесс вводится как уровень управления. Затем менеджеры могут более эффективно отслеживать жизненный цикл разработки, фокусировать усилия на задачах, определенных как критические, важные и т.д., Предоставлять обратную связь клиенту относительно того, на каком этапе они находятся, и все другие вещи, которые кажутся несущественными для разработчиков, но менеджеров и клиенты любят, потому что это показывает, что мы на самом деле делаем то, что, по их мнению, полезно:)
* Я не предполагаю, что это всегда последствия для взлома или что более структурированный процесс удалит их. Они лучше называются областями "повышенного риска" метода взлома и, следовательно, проект, который просто взламывает, а хаки и хаки в значительной степени не волнует, если они происходят или нет:)
Я предполагаю ту же причину, почему существует процесс создания автомобилей и строительства домов?
Принятие процесса развития может уменьшить количество раз, когда вы говорите "О, должно было подумать об этом".
Если процесс "взлома" позволяет малой компании доставлять то, что хочет их клиент, и за счет того, что клиент доволен, компания не должна, по-видимому, не принимать какой-либо другой процесс.
Конечно, проблема заключается в том, что хакинг, даже в небольшой компании, затрудняет производство этих результатов. Кроме того, если компания или ее приложения хотят расти, взлома быстро станет несостоятельной.