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

Откуда:
Сообщений: 253
Василий_100
veep,

Да, проблема Скрам не в нем самом, а в том, кто это придумал и в тех, кто внедряет его. По сути это крайне ужасная методология. Она важнее для бизнеса.


Да и кстати разве команда разработчиков это не бизнес?
16 июл 18, 23:55    [21576371]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
veep
Member

Откуда:
Сообщений: 253
Охранник смузи-машины
а ещё дэйли скрам превращают в персональный отчёт перед начальником отдела


Это не скрам уже, начальник (продукт оунер) ходит на планирование и закрытие и ретроспективу и то по желанию.
16 июл 18, 23:58    [21576375]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1648
Vyatich
Alexey Tomin
пропущено...
А что лучше? Просто работать без процесса? ИлиRUP какой? Или водопад?
Интересно же, куда бежать.

Интересно, а чем конкретно не устраивают RUP с водопадом?


Водопад пробовал. Это п..ц. Перекладывание ответственности. Архитектуру рисует непойми кто. Когда во время проектирования выясняется, что архитектура хромает- "уже выбрано".
Этап проектирование кое-как сделан- а теперь попробуем это акодировать. Что, фигня получилась? Не, проект же есть.
Постепенно перешли к варианту- "ладно, сделай как правильно- проект нарисуем по коду".
Теперь это дошло до тестировщиков. Если ошибка в проекте- то начинается перекидывание какашек между тремя людьми. "Бага"- "ошибка в проекте"- "не, проект правильный, разбирайтесь сами".
Ну да ладно. 3 года строили- наконец построили. попробовали запустить. Админы увидели запросы- и не знают, то ли убить кого-нибудь, то ли просто бежать отсюда нафиг. Переписывать запросы поздно.
Нафиг. Пробовал- это способ потратить в 2 раза больше времени и получить не рабочий продукт.

RUP не пробовал. А кто-нибудь может сказать, что это хорошо?
17 июл 18, 06:15    [21576510]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Василий_100
Member

Откуда:
Сообщений: 107
Alexey Tomin,

По RUP работал более 5 лет в далёких 2005-20010 гг. И это реально хорошо, удобно, надёжно и дёшево. Рекомендую.
17 июл 18, 08:59    [21576694]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
17-77
Member

Откуда:
Сообщений: 1349
Alexey Tomin
А что лучше? Просто работать без процесса? ИлиRUP какой? Или водопад?
Интересно же, куда бежать.

быть гибким, сборная солянка, видишь что ежедневные митинги съедают кучу времени - ф топку их

я в целом за итеративный процесс + архитектура с заделом на будущее или какие-то точки расширения, но это основано на опыте.
основная цель - уменьшить время на исправление ошибок архитектуры, так как они самые дорогие. и исправление в данном случае - это не костыль, а нормальное. а то проект в итоге скатится в говнокод
17 июл 18, 09:08    [21576707]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Полковник.
Member

Откуда:
Сообщений: 1817
Alexey Tomin,

В том, что ваше руководство не желало платить архитектору, поэтому у вас сапоги точал пирожникиа пироги пек сапожник виновата водопадная модель. Так что ли? И при чем тут методология, если в ва́шей конторе все через ж. делается? Переделывать всё по сто раз, потому что проект стартагул без архитектора и аналитика это теперь аджайл и скрам хахаха.
17 июл 18, 09:29    [21576742]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2069
Охранник смузи-машины
Этот новоявленный скрам-мастер в лице начальника отдела, который отстранил прежнего скрам мастера, назначает ежедневные скрам-митинги, но сам на них регулярно забивает!

наш тракторист, по пьяни, утопил новый трактор "кировец". плохие и очень негодные трактора, никому не советую!!!1!111 ;)
17 июл 18, 09:53    [21576799]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1648
Полковник.
Alexey Tomin,

В том, что ваше руководство не желало платить архитектору, поэтому у вас сапоги точал пирожникиа пироги пек сапожник виновата водопадная модель. Так что ли? И при чем тут методология, если в ва́шей конторе все через ж. делается? Переделывать всё по сто раз, потому что проект стартагул без архитектора и аналитика это теперь аджайл и скрам хахаха.


