По Коуберну — нужно менять методологию при каждом переходе из клетки в клетку и тут я с ним полностью согласен: начало проекта втроем и развитие проекта в команде из 20 человек — очень разные вещи, требующие сильно разных подходов и методологий.
Так что менять методологию придется. Но так как рост заранее понятен — то можно к нему готовиться и делать переход максимально «гладким». А вот как именно расти — сильно зависит от людей и проекта.
Вообще процесс разделения одной команды на несколько — очень опасная штука, так как начинается (если специально с этим не бороться) соревнование между командами, спонтанное разделение на «нас» и «их». Может быть для группы в 20 человек не делить на отдельные команды, а просто потихоньку разным членам команды давать одного-двух человек в «ведомых». Тогда вместо 3-4 команд получится одна команда из 7-8 «звеньев», но при этом воспринимающая себя как нечто более «целостное».
Но все зависит, конечно, от конкретных целей и конкретных людей.
3. Про «конструктор».
Я не очень верю в «конструктор», больше в набор «шаблонов» с границами применимости и рекомендациями по внедрению. И воспитанию здравого смысла.
Конструктор очень быстро превратиться в еще один «карго-культ», как в него уже превращают и разнообразные agile-методики (которые, конечно, изначально были вполне здравыми). Карго-культ проще продавать, а в конечном итоге решает именно это.
А вот просто набор шаблонов продавать сложнее — из design patterns так и не сделали, к счастью, методики (хотя карго-культом до сих пор попахивает, но не слишком сильно), так что есть шансы.
2. Про «взрослые» и «аджайл» методологии. Вообще, и те и другие пришли сверху, отнюдь не из «девелоперской» среды. Просто они отвечают разным наборам страхов (тяжелые — потеря управляемости и выхода за границы бюджета, легкие — увеличения time-to-market и «сделать не то»).
Но да, и те и другие не пригодны для конкретного проекта, нужно делать что-то свое. Про что и доклад )
Буду отвечать по пунктам, а то слишком сложно уже ориентироваться в большом тексте.
1. «Большинство методологий ничего не стоят». Это не так. Стоимость внедрения методологии, стоимость реализации ритуалов методологии, стоимость подготовки артефактов, стоимость поиска кадров — все это очень заметные расходы. Для некоторых методологий еще и требуется проведение пилотных проектов (RUP, например), что только увеличивает их стоимость. На этом фоне стоимость консультантов или специального софта уже совершенно незначительна.
Хм, возможно я просто не в курсе. А есть какие-то научные работы по менеджменту? Соответствующие критериям Поппера? Или что вы имеете в виду под «теоретическими достижениями в управлении»? Лучшее, что я видел — это была не слишком корректная статистика, хотя приходится опираться на нее, конечно.
Спасибо за ответ.
Одна из важных для меня мыслей, которую я и пытался передать в докладе: четкие, системные, упорядоченные методологии обычно и/или очень дорогие или не решают именно ваших задач. Так как применять любые чужие методологии не понимая «почему» и «зачем» — это решать не свои задачи, а чужие. CMMI как раз хороший пример, соответствие стандарту ни как не соотносится ни с эффективностью компании, ни с качеством ее продуктов (по крайней мере положительной корреляции я не видел, возможно есть отрицательная). Кстати, вопрос «какие именно цели должен решать CMMI» весьма неочевиден, я вот не знаю ответа (ну, кроме зарабатывания денег компанией-создателем).
И как раз «под каждый процесс что-то внедрить» — это одна из самых опасных вещей, которые могут произойти, карго-культ как он есть.
Так что хорошо, что в моем докладе не получилось найти «методологию» в вашем понимании, что никто не собирается внедрять указанные там практики или подходы просто потому, что так написано. Это было бы для меня худшим результатом.
P.S. Увы, мне очень сложно всерьез говорить о «теоретических достижениях в управлении», хотя я знаю, что по этой теме даже реферируемые журналы выпускают и отнюдь не по кибернетике. Я все-таки слишком инженер.
Вот собственно про движение от 722 и близких к нему к текущему Лего я и говорю. Когда вместо единообразия универсальных деталей появились гораздо более узко специализированные конструкторы с мелкими, но специфическими деталями. Когда появилось много узких линеек.
И про то, насколько разный инженерный подход стоит за старым и новым Лего )
А насколько разнообразие в деталях повлияло на фантазию — не знаю, у меня нет статистики. Но вообще сомневаюсь )
В основном классика: Брукс, ДиМарко+Листер.
Коуберн — в основном старые переведенные статьи («Каждому проекту — свою методологию», «Люди как нелинейные и самые важные ...». К сожалению, его сайт сейчас в длительном периоде реконструкции.
Бек — да, описание XP.
Нет, конечно.
Но из одного произвольного набора собрать 20 разных игрушек уже не получается. Каких-то аналогов вполне обычному 722му уже нет. Конечно, из большой группы разных конструкторов можно собрать очень много всего нового (и статья, кстати, и про это).
Но если купить в магазине один произвольный конструктор, то количество возможностей будет заметно меньше, чем купив один конструктор лет 25 назад. Но смотреться результат будет симпатичнее.
КДПВ вообще не моя, если честно. На слайдах или в видео видны оригинальные картинки, там официальные наборы.
Но, оффтопика ради, наборов лего вида «600 деталей и можно собрать 20 разных игрушек» я очень давно не видел, с собственного детства. И тенденция к специализированным крупным блокам в лего очень заметна. И вот смотрю на набор игрушек, которые надарили моим детям родственики — там почти всюду одна-две очень похожие модели. Конструкторы вида корабль/дом/самолет уже не делают.
Ну, надо подождать, пока JS догонит Java по списку имеющихся полезных новшеств — и тогда можно будет посмотреть, где что новое появится. Пока заметные новшества скорее сначала появляются в мире Java, а потом уже проникают на фронтенд (тот же Netty старше Ноды лет на пять, Future появился в стандартной библиотеке примерно тогда же, где раньше реактивщина появилась — сложно сказать).
Развитию JS сильно способствует мода переделывать фронтенд каждые год-два, в Java такое реже. Но новые проекты уже делают и функциональные и асинхронные (если это нужно) и довольно давно.
Ага, т.е. столько же, сколько у меня на персистентных акторах получалось (для решения примерно тех же задач).
Хотя пока мне кажется, что акторная модель для описания бизнес-транзакций более удобна. Ну и вместо блокировок можно использовать актор-на-блокируемый объект.
«Касаемо безопасности внутри защищённого периметра — спорно. Если к вам во внутреннюю сеть влезли враги, то у вас уже всё плохо и наличие/отсутствие ident там погоды не сделает.»
Тут все зависит от проекта. Если это соцсеточка, то можно надеяться на периметр, все равно безопасность никого не волнует. А вот если это финтех или приличный энтерпрайз, то уже неплохо бы защищаться и от собственных админов (и тут разделение паролей сильно помогает).
Теоретически — да. Но если в системе много разных сервисов и необходимо поддерживать работу с интерфейсами разных версий, то стандартная сериализация уже не очень удобна, так как в ней нет удобных механизмов разрешения конфликтов. Jackson тут заметно удобнее.
Так что менять методологию придется. Но так как рост заранее понятен — то можно к нему готовиться и делать переход максимально «гладким». А вот как именно расти — сильно зависит от людей и проекта.
Вообще процесс разделения одной команды на несколько — очень опасная штука, так как начинается (если специально с этим не бороться) соревнование между командами, спонтанное разделение на «нас» и «их». Может быть для группы в 20 человек не делить на отдельные команды, а просто потихоньку разным членам команды давать одного-двух человек в «ведомых». Тогда вместо 3-4 команд получится одна команда из 7-8 «звеньев», но при этом воспринимающая себя как нечто более «целостное».
Но все зависит, конечно, от конкретных целей и конкретных людей.
Я не очень верю в «конструктор», больше в набор «шаблонов» с границами применимости и рекомендациями по внедрению. И воспитанию здравого смысла.
Конструктор очень быстро превратиться в еще один «карго-культ», как в него уже превращают и разнообразные agile-методики (которые, конечно, изначально были вполне здравыми). Карго-культ проще продавать, а в конечном итоге решает именно это.
А вот просто набор шаблонов продавать сложнее — из design patterns так и не сделали, к счастью, методики (хотя карго-культом до сих пор попахивает, но не слишком сильно), так что есть шансы.
Но да, и те и другие не пригодны для конкретного проекта, нужно делать что-то свое. Про что и доклад )
1. «Большинство методологий ничего не стоят». Это не так. Стоимость внедрения методологии, стоимость реализации ритуалов методологии, стоимость подготовки артефактов, стоимость поиска кадров — все это очень заметные расходы. Для некоторых методологий еще и требуется проведение пилотных проектов (RUP, например), что только увеличивает их стоимость. На этом фоне стоимость консультантов или специального софта уже совершенно незначительна.
Одна из важных для меня мыслей, которую я и пытался передать в докладе: четкие, системные, упорядоченные методологии обычно и/или очень дорогие или не решают именно ваших задач. Так как применять любые чужие методологии не понимая «почему» и «зачем» — это решать не свои задачи, а чужие. CMMI как раз хороший пример, соответствие стандарту ни как не соотносится ни с эффективностью компании, ни с качеством ее продуктов (по крайней мере положительной корреляции я не видел, возможно есть отрицательная). Кстати, вопрос «какие именно цели должен решать CMMI» весьма неочевиден, я вот не знаю ответа (ну, кроме зарабатывания денег компанией-создателем).
И как раз «под каждый процесс что-то внедрить» — это одна из самых опасных вещей, которые могут произойти, карго-культ как он есть.
Так что хорошо, что в моем докладе не получилось найти «методологию» в вашем понимании, что никто не собирается внедрять указанные там практики или подходы просто потому, что так написано. Это было бы для меня худшим результатом.
P.S. Увы, мне очень сложно всерьез говорить о «теоретических достижениях в управлении», хотя я знаю, что по этой теме даже реферируемые журналы выпускают и отнюдь не по кибернетике. Я все-таки слишком инженер.
И про то, насколько разный инженерный подход стоит за старым и новым Лего )
А насколько разнообразие в деталях повлияло на фантазию — не знаю, у меня нет статистики. Но вообще сомневаюсь )
Коуберн — в основном старые переведенные статьи («Каждому проекту — свою методологию», «Люди как нелинейные и самые важные ...». К сожалению, его сайт сейчас в длительном периоде реконструкции.
Бек — да, описание XP.
Но из одного произвольного набора собрать 20 разных игрушек уже не получается. Каких-то аналогов вполне обычному 722му уже нет. Конечно, из большой группы разных конструкторов можно собрать очень много всего нового (и статья, кстати, и про это).
Но если купить в магазине один произвольный конструктор, то количество возможностей будет заметно меньше, чем купив один конструктор лет 25 назад. Но смотреться результат будет симпатичнее.
Но, оффтопика ради, наборов лего вида «600 деталей и можно собрать 20 разных игрушек» я очень давно не видел, с собственного детства. И тенденция к специализированным крупным блокам в лего очень заметна. И вот смотрю на набор игрушек, которые надарили моим детям родственики — там почти всюду одна-две очень похожие модели. Конструкторы вида корабль/дом/самолет уже не делают.
И вроде бы там «папа» уже сменился.
Развитию JS сильно способствует мода переделывать фронтенд каждые год-два, в Java такое реже. Но новые проекты уже делают и функциональные и асинхронные (если это нужно) и довольно давно.
Хотя пока мне кажется, что акторная модель для описания бизнес-транзакций более удобна. Ну и вместо блокировок можно использовать актор-на-блокируемый объект.
Тут все зависит от проекта. Если это соцсеточка, то можно надеяться на периметр, все равно безопасность никого не волнует. А вот если это финтех или приличный энтерпрайз, то уже неплохо бы защищаться и от собственных админов (и тут разделение паролей сильно помогает).
Просто и очень удобно.