• дыбр ? Наконец то понял, чем мне не нравятся апологеты методик управления проектами, будь то XP или Agile.
    Первый момент мне был ясен и раньше — эти люди продают свой метод, а значит делятся делятся только успешными примерами, замалчивая фейлы.
    Второй понял лишь недавно — просто практика мне не интересна, потому как неизвестно получится ли её применить в конкретной неописанной продавцами ситуации. Хочется теории, объясняющей почему эта практика работает и каковы у неё ограничения.

    Посему реквестирую хороший теоретический обзор данных методик, который определяет их границы применения с описанием потенциально опасных моментов применения практик и обязательно взглядом с точки зрения социальной психологии (интересно какие ограничения есть в зависимости от состава участников команды. Например, есть мнение, что agile-команды должны по максимуму состоять из весьма общительных людей, что бывает не верно для хороших программистов)

Replies (9)

  • @Heni, В классической книге по XP утверждалось, что только следование всем N (сколько там, что-то окло 12) советам типа "парное программирование" и "частые релизы" ведет к успеху. В противном случае: ru.wikipedia.org :)
  • @sky, И какой-же это тогда XP, если он не устойчив к изменениям в методологии, это напоминает просто стандартную отмазку для продавцов технологии: "не методика плохая, просто вы готовить её правильно не научились. И, кстати, всего за N тысяч баксов мы сможем подсказать вам, что неправильно в вашем рецепте приготовления методики"
  • @sky, А за ссылку на принцип "Анны Карениной" спасибо! Не знал раньше как это называется.
  • @Heni, Ну вот так, честно-честно. Я сам читал. Аргументация такая: опытные программисты всегда чувствовали отдельные аспекты XP, пытались их применять и часто обламывались, потому что одни вещи не были поддержаны другими. Авторы XP провели исследование, выделили все эти полезные советы, которые работают вместе и дают положительный результат и обозвали это XP.
  • @sky, ясно — теперь я понимаю как давать характеристику подобным методологиям: "методология хорошая, позволяет предсказуемо достичь результата, но весьма хрупкая и любое изменение базовых принципов может привести к непредсказуемому распаду проекта"
  • @Heni, Если честно, я никогда не работал в agile команде, поэтому никак не могу её защищать или поносить. Сугубо теоретические знания, я даже не знаю работает ли она вообще :) Но с определением априори согласен.
  • @Heni, вот у этого дядьки много написано про различные методики, их плюсы, минусы и ограничения использования: gaperton.livejournal.com
  • @l1feh4ck3r, спасибо — почитаю на досуге
  • @Heni, Продавцы методик ничего не сделали, и совершенно глупо им делегировать такую важную вещь как организацию команды. Лучше изучать успешные структуры и брать здравые моменты, а не выслушивать мнение в принципе некомпетентного продавца. Проверенный способ, очевидный и понятный, — это делегировать одному человеку организацию работы команды.

    Такой человек:
    а) должен быть один, он же и несёт всю ответственность. Коллективная ответственность — миф.
    б) должен быть компетентен в области разработки, сам должен уметь программировать. Успешные команды, управляемые сферическими менеджерами, — миф или везение. Последнее возможно только тогда, когда такой "менеджер" на самом деле принимает все технические решения не сам, и имеет в штате хорошего советчика, но тогда вопрос — почему не поставить этого советчика на место управляющего?
    в) должен чего-то хотеть кроме денег. Мотивация деньгами — нелепость, технический лидер должен ещё чего-то хотеть: выступления на конференциях, статьи в профильные журналы, счастье всех сотрудников, мир во всём мире.

    Ну и сразу надо прощаться с теми, кто хочет большой бюджет, большой штат для "пинания" и ни строки не писать самому. Эти люди чаще всего хотят просто срубить капусту.