Об адаптации.

Местами "гибкость" методологии понимают достаточно однобоко, "адаптивно под себя", ведь главное это ударить пяткой в грудь и громко крикнуть "Мы продвинутые, у нас Скрам, ХР (нужное вставить) давайте платите нам за это !".

О выдержке.

ОйК должен обладать подготовкой и выдержкой хорошего психолога.
А иногда и психиатора.

О любви.

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

Об изменяемом треугольнике.

Да будут подвергнуты остракизму отвергающие здравый смысл в виде:

И да будут просвещены сомневающиеся:

Треугольник компромисов (Trade-off triangle).

MSF – философия создания IT-решений или голые амбиции лидера

З.Ы.
При всей монструозности Майкрософта, тамошние ребята дело знают. Хотя их треугольник что-то таки сильно напоминает ;).

Сказка о скраме и прочих.

Давным-давно, местами недавно, а кое-где и поныне жили-были, существовали белками, воду пили, углеводы потребляли, кислород вдыхали хмуро-мудрые дядьки-математики или что-то вроде того, любящие кроме всего прочего чего-нибудь и как-нибудь поиспытывать, т.е. первобытные ОйКи. Вырастали они в тяжкие времена становления отрасли и мутации сеток в затворы-базы. Росли они вместе с написанием монструозного количества программного кода, призванного рассчитывать и управлять подводными лодками, космическими аппаратами и всяко разными ракетами специального, как говорится, назначения. Росли, росли да и выросли в суровых борцов за качество, ибо кому нужна подводная лодка грациозно стоящая на киле посреди чернозёмной али ещё какой степи? Дядьки придумывали (и как ни странно использовали) мудрёные технологии оценки того за что боролись, головоломные подходы к анализу кода, хитрые и ёмкие термины, писали программы для разборки по частям и испытания других программ, ещё и книжки строчили, многостраничные концентраты математических формул, прикидок и всего остального добра, позволявшего с заданной вероятностью сказать «Поехали» и при этом ещё и вернуться. Всё это есть и сейчас, где-то там, в два-в-шестнадцатой царстве.

Транзисторы мельчали и заказчики пошли уже в совсем других костюмах. Деловарам надо было, естественно, побыстрее, качеством попроще чем космический зонд, но так чтобы и работало 24/7. Начались отступления от классического «водопада» и изобретение всяческий «быстрых» способов сваять и испытать, таким образом наметилась тенденция.

А затем пришла эра персональных вычислителей, цифровая тактируемая «мысль» хлынула в массы и появились мальчики-отличники с деловой искоркой на пальцах, которые жаждали обеспечить те самые массы не только «железом», но и программным кормом для оного. И лень им было дядькины талмуды читать, долго и скучно, а главное неясно насколько денежно, ибо трудно продать вероятность и цикломатическую сложность человеку, увлечённому в основном бананами. Стали появляться очередные «упрощения» и «ускорения», достигшие локального пика, когда писать код начали студенты всех возрастов, которым и сессию сдавать и в кино сходить и на личном фронте повоевать. Тонны кода начали вываливаться перед самыми последними рубежами по принципу «ой, завтра ж сдавать», заказчики в свою очередь хотели мгновенного счастья (ЛСД не предлагать), обстановка накалялась. Постепенно у руля проектов начали стоять слегка оперившиеся пять-ещё-минут-назад студенты-писальщики кода, психологии и методов своей работы конечно не изменившие, верные тезису «докурю и пойдём сдавать», которым натурально лень было читать (и применять) Канера и иже с ним, тем более что они «рулевые», они и так знают, что всё хорошо, а качество это что-то вроде неразбавленного водой пива. Зачем что-то испытывать, если в команде все как один одногруппники РП, все отличные ребята и плохих вещей в репозиторий не вливают? Правильно, незачем. Один лишь нюанс, надо бы такое положение вещей «продать» заказчику, официально закрепить.

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

На практике в рамках «бардака» из тезиса «Сделать качественный продукт и в срок» единственное прилагательное исчезает.

К чему вязать? .

Айдишники - лучшие друзья робо-ОйКа.

Одна из характиристик "процесса".

Метрики, метрики, качество процессов, количественные показатели ... традиционная "всенощная" перед выкаткой очередной версии чем не характеристика того самого процесса ;)?

О бардаке.

SCRUM советует иметь полнофункциональные команды. Это неспроста.

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

= "У семи нянек дитё без глазу".

Об оптимальности нагрева.

ОйКу-адепту "терморектального криптоанализа" (да и не только таковому) следует помнить, что максимум ещё не есть оптимум, подбор температуры жала должен быть индивидуальным.

Сверхсверхсверхбыстрое т...

Читая "Быстрое тестирование" подумалось, что если это у них "быстрое", то у нас тогда на большинстве проектов - "гиперскоростное".

О рвачестве.

Печально, что поддавшись соблазну быстрых денег за счёт быстрой/скоростной/экстремальной разработки конторы начинают забывать о качестве как таковом, опьянение скоростью влечёт порочную идеологию в духе "мы опытные и ещё раз опытные, выше нас только горы, круче нас только яйца, пишем с первого раза и с кучей особенностей, которые и не ошибки и не просчёты вовсе".
Рвачество, ИТ-шное рвачество.

О вечности.

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

Грустно, но ОйКи в ИТ всё чаще напоминают Техников (А.Азимов, "Конец Вечности").
Нас не любят-с, ну и шут с ними, главное чтоб работали эффективно ;).

О нежности.

рПО-ки - в среднем течении существа нежные и трепетные. Пока не пнёшь, не "напедалят".