Концепция SharePoint хороша, но киевское представительство Microsoft в свое время так и не смогло предоставить нормальное решение для работы с документами. Очень не удобно было (правда было год назад или 2 - не помню), может уже отладили. Тяжелое решение (почти весь софт Майкрософта ставить надо)
Не видел удачного использования для документооборота. Никто из знакомых так и не смог с ней работать (да и дорого это ;). Наверное нужны более серьезные програмные решения.
По поводу документации - очень хорошо подходит SVN.
Обосную. Для начала давайте определимся что имеется в виду под "документацией". Условно разделю ее на 4 вида:
0. Создание общей документации проекта
1. Создание документации API вашего проекта
2. Создание хелпа для вашего проекта
3. Создание туториалов для вашего проекта
Поподробнее:
0. Вам хочется описать проект со всех сторон. Данная документация является по сути вспомогательной - для разработчиков. Но может понадобится возможность печати для заказчика. Берем ВиКи - контроль версий в кармане. (ВиКи - модуль TRAC'а)
1. Создание документации API является по сути задачей важной. Но первопричиной есть хороший стиль написания комментариев в исходном коде. Потом просто используется соответсвующая утилита java - javadoc, php - PHPDoctor например, и т.д. для других языков. Соответсвенно наша задача - правильно писать исходный код - в SVN
2. На данный момент хелпы в основном пишутся из HTML (в свн) или для hh (что тоже HTML)
3. Туториал. Тут каких-то особых предпочтений среди разработчиков нет. Одни пишут отдельные приложения, другие делают скриншоты, третие скринкасты. Скринкасты лично я делаю на флеше, а флеш что? - правильно ложится в SVN
Так что вопрос с документацией в разработке я думаю решен (про скрепочки говорить я думаю не надо)
Подробнее надеюсь опишу в отдельном топике при наличие дастаточного количества маны, хабры, и кармы ;)
>> 4. Нельзя ли подробнее о средствах коллективной разработки?
Очень полезная связка TRAC + SVN. Как только будет карма опубликую статью из своего опыта по коллективной разработке благо наметки есть :)
Спасибо автору за очень жизненный топик.
От себя добавлю несколько аспектов которые очень помогают мне по жизни:
0. Разрабатываем проекты:
- быстро
- качественно
- недорого
Выберите любых два пункта.
Шутки, шутками но заказчик должен понять что волшебники живут только в сказках. Чаще проще отказаться от проекта чем заработать себе плохую репутацию (отхабрят вас и кирдык).
1. Планирование, планирование, и еще раз планирование - на данный момент предпочитаю потратить половину времени проекта на планирование. Иногда даже доходит до абсурда когда хелп по продукту готов намного раньше самого продукта. Правильным, утвержденным у заказчика, планом вы избавляетесь от очень многих проблем (от креативности заказчика например)
2. Время разработки проекта = (предполагаемое время разработки) * 2.
3. Если работаете не над одним проектом то они имеют свойство начать аврализировать вас одновременно goto 1;
4. Пользуйтесь системами коллективной разработки. Много людей банально не могут организовать свое рабочее место (и себя за компанию)
5. Полностью согласен с 4 пунктом. Предлагаю так же усилить его. Информируйте заказчика на каждом этапе разработки. Покажите что Вы его уважаете. Вероятность ситуации "а вот это мне не нравится" за неделю до сдачи проекта уменьшается на 50%.
6. Заказчик должен вас уважать. Делайте все что угодно.
7. Не тряситесь над заказчиком. "А вот это вам нравится? Не нравится, сейчас переделаем...". У вас есть ПЛАН разработки утвержденный заказчиком. Это как на войне. Если планы хромают начинается героические штурмы. Если нет плана goto 1
8. Сделайте план.
9. Если возникает конфликт с заказчиком то это полностью ваша вина. Заказчику изначально конфилкты не нужны.
Попробовал перейти с 4.6.
Времени много не было но вот результаты:
- полностью прийдется переписывать тему (желательно с нуля)
- ждать плагинов - тех что есть категорически мало
+ Приятные нововведения (описано автором топика)
+ Работать стала визуально быстрее
Итог:
Работать можно будет при адаптации плагинов под новую версию - сейчас смысла особого не вижу
Не видел удачного использования для документооборота. Никто из знакомых так и не смог с ней работать (да и дорого это ;). Наверное нужны более серьезные програмные решения.
По поводу документации - очень хорошо подходит SVN.
Обосную. Для начала давайте определимся что имеется в виду под "документацией". Условно разделю ее на 4 вида:
0. Создание общей документации проекта
1. Создание документации API вашего проекта
2. Создание хелпа для вашего проекта
3. Создание туториалов для вашего проекта
Поподробнее:
0. Вам хочется описать проект со всех сторон. Данная документация является по сути вспомогательной - для разработчиков. Но может понадобится возможность печати для заказчика. Берем ВиКи - контроль версий в кармане. (ВиКи - модуль TRAC'а)
1. Создание документации API является по сути задачей важной. Но первопричиной есть хороший стиль написания комментариев в исходном коде. Потом просто используется соответсвующая утилита java - javadoc, php - PHPDoctor например, и т.д. для других языков. Соответсвенно наша задача - правильно писать исходный код - в SVN
2. На данный момент хелпы в основном пишутся из HTML (в свн) или для hh (что тоже HTML)
3. Туториал. Тут каких-то особых предпочтений среди разработчиков нет. Одни пишут отдельные приложения, другие делают скриншоты, третие скринкасты. Скринкасты лично я делаю на флеше, а флеш что? - правильно ложится в SVN
Так что вопрос с документацией в разработке я думаю решен (про скрепочки говорить я думаю не надо)
Подробнее надеюсь опишу в отдельном топике при наличие дастаточного количества маны, хабры, и кармы ;)
На пи многовато ;)
А вообще это 2
Очень полезная связка TRAC + SVN. Как только будет карма опубликую статью из своего опыта по коллективной разработке благо наметки есть :)
От себя добавлю несколько аспектов которые очень помогают мне по жизни:
0. Разрабатываем проекты:
- быстро
- качественно
- недорого
Выберите любых два пункта.
Шутки, шутками но заказчик должен понять что волшебники живут только в сказках. Чаще проще отказаться от проекта чем заработать себе плохую репутацию (отхабрят вас и кирдык).
1. Планирование, планирование, и еще раз планирование - на данный момент предпочитаю потратить половину времени проекта на планирование. Иногда даже доходит до абсурда когда хелп по продукту готов намного раньше самого продукта. Правильным, утвержденным у заказчика, планом вы избавляетесь от очень многих проблем (от креативности заказчика например)
2. Время разработки проекта = (предполагаемое время разработки) * 2.
3. Если работаете не над одним проектом то они имеют свойство начать аврализировать вас одновременно goto 1;
4. Пользуйтесь системами коллективной разработки. Много людей банально не могут организовать свое рабочее место (и себя за компанию)
5. Полностью согласен с 4 пунктом. Предлагаю так же усилить его. Информируйте заказчика на каждом этапе разработки. Покажите что Вы его уважаете. Вероятность ситуации "а вот это мне не нравится" за неделю до сдачи проекта уменьшается на 50%.
6. Заказчик должен вас уважать. Делайте все что угодно.
7. Не тряситесь над заказчиком. "А вот это вам нравится? Не нравится, сейчас переделаем...". У вас есть ПЛАН разработки утвержденный заказчиком. Это как на войне. Если планы хромают начинается героические штурмы. Если нет плана goto 1
8. Сделайте план.
9. Если возникает конфликт с заказчиком то это полностью ваша вина. Заказчику изначально конфилкты не нужны.
http://www.masteringdrupal.com/screencast/new-features-drupal-6
Времени много не было но вот результаты:
- полностью прийдется переписывать тему (желательно с нуля)
- ждать плагинов - тех что есть категорически мало
+ Приятные нововведения (описано автором топика)
+ Работать стала визуально быстрее
Итог:
Работать можно будет при адаптации плагинов под новую версию - сейчас смысла особого не вижу