TemplarПро самоуправляемость в коллективе размером до 10 человек независимо от Agile-" наживулька " это или нет, я слышал давно. Личной практикой тоже подтверждено.
Видимо, эту цифру можно вывести из функции временных затрaт на коммуникации от числа членов команды.
Вот пример, статья 11-летней давности, а проект еще старше.
См. главку "Организация работы" .
Действительно, команда числом до 10-12 человек самоорганизуется, как правило, без проблем. При большем количестве людей это сделать несколько труднее, но все равно можно. Тут многое зависит от уровня подготовленности участников к командной работе и мастерства PMa - от него как от организатора жизненного пространства команды очень многое зависит.

В приведенной статье мое внимание привлекла вот эта цитата:

Разработчики системы решили ограничиться небольшой (до 10 человек) группой профессионалов...Такая группа является самоорганизующейся и методами проб и ошибок , как показывает опыт, выдает нужный результат

Понятно, что статье 11+ лет (я даже ее помню :)) и тогда многое делали методом проб и ошибок. Сейчас в этом нет необходимости - практики Agile командной работы очень хорошо помогают в построении команды.

TemplarСамое приятное, что в статье никто не употребляет "страшных слов" и прочей религиозно-манипулятивной атрибутики :)
Кстати, "стейкхолдеры" по-русски, это "заинтерсованные лица".
Ну что ж проверим слова "наживулька" и "стейкхолдер" на соответствие русскому языку :)
Яндекс находит слово "наживулька" на 179 страницах, Гугл - 163 вхождения
"Стейкхолдер" находится Яндексом на 13 722 страницах, Гугл - 442 вхождения
Википедия содержит определение слова "стейкхолдер", "наживулька" там отсутствует.

Исходя из этого, какое слово является более русским? :)

nibblesА вот подбор ложных (заведомо?) аналогий очень многое говорит о методах убеждения, которыми пользуется группа энтузиастов новой революционной парадигмы управления...
Вы меня еще в геноциде обвините :)

nibblesP.S. Кстати, таки хотелось бы услышать от популяризаторов основные характеристики, по которым супер-дрим-тим отличается от "динозавров" менеджмента... этот вопрос так и остался без ответа... ну, кроме намека на супер-производительность дрим-тим, конечно.
Основной признак команды-мечты - это способность достигать цели там, где остальные команды (или отдельные люди) пасуют. Чтобы было еще понятнее, приведу два примера команды-мечты из мира спорта:

Баскетбольная сборная СССР 1972 года, которая на Олимпиаде в Мюнхене выиграла золото у американцев, вырвав решающее очко за одну секунду до окончания игрового времени

Олимпийская сборная СССР 1988 года, которая на Олимпиаде в Сеуле выиграла финал у бразильцев со счетом 1:0

Мы, кстати, встречались с игроками и той, и другой команды. Прошло уже много лет, а победители по-прежнему выделяются среди остальных людей

Сергей Васкецов byurОбычно врач не берется диагностировать дистанционно (знаю не по наслышке). Тех кто берется диагностировать по косвенным признакам, "со слов", по фотографии, по ауре ... ну вы поняли :-).
Я не врач, поэтому весь Ваш тезис мгновенно рассыпается. Тем не менее, думате как хотите. Можете считать, что данных у меня достаточно, ибо у меня нет оснований считать, что оппонент думает и пишет здесь разные вещи. А можете считать, что я сам себе свой диагноз подтвердил, рискнув вступить в полемику с суперпионером из дримтим с завышенным самомнением, считающим, что он сделал суперпроект за счет суперускорения в ущерб документированности. Если пока везение сопутствует и такие проекты попадаются - слава богу. Изначально я в теме просил привести в пример немного другого собеседника (точнее, имеющего опыт реализации куда более сложных и ответственных проектов).
Сергей, мне так везет уже последние 5+ лет, что я управляю проектами. И результаты этих проектов проверяются рынком. Везде: от Японии до Калифорнии.

А до этого мне везло на то, что черты и подсистемы, которые я реализовывал, получались работоспособными, быстрыми, со стройной архитектурой, и юзабельными. А знаете, почему везло? Потому что я вкладывался в свою работу на 100+ процентов, постоянно искал лучшие способы реализации и организации софта.

А о (не)сложности проектов Вы по чему судите? По тому, что я живо пишу в своих постах, а не напоминаю своими текстами сушеную воблу? Так это результат тренировки - никогда не терять тонуса, всегда радоваться жизни и тому, что ты сам способен устроить свою жизнь, принимать вызовы судьбы и склонять ее в свою пользу. И проект мы сделали не за счет суперускорения в ущерб документированности, а за счет того, что изначально выставили себе высокие планки и сумели достигнуть их.

Попробуйте сделать годовой проект в компании, которая стоит на паблике, и акции которой в дауне, которую вечно пинают аналитики с Уолл-стрита и требуют снижения расходов. Попробуйте пережить с командой за это время два лейоффа и не потерять ни одного человека.

Попробуйте заменить рассыпающийся фундамент в многоэтажном доме так, чтобы этот дом не рухнул и в доме можно было надстроить еще этажей.

