Странно видеть на форумах воинствующих проповедников анти-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>когда на самом деле в реальной жизни, либо команда совершенно не квалифицированна, для решения данной задачи, либо настолько квалифицирована и сработана, что не нужен никакой агил.
