Интересно. Благодарю!
Вот, действительно, пользоваться облачными сервисами, это либо урезанный функционал и не понятные перспективы, либо у конторы много денег.
Редмайн достаточно функционален. То, что он опенсорс при таком функционале, является неоспоримым преимуществом перед другими решениями.
Если нужны доработки «под себя», можно нанять разработчиков. А вот, как заказывать доработки во всяких облачных решениях?
По поводу интерфейса. У Редмайн есть ведь api. Можно же сделать/заказать отдельную доработку, заточку интерфейса для собственных нужд под конкретный сценарий использования. Сделать модное приложение. Как вариант.
Да, перевод — жесть. Причем, с самого начала. «Кроме того, там также будет обновляться база знаний. » Каким образом, тот факт, что по скала три будет, так же, обновляться база, является критерием (причем, одним из), того, что этот язык «новый»?
С этим, особенно, с последним предложением согласен.
Про то, что гибкие методы надо использовать в случае неопределенности предметной области, похоже, нигде не заострялось внимание. Всё говорилось, именно, про то, что заказчик может поменять требования. Но, нигде не заострялось внимание, что требования заказчик может поменять, потому что, сама предметная область «не изведана», а не потому что, например, «заказчик капризный».
А не получается ли тогда, что предметная область «не изведана», в случае, именно стартапов (исследовательских проектов), заказчиком которого являются сами разработчики (или, как вариант, инвестор)?
И, второй вопрос. Может, часто надо просто достаточно изследовать саму предметную область, прежде чем делать проект, и по ходу смотреть, «что там да как»? (понятно, что тут баланс скорее всего нужен)
В таком случае, без всяких эджайл манифестов, понятно, что надо сначала попробовать. Потом посмотреть, получается или нет. Если возникли какие-то проблемы и/или стало понятно куда двигаться/сворачивать, то делать это. Опять, же маленькими шагами. Что тут, тогда, эджайл нового привнес?
я больше про то, что раз «не раскурили предметную область» и «не смогли в требованиях», то давайте придумывать эджайлы всякие.
наподобие того, как у нас попадаются заказчики, когда мы пытаемся получить с них требования, а они говорят, например, «ну нарисуйте нам хоть какую-нибудь форму, мы посмотрим, тогда и скажем, что нам надо». Т.е., абстрактное мышление стремиться к нулю, хотя речь идет об их повседневной деятельности.
так же и сами разработчики. пока не запрогарммируем сами хоть что-нибудь, вообще не сможем понять, что надо-то было => работаем итерациями. а на самом деле, может надо было просто, все же суметь разобраться в предметной области (конечно, заранее все не предусмотришь, и гибкость должна быть и в методологии, но не такая, что начинаем делать чебурашку, а в итоге переделываем в слона. просто сразу не поняли, что надо слона именно делать).
Как пример, пришлось мне полгода где-то поработать в стартапе, где вот прям скрам (не знаю, на сколько именно соответствовал процесс скраму). попал туда уже, когда им через пару месяцев надо было сдавать проект, а у них вопрос стоял, что все это надо переписать. Делался до этого проект, как понял, почти год. Хотя, на самом деле, ничего там инновационного, с точки зрения функционала не было. впечатление было, что просто не было у команды опыта. Эджайл тут никак не помог.
А не может ли быть такая ситуация, что «требования могут поменяться», лишь потому, что аналитики не могут грамотно составить требования заказчика и не разбираются в предметной области?
это — да. но с другой стороны, если частные решения сыпятся при каждом чихе, то…
Т.е., если задача чуть сложнее, чем тривиальная, может лучше на день-два-неделю (в зависимости от объема задачи) дольше повозиться, но досконально разобраться.
нет нет. не так. надо искать достаточно общее решение, чтобы оно было понятно и просто «во всех ситуациях», чтобы под этими ситуациями не понималось. Ка в математике. Общее решение или более общая теория в итоге проще, чем частные.
Если прелоадер запускается на клиенте (хоть каким образом), или, вообще — анимированный гиф, то его работа никак не говорит о том, что сайт завис или нет.
Вот, действительно, пользоваться облачными сервисами, это либо урезанный функционал и не понятные перспективы, либо у конторы много денег.
Если нужны доработки «под себя», можно нанять разработчиков. А вот, как заказывать доработки во всяких облачных решениях?
По поводу интерфейса. У Редмайн есть ведь api. Можно же сделать/заказать отдельную доработку, заточку интерфейса для собственных нужд под конкретный сценарий использования. Сделать модное приложение. Как вариант.
Про то, что гибкие методы надо использовать в случае неопределенности предметной области, похоже, нигде не заострялось внимание. Всё говорилось, именно, про то, что заказчик может поменять требования. Но, нигде не заострялось внимание, что требования заказчик может поменять, потому что, сама предметная область «не изведана», а не потому что, например, «заказчик капризный».
А не получается ли тогда, что предметная область «не изведана», в случае, именно стартапов (исследовательских проектов), заказчиком которого являются сами разработчики (или, как вариант, инвестор)?
И, второй вопрос. Может, часто надо просто достаточно изследовать саму предметную область, прежде чем делать проект, и по ходу смотреть, «что там да как»? (понятно, что тут баланс скорее всего нужен)
наподобие того, как у нас попадаются заказчики, когда мы пытаемся получить с них требования, а они говорят, например, «ну нарисуйте нам хоть какую-нибудь форму, мы посмотрим, тогда и скажем, что нам надо». Т.е., абстрактное мышление стремиться к нулю, хотя речь идет об их повседневной деятельности.
так же и сами разработчики. пока не запрогарммируем сами хоть что-нибудь, вообще не сможем понять, что надо-то было => работаем итерациями. а на самом деле, может надо было просто, все же суметь разобраться в предметной области (конечно, заранее все не предусмотришь, и гибкость должна быть и в методологии, но не такая, что начинаем делать чебурашку, а в итоге переделываем в слона. просто сразу не поняли, что надо слона именно делать).
Как пример, пришлось мне полгода где-то поработать в стартапе, где вот прям скрам (не знаю, на сколько именно соответствовал процесс скраму). попал туда уже, когда им через пару месяцев надо было сдавать проект, а у них вопрос стоял, что все это надо переписать. Делался до этого проект, как понял, почти год. Хотя, на самом деле, ничего там инновационного, с точки зрения функционала не было. впечатление было, что просто не было у команды опыта. Эджайл тут никак не помог.
Может я ошибаюсь
Т.е., если задача чуть сложнее, чем тривиальная, может лучше на день-два-неделю (в зависимости от объема задачи) дольше повозиться, но досконально разобраться.