|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Эволюция Wiki-Way командной разработкиМатериал из CustisWikiВерсия от 22:26, 9 августа 2011; StasFomin (обсуждение | вклад) Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Короткая ссылка: WikiWay-DevConf-2011
АннотацияВ докладе мы хотим кратко рассказать историю развития Open-Source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. У нас она начиналась с идей — (1) Open-Source, (2) Wiki + баг-трекер + система контроля версий, (3) расширяемость => MediaWiki. Кроме того, мы наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками. Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как систему информационных потоков (читай — форумов и блогов), презентаций, опросов и экзаменов, личный «кэш» сетевых закладок и так далее. Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах». О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад. Итак, теперь об идеях — Идея № 1: Open-Source. Начиналось всё с того, что из доступных вариантов —
— из доступных вариантов мы выбрали OpenSource, и теперь — Good News, Everyone! — можем рассказать о наборе свободных систем, которые успешно используем в компании. Более того, это не просто слова — «Talk is cheap. Show me the code.» (c) Linus Torvalds — мы наконец-то выполнили своё обещание о выходе в Open-Source и теперь вы можете сами попробовать эти инструменты, причём, со всеми нашими доработками. Идея № 2 — «Вики-Трекер-VCS», которая родилась у нас ещё N (≈ 7) лет назад, а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы Google Code или GitHub. Идея заключается в том, что почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:
В этой троице каждому из типов соответствует своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, баг-трекер для требований. Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться покрывать большую часть процессов. Хороший пример — расширения MediaWiki (скажем, WikEd), у которых Wiki зачастую служит и системой контроля версий (код кладётся прямо на страницу), и баг-трекером (в обсуждении). Итак, допустим, мы определились с идеями — осталось лишь подобрать правильные системы и связать их воедино.
Третья идея — использовать мощную концепцию MediaWiki — страницы, отсутствие суррогатных ID, служебные страницы для специального функционала, мини-язык парсера со включениями шаблонов, функциями парсера, вставкой изображений и других медиаданных и так далее, и хорошую поддержку для расширения всего этого. Куда двигаться дальшеВ сторону эволюционных (не революционных!) методов создания «правильной багзиллы», свободной ото всех недостатков оригинальной:
В связи с теперешней популярностью SCRUM’а и Agile-разработки в целом — в сторону добавления механизмов интеграции с Agile — например, построения графиков Burndown, карточек. В сторону выявления практик использования Wiki как системы тестирования и упрощения этого. В сторону Semantic MediaWiki, а точнее, «вики с атрибутами страниц» — то есть, ликвидировать слабость MediaWiki в хранении сильно структурированных данных (а не плоского текста). В сторону привлечения сообщества к проекту :)
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |