Comments 28
а разве product backlog берется не от product owner-а? точнее, откуда он берется у PO нас (SM и команду) не сильно волнует. нас интересует только чтобы в sprint backlog попадали «хорошие» истории.
про сторимаппинг с удовольствием бы послушал отзывы реального применения в духе «было — стало». тема интересная, но главным образом с практической точки зрения. слайды — это красиво, но не совсем то, что хотелось бы почитать.
на тему производительности: вы рассматриваете способы мотивации людей с развитой само-мотивацией. таких мотивировать несколько проще, поскольку можно играть на амбициях. людей со слабо развитой само-мотивацией такими вещами сложно мотивировать. их надо постоянно хвалить, отправлять на конференции в качестве награды, давать им карьерно расти, но не вертикально, а горизонтально и надеяться, что уровень их самомотивации когда-нибудь выростет. при всем при этом, это не означает, что они плохие сотрудники/работники. просто они другие.
про сторимаппинг с удовольствием бы послушал отзывы реального применения в духе «было — стало». тема интересная, но главным образом с практической точки зрения. слайды — это красиво, но не совсем то, что хотелось бы почитать.
на тему производительности: вы рассматриваете способы мотивации людей с развитой само-мотивацией. таких мотивировать несколько проще, поскольку можно играть на амбициях. людей со слабо развитой само-мотивацией такими вещами сложно мотивировать. их надо постоянно хвалить, отправлять на конференции в качестве награды, давать им карьерно расти, но не вертикально, а горизонтально и надеяться, что уровень их самомотивации когда-нибудь выростет. при всем при этом, это не означает, что они плохие сотрудники/работники. просто они другие.
Я собственно и написал, что в теории беклог продукта самым, что ни есть, волшебным образом появляется у владельца продукта :) На практике необходимы определенные усилия и трудозатраты.
Про сторимаппинг из опыта могу сказать следующее (именно практические вещи):
— у команды улучшается видение целей и содержания проекта;
— у команды улучшается мотивация к успешному завершению проекта;
— выявляются целы «пласты» функционала, про который обычно забывают;
— четче и прозрачней расставляются приоритеты и планируются релизы;
Про мотивацию вопрос очень сложный и, безусловно, надо сочетать как материальные способы, так и нематериальные. Ваш кэп :)
Про сторимаппинг из опыта могу сказать следующее (именно практические вещи):
— у команды улучшается видение целей и содержания проекта;
— у команды улучшается мотивация к успешному завершению проекта;
— выявляются целы «пласты» функционала, про который обычно забывают;
— четче и прозрачней расставляются приоритеты и планируются релизы;
Про мотивацию вопрос очень сложный и, безусловно, надо сочетать как материальные способы, так и нематериальные. Ваш кэп :)
Сейчас бОльшая проблема — как продать Agile. Видеодоклад Азхата Уразбаева хорош, но не ответил на главный вопрос — как?
До сих пор так и не нашёл примеров договоров в сфере созданий сайтов, допустим. Либо образец ТЗ или ещё чего нибудь что прикладывается к договору вместо ТЗ.
Проблема важная — бывает работаем по Agile, регулярно общаемся с заказчиком и лижем пятки, а оплата происходит по каскадной схеме — один раз и фиксированно.
До сих пор так и не нашёл примеров договоров в сфере созданий сайтов, допустим. Либо образец ТЗ или ещё чего нибудь что прикладывается к договору вместо ТЗ.
Проблема важная — бывает работаем по Agile, регулярно общаемся с заказчиком и лижем пятки, а оплата происходит по каскадной схеме — один раз и фиксированно.
Есть инсайд, что такие договора могут появиться после НГ :)
А договор по принципу «Продажа времени» не подходит? То есть клиент оплачивает вам стоимость команды в месяц
Точно, у нас все договоры с клиентами построены именно так: мы продаём часы. Бывают разные непонятки, но в целом все довольны.
А бывает, что команда ничего не делает, но за это получает ЗП?
К чему этот вопрос?
Нет, не бывает, потому что во-первых, люди хорошо мотивированы, а во-вторых, технические практики аджайла, в частности парное программирование, особо отвлекаться от работы не позволяют.
Нет, не бывает, потому что во-первых, люди хорошо мотивированы, а во-вторых, технические практики аджайла, в частности парное программирование, особо отвлекаться от работы не позволяют.
У вас парное программирование 100% рабочего времени?
Да.
Ну, бывают исключения, когда кто-то болеет, в отпуске или просто решил поэкспериментировать, но в целом да, 100% рабочего времени.
Ну, бывают исключения, когда кто-то болеет, в отпуске или просто решил поэкспериментировать, но в целом да, 100% рабочего времени.
Ужас. Сколько в среднем по времени человек держится у вас в конторе?
Ещё вопрос, вот у меня как у ПМ появляется большой соблазн не гнать команду, а дать возможность спокойно работать, с уходами пораньше, пивными вечеринками и т.д.
А когда есть сроки, то возможности по халявить обычно нет.
Ещё вопрос, вот у меня как у ПМ появляется большой соблазн не гнать команду, а дать возможность спокойно работать, с уходами пораньше, пивными вечеринками и т.д.
А когда есть сроки, то возможности по халявить обычно нет.
Ужас? :)
Вы пали жертвой стереотипов. Это не ужас, это крайне эффективный и интересный способ работы. Если, конечно, приоритетом для работника является именно эффективность, а не возможность посидеть в одиночестве и расслабиться.
Все, кто пришёл в нашу фирму, заранее знали, что будет 100% парного программирования, и никто до сих пор не ушёл.
А в чём вопрос-то?
Да, у нас тоже никто никого не гонит, люди могут, если надо, уйти пораньше, поиграть после обеда в настольный футбол и всё такое. Но все видят общий отчёт, где показано, кто сколько часов наработал за неделю. Если у всей фирмы за неделю меньше N часов — график красный, если больше — зелёный. Всё. Дальше у людей в головах всё щёлкает само как надо.
Вы пали жертвой стереотипов. Это не ужас, это крайне эффективный и интересный способ работы. Если, конечно, приоритетом для работника является именно эффективность, а не возможность посидеть в одиночестве и расслабиться.
Все, кто пришёл в нашу фирму, заранее знали, что будет 100% парного программирования, и никто до сих пор не ушёл.
А в чём вопрос-то?
Да, у нас тоже никто никого не гонит, люди могут, если надо, уйти пораньше, поиграть после обеда в настольный футбол и всё такое. Но все видят общий отчёт, где показано, кто сколько часов наработал за неделю. Если у всей фирмы за неделю меньше N часов — график красный, если больше — зелёный. Всё. Дальше у людей в головах всё щёлкает само как надо.
Вы не ответили на вопрос, сколько лет в среднем работает сотрудник на парном программировании? Какой средний возраст сотрудников? 23-25 лет?
Средний возраст не считал. Большинство людей 25-30 лет, и примерно четверть 30-50 лет.
Фирма существует 2 года, ПП используется 100% времени, стало быть в среднем сотрудник работает на парном программировании 2 года. Так?
Фирма существует 2 года, ПП используется 100% времени, стало быть в среднем сотрудник работает на парном программировании 2 года. Так?
да. необычно. В первые слышу про подобные результаты.
Интересно было бы посмотреть изнутри.
Интересно было бы посмотреть изнутри.
Есть страничка в фейсбуке, правда, там всё на английском и эстонском.
Есть фотки офиса и рабочего процесса, а также видео живой демонстрации парного программирования.
А так, будете в Таллинне — заходите…
Есть фотки офиса и рабочего процесса, а также видео живой демонстрации парного программирования.
А так, будете в Таллинне — заходите…
Мы продаём Agile вполне успешно таким образом: клиент платит за часы работы, а мы за это время делаем столько, сколько получается. Естественно, у клиентов возникают сомнения: для них такая схема будет невыгодной, если мы будем работать медленно. На что мы объясняем, что благодаря аджайлу мы работаем быстрее конкурентов, и они сами могут в этом убедиться. А если наша скорость не будет их устраивать, они могут разорвать контракт после любой итерации. Это сильный ход в том смысле, что клиент мало чем рискует.
Конечно, не каждый клиент на это соглашается, но такие смельчаки находятся, и пока все довольны. Количество контрактов превышает нашу производственную мощность.
Конечно, не каждый клиент на это соглашается, но такие смельчаки находятся, и пока все довольны. Количество контрактов превышает нашу производственную мощность.
Хорошей хозяйке на заметку: большинство т.н. «проектов» похожи друг на друга как близнецы-братья и «сложных» и «амбициозных» задач там просто нет. Более того — значительная часть вполне может быть сделана «тяп-ляп» и будет б.м. работать. Люди с развитыми аналитическими способностями это замечают очень быстро и как только им становится не интересно программирование ради программирования (что тоже происходит довольно быстро) — все потуги «мотивировать» их «сложными» задачами приведут только к одному: на вас буду смотреть как на идиота.
По всей видимости, имеется ввиду разработка нового проекта. Описывать все user-story при continuous integration уже чревато большими трудозатратами, те что уже описаны — не актуальны, т.к. относятся к старту проекта. Тут я думаю стоит ограничиваться рамками необходимых доработок в текущих итерациях.
А постоянная интеграция тут причем?
Вы имели в виду этап под названием сопровождение продукта наверное?
И вы перепутали пользовательские истории со спецификацией продукта.
Пользовательская история как раз описывает только изменение в системе с точки зрения пользователя.
И никак не полную функциональность модуля или подсистемы.
Поэтому то что тут называется доработками в случае СКРАМ как раз описывается в виде пользовательских историй.
После того как история выполнена ее можно в общем-то выбрасывать потому что определение DONE должно включать в себя обновление спецификации продукта если таковая предусмотрена правилами проекта.
А по мне так код на продакшене чаще всего уже достаточная спецификация.
Старайтесь всегда упростить работу — меньше ошибок в итоге совершите и больше сил останется для чего-то производительного.
Производительное — то что даст работающий функционал пользователям.
Вы имели в виду этап под названием сопровождение продукта наверное?
И вы перепутали пользовательские истории со спецификацией продукта.
Пользовательская история как раз описывает только изменение в системе с точки зрения пользователя.
И никак не полную функциональность модуля или подсистемы.
Поэтому то что тут называется доработками в случае СКРАМ как раз описывается в виде пользовательских историй.
После того как история выполнена ее можно в общем-то выбрасывать потому что определение DONE должно включать в себя обновление спецификации продукта если таковая предусмотрена правилами проекта.
А по мне так код на продакшене чаще всего уже достаточная спецификация.
Старайтесь всегда упростить работу — меньше ошибок в итоге совершите и больше сил останется для чего-то производительного.
Производительное — то что даст работающий функционал пользователям.
Возможно, вы правы.
Просто кроме спецификации системы, т.е. технической информации необходимой разработчику, также важна и составляющая вариантов использования (user-story) пользователей. Для команды важно понимать как и для чего используется система, какие требования и какие ожидания у пользователей от системы. Тем самым, формируется видение «что нужно», понимание как для конкретно этой категории пользователей сделать систему лучше.
Просто кроме спецификации системы, т.е. технической информации необходимой разработчику, также важна и составляющая вариантов использования (user-story) пользователей. Для команды важно понимать как и для чего используется система, какие требования и какие ожидания у пользователей от системы. Тем самым, формируется видение «что нужно», понимание как для конкретно этой категории пользователей сделать систему лучше.
definition of done — это да, но мы никак не могли «закрывать» истории из-за того, что на последних этапах продукт овнер или индуские тестировщики, вдруг, начинали делать более глубокий анализ по задаче (тем самым раздувая ее, и оттягивая acceptance).
нам помогло введение понятия «acceptance criteria». это не тест кейсы, но и не абстрактное «все сделано — когда все сделано». Это шаги/проверки, которые сделает продукт овнер чтобы убедиться что нами все реализовано правильно. Это помагает нам формализировать/конкретизировать «definition of done» на уровне одной отдельной истории.
«acceptance criteria» -это не отмазка для девелопера. мы пишем тест кейсы, стараемся оборачивать старый код в юнит-тесты, и активно юзаем селениум. просто так, разработчику легче понять чего именно от него хотят)
нам помогло введение понятия «acceptance criteria». это не тест кейсы, но и не абстрактное «все сделано — когда все сделано». Это шаги/проверки, которые сделает продукт овнер чтобы убедиться что нами все реализовано правильно. Это помагает нам формализировать/конкретизировать «definition of done» на уровне одной отдельной истории.
«acceptance criteria» -это не отмазка для девелопера. мы пишем тест кейсы, стараемся оборачивать старый код в юнит-тесты, и активно юзаем селениум. просто так, разработчику легче понять чего именно от него хотят)
Sign up to leave a comment.
Как преодолеть традиционные проблемы при внедрении Agile