Ты спутал всё в одну кучу :)
Во-первых водопад был давно и в другом месте.
Во-вторых итеративные технологии не просто так придуманы. Когда делается PoC а затем MVP то все проблемы видны сразу, а не когда уже позно.
В-третьих, в конкретном месте следующий проект, стартовавший в скраме, зашёл намного лучше, чем водопадный.

Вообще технология должна соответствовать продукту/проекту.
Одно дело, когда делает ПО для спутника. Тут водопад нужен.
Другое, когда делается бизнес-продукт. Тут никто вообще не знает ни всей нагрузки, ни нужных фич- не то, что до внедрения, а и после тоже. И тут гибкие технологии (скрам, канбан, их смесь) очень помогают. Но надо уметь пользоваться, да.
17 июл 18, 10:17    [21576877]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Langobard
Member

Откуда: Новосибирск
Сообщений: 35
Работал по Скраму чуть больше года.
Первые пару месяцев было трудно и не совсем понятно "Нафига это всё?".
Жуткое раздражение вызывали:
1. Постоянные тренинги (в виде "игрищ");
2. Ретроспективы и планирования, которые тянулись часами;
3. Цепочки взаимозависимых задач. В том числе в результате непредвиденных проблем, которые могли возникнуть по вине других команд (поскольку у них были свои приоритеты).
4. Ошибочная оценка сроков выполнения задач.

В результате наша небольшая команда (3 разработчика + продукт оунер + скрам мастер) постоянно напрягалась, а выхлопа было мало.
Что было сделано:

1. Мы отказались от всех игрищ, поскольку вся эта "геймизация разработки" может быть интересна только вчерашним студентам, а все разработчики были в возрасте 30-35 лет.

2. Свели ретроспективы к минимуму. Перестали заниматься всякой фигней (что понравилось/не понравилось и прочей манагерско-психологической лабудой). Обсуждали только возникшие проблемы: почему не получилось выполнить какие-то задачи.
Планирование стало проще, когда появился нормальный бэклог задач (40-50 задач и более).

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

4. Пару раз провели спринты с "Burning up chart" вместо "Burning down chart", чтобы оценить сколько стори-поинтов мы реально можем закрыть. Стали дробить задачи на более мелкие. Появились "исследовательские" задачи на 1-2 SP. Появились "технические" задачи, которые не "поставляли ништяки пользователям". В каждый спринт мы стали брать разные задачи. Например: одна крупная, пару средних, несколько мелких, по одной исследовательской и технической.

Справедливости ради, отмечу, что руководство пошло нам на встречу. У него сдулся фанатизм, поскольку мы придерживались технологии, пусть и отбросив некоторые "фишечки" (которые скрам-консалтеры с нездоровым блеском в глазах втирали чуть ли ни как "без этой хреновины это будет уже не скрам!!!").
Скрам-митинги были по 5-10 минут. Обсуждали только 3 вещи:
- кто что сделал вчера;
- кто что будет сегодня;
- вопросы по взаимодействию, при необходимости.

--------------------------------------
Смешно читать завывания местных троллей про то, как плох Скрам.
Скрам плохо работает на больших проектах с командами более 10 человек.
Скрам не подходит для сложных задач, которые нельзя декомпозировать.
Для любителей подумать месяц-другой над задачей есть другие способы организации работы. Сам в прошлом занимался такими задачами, да и сейчас иногда занимаюсь (на текущей работе нет Скрама).

Толстолобость рукововодства + Капризность разработчиков = Вселенский вой на форумах.

Причина по которой я это написал: уже весь форум "Работа" завалили "соплями" непризнанных "гениев", которых обидели злые манагеры.
17 июл 18, 10:19    [21576885]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
17-77
Member

Откуда:
Сообщений: 1349
Langobard,

+1 вот она гибкость

Langobard
Появились "исследовательские" задачи на 1-2 SP. Появились "технические" задачи, которые не "поставляли ништяки пользователям"

