Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
Главным достоинством scrum'а в сравнении с другими методиками является малый оверхед. Команды, которые используют скрам, всего в 1.5-2 раза менее эффективны, чем команды, которые не используют ничего. Это выдающийся результат, потому что другие методологии замедляют команду ещё больше.
Методологии существуют совсем не для того, чтобы снизить «overhead», или только лишь повысить эффективность команды. Методологии созданы чтобы повысить управляемость, предсказуемость и эффективность управления проектом. Команда, работающая над продуктом — лишь часть любой методологии, и ее интересы отнюдь не на первом месте.
В конце концов, какой смысл делать работу быстро, если эта работа не решит стояющую проблему? Можно быстро построить во дворе двадцатиэтажный гараж, но все равно жить будет негде :)
В конце концов, какой смысл делать работу быстро, если эта работа не решит стояющую проблему? Можно быстро построить во дворе двадцатиэтажный гараж, но все равно жить будет негде :)
Оверхэд скрама зависит от многих факторов. У нас он составляет ~20% (редко 30%) рабочего времени.
Команды, которые не используют ничего, также тратят время на постановку/разбор задач и т.п. Только его подсчитать сложнее.
Команды, которые не используют ничего, также тратят время на постановку/разбор задач и т.п. Только его подсчитать сложнее.
А энтузиазм? Как любая бюрократия, оно угнетает. С одной стороны всё ровненько и гладенько, с другой стороны без особых всплесков энтузиазма в плохорешаемых задачах, вроде разработки архитектуры или продумывания всех аспектов проблем.
Вам знакомы успешные команды без бюрократии? Мне нет.
Насколько я знаю, мозаик был написан Ли без использования бюрократии. Апач был создан без использования бюрократии. Каких-либо скрам-митингов в написании Линукса я тоже не видел.
Вопрос был про команды и бюрократию, а не личности и скрам-митинги.
Как я сказал, апач был написан без какой-то бюрократии.
Обычно же в крупных проектах бюрократия нужна для поддержания минимального порядка.
Но основной ресурс, который надо учитывать в накладных расходах на бюрократию, это не только время, но и энтузиазм. Причём он даже важнее времени, а как раз энтузиазм бюрократией портится с фантастической силой, так что если проект интересный, то лучше бюрократию минимизировать. Если это очередной интернет-магазин, биллинг или банк-клиент, то бюрократии можно побольше, потому что энтузиазма там всё равно не особо много.
Обычно же в крупных проектах бюрократия нужна для поддержания минимального порядка.
Но основной ресурс, который надо учитывать в накладных расходах на бюрократию, это не только время, но и энтузиазм. Причём он даже важнее времени, а как раз энтузиазм бюрократией портится с фантастической силой, так что если проект интересный, то лучше бюрократию минимизировать. Если это очередной интернет-магазин, биллинг или банк-клиент, то бюрократии можно побольше, потому что энтузиазма там всё равно не особо много.
Господа, объясните по хардкору, зачем используют все эти методологии типа scrum, agile, %dozens of em%?
Ну то есть мы в команде имеем проект, в рамках которого выполняем задачи, внедряем баги, фиксим фичи и в том же духе. При постановке задачи определяются сроки на ее выполнение и внедрение. Всё.
Я просто не могу понять прикол :(
Ну то есть мы в команде имеем проект, в рамках которого выполняем задачи, внедряем баги, фиксим фичи и в том же духе. При постановке задачи определяются сроки на ее выполнение и внедрение. Всё.
Я просто не могу понять прикол :(
Я, похоже, ответил на ваш вопрос выше :)
Просумировать, ЦА методологий — не команда, а менеджмент проекта, которому нужны управляемость, предсказуемость, и.т.д
Методологии существуют совсем не для того, чтобы снизить «overhead», или только лишь повысить эффективность команды. Методологии созданы чтобы повысить управляемость, предсказуемость и эффективность управления проектом. Команда, работающая над продуктом — лишь часть любой методологии, и ее интересы отнюдь не на первом месте.
В конце концов, какой смысл делать работу быстро, если эта работа не решит стояющую проблему? Можно быстро построить во дворе двадцатиэтажный гараж, но все равно жить будет негде :)
Просумировать, ЦА методологий — не команда, а менеджмент проекта, которому нужны управляемость, предсказуемость, и.т.д
Там всё сложно и пронизано болью. Кто вам задачи ставит? Почему они выполняются в таком порядке? Если кто-то из команды видит, что надо рефакторить нафиг, а вместо этого ему говорят «переделай формочку вывода» — что важнее, формочка или рефакторинг?
Столь всеми поливаемый и ненавидемый ватерфалл подразумевает, что ТЗ спускается с небес и непогрешимо, и уж точно не будет меняться в течение ближайших двух тысяч лет. На практике это не так, и все методологии отвечают, как с этим нам теперь жить.
Столь всеми поливаемый и ненавидемый ватерфалл подразумевает, что ТЗ спускается с небес и непогрешимо, и уж точно не будет меняться в течение ближайших двух тысяч лет. На практике это не так, и все методологии отвечают, как с этим нам теперь жить.
Ну в роли уравновешивателя может выступать тот же тимлид, который объяснит начальству на пальцах, что такое технический долг и как все скоро из-за этого огребут. На том же уровне решается приоритетность и прикидка по срокам. Не?
Фактически вы уже используюте методологию, которую называете «нормальный бизнес-процесс в it среде».
Проблемы начнуться, когда, к примеру, вам обратятся стороние (зарубежные, или еще круче, государственные) заказчики ПО. Зарубежным подавай Agile (и обязательно c сертифицированными Scrum-мастерами). Государственным подавай по ГОСТ (есть и они :) )
Методология не дает ответов, если у вас уже налажен здоровый процесс. Методология дает ответы, как можно наладить (более-менее) здоровый процесс, если у ваш текущий процесс из семейства «через #опу».
Или, как выгодно «продать» текущий бизнес процесс потенциальному заказчику или инвестору.
Проблемы начнуться, когда, к примеру, вам обратятся стороние (зарубежные, или еще круче, государственные) заказчики ПО. Зарубежным подавай Agile (и обязательно c сертифицированными Scrum-мастерами). Государственным подавай по ГОСТ (есть и они :) )
Методология не дает ответов, если у вас уже налажен здоровый процесс. Методология дает ответы, как можно наладить (более-менее) здоровый процесс, если у ваш текущий процесс из семейства «через #опу».
Или, как выгодно «продать» текущий бизнес процесс потенциальному заказчику или инвестору.
Очередное предположение, что тимлид спускается с небес и Точно Всё Знает. Не знает он всего, особенно, в новом коде. Кто-то что-то напридумывал, оно, вроде, работает, но до какой степени это халтура (и адаптировано под изменившееся ТЗ на лету) знает только его автор — он на митинге и комплейнится, мол, «в срок написали, а теперь у нас технический долг».
В описываемой вами схеме совершенно не понятно:
а) когда тимлид узнает про это
б) когда он это объяснит начальству
в) когда будет принято решение об исправлении дефекта.
scrum описывает процесс взаимодействия между членами команды такое, чтобы время между «обнаружили проблему» (получили feature request) до «приняли решение когда и как делать» было контролируемым и разумным.
В описываемой вами схеме совершенно не понятно:
а) когда тимлид узнает про это
б) когда он это объяснит начальству
в) когда будет принято решение об исправлении дефекта.
scrum описывает процесс взаимодействия между членами команды такое, чтобы время между «обнаружили проблему» (получили feature request) до «приняли решение когда и как делать» было контролируемым и разумным.
К тому же, методология «призвана» снизить влияние человеческого фактора. В том же Скрам, ответсвенность тимлида «размазана» между скрам мастером, продукт оунером, и собсна командой. С одной стороны, это плохо — не пойми кто накосячил/молодец. С другой стороны, если тимлид забухал вдруг, все равно есть кто-то, кто пойдет защищать рефакторинг и отбиваться от формочки.
По сути, методология, это правила игры, описаные на бумаге (или веб странички). Они нужны, потому, что ваше понимание вменяемого бизнес процесса может разительно отличаться от понимания Васи.
И вот подрались Петя с Васей из-за формочки и рефакторинга. А могли бы ретроспективу устроить. И звучит модно, и гораздо менее болезнено! :)
По сути, методология, это правила игры, описаные на бумаге (или веб странички). Они нужны, потому, что ваше понимание вменяемого бизнес процесса может разительно отличаться от понимания Васи.
И вот подрались Петя с Васей из-за формочки и рефакторинга. А могли бы ретроспективу устроить. И звучит модно, и гораздо менее болезнено! :)
Там масса деталей, в частности, например прикидка по срокам может считаться статистически.
Кто оценивает — тим лид или команда? И т.д.
Кто оценивает — тим лид или команда? И т.д.
Есть очень большая тема про треугольник project-managmenta, работу с заказчиком, разделение ответственности заказчика и исполнителя и прочая прочая. Эта тема достойна пожалуй вереницы статей, потому что это тема про боль и страдания современного it бизнеса :)
Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.
Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.
Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.
Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.
затем же, зачем при разработке используется ide, сниппеты, библиотеки, и прочее.
бизнес хочет зарабатывать деньги, желательно вкладывая меньше ресурсов.
при этом у бизнеса уже есть опыт, который фиксируют в методологиях.
в зависимости от типа проекта подбирают те практики, которые ему подходят и позволяют сэкономить ценный ресурс.
бизнес хочет зарабатывать деньги, желательно вкладывая меньше ресурсов.
при этом у бизнеса уже есть опыт, который фиксируют в методологиях.
в зависимости от типа проекта подбирают те практики, которые ему подходят и позволяют сэкономить ценный ресурс.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?»
Зачем все эти унылые и ненужные сборища? Есть тикеты, есть статус тикетов. Всё по ним видно. И время тратится на этих сходках, и нервы. К тому же, редко что новое там услышишь относительно своих тикетов.
Когда нового мало то и daily занимает минут 10-15 обычно.
daily нужны чтобы команда была в курсе всех изменений которые происходят в коде. Очень плохо когда человек закрывается на несколько дней в и делает свой тикет, а потом выясняется что все можно было сделать проще или что изменения которые он сделал задевают работу других разработчиков. Обычно общаться голосом гораздо легче и эффективнее чем смотреть на доску в трекере.
daily нужны чтобы команда была в курсе всех изменений которые происходят в коде. Очень плохо когда человек закрывается на несколько дней в и делает свой тикет, а потом выясняется что все можно было сделать проще или что изменения которые он сделал задевают работу других разработчиков. Обычно общаться голосом гораздо легче и эффективнее чем смотреть на доску в трекере.
Обсудить задачу можно и в процессе самой работы.
Когда нового мало то и daily занимает минут 10-15 обычно.Встреча утром, как правило, происходит. Пока все соберутся и т.д., пройдёт час, предположим. Весь этот час я не могу нормально работать, так как давит ожидание встречи. Сама беседа минут 15. Туда-сюда и 2 часа в итоге выпадает из рабочего процесса. Может, правда, это только у меня такая проблема…
Ни кто ни кого не ждет.
Есть четко определенное время для митинга, и если кто-то к этому времени не успел, то он ССЗБ.
У нас, например, за каждый пропущенный митинг должен всем из команды по бокалу хорошего пива в пабе.
Есть четко определенное время для митинга, и если кто-то к этому времени не успел, то он ССЗБ.
У нас, например, за каждый пропущенный митинг должен всем из команды по бокалу хорошего пива в пабе.
Это я к тому, что команда — саморегулирующийся механизм.
Если вы час собираетесь на митинг, то либо у вас команда разгильдяев, либо неудачно выбрано время митинга, либо все вместе.
Если вы час собираетесь на митинг, то либо у вас команда разгильдяев, либо неудачно выбрано время митинга, либо все вместе.
Вот такие вещи и убивают всё и вся.
Я, например, с хроническим расстройством сна — и мне физически тяжело держать график по времени. Зато я могу спокойно работать когда мне работается и делать больше, чем в рабочее время.
И не только я один такой. Что делать с человеком, который не может заснуть до 5 утра, а скрам на 10 назначен? Заставлять просыпаться?
Если раз в неделю подгадать время ещё можно, то каждый день — это просто мучение.
Я, например, с хроническим расстройством сна — и мне физически тяжело держать график по времени. Зато я могу спокойно работать когда мне работается и делать больше, чем в рабочее время.
И не только я один такой. Что делать с человеком, который не может заснуть до 5 утра, а скрам на 10 назначен? Заставлять просыпаться?
Если раз в неделю подгадать время ещё можно, то каждый день — это просто мучение.
Вот такие вещи и убивают всё и вся.Какие такие?
Время митинга устанавливает команда, это может быть 9 утра, 3 дня, 7 вечера, любое удобное для большинства.
Если вы не можете вписаться, то командная работа не для вас.
А что делать людям, которых не устраивает текущий code convention? Или которых бесят табы (пробелы) в репозитории?
«Я тут весь такой великий гуру, быстренько подстраивайтесь под меня», так должно быть?
Ну, начинается. Agile работает с правильными программистами. Дайте мне других программистов и на этот раз agile точно заработает.
Я отлично работаю в команде, только на работе появляюсь неровно (иногда с утра, иногда с вечера).
Такое ощущение, что соблюдение графика рабочих часов — это обязательное условие для agile.
И никто не «великий гуру». Если человек вовремя с работой справляется, что к нему с графиком лезть?
Собственно, претензия только к ежедневным standup'ам, потому что в остальном scrum очень разумная технология.
ЗЫ Совместные обеды неплохо заменяют собой стэндапы.
Я отлично работаю в команде, только на работе появляюсь неровно (иногда с утра, иногда с вечера).
Такое ощущение, что соблюдение графика рабочих часов — это обязательное условие для agile.
И никто не «великий гуру». Если человек вовремя с работой справляется, что к нему с графиком лезть?
Собственно, претензия только к ежедневным standup'ам, потому что в остальном scrum очень разумная технология.
ЗЫ Совместные обеды неплохо заменяют собой стэндапы.
Agile работает с правильными программистами.Не передергивайте.
Agile потому и аgile — нет правил, высеченных в граните.
Повторюсь: команда — саморегулирующийся механизм. Если ее устраивает ваша работа и ваше непоявление на митингах, то о чем вообще разговор?
Так и ватерфол можно назвать самоотрегулировавшимся agile'ом :)
Я к тому, что ежедневные стэндапы воспринимаются как наиболее интрузивная и раздражающая составляющая любого scrum'а. Всё остальное воспринимается обычно позитивно и спокойно, т.к. всем понятно «зачем». Мотивация у стэндапов же звучит очень вяло.
Я к тому, что ежедневные стэндапы воспринимаются как наиболее интрузивная и раздражающая составляющая любого scrum'а. Всё остальное воспринимается обычно позитивно и спокойно, т.к. всем понятно «зачем». Мотивация у стэндапов же звучит очень вяло.
Как по мне, митинги зависят от людей и самой работы.
У меня был опыт работы в компаниях, где на митингах было все просто, весело и задорно (и они редко занимали более 10 минут), и в компаниях, где на получасовых митингах было охота блевать.
У меня был опыт работы в компаниях, где на митингах было все просто, весело и задорно (и они редко занимали более 10 минут), и в компаниях, где на получасовых митингах было охота блевать.
Я к тому, что ежедневные стэндапы воспринимаются как наиболее интрузивная и раздражающая составляющая любого scrum'а.
Кем и когда воспринимается? Откуда статистика? 15 минутный проход по задачам — это не очень много.
Кем и когда воспринимается? Откуда статистика? 15 минутный проход по задачам — это не очень много.
Если у него настолько нестандартный график, что он не пересекается вообще с командой, то как с ним общаться по рабочим вопросам? Т.е. он убивает командую эффективность. Гибкий график это хорошо, но он должен иметь какое-то общее пересечение дающее какие-то гарантии на возможность пообщаться с другим участником команды.
И чем совместный обед лучше стендапа? Так же нужно общее время и плюс еще привязывается общение к нерабочим факторам (ну не хочу я еще обедать, а чтобы быть в курсе надо идти со всеми). Стендап в середине дня вполне комфортен.
И чем совместный обед лучше стендапа? Так же нужно общее время и плюс еще привязывается общение к нерабочим факторам (ну не хочу я еще обедать, а чтобы быть в курсе надо идти со всеми). Стендап в середине дня вполне комфортен.
Пересекается, но в разное время.
Ну пусть тогда появляется не на всех стендапах, если это устраивает команду. Эффективность немного понизится, но если остальные к этому готовы (преимущества превышают недостатки), то вполне. Даже если 8 часовой рабочий день равномерно случайно распределен в сутках (надеюсь, что это не так, а то это уже лечить надо), то можно попадать на треть стендапов. У нас стендап занимает 5-10 минут в команде из 15+ людей.
Я, например, с хроническим расстройством сна
Вы ко врачам обращались? Не может быть такое, что это просто привычка?
Вы ко врачам обращались? Не может быть такое, что это просто привычка?
А просто тупо постить ответы на 3 вопроса в специально отведенный для этого чат в начале каждого рабочего дня не поможет?
Получаем, что мы не привязаны ко времени, достигаем практически тех же целей и теряем только обсуждения (а они нужны вообще во время стендапа?) и общение лицом к лицу (тоже, наверное, не проблема, если команда в одной комнате сидит).
Получаем, что мы не привязаны ко времени, достигаем практически тех же целей и теряем только обсуждения (а они нужны вообще во время стендапа?) и общение лицом к лицу (тоже, наверное, не проблема, если команда в одной комнате сидит).
Универсальных рецептов нет. Можно придумать множество различных способов.
Главное, чтоб они подошли и были поддержаны остальными участниками.
Мы остановились именно на митингах поскольку все итак присутствуют в офисе в обозначенное время и сам митинг отнимает времени не больше, чем занимала бы переписка и ее последущее чтение.
Главное, чтоб они подошли и были поддержаны остальными участниками.
Мы остановились именно на митингах поскольку все итак присутствуют в офисе в обозначенное время и сам митинг отнимает времени не больше, чем занимала бы переписка и ее последущее чтение.
Во время стендапа могут быть быстрые обсуждения.
Чат тоже можно использовать — кажется в гугле просто исползуют почту для этого — но найти ссылку пока не смог.
Чат тоже можно использовать — кажется в гугле просто исползуют почту для этого — но найти ссылку пока не смог.
если эти сходи просто формальность — тогда да, они унылы.
если же их подстраивать под задачи команды — это замечательный интсрумент.
хороший вариант старта — как раз тикеты и их статус, а не фромально отвечать на вопросы.
в стиле «хм, ты же хотел вчера этот тикет закрыть, в чем проблема?»
надеяться, что без таких сходок кто-то будет ходить и смотреть статусы чужих задач — очень наивно :)
если же их подстраивать под задачи команды — это замечательный интсрумент.
хороший вариант старта — как раз тикеты и их статус, а не фромально отвечать на вопросы.
в стиле «хм, ты же хотел вчера этот тикет закрыть, в чем проблема?»
надеяться, что без таких сходок кто-то будет ходить и смотреть статусы чужих задач — очень наивно :)
Очень хорошая статься, как повод углубиться в обсуждения преимуществ и недостатков. Я бы порекомендовал вам взять за шкирку челвека который уже пару лет занимается Scrum и обсудить с ним все аспекты. На втором уровне рассмотрения могут выползти другие недостатки, а текущие изящно решиться.
P.S. Статью можно уверенно назвать вбросом недели, комментарии читать не менее интересно чем саму статью. Вообще спорить тут не о чем: у тебя либо скрам работает либо нет, по разным причинам. Любо стоит исправить ситуацию и построить работу по нормальному либо отказаться от фреймворка. В конце концов есть очень много примеров где scrum не применим или не особо нужен.
P.S. Статью можно уверенно назвать вбросом недели, комментарии читать не менее интересно чем саму статью. Вообще спорить тут не о чем: у тебя либо скрам работает либо нет, по разным причинам. Любо стоит исправить ситуацию и построить работу по нормальному либо отказаться от фреймворка. В конце концов есть очень много примеров где scrum не применим или не особо нужен.
Пожалуйста, уберите в статье слово методология отовсюду. Scrum — не методология, это framework. Методологий в Agile-mindset вообще дико мало. RUP, например.
Вы думаете стоит убрать? В самом начале я указал, что Scrum не является методологией, хотя (в обиходе) часто называется методологией.
Хотя…
Убрал почти везде, кроме начальной части.
Убрал почти везде, кроме начальной части.
Во время работы это часто вызывает проблемы, потому что методология подразумевает встроенное решение любых проблем и вопросов. Я просто за то, чтобы сразу этого избегать, употребляя верные термины. Это мелочь, но каждое такое объяснение в рабочем процессе потихоньку стачивает мозг :)
в обиходе вообще Agile называют методолгией, а подразумевают Scrum :)
Все равно все заканчивается тем, что на стендапы никто не хочет ходить, никто не хочет говорить и все превращается в обременительную формальность. Зато менеджер доволен и есть иллюзия контроля над процессом. А потом случаются овертаймы. А потом надо писать заказчику, почему же все таки у нас проблемы и что мы будем делать, чтобы их решить. В рамках заданного бюджета, конечно же.
В разработке (не сайтов-визиток, конечно же) слишком мало типичных задач, которые бы хорошо подходили под планирование. Оценки всегда врут, обычно они или излишне оптимистичны, или их таковыми делают, потому как «Вы что?! Заказчик не поймет!», соотв. эта тупая гонка в рамках спринта за вымпел победителя соц. соревнования с наплевательским отношением к качеству приводит к огромным долгам в разработке («потом сделаем нормально»), которые, в купе с почти всегда трусливой позицией менеджмента по отношению к клиенту, приводят к тому, что времени на «сделать нормально» никогда нет и не будет.
Есть тикеты, есть время в них — у менеджера есть механизм постоянно контроля процесса — что еще нужно? Да всем плевать, что я вчера сделал и какие проблемы у меня возникли. А еще гигантское кол-во времени, которое тратят технические специалисты на всякие груминги, планирование, ретроспективу — я бы не назвал это «минималистичным».
В разработке (не сайтов-визиток, конечно же) слишком мало типичных задач, которые бы хорошо подходили под планирование. Оценки всегда врут, обычно они или излишне оптимистичны, или их таковыми делают, потому как «Вы что?! Заказчик не поймет!», соотв. эта тупая гонка в рамках спринта за вымпел победителя соц. соревнования с наплевательским отношением к качеству приводит к огромным долгам в разработке («потом сделаем нормально»), которые, в купе с почти всегда трусливой позицией менеджмента по отношению к клиенту, приводят к тому, что времени на «сделать нормально» никогда нет и не будет.
Есть тикеты, есть время в них — у менеджера есть механизм постоянно контроля процесса — что еще нужно? Да всем плевать, что я вчера сделал и какие проблемы у меня возникли. А еще гигантское кол-во времени, которое тратят технические специалисты на всякие груминги, планирование, ретроспективу — я бы не назвал это «минималистичным».
Не у всех все так плохо
А вы можете предложить годную альтернативу Скраму (канбану, рупу, вотерфолу), которая лишена всех этих недостатков, и к тому же менеджер доволен? :)
Да, она называется здравый смысл и вот это. Бывают случаи, когда «гибкая» разработка не работает, и нужно тщательно обозначить требования заранее и заняться архитектурой. Бывает наоборот. Бывают легаси-проекты, где есть трудновоспроизводимые баги, фикс которых ну никак ты не спланируешь в спринт. А зачастую получается скрам ради скрама. Третий раз переносим тикеты из спринта в спринт, ну не успели, а тут еще и тим хелс падает. А бывают маленькие команды по 3-4 человека на проект. Все проекты (ну, может кроме уж очень крупных типа банковских систем) очень сильно между собой отличаются и хорошо работающая команда всегда отличается здоровой головой (ПМ и клиент), а не строгим следованием некой методологии. Люди решают.
Вы смешали в одну кучу теплое с мягким.
Скрам — не методология, которая диктует «как жить», а фреймоврк, который должен быть адаптирован под существующие в компании реалии.
Что работает в одних случаях, не работает в других — универсальных рецептов нет.
Скрам — не методология, которая диктует «как жить», а фреймоврк, который должен быть адаптирован под существующие в компании реалии.
Что работает в одних случаях, не работает в других — универсальных рецептов нет.
Извините, но мне непонятен смысл понятия «фреймворк» в отношении организации процесса. И что такое в вашем понятии «адаптация»?
Извините, но мне непонятен смысл понятия «фреймворк» в отношении организации процесса.Это стратегия, а не имплементация.
И что такое в вашем понятии «адаптация»?Это уже имплементация (применение стратегии) в конкретной компании/команде.
Например, как ставить задачи и определение DoD.
Слишком общие фразы. Непонятно, насколько сильно ваш фреймворк нужно изменять под конкретные нужды, и с учетом объема правок — нужен ли он вообще.
Непонятно, насколько сильно ваш фреймворк нужно изменять под конкретные нужды, и с учетом объема правок — нужен ли он вообще.Фреймворк не мой, и я без понятия что происходит в вашей компании и какая адаптация вам нужна или не нужна.
Слишком общие фразы.На любые вопросы даю любые ответы.
Сейчас это выглядит как «Убедите меня что скрам хорош», а это, увы, не мой профиль.
Будут конкретные вопросы по конкретной теме, по мере своих возможностей дам конкретный ответ.
Вы, верно, меня не правильно поняли. Я ни в коем случае не утверждаю что азм есм скрам, и кто не скрам — неверный.
Я рассматриваю различные методологии (и подходы) и стараюсь проанализировать их достоинства и недостатки с организационной и психологической точки зрения.
Я рассматриваю различные методологии (и подходы) и стараюсь проанализировать их достоинства и недостатки с организационной и психологической точки зрения.
Да всем плевать, что я вчера сделал и какие проблемы у меня возникли.
Я такое видел, когда люди, которые формально причисленны к одной команде работают над ворохом слабо связанных задач. Если люди работают надо одной областью, то им интересно, какие возникают у кого проблемы и как другим помочь.
Я такое видел, когда люди, которые формально причисленны к одной команде работают над ворохом слабо связанных задач. Если люди работают надо одной областью, то им интересно, какие возникают у кого проблемы и как другим помочь.
Для меня даже еженедельно отчитываться о проделанной работе — это стресс. Каждый раз мысленно вжимаю голову в плечи, ожидая упрёка «а почему так мало». Каждый день — это вообще кошмар, потому что бывают дни, когда вообще «мысль не идёт».
Каждый раз мысленно вжимаю голову в плечи, ожидая упрёка «а почему так мало».Что-то не так в Датском королевстве.
Каждый день — это вообще кошмар, потому что бывают дни, когда вообще «мысль не идёт».Все мы люди, все мы человеки. Такие ситуации не редкость.
В скраме ежедневные «отчеты» не для того, чтоб шпинять «лентяев», а для выявления и решения проблем как можно раньше.
По нормальному такая ситуация разрешается коллективным разумом/отдачей таски другому участнику/выделением дополнительного времени.
Ну а если у вас «таких дней» 15 из 20, то следует задуматься о смене работы.
вот как раз из-за того, что люди боятся упреков за работу — такие инструменты и делают.
если бы каждый сотрудник был готов сразу придти к менеджеру и честно сказать «у меня проблема, вот тут можем зфакапить. надо решать, но у меня не полчается» — стендапы были бы не нужны :)
если бы каждый сотрудник был готов сразу придти к менеджеру и честно сказать «у меня проблема, вот тут можем зфакапить. надо решать, но у меня не полчается» — стендапы были бы не нужны :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкая методология разработки “Scrum”