Forwarded from Dodo Engineering via @like
В конце прошлого года мы задумались над созданием манифеста для разработчиков. Идея повисла в воздухе...
И буквально на прошлой неделе руками Alexander Andronov (СТО Dodo Pizza) она преобразовалась в 7 важных для нас вещей:
1. Nobullshit
Если какой-то процесс не приносит ценности, давай избавимся от него. Здравый смысл и доверие — вот наши инструменты.
2. Гемба
Наш бизнес — это совмещение IT и оффлайн. Разработчики и управляющие пиццерией сидят рядом, постоянно общаются и работают рука обруку над созданием Dodo IS. Закодил — сразу видишь, насколько рад пиццамейкер новым фичам.
3. Инженерная культура
Лучшие инженерные практики: разработка маленькими шагами, постоянный рефакторинг кода, покрытие кода быстрыми и читаемыми юнит-тестами, бесшовная выкладка на боевое окружение. Качество встраивается в процесс.
4. Команда важнее
Команда — это нечто большее, чем просто группа людей. Команда, где каждый дополняет друг друга, подходит друг другу, может сделать то, что другим не под силу. Цени свою команду и помогай ей развиваться.
5. Фокус
Фокусируйся на главном. Отбрось то, что не важно. Не пытайся взять 20 задач и делать все подряд, ведь тогда ты не сделаешь ничего. Сделать что-то одно важнее, чем делать 20.
6. Ответственность
Менять жизнь 10 миллионов клиентов с помощью кода. Да, цена ошибки высока и мы несём ответственность перед миллионами клиентов, десятками тысяч сотрудников Додо. Нам не всё равно.
7. Постоянный рост
Расти можно только тогда, когда ты делаешь то, чего не делал раньше. Бери сложные задачи, бери то, чего не делал раньше. Ошибёшься — не бойся, пробуй снова. Только так возможен рост.
И буквально на прошлой неделе руками Alexander Andronov (СТО Dodo Pizza) она преобразовалась в 7 важных для нас вещей:
1. Nobullshit
Если какой-то процесс не приносит ценности, давай избавимся от него. Здравый смысл и доверие — вот наши инструменты.
2. Гемба
Наш бизнес — это совмещение IT и оффлайн. Разработчики и управляющие пиццерией сидят рядом, постоянно общаются и работают рука обруку над созданием Dodo IS. Закодил — сразу видишь, насколько рад пиццамейкер новым фичам.
3. Инженерная культура
Лучшие инженерные практики: разработка маленькими шагами, постоянный рефакторинг кода, покрытие кода быстрыми и читаемыми юнит-тестами, бесшовная выкладка на боевое окружение. Качество встраивается в процесс.
4. Команда важнее
Команда — это нечто большее, чем просто группа людей. Команда, где каждый дополняет друг друга, подходит друг другу, может сделать то, что другим не под силу. Цени свою команду и помогай ей развиваться.
5. Фокус
Фокусируйся на главном. Отбрось то, что не важно. Не пытайся взять 20 задач и делать все подряд, ведь тогда ты не сделаешь ничего. Сделать что-то одно важнее, чем делать 20.
6. Ответственность
Менять жизнь 10 миллионов клиентов с помощью кода. Да, цена ошибки высока и мы несём ответственность перед миллионами клиентов, десятками тысяч сотрудников Додо. Нам не всё равно.
7. Постоянный рост
Расти можно только тогда, когда ты делаешь то, чего не делал раньше. Бери сложные задачи, бери то, чего не делал раньше. Ошибёшься — не бойся, пробуй снова. Только так возможен рост.
Привет! Спешу поделиться потрясающим по своей насыщенности постом о законе Конвея от Ивана Евтухова.
Суть закона: «Организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникации в этой организации».
«Из этого закона есть логичный вывод, а что если нам не „натягивать“ новый продукт на существующую организацию, а создавать организацию под новый продукт. Такая простая мысль, а так сложно ее реализовать. Ведь в любой организации, особенно крупной, все роли поделены и любая попытка рыпнуться вызывает политическое сопротивление, ведь у кого-то после этого власти станет меньше, а у кого-то и больше. И чтобы не тратить силы на политическую войну, люди договариваются делать что-то новое по-старинке, в рамках существующей оргструктуры.»
Попытки «натянуть» продукт на существующую оргструктуру приводят к чрезмерному количеству совещаний для синхронизации, ненужным ролям и странным KPI.
«Как только продуктовая команда сможет делать свои дела, ни с кем не особо не договариваясь и никого не ожидая, дело пойдет совсем с другой скоростью. »
В общем, однозначный мастрид в первый день новой рабочей недели.
http://evtuhovich.ru/blog/2016/10/05/conways-law/
Суть закона: «Организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникации в этой организации».
«Из этого закона есть логичный вывод, а что если нам не „натягивать“ новый продукт на существующую организацию, а создавать организацию под новый продукт. Такая простая мысль, а так сложно ее реализовать. Ведь в любой организации, особенно крупной, все роли поделены и любая попытка рыпнуться вызывает политическое сопротивление, ведь у кого-то после этого власти станет меньше, а у кого-то и больше. И чтобы не тратить силы на политическую войну, люди договариваются делать что-то новое по-старинке, в рамках существующей оргструктуры.»
Попытки «натянуть» продукт на существующую оргструктуру приводят к чрезмерному количеству совещаний для синхронизации, ненужным ролям и странным KPI.
«Как только продуктовая команда сможет делать свои дела, ни с кем не особо не договариваясь и никого не ожидая, дело пойдет совсем с другой скоростью. »
В общем, однозначный мастрид в первый день новой рабочей недели.
http://evtuhovich.ru/blog/2016/10/05/conways-law/
evtuhovich.ru
Закон Конвея
Мелвин Конвей в 1968 году (48 лет назад!) опубликовал свою работу, в
которой сформулировал следующую идею: «Организация, которая создает систему, ограничена дизайном, который копирует
структуру коммуникации в этой организации». Более просто эту идею перефразировал…
которой сформулировал следующую идею: «Организация, которая создает систему, ограничена дизайном, который копирует
структуру коммуникации в этой организации». Более просто эту идею перефразировал…
#ценности #scrumValues #ретроспектива
Поговорим о Scrum ценностях. В самом начале моего пути я не обращал на них внимание и считал, что это какая-то ненужная фигня (готовясь к первому собеседованию на позицию Скрам Матера я просто пропустил этот блок в скрам гайде). Но чем больше я работаю с командами, тем больше понимаю, что ценности Scrum - краеугольный камень всего фреймворка. Чем сильнее члены Scrum команды привержены ценностям, тем эффективнее работает сам фреймворк: уберите одну из них и постепенно ваш Scrum начнет хромать, а затем совсем «загнется» и превратится во что угодно, но только не Scrum.
Подробнее о ценностях можно почитать здесь: https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/
Хочу поделиться с вами сценарием ретроспективы, в рамках которой вы можете обсудить с командой ценности Scrum, определить какие из них больше всего «страдают» и обозначить шаги по развитию приверженности данным ценностям внутри команды.
1. Короткий рассказ о ценностях (15 минут)
2. Команда совместно определяет, какие ценности сильнее всего «страдают» (dot-voting) (5 минут)
3. Разделение на небольшие группы (2-3 в зависимости от размера команды) и обсуждение наиболее «слабых» ценностей (одна команда - одна ценность). Что происходит с командой и фреймворком, если данная ценность игнорируется? Какие анти-паттерны формируются? (5 минут)
4. Короткое обсуждение между группами последствий игнорирования определенных ценностей (5 минут)
5. Каждая группа определяет, какие действия/события усиливают определенную ценность, а какие - разрушают ее. (Одна группа - одна ценность) (7 минут)
6. Группы презентуют результаты своей работы и при необходимости дополняют друг друга. (15 минут)
7. Команда обсуждает, какие конкретные действия нужно предпринять на основании прошедшего обсуждения для того чтобы повысить приверженность к ценностям Scrum. (10 минут)
Рекомендую проводить данную ретроспективу уже после того, как команда поняла суть эмпирического процесса и понимает значимость каждого события фреймворка (не раньше чем через 5-10 спринтов).
Поговорим о Scrum ценностях. В самом начале моего пути я не обращал на них внимание и считал, что это какая-то ненужная фигня (готовясь к первому собеседованию на позицию Скрам Матера я просто пропустил этот блок в скрам гайде). Но чем больше я работаю с командами, тем больше понимаю, что ценности Scrum - краеугольный камень всего фреймворка. Чем сильнее члены Scrum команды привержены ценностям, тем эффективнее работает сам фреймворк: уберите одну из них и постепенно ваш Scrum начнет хромать, а затем совсем «загнется» и превратится во что угодно, но только не Scrum.
Подробнее о ценностях можно почитать здесь: https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/
Хочу поделиться с вами сценарием ретроспективы, в рамках которой вы можете обсудить с командой ценности Scrum, определить какие из них больше всего «страдают» и обозначить шаги по развитию приверженности данным ценностям внутри команды.
1. Короткий рассказ о ценностях (15 минут)
2. Команда совместно определяет, какие ценности сильнее всего «страдают» (dot-voting) (5 минут)
3. Разделение на небольшие группы (2-3 в зависимости от размера команды) и обсуждение наиболее «слабых» ценностей (одна команда - одна ценность). Что происходит с командой и фреймворком, если данная ценность игнорируется? Какие анти-паттерны формируются? (5 минут)
4. Короткое обсуждение между группами последствий игнорирования определенных ценностей (5 минут)
5. Каждая группа определяет, какие действия/события усиливают определенную ценность, а какие - разрушают ее. (Одна группа - одна ценность) (7 минут)
6. Группы презентуют результаты своей работы и при необходимости дополняют друг друга. (15 минут)
7. Команда обсуждает, какие конкретные действия нужно предпринять на основании прошедшего обсуждения для того чтобы повысить приверженность к ценностям Scrum. (10 минут)
Рекомендую проводить данную ретроспективу уже после того, как команда поняла суть эмпирического процесса и понимает значимость каждого события фреймворка (не раньше чем через 5-10 спринтов).
Ullizee-Inc
There’s value in the Scrum Values
Notice: following is my original description of the Scrum Values. I won’t be touching this description. I have however since the inception of this description (2012) slightly updated the desc…
Привет!
Поиски края интернета снова не прошли даром. Наткнулся на законы об организационном поведении, сформулированные Крэгом Ларганом (создатель LeSS, консультант и software engineer).
Вот они:
1. Организации устроены таким образом, чтобы избегать изменений структуры власти, статуса-кво между топ- и средним менеджментом, а также между средним-менеджментом и специалистами.
2. Первое следствие из п.1 – любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей тоже самое, что и до изменений, но позволяющей поддерживать статус-кво.
3. Второе следствие из п.1 – любая инициатива по изменению будет высмеяна как «пуристическая», «теоретическая», «излишне революционная» и «требующая приземления на реалии организации», что мешает началу работ по устранению существующих проблем и сохраняет статус-кво руководителей и специалистов.
4. Культура подчиняется структуре (следует за ней).
Исходя из этих законов становится понятно, почему SAFe так легко «заходит» крупным корпорациям в отличие от Scrum и LeSS. В то же время проясняется ситуация, почему SAFe не всегда приводит «взрыву» производительности и повышению вовлечённости: сотрудники просто меняют таблички на кабинетах, а вся схема коммуникаций остаётся прежней. Есть о чем подумать.
Трансформация это больно.
На русском с законами можно познакомиться здесь: https://m.habr.com/ru/company/scrumtrek/blog/320832/
Оригинал для гурманов вот тут: http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
Поиски края интернета снова не прошли даром. Наткнулся на законы об организационном поведении, сформулированные Крэгом Ларганом (создатель LeSS, консультант и software engineer).
Вот они:
1. Организации устроены таким образом, чтобы избегать изменений структуры власти, статуса-кво между топ- и средним менеджментом, а также между средним-менеджментом и специалистами.
2. Первое следствие из п.1 – любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей тоже самое, что и до изменений, но позволяющей поддерживать статус-кво.
3. Второе следствие из п.1 – любая инициатива по изменению будет высмеяна как «пуристическая», «теоретическая», «излишне революционная» и «требующая приземления на реалии организации», что мешает началу работ по устранению существующих проблем и сохраняет статус-кво руководителей и специалистов.
4. Культура подчиняется структуре (следует за ней).
Исходя из этих законов становится понятно, почему SAFe так легко «заходит» крупным корпорациям в отличие от Scrum и LeSS. В то же время проясняется ситуация, почему SAFe не всегда приводит «взрыву» производительности и повышению вовлечённости: сотрудники просто меняют таблички на кабинетах, а вся схема коммуникаций остаётся прежней. Есть о чем подумать.
Трансформация это больно.
На русском с законами можно познакомиться здесь: https://m.habr.com/ru/company/scrumtrek/blog/320832/
Оригинал для гурманов вот тут: http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
Хабр
Законы Лармана об организационном поведении
Перевод статьи Craig Larman «Larman's Laws of Organizational Behavior» выполнен Лилией Алексеевой (Agile-евангелист, Сбербанк) с разрешения автора. Я провёл десятки лет, консультируя различные...
«Главное качество лидера - энергия, а не интеллект» - Пьер Касс.
Согласны?
Согласны?
«Производительность Agile команды» - очень крутой тренинг от Анны Обуховой. Три дня чистого удовольствия. Регистрация и подробная информация здесь: https://scrumtrek.ru/product/58/proizvoditelnost-agile-komandi/
#владелецПродукта #стейкхолдер #управлениеБэклогом
Ведущего аналитика от Владельца Продукта отличает умение правильно сказать «нет» на запрос стейкхолдера включить в бэклог продукта очередную фичу с НУЛЕВЫМ приоритетом. Как это сделать и при этом сохранить свое место в компании?
Майк Кон написал хорошую статью, где поделился полезными советами о том, как «правильно» отказывать заинтересованным лицам.
Ключевые тезисы:
1. Будьте предельно точны: это окончательное «нет» или «нет» в текущий момент (обозначьте время и условия при которых будете готовы вновь вернуться к разговору).
2. Не забывайте про уважение и эмпатию. Прежде чем говорить «нет» убедитесь, что точно понимаете, почему данный функционал важен вашему стейкхолдеру.
3. Сфокусируйтесь на одном, самом весомом аргументе. Не упирайтесь рогами в землю, если понимаете, что ваша аргументация слаба и после разговора вы согласны с позицией стейкхолдера.
4. Обратитесь к видению продукта и ключевым целям. Если вы их разделяете, а новая фича идет в разрез с обозначенным направлением движения - у вас есть весомый повод отказать.
5. Расскажите о последствиях, в случае, если вы скажите «да».
6. Предложите альтернативные варианты. Возможно есть способ реализовать необходимый функционал менее затратным способом за счет изменения некоторых элементов бэклога.
Подробнее с советами Майка вы можете ознакомиться здесь: https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder
Ведущего аналитика от Владельца Продукта отличает умение правильно сказать «нет» на запрос стейкхолдера включить в бэклог продукта очередную фичу с НУЛЕВЫМ приоритетом. Как это сделать и при этом сохранить свое место в компании?
Майк Кон написал хорошую статью, где поделился полезными советами о том, как «правильно» отказывать заинтересованным лицам.
Ключевые тезисы:
1. Будьте предельно точны: это окончательное «нет» или «нет» в текущий момент (обозначьте время и условия при которых будете готовы вновь вернуться к разговору).
2. Не забывайте про уважение и эмпатию. Прежде чем говорить «нет» убедитесь, что точно понимаете, почему данный функционал важен вашему стейкхолдеру.
3. Сфокусируйтесь на одном, самом весомом аргументе. Не упирайтесь рогами в землю, если понимаете, что ваша аргументация слаба и после разговора вы согласны с позицией стейкхолдера.
4. Обратитесь к видению продукта и ключевым целям. Если вы их разделяете, а новая фича идет в разрез с обозначенным направлением движения - у вас есть весомый повод отказать.
5. Расскажите о последствиях, в случае, если вы скажите «да».
6. Предложите альтернативные варианты. Возможно есть способ реализовать необходимый функционал менее затратным способом за счет изменения некоторых элементов бэклога.
Подробнее с советами Майка вы можете ознакомиться здесь: https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder
Mountain Goat Software
Saying No to Stakeholders: 6 Tips for Product Owners
When customers ask for features a team can’t work on right away, it’s hard for product owners to turn them away.