Совместная разработка проекта. - страница 6

 
barabashkakvn:
Всё это оторвано от реальности. Нужны простые способы и инструменты.
я в курсе ) просто попалось на глаза по этому вопросу, решил выложить...
 
Karputov Vladimir:
Если разрабатывать совместный проект - продукт MQL5, как лучше организовать обмен информацией? Например начальное обсуждение - построение техзадания. Можно для этого варианта использовать редактирование документа с правами доступа на редактирование для всех участников проекта?

Сейчас делаю сайт под совместные проекты с трекером задач.

Суть тривиальна. Пусть есть некто имеющий права менеджера проектов, он берёт проект и подвергает декомпозиции, т.е. разбивает его на части. Эти самые части доступны разработчикам.

Например, есть готовое ТЗ и бюджет, необходимо сделать по нему советника. Выполняем декомпозицию:

  1. Код сигналов тех. анализа для входа в рынок
  2. Код выхода из рынка
  3. Код сопровождения открытых позиций
  4. Код управления капиталом и риском
  5. Общий код советника

Сразу получаем четыре задания, которые можно раздать четверым разработчикам, распределив между ними часть бюджета (всё распылять сразу нельзя, т.к. в процессе разработки могут появиться непредвиденные обстоятельства, поэтому часть бюджета проекта необходимо держать в НЗ), чтобы всё выполнялось параллельно. Потом всё это дело можно сшить в один проект, объединив с пятой частью.

Трекер задач позволяет:

  1. Проект в виде отдельной веб-страницы с возможностью просмотра и редактирования только для менеджера проекта. На странице есть необходимые поля под полное ТЗ, возможность загружать и смотреть скриншоты, а также возможность загружать файлы. Ну и комментарии, поскольку по ходу пьесы появляются новые подробности и их надо где-то записывать.
  2. Отдельные страницы для каждой из задач проекта, с возможностью доступа к ним только тех разработчиков, которых менеджер проекта допустит к этому делу. Допущенные разработчики могут оставлять свои комментарии и прикреплять к ним файлы выполненных работ.
  3. Таблицы с фильтрацией и сортировкой по полям, например, по дате, приоритету статусу готовности, как для проектов, так и для задач, чтобы видеть и выявлять наиболее проблемные места.

Для каждой страницы задачи, помимо основных описаний под ТЗ, также имеются дополнительные данные: срок завершения, бюджет, статус (этап готовности), приоритет, тип.

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

 
Yury Reshetov:


Давайте я поэкспериментирую.
 
Karputov Vladimir:
Давайте я поэкспериментирую.
Написал в личку. Там на сайте достаточно всего лишь зарегистрироваться, чтобы создавать проекты и задачи. Проекты по умолчанию закрыты от посторонних, а задачи наоборот, открыты. Впрочем пользователи могут сами настраивать права доступа для своих проектов и задач без вмешательства администрации сайта.
 
Yury Reshetov:

Сейчас делаю сайт под совместные проекты с трекером задач.

Суть тривиальна. Пусть есть некто имеющий права менеджера проектов, он берёт проект и подвергает декомпозиции, т.е. разбивает его на части. Эти самые части доступны разработчикам.

Например, есть готовое ТЗ и бюджет, необходимо сделать по нему советника. Выполняем декомпозицию:

  1. Код сигналов тех. анализа для входа в рынок
  2. Код выхода из рынка
  3. Код сопровождения открытых позиций
  4. Код управления капиталом и риском
  5. Общий код советника

Сразу получаем четыре задания, которые можно раздать четверым разработчикам, распределив между ними часть бюджета (всё распылять сразу нельзя, т.к. в процессе разработки могут появиться непредвиденные обстоятельства, поэтому часть бюджета проекта необходимо держать в НЗ), чтобы всё выполнялось параллельно. Потом всё это дело можно сшить в один проект, объединив с пятой частью.

Трекер задач позволяет:

  1. Проект в виде отдельной веб-страницы с возможностью просмотра и редактирования только для менеджера проекта. На странице есть необходимые поля под полное ТЗ, возможность загружать и смотреть скриншоты, а также возможность загружать файлы. Ну и комментарии, поскольку по ходу пьесы появляются новые подробности и их надо где-то записывать.
  2. Отдельные страницы для каждой из задач проекта, с возможностью доступа к ним только тех разработчиков, которых менеджер проекта допустит к этому делу. Допущенные разработчики могут оставлять свои комментарии и прикреплять к ним файлы выполненных работ.
  3. Таблицы с фильтрацией и сортировкой по полям, например, по дате, приоритету статусу готовности, как для проектов, так и для задач, чтобы видеть и выявлять наиболее проблемные места.

