Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9   вперед  Ctrl      все
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Vyatich
Member

Откуда:
Сообщений: 3169
softwarer
golovonometr
Странно, для меня водопад всегда ассоциируется с переработками, неадекватным менеджментом, нищета по зарплатам и несправедливость по нагрузкам. Без каких-либо перспектив роста для хороших исполнителей.

Лично для меня водопад ассоциируется в первую очередь с единственным за всю жизнь опытом работы по хорошо продуманному адекватному ТЗ, без лихорадочных переделок на ходу и перепроектирования из-за внезапной смены парадигмы. Когда задача поставлена так: "Берёшь ТЗ начиная с пункта 3.2.1.4 и делаешь одно за другим, пока не дойдёшь до 3.5. Как дойдёшь - приходи за следующей задачей". И через полтора месяца приходишь - всё сделал. Ну заодно - с тремя увеличениями зарплаты за полгода без единого слова с моей стороны и многими другими приятностями.

Что это был за проект, если не секрет?
3 сен 19, 13:10    [21962426]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1751
Nelrum
Alexey Tomin
... худшие впечатления - от водопада.


Почему, если не секрет?


Разные уровни естественным образом оказываются антоганистами.
Когда а любой фиче есть 6 участников (аналитик, проектировщик, кодер, тестировщик, внедренец, техподдержка), то найти концы невозможно.
Как результат- постоянно получается г..но, причём никто не виноват- "к пуговицам претензии есть?".
Если что- набрав часть людей этой же команды по классическому scrum удалость сделать нормально- процесс разработки был намного более контролируемым.
3 сен 19, 14:29    [21962541]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1751
softwarer
Alexey Tomin
Для разработки ПО управления автомобилем водопад хорош, для движка веб-сайта это смерть. Аналогично agile - убьёт первый проект и поддержит второй.

Было бы любопытно услышать обоснование. Если оно серьёзное, конечно.


Обоснование того, что водопад хорош для встроенного ПО или что он плох для сайта?

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

Может где-то в палате мер и весов есть сферический аналитик, способные создать спецификацию для сайта, который не придётся переделывать- но я там не был.
3 сен 19, 14:31    [21962543]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1751
softwarer
Лично для меня водопад ассоциируется в первую очередь с единственным за всю жизнь опытом работы по хорошо продуманному адекватному ТЗ, без лихорадочных переделок на ходу и перепроектирования из-за внезапной смены парадигмы. Когда задача поставлена так: "Берёшь ТЗ начиная с пункта 3.2.1.4 и делаешь одно за другим, пока не дойдёшь до 3.5. Как дойдёшь - приходи за следующей задачей". И через полтора месяца приходишь - всё сделал. Ну заодно - с тремя увеличениями зарплаты за полгода без единого слова с моей стороны и многими другими приятностями.


А что за продукт делался?
Он внедрён? Работает?
Насколько конкурентная разработка?
Какой примерно кусок делали?

Мне интересно- когда же водопад хорош...
3 сен 19, 14:33    [21962547]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58478
Блог
Vyatich
Что это был за проект, если не секрет?

ДМС для РОСНО. Возможно, помните - в конце девяностых некоторое время вся Москва была увешана рекламой типа "Людмила Зыкина - полис ДМС номер М2-123456". Вот оно самое.
3 сен 19, 14:48    [21962561]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Zmeelov2
Member

Откуда:
Сообщений: 245
softwarer
РОСНО

То самое РОСНО(RxLib)? Знаковое имя.
3 сен 19, 14:53    [21962566]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1751
softwarer
Vyatich
Что это был за проект, если не секрет?

ДМС для РОСНО.


Т.е. это внутреннее приложение для работы специально выделенных операторов?
Ну видел я подобный софт- перегруженные окна, действия выполняются с вдвое большими усилиями, чем можно- так как выбора у оператора нет и конкуренции тоже нет.
3 сен 19, 14:56    [21962570]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58478
Блог
Alexey Tomin
Обоснование того, что

В том, что я процитировал, было четыре отдельных утверждения. Хотелось бы обоснования каждого из них. И крайне желательно - так, чтобы если речь шла о "движке сайта", то и дальше она шла о "движке", а не о "сайте".
3 сен 19, 14:57    [21962571]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 456
Вот тут, например, есть известный мне набор рассуждений на эту тему.
4 сен 19, 13:54    [21963414]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
mirudom
Member

Откуда:
Сообщений: 1025
mirudom
Уважаемый Дмитрий Мух,
Подскажите пожалуйста, есть ли в Вашем окончании итерации, т.е. Ретроспективе, место для оценки
технических характеристик полученного продукта ( кода или ... ) ?
Ежели такое место есть - укажите пожалуйста.

WebSharper
Я хоть и не Дмитрий, но скажу про то, что видел сам и по что читал:

Обычно технические характеристики, если под этим понимаются нефункциональные требования оцениваются в процессе тестирования ( либо релиза либо конкретного элемента беклога либо и там и там) . Для этого предусматриваются acceptance criteria для конкретного элемента или/и definition of done.

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

