Я не знаю, что такое "подобные случаи" но как мне кажется, если это не говноконтора со взаимоотношениями "я — начальник, ты — дурак", то можно, по крайней мере попробовать убедить начальника поменять. Кстати, в скраме встроены ретроспективы для того, чтобы улучшать процесс. Или у вас был скрам без ретроспектив?
Кто-то тогда должен выбирать скрам-мастера и он должен понимать как его выбирают. Еще такие разработчики, по моему, должны говорить типа "Скрам в интерпретации Васи Пупкина"
А какой был размер спринта? Планирование осуществлялось с учетом накопленной статистики о скорости команды или разработчики оценивали в календарных днях?
Кстати, Интересный доклад о том, что оценка имеет вероятностный характер и про NoEstimates
И берут на себя, как основная часть скрам-команды, обязательства сделать за неделю-две то-то и то-то.
В современном скраме этого нет. Даже нет оценки того, что можно сделать за спринт. Есть предсказание
"The Development Team works to forecast the functionality that will be developed during the Sprint"
"As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."
Ситуация усугубляется, если несколько проектов на одну команду, каждая со своим продакт аунером, в разборки между ними вовлекаются разработчики на планировании спринтов, времени на планирование тратится ещё больше.
Не могу с ходу привести цитату, но мне кжется, это вообще антипаттерн.
Давайте попробуем сопоставить то, что написано в статье и Scrum guide
"Scrum is:
Lightweight
Simple to understand
Difficult to master"
Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками.
Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика,
ведь это просто обновление с одной версии на другую?
Была ли эта проблема обсуждена на ретроспективах и что на это сказали?
Я думаю, если бы вы объяснили PO, зачем именно нужен преход между фреймворками и какой business value это принесет, то разумный PO смог бы приоретизировать эту задачу.
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление
со стороны менеджмента и отчет за каждый час рабочего времени.
Scrum guide:
"The number of items selected from the Product Backlog for the Sprint is
solely up to the Development Team. Only the Development
Team can assess what it can accomplish over the upcoming Sprint."
"The Development Team is responsible for all estimates.
The Product Owner may influence the Development Team by helping
it understand and select trade-offs, but the
people who will perform the work make the final estimate."
Стали выполняться только задачи (User Story), приходящие
от менеджеров,
По Scrum guide команда может управлять беклогом при одобрении
product owner.
Задачам стали присваивать приоритеты.
А раньше никаких приоритетов не было и все делалось одновременно?
Или фактически приоритеты были, но их никто не записывал?
Менеджеры начали конфликтовать между собой,
пытаясь присвоить своей userStory высший приоритет,
т.к. у них обязательства перед заказчиками и никого не волнует
занятость разработчиков.
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner."
Методология Скрам, превращающая процесс разработки в конвейер...
Резюме: методология Scrum описана в Scrum guide. То, что описано
в статье частично ей противоречит, частично ее дополняет.
Описанные проблемы, я думаю, именно из-за этих противоречий и дополнений
Автор, как мне кажется, на веру принял то, что ему говорил скрам-мастер и не сопоставил это с тем, что пишут авторы скрама.
Именно для таких приложений и есть трей. В принципе, для какого-нибудь мессенджера достаточно двуз кнопок — свернуть и закрыть. Только вот основная проблема была в том, что если кнопка прям здесь на виду, то закрыть очень легко и надо вставлять предупредлеждение.
А еще у приложени может быть UI отдельным процессом, а то, что жрет сеть и процессор — отдельным процессом. То есть все равно в логике приложени надо делать какую-то специальную вещь для управления бекграундом.
Мне кажется, для массового пользователя управлять беграундом не надо, а для нас с вами вполне достаточно того, что есть
А зачем пользователю вообще в его системе понятий приложение как таковое? Ему надо какие-то сущности предметной области — документ, процесс приема и передачи сообщений
1) Почему нельзя разработчикам добавлять новый код в ветке относящейся к следующему спринту. Так будет выпущен стабильный оттестированный спринт n и не затормозится работа над спринтом n+1
2) В идеологии канбан, насколько я помню, команд должна работать как единое целое и над тем, чтобы задачи прошли через доску быстрее. То есть часть разработчиков может вполне заняться тетированием.
Не знаю. Может быть в сборке с классом. Тогда, наверное, надо его генерить по атрибуту а не при приведении. Вы лучше меня знаете дотнет, придумайте сами :)
У нас член команды добавляет тикет в таком случае который может быть приоритезирован или отвергнут овнером.
В кабан используется статистика для планирования
вот тут разжёвано http://www.dennisstevens.com/2010/06/07/kanban-and-when-will-this-be-done/
Это так начальник сказал? Тогда надо спросить чем скрам для конкретных условий лучше канбана.
Вот, кстати, зачем надо разработчику разбираться в предмете — чтобы аргументировать свою точку зрения.
Вот, кстати, видео об изменениях в скраме — что убрали, что добавили и почему?
https://youtu.be/PGD4lllhJ_I
Были какие-то аргументы против канбана?
Я не знаю, что такое "подобные случаи" но как мне кажется, если это не говноконтора со взаимоотношениями "я — начальник, ты — дурак", то можно, по крайней мере попробовать убедить начальника поменять. Кстати, в скраме встроены ретроспективы для того, чтобы улучшать процесс. Или у вас был скрам без ретроспектив?
С моей точки зрения логично посмотреть отзывы на врача, вызнать что за прививка и какое качество у производителя, второе мнение и т.д.
То есть ответственные люди врача выбирают
Кто-то тогда должен выбирать скрам-мастера и он должен понимать как его выбирают. Еще такие разработчики, по моему, должны говорить типа "Скрам в интерпретации Васи Пупкина"
А какой был размер спринта? Планирование осуществлялось с учетом накопленной статистики о скорости команды или разработчики оценивали в календарных днях?
Кстати, Интересный доклад о том, что оценка имеет вероятностный характер и про NoEstimates
Надеюсь, это была не русскоязычная википедия?
Идеология предварительного абсолютно точного планирования 100% времени со буквальным следованием плану без пересмотра убивает спонтанные идеи :)
Агилисты часто цитируют:
Я понимаю, почему нельзя считать такой постулат догматом, но почему нельзя мыслить этими катерогиями?
Почему хотя бы нельзя задаться вопросом, "А скрам ли это?" "А правильно ли мы его готовим?"?
Может их придумали не потому, что скрам нехорош, а потому что он хорош, но можно лучше :)
В современном скраме этого нет. Даже нет оценки того, что можно сделать за спринт. Есть предсказание
"The Development Team works to forecast the functionality that will be developed during the Sprint"
"As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."
Не могу с ходу привести цитату, но мне кжется, это вообще антипаттерн.
Давайте попробуем сопоставить то, что написано в статье и Scrum guide
"Scrum is:
Была ли эта проблема обсуждена на ретроспективах и что на это сказали?
Я думаю, если бы вы объяснили PO, зачем именно нужен преход между фреймворками и какой business value это принесет, то разумный PO смог бы приоретизировать эту задачу.
Scrum guide:
"The number of items selected from the Product Backlog for the Sprint is
solely up to the Development Team. Only the Development
Team can assess what it can accomplish over the upcoming Sprint."
"The Development Team is responsible for all estimates.
The Product Owner may influence the Development Team by helping
it understand and select trade-offs, but the
people who will perform the work make the final estimate."
По Scrum guide команда может управлять беклогом при одобрении
product owner.
А раньше никаких приоритетов не было и все делалось одновременно?
Или фактически приоритеты были, но их никто не записывал?
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner."
Резюме: методология Scrum описана в Scrum guide. То, что описано
в статье частично ей противоречит, частично ее дополняет.
Описанные проблемы, я думаю, именно из-за этих противоречий и дополнений
Автор, как мне кажется, на веру принял то, что ему говорил скрам-мастер и не сопоставил это с тем, что пишут авторы скрама.
Именно для таких приложений и есть трей. В принципе, для какого-нибудь мессенджера достаточно двуз кнопок — свернуть и закрыть. Только вот основная проблема была в том, что если кнопка прям здесь на виду, то закрыть очень легко и надо вставлять предупредлеждение.
А еще у приложени может быть UI отдельным процессом, а то, что жрет сеть и процессор — отдельным процессом. То есть все равно в логике приложени надо делать какую-то специальную вещь для управления бекграундом.
Мне кажется, для массового пользователя управлять беграундом не надо, а для нас с вами вполне достаточно того, что есть
А зачем пользователю вообще в его системе понятий приложение как таковое? Ему надо какие-то сущности предметной области — документ, процесс приема и передачи сообщений
А чем закрытие и потом открытие с восстановлением состояния отличается от сворачивание в трей?
Мне кажется, окна-то как раз закрываются. Просто приложение продолжает работать
What are developers expected to do during testing in the latter half of each Sprint?
1) Почему нельзя разработчикам добавлять новый код в ветке относящейся к следующему спринту. Так будет выпущен стабильный оттестированный спринт n и не затормозится работа над спринтом n+1
2) В идеологии канбан, насколько я помню, команд должна работать как единое целое и над тем, чтобы задачи прошли через доску быстрее. То есть часть разработчиков может вполне заняться тетированием.
Мне, наоборот, непонятно зачем вообще изображение. Вся информация звуком :)
Не знаю. Может быть в сборке с классом. Тогда, наверное, надо его генерить по атрибуту а не при приведении. Вы лучше меня знаете дотнет, придумайте сами :)