Конечно можно :). Не хотел чтобы сочли пост рекламой в каком-либо виде.
Из лидеров рынка я бы выделил ERPM от Lieberman Software и комплексное решение от Cyber-Ark. Есть решения от монстров рынка Identity Management — IBM и Oracle. Они не могут похвастаться большой функциональностью, это лишь дополнения к основным IdM продуктам. Есть нишевые решения, например Hytrust специализируется на защите виртуальных сред.
Тут уже много всего было сказано, но я еще добавлю.
На мой взгляд, неправильно воспринимать юнит и интегральные тесты как средство проверки работоспособности программы.
Процедура тестирования — она, действительно, предназначена для того, чтобы проверить, что программа более менее работоспособна. Тесты пишутся для того, чтобы в любой момент можно было проверить работоспособность программы. А это, в свою очередь, необходимо для того, чтобы быть готовым к внесению изменений в программу.
Понимание этой цепочки следствий приводит к следующему:
Если вы пишете программу, развитие и изменение которой не планируется, то разработка тестов — это просто трата времени. Тестирование можно провести и вручную (оно все равно происходит).
Но если вы используете гибкий подход к разработке, всегда готовы к появлению новых и изменению существующих требований, то тесты — это просто суровая необходимость. Без них просто невозможно обеспечить необходимую скорость внесения изменений.
Начинание правильное, сервис мог бы быть полезным для меня, ЕСЛИ БЫ:
1. Была возможность интеграция в среду разработки. Без этого — проще пользоваться сторонними средствами.
2. Была возможность подстановки значений. Я использую сниппеты не столько как сокровенное знание об алгоритмахх, сколько уменьшение рутинной писанины. Часто случается, когда одну и ту же строчку нужно написать много раз(например название свойства — его использует геттер, сеттер и поле для хранения значения)
Тогда (из своего опыта) рекомендую включить в примеры задачи управления документами вообще и документооборота в частности (которые в статье почему-то упомянуты как не нуждающиеся в метамодели). Я много лет занимался вопросами как раз обобщенных решений для работы с документами, так что могу с уверенностью утверждать, что описываемый Вами подход в этих задачах вполне применим.
ага, а еще эти методы позволяют аргументировано и безрезультатно проедать бюджет в течение весьма длительного времени. Потому как для того чтобы команда успешно реализовала метамодель, пригодную для практического применения, сначала нужно лет несколько успешно порешать практические задачи на прикладном уровне. А без этого почему-то получается очередной многофункциональный, очень полезный, но неповоротливый комбайн, который никто не понимает как использовать в конкретной задаче. :-(
Вот такие примеры, как веб браузеры, (а вместе с ними — СУБД, и другие подобные решения, реализующие метамодели) очень надо включить непосредственно в статью. По опыту, человеку, далекому от понятия метамодели, объяснить что это такое и зачем нужно почти невозможно без живых, понятных ему примеров. В результате получается, что статья реально доступна только тем, кто уже и так понимает что такое метаподход. А для этой аудитории, честно говоря, ничего интересного не прозвучало :-(.
Ой, да ладно, можно подумать кто-то устроен по другому, от пекаря, до ракетостроителя!
Банальное нытье эгоиста, думающего, что он самый разнесчастный. (специально утрирую, чтобы показать абсурд)
Скрестить ничего не мешает, как видите, это даже кто-то уже сделал.
Только толку от этого, к сожалению, немного :-(.
Если Jira вообще не является системой планирования, то MS Project, конечно, пытается это делать, но до того туманным способом… Вспоминается цитата из Р.Хайнлайна — «Демократия плохая система. Её единственное достоинство — она в 8 раз лучше любой другой.» Т.е. большинство достоинств Project кроются в недостатках других систем, он лучше их. Но не становится от этого хорошей системой.
Небольшой вывод — применение любых методологий просто ради их применения в легкую может привести совсем не туда, куда ожидалось. Любые методологии, шаблоны и прочий Фаулер придуманы для того, чтобы решать конкретные задачи. Но есть большой соблазн вляпаться в них до появления самих задач. Вот и получается такая, с позволения сказать, хлебопечка.
Вы знаете, а я не хочу создавать систему управления проектами. Есть куча систем, которые с этой задачей справляются. Мне хочется создать инструмент планирования, который позволит создать приемлемый план, а потом скормить задачи из полученного плана в какой-нибудь issue-tracker типа Jira и отслеживать их выполнение. Мне кажется, что это в несколько раз проще, чем делать очередную систему управления проектами, и при этом даст заметный эффект.
MS Project вполне можно использовать как систему управления проектом. Его сложно рассматривать как систему управления задачами, это верно. Тут уже можно обходиться личным общением или использовать TFS, Jira или любой другой трэкер.
На самом деле, важно смотреть не только на то как мы оценивали задачи, а смотреть в динамике на изменение планируемого срока окончания работ. Пока у нас нет таких данных мы ни о чем не можем говорить, но у меня есть устойчивое ощущение, что скорость движения планируемого «хвоста» проекта (т.е. даты окончания) — величина достаточно стабильная. В частности, подобные наблюдения были сделаны в процессе анализа множества проектов, управляемых по методике освоенного объема. Было замечено, что коэффициент эффективности вложений (по сути отношение фактического результата к планируемым затратам) сильно не меняется после отметки 20% завершения. Это позволяет использовать эту величину для корректирования планируемого срока. Но беда это методики в том, что она требует очень точного расчета всех затрат, что почти невозможно когда проекты не очень большие и их много. Мне кажется, что оценка скорости движения хвоста проекта приведет к тем же результатам при существенно меньших затратах на получение этой оценки.
Если команда под управлением менеджера становится в позу, то это означает только одно — надо гнать в шею либо команду, либо менеджера. А контроль — это не цель. Это лишь один из инструментов управления.
близко имел дело с:
MS Project (+MS Project Server)
Jira
TFS
Basecamp
Trac
Asana
Издалека смотрел на Redmine, Мегаплан, LiquidPlanner.
Много читал про разные другие системы (конкретных названий уже не скажу, все смешалось, уж больно они все похожи).
Не упоминаю разнообразные персональные органайзеры, которые претендуют на управление проектами.
Интересная мысль… Я вообще больше думал в сторону автоматизации способа мышления, а это движение в сторону применения для планирования социальных инструментов — очень в духе времени :-)
Мне очень грустно развеивать Ваши заблуждения, но управление на самом деле бывает. Действительно, специалисты решают конкретные технические задачи, а менеджеры контролируют их деятельность. Но кроме них еще существуют руководители, которые весь этот бардак пытаются вести в некотором направлении. И при отсутствии управления все почему-то очень быстро превращается в иллюстрацию к басне «Лебедь, рак и щука». Случается, конечно, такое чудо, как самоуправляемые команды, но это очень большая редкость.
Из лидеров рынка я бы выделил ERPM от Lieberman Software и комплексное решение от Cyber-Ark. Есть решения от монстров рынка Identity Management — IBM и Oracle. Они не могут похвастаться большой функциональностью, это лишь дополнения к основным IdM продуктам. Есть нишевые решения, например Hytrust специализируется на защите виртуальных сред.
На мой взгляд, неправильно воспринимать юнит и интегральные тесты как средство проверки работоспособности программы.
Процедура тестирования — она, действительно, предназначена для того, чтобы проверить, что программа более менее работоспособна. Тесты пишутся для того, чтобы в любой момент можно было проверить работоспособность программы. А это, в свою очередь, необходимо для того, чтобы быть готовым к внесению изменений в программу.
Понимание этой цепочки следствий приводит к следующему:
Если вы пишете программу, развитие и изменение которой не планируется, то разработка тестов — это просто трата времени. Тестирование можно провести и вручную (оно все равно происходит).
Но если вы используете гибкий подход к разработке, всегда готовы к появлению новых и изменению существующих требований, то тесты — это просто суровая необходимость. Без них просто невозможно обеспечить необходимую скорость внесения изменений.
Опоздал ставить плюс за статью, придется плюсовать карму :)
1. Была возможность интеграция в среду разработки. Без этого — проще пользоваться сторонними средствами.
2. Была возможность подстановки значений. Я использую сниппеты не столько как сокровенное знание об алгоритмахх, сколько уменьшение рутинной писанины. Часто случается, когда одну и ту же строчку нужно написать много раз(например название свойства — его использует геттер, сеттер и поле для хранения значения)
Банальное нытье эгоиста, думающего, что он самый разнесчастный. (специально утрирую, чтобы показать абсурд)
Программист всего лишь старается сделать мир лучше, исправляя его самые худшие проявления. При чем тут негатив?
Только толку от этого, к сожалению, немного :-(.
Если Jira вообще не является системой планирования, то MS Project, конечно, пытается это делать, но до того туманным способом… Вспоминается цитата из Р.Хайнлайна — «Демократия плохая система. Её единственное достоинство — она в 8 раз лучше любой другой.» Т.е. большинство достоинств Project кроются в недостатках других систем, он лучше их. Но не становится от этого хорошей системой.
MS Project (+MS Project Server)
Jira
TFS
Basecamp
Trac
Asana
Издалека смотрел на Redmine, Мегаплан, LiquidPlanner.
Много читал про разные другие системы (конкретных названий уже не скажу, все смешалось, уж больно они все похожи).
Не упоминаю разнообразные персональные органайзеры, которые претендуют на управление проектами.