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

[vit_r]

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

Comments

[kouzdra.livejournal.com]

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

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

[vit-r.livejournal.com]

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

[kouzdra.livejournal.com]

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

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

[vit-r.livejournal.com]

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

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

[kouzdra.livejournal.com]

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

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

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

[vit-r.livejournal.com]

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

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

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

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

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

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

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

[theaspect.livejournal.com]

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

[vit-r.livejournal.com]

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

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

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

[cucumber405.livejournal.com]

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

[vit-r.livejournal.com]

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

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

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

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

[theaspect.livejournal.com]

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

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

[vit-r.livejournal.com]

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

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

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

[theaspect.livejournal.com]

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

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

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

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

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

[vit-r.livejournal.com]

поэтому давайте как-то адаптироваться к этим условиям.

А теперь следим за руками.

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

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

Впрочем, редко кто читал Кокбурна. А из тех, кто читал, мало кто понял про три уровня.

мы не можем нормально спроектировать, но код писать надо

Чего тут думать? Трясти надо.

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

делаем шажок, сверяемся с картой

Карты-то НЕТ. Делаем шажок - ощупываем почву руками. Если в дерьмо не вляпались, пытаемся идти дальше. Если вляпались, берём немного вбок.

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

[cucumber405.livejournal.com]

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

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

[cucumber405.livejournal.com]

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

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

[vit-r.livejournal.com]

При чём тут менеджеры? База метрик - это не личные наблюдения, а результаты измерений.