Каморка

george писал(а):Гади, акела, вы в каких конторах работаете?

не банки ни разу. Telecommunications, IP networking/protocols.

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

Скрамы занимают 15 минут в день, и это не напрягает, при условии что удалось отмахаться от роли скрам-мастера :)

У меня ощущение, что тут спутаны апельсины с помидорами.

В банках по определению не бывает кривых requirements?

Недоделано/недотестировано - легко, если гнаться только за "стори-поинтами". Если же составить (и контролировать) нормальные "definition of done", достаточно строгие критерии по покрытию кода тестами, плюс откровенно посылать недоделанные requirements - жизнь становится возможной даже с agile

А если еще QA грамотный - фиг вы вообще "сдадите" кривые недоделки

K.B. писал(а):У меня ощущение, что тут спутаны апельсины с помидорами.

В банках по определению не бывает кривых requirements?

Недоделано/недотестировано - легко, если гнаться только за "стори-поинтами". Если же составить (и контролировать) нормальные "definition of done", достаточно строгие критерии по покрытию кода тестами, плюс откровенно посылать недоделанные requirements - жизнь становится возможной даже с agile

А если еще QA грамотный - фиг вы вообще "сдадите" кривые недоделки

Все бывает, Вы просто невнимательно почитали.
Речь идет о: 1) повышенной опасности сделать что-то не так в случае с agile, и о 2) рисках для банка, с этим связанными.

1) Я все еще затрудняюсь понять чем правильно организованный agile качественным QA более рискован чем waterfall
2) Только банки могут терять деньги/клиентов от кривого софта?

Конечно же, требования к спецификациям, архитектуре и процессу QA у банков строже. Но это не значит, что Agile неприменим. Это означает, что velocity в банках будет ниже по определению, но процесс вполне работоспособен имхо

K.B. писал(а):1) Я все еще затрудняюсь понять чем правильно организованный agile качественным QA более рискован чем waterfall
2) Только банки могут терять деньги/клиентов от кривого софта?

Конечно же, требования к спецификациям, архитектуре и процессу QA у банков строже. Но это не значит, что Agile неприменим. Это означает, что velocity в банках будет ниже по определению, но процесс вполне работоспособен имхо

Когда мы ставим вопрос о снижении velocity, то нам говорят - гайз, мы скатываемся к вотерфолу. У спринта есть сроки (2 недели), и будьте любезны их придерживатца. Если вам не хватает ресурсов для тестинга, то давайте мы перебросим вам девелопера в помощь, из того же тима. Хе-хе, и что девелопер там натестирует? Свой стрейт-форвард сценарий? Ну вот так оно и получается... И не только в этом дело. Девелопер в принципе способен справиться в поставленные сроки со всеми своими "user stories", но уже отмечено, что: на перформанс ему пофик, на недопущение cut&paste технологии - пофик, вообще на продуманный дезайн - пофик. Главное - скорость разработки. Пировское code review проскакивается на раз, кому охота вникать-то, особенно когда сроки сжатые. На первый взгляд ОК, ну и pass. А "product owner" во время "demo" (последний день спринта!) может и промолчать, что что-то не так. Ибо.

Я бы сказал, что применимо к небольшим проектам или change request-ам, и то еще подумать...

А, про scrum митинги - раздражает то, что они каждый день. Запрещено работать из дома, когда на Agile проекте. Проходится на работу тащитца. Беспердел!

Кстати, вот еще мнение, но тут правда товарищ с т.зр. распила бабла рассматривает вопрос.
http://blog.jdevelop.com/software/2015/06/28/scrum.html

Как обычно, хорошая идея - плохое внедрение?

Моя команда:
Я работаю из дома, еще 2 человека + менеджер - в Техасе, еще один парень сидит дома в Остине, ПО & QA - в Южной Калифорнии

еще ни разу никто не нажимал на ускоренное code review только чтобы отчитаться; аналогично, если тестирование не закончено - вся story не закончена

Часто оказывается, что что-то недооценили при планировании - тогда просто задачи разбиваются на отдельные куски. Для демо предполагается только то, что на 100% прошло QA..

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

Я просто оставлю это здесь.

tfrog писал(а):
Я просто оставлю это здесь.

Вот-вот!

Вообще же, если разбивать таски на подтаски, и переносить их частично на следующий спринт, то мы таки реально скатываемся к вотерфоллу, и нам т.н. "скрам коачи" об постоянно говорят. (Кстати, эти гайз тоже денег стоят, и немеряных). Так какой тогда смысл вообще в аджайле? Плюс, с документацией таки есть проблемы, о чем тут уже говорили. Человек уволился - и концов не найти.
Нет, ребяты-демократы, это лажа все. Не должно оно работать в банках, по крайней мере.
Свежий пример - человек не смог сделать какой-то срочный платеж в онлайне, русский кстати. И до того был frustrated, что аж CEO письмо написал. И что мы имеем в итоге? - потеря клиента (скорее всего), плюс потеря репутации банка. Не говоря уже о том, что фикс стоит денег, и немалых. Дай Бог еще, чтобы этот клиент не эскалейтил до омбудсмена или до масс-медиа, или до суда вообще.
Наверное, если речь идет о каком-то биллинге, или о каком-то веб-сайте, то там еще можно. Но тут слишком все сенситив, оно "по-живому", касается живых людей, которым часто надо "здесь и сейчас". А если еще посмотреть на секьюрити, на лигал ишуес? Легко можно попасть на каких-то хакеров, или "сильно умных" клиентов, которые усмотрят что-то незаконное. А просто что-то не учли, недодумали, недодевелопили, недотестили. Ну и что? Банк потеряет миллионы... Пока что Господь миловал, но ИМХО, оно все очень опасно...
Давайте еще на АЭС аджайл внедрим, или в аэропортах Утрированно, но идея та же.

george писал(а):Банк потеряет миллионы...

чьи?

идея agile - не в выпуске сырого и недоделанного кода, а в разделении задач/проектов на отдельные небольшие кусочки, которые могут быть 100% завершены за фиксированные промежутки времени

это не отменяет full regression testing и пр. и пр.

Ваши "скрам коачи" какое-то недоделанные, если против разбивания историй. Это как раз и является адаптацией к изменениям, и главная идея - поиметь хоть небольшой, но 100% законченный кусочек к концу спринта

Это не отменяет полной проверки новых версий от начала до конца перед релизами. Ваш QA обо$рался, а виноват agile? А при ватерфолле QA всегда был белый и пушистый? Или девелоперы тестировали свои фенечки в 3 раза дольше?

K.B. писал(а):идея agile - не в выпуске сырого и недоделанного кода, а в разделении задач/проектов на отдельные небольшие кусочки, которые могут быть 100% завершены за фиксированные промежутки времени

Читаем определение

Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing,[1] cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.

Иными словами, идея аджайл в том чтобы не разрабатывать полную документацию с самого начала (потому как требования неизвестны), а итерактивными шагами с рабочими примерами прийти к взаимному удовольствию.
В финансовой сфере это крайне опасно, потому как непонятно, кто будет отвечать если через полгода выяснится какой-то баг, который при недостатке документации воспринимался не как баг а как фича?