Для каждой страницы задачи, помимо основных описаний под ТЗ, также имеются дополнительные данные: срок завершения, бюджет, статус (этап готовности), приоритет, тип.

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

Ничё у тебя Юра не получиться. 

Нет, с сайтом получиться, а вот с унификацией нет.

Во первых "Код сигналов тех. анализа для входа в рынок" не плохо бы расширить ещё и кодом сигналов теханализа по выходу из рынка.

Во вторых всё вышеперечисленное сделает любой босяк. А куда всунуть разработку архитектуры, постановку задачи, формализацию задачи?

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

 
Nikolay Demko:

Ничё у тебя Юра не получиться. 

Нет, с сайтом получиться, а вот с унификацией нет.

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

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

Однако, Николай, вы ошиблись в расчётах. Холивара не будет.


Nikolay Demko:

Во первых "Код сигналов тех. анализа для входа в рынок" не плохо бы расширить ещё и кодом сигналов теханализа по выходу из рынка.ами

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

  1. Код сигналов тех. анализа для входа в рынок
  2. Код выхода из рынка
  3. Код сопровождения открытых позиций
  4. Код управления капиталом и риском
  5. Общий код советника

Nikolay Demko:


Во вторых всё вышеперечисленное сделает любой босяк. А куда всунуть разработку архитектуры, постановку задачи, формализацию задачи?

Ну это тоже понятно. Чтобы обратить на себя внимание, необходимо принизить потенциального оппонента, сравнив его например, с босяком. Но что-то, несмотря на все Ваши заверения о том, что якобы даже босякам такая задача по плечу, уже шесть страниц идёт пустопорожнее обсуждение и никто даже не приступил к реализации. А всё вовсе не потому что босяки могут сделать, а потому что значительная часть обсуждающих даже не пыталась искать ответы на вопросы, а всего лишь вставляли свои пятикопечные 500 бесполезных советов. Однако велосипед изобретать не нужно, поскольку автоматизация через трекеры задач уже давно изобретена. Другой компот, как грамотно настроить этот самый трекер, чтобы он не стал причиной для излишней бюрократической возни, а наоборот способствовал решению проблем.

Nikolay Demko:


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

Ну дык. Ясен пень. Ведь заказчик - это не разработчик. А соответственно никакого опыта в разработке не имеет. Поэтому он даже понятия не имеет, что конкретно нужно уточнить, чтобы получить торговую систему, пригодную для составления алгоритма. Итак он пришел и притащил идею. И тут мы ему поясняем, что советник состоит из пяти частей:

  1. Код сигналов тех. анализа для входа в рынок
  2. Код выхода из рынка
  3. Код сопровождения открытых позиций
  4. Код управления капиталом и риском
  5. Общий код советника

И если он чётко не определиться с четырьмя первыми частями, то ТЗ для создания советника согласовать невозможно. Поэтому прямо по пунктам, начинаем из него либо вытягивать информацию, либо предлагать подходящие варианты. И когда мы чётко и однозначно получим ответ, чего хочет заказчик по четырём первым пунктам, то сможем составить и согласовать с ним ТЗ. Если хоть один из четырёх пунктов останется неоднозначным, то у заказчика появится повод заявить в арбитраж, что разработчик его нагло надул и сделал то, чего он не заказывал, поскольку в ТЗ этого не указано. И будет прав.

С этим разобрались, а посему возвращаться к данному вопросу нет смысла.

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

Чтобы организовать совместную разработку, необходимо придерживаться принципа: Разделяй и Властвуй

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

Надеюсь, ясно пояснил или у кого ещё есть вопросы по теме, а не гнилые отмазки?

 

Когда я обзывал (придумывал название) эту тему то под словом "совместная" прежде всего имелась ввиду коллективная разработка проекта. Согласен, что без разделения техзадания на отдельные куски не обойтись. Это даст возможность:

  1. Распараллелиться при выполнении задания;
  2. Уменьшить сложность каждого отдельного куска.

А сайт протестирую.  

 
Yury Reshetov:

Сейчас делаю сайт под совместные проекты с трекером задач...

А можно ссылку на сайт?

 
Event:

А можно ссылку на сайт?

Отправил в личку
 

как-раз ща основательно изучаю это направление, вспомнил про ветку на этом форуме