Здравствуйте, Министр Промышленности, Вы писали:

МП>но только сильно недооценивается следующий фундаментальный фактор:
МП>моральные силы разработчика — это ценный, медленно возобновляемый ресурс
МП>нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день

Так никто ж и не ожидает 8 часов работы.
Когда я работал в Microsoft, в моей команде были двухнедельные спринты и время на выполнение запланированных задач рассчитывалось как 25 рабочих часов в неделю. Остальное врем съедали митинги, переписка и прочее. И результат был вполне нормальным.

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

Здравствуйте, landerhigh, Вы писали:

L>>>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам.
IT>>А что по-твоему делает этот сложный инженерный процесс сложным?
L>Ничего его не делает сложным.
L>Он такой есть. Изначально.
L>Если бы он был простым, уже давно вся разработка софта сводилась бы к набросу кубиков в чем-то вроде Rational Rose. Но пока все попытки упростить процесс его лишь усложняют.

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

L>Что значит "перекладывая ответственность". А кто, по твоему, вообще должен отвечать за "готовность модуля"?

В аджайле? Все. Аджайл — это коллективная ответственность. Ака колхоз.

IT>>а далее с них всех вместе взятых на заказчика.
L>Не перекладывает на заказчика, а вовлекает заказчика в итеративный процесс постоянного получения обратной связи.

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

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

Аджайл делает тоже самое, только ничего не объясняя сразу говорит — давайте все вместе. Нет никакого вовлечения. Если ты громогласно обозначил проблему, а заказчик при этом промолчал, то у тебя всегда есть возможность сказать, что я же говорил, а Ирина Ваисльевна при это молча согласилась. Хотя Ирина Васильевна может вообще вчера была принята на работу и молчала потому что вообще не понимала что тут происходит.

Манифеста — она вся такая. Там только про давайте все вместе. Дружный коллектив, нерушимая дружба, передовой колхоз.

IT>>Это работает какое-то время, пока девелоперы не просекут фишку и потом это всё работает ещё медленнее, но более прогнозируемо.
L>Ну тут не кровати надо переставлять, а далее по тексту.

Ы?

IT>>Всё это решается гораздо проще — заменой менеджера в самом начале.
L>Ну заменил ты менеджера в самом начале. Чем это поможет?

Тем, что аджайл не нужен.

Здравствуйте, landerhigh, Вы писали:

IT>>Например, митинг назначается на 9:30 утра, чтобы все выспались и все собрались. Это означает, что до этого времени никто ничем другим заниматься не будет. Далее в течении 15-20-ти минут 10 человек рассказывают друг другу ненужные и неинтересные вещи. При этом замечено, что чем меньше чел сделал, тем больше он об этом будет говорить.

L>Ну вот такое дело, что если "ненужные и неинтересные вещи", то это не скрам. А карго-культ.
L>Ну и 15-20 минут тоже уже индикатор.

Оно карго-культ по определению. Как для тебя вотерфол — это already 95% ready. Так для меня аджайл на 99% — это религия. Успешные аджайл проекты возможны при условии: ровная команда, мелкий типовой проект, нелимитированные сроки, вменяемый менеджмент. Но тогда возникает вопрос — зачем?

IT>>Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.
L>А откуда у вас следующие митинги? А работать когда?

Вообще-то это мой вопрос. На который до сих пор никто не может ответить.

L>Так это, неплохо было бы определение аджайла почитать. Вообще, ежедневный скрам для аджайла совершенно не обязателен

Я тебя умоляю. Если мы сейчас начнём читать аджайлы и не дай бог манифесту, то ржать будем до утра.

IT>>В том-то и дело, что аджайл с радостью предоставляет такие возможности. В предыдущей теме пару месяцев назад я уже говорил, что аджайл — это рай для бездельников и балаболов. А в это теме я говорил, что если у вас в команде таких нет, то при прочих условиях аджайл может кое-как работать. Только вот зачем?
L>А типа вотерфол, где можно годами прятаться за "почти готово", а в момент аврала собак повесить на васю, который api модуля не совсем по спекам реализовал, не рай для балаболов, да.

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

