Size: a a a

Agile, Scrum, Lean, Kanban, XP

2020 October 25

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Alexander Kivaev
"а значит более управляемым. Что значит, что вы как индивид станете более живучим" - Сложилось так, что лично я уже все доказал и в прямом и переносном смыслах нашего культурного кода - и построил и посадил и воспитал.
Развития нельзя достичь, это не результат, это процесс.

Не останавливайтесь, чего вы достигнете, если продолжите такими же темпами?)
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Nataly
С чего взяли что у нас иначе? Я не веду бои с ветряными мельницами. Хорошего вам дня
Значит вас неправильно понял. Ошибочно истолковал некоторые маркеры )

Вам тоже хорошего выходного дня! :)
источник

N

Nataly in Agile, Scrum, Lean, Kanban, XP
Ivan Z
"Не уходите от ответа, опишите пожалуйста видение свое процесса"

По другому зайду: своих ребят я готовил так, что полностью доверял их оценке. Они не станут специально затягивать сроки или пытаться кого-то кинуть.

Доверие! Я доверял им, они мне. Это позволяет делегировать всё вниз, на исполнителей.

Ошибки верхнего уровня внизу не исправить, а значит тупо нужно всё по максимуму делегировать вниз.

Nataly , у вас где-то блок, фильтр на мои слова)
Мне мои же слова пишет. Прекратить свои диагнозы людям приписывать. Все так живут как вы описываете. Сюда бы иначе за советом не ходили. Все что вы говорили старо как мир. Мир многогранен. Докапывания и оскорбления ваши надоели мягко говоря. Сюда смотрят за ответами, а не баталиями. Или просто оценить свои же ситуации с другой стороны, а не опусканими и собачками -драчками о том как не нужны рп, см, пм и кто там еще. Подобных групп и без того хватает.Что-то по конструктиву будет - напишете, а так , постарайтесь хотя бы настроение людям не портить.
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Nataly
Мне мои же слова пишет. Прекратить свои диагнозы людям приписывать. Все так живут как вы описываете. Сюда бы иначе за советом не ходили. Все что вы говорили старо как мир. Мир многогранен. Докапывания и оскорбления ваши надоели мягко говоря. Сюда смотрят за ответами, а не баталиями. Или просто оценить свои же ситуации с другой стороны, а не опусканими и собачками -драчками о том как не нужны рп, см, пм и кто там еще. Подобных групп и без того хватает.Что-то по конструктиву будет - напишете, а так , постарайтесь хотя бы настроение людям не портить.
Вы меня не спрашивали.

Вы тут описывали кривую, костыльную ситуацию как норму.

Не согласен с такой нормой. Поэтому вам возражаю.

И буду возражать, до тех пор, пока вы будете говорить, что черное это белое, а белое это черное. :)
источник

AK

Alexander Kivaev in Agile, Scrum, Lean, Kanban, XP
Ivan Z
Не я придумал эти правила!)
Интересно был ли вы на переговорах с заказчиком командой в полном составе, то есть все 8 человек?
источник

N

Nataly in Agile, Scrum, Lean, Kanban, XP
Ivan Z
Вы меня не спрашивали.

Вы тут описывали кривую, костыльную ситуацию как норму.

Не согласен с такой нормой. Поэтому вам возражаю.

И буду возражать, до тех пор, пока вы будете говорить, что черное это белое, а белое это черное. :)
Вы правы. Я вас не спрашивала.
источник

AK

Alexander Kivaev in Agile, Scrum, Lean, Kanban, XP
Andrei Soloschak
«Последовательная работа» это и есть типичный водопад, даже если существует несколько этапов (итераций).  То есть сначала одни пишут и согласовывают ТЗ, вторые пишут код строго по ТЗ, третьи тестируют в конце приемка и если повезёт развёртываете. Про обратную связь от конечных пользователей я вообще молчу. Такая модель порождает огромное количество потерь (waste), очень мало реальной пользы (value), а полученный результат уже заранее несёт в себе существенный  техдолг.
А есть ли разбиение проекта на этапы или их нет совсем, и что там имел в виду Ройс уже неважно. Суть одна и та же - эта модель крайне неэффективна и именно это называется вотерфолом.
Поэтому когда Пименов настаивает на том, что вотерфола никогда не было, мне смешно.
Разве кто-то мешает водопад разбивать на итерации и в результате каждой итерации развертывать готовый продукт и получать обратную связь?  Например, каждые две недели, или одну неделю?

