Данный идентификатор никак не влияет на работу команды.
С моей точки зрения, чтобы сделать такое заключение надо либо быть серьезным специалистом с опытом либо треплом. В первом случае надо еще понимать, что означает слово "скрам" иначе суждение не имеет смысла.
Ну вот есть команда, работает хорошо, но не по скраму. И что с того?
Разобраться, как это устроено и постараться позаимствовать. Чтобы разобраться надо как-то все это назвать.
Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.
Оценить можно все, что угодно, вопрос, с какой точностью ;)
Общее понимание слов нужно для того, чтобы общаться. Например если скловом скрам обозначать вообще все, что угодно, то вас могут не понять в магазине куда вы придете со словами «дайте мне скрам», хотя, возможно этот скрам будет даже работать.
Если не обосновывать принадлежность к тому или ином способу работы, то мы теряем возможность употреблять термины, каждый раз это будет обозначать все, что угодно и надо приводить полное описание того, как была устроена работа.
Мне очень странно, что такие элементарные вещи надо объяснять программисту — ведь он-то должен знать зачем нужны идентификаторы
Если есть какой-то идиот который текст по ссылке может только выполнять, то да. А разумный критик может использовать ссылки чтобы сказать, что скрам а что нет.
Хотя с другой стороны, вы опять правы — они ограничивают в в возможности придумать какую-то отсебятину и назвать ее скамом.
Так же как некоторые придумывают какую-то свою внутренне противоречивую отсебятину и называют что-то там юнит тестами ;).
Дейли скрам вызвал у вас проблему не потому, что это скрам, а потому, что вы не можете обсудить публично такую пустяковую вещь как задержка в выполнении задачи.
Эти обвиняшки таким образом будут блокировать вам любое общее обсуждение. Вне зависимости, скрам это или нет.
Вместо того, чтобы использовать таймслот, предназначенный для синхронизации команды вы прервете Васю отдельно, в то время когда он не готов к этому, и не сможете использовать головы остальной команды для решения задачи (Петя может знать тул, алгоритм, кусочек кода или Мишу, который это знает). Вам придется Петю отвлекать от его задачи в еще какой-то момент времени, либо вы можете даже не подозревать что он что-то знает.
С моей точки зрения вот это «это означает обвинить Васю перед всей командой, поставить его в неловкое положение, вынудить оправдываться и надолго (навсегда?) ухудшить отношения с ним.» будет вам вредить хоть при скраме хоть при канбане хоть при водопаде, хоть при «фигач, блин, код»
Подниму ли я эту проблему на дейли-митинге? Нет, не подниму, поскольку это означает обвинить Васю перед всей командой, поставить его в неловкое положение, вынудить оправдываться и надолго (навсегда?) ухудшить отношения с ним.
… если в вашей команде принято искать виноватых. А если проблемы принято решать, то Вася скажет, почему его функция заняла больше чем спрогнозировано и вы вместе подумаете как исправить ситуацию.
Скрам описан в скрам гайд. Если человек хочет обсудить, какой-то способ работы, то он должен сослаться на ту часть гайда, которая его требует или хотя бы это проверить. Если какая-то практика с его точки зрения неизбежна при интерпретации гайда, он должен обосновать почему.
Если он не хочет этим заморачиваться, то для меня он — трепло, которое не знает о чем говорит, а делает вид, что знает.
Автор оригинала — Michael O. Church, «the most hated Ex-Googler», человек, который участвовал во всех возможных «политических» срачах компании и при этом делал мало производительной работы, уволившийся оттуда с отрицательной рекомендацией, с которой его не взяли в foursquare, короче неоправданно opinionated фрик, end of story. Особенно смешно он бегал по интернетам, пытаясь доказать, что когда наниматель звонит кому-то из бывших работодателей, кого кандидат не указал в списке рекомендаций, он нарушает право на частную жизнь и вторгается на недовзоленную территорию.
Его представления о ремесле, о рынке труда, не нуждаются в комментариях.
Ну, вообще говоря он необязательно кого-то винит, но суть в том, что, да, для рашен бизнеса в особенности характерно мечтать всех обмануть и родить ребенка за месяц (но усилиями не девяти женщин, а, например, трех). И не те самые «плохие менеджеры» стоят во главе этой идеологии, отнюдь.
С моей точки зрения это не так. См пример про чайники.
Вот уж не думал, что вы мою писанину воспринимаете как нытье…
Я про тех кто пишет даже не попытавшись разобраться. С того, про что начался разговор.
Тут два варианта. Или это все самому ему объективно нужно (например, он сам знает что пообещал сделать быстрее чем может и понял, что ошибся в оценке и ему надо свалить вину на кого-то) или он искренне не понимает как это все работает и в его сознании отсутствие необходимого не связано с багами, которые вдобавок дополнительно замедляют.
Что тут может сделать разработчик?
Самому разобраться как это должно работать, разобраться к какому варианту относится ситуация и показать или начальнику или начальнику начальника или коллегам что в результате все проигрывают. Начальники не вечны и один из коллег вполне может быть следующим начальником.
Уволиться (при поиске работы может пригодиться знание что такое аджайл и за счет чего он работает — т.е. он сможет по беседе понять какие части пропущены и с чем могут быть проблемы). Еще вся эта система держится на том, что по какой-то причине разработчики не уходят — или не уважают себя или просто безинициативны. Станьте круче, учитесь себя продавать, найдите более широкий рынок (как у вас с английским, например).
Ныть на форуме
Я думаю, если разработчик хочет улучшить свою жизнь, а не просто выпустить пар и продолжить в том же духе, первые два пути более перспективны.
So, when would I not want to do Scrum?
I gave two examples.
If two people on the 7 person Team say “I hate Scrum”, then I probably would not do Scrum with that Team. Almost surely they will make it fail. Maybe you would do waterfall instead. (I might fire myself, though, and get myself on another Team.)
If they give you an impossible project (say 18 months of work that must be done in 12 months), and if you don’t succeed they will fire you — then, I recommend waterfall.
Management won’t really know how the (waterfall) project is doing. Just say: Green. You will have plenty of time to work on your resume, post it on Monster.com (or CareerBuilder), have some interviews, and get a new job. It is important that you protect yourself and your family from these jerks (or this situation). (Firing someone for not accomplishing the impossible is being a jerk.)
Some people laugh when I describe that situation, but seriously, you have to protect yourself. As you are leaving, wave goodbye and tell them the project is RED.
Надо просто лучше и больше работать, а не играть два раза в день по десять минут в пинг-понг и не читать статьи на Хабре после обеда.
Хорошо, мы я постараюсь чтобы в рабочее время больше этого не было.
Тогда почему вы постоянно ноете про этот ваш «технологический долг»?
Чтобы сделать проще надо подумать. Технический долг это как раз когда делают слишком сложно из-за спешки.
Не потом, а сию секунду! Иначе я позвоню Самому Главному, и он вам объяснит, кому куда идти. Удовлетворенность клиентов на первом месте!
Конечно, я это и имел ввиду. Сейчас исправим, потом подумаем, как сделать чтобы больше не повторялось. (Прекратить разговор до следующего удобного случая чтобы не передавить)
Мне это нафиг неинтересно, откуда они возникли (хотя я и делаю вид, что интересно), просто скажите, кто виноват.
Это очень странно, что человеку неинтересно откуда возникли проблемы, если они есть. Как вы убедились, что он только делает вид?
никто не брал в расчет, что появятся новые и новые проекты, то это уже не «запрос на предсказуемость».
Это означает, что либо данный уровень качества на самом деле всех устраивает либо люди не понимают что они за баги платят больше, либо происходит явный обман клиента, когда сознательно обещают намного больше чем надо сделать. Надо разобраться какой именно вариант в конкретном случае.
Большинство виденных мной начальников транслируют запрос бизнеса, а запрос рашен бизнеса известно какой.
По-моему, что с товарами, что с услугами часто следующий сценарий — сначала люди выбирают подешевле, потом понимают, что они уже выбросили три самых дешевых чайника и покупают один подороже и смотрят отзывы. Для меня странно, что современный русский бизнес в массе работает как-то по другому. Причем, я работал в русских компаниях внутри и вижу изменения как пользователь снаружи — качество практически всего растет, включая госуслуги.
Кроме нескольких проколов люди достаточно адекватно оценивали сроки и делали запасы. И обращались к техническим специалистам при планировании.
одни ожидания, что гибкость позволит взять от вас больше — тут и начинается адуха.
Начальник которого вы сэмулировали никак не аппелировал к тому, что в аджайле так или нет так.
Гибкость позволяет больше взять за счет того, что результат именно тот, что нужен. Т.е. это последствие выбора того, кто руководит процессом. Если он выбирает скорость каждой конкретной итерации, то он это получит. Если он выбирает качество то, он это получит.
Я думаю, описанный вами начальник сможет создать давление вполне и без скрама и получить то же самое.
Давайте обсудим, за счет чего? Пока я вижу что люди оптимизируют фазу тестирования, в результате предыдущая итерацию мы были заняты в основном исправлением багов. Для исправления бага его пришлось сначала воспроизвести службе поддержки, потом Васе потом Вася пообщался со службой поддержки чтобы уточнить шаги и потом он разобрался в коде и исправил. Если бы Петя протестировал это тщательнее то он бы исправил это быстрее, так как он помнил код и не отнимал время у трех человек.
Вот моя идея. А вы как считаете за счет чего мы должны работать быстрее?
2) Хватит изобретать и мудрствовать, пилите проще, пусть будут костыли, главное быстрее.
Я совершенно за простоту как и вы.
3) Нет, ну конечно должна быть хорошая архитектура и комментарии.
В этом мы на одной волне.
4) Так, стоп, хватит болтать, тут в Н-ске ваши прошлые баги вылезли, бегом все чинить (При этом сроки новых разработок никуда не двигаются — Прим. авт.).
Давайте потом подумаем, как сделать чтобы их было поменьше.
Потом прислать письмо с кратким описанием откуда возникли баги.
Само собой, и это декларируется постоянно и везде.
По моему опыту это не только декларируется. И я работал преимущественно в Российских компаниях.
Еще заметьте что аджайл совершенно выпал из этого диалога — он просто не является фактором тут. Основные проблемы тут отношение к разработчикам, планирование и качество. Эти проблемы можно решать, хоть в аджайле, хоть в водопаде только разными средствами и в соответствующих книжках описано какими.
Ваш сэмулированный начальник не ссылается на скрам или канбан. И еще вполне может быть что реальный начальник сложнее сэмулированного и поддается агрументированному убеждению в какой-то мере.
Я бы начал с анализа ситуации — почему все сложилось так, и какие цели у лиц принимающих решения.
Можно спросить начальника как он оценивает и посмотреть чего не хватает в оценках. Можно в багтрекере собрать статистику по реальной трудоемкости vs оценка и предложить на основе нее увеличить оценки, чтобы соблюдать условия. Можно посмотреть к каким последствием приводит такая политика (спешка => люди не тестируют => в последующие итерации разгребаем баги (статистика по багам, анализ откуда взялись, общая стоимость исправления на всех этапах) или (спешка => овертайм => выгорание => увольнения). Можно спросить почему именно все так устроено, почему он не доверяет оценке программистов.
Часто начальству нужна предсказуемость планирования, а тут вот баги-то как раз и мешают.
Еще если постоянный овертайм и штрафы, то просто похоже что программистам платят меньше чем договорились. Если это сознательная политика, а не по незнанию.
Тут как по мне, надо либо разбираться на уровень выше либо уходить.
например заслужить репутацию «бессильного жалобщика»
Если кроме жалоб не приходит на ум никаких других способов действия, то да. В таком случае репутация будет заслужена и лучше жаловаться на форумах :) тогда репутация будет только у ника.
Ага, и бросить проект, и бросить людей, которые вместе с тобой тут ночевали, вот это вот все. То есть это конечно бывает необходимо. но от этого не легче.
Проект не вечен. По определению. Возможно эти люди тоже так думают и не уходят и таким образом они друг друга мучают в говноконторе.
И вообще это напоминает манипуляцию чувством вины.
далеко не все изучают, например, механизмы распространения HIV, даже если страшно его боятся.
Ну да боятся, сами болеют и не изучают — таких большинство
Буду говорить за рашен бизнес — другие варианты просто не работают.
Если не пытаться, то точно не работают. Если пытаться, то есть варианты. Кстати рашен бизнес это, в том числе, ABBYY, JetBrains, Касперский, Яндекс. Интересно, как у них.
Насчет деструкции — конечно оно так, «чем хуже — тем лучше», но глобально это не лучший подход.
Деструкция это не хуже, если она на месте. Уволиться из говноконторы эта правильная деструкция. Рак — это сбой деструкции.
Но если создаём продукт, то любое поползновение в сторону agile приравниваем к саботажу и караем по законам военного времени.
Я думаю, для начала надо расстрелять покупателей. А то, ишь, не хотят платить за списки дел, разработанные по нормам для создания автомобилей и по такой же цене!
С моей точки зрения, чтобы сделать такое заключение надо либо быть серьезным специалистом с опытом либо треплом. В первом случае надо еще понимать, что означает слово "скрам" иначе суждение не имеет смысла.
Разобраться, как это устроено и постараться позаимствовать. Чтобы разобраться надо как-то все это назвать.
А при чем тут "невозможно оценить" наверное вы имели ввиду "невозможно было безошибочно предсказать".
прочитайте определение https://en.wikipedia.org/wiki/Estimation
Оценить можно все, что угодно, вопрос, с какой точностью ;)
Если не обосновывать принадлежность к тому или ином способу работы, то мы теряем возможность употреблять термины, каждый раз это будет обозначать все, что угодно и надо приводить полное описание того, как была устроена работа.
Мне очень странно, что такие элементарные вещи надо объяснять программисту — ведь он-то должен знать зачем нужны идентификаторы
Хотя с другой стороны, вы опять правы — они ограничивают в в возможности придумать какую-то отсебятину и назвать ее скамом.
Так же как некоторые придумывают какую-то свою внутренне противоречивую отсебятину и называют что-то там юнит тестами ;).
Эти обвиняшки таким образом будут блокировать вам любое общее обсуждение. Вне зависимости, скрам это или нет.
Вместо того, чтобы использовать таймслот, предназначенный для синхронизации команды вы прервете Васю отдельно, в то время когда он не готов к этому, и не сможете использовать головы остальной команды для решения задачи (Петя может знать тул, алгоритм, кусочек кода или Мишу, который это знает). Вам придется Петю отвлекать от его задачи в еще какой-то момент времени, либо вы можете даже не подозревать что он что-то знает.
С моей точки зрения вот это «это означает обвинить Васю перед всей командой, поставить его в неловкое положение, вынудить оправдываться и надолго (навсегда?) ухудшить отношения с ним.» будет вам вредить хоть при скраме хоть при канбане хоть при водопаде, хоть при «фигач, блин, код»
… если в вашей команде принято искать виноватых. А если проблемы принято решать, то Вася скажет, почему его функция заняла больше чем спрогнозировано и вы вместе подумаете как исправить ситуацию.
Скрам описан в скрам гайд. Если человек хочет обсудить, какой-то способ работы, то он должен сослаться на ту часть гайда, которая его требует или хотя бы это проверить. Если какая-то практика с его точки зрения неизбежна при интерпретации гайда, он должен обосновать почему.
Если он не хочет этим заморачиваться, то для меня он — трепло, которое не знает о чем говорит, а делает вид, что знает.
С моей точки зрения это не так. См пример про чайники.
Я про тех кто пишет даже не попытавшись разобраться. С того, про что начался разговор.
Тут два варианта. Или это все самому ему объективно нужно (например, он сам знает что пообещал сделать быстрее чем может и понял, что ошибся в оценке и ему надо свалить вину на кого-то) или он искренне не понимает как это все работает и в его сознании отсутствие необходимого не связано с багами, которые вдобавок дополнительно замедляют.
Что тут может сделать разработчик?
Самому разобраться как это должно работать, разобраться к какому варианту относится ситуация и показать или начальнику или начальнику начальника или коллегам что в результате все проигрывают. Начальники не вечны и один из коллег вполне может быть следующим начальником.
Уволиться (при поиске работы может пригодиться знание что такое аджайл и за счет чего он работает — т.е. он сможет по беседе понять какие части пропущены и с чем могут быть проблемы). Еще вся эта система держится на том, что по какой-то причине разработчики не уходят — или не уважают себя или просто безинициативны. Станьте круче, учитесь себя продавать, найдите более широкий рынок (как у вас с английским, например).
Ныть на форуме
Я думаю, если разработчик хочет улучшить свою жизнь, а не просто выпустить пар и продолжить в том же духе, первые два пути более перспективны.
Манифест это просто набор целей, а не конкретный процесс. Но в разных источниках есть про ограничения.
Вот я поискал.
Еще есть agile fluency model ( https://martinfowler.com/articles/agileFluency.html )
т.е. тот, кто захочет, может найти информацию, как помешать называть аджайлом или там скрамом ктому-то все, что угодно я не знаю.
Хорошо, мы я постараюсь чтобы в рабочее время больше этого не было.
Чтобы сделать проще надо подумать. Технический долг это как раз когда делают слишком сложно из-за спешки.
Конечно, я это и имел ввиду. Сейчас исправим, потом подумаем, как сделать чтобы больше не повторялось. (Прекратить разговор до следующего удобного случая чтобы не передавить)
Это очень странно, что человеку неинтересно откуда возникли проблемы, если они есть. Как вы убедились, что он только делает вид?
Это означает, что либо данный уровень качества на самом деле всех устраивает либо люди не понимают что они за баги платят больше, либо происходит явный обман клиента, когда сознательно обещают намного больше чем надо сделать. Надо разобраться какой именно вариант в конкретном случае.
По-моему, что с товарами, что с услугами часто следующий сценарий — сначала люди выбирают подешевле, потом понимают, что они уже выбросили три самых дешевых чайника и покупают один подороже и смотрят отзывы. Для меня странно, что современный русский бизнес в массе работает как-то по другому. Причем, я работал в русских компаниях внутри и вижу изменения как пользователь снаружи — качество практически всего растет, включая госуслуги.
Кроме нескольких проколов люди достаточно адекватно оценивали сроки и делали запасы. И обращались к техническим специалистам при планировании.
Начальник которого вы сэмулировали никак не аппелировал к тому, что в аджайле так или нет так.
Гибкость позволяет больше взять за счет того, что результат именно тот, что нужен. Т.е. это последствие выбора того, кто руководит процессом. Если он выбирает скорость каждой конкретной итерации, то он это получит. Если он выбирает качество то, он это получит.
Я думаю, описанный вами начальник сможет создать давление вполне и без скрама и получить то же самое.
Давайте обсудим, за счет чего? Пока я вижу что люди оптимизируют фазу тестирования, в результате предыдущая итерацию мы были заняты в основном исправлением багов. Для исправления бага его пришлось сначала воспроизвести службе поддержки, потом Васе потом Вася пообщался со службой поддержки чтобы уточнить шаги и потом он разобрался в коде и исправил. Если бы Петя протестировал это тщательнее то он бы исправил это быстрее, так как он помнил код и не отнимал время у трех человек.
Вот моя идея. А вы как считаете за счет чего мы должны работать быстрее?
Я совершенно за простоту как и вы.
В этом мы на одной волне.
Давайте потом подумаем, как сделать чтобы их было поменьше.
Потом прислать письмо с кратким описанием откуда возникли баги.
По моему опыту это не только декларируется. И я работал преимущественно в Российских компаниях.
Еще заметьте что аджайл совершенно выпал из этого диалога — он просто не является фактором тут. Основные проблемы тут отношение к разработчикам, планирование и качество. Эти проблемы можно решать, хоть в аджайле, хоть в водопаде только разными средствами и в соответствующих книжках описано какими.
Ваш сэмулированный начальник не ссылается на скрам или канбан. И еще вполне может быть что реальный начальник сложнее сэмулированного и поддается агрументированному убеждению в какой-то мере.
Можно спросить начальника как он оценивает и посмотреть чего не хватает в оценках. Можно в багтрекере собрать статистику по реальной трудоемкости vs оценка и предложить на основе нее увеличить оценки, чтобы соблюдать условия. Можно посмотреть к каким последствием приводит такая политика (спешка => люди не тестируют => в последующие итерации разгребаем баги (статистика по багам, анализ откуда взялись, общая стоимость исправления на всех этапах) или (спешка => овертайм => выгорание => увольнения). Можно спросить почему именно все так устроено, почему он не доверяет оценке программистов.
Часто начальству нужна предсказуемость планирования, а тут вот баги-то как раз и мешают.
Еще если постоянный овертайм и штрафы, то просто похоже что программистам платят меньше чем договорились. Если это сознательная политика, а не по незнанию.
Тут как по мне, надо либо разбираться на уровень выше либо уходить.
Конструктивное предложение, например, на ретроспективе желательно подтвержденное данными и учитывающее личную выгоду начальника.
Начальника, коллег, родителей, государства, общества.
Если кроме жалоб не приходит на ум никаких других способов действия, то да. В таком случае репутация будет заслужена и лучше жаловаться на форумах :) тогда репутация будет только у ника.
Проект не вечен. По определению. Возможно эти люди тоже так думают и не уходят и таким образом они друг друга мучают в говноконторе.
И вообще это напоминает манипуляцию чувством вины.
Ну да боятся, сами болеют и не изучают — таких большинство
Если не пытаться, то точно не работают. Если пытаться, то есть варианты. Кстати рашен бизнес это, в том числе, ABBYY, JetBrains, Касперский, Яндекс. Интересно, как у них.
Деструкция это не хуже, если она на месте. Уволиться из говноконторы эта правильная деструкция. Рак — это сбой деструкции.
Я думаю, для начала надо расстрелять покупателей. А то, ишь, не хотят платить за списки дел, разработанные по нормам для создания автомобилей и по такой же цене!