Совместная разработка проекта. - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Всё это оторвано от реальности. Нужны простые способы и инструменты.
Если разрабатывать совместный проект - продукт MQL5, как лучше организовать обмен информацией? Например начальное обсуждение - построение техзадания. Можно для этого варианта использовать редактирование документа с правами доступа на редактирование для всех участников проекта?
Сейчас делаю сайт под совместные проекты с трекером задач.
Суть тривиальна. Пусть есть некто имеющий права менеджера проектов, он берёт проект и подвергает декомпозиции, т.е. разбивает его на части. Эти самые части доступны разработчикам.
Например, есть готовое ТЗ и бюджет, необходимо сделать по нему советника. Выполняем декомпозицию:
Сразу получаем четыре задания, которые можно раздать четверым разработчикам, распределив между ними часть бюджета (всё распылять сразу нельзя, т.к. в процессе разработки могут появиться непредвиденные обстоятельства, поэтому часть бюджета проекта необходимо держать в НЗ), чтобы всё выполнялось параллельно. Потом всё это дело можно сшить в один проект, объединив с пятой частью.
Трекер задач позволяет:
Для каждой страницы задачи, помимо основных описаний под ТЗ, также имеются дополнительные данные: срок завершения, бюджет, статус (этап готовности), приоритет, тип.
Поскольку сайт пока ещё не запущен в рабочую фазу, то могу всем желающим через личку дать доступ к аккаунтам менеджеров проектов, чтобы посмотреть, заценить, а может быть и что-то дельное посоветовать.
Давайте я поэкспериментирую.
Сейчас делаю сайт под совместные проекты с трекером задач.
Суть тривиальна. Пусть есть некто имеющий права менеджера проектов, он берёт проект и подвергает декомпозиции, т.е. разбивает его на части. Эти самые части доступны разработчикам.
Например, есть готовое ТЗ и бюджет, необходимо сделать по нему советника. Выполняем декомпозицию:
Сразу получаем четыре задания, которые можно раздать четверым разработчикам, распределив между ними часть бюджета (всё распылять сразу нельзя, т.к. в процессе разработки могут появиться непредвиденные обстоятельства, поэтому часть бюджета проекта необходимо держать в НЗ), чтобы всё выполнялось параллельно. Потом всё это дело можно сшить в один проект, объединив с пятой частью.
Трекер задач позволяет:
Для каждой страницы задачи, помимо основных описаний под ТЗ, также имеются дополнительные данные: срок завершения, бюджет, статус (этап готовности), приоритет, тип.
Поскольку сайт пока ещё не запущен в рабочую фазу, то могу всем желающим через личку дать доступ к аккаунтам менеджеров проектов, чтобы посмотреть, заценить, а может быть и что-то дельное посоветовать.
Ничё у тебя Юра не получиться.
Нет, с сайтом получиться, а вот с унификацией нет.
Во первых "Код сигналов тех. анализа для входа в рынок" не плохо бы расширить ещё и кодом сигналов теханализа по выходу из рынка.
Во вторых всё вышеперечисленное сделает любой босяк. А куда всунуть разработку архитектуры, постановку задачи, формализацию задачи?
Ведь заказчик обычно приходит с идеей, которую в лучшем случае может внятно описать, в худшем суть из него нужно вытягивать клещами.
Ничё у тебя Юра не получиться.
Нет, с сайтом получиться, а вот с унификацией нет.
Я конечно же понимаю, что здесь на форуме масса критиканов, которые пытаются выпендриться тем, что уговаривают наиболее креативных посетителей от реализации их идей. Суть ведь ясна: дефицит общения, а когда на человека не обращают внимание (игнорируют), то это самое худшее наказание. В таком случае он зачастую становится на колени и просит, чтобы его лучше побили, но считали своим. Впрочем, многие, чтобы на них обратили внимание, делают всё так чтобы их побили или хотя бы поругали.
В данном случае мы имеем аналогичную ситуацию. Пришёл Николай, вставил свои пять копеек, чтобы оказаться в центре холивара и на него тем самым обратили внимание.
Однако, Николай, вы ошиблись в расчётах. Холивара не будет.
Во первых "Код сигналов тех. анализа для входа в рынок" не плохо бы расширить ещё и кодом сигналов теханализа по выходу из рынка.ами.
Поскольку всякий критикан не пытается разобраться в вопросе, т.е. не слышит собеседника, а сразу пытается воткнуть свои пять копеек, то он зачастую опростоволосивается. Для особо внимательных ещё раз повторяю пять пунктов и выделяю, то что критикуется:
Nikolay Demko:
Во вторых всё вышеперечисленное сделает любой босяк. А куда всунуть разработку архитектуры, постановку задачи, формализацию задачи?Ну это тоже понятно. Чтобы обратить на себя внимание, необходимо принизить потенциального оппонента, сравнив его например, с босяком. Но что-то, несмотря на все Ваши заверения о том, что якобы даже босякам такая задача по плечу, уже шесть страниц идёт пустопорожнее обсуждение и никто даже не приступил к реализации. А всё вовсе не потому что босяки могут сделать, а потому что значительная часть обсуждающих даже не пыталась искать ответы на вопросы, а всего лишь вставляли свои пятикопечные 500 бесполезных советов. Однако велосипед изобретать не нужно, поскольку автоматизация через трекеры задач уже давно изобретена. Другой компот, как грамотно настроить этот самый трекер, чтобы он не стал причиной для излишней бюрократической возни, а наоборот способствовал решению проблем.
Nikolay Demko:
Ведь заказчик обычно приходит с идеей, которую в лучшем случае может внятно описать, в худшем суть из него нужно вытягивать клещами.Ну дык. Ясен пень. Ведь заказчик - это не разработчик. А соответственно никакого опыта в разработке не имеет. Поэтому он даже понятия не имеет, что конкретно нужно уточнить, чтобы получить торговую систему, пригодную для составления алгоритма. Итак он пришел и притащил идею. И тут мы ему поясняем, что советник состоит из пяти частей:
И если он чётко не определиться с четырьмя первыми частями, то ТЗ для создания советника согласовать невозможно. Поэтому прямо по пунктам, начинаем из него либо вытягивать информацию, либо предлагать подходящие варианты. И когда мы чётко и однозначно получим ответ, чего хочет заказчик по четырём первым пунктам, то сможем составить и согласовать с ним ТЗ. Если хоть один из четырёх пунктов останется неоднозначным, то у заказчика появится повод заявить в арбитраж, что разработчик его нагло надул и сделал то, чего он не заказывал, поскольку в ТЗ этого не указано. И будет прав.
С этим разобрались, а посему возвращаться к данному вопросу нет смысла.
Теперь перейдём непосредственно к основной теме топика, а именно к совместной разработке. Тут возникает терминологическая путаница. Поскольку в русском языке термин совместная, не совпадает с успешной практикой прожект менеджмента. Ведь на самом деле, чтобы добиться результата, разработка должна быть раздельная. Т.е. сначала общую задачу проекта подвергают декомпозиции и делят на мелкие части, для каждой из которых субТЗ примитивно и предельно ясно. Потом эти части распределяются по компетенции между разработчиками. В конечном итоге части сшиваются в одно целое. И получаем некий продукт на выходе.
Чтобы организовать совместную разработку, необходимо придерживаться принципа: Разделяй и Властвуй
И тут вся тонкость заключается в том, как правильно разделить проект и как обеспечить коммуникации между разработчиками и менеджером проекта, чтобы не получить лебедя, рака и щуки или квартета. Для этого и предназначены трекеры задач, которые позволяют следить за ситуацией по частям и обеспечивать коммуникации тоже раздельно. Т.е. если один разработчик выполняет некую часть проекта, то коммуникации между ним и менеджером проекта происходят также раздельно, на специально выделенной для этого веб странице, дабы не смешать это всё в общую кучу, где возникнет шум и суета. Более того, такая вебстраница содержит и всю необходимую информацию, только по данному конкретному участку проекта. А поскольку память у людей коротка, то менеджер проекта перейдя с одного участка проекта на другой может быстро сориентироваться и вникнуть в суть происходящее. И только когда он сможет получить нужную информацию, не морща лба в попытках вспомнить о чём в прошлый раз шла речь, когда обсуждались проблемы этого участка проекта. А получив необходимую информацию, он сможет принять адекватное решение.
Надеюсь, ясно пояснил или у кого ещё есть вопросы по теме, а не гнилые отмазки?
Когда я обзывал (придумывал название) эту тему то под словом "совместная" прежде всего имелась ввиду коллективная разработка проекта. Согласен, что без разделения техзадания на отдельные куски не обойтись. Это даст возможность:
А сайт протестирую.
Сейчас делаю сайт под совместные проекты с трекером задач...
А можно ссылку на сайт?
А можно ссылку на сайт?
как-раз ща основательно изучаю это направление, вспомнил про ветку на этом форуме