"... то есть сначала одни пишут и согласовывают ТЗ" - Но может быть несколько сложнее в несколько этапов: Цель или задача решаемая продуктом; некие бизнес-требования; функциональные и нефункциональные требования; на последнем этапе возможно ТЗ как сугубо технический документ.
К чему я - изменение бизнес-требований, на которые вы намекаете может быть только по завершении итерации, когда вы развернули продукт и предоставили заказчику акт сдачи-примемки оказанных услуг вместе со счетами на оплату. Верно?

Если вы работаете с заказчиком по контракту T&M, то годами он вам платит за доработку продукта предоставляя свои новые бизнес-требования каждую неделю. Это понятно.

Но мне не понятно -  как вы будете организовывать работы, если у вас есть перечень бизнес-требований заказчика, которые должны быть реализованы в продукте к заданной дате? И как вы поступите если до подписания контракта вы должны назвать заказчику стоимость контракта и далее вы работаете по фикс прайс?

И еще - как можно поступить, если продукт технически сложный и еженедельное добавление или изменение "фич" сделать невозможно?
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Alexander Kivaev
Интересно был ли вы на переговорах с заказчиком командой в полном составе, то есть все 8 человек?
Хватало до 3-4 человек в моем случае.


Численность команды в 8-9 человек это предельная численность, а не обязательная )
источник

AK

Alexander Kivaev in Agile, Scrum, Lean, Kanban, XP
Ivan Z
Хватало до 3-4 человек в моем случае.


Численность команды в 8-9 человек это предельная численность, а не обязательная )
Про обязательное слов не было.
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Alexander Kivaev
Разве кто-то мешает водопад разбивать на итерации и в результате каждой итерации развертывать готовый продукт и получать обратную связь?  Например, каждые две недели, или одну неделю?

"... то есть сначала одни пишут и согласовывают ТЗ" - Но может быть несколько сложнее в несколько этапов: Цель или задача решаемая продуктом; некие бизнес-требования; функциональные и нефункциональные требования; на последнем этапе возможно ТЗ как сугубо технический документ.
К чему я - изменение бизнес-требований, на которые вы намекаете может быть только по завершении итерации, когда вы развернули продукт и предоставили заказчику акт сдачи-примемки оказанных услуг вместе со счетами на оплату. Верно?

Если вы работаете с заказчиком по контракту T&M, то годами он вам платит за доработку продукта предоставляя свои новые бизнес-требования каждую неделю. Это понятно.

Но мне не понятно -  как вы будете организовывать работы, если у вас есть перечень бизнес-требований заказчика, которые должны быть реализованы в продукте к заданной дате? И как вы поступите если до подписания контракта вы должны назвать заказчику стоимость контракта и далее вы работаете по фикс прайс?

И еще - как можно поступить, если продукт технически сложный и еженедельное добавление или изменение "фич" сделать невозможно?
"
Но мне не понятно -  как вы будете организовывать работы, если у вас есть перечень бизнес-требований заказчика, которые должны быть реализованы в продукте к заданной дате? И как вы поступите если до подписания контракта вы должны назвать заказчику стоимость контракта и далее вы работаете по фикс прайс?"

Есть треугольник: срок, качество, цена.

Быстро, дешево и качественно - выберите два из трех (с) За этой фразой стоит целая математика как по мне.

Так вот, тупой заказчик уже зафиксировал два из трех оптимизационных критерия. И ищет ещё более неразумного исполнителя, который бы вписался в этот блудняк взяв на себя ответственность за то, чем придется поступаться. Заказчк уже решил - сроки и качество не двигаются.

Так бывает. А ещё бывает, что людей в рабство продают. Но это не значит, что надо в рабство идти. Уходите от тупых заказчиков. Не доказывайте потом какие-то костыльные методы работы с идиотами... иначе вот тут вы доказываете "как жить в рабстве", "как угодить хозяину, чтобы он не бил кнутом".

А я вам говорю - не будьте рабами, ептыть.

Не надо изначально подписываться под обреченные проекты. Вам точно будет лучше.
источник

AK