L>Тут не кровати надо переставлять, а, гхм, сотрудников, гхм, менять.

Вот! Золотые слова. Нахер хреновых менеджеров и аджайл не нужен.

Здравствуйте, IT, Вы писали:


IT>Оно карго-культ по определению. Как для тебя вотерфол — это already 95% ready.

Есть люди, которые из чего угодно сделают карго-культ

IT>Так для меня аджайл на 99% — это религия.

Естественно. Молния — это тоже божий промысел. Для тех, кто в школе физику прогуливал.

IT>спешные аджайл проекты возможны при условии: ровная команда, мелкий типовой проект, нелимитированные сроки, вменяемый менеджмент. Но тогда возникает вопрос — зачем?

Зачем на типовой проект какая-то команда? Для типового проекта берется типовое решение из типовой коробки.

IT>>>Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.
L>>А откуда у вас следующие митинги? А работать когда?
IT>Вообще-то это мой вопрос. На который до сих пор никто не может ответить.

Вот именно — откуда у вас "следующие митинги" и каким боком тут аджайл?

L>>Так это, неплохо было бы определение аджайла почитать. Вообще, ежедневный скрам для аджайла совершенно не обязателен
IT>Я тебя умоляю. Если мы сейчас начнём читать аджайлы и не дай бог манифесту, то ржать будем до утра.

Так может стоит попробовать? Ну чтобы чиста поржать?

IT>Вроде я уже говорил, что это проблема менеджмента.
IT>Вот! Золотые слова. Нахер хреновых менеджеров и аджайл не нужен.

Короче, разработчики совсем неуиоаые, виноваты менеджеры.

Здравствуйте, landerhigh, Вы писали:

L>Комфортность водопада заканчивается в тот самый момент, когда выясняется, что согласованный, утвержденный и принятый заказчиком фреймворк не позволяет реализовать следующую по списку фичу иначе, как стоя. В гамаке и противогазе.

L>Все это уже 100500 раз пройдено.

То что вы описали, это как раз про аджайл. Когда выясняется, что новая фича требует переписать всю архитектуру приложения, когда уже пол проекта сделано. Но в аджайле такие ситуайии только приветствуются, потому что чем дольше можно доить заказчика, тем лучше. Лучше не для заказчика.

L>>Все это уже 100500 раз пройдено.

I>То что вы описали, это как раз про аджайл. Когда выясняется, что новая фича требует переписать всю архитектуру приложения, когда уже пол проекта сделано. Но в аджайле такие ситуайии только приветствуются, потому что чем дольше можно доить заказчика, тем лучше. Лучше не для заказчика.

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

Gt_

Здравствуйте, ilvi, Вы писали:

L>>Все это уже 100500 раз пройдено.

I>То что вы описали, это как раз про аджайл. Когда выясняется, что новая фича требует переписать всю архитектуру приложения, когда уже пол проекта сделано. Но в аджайле такие ситуайии только приветствуются,

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

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

Здравствуйте, landerhigh, Вы писали:

IT>>Я считаю, что процесс нужно организовывать под конкретный проект и руководствоваться прежде всего здравым смыслом.
L>Между прочим, именно это говорят во всех скрам тренингах.

Есть супер классическая книга на эту тему «Цель: процесс непрерывного совершенствования» Голдратт, Кокс. Там был пример по оптимизации завода, когда покупка дорогого автоматизированного оборудования замедляла процесс и приводила к убыточности и срывам сроков. Там описывается подход на основе здравого смысла, есть даже что-то от разработки ПО, но в итоге оптимальный процесс становится очень похожим на оптимизацию ПО: ставится цель, выявляются узкие места, препятствующие её выполнению, они оптимизируются, осуществляется переход к следующему узкому месту. По книге оказывается не важным, как всё организуется, главное следовать цели, делать более важное и отбрасывать менее на основе показателей, характеризующих исключительно достижение цели.
Лично мне кажется, что процесс разработки ПО надо строить аналогичным способом. Главное — это Цель, а не методология. Если надо реализовать сложный алгоритм, который не факт что окажется работающим, то бросить всё, нанять умных чуваков и штурмами, а то и параллельными командами решать проблему. Писать тесты на качество/скорость алгоритма, но не на сам код, сидеть над задачей неделями и месяцами — это норм. Если не получается, но интуиция говорит, что может сработать — надо копать. Остальную предсказуемую и детерменированную часть послать нахер и делать по остаточному признаку. То есть при планировании таких проектов оперирую не столько сроками, сколько вероятностями.
Если проект предсказуемый, есть опыт разработки, то можно разворачивать скрам и делать всё кусочками, методично пожирая проблему.
Объяляя скрам универсальным средством, который такой гибкий, что подходит подо всё, ты автоматически превращаешь его в сову.

