Опережающее смягчение рисков.

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

О работе с требованиями и общности ИТ с остальным миром.

Перекрёсток, нерегулируемый. Его(перекрёсток) переделывают в регулируемый, Канавы, знаки, светофоры... . Пешеходный переход на этом перекрёстке и пятеро(5-ро) мужиков машут руками, голосят, споря где/как/что тут  копать/штробить/цементировать. И тут один из них выдаёт робкую фразу “А как у нас по проекту должно быть?“. 
Оказывается не только лишь в ИТ так, не только лишь... .

Надумалось по поводу нагрузочных тестов и когда начинать всё то.

Надумалась тут банальщина - если "тормоза" системы заметны невооружённым взглядом, то о нагрузочных тестах задумываться уже поздно и ещё рано.

О наступании на горло собственной песни.

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

О целях собеседований.

Вот скажите, зачем собеседовать людей на ту или иную должность? Каковы конечные цели, каковы промежуточные?  И речь не о декларируемых целях, а о фактических. Частенько приходится сталкиваться с тем, что декларируемая цель это нечто в духе "нанять высококлассного инженера который будет максимально полезен работая в данной должности". А вот фактическая цель конкретных исполнителей это "показать какой я весь из себя крутой, показать какой кандидат "никакой",  смешать его с пылью и не принять на работу.". Грубо? Задевает чувства? Зато правда. В итоге - вакансия открыта, кандидат ушёл строчить гневные заметки в уютных бложиках и соц.сетях и лишь собеседовавший ходит выпятив грудь - герой, как же, не допустил, не пропустил в святая святых очередное "ничтожество". Как по-мне, цель собеседования - понять подходит человек или нет, где и в чём может быть полезен его опыт и знания, насколько он обучаем и открыт к обучение и вообще - "я хочу работать с ним или нет?". Показывать свою личную крутость следует на проекте, в деле.

Заказчика надо держать в курсе...

 ... . И в ежовых рукавицах :).

"Зоопарковый" Скрам...

...один из видов местной "живности", закономерная мутация в условиях ослабленного контроля и наличия творческих способностей.
Основные особенности: РП нет (как теоритически и не должно быть), где-то там есть висящий вниз головой псевдо-владелец-продукта, команда самоорганизующаяся до жути, чуть ли не читающая мысли друг друга и с минимальной "звездатостью" каждого в ней. Контроль есть, но умышлено ослаблен со стороны всех, аудиторы не бегают с дикими криками "А что это у вас Скрам не по CMMI-N?" и "Какие метрики и где?". И вообще - практически всюду зеленоватый свет, правда без Mac Air каждому. Есть ощущение, что ты в зоопарке по ту сторону ограждения, но еду приносят по расписанию, вольер весь твой, а от тебя требуется производить впечатление.

В довесок ещё кучка тонкостей и оговорок, но это уже детали.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О бардаке.

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

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

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

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

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

О рвачестве.

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

О вечности.

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

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

О нежности.

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