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

[vit_r]

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

Comments

[kouzdra.livejournal.com]

Надо заметить, что построить агильными методами водовод длиной в 20-30 км с средним уклоном 30-50 сантиметров на километр никак невозможно

PS: Что до труб - там где дешевле римляне их и прокладывали - но у них это была дороже акведуков

[vit-r.livejournal.com]

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

[vit-r.livejournal.com]

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

[kouzdra.livejournal.com]

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

там чистая экономика - так дешевле выходило.

[vit-r.livejournal.com]

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

Впрочем, как упомянуто ниже, про экономику вопрос не в тогда, а в сейчас.

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

[cucumber405.livejournal.com]

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

[cucumber405.livejournal.com]

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

[cucumber405.livejournal.com]

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

[kouzdra.livejournal.com]

Да умели они эти-то вещи считать - ну понятно, что большая часть цифирек эмпиричемская - просто в том же 50-м сифоне - там сечение у 8-ки емнимп труб 5 см, и толщина стенок - 5 см (потому что 5 атм для свинца очень приличное давление), да еще поправки на гидроудар на переломах труб.

Ну и как такую туеву хучу свинца волочь?

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

[vit-r.livejournal.com]

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

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

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

[vit-r.livejournal.com]

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

Что за бред. Если требования меняются раз в неделю, это не ТЗ, а истерика. Да и умеют все водопады доворачивать. Не надо путать модель и процесс, работающий по этой модели.

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

[vit-r.livejournal.com]

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

[cucumber405.livejournal.com]

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

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

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

Прототипирование - это не "спасение", а совершенно стандартная техника во время разработки ТЗ.

[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]

Термин Архипенкова, он из ракетной индустрии пришел http://www.arkhipenkov.ru/

[theaspect.livejournal.com]

Что такое level bridge?

Как бы с тобой потереть за плÐ

[theaspect.livejournal.com]

Никак не удается планировать больше чем на сотню часов, да и те с учетом тестирования и допила выливаются в 200. Причем на само планирование уходит 2-3 дня. Как качество повышать?

Re: Как бы с тобой потереть за пÐ

[vit-r.livejournal.com]

Обычно планируют на основе собранных в предыдущих проектах метрик. (Как правило, не правильно). Для новых продуктов и областей деятельности вообще теорий пригодных видел.

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

[vit-r.livejournal.com]

Пять фирм. Причём ни одной, где "старые методы" были бы применены правильно. Плюс последнее время чистое руководство.

Это не серьёзно.

Re: Как бы с тобой потереть за пÐ

[theaspect.livejournal.com]

Ты постоянно гнобишь аджайлистов, но проблема ИМХО глубже: по любой методолгии может так получаться что до буквы следуем правилам, проекты проектируем, планы планируем, майлстоуны выполняем в срок, куча писанины, но на выходе почему-то шлак.

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

Другая проблема - актуальность этого самого плана. Составляют стостраничный документ или писульку на два листика. Через какое-то время всё это теряет актуальность и идем куда идем. Некогда обновлять. А на выходе сравнивают с исходным планом и сильно удивляются.

Мне черная формула метрик очень понравилась http://cartmendum.livejournal.com/143761.html

[cucumber405.livejournal.com]

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