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

StasFomin в 19:26, 9 августа 2011

2011-08-09T19:26:56Z

Внесённые изменения

VitaliyFilippov в 16:25, 24 мая 2011

2011-05-24T16:25:01Z

VitaliyFilippov в 08:34, 28 апреля 2011

2011-04-28T08:34:33Z

VitaliyFilippov в 08:34, 28 апреля 2011

2011-04-28T08:34:11Z

VitaliyFilippov в 08:31, 28 апреля 2011

2011-04-28T08:31:33Z

Новая страница

* Докладчик: [[Участник:VitaliyFilippov|Виталий Филиппов]] [vitalif * mail % ru].
* Заявка подана на [http://devconf.ru/ DevConf-2011].

== Аннотация ==

В докладе мы хотим кратко рассказать историю развития Open-Source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. У нас она начиналась с идей — (1) '''Open-Source''', (2) '''Wiki + баг-трекер + система контроля версий''', (3) '''расширяемость => MediaWiki'''. Кроме того, мы наконец-то выполнили обещание выйти в Open-Source и теперь существует проект '''[http://wiki.4intra.net/ 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 и теперь вы можете сами попробовать эти инструменты, причём, со всеми нашими доработками.

[[Файл:Информационные_объекты_в_разработке_ПО.jpg|thumb|300px|right]] '''Идея № 2 — «Вики-Трекер-VCS»''', которая родилась у нас ещё N (≈ '''7''') лет назад, а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы [http://code.google.com/ Google Code] или [https://github.com GitHub]. Идея заключается в том, что почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:
* '''Требования''' — то, что нужно сделать, то есть, все виды постановок задач
* '''Артефакты''' — всё то, что является результатом разработки
* '''Знания''' — то, благодаря чему разработка становится возможна
В этой троице каждому из типов соответствует своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, баг-трекер для требований. Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться покрывать большую часть процессов.

<blockquote>Хороший пример — расширения MediaWiki (скажем, [http://en.wikipedia.org/wiki/User:Cacycle/wikEd WikEd]), у которых Wiki зачастую служит и системой контроля версий (код кладётся прямо на страницу), и баг-трекером (в обсуждении).</blockquote>

Итак, допустим, мы определились с идеями — осталось лишь подобрать правильные системы и связать их воедино.
* 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 в хранении сильно структурированных данных (а не плоского текста).

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

{{replicate-from-custiswiki-to-lib}}

@@ Строка 6: / Строка 6: @@
 В докладе мы хотим кратко рассказать историю развития Open-Source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. У нас она начиналась с идей — (1) '''Open-Source''', (2) '''Wiki + баг-трекер + система контроля версий''', (3) '''расширяемость => MediaWiki'''. Кроме того, мы наконец-то выполнили обещание выйти в Open-Source и теперь существует проект <span style="font-size: 150%">'''[http://wiki.4intra.net/ 4intra.net]'''</span> («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.
-Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как систему '''форумов и блогов''', '''презентаций''', '''опросов и экзаменов''', личный «кэш» '''сетевых закладок''' и так далее. Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».
+Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как систему информационных потоков (читай — '''форумов и блогов'''), '''презентаций''', '''опросов и экзаменов''', личный «кэш» '''сетевых закладок''' и так далее. Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».
 О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.

@@ Строка 1: / Строка 1: @@
 * Докладчик: [[Участник:VitaliyFilippov|Виталий Филиппов]] [vitalif * mail % ru].
-* Заявка подана на [http://devconf.ru/ DevConf-2011].
+* Доклад принят на [http://devconf.ru/ DevConf-2011].
 == Аннотация ==

← Предыдущая	Версия 08:34, 28 апреля 2011
(нет различий)