+1 тоже пришел к этому

только я еще и митинги убрал, потому что они длились полчаса-час каждый день на всю команду 8-10 человек. я прикинул, что комнда в целом при этом теряет 4-10 часов чистого рабочего времени ежедневно (!) и перевел все на личные митинги с одним человеком и только по его вопросам
17 июл 18, 10:28    [21576914]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
КритерийОтбора
Member

Откуда:
Сообщений: 1813
Langobard
"Работа" завалили "соплями" непризнанных "гениев", которых обидели злые манагеры.


а на что еще списать свои фейлы?

не я такой, жизнь скрам/начальник/скульру/язык/страна такие
17 июл 18, 10:35    [21576943]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Агнец за бортом
Member

Откуда:
Сообщений: 1189
Langobard,

Хорошо разложил. Но как продавать "крупные" технические задачи?
17 июл 18, 10:43    [21576967]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Langobard
Member

Откуда: Новосибирск
Сообщений: 35
17-77
только я еще и митинги убрал, потому что они длились полчаса-час каждый день на всю команду 8-10 человек.


Забыл уточнить, что я один из трех разработчиков, а не скрам-мастер или руководитель :-)

Митинги у нас остались, иногда на них присутствовало руководство, но напряга не вызывали.

В другой команде нашего отдела было примерно столько же человек, как у Вас. По моим наблюдениям, им удавалось уложится в 15-20 минут. Наблюдал постоянно, поскольку сидели мы с ними в одном большом кабинете (и у нас, и у них были сотрудники в разных офисах: собственно Новосибирск и Академгородок).
17 июл 18, 10:47    [21576986]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55665
Блог
Alexey Tomin
А что лучше? Просто работать без процесса? ИлиRUP какой? Или водопад? Интересно же, куда бежать.

В принципе - зависит от задачи. Лично по мне, лучше всего было так, как я работал на удалёнке:

1. Итеративный процесс с недельными итерациями
2. Отсутствие митингов и прочей идиотской фигни
3. Из нескольких источников (аналитики, тестировщики, техподдержка) идут задачи
4. Я проставляю задачам оценочную трудоёмкость. Шкала примерно следующая - 30m/1h/2h/4h/1d/2d/3d. Большие задачи дробятся. Спорные - исследуются. Задачи больше 2d - редкость.
5. В понедельник начальник отбирает из оцененных задач пул работ на неделю из расчёта 32 часов. Если у него возникают вопросы, я объясняю оценку трудоёмкости. Если у меня возникают вопросы, я объясняю, почему не хочу делать эту задачу именно сейчас.
6. В пятницу я сдаю выполненный набор задач с тестами для них. Если не успел к пятнице - сдаю максимум к понедельнику. Собирается релиз.
7. Следующую неделю тестировщики гоняют релиз. Если находят баги, то сдают их в виде воспроизводящего тестового скрипта. Поэтому они, как правило, правятся почти без дополнительной трудоёмкости (в рамках 8 часов, зарезервированных на "прочее")
17 июл 18, 10:50    [21576992]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Langobard
Member

Откуда: Новосибирск
Сообщений: 35
Агнец за бортом
Langobard,

Хорошо разложил. Но как продавать "крупные" технические задачи?


На мой взгляд, только дробить на этапы.
При чем результатом будет не "ништяк для пользователя", а протестированная задача.
Такие у меня тоже были, когда я переводил одну из наших систем с MySQL на PostgreSQL. Мы выкатывали изменения (таблицы, процедуры и т.д.) на специально созданный для этого тестовый сервер.
Параллельно с моими изменениями в БД, коллеги по команде вносили свои изменения. Когда всё было сделано (около 2 месяцев), мы просто накатили все изменения на бой.

Если же и такое невозможно, то надо выбирать не Скрам, а то, что больше подходит.
17 июл 18, 11:04    [21577041]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
17-77
Member

Откуда:
Сообщений: 1349
Langobard
По моим наблюдениям, им удавалось уложится в 15-20 минут.