Alexander Kivaev in Agile, Scrum, Lean, Kanban, XP
Ivan Z
"
Но мне не понятно -  как вы будете организовывать работы, если у вас есть перечень бизнес-требований заказчика, которые должны быть реализованы в продукте к заданной дате? И как вы поступите если до подписания контракта вы должны назвать заказчику стоимость контракта и далее вы работаете по фикс прайс?"

Есть треугольник: срок, качество, цена.

Быстро, дешево и качественно - выберите два из трех (с) За этой фразой стоит целая математика как по мне.

Так вот, тупой заказчик уже зафиксировал два из трех оптимизационных критерия. И ищет ещё более неразумного исполнителя, который бы вписался в этот блудняк взяв на себя ответственность за то, чем придется поступаться. Заказчк уже решил - сроки и качество не двигаются.

Так бывает. А ещё бывает, что людей в рабство продают. Но это не значит, что надо в рабство идти. Уходите от тупых заказчиков. Не доказывайте потом какие-то костыльные методы работы с идиотами... иначе вот тут вы доказываете "как жить в рабстве", "как угодить хозяину, чтобы он не бил кнутом".

А я вам говорю - не будьте рабами, ептыть.

Не надо изначально подписываться под обреченные проекты. Вам точно будет лучше.
"Есть треугольник: срок, качество, цена." - Поправка - это называется "треугольник качества", который состоит из: срок, содержание, ресурсы.
источник

AK

Alexander Kivaev in Agile, Scrum, Lean, Kanban, XP
Ivan Z
"
Но мне не понятно -  как вы будете организовывать работы, если у вас есть перечень бизнес-требований заказчика, которые должны быть реализованы в продукте к заданной дате? И как вы поступите если до подписания контракта вы должны назвать заказчику стоимость контракта и далее вы работаете по фикс прайс?"

Есть треугольник: срок, качество, цена.

Быстро, дешево и качественно - выберите два из трех (с) За этой фразой стоит целая математика как по мне.

Так вот, тупой заказчик уже зафиксировал два из трех оптимизационных критерия. И ищет ещё более неразумного исполнителя, который бы вписался в этот блудняк взяв на себя ответственность за то, чем придется поступаться. Заказчк уже решил - сроки и качество не двигаются.

Так бывает. А ещё бывает, что людей в рабство продают. Но это не значит, что надо в рабство идти. Уходите от тупых заказчиков. Не доказывайте потом какие-то костыльные методы работы с идиотами... иначе вот тут вы доказываете "как жить в рабстве", "как угодить хозяину, чтобы он не бил кнутом".

А я вам говорю - не будьте рабами, ептыть.

Не надо изначально подписываться под обреченные проекты. Вам точно будет лучше.
То есть, если пропустить грусть о несовершенстве мира, вопрос -  верно ли я понял, что вы отказываетесь от контрактов по фикс прайс?
источник

S

Sonya in Agile, Scrum, Lean, Kanban, XP
Ivan Z
Плохой заказчик испортит любую работу.

Если вы сосредоточены на производстве качественного продукта, то должны понимать, что активная заинтересованность, вклад заказчика это необходимое условие качественного продукта.

И если заказчик отстой, то он запорет абсолютно всё, что бы вы ни сделали. Плохой заказчик это царь Мидас наоборот, превращающий всё, к чему ни прикоснется - в говно.

Впрочем, для тех у кого подход - "я свою часть работы сделал, а на остальное мне похер", это некритично.
Для начала нужно попробовать предложить заказчику альтернативные варианты организации процесса, показав плюсы от нововведений. Если заказчик отказывается, есть шанс адаптировать работу команды под реалии, чтобы она по крайней мере испытывала меньше боли. И продолжить прорабатывать заказчика на предмет изменения модели взаимодействия. Всегда можно что-то сделать на своём уровне. Этого может быть недостаточно, но сбегать надо как только убедишься что сделал все зависящее от себя. Про "тех, кому похер", не поняла, про что вообще этот выброс был
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Alexander Kivaev
То есть, если пропустить грусть о несовершенстве мира, вопрос -  верно ли я понял, что вы отказываетесь от контрактов по фикс прайс?
А вы подумайте, что такое фикс. Это позиция бюрократа-имитатора: мне всё равно, будет результат или нет, я не готов платить больше суммы X.

Даже если нужный результат стоит X+100 рублей платить в идеологии фикса нельзя.

Что очень тупо, повторюсь. Если мы ориентированны на работающий продукт, а не имитацию работы с закрытием актов.

