Size: a a a

Agile, Scrum, Lean, Kanban, XP

2021 May 06

АЛ

Артем Летюшев... in Agile, Scrum, Lean, Kanban, XP
Никогда не понимал, зачем привязывать нормальный менеджмент, лидерство и адекватные процессы к какой-то конкретной концепции. Как будто без условного SAFe организация рухнет, будет разлад и люди резко разучатся работать
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Согласна, к тому же менеджмент с лидерством, как его преподносит скрам, к примеру, вполне возможен и даже желателен. Образ ПМа с палкой давно устарел и потерял актуальность. Закоучить само-организующуюся команду - так это же мечта. Но крип-менеджмент от того, что мы сделаем спринты, не станет поставлять качественно и то, что клиент хочет.

Более того, ценности скрама нести в команду и самому перенять крайне желательно. Использовать практики - ретро, к примеру. Может для кого-то секрет, но ретро можно делать без скрама. Или общее планирование…да что угодно. Синки.
источник

AP

Aleksei Pimenov in Agile, Scrum, Lean, Kanban, XP
Если вам нужно больше 1 спринта на реализацию, то ставится под вопрос их необходимость или их длина
источник

AP

Aleksei Pimenov in Agile, Scrum, Lean, Kanban, XP
я тут присоединюсь. Ведь есть еще одна вещь: то что работает у одних (в их контексте) не работает у других и часто у экспертов тут возникает trollface с фразой: меняйте контекст. И тогда уже становится имплементация фреймворка ради фреймворка а не ради результата
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
🤝
источник

ДШ

Данила Шалыгин... in Agile, Scrum, Lean, Kanban, XP
❤️
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Ретро - бомбическая тема. А обратная связь в целом позволила лично мне состояться как профессионалу (все свои беседы с коллегами теперь заканчиваю фразами: вопросы, замечания, предложения?)
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Просто для этого думать надо. Управление самоорганизующимися системами - предпоследний уровень сложности в управлении.

А не хочется/не можется. В итоге через шишки доходит. Самое неприятное в этой ситуации, когда ошибки делает один, а шкуры страдают у других :(

В последнем случае ещё и необучаемость появляется, лол
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Пример авторетроспективы (?) https://t.me/internetculture/198
Telegram
Интернет-культура
​​Собственный AI-коуч и гештальт-терапия в VR

В ТикТоке можно встретить видео, где пользователи делают дуэты с самими собой, такие как ниже (говоря простыми словами, записывают видеоответы на свои же видео из прошлого). В таких дуэтах пользователь, как правило, в первом видео озвучивает свои желания и цели и подбадривает самого себя, а во втором отвечает, что из всего этого у него получилось. Как правило, ему удается достичь многих поставленных целей.

В гештальт-терапии существует "метод пустого стула", где пациенту предлагается представить напротив себя какую-то значимую фигуру (или самого себя) и рассказывать ему/ей о своей проблеме. Таким образом, пациент учится наблюдать за собой со стороны, развивая навык осознавания собственных потребностей и ожиданий. Эксперимент с "пустым стулом" успешно провели в Барселонском Университете: там в VR пациент рассказывал о своей проблеме виртуальному Фрейду, а затем пациенту предлагалось взглянуть на 3D-модель самого себя глазами Зигмунда, и дать самому себе совет по…
источник

СШ

Сергей Шаблонов... in Agile, Scrum, Lean, Kanban, XP
Вот я был таким "нормальным" менеджером в крупной компании и выступал в роли заказчика продукта, и все крутилось, и люди бегали и продукт достигал клиентов, и с контролем у меня все было хорошо и административным управлением и с критическим мышлением, а еще и ИТ-бэкграундом, так что людей в пурпур загонял на раз. Сейчас стыдно вспомнить. А тогда считал это круто, целей-то достигал, что удивительно, только на цену не смотрел и на людей тоже. А потом просочился свет в тоннеле, спасибо ребятам из ScrumTrek.

Проблема в том, что многие нормальные менеджеры и лидеры считают, что разрабатывать ПО можно теми же методами, как и управлять производством. А об этом хорошо пишет в Forbes Стив Деннинг "Компании на собственном горьком опыте усваивают, что программное обеспечение требует иного способа управления организацией для достижения успеха. И этот вид управления выходит за рамки возможностей лесопиления промышленных гигантов 20- го века" (статья "Why Agile Is Eating The World")
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Спасибо за наводку на статью!)
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Вы навели меня на воспоминания из художественного опыта. Накропал заметку https://t.me/antxt/1048 )
Telegram
Аналитика для всех желающих
Искусство как передовой отряд общества-1

https://www.forbes.com/sites/stevedenning/2018/01/02/why-agile-is-eating-the-world%E2%80%8B%E2%80%8B/?sh=6d2a16b94a5b - спасибо коллегам за наводку на статью о том, почему Agile захватывает мир.

Преимущество этого подхода ясно видно в искусстве. Например, при лепке из пластилина можно:
А. Взять большой кусок и начать из него вытягивать форму, то есть требуется изначально рассчитать какую долю общей массы вытянуть на ноги, какую долю на руки, сколько на голову. В итоге получаютсч очень странные фигуры с родовыми травмами
Б. Можно отщипывать небольшие кусочки и им прилаживать требуемую форму.

