АЦ
Наверное, если команда низкоэффективная с точки зрения - результат к затраченным усилиям, нужно пересматривать а нужно ли продолжать разрабатывать продукт ?
Size: a a a
2019 April 30
АЦ
И мне кажется, что внедрить скрам это не так просто как кажется. Для внедрения требуется как минимум изменения в орг дизайне. Ну а если говорить про маштабирование так к изменению орг дизайна добовлчется наличие хороших инженерных практик, обучение всех участников, и т.д. это не очень тривиальная задача.
AR
Алексей Цыбульник
И мне кажется, что внедрить скрам это не так просто как кажется. Для внедрения требуется как минимум изменения в орг дизайне. Ну а если говорить про маштабирование так к изменению орг дизайна добовлчется наличие хороших инженерных практик, обучение всех участников, и т.д. это не очень тривиальная задача.
V
Алексей Цыбульник
Так, ага. Но смотри, о чем говорит нам скрам гайд? Что владелец продукта несёт ответственность за достижения максимальной ценности продукта как результата работы команды. То есть владелец продукта управляет бэклогом для наилучшего достижения целей и оптимизацию ценности работы, выполняемой командой.
Скрамгайд может говорить что угодно.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
V
Алексей Цыбульник
И мне кажется, что внедрить скрам это не так просто как кажется. Для внедрения требуется как минимум изменения в орг дизайне. Ну а если говорить про маштабирование так к изменению орг дизайна добовлчется наличие хороших инженерных практик, обучение всех участников, и т.д. это не очень тривиальная задача.
Это называется «цена внедрения инструмента», да
AR
Скрамгайд может говорить что угодно.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Процессы? Нет, не должны.
V
Почему же нет?
AR
Почему же нет?
Потому, что Сю, Ха и Ри 🤷🏻♂😎
V
Потому, что Сю, Ха и Ри 🤷🏻♂😎
Можешь пожалуйста подробнее?
V
Процесс — такой же инструмент, как и технология.
AR
Да, напишу.
V
Спасибо
AR
Алексей Цыбульник
Так, ага. Но смотри, о чем говорит нам скрам гайд? Что владелец продукта несёт ответственность за достижения максимальной ценности продукта как результата работы команды. То есть владелец продукта управляет бэклогом для наилучшего достижения целей и оптимизацию ценности работы, выполняемой командой.
Алексей, хотел спросить, а как ты считаешь, backlog - это инструмент?))
АЦ
Алексей, хотел спросить, а как ты считаешь, backlog - это инструмент?))
Беклог продукта это артефакт в скраме
АЦ
Скрамгайд может говорить что угодно.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Скрам это фреймворк, в рамках которого можно использовать любые удобные инструмент для команды
AR
Алексей Цыбульник
Беклог продукта это артефакт в скраме
Ок, отмазался цитатами ))😂
АЦ
Скрамгайд может говорить что угодно.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Планирование, продуктивность и рост разработчиков эффективнее не в скраме.
Продукт разрабатывать нужно, если этому есть экономическое обоснование. Процессы должны подстраиваться под бизнес-требования и людей, а не наоборот. Процесс — инструмент.
Интересно, а где эффективнее развитие если не в complex домене?
АЦ
Ок, отмазался цитатами ))😂
Почему цитатами? Если я думаю что это так
V
Алексей Цыбульник
Интересно, а где эффективнее развитие если не в complex домене?
Я не о домене.
Я о скраме как инструменте.
Эффективнее, конечно же, индивидуальная работа. Индивидуальное планирование, индивидуальный рост
Я о скраме как инструменте.
Эффективнее, конечно же, индивидуальная работа. Индивидуальное планирование, индивидуальный рост
V
Алексей Цыбульник
Скрам это фреймворк, в рамках которого можно использовать любые удобные инструмент для команды
Нет, нельзя.
Нельзя дать разработчику задачу.
Нельзя дать разработчику задачу.