Здравствуйте, Nuzhny, Вы писали:

IT>>>Я считаю, что процесс нужно организовывать под конкретный проект и руководствоваться прежде всего здравым смыслом.
L>>Между прочим, именно это говорят во всех скрам тренингах.
N>Объяляя скрам универсальным средством, который такой гибкий, что подходит подо всё, ты автоматически превращаешь его в сову.

В первый же день на всех скрам тренингах говорится
1. Это не универсальное средство
2. Это не серебряная пуля
3. Если у вас уже есть процесс, который для вас работает — You are lucky bastrads. НИ В КОЕМ СЛУЧАЕ НЕ ТРОГАЙТЕ ЕГО.
4. Если пункт 3 в вашем случае не применим, то велкам на наш тренинг.


И кто тут ССЗБ, если методологию возводят в религию?

Здравствуйте, IT, Вы писали:


L>>Если бы он был простым, уже давно вся разработка софта сводилась бы к набросу кубиков в чем-то вроде Rational Rose. Но пока все попытки упростить процесс его лишь усложняют.

IT>Так, стопэ. Т.е. 20 лет назад всё было просто.

Скорее все же >25 лет назад.
Было еще сложнее. Ввиду отсутствия кучи инструментов, которые мы сейчас принимаем за само собой разумеющееся.
В среднем размер проектов и их масштаб был меньше.
Разработка укладывалась в подход, когда за определенную систему или ее части отвечал один человек, который был на этом проекте с самого начала, знал ее вдоль, поперек и по диагонали и мог точно сказать, что можно сделать в рамках текущей реализации, что можно реализовать относительно легко, я для чего придется все выкинуть и начать с чистого листа. И точно знал, как и что нужно менять, чтобы все не развалилось. Грубо говоря, и гуру и костыльмейстер в одном лице. Он всегда мог сказать, за какое время может добавить фичу х, и все, что манагеру нужно было — это умножить эту цифру на два и подвинуть сроки проекта таким образом, чтобы дедлайн не попадал на сезон отпусков.

Софт банально стал больше. Изменился рынок. Сроки стали поджимать чаще. Выезжать на авралах стало сложнее.
Плюс еще все меньшая пропорция кода стала оставаться под опекой специально выделенного гуру. По разным причинам.
Возникла необходимость разделять ответственность между людьми.
И вот тут уже начались грабли. Если в строительстве в общем случае добавлением второго экскаватора можно сократить время на копку котлована вдвое, то в разработке софта почему-то зачастую получалось очень даже наоборот.
Были попытки решить эту проблему формализацией. Дотошными ТЗ, на написание которых уходили годы, которые начинали противоречить реализации буквально после 10 коммитов.
Были попытки решать проблему дизайном вообще всего еще до начала разработки. Чтобы было как на стройке — вот это фундамент, вот это стены, а обои будем клеить в последнюю очередь. Результат все знают.

IT>А "Сегодня разработка софта — это очень сложный инженерный процесс". Вот я и спрашиваю — что по-твоему этот сложный инженерный процесс делает (сделало за 20 лет) сложным? Ты сам-то 20 лет назад на каком уровне простоты находился?

Переход на личности — некрасиво.

L>>Что значит "перекладывая ответственность". А кто, по твоему, вообще должен отвечать за "готовность модуля"?
IT>В аджайле? Все. Аджайл — это коллективная ответственность. Ака колхоз.

Ну говорю же, по телефону Рабинович напел.

IT>Ы?