skyANA
+1

также команда определяет набор SLO для своей области ответственности, в первую очередь для критических областей
пороги пропускной способности, скорости отклика и т.п.
по ним настраивает мониторинг и уведомления, чтобы в случае чего быстро отреагировать
непосредственно следит за текущими показателями, чтобы заранее исключить нарушения SLO

но если таки происходит инцидент, то собирается отдельная ретроспектива, где ищется Root Cause и составляется план действий, чтобы больше такого не было
но это уже Incident management (ITSM)...

Уважаемый skyANA,
это Вы отвечаете на поставленный мной вопрос о качестве кода, правильно ?
7 сен 19, 20:29    [21966104]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2060
Уважаемый mirudom,
вы не поставили вопрос о качестве кода
вы спрашивали, есть ли место на Ретроспективе для оценки технических характеристик продукта

если вас интересует именно качество кода, то сформулируйте соответсвующий вопрос
7 сен 19, 20:47    [21966114]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 456
mirudom
технических характеристик полученного продукта ( кода или ... ) ?
Ежели такое место есть - укажите пожалуйста.
Смысл вопроса Вам непонятен ?[/quot]

Вы поставили вопрос о технических характеристиках кода. Я так понял что это какие-то метрики получившегося продукта.

Или вы имели ввиду какие-то характеристики самого кода как исходного текста типа cyclomatic complexety, длина метода, покрытие тестами или что-то типа того?
8 сен 19, 10:46    [21966246]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 456
mirudom
Уважаемый skyANA,
это Вы отвечаете на поставленный мной вопрос о качестве кода, правильно ?


С моей точки зрения это является ответом на вопрос про место качества продукта в том числе и кода на ретроспективе и вообще в процессе.
8 сен 19, 10:52    [21966248]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2060
WebSharper,

возможно уважаемый mirudom не понимает как обеспечить качество в рамках его представлений об Agile/Scrum
8 сен 19, 11:32    [21966259]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 456
Дмитрий Мух
WebSharper,

возможно уважаемый mirudom не понимает как обеспечить качество в рамках его представлений об Agile/Scrum


Я бы предпочел не додумывать за него а просто услышать его уточнение вопроса.
8 сен 19, 11:41    [21966261]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2060
WebSharper
Дмитрий Мух
WebSharper,

возможно уважаемый mirudom не понимает как обеспечить качество в рамках его представлений об Agile/Scrum


Я бы предпочел не додумывать за него а просто услышать его уточнение вопроса.

Я предполагаю на основе прошлого с ним общения.
Будет хорошо, если он подтвердит, или развеет мои предположения, своими уточнениями.

Ждёмс..
8 сен 19, 11:53    [21966264]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Охранник смузи-машины
Member

Откуда:
Сообщений: 639
вот ещё нашёл отличное.
автор
Самым вопиющим примером являются офисы открытой планировки. Они не продуктивны. В них трудно сконцентрироваться. Они антиинтеллектуальны, поскольку люди боятся быть пойманными, читая книги (или просто думая) на работе. Когда вы заставляете людей притворяться продуктивными, они на самом деле теряют продуктивность. Офисы открытой планировки вообще не для продуктивности. Речь идёт о корпоративном имидже.

Хорошо известно, что творческие люди теряют креативность, если их просят объясниться во время работы. То же и с программным обеспечением. Программистам часто приходится работать в условиях односторонней прозрачности. Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности. Вместо того, чтобы работать над фактическими долгосрочными проектами, которыми человек мог бы увлечься, они низведены до работы над атомизированными, функциональными «пользовательскими историями» и часто запрещают работать над улучшениями, которые не связаны с краткосрочными, непосредственными потребностями бизнеса (часто спускаемыми сверху). Этот неправильный, но распространённый вариант Agile исключает понятие собственности и расценивает программистов как взаимозаменяемые, одинаковые компоненты.

Scrum — худший вариант, с глупостью двухнедельных «итераций». Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Это неправда.

Хорошие инженеры хотят работать в фирмах, управляемых инженерами, где они будут участвовать в планировании работы без необходимости оправдываться перед «скрам-мастерами», «владельцами продукта» и несколькими уровнями менеджеров-гуманитариев.

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.


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


клац
8 сен 19, 19:26    [21966346]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
WebSharper
Member

Откуда:
Сообщений: 456
Охранник смузи-машины
вот ещё нашёл отличное.


Вы уже второй раз это нашли: 21687616! Ничего не болит и всегда что-то новенькое ;).

Кстати, не ответите ли на вопрос из вот этого сообщения 21961497
8 сен 19, 19:59    [21966356]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Citizen 4
Member

