Эволюция Wiki-Way командной разработки

Короткая ссылка: WikiWay-DevConf-2011

Ссылки сюда (2) →

Подстраницы (1) →

• Докладчик: Виталий Филиппов [vitalif * mail % ru].
• Заявка подана на 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. Начиналось всё с того, что из доступных вариантов —

«Ящик Вендора»

☹Платный, сильно связанный, закрытый, производимый заданным вендором инструментарий.
Почти всё это кто-то может сформулировать и как плюсы: «платный => наверное, качественный?!», «сильно связанный => удобно, всё интегрированное?!», «закрытый => кому нужно в нём копаться?!», «производимый вендором => хорошая поддержка?!». Однако мы считаем, что всё это — минусы. Стоимость лицензий может превышать стоимость неплохого оборудования. Связанность убивает гибкость — шаг в сторону от вендорских инструментов, и работать уже неудобно. Закрытость не даёт исправить недостатки или неудобства, которые наверняка вскроются. Раз производит всё это вендор, вы должны слепо доверять его выбору инструментов.

«Велосипед»

☹Полностью внутренние инструменты, созданные своими руками.
Сейчас, во времена LAMP, node.js и прочих языков и фреймворков быстрой веб-разработки, написать новую веб-систему не составляет никакого труда. Однако это грозит вам никому не нужным «велосипедом», жёстко завязанным на внутренние процессы компании, который со временем может стать (и наверняка станет) очень тяжело поддерживать.

OpenSource

☺Поддерживаемые большими внешними сообществами, свободные mainstream-инструменты, «прирученные» и «допиленные» для внутреннего использования.
Единственная проблема здесь — свободных систем стало много и нужно сделать правильный выбор. Но — после этого вы совершенно бесплатно получаете мощнейшие инструменты, можете сами решать, сколько вы хотите приложить усилий к «допиливанию», точно знаете, что выбранные инструменты «не умрут» завтра, и имеете полную свободу всех действий, да ещё и можете сами сделать что-то хорошее!.

— из доступных вариантов мы выбрали 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 зачастую служит и системой контроля версий (код кладётся прямо на страницу), и баг-трекером (в обсуждении).

Итак, допустим, мы определились с идеями — осталось лишь подобрать правильные системы и связать их воедино.

• VCS: Subversion — на данный момент вершина эволюции централизованных VCS. Также у нас до сих пор живёт CVS. + ViewVC — веб-интерфейс и поиск к ним.
• Wiki: MediaWiki — самая мощная, расширяемая и, наверное, самая широко используемая Wiki-система. Есть более 1700 расширений к ней. Другие популярные Wiki сейчас — это в первую очередь MoinMoin и DokuWiki. Важное отличие MediaWiki от многих других систем — достаточно выверенная концептуальная архитектура.
• Трекер: Bugzilla — широко распространена, хорошо поддерживаема и весьма мощна. Из минусов — немного заточена под баг-трекер Mozilla, legacy-продукт, инертные разработчики, не очень с юзабилити. Вообще, правильно выбрать трекер сложнее всего — либо это монстры (Bugzilla, Jira), либо слабы для интранета (Trac, Mantis, Roundup)… Поэтому здесь мы выбрали mainstream — то, что используется давно и довольно успешно.

Третья идея — использовать мощную концепцию MediaWiki — страницы, отсутствие суррогатных ID, служебные страницы для специального функционала, мини-язык парсера со включениями шаблонов, функциями парсера, вставкой изображений и других медиаданных и так далее, и хорошую поддержку для расширения всего этого.

Куда двигаться дальше

В сторону эволюционных (не революционных!) методов создания «правильной багзиллы», свободной ото всех недостатков оригинальной:

• Юзабилити: показывать историю изменений в комментариях, добавить ленты обновлений, форум-функциональность, Grid, теги
• Трепанация внутренностей: Переделать JS-часть (убрать YAHOO UI), переделать систему прав, прокачать объектный движок, выкинуть CGI.pm, шаблонизатор

В связи с теперешней популярностью SCRUM’а и Agile-разработки в целом — в сторону добавления механизмов интеграции с Agile — например, построения графиков Burndown, карточек.

В сторону выявления практик использования Wiki как системы тестирования и упрощения этого.

В сторону Semantic MediaWiki, а точнее, «вики с атрибутами страниц» — то есть, ликвидировать слабость MediaWiki в хранении сильно структурированных данных (а не плоского текста).

В сторону привлечения сообщества к проекту :)

---

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Эволюция Wiki-Way командной разработки»