Вы правы, почасовая оплата мне нравится больше, заказчик включается в работу, участвует в планировании и что особенно важно - в приоритизации работ.

Но тем не менее - всё зависит от заказчика. С нормальными ребятами лучше по фиксу работать, чем с отстойными по почасовке.

Имхо.
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Sonya
Для начала нужно попробовать предложить заказчику альтернативные варианты организации процесса, показав плюсы от нововведений. Если заказчик отказывается, есть шанс адаптировать работу команды под реалии, чтобы она по крайней мере испытывала меньше боли. И продолжить прорабатывать заказчика на предмет изменения модели взаимодействия. Всегда можно что-то сделать на своём уровне. Этого может быть недостаточно, но сбегать надо как только убедишься что сделал все зависящее от себя. Про "тех, кому похер", не поняла, про что вообще этот выброс был
Зачем вообще мучать команду, если заказчик необучаемый? Ежики кололись, но продолжали грызть кактус)

Про "похер" - тупой заказчик испоганит ваш любой самый тонкий труд. Труд вашей команды, все усилия, всё уйдет коту под хвост.

Вот именно этот факт вам я смотрю похер. Что это безнадежная и бессмысленная в итоге суета.

Я про то, что такие вещи видны и прогнозируемы заранее. Но если вы хотите набить шишки сами, или вам похер - штош. 💁‍♂
источник

S

Sonya in Agile, Scrum, Lean, Kanban, XP
Ivan Z
Зачем вообще мучать команду, если заказчик необучаемый? Ежики кололись, но продолжали грызть кактус)

Про "похер" - тупой заказчик испоганит ваш любой самый тонкий труд. Труд вашей команды, все усилия, всё уйдет коту под хвост.

Вот именно этот факт вам я смотрю похер. Что это безнадежная и бессмысленная в итоге суета.

Я про то, что такие вещи видны и прогнозируемы заранее. Но если вы хотите набить шишки сами, или вам похер - штош. 💁‍♂
Общение с людьми все ещё 2/10 :)
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Sonya
Общение с людьми все ещё 2/10 :)
👌


Не со всеми так плохо )
источник

S

Sonya in Agile, Scrum, Lean, Kanban, XP
Ivan Z
Зачем вообще мучать команду, если заказчик необучаемый? Ежики кололись, но продолжали грызть кактус)

Про "похер" - тупой заказчик испоганит ваш любой самый тонкий труд. Труд вашей команды, все усилия, всё уйдет коту под хвост.

Вот именно этот факт вам я смотрю похер. Что это безнадежная и бессмысленная в итоге суета.

Я про то, что такие вещи видны и прогнозируемы заранее. Но если вы хотите набить шишки сами, или вам похер - штош. 💁‍♂
Похер это тебе, твоя тонкая душевная организация не даст тебе сделать хоть что-то для людей, которые там работают и будут работать - не одни, так другие. Ты лучше пойдёшь к классным ребятам и будешь там балластом, потому что классные ребята никакого полезного опыта работы в направлении коучинга тебе не дадут. Зато все просто. И красиво. А для самореализации можно херами покидаться в каком-то чате)
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Sonya
Похер это тебе, твоя тонкая душевная организация не даст тебе сделать хоть что-то для людей, которые там работают и будут работать - не одни, так другие. Ты лучше пойдёшь к классным ребятам и будешь там балластом, потому что классные ребята никакого полезного опыта работы в направлении коучинга тебе не дадут. Зато все просто. И красиво. А для самореализации можно херами покидаться в каком-то чате)
Тут есть нюанс: из самых хороших людей можно сделать патологическую структуру.

Правила делают систему. Не с одних, так с других, кто придет им на замену. В этом крутая штука в скраме, что он задает новые правила игры. Ну не совсем новые, но ясно и четко их обозначает.
источник

S

Sonya in Agile, Scrum, Lean, Kanban, XP
Можно работать по своим правилам в саоей команде, для начала построить команду на общей оси ненависти к заказчику, если уж не удаётся его исправить. А потом на несёшь этим людям добро и они пойдут на нормальную работу, и хотя бы 10 людей в этом мире будут вспоминать тебя с теплом в сердце. Тратить на это время или нет, и сколько его потратить без ущерба для себя - выбор каждого. Построение команды из кучи озлобленных волков - тоже отличный опыт
источник