Материалы по стандарту CMMI и около него Основной документ стандарт SWCMMI на русском swcmmi.doc Неформальное введение, управление программистами pravilaashmanova1.doc Неформальное введение, правильные и неправильные проекты pravilaashmanova2…….

В первом комментарии сказано достаточно точно – есть “за”, есть “против”. Единственно верного решения не существует – Си для одного, С++ для другого, Java для третьего, Питон для десятого, bash для двадцатого, “смешать, но не взбалтывать”. Не отменяет необходимости вменяемых программистов, чутких менеджеров и щедрых заказчиков.

Ведь не зря же придумали XP, Scrum, TDD, continues integration и так далее.
Это как раз для того чтобы сохранить контроль над большими проектами.

Краткое содержание: Java своей консервативностью создает бОльшую часть из той горы кода, с которой так помогают управляться ее фичи. То же соображение применимо к любому языку, обменивающему возможности на безопасность.

Вредные решения:
Языки со статической типизацией, проверяемыми исключениями и прочей защитой от дурака

Смешались в кучу кони, люди…
Считать язык со статической типизацией однозначно вредным решением можно только предварительно крепко приняв на грудь. Ибо – очень много факторов за и против, если очень сильно огрубить – то языки со статической типизацией в среднем лучше для больших проектов, с динамической – для мелких.

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

Вы можете заменить в urls метод patterns() или include() на ваш собственный, который будет навешивать нужный (или произвольно указанный) декоратор.

В результате:
– дублирование кода ещё меньше.
– те же самые гарантии безопасности
– в отличие от вашего, подход расширяемый: вы можете описать ещё больше разных нужных декораторов (например, login_with_role, require_permission, vary или nocache).

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

1. Подмена понятий. Заголовок гласит “MSP нельзя использовать для управления проектами”. Однако, статья относится только к проектам по разработке software. Некрасиво. Вы забыли, что существует целая куча других проектов.
2. Фраза “Лично не проверял, но могу предположить…” заставляет меня улыбнуться еще раз. Не проверяли – почему так уверенно говорите?
3. Вы правы, ID постоянно меняются. Конечно, Microsoft’у следовало назвать это поле “Номер строки”, как в Excel. Но весь мир давно пользуется WBS-кодами для идентификации задач. Это удобней, наглядней и помогает разбираться в большом объеме схожих задач. Вы просто не дочитали книжку по MS Project.
4. Жизненный цикл задач должен быть подробным, чтобы обеспечить управляемость. Понятие “громоздкость” известна только вам, как руководителю проекта. Участники проекта расписание в целом могут и не увидеть до конца проекта. “Громоздкое расписание” позволяет точно знать, в чьих руках сейчас находится “мячик” и когда это все закончится.
5. Взаимозаменяемость ресурсов. Просто хохма. Если вы как менеджер доверяете софту замену людей на задачах, то вы – просто технический администратор проекта. Прежде чем заменить одного сотрудника на другого, вы обязаны выполнить весьма трудоемкую процедуру по оценке трудозатрат “новых сотрудников”, добиться согласования их руководителя, убедиться, что расписание останется в рамках и т.п. И только потом нажать Alt+F10 и заменить сотрудников.
6. Процент выполнения нужен только тогда, когда вы не утруждаете себя “громоздким расписанием” (см.4). Тогда вы заранее должны определить, что означает 50-75-100% для конкретного проекта. Мой совет – детализируйте задачи до 1 недели и отмечайте выполнение по принципу 0-100%.
7. Длительность проекта – является следствием длительностей задач и сетевого графика. Если у вас по-другому, значит вы не управляете проектом. Попробуйте прийти к инвестору за деньгами и на вопрос “Когда вы рассчитываете закончить проект?” ответить “Не знаю”.
8. Совместная работа в Microsoft Project требует отдельного разговора. Все можно сделать, если захотеть. Скажу только, что никто не снимал с вас необходимости организовывать взаимодействие людей лично. Забудьте про программу. Займитесь людьми.
9. Серверная версия. То, что у вас не получилось поставить сервер не говорит, что он плохо работает.