Comments 6
«Можете почитать труды Тейлора и Друкера, в IT повально недооценивают достижения классического менеджмента.»
Уважение вам за эти слова и в целом за статью. К сожалению, голосовать не хватает кармы.
Уважение вам за эти слова и в целом за статью. К сожалению, голосовать не хватает кармы.
У нас не любят золотую середину. А давайте классический метод, да еще со всеми практиками, да и workflow согласования изменения из 56 этапов. Или, а давайте мы Agile, поэтому инженерные практики, документирование, процессы — побоку. Во все нужна золотая середина. Я бы не хотел жить рядом с атомной электростанцией на которую систему управления вот прямо сейчас пишут по Scrum…
Статья у вас получилась очень сумбурная, такой поток сознания.
Осталось неясно, что вам конкретно не нравится в Scrum.
Стендап длится от силы 10 минут и это, пожалуй, самый полезный митинг.
На новости на Хабре уходит куда больше времени.
Ретро помогает разобраться в корнях проблем, до того, как будет поздно.
Например, в вашем примере со студией, возможно, программер уже подустал писать однотипные магазы и уже смазывает лыжи, но вы прочувствуете этот момент, если не будете получать от него регулярный фидбек по работе.
Т.е. распыление внимания на много разных задач эффективность повышает?
Весьма спорно. Тем более, в методологии команда сама решает, сколько задач она может тянуть параллельно.
Совместное владение кодом — это не про эффективность, а про взаимозаменяемость.
Это на случай, если тот программер из студии укатил на смазанных лыжах, работа не встанет на неделю, пока кто-то будет в панике разгребать его код.
Честно говоря, осталось впечатление, что вы не видите за деревьями леса.
Максимизация эффективности идет из психологии работников, из их внутренней мотивации. Ритуалы просто помогают поддерживать эту мотивацию, но они не самоцель.
Осталось неясно, что вам конкретно не нравится в Scrum.
есть потери времени на стендапы, ретроспективы и т.п.
Стендап длится от силы 10 минут и это, пожалуй, самый полезный митинг.
На новости на Хабре уходит куда больше времени.
Ретро помогает разобраться в корнях проблем, до того, как будет поздно.
Например, в вашем примере со студией, возможно, программер уже подустал писать однотипные магазы и уже смазывает лыжи, но вы прочувствуете этот момент, если не будете получать от него регулярный фидбек по работе.
совместное владение кодом и ограничение на число одновременных задач снижают общую эффективность
Т.е. распыление внимания на много разных задач эффективность повышает?
Весьма спорно. Тем более, в методологии команда сама решает, сколько задач она может тянуть параллельно.
Совместное владение кодом — это не про эффективность, а про взаимозаменяемость.
Это на случай, если тот программер из студии укатил на смазанных лыжах, работа не встанет на неделю, пока кто-то будет в панике разгребать его код.
Честно говоря, осталось впечатление, что вы не видите за деревьями леса.
Максимизация эффективности идет из психологии работников, из их внутренней мотивации. Ритуалы просто помогают поддерживать эту мотивацию, но они не самоцель.
В голосовании нет варианта «не знаю».
У скрама есть большой плюс, который делает эту методологию уместной на крупных проектах, а именно — передача приоритезации задач из бэклога на сторону заказчика, так что заказчик получает наиболее актуальные для себя функции в первую очередь. Это же, собственно, и минус, поскольку со стороны заказчика должен быть адекватный руководитель проекта, который понимает «как это устроено», а вот это уже большая редкость. Но уж если такой человек у заказчика находится, то результаты фантастические.
Отличная статья.
У меня возникла мысль для обсуждения — а с точки зрения проектного менеджмента, можно ли считать проект, в котором глобальные изменения в требования и ожиданиях заказчика происходят чаще чем релизы успешным в принципе?
В итоге на моменте старта проекта мы планируем достичь одно (сделать самолет), а в процессе работы и уточнения требований в зависимости от условий внешней среды (мало денег, крылья не успели придумать, и далее по списку) мы в итоге конечно что-то сделали, но оно больше похоже на подводный трактор с велоприводом.
Конечно мы, как команда, оперативно отвечали на все изменения среды, и довели (довели ли? :) ) проект до конца, т.е. что-то да собрали.
Но разве это не полный провал самого проекта, если посмотреть на него с точки классического проектного менеджмента?
У меня возникла мысль для обсуждения — а с точки зрения проектного менеджмента, можно ли считать проект, в котором глобальные изменения в требования и ожиданиях заказчика происходят чаще чем релизы успешным в принципе?
В итоге на моменте старта проекта мы планируем достичь одно (сделать самолет), а в процессе работы и уточнения требований в зависимости от условий внешней среды (мало денег, крылья не успели придумать, и далее по списку) мы в итоге конечно что-то сделали, но оно больше похоже на подводный трактор с велоприводом.
Конечно мы, как команда, оперативно отвечали на все изменения среды, и довели (довели ли? :) ) проект до конца, т.е. что-то да собрали.
Но разве это не полный провал самого проекта, если посмотреть на него с точки классического проектного менеджмента?
Sign up to leave a comment.
Почему Scrum иногда не работает и что с этим делать