т.е. на 10 человек - это 150-200 минут в день, или 750 - 1000 в неделю, или 12,5-16,7 часов работы, тоже нехило
например я за 4 ч на своих проектах - менял транзакционную подсистему на более надежную (архитектурная ошибка выбора библиотеки/подхода) или переводил с Oracle на MS SQL (внешнее новое требование)
17 июл 18, 11:24    [21577121]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Langobard
Member

Откуда: Новосибирск
Сообщений: 35
17-77
т.е. на 10 человек - это 150-200 минут в день, или 750 - 1000 в неделю, или 12,5-16,7 часов работы, тоже нехило



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

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

Экономия возможна, только если у Вас в команде только кодеры, которые пишут строго по ТЗ и неопределенность стремится к нулю.
17 июл 18, 11:52    [21577227]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Addx
Member

Откуда:
Сообщений: 957
Проблема не в Agile и Scrum - это хорошие технологии. Проблема в их восприятии в глазах руководства. Скрам превращается в "нескрам". Некоторые воспринимают его так:

1. Софт пишется быстрее. За две недели можно сделать то, что раньше делали месяц.
2. Есть ежедневная отчетность. Каждый должен предъявить то, что сделал. Слова "делал ревью", "изучал архитектуру", "столкнулся с проблемой" - должны быть исключены. Либо сделал, либо нет. Если нет - сиди хоть круглосуточно, но сделай.
3. На каждом спринте должна быть достигнута бизнес-ценность. Если месячный продукт не ушел в прод - то это не бизнес-ценность.
4. Если успел - это нормально, можно и больше в следующий раз запланировать. Если нет - это твоя вина. Нужно наказать тем или иным образом.
5. ПО более гибкое - его можно переделывать хоть каждый день, на финальных сроках это не скажется.

Гибкие технологии в моде, вникать в их смысл многие не хотят.
Отсюда и негативное восприятие многих разработчиков - они столкнулись именно с таким "скрамом".
17 июл 18, 11:56    [21577241]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Василий_100
Member

Откуда:
Сообщений: 107
Alexey Tomin
Полковник.
Alexey Tomin,

В том, что ваше руководство не желало платить архитектору, поэтому у вас сапоги точал пирожникиа пироги пек сапожник виновата водопадная модель. Так что ли? И при чем тут методология, если в ва́шей конторе все через ж. делается? Переделывать всё по сто раз, потому что проект стартагул без архитектора и аналитика это теперь аджайл и скрам хахаха.


Ты спутал всё в одну кучу :)
Во-первых водопад был давно и в другом месте.
Во-вторых итеративные технологии не просто так придуманы. Когда делается PoC а затем MVP то все проблемы видны сразу, а не когда уже позно.
В-третьих, в конкретном месте следующий проект, стартовавший в скраме, зашёл намного лучше, чем водопадный.

Вообще технология должна соответствовать продукту/проекту.
Одно дело, когда делает ПО для спутника. Тут водопад нужен.
Другое, когда делается бизнес-продукт. Тут никто вообще не знает ни всей нагрузки, ни нужных фич- не то, что до внедрения, а и после тоже. И тут гибкие технологии (скрам, канбан, их смесь) очень помогают. Но надо уметь пользоваться, да.


Ничего не понимаю.
Прошу помочь разобраться:
1. Как и в каких местах водопадная модель поможет уклониться от технических рисков и сложностей? Ведь предвидеть всё это находясь "наверху" просто нереально. А "внизу" - уже поздно.
2. Водопадная модель более длительная и трудоёмкая. А заказчик требует результат или статус выполнения работ уже сразу или через 1-2 недели. Значит, водопадная модель подходит только для крупных проектов с длительными сроками?
3. Agile и SCRUM суммарно съедают 10% бюджета за счёт регулярных стэндапов, досок позора и почти ежедневной отчётности?
Я оценивал стоимость именно так. Потому как на стэндапах присутствует вся команда. А вот при каскадной модели могут отрабатывать только трое - архитектор и ведущий бизнес-аналитик, ПМ. Так?
17 июл 18, 12:02    [21577264]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
ponuch
Member

