Ну, если средств нет, это ещё не означает, что это именно потому, что их в принципе быть не может. Того же Project'а и Excel'а тоже когда-то не было. Или более подходящий пример: не так давно фейсбука не было, а люди как-то между собой общались. Может быть, стоит отказаться от него сейчас? Мне кажется, нам, технарям вредно думать в направлении, что что-то сделать нельзя. Целесообразность создания средства может быть под вопросом. Но мне не так много не хватило в связке Project + TFS.
Согласен с тем, что высокоуровневые проектные задачи и таски — это разные вещи. Не уверен, что это подчёркнуто в статье, но я это имел в виду, когда её писал.
Борис, почему Вы считаете, что автоматическая синхронизация, хотя бы с вопросами пользователю (менеджеру) вредна? Я не вижу серьёзных аргументов в защиту этого тезиса. Это вот разные типы задач? Если внимательно посмотреть на первый скриншот, то план работ включает у меня и таски для дизайнеров, и для аналитиков. Что же касается, к примеру, написания документации, то можно как вести учёт работы по этой проектной задаче в системе контроля тасков, так и не вести.
Мне не нравится, что в этой совместной работе менеджера проекта, тимлида и всех прочих лиц, как сейчас почти везде и происходит, появляются соглашения, суть которых может быть не зафиксирована в совместном опубликованном плане работ. Я встречал ситуацию, когда менеджер проектов и аналитик пошли и договорились, что они понимают под высокоуровневой задачей, и при этом никому не сказали, что конкретно нужно сделать в определённой итерации в определённом таске. Конечно, Вы сейчас скажете, что можно придумать управленческую технику, должны быть протоколы и т.п., но зачем заставлять себя придумывать 10 способов учёта, если можно было бы воспользоваться одной системой?
Проблема в том, что вроде бы такой системы не существует. Почему бы сообществу не застартапить такой проект? Чем он хуже других отчаянных попыток автоматизировать любую область человеческой деятельности?
Есть контр-аргументы создания такой системы. Проблемы делятся на две группы:
1) Проектные подходы различаются, поэтому сделать систему, которая учитывает все нюансы, довольно трудозатратно
2) Люди — это не ресурсы, а именно люди — и им тяжело выдерживать до конца тот цикл, в который их стараются погрузить
На мой взгляд, совершенно очевидно то, что машину несложно научить исправлять ошибки планирования вида «таск X стала в два раза дольше, поэтому есть проблемы с закрытием итерации => существует риск закрытия этапа». Но программисты очень мало инвестируют в технологии для самих себя. С их точки зрения это очень длинные инвестиции, а текущая разработка принесёт прибыль здесь и сейчас. Именно по этой причине в статье я и обратился с критикой к гиганту — Microsoft — ведь у них есть система для управления проектами и система для управления разработкой. Microsoft до сих пор качественно их не объединила, но при этом затраты на «рутинный труд менеджеров» у них самих при выпуске продуктов должны быть грандиозными. Те же новости о срывах сроков производства Windows и Office появляются регулярно.
Представьте, что автор этой статьи прекрасно знает о том, что Вы пишите. Теперь предположите, что и все следующие аргументы из разряда «Java — лучше» ему тоже известны. А теперь задайте себе вопрос: раз так, то почему же эти парни вместо Java взяли в руки node.js? Ответ сложен и прост одновременно: хорошие программисты добиваются результата на том стеке, который больше подходит для конкретной задачи.
Я бы хотел перевести разговор в иную плоскость: какой RAD больше подходит для разработки в условиях очень кратких, практически одно- и двухдневных итераций с условием перехода в условный продакшн на финишной прямой такой разработки.
Я не очень-то хочу заниматься критикой авторов комментариев, так как уважаю чужое мнение, однако хочу заметить, что через несколько лет, когда у Вас будет больше опыта промышленной разработки в разных проектах как Java, так и на других платформах и языках, Ваше мнение о том, что хороший программист должен ускоспециализироваться только на одном самом крутом и самом мощном инструменте, изменится.
При всех достоинствах Java и при всей «крутости» Java-программистов инструменты будут продолжать развиваться и когда-нибудь некая платформа «X» окончательно похоронит эту замечательную технологию, которой уже исполнилось двадцать лет.
Мы находимся в постоянном поиске, в работе по изучению инструментов под наши задачи, которые позволяют как быстро прототипировать ПО, так и запускать его в опытную эксплуатацию. В связи с этим и возникают задачи «изучить X для опытных Java-программистов», подобные этой. И люди, которые работают в одном с нами направлении, прекрасно понимают, почему мы это затеяли. Обо всей этой кухне мы напишем, я надеюсь, в следующих статьях в блоге Центра Информационных Технологий.
Согласен с тем, что высокоуровневые проектные задачи и таски — это разные вещи. Не уверен, что это подчёркнуто в статье, но я это имел в виду, когда её писал.
Борис, почему Вы считаете, что автоматическая синхронизация, хотя бы с вопросами пользователю (менеджеру) вредна? Я не вижу серьёзных аргументов в защиту этого тезиса. Это вот разные типы задач? Если внимательно посмотреть на первый скриншот, то план работ включает у меня и таски для дизайнеров, и для аналитиков. Что же касается, к примеру, написания документации, то можно как вести учёт работы по этой проектной задаче в системе контроля тасков, так и не вести.
Мне не нравится, что в этой совместной работе менеджера проекта, тимлида и всех прочих лиц, как сейчас почти везде и происходит, появляются соглашения, суть которых может быть не зафиксирована в совместном опубликованном плане работ. Я встречал ситуацию, когда менеджер проектов и аналитик пошли и договорились, что они понимают под высокоуровневой задачей, и при этом никому не сказали, что конкретно нужно сделать в определённой итерации в определённом таске. Конечно, Вы сейчас скажете, что можно придумать управленческую технику, должны быть протоколы и т.п., но зачем заставлять себя придумывать 10 способов учёта, если можно было бы воспользоваться одной системой?
Проблема в том, что вроде бы такой системы не существует. Почему бы сообществу не застартапить такой проект? Чем он хуже других отчаянных попыток автоматизировать любую область человеческой деятельности?
Есть контр-аргументы создания такой системы. Проблемы делятся на две группы:
1) Проектные подходы различаются, поэтому сделать систему, которая учитывает все нюансы, довольно трудозатратно
2) Люди — это не ресурсы, а именно люди — и им тяжело выдерживать до конца тот цикл, в который их стараются погрузить
На мой взгляд, совершенно очевидно то, что машину несложно научить исправлять ошибки планирования вида «таск X стала в два раза дольше, поэтому есть проблемы с закрытием итерации => существует риск закрытия этапа». Но программисты очень мало инвестируют в технологии для самих себя. С их точки зрения это очень длинные инвестиции, а текущая разработка принесёт прибыль здесь и сейчас. Именно по этой причине в статье я и обратился с критикой к гиганту — Microsoft — ведь у них есть система для управления проектами и система для управления разработкой. Microsoft до сих пор качественно их не объединила, но при этом затраты на «рутинный труд менеджеров» у них самих при выпуске продуктов должны быть грандиозными. Те же новости о срывах сроков производства Windows и Office появляются регулярно.
Вот это в точку.
Представьте, что автор этой статьи прекрасно знает о том, что Вы пишите. Теперь предположите, что и все следующие аргументы из разряда «Java — лучше» ему тоже известны. А теперь задайте себе вопрос: раз так, то почему же эти парни вместо Java взяли в руки node.js? Ответ сложен и прост одновременно: хорошие программисты добиваются результата на том стеке, который больше подходит для конкретной задачи.
Я бы хотел перевести разговор в иную плоскость: какой RAD больше подходит для разработки в условиях очень кратких, практически одно- и двухдневных итераций с условием перехода в условный продакшн на финишной прямой такой разработки.
При всех достоинствах Java и при всей «крутости» Java-программистов инструменты будут продолжать развиваться и когда-нибудь некая платформа «X» окончательно похоронит эту замечательную технологию, которой уже исполнилось двадцать лет.
Мы находимся в постоянном поиске, в работе по изучению инструментов под наши задачи, которые позволяют как быстро прототипировать ПО, так и запускать его в опытную эксплуатацию. В связи с этим и возникают задачи «изучить X для опытных Java-программистов», подобные этой. И люди, которые работают в одном с нами направлении, прекрасно понимают, почему мы это затеяли. Обо всей этой кухне мы напишем, я надеюсь, в следующих статьях в блоге Центра Информационных Технологий.
Мне нравится — я читаю. Не нравится — не читаю.