Я ведь сравниваю и рассуждаю на основе изложенного материала и опыта использования subversion. Да, переключение между ветвями и merge не такие гладкие, как хотелось бы, если в git что-то сделано гораздо лучше, хотелось бы знать, как и что именно.
Зачем нужна статья, которая не раскрывает преимуществ?
Я позволю себе сравнить с subversion, с моей точки зрения
2. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.
Ну так и в subversion все так же
3. git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке..
Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.
Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.
4. Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно.
Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.
5. Удобные частичные комиты
Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью git add. При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.
В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.
6. Возможность припрятать изменения.
Пока не понял, зачем это нужно.
Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.
Сопротивление админов...
Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.
Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
Интересно, на хабре тоже будет тенденция с целью распространения контента прикручивать к нему все более и более откровенные фото моделей со все более длинными ногами :)
Потому, что Scrum (как и гибкая разработка (agile), да и бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.
Смотря что называть идеологией SCRUM. Описание методологии SCRUM весьма и весьма компактно, саму по себе методологию считаю очень эффективной, думаю, из-за этого — простота и эффективность — она так популярна.
Популярность легко переходит в модность, в силу этого очень многие люди стремятся высказаться на темы вокруг SCRUM, слово SCRUM в заголовке сильно повышает популярность темы в определенных кругах, круги волей-неволей читают, комментируют, и происходит еще один спринт по переливанию из пустого в порожнее :). Все довольны, все высказались. А вот платит за эти разговоры заказчик :) Тут практически без вариантов.
>Особенно если цель поставлена чётко и недвусмысленно — тупо удовлетворить заказчика не занимаясь при этом никакой самодеятельностью.
А какая интересно еще бывает цель? Если заказчик доволен, то и исполнителю воздается соответственно, корреляция довольно хорошая. Вот если исполнитель начинает помимо тупого удовлетворения заказчика еще и интеллектуально удовлетворять себя, тут возможны нюансы :)
На мой взгляд, ситуация несколько перекликается с тестом Тьюринга по ИИ, где интеллект определяется через другой интеллект, по сути — крайне субъективно, ввиду наличия отсутствия объективных критериев.
Так и здесь — для оценки работника нужен другой работник, иногда называемый начальником :)
Хороший работник виден начальнику и так, невооруженным статистикой глазом. Ведь зачастую крайне важны такие вещи как мотивация, коммуникабельность, способность позитивно вести себя в конфликтных ситуациях, энтузиазм, в конце концов, а как это все объективно измерить?
Иными словами, хочешь узнать, кто лучший в конкретном подразделении — спроси у начальника подразделения.
На мой взгляд, самая большая проблема тут — Прогнозируемая производительность команды
Чтобы ее получить, необходимо выполнить несколько итераций. Хенрик Книберг в Scrum и XP: заметки с передовой рекомендует в качестве продолжительности спринта 3 недели. Т.е. пилотный проект, получается, будет длиться несколько месяцев. Хорошо, когда это лишь малая часть от общего бюджета, т.е. проект — весьма крупный.
С трудом представляю, как можно оценить производительность за одну итерацию — народ только-только начнет «въезжать» в проект.
Ну т.е. самая крупная проблема проектов с фиксированой ценой по сути осталась за рамками статьи. Ну что ж, зато еще раз прочитали изложение методологии SCRUM :)
>Вот, например, по этому скриншоту: если у меня еженедельные milestones, то очень скоро прийдется долго прокручивать вниз, чтобы открыть, скажем, поддерево проекта, который идет в списке следующим.
Вообще, текущие milestones заносятся в закладки и выбираются из закладок, в дерево для текущей работы с milestone лазить не нужно. Туда в основном нужно заходить чтобы создавать новые элементы. У нас, кстати, можно создавать вложенные milestone. Пустячок, а приятно ;)
Ах, как это верно! Действительно, была такая программерская мысль, c нее и началось все. Однако, наряду с минусами есть и плюсы. Мы ведем постоянную борьбу, чтобы плюсы перевесили минусы.
>Вообще интерфейс должен учитывать текущий контекст: если человек в данный момент работает над проектом A, то все остальное ему не нужно
Стремимся к этому, конечно. Но не все сразу получается.
>надо садиться и писать пользовательские сценарии, представляя себя пользователем и анализируя его потребности с точки зрения того, какую задачу он в данном сценарии решает
Все верно. Заказчик подключен к backlog и видит у себя в Мои проекты плоский список
Разработчик, помимо плоского списка, работает с деревом требований к системе. Если декомпозиция требований заказчика не нужна, тогда и дерево, понятно дело, лишнее, можно использовать redmine. А если нужна?
Зачем нужна статья, которая не раскрывает преимуществ?
Ну так и в subversion все так же
Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.
Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.
Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.
В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.
Пока не понял, зачем это нужно.
Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.
Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.
Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
Sony a55
Может, кто-то развлекается таким образом. Вообще мне неясен смысл реагировать на спам способом сильно отличным от его удаления.
Такое противопоставление наводит на мысль, что движок хабра относится к категории хард :)
>Важно доводить решение задач до конца, т.к. выполненной можно считать только принятую заказчиком задачу
К примеру
Из Scrum и XP: заметки с передовой:
Популярность легко переходит в модность, в силу этого очень многие люди стремятся высказаться на темы вокруг SCRUM, слово SCRUM в заголовке сильно повышает популярность темы в определенных кругах, круги волей-неволей читают, комментируют, и происходит еще один спринт по переливанию из пустого в порожнее :). Все довольны, все высказались. А вот платит за эти разговоры заказчик :) Тут практически без вариантов.
>Нам понадобится (кроме головы и рук) только работающий web-сервер с поддержкой cgi-bin, к которому у нас есть доступ по FTP
FTP — это опечатка ( м.б. HTTP? ), или же я чего-то не понял?
> Фактически, нужны только Perl и программа gs, которые есть практически везде.
Ну, perl я у себя на рабочей Windows XP нашел :), а с gs вот так вот с ходу проблема. Никогда не задавался целью, правда, эту gs как-то использовать.
А какая интересно еще бывает цель? Если заказчик доволен, то и исполнителю воздается соответственно, корреляция довольно хорошая. Вот если исполнитель начинает помимо тупого удовлетворения заказчика еще и интеллектуально удовлетворять себя, тут возможны нюансы :)
Хотя желание организовать что-то по типу переписки Энгельса с Каутским тоже понять можно :)
Так и здесь — для оценки работника нужен другой работник, иногда называемый начальником :)
Хороший работник виден начальнику и так, невооруженным статистикой глазом. Ведь зачастую крайне важны такие вещи как мотивация, коммуникабельность, способность позитивно вести себя в конфликтных ситуациях, энтузиазм, в конце концов, а как это все объективно измерить?
Иными словами, хочешь узнать, кто лучший в конкретном подразделении — спроси у начальника подразделения.
По виду — латынь :) Сходил в google translate. Так и есть: «Перевод этой языковой пары (латынь > русский) пока не поддерживается»
Шифруетесь? :)
По объему информации, сложности освоения, на мой взгляд, разница как бы не в несколько порядков будет, между языком и его рабочим окружением…
Чтобы ее получить, необходимо выполнить несколько итераций. Хенрик Книберг в Scrum и XP: заметки с передовой рекомендует в качестве продолжительности спринта 3 недели. Т.е. пилотный проект, получается, будет длиться несколько месяцев. Хорошо, когда это лишь малая часть от общего бюджета, т.е. проект — весьма крупный.
С трудом представляю, как можно оценить производительность за одну итерацию — народ только-только начнет «въезжать» в проект.
Ну т.е. самая крупная проблема проектов с фиксированой ценой по сути осталась за рамками статьи. Ну что ж, зато еще раз прочитали изложение методологии SCRUM :)
Вообще, текущие milestones заносятся в закладки и выбираются из закладок, в дерево для текущей работы с milestone лазить не нужно. Туда в основном нужно заходить чтобы создавать новые элементы. У нас, кстати, можно создавать вложенные milestone. Пустячок, а приятно ;)
> логика чисто программерская, программисту показалось, что было бы круто объединить все элементы в дерево (из серии «это ж можно будет абстрактный класс заюзать!» ©)
Ах, как это верно! Действительно, была такая программерская мысль, c нее и началось все. Однако, наряду с минусами есть и плюсы. Мы ведем постоянную борьбу, чтобы плюсы перевесили минусы.
>Вообще интерфейс должен учитывать текущий контекст: если человек в данный момент работает над проектом A, то все остальное ему не нужно
Стремимся к этому, конечно. Но не все сразу получается.
Все верно. Заказчик подключен к backlog и видит у себя в Мои проекты плоский список
Разработчик, помимо плоского списка, работает с деревом требований к системе. Если декомпозиция требований заказчика не нужна, тогда и дерево, понятно дело, лишнее, можно использовать redmine. А если нужна?