Секреты менеджмента

[vit_r]

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

Comments

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

Видел я, во что превращается продукт после двух-трёх лет этого действа. Но да, слоники бегают очень эффективно.

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

[cucumber405.livejournal.com]

да, и еще - скрам предполагает ТДД для сокращения издержек и ПЕРМАНЕНТНЫЙ рефакторинг.
я тоже сначала думал, что очень неплохо заложить максимум фичь, что потом не переделывать. нифига, половина будет мертвым капиталом, а усложненная кнострукция будем налогом на архитектуру.
при скруме не нужно боятся улучшать, другой вопрос, что начинается борьба с ПМами, для которых рефакторинг - слово ругательное.

[vit-r.livejournal.com]

начинается борьба с ПМами, для которых рефакторинг - слово ругательное.

При бесконечном притоке денег и отсутствии клиентов работает всё.

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

[cucumber405.livejournal.com]

какие, например?
единственное, за что нужно отрывать яйцы сразу, level bridge. Потому что это уже как раз трудно править.
во всех остальных случаях, если изоляция по слоям нормальная, все получится.
примеры приведи.

[vit-r.livejournal.com]

Ага. Пароли, явки документы и ключи от квартиры, где деньги лежат. Какие могут быть в agile примеры, если они даже метрики нормальные делать не умеют. "Бежим хорошо, а куда - пофиг". Вся правда только в личных беседах и в тайне от менеджмента, и, тем более, клиентов.

Вот типичная история (http://www.manage-agile.de/files/manageagile/Vortraege/Britz/Tag1/Ursual%20Meseberg%20-%20microTOOL%20-%2010%20Jahre%20agil.pdf)., правда с анализом и выводами я не согласен, но симптомы обычные. Списаны они, правда, не всегда на то, на что нужно.

[theaspect.livejournal.com]

Что такое level bridge?

[cucumber405.livejournal.com]

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

[theaspect.livejournal.com]

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

[cucumber405.livejournal.com]

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