Вы совсем не понимаете, как работает эджайл. Очевидно, это вина тех "эффективных менеджеров", которые внедряли модные технологии, совершенно не разобравшись в их сути, и в результате испортили им репутацию у множества разработчиков. В настоящем эджайле нет буквально ничего из Вами описанного, это совсем иначе работает.
Не скрою, когда году в 2002 один заказчик (друган аж самого Кента Бека) принёс нам на хвосте хР, тоже сначала подумал: что за дичь такая. Но вскоре проникся – ибо результаты говорили сами за себя, нужно было быть дураком, чтобы не увидеть преимуществ. С тех пор сам несколько раз сам организовывал такую трансфомацию – и всегда это приводило к улучшениям. В том числе и к повышению удовлетворённости разработчиков. Например, сейчас у меня в команде средний период трудоустройства превышает 10 лет. Было бы такое возможно при наличии всех описанных Вами ужасов? Согласитесь, вряд ли.
Просто хорошо помню как оно раньше было, м.б. и не так все приятно и понятно для менеджмента, но разработчику было намного комфортнее работать, как по мне.
Жизнь тогда была совсем другая. Прежде всего – темп жизни. Эджайл – ответ именно на это, сейчас невозможно пилить систему годами до её выхода в продакшн – обязательно найдётся кто-то другой, кто сделает раньше и снимет все сливки. Именно с этой точки зрения жизнь была более комфортной (не только у разработчиков) – не было этой непрекращающейся гонки. Вообще конкуренции как таковой не было – каждый проект делала одна конкретная организация. Зато и прогресс сейчас идёт гораздо быстрее – что, разумеется, хорошо, но тоже в каком-то смысле добавляет дискомфорта, ибо и самому нужно за ним успевать.
Мне эджайл нравится, уже 20 с лишним лет по-другому не работаю. Но у меня он без фанатизма: беру только то, что на самом деле помогает конкретно в моём случае. Одно неизменно: короткие итерации и непрерывная обратная связь. Это действительно помогает раннему выводу продукта и внесению корректив в разумные сроки. Коммуникации по необходимости, обязательных встреч всего две: по пятницам внутрикомандные, подбить результаты прошедшей недели, и по понедельникам общая, с обзором состояния в целом по проекту и корректировкой приоритетов. Нам достаточно для того, чтобы все были в курсе происходящего и видели своё место в общей картине.
вы отлично иллюстрируете один из типов менеджеров "мне неизвестны детали, и вникать я не буду, лучше поосуждаю"
Почему же неизвестны-то? Я опытный менеджер, и вполне могу обсуждать утверждения, какие именно задачи для менеджеров приоритетны. И считаю, что если менеджер озабочен(а) по большей части тем, чтобы не мешать – это означает, что свои прямые менеджерские обязанности он(а) не выполняет, или что эта должность вовсе не нужна.
А обсуждаю я ровно то, что Вы написали – ни больше, ни меньше. На продолжении дискуссии не настаиваю, разумеется.
команда у меня работает сильно иначе, чем обычно принято
В том смысле, что у вас там полно нижне-средних менеджеров, которые постоянно лезут не в своё дело, мешая другим работать? Сочувствую, но не стоит экстраполировать этот свой опыт на весь остальной мир. Тем более, сознавая, что оно у вас работает "иначе, чем обычно принято".
При больших объёмах работы и на большом отрезке времени это уже не так просто держать все в голове
Если объём превышает возможности одного человека, то пора дробить команду на более мелкие, и делегировать контроль низовым менеджерам. А больших отрезков при грамотной декомпозиции задач и вовсе быть не должно.
Встречал и такие реализации – очень плохо, и в целом свидетельствует о непонимании сути технологии. SCRUM в чистом виде никогда не использовал, но смысл любой эджайл технологии именно в повышении степени информированности и вовлечённости исполнителей – когда они понимают конечную задачу и стремятся её реализовать максимально эффективно. Это прямо в манифесте записано, и всё, что этому противоречит, есть ересь.
С этой точки зрения каскадная модель (тебе написали ТЗ и сиди, выполняй в строгом соответствии с написанным) гораздо ближе к конвейеру. Только он очень медленный.
Раньше тебе давали какую-то задачу, срок на ее выполнение, причем сроки там нарезались не часами а неделями, а то и месяцами
Скорее всего, там были проблемы с проектированием. При грамотно проведённой декомпозиции задач такой длительности просто не должно быть. По крайней мере, как системы – какие-то редкие исключения возможны.
А "все эти скрамы" отнюдь не предписывают поминутный учёт времени. Сам работаю в режиме недельных итераций, и тайм-трекинг не использую. Зато имею уверенность, что каждая из выполняемых в данный момент задач действительно актуальна для бизнеса, и даже если потом окажется, что идея была ошибочной – потеряю всего неделю, а не месяцы.
Во-первых ты понимаешь реальную скорость работы человека
Я и без этого понимаю. Для этого всего-то и нужно, что следить за выполнямыми командой задачами. Имея при этом в голове некоторое понимание сложности каждой, и при случае не стесняясь спросить исполнителя, в чём у него затык и нужна ли помощь.
Я за 20 лет практически не видел руководителя низшего и среднего звена, который бы четко понимал, что первая его задача - НЕ МЕШАТЬ.
Дельного менеджера с таким пониманием собственной роли быть не может. Ибо если этим его функции исчерпываются, то умный человек должен сознавать, что эта должность вовсе не нужна, и искать другую работу. Я своим всегда говорю, что моя работа – им помогать. Согласитесь, совсем не одно и то же.
для моделей данных такой подход на мой взгляд вполне оправдан
Да, в таком ограниченном варианте использования – вполне возможно. Но мечталось-то, что весь проект можно будет держать в понятной визуальной модели 🙂 Не получилось.
Я лет через 10 после того, как сам бросил это дело, был на каком-то митапе, и одна из лекций была как раз по моделированию – заглянул по старой памяти. Мужик долго рассказывал, какой UML чудесный, а закончил тем, что его повсеместному внедрению пока мешает одно мелкое, но досадное обстоятельство: отсутствие средств переноса изменений кода в модель. Надо кому-то это быстренько сделать (желательно, для всех основных языков) , и сразу наступит всеобщее щастье.
Был у меня недолгий период увлечения UML. На практике оказалось, что поддерживать модель в актуальном состоянии практически невозможно. Не было (и насколько я знаю, до сих пор нет) ни одного инструмента, способного её качественно перегенерить согласно изменениям в коде. Даже такие очевидные разновидности, как диаграмма классов – не говоря уж о более высоких абстракциях типа use cases. А без этого оно бесполезно.
Ещё как-то случилось чуток поработать с IBM Visual Age C++. Воспоминания жуткие, любой сколько-нибудь сложный проект тут же превращается с месиво из стрелочек, которое даже авторы вскоре перестают понимать – не говоря уж о всех остальных.
Что думаете вы о девушках в IT и в разработке в частности?
Я девушек очень люблю – везде, в IT в том числе, и думаю о них всегда хорошо 🙂 Соответственно, никаких предрассудков нет – а вот опыт есть. Как это объяснить, я не знаю, потому что женщины в среднем точно не тупее мужчин – но по моему опыту женщины-программисты в среднем заметно слабее. Единственное более или менее внятное объяснение, которое приходит в голову – их таки значительно меньше, и возможно, на столь малой выборке сложнее встретить действительно выдающихся специалистов. Хотя, вспоминая ещё советские времена – случалось работать в коллективах, где пропорция был примерно пополам – и даже тогда лидерами всё равно были парни. Девчонки писали неплохо – но как-то без изюминки, что ли. Сложно объяснить. В любом случае, умных девушек мы любим и всегда им рады 🙂
При чём тут это? И вообще, мы тут что, полную систему проектируем? Причём в ситуации, когда
бизнес-логика попросту неизвестна.
Я так не умею. И базы проектировать, не зная, для чего – тоже. Что я знаю точно – в хорошо спроектированной системе строковые ключи нужны крайне редко, и их нужно по возможности избегать.
Вы совсем не понимаете, как работает эджайл. Очевидно, это вина тех "эффективных менеджеров", которые внедряли модные технологии, совершенно не разобравшись в их сути, и в результате испортили им репутацию у множества разработчиков. В настоящем эджайле нет буквально ничего из Вами описанного, это совсем иначе работает.
Не скрою, когда году в 2002 один заказчик (друган аж самого Кента Бека) принёс нам на хвосте хР, тоже сначала подумал: что за дичь такая. Но вскоре проникся – ибо результаты говорили сами за себя, нужно было быть дураком, чтобы не увидеть преимуществ. С тех пор сам несколько раз сам организовывал такую трансфомацию – и всегда это приводило к улучшениям. В том числе и к повышению удовлетворённости разработчиков. Например, сейчас у меня в команде средний период трудоустройства превышает 10 лет. Было бы такое возможно при наличии всех описанных Вами ужасов? Согласитесь, вряд ли.
Можно уточнить, в чём разница между
и
Я её не вижу, ИМХО то же самое. Только последовательность в первом варианте несколько перепутана:
Таки лучше наоборот: тестируй, внедряй, «допиливай»
Жизнь тогда была совсем другая. Прежде всего – темп жизни. Эджайл – ответ именно на это, сейчас невозможно пилить систему годами до её выхода в продакшн – обязательно найдётся кто-то другой, кто сделает раньше и снимет все сливки. Именно с этой точки зрения жизнь была более комфортной (не только у разработчиков) – не было этой непрекращающейся гонки. Вообще конкуренции как таковой не было – каждый проект делала одна конкретная организация. Зато и прогресс сейчас идёт гораздо быстрее – что, разумеется, хорошо, но тоже в каком-то смысле добавляет дискомфорта, ибо и самому нужно за ним успевать.
Мне эджайл нравится, уже 20 с лишним лет по-другому не работаю. Но у меня он без фанатизма: беру только то, что на самом деле помогает конкретно в моём случае. Одно неизменно: короткие итерации и непрерывная обратная связь. Это действительно помогает раннему выводу продукта и внесению корректив в разумные сроки. Коммуникации по необходимости, обязательных встреч всего две: по пятницам внутрикомандные, подбить результаты прошедшей недели, и по понедельникам общая, с обзором состояния в целом по проекту и корректировкой приоритетов. Нам достаточно для того, чтобы все были в курсе происходящего и видели своё место в общей картине.
Почему же неизвестны-то? Я опытный менеджер, и вполне могу обсуждать утверждения, какие именно задачи для менеджеров приоритетны. И считаю, что если менеджер озабочен(а) по большей части тем, чтобы не мешать – это означает, что свои прямые менеджерские обязанности он(а) не выполняет, или что эта должность вовсе не нужна.
А обсуждаю я ровно то, что Вы написали – ни больше, ни меньше. На продолжении дискуссии не настаиваю, разумеется.
В том смысле, что у вас там полно нижне-средних менеджеров, которые постоянно лезут не в своё дело, мешая другим работать? Сочувствую, но не стоит экстраполировать этот свой опыт на весь остальной мир. Тем более, сознавая, что оно у вас работает "иначе, чем обычно принято".
Менеджер, безусловно. Но не один из – ибо задачи у меня совсем иные, под описание никак не подхожу.
И видите свою задачу в том, чтобы не мешать? Гм.
Первая – она же, вероятно, и основная? Во всяком случае, я так услышал. Если да, то не согласен, и написал, почему.
Тут есть два варианта:
Вам сильно не повезло.
Вы на своей позиции не видите, в чём ценность деятельности менеджеров. Как в политике: "Очень жаль, что все, кто умеет руководить государством, уже работают таксистами и парикмахерами".
Если объём превышает возможности одного человека, то пора дробить команду на более мелкие, и делегировать контроль низовым менеджерам. А больших отрезков при грамотной декомпозиции задач и вовсе быть не должно.
Мысль-то понял – а вот её связь с моим комментарием нет.
Встречал и такие реализации – очень плохо, и в целом свидетельствует о непонимании сути технологии. SCRUM в чистом виде никогда не использовал, но смысл любой эджайл технологии именно в повышении степени информированности и вовлечённости исполнителей – когда они понимают конечную задачу и стремятся её реализовать максимально эффективно. Это прямо в манифесте записано, и всё, что этому противоречит, есть ересь.
С этой точки зрения каскадная модель (тебе написали ТЗ и сиди, выполняй в строгом соответствии с написанным) гораздо ближе к конвейеру. Только он очень медленный.
Польщён. Это какой-то прям запредельный уровень эмпатии. Вот если человек слушает, но не слышит – тогда дело действительно плохо.
Скорее всего, там были проблемы с проектированием. При грамотно проведённой декомпозиции задач такой длительности просто не должно быть. По крайней мере, как системы – какие-то редкие исключения возможны.
А "все эти скрамы" отнюдь не предписывают поминутный учёт времени. Сам работаю в режиме недельных итераций, и тайм-трекинг не использую. Зато имею уверенность, что каждая из выполняемых в данный момент задач действительно актуальна для бизнеса, и даже если потом окажется, что идея была ошибочной – потеряю всего неделю, а не месяцы.
Я и без этого понимаю. Для этого всего-то и нужно, что следить за выполнямыми командой задачами. Имея при этом в голове некоторое понимание сложности каждой, и при случае не стесняясь спросить исполнителя, в чём у него затык и нужна ли помощь.
Дельного менеджера с таким пониманием собственной роли быть не может. Ибо если этим его функции исчерпываются, то умный человек должен сознавать, что эта должность вовсе не нужна, и искать другую работу. Я своим всегда говорю, что моя работа – им помогать. Согласитесь, совсем не одно и то же.
Паблик Морозов? 😲
Да, в таком ограниченном варианте использования – вполне возможно. Но мечталось-то, что весь проект можно будет держать в понятной визуальной модели 🙂 Не получилось.
Я лет через 10 после того, как сам бросил это дело, был на каком-то митапе, и одна из лекций была как раз по моделированию – заглянул по старой памяти. Мужик долго рассказывал, какой UML чудесный, а закончил тем, что его повсеместному внедрению пока мешает одно мелкое, но досадное обстоятельство: отсутствие средств переноса изменений кода в модель. Надо кому-то это быстренько сделать (желательно, для всех основных языков) , и сразу наступит всеобщее щастье.
Был у меня недолгий период увлечения UML. На практике оказалось, что поддерживать модель в актуальном состоянии практически невозможно. Не было (и насколько я знаю, до сих пор нет) ни одного инструмента, способного её качественно перегенерить согласно изменениям в коде. Даже такие очевидные разновидности, как диаграмма классов – не говоря уж о более высоких абстракциях типа use cases. А без этого оно бесполезно.
Ещё как-то случилось чуток поработать с IBM Visual Age C++. Воспоминания жуткие, любой сколько-нибудь сложный проект тут же превращается с месиво из стрелочек, которое даже авторы вскоре перестают понимать – не говоря уж о всех остальных.
Я девушек очень люблю – везде, в IT в том числе, и думаю о них всегда хорошо 🙂 Соответственно, никаких предрассудков нет – а вот опыт есть. Как это объяснить, я не знаю, потому что женщины в среднем точно не тупее мужчин – но по моему опыту женщины-программисты в среднем заметно слабее. Единственное более или менее внятное объяснение, которое приходит в голову – их таки значительно меньше, и возможно, на столь малой выборке сложнее встретить действительно выдающихся специалистов. Хотя, вспоминая ещё советские времена – случалось работать в коллективах, где пропорция был примерно пополам – и даже тогда лидерами всё равно были парни. Девчонки писали неплохо – но как-то без изюминки, что ли. Сложно объяснить. В любом случае, умных девушек мы любим и всегда им рады 🙂
или возможно, с ключом юзер ид из базы, не знаю:
При чём тут это? И вообще, мы тут что, полную систему проектируем? Причём в ситуации, когда
Я так не умею. И базы проектировать, не зная, для чего – тоже. Что я знаю точно – в хорошо спроектированной системе строковые ключи нужны крайне редко, и их нужно по возможности избегать.
🤦♂️ Да что ж Вы такое пишете-то.... Почему?! Это будет
User.role– которое, в свою очередь, нечто вродеПоразительно.