С удовольствием узнаю о вашем опыте выполнения сложных и ответственных проектов (Другого собеседника, видите ли, он просил...Не будет Вам другого собеседника! :))

AlexTheRaven Павел АфанасенкоВообще-то Agile подразумевает постоянство скорости разработки. От команды нельзя требовать большего, чем она потенциально может сделать. Иначе случается то, что случилось с вашей знакомой командой - команда ломается.
Вы это понимаете, я понимаю, а вот project owner - не всегда понимает. Он в России весь в малинововом пиджаке, типа платит деньги и считает себя выше всяких правил. Поэтому IMHO нужна фиксация хотя бы границ системы, и нужен весьма жёсткий человек, у которого будут права спорить с project owner'ом и отвергать те пользовательские истории, которые не укладываются в границы системы.
AlexTheRavenВ том-то и дело, что в том SCRUMе было всё, кроме самого главного - того, что все играют по одним, заранее установленным правилам. Даже тот, кто платит деньги.
Ну так, наверное, это был не SCRUM? :) От того, что сто раз скажешь слово "халва", во рту слаще не станет. Agile методологии на самом деле очень строгие - если делать нарушения, то все накрывается. И дело здесь не в жестком РМе - там есть и другие роли. Просто каждый в этой игре должен играть в свою роль по определенным правилам. Тогда все получается.

Templar Павел АфанасенкоНу что ж проверим слова "наживулька" и "стейкхолдер" на соответствие русскому языку :)
Яндекс находит слово "наживулька" на 179 страницах, Гугл - 163 вхождения
"Стейкхолдер" находится Яндексом на 13 722 страницах, Гугл - 442 вхождения
Википедия содержит определение слова "стейкхолдер", "наживулька" там отсутствует.
Результаты поиска слова "гугл" в яндексе и "яндекс" в гугле еще более впечатляющи :)

Исходя из этого, какое слово является более русским? :)
Исходя из этого можно сказать, что вы некомпетентны в вопросах языкознания :)
Мда...я ожидал какого угодно ответа на мой шуточный пост, но вот такого, если честно, не оидал

nibbles Павел АфанасенкоОсновной признак команды-мечты - это способность достигать цели там, где остальные команды (или отдельные люди) пасуют.

ДО достижения какого-либо результата можно сказать, что рассматриваемая команда является "командой-мечтой"? Да/Нет
Команда становится "командой-мечтой" как раз по достижении такого сверхрезультата. При этом у участников команды от факта достижения цели повышается самооценка, команда ставит еще более высокие планки и достигает их. И так далее. Получается такая положительная обратная связь.

Еще один, может быть, нестандартный пример "команды-мечты" - это Красная/Советская Армия времен второй мировой войны. После разгрома Германии Советская Армия была настолько мощна, что ей понадобилось меньше месяца, чтобы разгромить миллионную Квантунскую армию на Дальнем Востоке. Конечно, за 4+ года войска научились воевать. Но еще более важным было то, что Советская Армия научилась побеждать, появился дух победителя.

Именно дух победителя отличает команду-мечту. Но без результатов этого духа не появляется

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

iscrafm...Более менее крупный ERP-проект без документирования, интеграция нескольких систем, управление качеством.... легко как "Hello, world" ...
Насколько я понимаю, большую часть ERP-проектов занимает внедрение системы, передача знания заказчикам/пользователям. Конечно, в этом случае знания лучше передавать на бумаге.

Я повторюсь, мы в Agile не против документации. Когда она нужна, мы ее делаем. Но можем работать и без нее.

Да, вот еще. Гугл на запрос "Agile ERP" выдает 2 200 000 документов. И одна из первых найденных ссылок указывает на статью с говорящим названием: Agile Project Management Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and Live to Tell About It . Как вот так получается - весь мир применяет Agile в ERP, а в Киеве-Москве это считают нереальным?

iscrafmИнтересно наблюдать как разгорается , а потом тихо затухает подобный юношеский задор.
Интересно быть наблюдателем? Смотреть, как жизнь проходит мимо, когда другие люди штурмуют высоты в то время, как ты сидишь в уютном кресле с пледом и лениво комментируешь происходящее?

TemplarПавел, предлагаю завершить тему "космических кораблей, бороздящих просторы большого театра".
Вот конкретная ситуация.
Найдена некоторая рыночная ниша, в которой можно сделать малотиражный (10-100 клиентов) продукт. Система средней сложности (единицы десятков требований на уровне концепции). Внедрение потребует доработки/настройки под заказчика.
Что предлагаете на уровне организации процесса в общих чертах?
Сразу не отвечу, позадаю вопросы.
0. Про какой процесс Вы спрашиваете (разработки, кастомизации, внедрения, всего вместе)?
1. Откуда деньги на разработку?
2. Кто определяет, какой будет продукт?
3. Каковы затраты на кастомизацию под конкретного заказчика (в относительном времени от разработки всей системы)?
4. Означает ли внедрение только кастомизацию продукта или там еще есть адаптация бизнес-процессов, обучение пользователей, etc?