IT>>>Всё это решается гораздо проще — заменой менеджера в самом начале.
L>>Ну заменил ты менеджера в самом начале. Чем это поможет?

IT>Тем, что аджайл не нужен.

Ну заменил ты менеджера. Проект опять в жопе. Причем тут аджайл?

AK>Так никто ж и не ожидает 8 часов работы.
AK>Когда я работал в Microsoft, в моей команде были двухнедельные спринты и время на выполнение запланированных задач рассчитывалось как 25 рабочих часов в неделю. Остальное врем съедали митинги, переписка и прочее. И результат был вполне нормальным.

за Майкрософт я не переживаю
если отвечать надо за 25 разработческих часов, то это терпимо
вот только мне кажется от конторы, специализирующейся на разработке софта, и даже бывшем лидере индустрии, можно было бы ожидать большей эффективности
может потому они больше и не лидеры


AK>А вот в другой конторе я видел жуткую жуть на проекте со скрамом. Там как раз какой-то из вчерашних "скрам мастеров" получил должность директора и весь смысл работы свели к скраму ради скрама. Было много графиков, отчётов, митингов — весь менеджмент был в восторге. Вот только проект сдох.
AK>Через год я поймал себя на мысли, что если я вообще перестану что-либо делать, то менеджмент заметит это не раньше чем через полгода. Менеджеры настолько запутались в требованиях, что за год мы этот проект три раза писали заново с нуля. Мне стало скучно, после третьего переписывания я ушёл. Коллеги потом сказали, что они ещё два раза всё переписали перед тем как проект окончательно закопали. Программисты разбежались, а менеджеры получили повышения и их всех вместе, целым подразделением, продали другой компании.

хыхы
я только что уволился из этого сразу же, на испытательном сроке
на 5й день понял как обстоит дело
на 7й донёс всю инфу высшему руководству и был послан
на 8й уволился

неужели полгода стоит на это терять?

L>3. Если у вас уже есть процесс, который для вас работает — You are lucky bastrads. НИ В КОЕМ СЛУЧАЕ НЕ ТРОГАЙТЕ

мм эти слова дают понять, что автор не спец и плывёт в теме
представляю, если бы отношение к софту было таким же
либо автор не верит в достаточную компетентность в индустрии в целом, чтобы успешно менять процессы (что похоже на правду)
но так чтобы "НИ В КОЕМ СЛУЧАЕ"
почему? я может вижу как можно улучшить конкретный процесс...

Здравствуйте, Министр Промышленности, Вы писали:

МП>Моё экспертное мнение — Scrum не подходит / (подходит с лишними издержками) для профессиональной разработки программного обеспечения.
МП>В данном случае это мнение я уже сверил с 2мя надёжными источниками — подтвердили.


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

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

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

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

Здравствуйте, Nuzhny, Вы писали:

N>Есть супер классическая книга на эту тему «Цель: процесс непрерывного совершенствования» Голдратт, Кокс. Там был пример по оптимизации завода, когда покупка дорогого автоматизированного оборудования замедляла процесс и приводила к убыточности и срывам сроков. Там описывается подход на основе здравого смысла, есть даже что-то от разработки ПО, но в итоге оптимальный процесс становится очень похожим на оптимизацию ПО: ставится цель, выявляются узкие места, препятствующие её выполнению, они оптимизируются, осуществляется переход к следующему узкому месту. По книге оказывается не важным, как всё организуется, главное следовать цели, делать более важное и отбрасывать менее на основе показателей, характеризующих исключительно достижение цели.
N>Лично мне кажется, что процесс разработки ПО надо строить аналогичным способом. Главное — это Цель, а не методология. Если надо реализовать сложный алгоритм, который не факт что окажется работающим, то бросить всё, нанять умных чуваков и штурмами, а то и параллельными командами решать проблему. Писать тесты на качество/скорость алгоритма, но не на сам код, сидеть над задачей неделями и месяцами — это норм. Если не получается, но интуиция говорит, что может сработать — надо копать. Остальную предсказуемую и детерменированную часть послать нахер и делать по остаточному признаку. То есть при планировании таких проектов оперирую не столько сроками, сколько вероятностями.
N>Если проект предсказуемый, есть опыт разработки, то можно разворачивать скрам и делать всё кусочками, методично пожирая проблему.
N>Объяляя скрам универсальным средством, который такой гибкий, что подходит подо всё, ты автоматически превращаешь его в сову.

