В дебрях водопада
Nov. 8th, 2014 11:47 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rOne of the key principles in the Agile Manifesto is to have working software at the end of every sprint. Yet, only 20% of teams that call themselves ’agile’ actually do this.Из рекламы вебинара
Они не могут даже этого...
На самом деле, это враньё. Если рассматривать манифест не с точки зрения Эффективных Менеджеров™, а с точки зрения инженеров,
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-11-08 11:43 am (UTC)no subject
Date: 2014-11-08 11:45 am (UTC)no subject
Date: 2014-11-08 04:06 pm (UTC)Agile - это гениальное изобретение, позволяющее трясти заказчика на бабло вне зависимости от качества команды, процессов и полученных результатов.
Зарабатывая деньги в ИТ, глупо начинать борьбу с такой дойной коровой.
no subject
Date: 2014-11-08 03:27 pm (UTC)1. Расширяем инфраструктуру, не меняя функциональность
2. Расширяем функциональность
В обоих этапах старая функциональность должна продолжать работать.
no subject
Date: 2014-11-08 03:59 pm (UTC)Угу. Добавить к самокату ещё четыре колеса и мотор, чтобы оно стало мотоциклом класса Harley Davidson
В любом софте всегда будут ошибки. Причём, не просто программные ляпы, но и архитектурные заблуждения. Их надо исправлять, а не ставить на "почти работающем" софте новые заплатки.
no subject
Date: 2014-11-09 03:16 am (UTC)А что, у мотоциклов нынче 6 колес? Но вообще принцип именно такой. Менять постепенно, а не переписывать с нуля.
> В любом софте всегда будут ошибки. Причём, не просто программные ляпы, но и архитектурные заблуждения. Их надо исправлять, а не ставить на "почти работающем" софте новые заплатки.
"Архитектурные заблуждения" - это не заблуждения, а нормальное явление. По мере развития проекта накапливается его понимание и соответственно расширяется архитектура. То самое про что я и расскзал. Сначала меняем внутреннюю архитектуру, не меняя функциональность, потом начинаем расширять функциональность.
А вот боязнь поменять архитектуру и жажда все переписывать сначала - это признак отсутствия мозга. И отсутствия нормальных тестов.
no subject
Date: 2014-11-09 09:03 am (UTC)Когда тут перестраивают старые дома, оставляют только фасад, а всё за ним разрушают и делают заново.
no subject
Date: 2014-11-10 05:26 am (UTC)И да, именно так, оставляют видимое пользователем, а остальное меняют. Потому что для видимого пользователем есть тесты. Которые позволяют удостовериться, что измененная внутренняя структура ничего не испортила.
no subject
Date: 2014-11-10 06:15 am (UTC)no subject
Date: 2014-11-12 03:10 am (UTC)no subject
Date: 2014-11-12 07:22 am (UTC)Но большинство программистов не умеет считать деньги.
no subject
Date: 2014-11-08 03:31 pm (UTC)no subject
Date: 2014-11-08 03:55 pm (UTC)Угу. Особенно, если это какой-нибудь банальный экспорт в голимый Эксел, без которого клиент софт в своих процессах применять просто не может.
no subject
Date: 2014-11-08 10:55 pm (UTC)Не то, чтобы я этот набор карго-культов защищал, Б-женька упаси. Но ИМХО Agile как раз сейчас (по ощущениям, последние года два-три, может, и поболее) довели до необходимого и достаточного набора шаманских слов и ритуалов - такого чтобы перед ним благоговейно затыкались "менеджеры среднего звена". "У нас теперь есть Scrum Master! Дипломированный, с кучей аттестатов и сертификатов! Ужо он нма теперь все настроит и организует!"
При этом вменяемые инженеры (при наличии таковых в команде) прикрыты от дурной инициативности начальства и получают возможность заниматься делом. Да, приходится платить временем (убивая его на дурь вроде Spring Retrospective Meeting или Spring Planning II), но ведь это - вполне умеренная плата за то, что каждое чмо в вертикали теперь не дергает по три раза на дню "ну, как там задача 12.1/4 на Critical Path? Освоена на 28 процентов? Хорошо, а когда будет на 31?". А если вменяемых инженеров в команде нет - так ей ни Agile, ни черт в ступе не помогут и не помешают.
Зато как замечательно становится: как только манагер проникается идеей CI, он готов молиться на индикатор Build Passed / Failed в Дженкинсе. Буквально за кофеем бегает, "ты только не отвлекайся, дорогой Developer, чини билд изо всех сил!"
no subject
Date: 2014-11-08 11:30 pm (UTC)Это, именно, проблемы того, что продаётся под этим лейблом.
но ведь это - вполне умеренная плата за то, что каждое чмо в вертикали теперь не дергает по три раза на дню "ну, как там задача 12.1/4 на Critical Path? Освоена на 28 процентов? Хорошо, а когда будет на 31?".
Нифига себе! И где такая дыра, где кнопкатыкателей настолько за людей не считают и менеджерам настолько нефиг делать?
no subject
Date: 2014-11-09 12:55 pm (UTC)> Это, именно, проблемы того, что продаётся под этим лейблом.
"Позвольте с Вами не согласиться"(С). Это проблема того, кто не умеет готовить именно эту кошку. Расстановка приоритетов - одна из немногих задач, решаемых руководством (ну, назовите этих людей Project Owner'ами для пущей Аджайлости или Architect'ами для ISO-шности, сути это не меняет).
Или Agile у нас разных систем, такое тоже возможно.
> Нифига себе! И где такая дыра, где кнопкатыкателей настолько за людей не считают и менеджерам настолько нефиг делать?
В абсолютно любой конторе на абсолютно любом проекте где появилось хоть немного условно-свободных денег и начальство мгновенно забронзовело для того, чтобы самолично заниматься разработкой day-to-day. Обычно при сем нанимают какого-нибудь шустрого пацана на должность вроде Project Manager, "и все заверте...". Ему ж надо красивые задоприкрывательные графички/диаграммки рисовать, вот и старается человек. Он обычно не злобен, просто дурноват, нагловат и дворняжьей властью наделен.
А при правильном употреблении от него даже польза бывает - отчетики те же нарисовать, Minutes of Meeting составить, комнату для совещаний забронировать / подготовить. Agile такому вполне способствует.
no subject
Date: 2014-11-09 03:49 pm (UTC)Это тоже иллюзия. Приоритеты нельзя "расставить". Система всегда оптимизируется по тем параметрам, которые измеряют.
А основная проблема агилят в отсутствии того, что обычно называют Requirements Engineering.
no subject
Date: 2014-11-10 09:22 am (UTC)Ааа, так у вас кнопкодавы считают, что их дело - кнопкодавствовать, а что и для чего - "пусть у манагеров голова болит"? Ну, в таком проекте хоть Аджайл, хоть RUP, хоть Водопад - любой набор заклинаний обречен, тут не спорю.
> А основная проблема агилят в отсутствии того, что обычно называют Requirements Engineering.
"Ну почему же, дорогая?" (С). Это совершенно ортогональные вещи: где есть - там есть, где нету - там нету. В последние несколько лет я видел с полдесятка команд и проектов с разной степенью Agile'нутости, нигде этот деликатный вопрос на самотек не оставляли. Вообще успех _любого_ проекта зависит (но не определяется) вменяемостью и грамотностью руководства, а уж какой цвет обложки будет у документа с требованиями или какие буковки будут на той обложке - дело вторичное.
Вообще у меня такое впечатление что мы о разных вещах говорим. У Вас такого не возникло?
no subject
Date: 2014-11-10 09:28 am (UTC)Потому что так написано в программных документах, этим объясняются все заскоки и вся система построена именно на этом.
no subject
Date: 2014-11-09 02:34 pm (UTC)считают
Вы из нее уехали.
no subject
Date: 2014-11-09 03:20 am (UTC)Я, кстати, карго-культ не защищаю. Все эти скрамы - говно полнейшее. Что не отменяет настоящего самолета, по мотивам которого они строят соломенный.
no subject
Date: 2014-11-09 08:59 am (UTC)Вот и основная ошибка кнопкодавов: Пользователям нафиг не нужны "фичи". Им нужно решение их задач.
Что не отменяет настоящего самолета, по мотивам которого они строят соломенный.
А был ли мальчик?
no subject
Date: 2014-11-10 05:29 am (UTC)no subject
Date: 2014-11-10 06:16 am (UTC)no subject
Date: 2014-11-10 09:23 am (UTC)no subject
Date: 2014-11-10 09:27 am (UTC)no subject
Date: 2014-11-10 09:38 am (UTC)Или Вы утверждаете, что если бы платили не "за спринты", а "за успешное завершение Стадии 4.1/3а на Этапе Эскизного Проектирования согласно Watefall по ГОСТ 1234234.34", а не за работающий софт, то вероятность создания работающего софта была бы выше? Сомневаюсь. А вот манаджерских заскоков, подозреваю, было бы на порядок поболее (впрочем, тут не настаиваю - эмпирика штука опасная).
no subject
Date: 2014-11-10 10:56 am (UTC)Потому что такова реальность Agile
В теории оно может быть и хорошо, а практика показывает грубые факты.
Сомневаюсь
Я видел как реально работают разные системы в реальных условиях. И я знаю, почему они так работают. А теоретических сомнений можно настроить сколько угодно. Особенно, если нет результатов измерений.
Замените AGile на что угодно - результат будет ровно тем же.
Нет, конечно.
no subject
Date: 2014-11-10 08:49 pm (UTC)"Коллега, мы же с Вами профессионалы. Давайте просто снимем штаны и сравним." (С) - бородатый уже анекдот. Я так понимаю, достоверной статистики у Вас тоже нет, иначе Вы бы меня уже ею завалили (у меня нет, я от входа предупреждал).
Дабы не раздражать, повторюсь: я утверждаю, что большинство проектов в современном ИТ обречены с момента их начала. Им не помогут ни Agile, ни RUP с MSF. На водопаде они, скорее всего, рухнут быстрее, но я не уверен что это было бы хорошо. Вменяемый же проект (т.е. организованный и возглавляемый адекватными людьми, которые _думают_ и сопоставляют прежде чем с радостным визгом тащить в проект свежевычитанные откровения очередного гуру), при наличии грамотных инжеренов с адекватным количеством кнопкодавов взлетит при любой методологии (тут, конечно, существуют граничные условния - разрабатывать САУ для марсианской экспедиции любой итеративной методологией все-таки не станут, но тут см. пункт про адекватный менеджмент). Точно так же НЕ взлетит проект, в который набрали ТОЛЬКО студентов и поставили над ними свежего выпускника курсов "Супер-пупер методология НАСА по разработке софта для лунного модуля для чайников за 24 часа с перерывом на обед и двумя перекурами". Надеюсь, по этому вопросу мы все-таки согласны друг с другом?
Теперь о грустном. Я давно почитываю Ваш журнал, и Ваша одержимость идеей "Аджайл - говно и Requirement Management в нем нет" стала неприятным сюрпризом - настолько, что я аж влез в разговор. Вторая посылка как минимум формально неверна - ну, хотя бы вот по этой ссылке гляньте, что ли: http://agilebench.com/blog/the-product-backlog-for-agile-teams. Но это - мелочи, главный вопрос - зачем столько желчи на этих, в общем-то безобидных, тварей? Аджайл ведь во многом уже стал _очередной_ религией для менеджеров-недоучек и их начальников, они только что не молятся на нодопонятые и с-пятого-на-десятое-недочитанные идеи из умных книг основателей. Вы бы слышали их "производственные совещания" - ни дать не взять теологические диспуты: "В книге с синей обложкой сказано, что Sprint Planning Meeting дожен проводиться не позднее второго дня от начала предыдущего спринта! - Да, но вот в статье на сайте Джона Пальцато сказано, что они использовали этот ресурс для Technical-Backlog-чем-то-обо-что-то-Retrospective! - А вот на курсах нам рассказывали, что ... " - это ж обхохотаться. Так чего ж Вы на убогих сердитесь? Они ж Вам в руки дают такое шикарное средство управления (или, как минимум, сведения ущерба от их дури к приемлемому уровню) - пользоваться надо, а не брюзжать.
Проводя аналогию - Вас вот Библия или Тора с Кораном не раздражают? А меж тем люди, буквально следующие этим писаниям, настолько предсказуемы и удобны в использовании, что только умиляешься. Так почему адепты одной книги Вас цепляют, а другой - нет?
no subject
Date: 2014-11-10 12:07 pm (UTC)А они там не пишут что такое работающий софт (working software)?
Который можно ставить клиенту (клиентам, если их тысячи)? Новая версия, которую можно ставить в production неглядя вместо предыдущей?
Который проходит текущий набор эталонных тестов?
Которая просто собралась в инсталяционный пакет и ее можно тестировать?
Имхо, если каждые четыре недели есть версия, которая прошла тестирования и ее не стыдно показать кому-нибудь за пределами RnD, это уже не так уж плохо.
(Знаю людей для которых и ежедневный билд является откровением)
no subject
Date: 2014-11-10 02:50 pm (UTC)Исходя из практического опыта это означает "удалось скомпилировать без ошибок".