Спасибо. Интересно все, тем более в печатном варианте, который можно использовать в качестве учебного пособия. Благодаря мнению Асхата о госпроектах, по-другому увидел проблему с так называемыми "быстрыми проектами", когда за неделю реализуется крупный заказ. Со стороны обывателя это видится как очередной распил бюджетного бабла, а на самом деле здесь задействованы довольно сложные механизмы и взаимоотношения заказчика и исполнителя.
PS: В качестве предложения... сделайте ссылку "скачать текстовый файл", иначе приходится по-дедовски выделять, копировать, вставлять...
Первое, что нужно сделать сотруднику (особено ведущему), когда руководство начинает поговаривать об Аджайле — писать заявление о увольнении. Руководитель повелся на россказни коммивояжера волшебных таблеток для повышения удоев? Уходите немедленно, если не считаете себя быдлом. Сначала вас сравняют со вчерашними студентами по задачам (они вам будут рекомендовать, что выбирать нужно именно технологию X, так как вчера её на харбре "пасаны" посоветовали), затем и по окладу. Оставьте "гибкие" методологии для молодых, пусть работают за интерес. Пока не повзрослеют и семьей не обзаведутся.
Все это откровенное пустозвонство. Просьба честно помечать такие выпуски "на правах рекламы". А если у Максима таковые ещё и за бесплатно рекламируется — то я искренне недоумеваю.
1. Деньги.
2. Деньги.
3. Если менеджер не может оградить разработчиков от постоянного изменения функционала — дурак именно он. Дешевые и гнилые приемы не сработают — лично у меня каждый час запротоколирован и тыкнуть меня носом в сорванные сроки проблематично.
В хорошо настроенной команде молодые и неопытные будут перенимать опыт и расти очень быстро, да. Но это не значит, что гибкие методологии не подхотят для команды матерых девелоперов. Практика тому подтверждение.
Вообще среди опытной команды все практики гибких методологий воспринимаются хорошо. Они естественны и органичны, позволяют работать с меньшим стрессом и с лучшим резутьтатом.
Сейчас я врятли пойду в проект, где не понимают преимуществ того же SCRUM, например, и у продукта нет product owner :)
Представьте себе дядю, который вам может досконально расказать чем отличается технология версии XX.X.54 от XX.X.52. Чего ему обсуждать? И с кем? Ставь задачу, получай результат. Ну, а если задачи не расписаны ввиду отсутсвия денег на вменяемых менеджеров... то и делать там нечего.
Трепаться, собираться - это смешно, ей богу. Песочница какая-то.
Заметь, gumayunov, чуть выше описал преимущества для молодых. Характерно. Не наигрался ещё в игрушки, место работы по методологии выбирает (sic!).
Дело не в умении работать в команде. Дело в самоуважении.
Толку от этого объяснения если с этим дядей невозможно работать из за его ЧСВ? Знаем таких, да.
Но если с коммуникациями у дяди все окей - что мешает ему поучаствовать в планироваии в начале итерации, в демонстрации в конце и в ежедневном, скраме, длинной не более 15 мин? Что именно тут мешает его самоуважению?
Мы с вами с настолько далеких полюсов, что интересного диалога не получится. Жаль, мне на самом деле интересно понять что лежит в основе вашего мнения.
PS: Не шло речи о выборе работы по методологии, не стоит переиначивать.
Мне с вами совершенно не о чем разговаривать, юноша со взором горящим. 15 мин * 15 человек = наполовину убитый человекодень. В месяц вы теряете половину человекомесяца. Дешевый прием скормить слона по частям, не более.
Если вы клепаете хоумпаги, то ариведерчи, вам дяди с ЧСВ (именно так вы посмели презрительно обозвать многолетний опыт) и не нужны. А дядям не нужны вы, любители интересных методологий.
Выпуск я не слушал, не особо интересно, но ваш коментарий меня позабавил, спасибо =)
Поясните, пожалуйста, связь между методологией и окладом?
PS: уже лет 5 не считаю себя молодым разработчиком, но после перехода всей компании на SCRUM работается намного продуктивнее, а от этого интереснее и веселее.
Вы не представляете каких усилий мне стоило этот выпуск прослушать полностью!
Самая прямая связь. Отсутсвие узкой специализации и взаимозаменяемость ведут к вожделенной экономии на вашей заработной плате. Вы так и останетесь "специалистом по общим вопросам". Вас всегда и без проблем можно заменить. А специалисту платят соразмерно геморрою по поиску замены.
Может и веселее, не спорю. Работайте за интерес. Но без меня. Всего доброго.
Эдак можно докатиться до того, что будешь сидеть на своих ноу-хау и благодаря этому тянуть деньги. Это тупиковый путь.
Agile отнюдь не делает разработчика специалистом по общим вопросам. Специализация всегда будет из-за ограниченности человеческого мышления и различных способностей индивидов.
Любой футболист из команды может погонять мяч вместо любого другого, однако, кто то сильный нападающий, кто то отличный защитник.
SCRUM настраивая должным образом командную игру разработчиков и заказчика, вовсе не лишает специализации и не позволяет без потерь заменить одного ниндзя парой-тройкой студентов.
Думаю дело не в рекламе. Скорее Максим заинтересован в увеличении производительности в тех командах разработчиков с которыми приходится работать. Вот и получился этот выпуск.
Отличный выпуск! Спасибо Асхату за участие. Спасибо Максиму за создание и развитие этого подкаста.
Хотел бы еще обратить внимание на то, что использование гибких методологий, и Scrum в том числе, позволяют значительно повысить качество программного продукта. И как раз о качестве в этом выпуске было сказано очень мало. А ведь от этого в немалой степени зависит коммерческий успех продукта.
Честно говоря, я слегка разочарован. Асхат умеет говорить правильно и красноречиво. Но в это раз - не сказать, чтобы это было захватывающе.
Помимо этого, взглад Асхате несколько "однобокий". Он последователен в продвижении своей позиции. Поэтому не может считаться беспристрастным арбитром в вопросах выбора методологии.
Ну, и остальные методлогии он сильно "опустил". На самом деле, все не совсем так, как он рассказывал. Adgile - это всего лишь одно направление в разнообразном мире. К тому же Adgile - это все же больше для разработки софта. Помимо девелопмента еще существуют другие софтверные миры, которые сильно отличаются от разработки.
С уважением,
Гринкевич Сергей