Откуда: PonuchLand
Сообщений: 3982
Addx
Проблема не в Agile и Scrum - это хорошие технологии. Проблема в их восприятии в глазах руководства. Скрам превращается в "нескрам". Некоторые воспринимают его так:

1. Софт пишется быстрее. За две недели можно сделать то, что раньше делали месяц.
2. Есть ежедневная отчетность. Каждый должен предъявить то, что сделал. Слова "делал ревью", "изучал архитектуру", "столкнулся с проблемой" - должны быть исключены. Либо сделал, либо нет. Если нет - сиди хоть круглосуточно, но сделай.
3. На каждом спринте должна быть достигнута бизнес-ценность. Если месячный продукт не ушел в прод - то это не бизнес-ценность.
4. Если успел - это нормально, можно и больше в следующий раз запланировать. Если нет - это твоя вина. Нужно наказать тем или иным образом.
5. ПО более гибкое - его можно переделывать хоть каждый день, на финальных сроках это не скажется.

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


как точно описана система разработки в рт лабс !
17 июл 18, 12:33    [21577355]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Василий_100
Member

Откуда:
Сообщений: 107
Addx
Проблема не в Agile и Scrum - это хорошие технологии. Проблема в их восприятии в глазах руководства. Скрам превращается в "нескрам". Некоторые воспринимают его так:

1. Софт пишется быстрее. За две недели можно сделать то, что раньше делали месяц.
2. Есть ежедневная отчетность. Каждый должен предъявить то, что сделал. Слова "делал ревью", "изучал архитектуру", "столкнулся с проблемой" - должны быть исключены. Либо сделал, либо нет. Если нет - сиди хоть круглосуточно, но сделай.
3. На каждом спринте должна быть достигнута бизнес-ценность. Если месячный продукт не ушел в прод - то это не бизнес-ценность.
4. Если успел - это нормально, можно и больше в следующий раз запланировать. Если нет - это твоя вина. Нужно наказать тем или иным образом.
5. ПО более гибкое - его можно переделывать хоть каждый день, на финальных сроках это не скажется.

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


Во. В точечности так! Именно в таком виде преподносится SCRUM в тех конторах, про которые знаю. И платят в таких конторах хуже всего. Во.
По сути, Agile и SCRUM являются признаками нищебродства и жадности работодателей. Дыма без огня не бывает.
17 июл 18, 12:36    [21577365]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Langobard
Member

Откуда: Новосибирск
Сообщений: 35
Addx
1. Софт пишется быстрее. За две недели можно сделать то, что раньше делали месяц.


Справедливо лишь отчасти. Первые 3-4 месяца мы никогда не закрывали спринты полностью и только потом "вошли в ритм".
Софт пишется быстрее, поскольку пользователи на Демо видят доработки. Демо проводятся после каждого спринта. Одно дело, когда вы получили от пользователя обратную связь на стадии прототипа, а другое дело, когда 3-4 месяца вы ваяли свою "нетленку", а потом оказалось, что все не так и приходится тратить уйму времени на рефакторинг.
Так что, да - скорость повышается, но не сразу и не всегда в два раза.

Addx
2. Есть ежедневная отчетность. Каждый должен предъявить то, что сделал. Слова "делал ревью", "изучал архитектуру", "столкнулся с проблемой" - должны быть исключены. Либо сделал, либо нет. Если нет - сиди хоть круглосуточно, но сделай.


Такой хрени у нас не было. Про "исследовательские" задачи писал выше.

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


Да, должна. Но не в ущерб системе. Добавляйте в бэклог задачи по рефакторингу, технические задачи. А потом берите их в спринты. Если руководство Вас не воспринимает, как полноценного сотрудника с правом голоса в технических вопросах, то это проблемы руководства и Ваши, а не Скрама. Такое руководство при любой методологии будет выжимать все соки. Бегите оттуда :-)

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


Нет. Если не успел, то обсуждается на ретроспективе.
Если цель наказать, то найдут за что при любой методологии разработки.

Addx
5. ПО более гибкое - его можно переделывать хоть каждый день, на финальных сроках это не скажется.


