Смотря что называть идеологией SCRUM. Описание методологии SCRUM весьма и весьма компактно, саму по себе методологию считаю очень эффективной, думаю, из-за этого — простота и эффективность — она так популярна.
Популярность легко переходит в модность, в силу этого очень многие люди стремятся высказаться на темы вокруг SCRUM, слово SCRUM в заголовке сильно повышает популярность темы в определенных кругах, круги волей-неволей читают, комментируют, и происходит еще один спринт по переливанию из пустого в порожнее :). Все довольны, все высказались. А вот платит за эти разговоры заказчик :) Тут практически без вариантов.
>Особенно если цель поставлена чётко и недвусмысленно — тупо удовлетворить заказчика не занимаясь при этом никакой самодеятельностью.
А какая интересно еще бывает цель? Если заказчик доволен, то и исполнителю воздается соответственно, корреляция довольно хорошая. Вот если исполнитель начинает помимо тупого удовлетворения заказчика еще и интеллектуально удовлетворять себя, тут возможны нюансы :)
На мой взгляд, ситуация несколько перекликается с тестом Тьюринга по ИИ, где интеллект определяется через другой интеллект, по сути — крайне субъективно, ввиду наличия отсутствия объективных критериев.
Так и здесь — для оценки работника нужен другой работник, иногда называемый начальником :)
Хороший работник виден начальнику и так, невооруженным статистикой глазом. Ведь зачастую крайне важны такие вещи как мотивация, коммуникабельность, способность позитивно вести себя в конфликтных ситуациях, энтузиазм, в конце концов, а как это все объективно измерить?
Иными словами, хочешь узнать, кто лучший в конкретном подразделении — спроси у начальника подразделения.
На мой взгляд, самая большая проблема тут — Прогнозируемая производительность команды
Чтобы ее получить, необходимо выполнить несколько итераций. Хенрик Книберг в Scrum и XP: заметки с передовой рекомендует в качестве продолжительности спринта 3 недели. Т.е. пилотный проект, получается, будет длиться несколько месяцев. Хорошо, когда это лишь малая часть от общего бюджета, т.е. проект — весьма крупный.
С трудом представляю, как можно оценить производительность за одну итерацию — народ только-только начнет «въезжать» в проект.
Ну т.е. самая крупная проблема проектов с фиксированой ценой по сути осталась за рамками статьи. Ну что ж, зато еще раз прочитали изложение методологии SCRUM :)
>Вот, например, по этому скриншоту: если у меня еженедельные milestones, то очень скоро прийдется долго прокручивать вниз, чтобы открыть, скажем, поддерево проекта, который идет в списке следующим.
Вообще, текущие milestones заносятся в закладки и выбираются из закладок, в дерево для текущей работы с milestone лазить не нужно. Туда в основном нужно заходить чтобы создавать новые элементы. У нас, кстати, можно создавать вложенные milestone. Пустячок, а приятно ;)
Ах, как это верно! Действительно, была такая программерская мысль, c нее и началось все. Однако, наряду с минусами есть и плюсы. Мы ведем постоянную борьбу, чтобы плюсы перевесили минусы.
>Вообще интерфейс должен учитывать текущий контекст: если человек в данный момент работает над проектом A, то все остальное ему не нужно
Стремимся к этому, конечно. Но не все сразу получается.
>надо садиться и писать пользовательские сценарии, представляя себя пользователем и анализируя его потребности с точки зрения того, какую задачу он в данном сценарии решает
Все верно. Заказчик подключен к backlog и видит у себя в Мои проекты плоский список
Разработчик, помимо плоского списка, работает с деревом требований к системе. Если декомпозиция требований заказчика не нужна, тогда и дерево, понятно дело, лишнее, можно использовать redmine. А если нужна?
Есть русскоязычный сайт, соответственно, и русскоязычный интерфейс.
Помомо задач и проектов, система может вести иерархическую документацию. (После открытия ссылки хорошо нажать иконку вверху слева «Найти в дереве»)
Зачем он вообще был сделан? Основная идея была такова — неограниченная иерархия всего, что позволяет строить дерево проекта необходимым образом. В частности, можно эффектно декомпозировать задачи из backlog
На картинке видны характерные особенности Project Kaiser:
а) Слева отображается дерево требований к системе, полученное путем декомпозиции плоского списка задач backlog проекта. Это эффективно самодокументирует систему, каждая функция представлена в виде требования, требования рассортированы по модулям, и все это отображается в виде древовидной структуры. Плоский списки, задач, понятное дело, тоже могут вестись.
б) Справа видим плоский список задач для требования usr:SCRUM, заметим, что он не совсем плоский, а показывает подзадачи ( неограниченной вложенности) в режиме outline
Кое-чего (и даже многого:( ) нет, но система не стоит на месте. Сейчас делаем поддержку SCRUM, в следующей версии будет учет времени выполнения задач.
GUI, конечно, во многом дело вкуса, но некоторым :) нравится
Ну, автор вроде как наоборот, уверен :)
Более того, автор указывает на проблему, связанную с этим:
>во время перехода в течение часа каждому значению wall clock time соответствуют два момента времени (часы дважды показывают 02:01, 02:02, 02:03 и т.д, при этом это разные моменты времени). То есть, мы не можем однозначно определить по wall clock time 02:30 27.10.2002, какой это момент во времени
>Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC
Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
www.itcompanies.ru/14zp.html
Зарплаты основных направлений ИТ-специалистов за 1 полугодие 2009 г. (по данным «Империя Кадров», 2009)
Зарплата-ориентир, тыс. руб.
С/С++ 40
Java 50
Можно оценить, выше твоя зп или ниже. Критерии можно и нужно уточнять в зависимости от региона, однако, конечно, таким образом оцениватся не технический уровень, а способность человека найти работу. Конечно, технический уровень является важной составляющей такой способности, но не единственной.
Популярность легко переходит в модность, в силу этого очень многие люди стремятся высказаться на темы вокруг 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. А если нужна?
Есть русскоязычный сайт, соответственно, и русскоязычный интерфейс.
Помомо задач и проектов, система может вести иерархическую документацию. (После открытия ссылки хорошо нажать иконку вверху слева «Найти в дереве»)
Зачем он вообще был сделан? Основная идея была такова — неограниченная иерархия всего, что позволяет строить дерево проекта необходимым образом. В частности, можно эффектно декомпозировать задачи из backlog
На картинке видны характерные особенности Project Kaiser:
а) Слева отображается дерево требований к системе, полученное путем декомпозиции плоского списка задач backlog проекта. Это эффективно самодокументирует систему, каждая функция представлена в виде требования, требования рассортированы по модулям, и все это отображается в виде древовидной структуры. Плоский списки, задач, понятное дело, тоже могут вестись.
б) Справа видим плоский список задач для требования usr:SCRUM, заметим, что он не совсем плоский, а показывает подзадачи ( неограниченной вложенности) в режиме outline
Кое-чего (и даже многого:( ) нет, но система не стоит на месте. Сейчас делаем поддержку SCRUM, в следующей версии будет учет времени выполнения задач.
GUI, конечно, во многом дело вкуса, но некоторым :) нравится
www.levadecorp.com/project_management_system.html
The system is browser based yet with snappy response time and intuitive GUI.
Более того, автор указывает на проблему, связанную с этим:
>во время перехода в течение часа каждому значению wall clock time соответствуют два момента времени (часы дважды показывают 02:01, 02:02, 02:03 и т.д, при этом это разные моменты времени). То есть, мы не можем однозначно определить по wall clock time 02:30 27.10.2002, какой это момент во времени
>Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC
Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
www.itcompanies.ru/14zp.html
Зарплаты основных направлений ИТ-специалистов за 1 полугодие 2009 г. (по данным «Империя Кадров», 2009)
Зарплата-ориентир, тыс. руб.
С/С++ 40
Java 50
Можно оценить, выше твоя зп или ниже. Критерии можно и нужно уточнять в зависимости от региона, однако, конечно, таким образом оцениватся не технический уровень, а способность человека найти работу. Конечно, технический уровень является важной составляющей такой способности, но не единственной.
Вот тут
www.dpreview.com/reviews/panasonicgf1/page14.asp
пишут такое:
«it's easily as good as the autofocus on most entry-level digital SLRs»
правда, это про другую систему, PANASONIC GF1, но тем не менее. Вроде как научились контрастный автофокус делать достаточно быстрым.