Откуда:
Сообщений: 4
Скрам это про самоорганизующиеся команды, прежде всего. Чтобы команда противостояла натиску бэклога, объединялась перед общим врагом - сплачивалась. Для этого начальникам вырывают клыки и делают из них скрам-мастеров, чтобы вместо руководства они занимались фасилитацией. Это подразумевает управление на уровне фактов-историй-идеологии, т.е. более медленные по времени процессы, зато более устойчивые, и ведущие к информационной прозрачности. Потому что самые лучшие команды по разработке ПО обладали прозрачностью в 80% - каждый в команде знал 80% того, что делает другой. Тут появляется чувство локтя, ты понимаешь, что твоя спина прикрыта, и готов как в правиле русском: сам погибай, а товарища выручай.
В результате формируется команда, которая и без твоего руководства продолжает развиваться.

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

Таким образом, на мой взгляд споры про SCRUM/Agile - это как споры про то, что лучше - джазз или классическая музыка, при том, что и ту, и другую музыку вам напевали Рабинович и Мойша из анекдота. Зачастую СКРАМ внедряется без его понимания, только для галочки, чтобы отчитаться перед боссом. В этом случае СКРАМ/Эджайл - искажаются до неузнаваемости.

Мы можем управлять только тем, что проще нас. Если СКРАМ/Эджайл/Ватерфолл не понимается, не ясна их природа - на выходе получается что угодно, только не то, что данные подходы подразумевают.
8 сен 19, 22:35    [21966404]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Вован Барабан
Member

Откуда:
Сообщений: 73
Недавно вышел на новый проект. На днях был скрам kick-off. На нем я узнал, что в скраме нет роли тимлида. И возрадовался.
8 сен 19, 22:39    [21966405]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Wizandr
Member

Откуда: Империя Добра
Сообщений: 36923
Citizen 4,

автор
Скрам это про самоорганизующиеся команды, прежде всего. Чтобы команда противостояла натиску бэклога, объединялась перед общим врагом - сплачивалась. Для этого начальникам вырывают клыки и делают из них скрам-мастеров, чтобы вместо руководства они занимались фасилитацией. Это подразумевает управление на уровне фактов-историй-идеологии, т.е. более медленные по времени процессы, зато более устойчивые, и ведущие к информационной прозрачности. Потому что самые лучшие команды по разработке ПО обладали прозрачностью в 80% - каждый в команде знал 80% того, что делает другой. Тут появляется чувство локтя, ты понимаешь, что твоя спина прикрыта, и готов как в правиле русском: сам погибай, а товарища выручай.



именно по этому работать из отпуска уже стало практически нормой
чушь собачья
8 сен 19, 23:34    [21966427]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Вован Барабан
Member

Откуда:
Сообщений: 73
Wizandr
Citizen 4,

автор
Скрам это про самоорганизующиеся команды, прежде всего. Чтобы команда противостояла натиску бэклога, объединялась перед общим врагом - сплачивалась. Для этого начальникам вырывают клыки и делают из них скрам-мастеров, чтобы вместо руководства они занимались фасилитацией. Это подразумевает управление на уровне фактов-историй-идеологии, т.е. более медленные по времени процессы, зато более устойчивые, и ведущие к информационной прозрачности. Потому что самые лучшие команды по разработке ПО обладали прозрачностью в 80% - каждый в команде знал 80% того, что делает другой. Тут появляется чувство локтя, ты понимаешь, что твоя спина прикрыта, и готов как в правиле русском: сам погибай, а товарища выручай.



именно по этому работать из отпуска уже стало практически нормой
чушь собачья

Это от человека зависит. Кому то просто нравится работать. Не из под палки. Из под палки прогера фиг заставишь.
8 сен 19, 23:43    [21966433]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Wizandr
Member

Откуда: Империя Добра
Сообщений: 36923
Вован Барабан
Wizandr
Citizen 4,

пропущено...



именно по этому работать из отпуска уже стало практически нормой
чушь собачья

Это от человека зависит. Кому то просто нравится работать. Не из под палки. Из под палки прогера фиг заставишь.


никакой палки не нужно
достаточно чтобы человек понимал что вслучае отпуска его обязанности перейдут к коллегам и искать себя в проекте после отпуска придется заново
9 сен 19, 14:27    [21966872]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Охранник смузи-машины
Member

Откуда:
Сообщений: 639
Вован Барабан
в скраме нет роли тимлида


К сообщению приложен файл. Размер - 92Kb
9 сен 19, 16:34    [21967055]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг . Part 2.  [new]
Quartz
Member

Откуда: МО
Сообщений: 466
Alexey Tomin
По сути ощущения от работы зависят только от команды- какие люди, какие руководители.
Все беды- от попытки создать продукт плохой командой под руководством менеджера- идиота.

По-моему, бесспорные утверждения. Но причём тут процессы?..

Alexey Tomin
Методология должна выбираться под продукт. Для разработки ПО управления автомобилем водопад хорош, для движка веб-сайта это смерть. Аналогично agile - убьёт первый проект и поддержит второй.
Но только если квалификация всех работников достаточная. Без этого не поможет ничего.

Что-то я не встречал предупреждений об убийстве проекта от "фасилитаторов эджайла" )))
В agilemanifesto тоже нет. Расскажите свой рецепт ветвления проектов, плиз.
9 сен 19, 17:11    [21967089]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9   вперед  Ctrl      все
Все форумы / Работа Ответить