Тут ничего не могу сказать, поскольку у нас был внутренний продукт. У меня нет опыта заказной работы по Scrum.

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


Я редко пишу на форуме, чаще читаю после вкусного обеда :-)
Но в последние месяцы я почти каждую неделю вижу скулёж и размазывание соплей на тему Скрама. Зачастую даже в темах, которые не связаны с Agile.
Поэтому, придя с обеда и увидев очередные завывания обиженных, я и решил написать "портянку" с описанием своего опыта работы по Scrum.
17 июл 18, 12:44    [21577381]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Агнец за бортом
Member

Откуда:
Сообщений: 1189
Langobard
Агнец за бортом
Langobard,

Хорошо разложил. Но как продавать "крупные" технические задачи?


На мой взгляд, только дробить на этапы.
При чем результатом будет не "ништяк для пользователя", а протестированная задача.
Такие у меня тоже были, когда я переводил одну из наших систем с MySQL на PostgreSQL. Мы выкатывали изменения (таблицы, процедуры и т.д.) на специально созданный для этого тестовый сервер.
Параллельно с моими изменениями в БД, коллеги по команде вносили свои изменения. Когда всё было сделано (около 2 месяцев), мы просто накатили все изменения на бой.

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


Да, ты прав.
17 июл 18, 12:49    [21577399]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1648
Василий_100
1. Как и в каких местах водопадная модель поможет уклониться от технических рисков и сложностей? Ведь предвидеть всё это находясь "наверху" просто нереально. А "внизу" - уже поздно.


Водопад позволяет уйти от ответственности. Разделив всё на шаги- получается, что за результат никто не отвечает. И, самое главное, множество ошибок невозможно исправить.

Василий_100
2. Водопадная модель более длительная и трудоёмкая. А заказчик требует результат или статус выполнения работ уже сразу или через 1-2 недели. Значит, водопадная модель подходит только для крупных проектов с длительными сроками?


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

Василий_100
3. Agile и SCRUM суммарно съедают 10% бюджета за счёт регулярных стэндапов, досок позора и почти ежедневной отчётности?


У нас тратится 5-10 минут в день (1-2%) плюс до 2х часов в 2 недели (2,5%). Итого 4%.
За это мы получаем полезный обмен опытом ("я делаю это, есть проблемы" - "а, я знаю, подходи потом"), понимание, что происходит (что было, что будет), фидбек от техподдержки и заказчика (через техподдержку).
Ну и когда третий день человек делает то же самое- значит надо помочь- это хорошо видно.

Василий_100
Я оценивал стоимость именно так. Потому как на стэндапах присутствует вся команда. А вот при каскадной модели могут отрабатывать только трое - архитектор и ведущий бизнес-аналитик, ПМ. Так?


Только их решение потом выльется в слёзы при эксплуатации. Невозможно предусмотреть всё, пока код не напишешь.

А про прессинг и потогонку- это не имеет никакого отношения к делу. У нас вон уходил один в контору, где никаких скрамов- через 3 месяца обратно прибежал- мол постоянно до ночи допиливать надо что-то
17 июл 18, 13:03    [21577427]     Ответить | Цитировать Сообщить модератору
 Re: Агиле/Скрам или прессинг ?  [new]
WebSharper
Member

Откуда:
Сообщений: 414
Langobard
Скрам плохо работает на больших проектах с командами более 10 человек.


Для работы над большими задачами есть всякий SCRUM of SRUMs, SAFe, Nexus, которые вуключают в себя команды, работающие по скраму канбану. SAFe например, рекомендует размер от 5 до 11 человек.

Толстолобость рукововодства + Капризность разработчиков = Вселенский вой на форумах.


Судя по тому, что пишут, просто пытаются внешние признаки скрама (причем выборочно) натянуть на отношения "ты начальник - я дурак". А разобраться в том, какие идеи лежат за фреймворком не хочет никто из этих начальников и работников :).
17 июл 18, 13:07    [21577440]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 29   вперед  Ctrl
Все форумы / Работа Ответить