Будьте уникальны. Есть два пути. Первый — это гиперспециализация. Вы можете стать экспертом по особому виду экземы, тесту, спорту, музыкальному инструменту или еще чему-нибудь. Фокус, фокус, фокус, а затем становитесь глобальным. Второй — вы добиваетесь успеха путем дефисирования, написания через дефис, то есть комбинирования противоположностей. Настройщики-технологи, визуальный-эргономист, психо-лингвисты уже ходят по земле.
Немного не так — если то, что вы делаете дополняет скрам или ему противоречит, то есть вероятность, что в провале проекта виноват не скрам, а ваши дополнения и противоречия
И еще. Для искажённого скрама есть отдельное название "scrumbut" ("скрамно") https://www.scrum.org/scrumbut так, что наверное стоит использовать его. "у нас внедрили скрамно, в результате все уводились"
Интересно, какая должна быть методология чтобы зарезать себя использовать неправильно? Даже в том случае, когда можно выполнять не все предписания или не полностью из гацда придумывать свое и все равно называть это ее именем? Есть скрам мастеру и сертификация оных, но все равно недостаточно. Мне кажется это должно быть тайное общество и методология должна называться секретно. То есть ее имя открывается только тому, кому верховный методолог разрешил, убедившись, что он усвоил ее букву и дух. И жестоко карать отступников.
Да в моей вселенной хорошие отношения на работе и менеджеры не давят на цифирьки и понимают, если им объяснить.
А в вашей вселенной получается вы работаете как-то так, что никаких чисел нельзя вычислить. Например в языке принципиально нельзя подсчитать количество строк кода, а то бы менеджеры их просили и за них дрючили.
… и попадаете в «чёрный список», потому что из-за вас количество UserStory, реализованных за спринт начинает падать, ваш отдел получает славу «скандалистов» и т.д. Оно вам надо?
Не могли бы вы процитировать кусок скрамгайда, относящийся к черным спискам? Вероятно, у вас какой-то опыт работы в конторах с не очень хорошими отношениями между начальством и подчиненными и вы накладываете это на скрам. Но весь эффект получается от именно этого отношения, а не от скрама
Это — месяца два работы, как минимум. Вы хотите это одним таском оформить?
Я не в теме. X может быть hello world, например. Или мигнуть виртуальной лампочкой.
Вы думаете кто-то, кому платят за выполнение «тасков» туда полезет разбираться?
В скраме команде платят не только за выполнение тасков. Таски это просто способ координировать работу команды
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
При чем тут Scrum? Он никак не предписывает разбивать спринты по командам процессора и не держать в уме всю архитектуру. Более того, реализация n команд — плохая цель спринта с моей точки зрения. Правильная цель спринта — "Дать пользователю запустить X на эмуляторе" — то есть декомпозиция должна быть вертикальной. Дальше команда может разбить инкремент спринта технически, если это надо — хотите по командам, хотите по группам битов внутри команд.
Что можно сделать при использовани скрама и тому подобных вещей? Создать 100 «тасков» на пару часов каждый и начать реализовывать эти инструкции. За месяц с небольшим задача будет решена (40-часовая неделя, всё такое).
Почему вы считаете, что скрам требует такого подхода? В рамках планирования спринта и груминга беклога команда может решить что это все одна User story. Или побить по видам команд. См также "Вертикальная декомпозиция"
Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов.
В скрам встроенны ретроспективы как способ выразить идеи и проблемы. Если для бизнеса в данный момент важно ускорять систему в два раза, то PO может одобрить такой айтем в беклоге.
https://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes
Я думаю, никакая методология не даст хорошего результата на ваших "типичных менеджерах". Надо им развиваться в нетипичных.
Бизнес в стиле фанк:
Вы просто привыкли к таким менеджерам и вам кажется, что других не бывает :)
Немного не так — если то, что вы делаете дополняет скрам или ему противоречит, то есть вероятность, что в провале проекта виноват не скрам, а ваши дополнения и противоречия
Я этот термин уже видел, да и искать его проще https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%D1%81%D0%BA%D1%80%D0%B0%D0%BC%D0%BD%D0%BE
И еще. Для искажённого скрама есть отдельное название "scrumbut" ("скрамно") https://www.scrum.org/scrumbut так, что наверное стоит использовать его. "у нас внедрили скрамно, в результате все уводились"
Интересно, какая должна быть методология чтобы зарезать себя использовать неправильно? Даже в том случае, когда можно выполнять не все предписания или не полностью из гацда придумывать свое и все равно называть это ее именем? Есть скрам мастеру и сертификация оных, но все равно недостаточно. Мне кажется это должно быть тайное общество и методология должна называться секретно. То есть ее имя открывается только тому, кому верховный методолог разрешил, убедившись, что он усвоил ее букву и дух. И жестоко карать отступников.
Получается, в вашем мире вам нельзя использовать гитхаб и багтрекеры — все что позволяет считать статистику. Давайте лучше к нам!
Да в моей вселенной хорошие отношения на работе и менеджеры не давят на цифирьки и понимают, если им объяснить.
А в вашей вселенной получается вы работаете как-то так, что никаких чисел нельзя вычислить. Например в языке принципиально нельзя подсчитать количество строк кода, а то бы менеджеры их просили и за них дрючили.
Не могли бы вы процитировать кусок скрамгайда, относящийся к черным спискам? Вероятно, у вас какой-то опыт работы в конторах с не очень хорошими отношениями между начальством и подчиненными и вы накладываете это на скрам. Но весь эффект получается от именно этого отношения, а не от скрама
Я не в теме. X может быть hello world, например. Или мигнуть виртуальной лампочкой.
В скраме команде платят не только за выполнение тасков. Таски это просто способ координировать работу команды
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
При чем тут Scrum? Он никак не предписывает разбивать спринты по командам процессора и не держать в уме всю архитектуру. Более того, реализация n команд — плохая цель спринта с моей точки зрения. Правильная цель спринта — "Дать пользователю запустить X на эмуляторе" — то есть декомпозиция должна быть вертикальной. Дальше команда может разбить инкремент спринта технически, если это надо — хотите по командам, хотите по группам битов внутри команд.
Почему вы считаете, что скрам требует такого подхода? В рамках планирования спринта и груминга беклога команда может решить что это все одна User story. Или побить по видам команд. См также "Вертикальная декомпозиция"
Была идея написать на PoSh игру, где надо было бы управлять коммандлетами Get-Enemies | ?{ $_.Distance < 20 } | %{ Kill-Enemy }
А что надо пофиксить в методике?
Мне пока приходит в голову:
Почему бесполезно анализировать причины косяков?
Именно чтобы предотвартить будущие косяки, надо анализировать причины прошлых
То, что вы описали задачи скорее продакт овнера и команды разработчиков, а не скрам мастера :)
Это может быть проблема, невидимая руководству. В данный конкретный момент.
В скрам встроенны ретроспективы как способ выразить идеи и проблемы. Если для бизнеса в данный момент важно ускорять систему в два раза, то PO может одобрить такой айтем в беклоге.