В первом случае у нас подход прескрипитивный, во втором - гибкий подход к разработке скульптуры. Второй ясно дело используется художниками по умолчанию.

Попробуйте, купите пачку пластилина, не пожалейте нескольких сотен на скульптурный пластилин, все прочувствуете :)

При этом данный подход прилаживания можно игнорировать, так как из детского пластилина можно тянуть что угодно …
источник
2021 May 07

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Спасибо за статью! Вот, именно то, что там написано - лидерство 21 века👍🏻
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
🙌🏻
источник

YG

Yuri Geronimus in Agile, Scrum, Lean, Kanban, XP
Здравствуйте!
Окажите консультацию, нужно скрестить ежа с ужом: компания продает проекты, но ведет деятельность по Agile.
Расскажите что вы думаете по этому поводу 🙏

🗣 Вот что у них говорят люди:
- Руководитель проектов: «Я отвечаю за проект». Но он не отвечает за проект, за проект отвечает сотрудник выше, а у него какое-то направление внутри проекта. Да и на вопрос про деньги он тоже ответить не может.
- Product Manager: «Я отвечаю за проект». Но он не отвечает за проект, он отвечает только за … формирование требований… Да и вообще пока не понятно за что.
- Product Owner: «Я отвечаю за проект». Но он не отвечает за проект, он отвечает за реализацию в срок требований, которые ему принесет Product Manager, его же аналитики или кто-то еще.
- Team lead: «Я отвечаю за проект». Но он не отвечает за проект, он отвечает за реализацию в срок требований.

😱 В общем все «отвечают» за клиентский проект, и никто не отвечает за клиентский проект.

📝 Думали что с этим делать… Решили что надо исходить из таких принципов:
1. Должен быть один ответсвенный по темам, иначе руководитель будет выполнять роль руководителя проекта по всем проектам.
2. Скрещивание должно быть по доступной методологии, чтобы сотрудникам было где почитать. Это чтобы руководителю не тратить на объяснение все силы, чтобы мог просто сказать «читать там». И чтобы «не изобретать велосипед»
3. Сохранить Agile-практики так как в проектах в начале реально не понятно что делать.  
4. Все роли должны быть одним из двух типов - «бизнес» (отвечают за какой-то бизнес-результат) и «сервисные» (меряются удовлетворенностью).

Пока думем так - нужно вводить три слоя управления (по ссылкам описание ролей из SAFE):
1️⃣ На уровне проекта:
- Сотрудник Business owner - отвечает перед компанией и Заказчиком за успешность проекта (сроки, деньги, удовлетворенность). Отвечает “за всё”. Может использовать практики руководителя проекта (что резонно т.к. его объект - проект). Может делать иерархию business owner по направлениям у себя в «подпроектах» или уровнях ниже.

2️⃣ На уровне Solution (ИТ-решения). В проекте может быть их несколько
- Оргфункция Product and Solution Management - отвечает за удовлетворение потребностей Клиента и за удовлетворенность Клиента и Business owner. Формирует список фич продукта.
- Оргфункция Solution architect - отвечает за разработку технического решения по реализации фич и удовлетворенность Product and Solution Management, Business Owner
- Сотрудник RTE - отвечает за выполнение и улучшение процесса, синхронизацию команд и удовлетворенность всех

3️⃣ На уровне Команды. Для одного ИТ-решения может быть несколько команд
- Сотрудник Product Owner - отвечает за формирование бэклога (приоритизированного списка) Agile team (включая оптимальное разбиение фич на user story) и удовлетворенность всех на уровне выше
- Agile team - выполнение бэклога и удовлетворенность Product Owner (внутри могут быть архитекторы, тимлиды и т.д., можно организовывать процесс как хотите)
- Сотрудник Scrum Master - отвечает за выполнение и улучшение процесса и удовлетворенность Agile team и Product Owner

* Один сотрудник может выполнять несколько ролей
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Добрый день! А кроме отвественности - на что может влиять и чем управлять роль (например, ПО - обязанности понятны, но какие права)?
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Смотрится интересно, с ходу проблем не нашёл, думаю в ходе реализации ещё подправите, и будет норм
источник

YG

Yuri Geronimus in Agile, Scrum, Lean, Kanban, XP
Добрый день, Jane!
Это пока не рассматривали… Считаем пока что они уторгуют права сами (так как считаем, что это зависит от конкретных практик работы по которым они проекты делают, а они разнеы). Понятно что точно есть список требований, потребностей. Список требований точно в бэклоге должен быть. А все остальное очень разным кажется… Но это пока, туда еще не опускались…
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Просто обычно это как раз камень преткновения - ответственные назначены, но решать мы им ничего не дадим (будем и тактические, и стратегические, и про инструменты, и как кодить - все спускать сверху). Так что обратите внимание.
источник

YG

Yuri Geronimus in Agile, Scrum, Lean, Kanban, XP
Спасибо, Jane! В первом приближении как раз не кажется что так надо делать в этом кейсе, кажется что надо ответственность, а дальше уже самим торговаться друг с другом внутри. Чтобы избежать того, о чем вы пишите
источник