Странно видеть на форумах воинствующих проповедников анти-Agile движения. Выкрики, скажем хором нет Agile вызывают только улыбку. Но напор анти-аджайлистов не убывает и со временем разрастается, подкрепившись страшными аббревиатурами PMI, PMBOK и другими. Но так ли Agile хорошо, чтобы такие вещи ему противопоставлять, а может быть Agile нету? А может это совершенно перпендикулярно?
Оказывается ответ на этот вопрос давным давно скрывается в источниках по управлению персоналом, теории организации и менеджменте. Оказывается продвинутый народ в областях не связанных с программированием ещё в 70-х годах, а может даже и раньше, стали задумываться о проблеме повышения эффективности работы производственных отделов, а особенно связанных с интеллектуальным трудом.
Учённые оксфорда, кэмбриджа, американских, европейских и кучи других институтов бились, как сделать так, чтобы бизнес работал эффективней. И о чудо! Взору учёных предстал тот самый человеческий фактор. И люди науки, народ кстати не глупый, сообразили, что нужно повернуться к человеку лицом. А чтобы дело пошло нужно сделать эффективным не производство, а сделать эффективной команду. А команда сама уже сделать производство эффективным.
И взрыв произошёл. Takeuchi, Hirotaka; Nonaka, Ikujiro (January-February 1986). "The New New Product Development Game" обобщили понятие эффективной команды. Команда тогда эффективна, когда она самоорганизуется. А дальше и наука и практика показали, что эти догадки были верны...
Поэтому осталось дело за малым дать какое-то хорошее определение и уже плясать от него. Командой называют небольшое количество человек (чаще всего пять — семь, реже до 15-20), которые разделяют цели, ценности и общие подходы к реализации совместной деятельности, имеют взаимодополняющие навыки; принимают на себя ответственность за конечные результаты, способны изменять функционально-ролевую соотнесенность (исполнять любые внутригрупповые роли); имеют взаимоопределяющую принад-лежность свою и партнеров к данной общности (группе).
Вот и свойства эффективной командой (доказано формально и научно, а так же подтверждено практическими фактами):
* Неформальная и открытая атмосфера;
* Задача хорошо понята и принимается;
* Члены группы прислушиваются друг к другу;
* В обсуждении принципиальных вопросов участвуют все члены группы;
* В ходе обсуждения поощряется как высказывание идей, так и выражение чувств;
* Конфликты и разногласия между членами группы цен-трируются вокруг идей и методов, а не личностей;
* Группа осознает, что делает, решение основывается на согласии, а не на голосовании большинства
Вопрос к вам: насколько ваша команда эффективна?
Да, хочется добавить. Вернёмся чуток раньше. А ведь уже в 1968 году D.Cartwright и A.Zander говорили, что : "Группа – это объединение индивидов, поддерживающих взаимоотношения, которые делают их взаимозависимыми, и стремящихся к общей цели". Опять вокруг да около
Теперь уже понятно. Решение наших проблем найдено. Но как сделать эту команду? Определение есть, признаки эффективной команды тоже написаны. Но крайне не понятно чего делать то? Как организовываться так, чтобы всё заработало. Можно поступить просто отдать на откуп команде. И пусть команда сама изобретёт те практики, которые приведут её к эффективности. Но постойте, команда будет изобретать то, что уже давно изобретено. А давайте всего лишь обратимся к мировому опыту. К мировым коллекциям лучших практик, которые уже проверены тысячами команд и не одним десятилетием. Просто обратимся к Agile...
Здравствуйте, denis miller, Вы писали:
DM>Странно видеть на форумах воинствующих проповедников анти-Agile движения. Выкрики, скажем хором нет Agile вызывают только улыбку.
Действительно странно. К проповедникам agile вроде уже привыкли. А вот "проповедники анти-agile движения" — это какая-то новая напасть. Особенно радует наличие какого-то "движения".
DM>Но так ли Agile хорошо, чтобы такие вещи ему противопоставлять, а может быть Agile нету? А может это совершенно перпендикулярно?
"Такие" вещи — это какие, можно поинтересоваться? Впрочем, это не важно, потому что никакого agile как цельного явления действительно "нету". Желающие могут убедится в этом сами, постаравшись найти хоть какое-то сходство между XP и FDD.
DM>Но напор анти-аджайлистов не убывает и со временем разрастается, подкрепившись страшными аббревиатурами PMI, PMBOK и другими.
Что, страшно?
DM>Оказывается ответ на этот вопрос давным давно скрывается в источниках по управлению персоналом, теории организации и менеджменте. Оказывается продвинутый народ в областях не связанных с программированием ещё в 70-х годах, а может даже и раньше, стали задумываться о проблеме повышения эффективности работы производственных отделов, а особенно связанных с интеллектуальным трудом.
И все они были агилистами.
DM>Учённые оксфорда, кэмбриджа, американских, европейских и кучи других институтов бились, как сделать так, чтобы бизнес работал эффективней. И о чудо! Взору учёных предстал тот самый человеческий фактор. И люди науки, народ кстати не глупый, сообразили, что нужно повернуться к человеку лицом. А чтобы дело пошло нужно сделать эффективным не производство, а сделать эффективной команду. А команда сама уже сделать производство эффективным.
Во-первых, никто не говорил, что производство не надо делать эффективным, и "команда сама должна сделать производство эффективным". Это бред. Командный фактор в работах по организационному поведению, на которые ты пытаешься сослаться, и в целом имеющими мало общего с agile, рассматривается как способ повышения производительности труда.
DM>И взрыв произошёл. Takeuchi, Hirotaka; Nonaka, Ikujiro (January-February 1986). "The New New Product Development Game" обобщили понятие эффективной команды. Команда тогда эффективна, когда она самоорганизуется. А дальше и наука и практика показали, что эти догадки были верны...
Вдохновенно. Вообще-то "хоторнские эксперименты" на заводе General Electric, которые научно достоверно установили важность неформальных малых групп, человеческого фактора, и их влияние на производительность, проводились с 1927 по 1939 год. Так, хозяйке на заметку.
DM>Поэтому осталось дело за малым дать какое-то хорошее определение и уже плясать от него. Командой называют небольшое количество человек (чаще всего пять — семь, реже до 15-20), которые разделяют цели, ценности и общие подходы к реализации совместной деятельности, имеют взаимодополняющие навыки; принимают на себя ответственность за конечные результаты, способны изменять функционально-ролевую соотнесенность (исполнять любые внутригрупповые роли); имеют взаимоопределяющую принад-лежность свою и партнеров к данной общности (группе).
"Мостовая — это участок дороги, выложенный камнями".
DM>Вот и свойства эффективной командой (доказано формально и научно, а так же подтверждено практическими фактами):
Формально доказать свойства эффективной команды невозможно . Это не математика . Впрочем, когда ссылаешься на факты, и научные работы, которые что-то доказывают, принято давать ссылку на работу.
DM>Теперь уже понятно. Решение наших проблем найдено. Но как сделать эту команду? Определение есть, признаки эффективной команды тоже написаны. Но крайне не понятно чего делать то? Как организовываться так, чтобы всё заработало. Можно поступить просто отдать на откуп команде. И пусть команда сама изобретёт те практики, которые приведут её к эффективности. Но постойте, команда будет изобретать то, что уже давно изобретено. А давайте всего лишь обратимся к мировому опыту. К мировым коллекциям лучших практик, которые уже проверены тысячами команд и не одним десятилетием. Просто обратимся к Agile...
Во имя Господа нашего, Иисуса Христа. Аминь. Ты посох из котелка вынь, наконец, Денис .
Здравствуйте, denis miller, Вы писали: серую проповедь "да здравствует ажайл"...
Вы один из свидетелей иег... agile. За шкирку вас и на улицу! Не морочте людям голову ,не отвлекайте их от работы. Вы со своими "обратимся к Agile" повышаете эффективность производства, как паразит в печени способствует правильному пищеварению.
Здравствуйте, denis miller, Вы писали:
DM>Вопрос к вам: насколько ваша команда эффективна?
DM>Да, хочется добавить. Вернёмся чуток раньше. А ведь уже в 1968 году D.Cartwright и A.Zander говорили, что : "Группа – это объединение индивидов, поддерживающих взаимоотношения, которые делают их взаимозависимыми, и стремящихся к общей цели". Опять вокруг да около
DM>Теперь уже понятно. Решение наших проблем найдено. Но как сделать эту команду? Определение есть, признаки эффективной команды тоже написаны. Но крайне не понятно чего делать то? Как организовываться так, чтобы всё заработало.
Вообще мне кажется тут путаем теплое с мягким. Управление проектами и методология разработки ПО — разные вещи. Использование той или иной методологии заставляет по разному в частности составлять ИСР, если в RUP или MSF я бы взял за верхний уровень фазу проекта ( анализ/разработка/тестирование ), то в Agile за верхний уровень удобнее взять итерации или грубо говоря фичи , т.к. каждая итерация в Agile это выпуск релиза с
добавлением новой фичи по сути небольшой проект который внутри уже содержит свои фазы ( анализ/разработка/тестирование ). Но в целом это никак не противоречит управлению проектами и PMI никоим образом не запрещает использовать какие либо методологии разработки. Для каждого проекта в идеале нужно выбирать свою методологию.
Также если я не ошибаюсь то Agile не говорит о том самоорганизованная команда или нет. Основной тезис Agile как мне представляется :
— снизить риск неверной интерпретации требований заказчика за счет частого выпуска промежуточных релизов и демонстрации заказчику.
А кто уж будет там профи или не профи заниматься непосредственно разработкой это не самое главное, если четко описаны процессы то там и индусы смогут работать.
Тут я могу заблуждаться ( с Agile знаком поверхностно ) — поправьте или дополните.
Если же говорить о самоорганизованной команде профи, то там скорее управление проектами не требуется. Чем это плохо или хорошо уже описано в стандарте CMM http://ru.wikipedia.org/wiki/CMM. Есть 5 уровней развития организации. Проектное управление становится необходимым на втором уровне. Ранее вводить не целесообразно.
Для тех у кого вдруг доступ к wikipedia закрыт приведу текст оттуда :
Сущность
Ключевым понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются «на ходу» — то что на современном языке называется творческим подходом, или искусством. В этом случае велика вероятность превышения бюджета или сроков сдачи проекта, и потому менеджеры и разработчики вынуждены заниматься только разрешением ближайших проблем, становясь, тем самым, заложниками собственного программного продукта.
С другой стороны, в зрелой организации имеются чётко определённые процедуры создания программных продуктов и управления проектами. Эти процедуры по мере необходимости уточняются и совершенствуются в пилотных проектах или с помощью анализа стоимость/прибыль. Оценки времени и стоимости выполнения работ основываются на накопленном опыте и достаточно точны. Наконец, в компании существуют стандарты на процессы разработки, тестирования и внедрения ПО, правила оформления конечного программного кода, компонентов, интерфейсов и т. д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения, когда все стандартизовано.
Уровни зрелости
CMM определяет пять уровней зрелости организаций. В результате аттестации компании присваивается определённый уровень, который в дальнейшем может повышаться или понижаться. Здесь хочется отметить, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих. Initial Level
Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причём успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.
Пример: Предприятия 1 уровня характеризуются тенденцией к завышению требований, отмене проекта в критической ситуации и неспособностью к повторению предыдущих успехов. Успех проекта зависит от наличия специалистов высокого уровня. Repeatable Level
Повторяемый уровень (repeatable level). Для его внедрения на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причём обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень. Defined Level
Определённый уровень (defined level). Он характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестаёт зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях. Managed Level
Управляемый уровень (managed level) в организации устанавливаются количественные показатели качества — как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счёт уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях. Optimizing Level
Оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например с помощью создания и повторного использования компонентов.
Здравствуйте, pashzhel, Вы писали:
P>Defined Level P>Начиная с этого уровня, организация перестаёт зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
Всегда забавлял этот неимоверный бред, про уровни CMMI! Надо думать организация начинает зависит только от количества разработчиков?
Про Agile ведь всё довольно понятно. Есть собирательное название кучи приёмчиков и практик разработки. Некоторые из них поддерживают друг друга, создавая кумулятивный эффект. Многие имеют ограниченную область применимости. Из этих кубиков и собирают различные методологии. В некоторых ситуациях некоторые собранные конфигурации работают довольно хорошо и это отрицать нельзя. В некоторых других ситуациях отдельные кубики могут оказаться неприменимы — это тоже факт (с которым правда Агилисты почему-то любят спорить).
Я боюсь сейчас происходит формирование отрицательного мнения к Agile за счёт формирования отрицательного отношения к проповеднику этого Agile...
Здравствуйте, XopoSHiy, Вы писали:
XSH>Здравствуйте, pashzhel, Вы писали:
P>>Defined Level P>>Начиная с этого уровня, организация перестаёт зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
XSH>Всегда забавлял этот неимоверный бред, про уровни CMMI! Надо думать организация начинает зависит только от количества разработчиков?
Ключевое слово "конкретных разработчиков" а не качества и уровня их подготовки "по больнице в среднем". Хотя нужно отметить что как правило требования к уровню подготовки для рядовых разработчиков при наличии качественных процессов снижаются и обеспечивается лучшая заменяемость.
Например я думаю сложно представить ситуацию что Microsoft не выпустит следующую версию Windows потому что уволился ключевой разработчик этой системы.
В организациях Initial Level как правило все держится на конкретных разработчиках и уход из команды одного из них как правило критичен для всего проекта.
Здравствуйте, pashzhel, Вы писали:
P>Если же говорить о самоорганизованной команде профи, то там скорее управление проектами не требуется. Чем это плохо или хорошо уже описано в стандарте CMM P>http://ru.wikipedia.org/wiki/CMM. Есть 5 уровней развития организации. Проектное управление становится необходимым на втором уровне. Ранее вводить не целесообразно.
О, коллега, я вижу, вы наконец нашли достойного оппонента. Инь и Янь нашего форума, буквально, свет и тьма — наконец, схлестнулись в благородной дискуссии!
Миллер, правда, в последнее время сильно сдал, и уже не боец. Жаль .
Денис, я за тебя болею! Давай, не подведи! Покажи ему! Он назвал самоорганизованные команды профи земляными червяками, приписав им уровеь 1 CMM — полная дизорганизованность!
DM>Учённые оксфорда, кэмбриджа, американских, европейских и кучи других институтов бились, как сделать так, чтобы бизнес работал эффективней. И о чудо! Взору учёных предстал тот самый человеческий фактор. И люди науки, народ кстати не глупый, сообразили, что нужно повернуться к человеку лицом. А чтобы дело пошло нужно сделать эффективным не производство, а сделать эффективной команду. А команда сама уже сделать производство эффективным.
DM>[...] А давайте всего лишь обратимся к мировому опыту. К мировым коллекциям лучших практик, которые уже проверены тысячами команд и не одним десятилетием. Просто обратимся к Agile...
ИМХО, энтузиазм некоторых коллег, по поводу приходящих к нам с Запада разнообразных гибких методологий в разработке ПО, скорее всего от недостатка информации и опыта. Суть всех этих подходов: Scrum, xProgramming, Crystal, ASD, FDD и прочих, — состоит в том, что они декларируют своей высшей ценностью командную работу, ориентированность на людей и их взаимодействие, а не на процессы и средства.
О признании на западе важности коллективизма и командобразования в разработке ПО так же свидетельствуют и последние труды Института технологий разработки программного обеспечения SEI. В частности, «Командный процесс разработки программного обеспечения (Team Software Process, TSP)» определяет, что «основная задача руководителя группы состоит в том, чтобы поддержать мотивацию и целеустремленность команды, направленные на достижение наивысшей эффективности выполнения работ».
На мой взгляд, эти методологии похожи на попытки «переоткрытия» представителями индивидуалистской западной культуры принципов коллективизма, хорошо зарекомендовавших себя в России с прежних времен.
Если вспомнить историю, то для российского менталитета командная работа достаточно привычный вид коллективной деятельности. С XIII века в России существовали производственные артели — различные формы добровольных объединений людей с целью осуществления общей хозяйственной деятельности. Например, артели плотников, лесорубов, рыболовов, земледельцев и др. Русская рабочая артель являлась одним из устоев народной жизни. Она была добровольным товариществом совершенно равноправных работников, призванных на основе взаимопомощи и взаимовыручки решать практически любые хозяйственные и производственные задачи. Равноправием артели резко отличались от капиталистических предприятий. Равноправие, конечно, не означало уравниловки — распределение дохода осуществлялось по труду.
Истинный российский коллективизм (соборность) не имеет ничего общего с вульгарным коллективизмом: со стадностью, подавлением личности («я нет, есть только мы!», «я – последняя буква алфавита!»), уступчивостью, групповой психологией и слепым подчинением меньшинства большинству. Суть российского коллективизма в том, что человек ощущает себя элементом органичной системы, где он выполняет свою функцию, свою задачу, совершенно особенную, которую не выполняет никто другой и выполнить не может. Эту задачу он выполняет совершенно сознательно, стремясь к максимальной реализации своих целей. Объединение людей в артель не только не ограничивало дух самостоятельности и предприимчивости каждого артельщика, а, напротив, поощряло его. Артель позволяла сочетать склонность русского человека к самостоятельному и даже обособленному труду с коллективными усилиями.
Позднее во времена СССР широкое распространение на производстве получили рабочие бригады, а в научно-исследовательских институтах — временные научные творческие коллективы, которые объединялись на основе общности цели, взаимопомощи и коллективной ответственности за результат. В чем их преимущество перед строгими многоступенчатыми иерархическими организационными структурами я имел возможность изучить на собственном опыте.
Вывод. Никакой Agile методологии нет. Есть набор практик, применение которых, если повезет, может поспособствовать образованию самоуправляемой и самоорганизующейся команды. А может и нет.
DM>Но крайне не понятно чего делать то? Как организовываться так, чтобы всё заработало.
Мое мнение. Эффективные команды не образуются сами по себе, они кристаллизуются вокруг признанного лидера. Как не бывает лидеров без последователей, так и не бывает команд без лидеров. Пример, сборная России по футболу 2008 и Гус Хидинг.
Факты о которых я упоминал ищите в теории менеджмента. Я находил.
Поэтому убеждён в сказаном. А вас убеждать не собираюсь, хотите — ищите
Я высказывал мысли в слух, кому нужно он понял.
А давайте сделаем просто — я прийду к вам в гости. У меня
будет пару вопросов к участнику ваших проектов, и потом вместе
сделаем выводы, как вам помогают ваши знания управления проектами "строить" команды
CB>На мой взгляд, эти методологии похожи на попытки «переоткрытия» представителями индивидуалистской западной культуры принципов коллективизма, хорошо зарекомендовавших себя в России с прежних времен.
Хороший пост.
Полностью разделяю твои взгляды.
Всегда говорю народу, что это наши техники, которые попали на запад и отшлифованы в Германии. Затем попали в Америку, обросли торговыми марками. И потом мы их купили
Здравствуйте, denis miller, Вы писали:
CB>>На мой взгляд, эти методологии похожи на попытки «переоткрытия» представителями индивидуалистской западной культуры принципов коллективизма, хорошо зарекомендовавших себя в России с прежних времен. DM>Хороший пост.
DM>Полностью разделяю твои взгляды.
DM>Всегда говорю народу, что это наши техники, которые попали на запад и отшлифованы в Германии. Затем попали в Америку, обросли торговыми марками. И потом мы их купили
P>Также если я не ошибаюсь то Agile не говорит о том самоорганизованная команда или нет. Основной тезис Agile как мне представляется : P> — снизить риск неверной интерпретации требований заказчика за счет частого выпуска промежуточных релизов и демонстрации заказчику. P>А кто уж будет там профи или не профи заниматься непосредственно разработкой это не самое главное, если четко описаны процессы то там и индусы смогут работать. P>Тут я могу заблуждаться ( с Agile знаком поверхностно ) — поправьте или дополните.
Основной тезис Agile — сделать качественное ПО Остальное лишь частности.
И он не противоречит другим практикам, которые существуют в мире. В том числе есть ветви Agile, где ряд классических практик XP вообще отменяются в связи со спецификой проекта.
А теперь чуток формальных слов. Можно характеризовать любой процесс (это одна из моделей описания) по двум параметрам
1) defined или empirical process
2) plan-driven или value/vision-driven
Комбинация этих двух параметров даёт разные варианты
Вариант 1. Defined plan-driven
Его чаще называют классическим (не вотерфольным — предлагаю это слово выкинуть из обсуждения, так как это книжный раритет, все современные подходы итерационны даже на Agile-подходы)
Вариант 2. Defined value-driven
Вариант 3. Empirical plan-driven
Вариант 4. Empirical value-driven
Agile подход максимизировал вариант 4. Если Emperical — то помаксимому (вспомните третий вопрос в Scrum, burndown диаграммы и т.п.). Если Value-driven то тоже максимально (клиент в команде, разработчики ориентируются на бизнес и т.п.)
DM>>Всегда говорю народу, что это наши техники, которые попали на запад и отшлифованы в Германии. Затем попали в Америку, обросли торговыми марками. И потом мы их купили CB>И теперь продаете их на нам... CB>
Пжди, я тебе их не продаю. Здесь я лишь обращаю внимание. А каждый из нас уже сам может с этим разобраться. Но если нужно разобраться быстро и большому количеству народу — тогда я могу помочь, как за денежку, так и просто так Да и деньгу просто обязывают брать. Ведь мотивация к внедрению у халявы меньше :D
Чуток внимания. Я рекламировал полезность создания эффективных команд для достижения бизнес-целей.
А Agile так... лишь средство достижения, можно использовать и лидеров и CMI — это тоже хорошо. Но практика согласитесь говорит о другом
ЗЫ. Кстати, мне известен проект, там всё было цивильно, CMMI и все дела, и харизматичный лидер, и зарплаты достойный, нанимали только профессионалов, в общем всё было. Но вот проект 4 года не выходил в продакшн. Маленькой вещи не хватило. Того самого человеческого фактора, который объединившись организует эффективную команду. Жизнь очень многогранна, а команды должна взращиваться. В таких командах не нужны лидеры, там нужны супер-лидеры (это те которые не вмешиваются).
Здравствуйте, denis miller, Вы писали:
DM>Факты о которых я упоминал ищите в теории менеджмента.
Мои апплодисменты, Денис — какой прям по арабски коварный ход — пока изумленная общественность будет перерывать всю "теорию менеджмента" в поисках неупомянутых тобой фактов, сто процентов либо ишак сдохнет, либо халиф. Какой тонкий рассчет .
Помнится, в ответ на что-то подобное я навсегда забанил тебя в своем ЖЖ. Давай, жми их!
DM>А давайте сделаем просто — я прийду к вам в гости. У меня DM>будет пару вопросов к участнику ваших проектов, и потом вместе DM>сделаем выводы, как вам помогают ваши знания управления проектами "строить" команды
Правильно, а если не проймет, так надо пригрозить в гости прийти, и на месте сделать далеко идущие выводы.
Только слыш, эта, этот сraft-browser тоже не так прост, ага. Я тут давеча его цельную книгу по человеческому фактору в разработке ПО рецензировал — по его просьбе. Так что ты аккуратнее в гостях, боюсь, как бы тебя там не порвали вместе с выводами на британский флаг.
Re[6]: Если вспомнить историю...
От:
Аноним
Дата:
02.10.08 20:05
Оценка:
Здравствуйте, denis miller, Вы писали:
DM>Чуток внимания. Я рекламировал полезность создания эффективных команд для достижения бизнес-целей.
DM>А Agile так... лишь средство достижения, можно использовать и лидеров и CMI — это тоже хорошо. Но практика согласитесь говорит о другом
DM>ЗЫ. Кстати, мне известен проект, там всё было цивильно, CMMI и все дела, и харизматичный лидер, и зарплаты достойный, нанимали только профессионалов, в общем всё было. Но вот проект 4 года не выходил в продакшн. Маленькой вещи не хватило. Того самого человеческого фактора, который объединившись организует эффективную команду. Жизнь очень многогранна, а команды должна взращиваться. В таких командах не нужны лидеры, там нужны супер-лидеры (это те которые не вмешиваются).
Денис
Как взращивать команду?
Косвенный вопрос — какая команда легче взращивается? Какая команда вообще невзращиваемая "по системе" agile?
Пример сферических команд в вакууме:
— все зеленые юниоры, ..близнецы
— все матерые профессионалы, близнецы
Несферический пример:
— два студента, два говнокодера, один сениор-профи (жена, 3 детей, на проект насрать -от звонка до звонка), один -примадонна
???
А>Денис А>Как взращивать команду? А>Косвенный вопрос — какая команда легче взращивается? Какая команда вообще невзращиваемая "по системе" agile? А>Пример сферических команд в вакууме: А>- все зеленые юниоры, ..близнецы А>- все матерые профессионалы, близнецы А>Несферический пример: А>- два студента, два говнокодера, один сениор-профи (жена, 3 детей, на проект насрать -от звонка до звонка), один -примадонна А>???
согласен. все эти методики неявно предполагают наличие готового к трудовому успеху боевого ресурса, который уже профессионален для решения задачи, его тока надо правильно рассадить по местам, как квартет в басне крылова.
типо все умные, только сообразить не могут как задачу эффективно решить. и тут приходит шустрый менеджер с своей агилой, и работа вскипает результатами.
когда на самом деле в реальной жизни, либо команда совершенно не квалифицированна, для решения данной задачи, либо настолько квалифицирована и сработана, что не нужен никакой агил.
DM>>А давайте сделаем просто — я прийду к вам в гости. G>Только слыш, эта, этот сraft-browser тоже не так прост, ага. Я тут давеча его цельную книгу по человеческому фактору в разработке ПО рецензировал — по его просьбе. Так что ты аккуратнее в гостях, боюсь, как бы тебя там не порвали вместе с выводами на британский флаг.
Ну так давай попробуем? Или слабо?
G>Мои апплодисменты, Денис — какой прям по арабски коварный ход — пока изумленная общественность будет перерывать всю "теорию менеджмента" в поисках неупомянутых тобой фактов, сто процентов либо ишак сдохнет, либо халиф. Какой тонкий рассчет .
Открою тебе страшную тайну — в книгах есть оглавление
А>Как взращивать команду? А>Косвенный вопрос — какая команда легче взращивается? Какая команда вообще невзращиваемая "по системе" agile?
Ответ простой: IQ + EQ.
Чуток развёрнутый. Чтобы взрастить тебе нужно знать:
1. Управление персоналом
2. Организационный менеджмент
3. Теория мотивация
4. Agile
Список написан без подготовки — поэтому ответ не слишком качественный.
И если ты готов начать разработку этого направления можно начать развитие этой темы а рамках Study Group.
M>согласен. все эти методики неявно предполагают наличие готового к трудовому успеху боевого ресурса, который уже профессионален для решения задачи, его тока надо правильно рассадить по местам, как квартет в басне крылова. M>типо все умные, только сообразить не могут как задачу эффективно решить. и тут приходит шустрый менеджер с своей агилой, и работа вскипает результатами. M>когда на самом деле в реальной жизни, либо команда совершенно не квалифицированна, для решения данной задачи, либо настолько квалифицирована и сработана, что не нужен никакой агил.
DM>3. Теория мотивация
Можно подробнее ?
А то я тут в обед за соседним столом был невольным свидетелем разговора менеджера с джуниором о мотивации в работе. Скупые слёзы умиления навёртывались у меня на глаза и падали в суп...
Здравствуйте, denis miller, Вы писали:
DM>>>А давайте сделаем просто — я прийду к вам в гости. G>>Только слыш, эта, этот сraft-browser тоже не так прост, ага. Я тут давеча его цельную книгу по человеческому фактору в разработке ПО рецензировал — по его просьбе. Так что ты аккуратнее в гостях, боюсь, как бы тебя там не порвали вместе с выводами на британский флаг.
DM>Ну так давай попробуем? Или слабо?
Я-то не против, я бы даже с удовольствием поприсутствовал, вопрос в том, "слабо" ли craft-brother-у .
G>>Мои апплодисменты, Денис — какой прям по арабски коварный ход — пока изумленная общественность будет перерывать всю "теорию менеджмента" в поисках неупомянутых тобой фактов, сто процентов либо ишак сдохнет, либо халиф. Какой тонкий рассчет .
DM>Открою тебе страшную тайну — в книгах есть оглавление
Хе, это уже секрет Полишенеля, это многие знают. Я тебе сейчас открою настоящую, реально страшную тайну, доступную лишь посвященным: у книг есть автор и название .
Здравствуйте, merk, Вы писали:
M>согласен. все эти методики неявно предполагают наличие...
Не существует никаких методик "построения команд". Денис вас обманывает. Том ДеМарко специально для непонятливых пишет в своем Peopleware — термин team building в корне ошибочен, более правильно сравнивать это с выращиванием растения. То есть, у вас есть десяток почти гарантированных способов загубить команду, и, если вы делаете все "правильно", то у вас есть надежда, что растение может бытьвырастет.
Здравствуйте, denis miller, Вы писали:
DM>А давайте всего лишь обратимся к мировому опыту. К мировым коллекциям лучших практик, которые уже проверены тысячами команд и не одним десятилетием. Просто обратимся к Agile...
Уважаемый Денис.
Можешь ли ты написать поподробнее о логической связи между Agile и "мировым коллекциям лучших практик"?
Не знаю, может у меня на заводе не лучшие практики — кому рублей пачку надо дать понюхать, кому леща треснуть на планерке а кого так вообще за шкирку у всех на глазах выгнать нах, чтоб другие дрожали. Ну есть конечно и доска подчета, премии за самые умные каменты к коду итд. Вообщем коллектив обычным темпом работает в кулаке у бригадиров, те как-везде шустрят под начальником цеха. Все как надо вроде... Но вот ты говоришь что такое управление неверно и, глядя на мировые коллекции, желательно обратиться к Агиле. Типо лидерство это грех, даешь волю в массы.
А вот как реально оценить, насколько мне выйдет эта перестройка — затраты и прибыли такскать. Читал кучу книжек (три), беседовал с вашим братом — продавцами энтого заморского чуда (на форумах) — внятного ответа не услышал. Типа: команда будет работать "эффективнее", вопрос на сколько? реальные цифры, проценты? оценка рисков? цифры, проценты? А если нашим архаровцам дать волю, где гарантия что они не начнуть творить беспредел? а если молодежь откажется стружку подметать а старики сядут козла забивать — а бригадиров нет? пока слышу ответы агилистов — только лозунги типа "один за всех..." — этого у нас навалом, еще от брежнева осталось — над каждым станком висит, а народу все равно леща надо давать время от времени. Человек же, не робот, по-хорошему не всегда понимает. А может поймет обратившись к агиле?
и еще общий вопрос: почему столько много рекламы ваших методологий? ведь хорошая вешь в рекламе не нуждается (почти.., может немного только, на начальной стадии. А в книжках пишут, что уже 12 лет как...)
M>>согласен. все эти методики неявно предполагают наличие... G>Не существует никаких методик "построения команд". Денис вас обманывает.
Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах.
Здравствуйте, Dog, Вы писали:
M>>>согласен. все эти методики неявно предполагают наличие... G>>Не существует никаких методик "построения команд". Денис вас обманывает. Dog>Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах.
Определенные _приемы_ наработаны в армии. Они опираются на то, что в "корпоративной" среде групповые поведенческие факторы в целом превалируют над личностными, как сейчас говорят специалисты по организационному поведению. Однако, _методики_, которая _гарантировала_ бы вам результат, нет и там. При одинаковой методике подготовки есть хорошие командиры, а есть плохие, и первых меньше чем вторых. Например, известно, что один из наиболее эффективных и сильно сплачивающих факторов — это совместная победа в трудной ситуации. Вперед, обеспечьте — всего-то ничего надо сделать .
Здравствуйте, Dog, Вы писали:
M>>>согласен. все эти методики неявно предполагают наличие... G>>Не существует никаких методик "построения команд". Денис вас обманывает. Dog>Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах.
"Фанатики могут победить. Но они не смогут удержать победу".
Примерно это сказал в поезде генерал Штирлицу в фильме 17 мгновений весны. Фильм, кстати, рекомендуется к просмотру менеджерам в качестве пособия по корпоративным интригам .
Dog>>Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах. G>"Фанатики могут победить. Но они не смогут удержать победу".
2000 лет это долгий срок ?
Dog>>Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах. G>Определенные _приемы_ наработаны в армии. Они опираются на то, что в "корпоративной" среде групповые поведенческие факторы в целом превалируют над личностными, как сейчас говорят специалисты по организационному поведению. Однако, _методики_, которая _гарантировала_ бы вам результат, нет и там.
Мне кажется, чтобы эффективно работала такая комманда(боевая единица) ей постоянно нужны трудности(враг), которые надо преодолевать(которого надо побеждать). В случае с сектой, вам нужен лишь хороший командир.
G>При одинаковой методике подготовки есть хорошие командиры, а есть плохие, и первых меньше чем вторых. Например, известно, что один из наиболее эффективных и сильно сплачивающих факторов — это совместная победа в трудной ситуации. Вперед, обеспечьте — всего-то ничего надо сделать .
Вот.
Dog пишет:
> А то я тут в обед за соседним столом был невольным свидетелем разговора > менеджера с джуниором о мотивации в работе. Скупые слёзы умиления > навёртывались у меня на глаза и падали в суп...
а вот я бы не стал портить своему подчиненному аппетит и тратить его
личное время на промывание мозгов...
РД>а вот я бы не стал портить своему подчиненному аппетит и тратить его РД>личное время на промывание мозгов...
Когда вы ещё можете заставить подчинённого смотреть вам рот, как не за обедом ?
Здравствуйте, Dog, Вы писали:
Dog>>>Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах. G>>"Фанатики могут победить. Но они не смогут удержать победу". Dog>2000 лет это долгий срок ?
Dog>>>>Думаю что существует и очень давно. Смотеть надо в сторону методик использующихся в деструктивных сектах. G>>>"Фанатики могут победить. Но они не смогут удержать победу". Dog>>2000 лет это долгий срок ? G>А кого они победили?
... эээ ... разум ?!
Здравствуйте, cccp_paketa, Вы писали:
_>Здравствуйте, denis miller, Вы писали:
DM>>А давайте всего лишь обратимся к мировому опыту. К мировым коллекциям лучших практик, которые уже проверены тысячами команд и не одним десятилетием. Просто обратимся к Agile...
_>Уважаемый Денис. _>Можешь ли ты написать поподробнее о логической связи между Agile и "мировым коллекциям лучших практик"?
_>Не знаю, может у меня на заводе не лучшие практики — кому рублей пачку надо дать понюхать, кому леща треснуть на планерке а кого так вообще за шкирку у всех на глазах выгнать нах, чтоб другие дрожали. Ну есть конечно и доска подчета, премии за самые умные каменты к коду итд. Вообщем коллектив обычным темпом работает в кулаке у бригадиров, те как-везде шустрят под начальником цеха. Все как надо вроде... Но вот ты говоришь что такое управление неверно и, глядя на мировые коллекции, желательно обратиться к Агиле. Типо лидерство это грех, даешь волю в массы. _>А вот как реально оценить, насколько мне выйдет эта перестройка — затраты и прибыли такскать. Читал кучу книжек (три), беседовал с вашим братом — продавцами энтого заморского чуда (на форумах) — внятного ответа не услышал. Типа: команда будет работать "эффективнее", вопрос на сколько? реальные цифры, проценты? оценка рисков? цифры, проценты? А если нашим архаровцам дать волю, где гарантия что они не начнуть творить беспредел? а если молодежь откажется стружку подметать а старики сядут козла забивать — а бригадиров нет? пока слышу ответы агилистов — только лозунги типа "один за всех..." — этого у нас навалом, еще от брежнева осталось — над каждым станком висит, а народу все равно леща надо давать время от времени. Человек же, не робот, по-хорошему не всегда понимает. А может поймет обратившись к агиле?
_>и еще общий вопрос: почему столько много рекламы ваших методологий? ведь хорошая вешь в рекламе не нуждается (почти.., может немного только, на начальной стадии. А в книжках пишут, что уже 12 лет как...)
У меня допустим, недавно возник вопрос к скраму.
Допустим, есть проект, в котром ~30% говнотасков. Соответственно, либо после каждого стендапа остаются говнотаски, которые делать никто не хочет, либо, за счет высокой мотивации и сплоченности команды, они таки разбираются и все идет хорошо.
Вопрос первый.
Что делать, когда таки они остаются и ими никто не хочет заниматься?
Вопрос второй.
Допустим, что команда высокомотивирована и сплочена, говнотаски растаскиваются. Но откуда взять такую команду? Вы много видели таких команд? Высокая мотивация обычное дело у нас в индустрии? Кто команду сбивать будет? А что делать, когда она еще не сбита?
Здравствуйте, Константин Л., Вы писали:
КЛ>Что делать, когда таки они остаются и ими никто не хочет заниматься?
Например, поставить им приоритет повыше и ввести правило, что задания с высоким приоритетом всегда забираются первыми. Т.е. нельзя взять таску с нормальным приоритетом, если висит "говнотаска" с высоким.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Константин Л., Вы писали:
КЛ>>У меня допустим, недавно возник вопрос к скраму.
B>Фиг знает что скажут апологеты скрама, B>но если перестать называть задания "говнотасками", то это немного поможет.
B>Используя лексикон типа "говнотаски и быдлокодер", B>практически невозможно мотивировать нормальных людей.
ну это для внутреннего использования так скажем . на стендапе они будут "интереснейшими задачами" .
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Константин Л., Вы писали:
КЛ>>Что делать, когда таки они остаются и ими никто не хочет заниматься? O>Например, поставить им приоритет повыше и ввести правило, что задания с высоким приоритетом всегда забираются первыми. Т.е. нельзя взять таску с нормальным приоритетом, если висит "говнотаска" с высоким.
это, по сути, означает отказ от выбора задач, что, по-моему, немного противоречит скраму. Жеребьевка?
Здравствуйте, Константин Л., Вы писали:
КЛ>>>Что делать, когда таки они остаются и ими никто не хочет заниматься? O>>Например, поставить им приоритет повыше и ввести правило, что задания с высоким приоритетом всегда забираются первыми. Т.е. нельзя взять таску с нормальным приоритетом, если висит "говнотаска" с высоким.
КЛ>это, по сути, означает отказ от выбора задач, что, по-моему, немного противоречит скраму. Жеребьевка?
Да, это, по сути, означает отказ от бардака и первый шаг к осознанному управлению рисками и приоритетами, т.е. к организованной разработке. Если это проявление здравого смысла противоречит скраму, то я бы предложил отправить скрам в топку.
Здравствуйте, denis miller, Вы писали:
DM>ЗЫ. Кстати, мне известен проект, там всё было цивильно, CMMI и все дела, и харизматичный лидер, и зарплаты достойный, нанимали только профессионалов, в общем всё было. Но вот проект 4 года не выходил в продакшн. Маленькой вещи не хватило. Того самого человеческого фактора, который объединившись организует эффективную команду. Жизнь очень многогранна, а команды должна взращиваться. В таких командах не нужны лидеры, там нужны супер-лидеры (это те которые не вмешиваются).
По моему мнению наличие такого проекта ни о чем не говорит, так же как и если бы этот проект вышел в продакшн через год. Вообще делать выводы из результатов одного проекта, даже если он будет супер-пупер весь из себя и к месту, бессмысленно. Или приводите довольно большую выборку из 1 000 или 1 000 000 проектов, тогда будет о чем поговорить и обсудить. А ещё лучше статистику по всем проектам, которые когда либо были, вот это действительно будет интересно ! А так почти каждый сможет привести по одному проекту подкрепляющему свою точку зрения.
Здравствуйте, merk, Вы писали:
M>согласен. все эти методики неявно предполагают наличие готового к трудовому успеху боевого ресурса, который уже профессионален для решения задачи, его тока надо правильно рассадить по местам, как квартет в басне крылова. M>типо все умные, только сообразить не могут как задачу эффективно решить. и тут приходит шустрый менеджер с своей агилой, и работа вскипает результатами.
Поддерживаю. Думая о коллективах, в которых довелось работать, приходит мысль, что Ajile подходы в принципе имеет право на существование, но требования к участникам проекта в этом случае будут значительно выше, чем если бы это был Non-Agile подход. При применения гибких методологий очень большую роль начинает играть сознательность/ответственность членов команды. Просто так взять 5-7 человек и начать работать по Agile методике, по моему, незначительно повысит вероятность успешного завершения проекта, по сравнению с тем, если бы они вообще никакой методики не использовали и просто работали опираясь на свой опыт и здравый смысл. А если посмотреть на программистов, которых я видел, то значительная их часть (скажем честно, большая часть, но надеюсь что это только мой такой неудачный опыт) без наличия за спиной "человека с палкой" вообще работать в полную силу не будет Наибольшее зло, которое приносит Agile методика в команду — это частичка свободы, и не всякая команда сможет осилить эту свободу и не перейти на "тёмную" сторону А так если уже есть базис/структура, налажена обратная связь с командой на поддержание духа ответственности в команде, и т.д. , то можно что-то и из Agile методик взять. Моё мнение такое чистого Agile в природе не существует, существует Agile поверх Non-Agile
CB>Если вспомнить историю, то для российского менталитета командная работа достаточно привычный вид коллективной деятельности. С XIII века в России существовали производственные артели — различные формы добровольных объединений людей с целью осуществления общей хозяйственной деятельности. Например, артели плотников, лесорубов, рыболовов, земледельцев и др. Русская рабочая артель являлась одним из устоев народной жизни. Она была добровольным товариществом совершенно равноправных работников, призванных на основе взаимопомощи и взаимовыручки решать практически любые хозяйственные и производственные задачи. Равноправием артели резко отличались от капиталистических предприятий. Равноправие, конечно, не означало уравниловки — распределение дохода осуществлялось по труду.
КЛ>У меня допустим, недавно возник вопрос к скраму.
КЛ>Допустим, есть проект, в котром ~30% говнотасков. Соответственно, либо после каждого стендапа остаются говнотаски, которые делать никто не хочет, либо, за счет высокой мотивации и сплоченности команды, они таки разбираются и все идет хорошо.
КЛ>Вопрос первый.
КЛ>Что делать, когда таки они остаются и ими никто не хочет заниматься?
ну это просто: рано или поздно интересные задачи будут сделаны и выбора не будет, надо будет таки кому-то (юниорам? ) приступать к говнотаскам.
КЛ>Вопрос второй.
КЛ>Допустим, что команда высокомотивирована и сплочена, говнотаски растаскиваются. Но откуда взять такую команду? Вы много видели таких команд? Высокая мотивация обычное дело у нас в индустрии? Кто команду сбивать будет? А что делать, когда она еще не сбита?
если провести параллель развития общества с коллективом программистов (см. http://ru.wikipedia.org — "Исторический материализм" ) то агилисты стремятся к модели "Коммунизм":
"Коммунизм. Теоретическое (никогда не существовавшее на практике) идеальное устройство общества, которое должно прийти на смену капитализму. При коммунизме все средства производства находятся в общественной собственности, частная собственность полностью устранена. Труд имеет всеобщий характер, классовое разделение отсутствует. Предполагается, что человек трудится сознательно, стремясь принести обществу наибольшую пользу и не нуждаясь во внешних стимулах, таких как экономическое принуждение. При этом общество предоставляет любые доступные блага каждому человеку. Таким образом, реализуется принцип: «От каждого — по способности, каждому — по потребности». Товарно-денежные отношения упраздняются. Идеология коммунизма поощряет коллективизм и предполагает добровольное признание каждым членом общества приоритета общественных интересов перед личными. Власть осуществляется всем обществом в целом, на основе самоуправления. В качестве общественно-экономической формации, переходной от капитализма к коммунизму, рассматривается социализм, при котором происходит обобществление средств производства, но сохраняются товарно-денежные отношения, экономическое принуждение к труду и ряд других особенностей, характерных для капиталистического общества. При социализме реализуется принцип: «От каждого — по способности, каждому — по труду».
Исторический материализм считает, что социальное развитие человечества в принципе конечно — за коммунизмом не последует никакой другой общественно-экономической формации. С другой стороны, если принять, что коммунизм — это недостижимый идеал, то общественное развитие есть не что иное, как бесконечное последовательное приближение к этому идеалу."
На практике, при несоблюдении всех рекомендаций агилистов, есть риск что скрам команда может оказатся далеко от "идеала" — очень близко к Первобытно-общинному строю:
"Уровень экономического развития крайне низкий, используемые орудия примитивны, поэтому нет возможности производства прибавочного продукта. Классовое разделение отсутствует. Средства производства находятся в общественной собственности. Труд имеет всеобщий характер, собственность — только коллективная. На поздних этапах существования первобытного общества уровень производства позволил создавать прибавочный продукт, что привело к появлению частной собственности, имущественного неравенства, товарно-денежных отношений, и обусловило переход к рабовладению, быдлокодерству и появлению индусов"
Так что за ответами на вопрос "как вырастить сферическую команду в вакууме" вам надо обратится к кирпичам Маркса, Энгельса, бревну Ленина или в http://agileconsulting.ru
Столько много интересно пошите. Когда вы работаете
То о чём я говорю, это вариант который работает — хотите верьте, хотете нет. Это неважно. Важно то, что вы оцениваете послухам. Agile-команды оценивают только после того как попробуют. Но есть другие — как ваши, где хорошим тоном является пожурить джуниора, надавать наставлений обормотам программерам, которые всё факапят. А любимцам подкидывать бабла — тоже стартегия. А если вы её придерживаетесь, значит она реализует какую-то вашу потребность.
Оценивать можно только после того как вы это делали, а иначе пустой трёп. Жаль, что у вас на него столько сил уходит.
А так прикольно почитать ваши отзывы. Всегда думал, как народ пишет книги. Теперь понятно — развенчивая вот такие высказывания, что на форуме.
Хотя находятся и те, кто покупает книги составленные только из таких высказываний :D
Можно не отвечать, в ближайшее время книгу не собираюсь писать :D
Re[5]: про скрам
От:
Аноним
Дата:
07.12.08 09:45
Оценка:
Здравствуйте, denis miller, Вы писали:
DM>Столько много интересно пошите. Когда вы работаете
Здравствуйте, denis miller, Вы писали:
DM>Столько много интересно пошите. Когда вы работаете
DM>То о чём я говорю, это вариант который работает — хотите верьте, хотете нет. Это неважно. Важно то, что вы оцениваете послухам. Agile-команды оценивают только после того как попробуют. Но есть другие — как ваши, где хорошим тоном является пожурить джуниора, надавать наставлений обормотам программерам, которые всё факапят. А любимцам подкидывать бабла — тоже стартегия. А если вы её придерживаетесь, значит она реализует какую-то вашу потребность. DM>Оценивать можно только после того как вы это делали, а иначе пустой трёп. Жаль, что у вас на него столько сил уходит.
DM>А так прикольно почитать ваши отзывы. Всегда думал, как народ пишет книги. Теперь понятно — развенчивая вот такие высказывания, что на форуме. DM>Хотя находятся и те, кто покупает книги составленные только из таких высказываний :D
DM>Можно не отвечать, в ближайшее время книгу не собираюсь писать :D
работаю в основном в дневную смену. Пишу по вечерам, очень мало, только о том, о чем есть теоретические знания и практический опыт.
Писать книги — хорошая мысль! Спасибо за идею. Может даже про агиле напишу. Золотая жила! Еще и ваши же ученики-наследники ее продавать будут
! А так почти каждый сможет привести по одному проекту подкрепляющему свою точку зрения.
Наибольшее зло, которое приносит Agile методика в команду — это частичка свободы, и не всякая команда сможет осилить эту свободу и не перейти на "тёмную" сторону 