пятница, 4 октября 2013 г.

[work] Подумалось про формальные процессы

По ходу спора в ЖЖ ув.тов.grundik всплыли упоминания о PSP/TSP. О PSP читал когда-то давным-давно. Пришлось восстановить в памяти. По ходу дела придумалась интересная аналогия.

Внедрение формальных процессов разработки ПО (например, RUP, PSP/TSP или даже строго соблюдаемый SCRUM) -- это как режим дня и расписание тренировок у спортсменов. Да, подготовленный спортсмен, которого заставляют дважды в день посещать спортзал, уделает новичка. Но когда на старт выходят спортсмены одинакового уровня, то кому достанется победа? В какой степени она будет обусловлена расписанием тренировок или строгостью распорядка дня? И каково будет влияние других факторов?

Я это к тому, что порядок в разработке должен быть. Нельзя начинать разработку не имея четких целей. Нельзя передавать софт в эксплуатацию без тестирования и документирования. Но точно так же нельзя ставить во главу угла формальные процедуры, без учета конкретных сложившихся в компании условий, традиций, культуры и, в первую очередь, персоналий. Если разработкой занимаются вменяемые люди, которые могут могут учиться на своих и чужих ошибках, которые смотрят по сторонам и имеют желание и возможность довести все до ума, то нужный для компании процесс разработки обязательно выстроится. Да и таких людей, смело могу сказать, не так уж и мало. По крайней мере в Интервэйле таковых еще несколько лет назад было много.


Еще несколько впечатлений по ходу поиска информации о PSP. Во-первых, такое впечатление, что информацию об этой методологии распространяют за деньги. Что уже подозрительно :)

Во-вторых, имеющиеся публичные материалы больше наводят на мысль о религии. Ну или о секте. Или о продавцах чудо-таблеток. Сплошные хвалебные речи :) Мол, если следовать PSP, то вы повысите точность своих предсказаний, существенно уменьшите количество дефектов в ПО и пр., и пр. Хотя из заявляемых пунктов этой методики особо не видно, за счет чего это будет происходить. И тут следует возвращение к "во-первых": для познания дзена овладения этим процессом нужно потратить много сил, денег и времени.

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

В общем, пришел к мнению, что вещи вроде PSP нужны для тех, кто в прямом смысле сидит на попе ровно. Ничему не учится сам. Ни к чему не стремится. Анализировать результаты своей работы не хочет. Критический разбор своего кода не делает и т.д. В советские времена в больших конторах таких программистов было достаточно. Но сильно сомневаюсь, что кто-то из них на просторах СНГ пережил 90-е годы в профессии. И что к таким можно отнести тех, кто пришел в программирование еще лет 7-8 назад. Хотя, возможно, в больших столичных конторах таких и сейчас можно будет отыскать. Но сама-то методология PSP появилась в Штатах. Там, подозреваю, ситуация несколько другая. И, возможно, для Штатов PSP намного актуальнее, чем для нашего, практически полностью офшорного рынка труда.

Отправить комментарий