William Edwards Deming, "Out of the Crisis", pages 180-181.

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

Fig. 10. The helix. Continue the cycle, over and over, with never-ending improvement of quality, at lower and lower cost.

Последнее -- это основное отличие инженерного подхода от agile, в котором на конце каждого витка спирали добавления feature громко раздаётся "Дай ещё денег!"

https://vit-r.dreamwidth.org/1109541.html

Здравствуйте, Министр Промышленности, Вы писали:

L>>3. Если у вас уже есть процесс, который для вас работает — You are lucky bastrads. НИ В КОЕМ СЛУЧАЕ НЕ ТРОГАЙТЕ
МП>мм эти слова дают понять, что автор не спец и плывёт в теме



МП>почему? я может вижу как можно улучшить конкретный процесс...

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

МП>>почему? я может вижу как можно улучшить конкретный процесс...

L>Улучшай, кто тебе запрещает?
L>Только вот конкретных предложений от тебя не слышно. Только "Scrum не подходит для программной разработки"

ну скрам улучшается радикальным сокращением митингов
только после этого он перестанет быть скрамом по определению

Здравствуйте, Министр Промышленности, Вы писали:

L>>Только вот конкретных предложений от тебя не слышно. Только "Scrum не подходит для программной разработки"
МП>ну скрам улучшается радикальным сокращением митингов
МП>только после этого он перестанет быть скрамом по определению

В определении скрама нет никакого дикого количества митингов.

Здравствуйте, Nuzhny, Вы писали:


N>Есть супер классическая книга на эту тему «Цель: процесс непрерывного совершенствования» Голдратт, Кокс. Там был пример по оптимизации завода, когда покупка дорогого автоматизированного оборудования замедляла процесс и приводила к убыточности и срывам сроков. Там описывается подход на основе здравого смысла, есть даже что-то от разработки ПО, но в итоге оптимальный процесс становится очень похожим на оптимизацию ПО: ставится цель, выявляются узкие места, препятствующие её выполнению, они оптимизируются, осуществляется переход к следующему узкому месту. По книге оказывается не важным, как всё организуется, главное следовать цели, делать более важное и отбрасывать менее на основе показателей, характеризующих исключительно достижение цели.

О, радует что кто-то еще работает по теории ограничения систем. А то все споры — scrum, водопад, нет бы взять лучшее из практик. Как будто в университетах не было предмета — Системология.

V>О, радует что кто-то еще работает по теории ограничения систем. А то все споры — scrum, водопад, нет бы взять лучшее из практик. Как будто в университетах не было предмета — Системология.

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

Здравствуйте, IT, Вы писали:

IT>Так, стопэ. Т.е. 20 лет назад всё было просто. А "Сегодня разработка софта — это очень сложный инженерный процесс". Вот я и спрашиваю — что по-твоему этот сложный инженерный процесс делает (сделало за 20 лет) сложным? Ты сам-то 20 лет назад на каком уровне простоты находился?

Проекты стали сложнее, конкуренции стало больше. Нужно делать макс. качественно и быстро.


IT>Аджайл делает тоже самое, только ничего не объясняя сразу говорит — давайте все вместе. Нет никакого вовлечения. Если ты громогласно обозначил проблему, а заказчик при этом промолчал, то у тебя всегда есть возможность сказать, что я же говорил, а Ирина Ваисльевна при это молча согласилась. Хотя Ирина Васильевна может вообще вчера была принята на работу и молчала потому что вообще не понимала что тут происходит.

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

Не знаю на сколько по аджайлу можно разрабатывать сложные инженерные продукты -- ОС, компиляторы, ядра бд,
поисковой движок, т.е. там на спринты не так легко задачи побить. Еще точнее, там, где для решения
задач нужна длительная работа штучных специалистов, возможно в команде. Ну скажет человек, что
сделает от 3 до 6 месяцев, ну ладно, а куда деваться?