> Если вы будете запускать её самостоятельно, имейте в виду: она довольно чувствительна к помехам, вносимым в графики фоновой нагрузкой. Чтобы получить более достоверные результаты, закройте все остальные программы на время замера.
Кроме прикладных программ, в системе осанутся фоновые службы, работа которых также вероятно исказит статистику. Вы не оценивали степень данных искажений, можно ли их считать существенными?
Полагаю, что «взрыв» все-таки более сильный термин, чем «быстрое развитие». Поясню почему: технология может развиваться, даже если ее никто еще массово не использует, однако мы не говорим в этом случае о взрыве. А вот когда начинаются массовые внедрения — это взрыв.
> «Наконец-то можно вздохнуть с облегчением! CSS3 и HTML5 были на горизонте веб-дизайна последние пару лет, но сейчас, в 2011, мы видим взрыв этих технологий.»
В оригинале стоит explosion — Вы уверен, что Автор имела в виду именно «взрыв», а не «быстрое развитие»? Меня лично смущает слово «взрыв», но я, к сожалению, не знаю статистики использования HTML5 в актуальных проектах.
Странная статья. С одной стороны в ней есть утверждения вроде «Сейчас ваш дизайн должен справлятся с нетбуками, смартфонами и таблетками. Вы готовы?» — они тривиальны, с другой стороны утверждения вроде «Наконец-то можно вздохнуть с облегчением! CSS3 и HTML5 были на горизонте веб-дизайна последние пару лет, но сейчас, в 2011, мы видим взрыв этих технологий.» — выглядят голословно. Сколько сайтов уже написано с использованием CSS3 и HTML5? Буду благодарен, если кто-нибудь приведет цифру с авторитетной ссылкой. Остальное в статье выглядит как ненавязчивое стремление убедить читателя, что ему не нужна Flash.
Не соглашусь. Стандарты (адекватные! — NB.) помогают избегать типичных ошибок при выключенном мозге. Жесткое расписание помогает вовремя увидеть надвигающиеся проблемы и предотвратить их.
Допустим, трудозатраты на решение некоторой задачи были оценены менеджером проекта и экспертами в 40 часов, а фонд оплаты труда, допустим, в 40000 рублей. Далее программисты находят способ выполнить ее за 10 часов. Менеджер проекта идет к руководству и говорит: «Босс, мои парни сделали этот крутой проект в 4 раза быстрее!»
Далее возможны два типичных варианта:
А) Босс говорит: «Вау, да это круто! Теперь они будут делать то, что раньше мне стоило 40 тысяч за 10 тысяч!»
— после этого timesheet превращается в timeshit и оценки проектов приобретают тенденцию к удлинению даже не на 230%, а на 450%.
Б) Босс говорит: «Вау, да это круто! Эти парни доказали, что они асы, теперь они будут делать более сложные, интересные задачи, оформляй им повышение категории!»
-здесь timesheet будет работать и приносить пользу всем, начиная от джуниоров и заканчивая учредителями компании.
А вот это наверное кривой бизнес-процесс, когда люди, делающие одинаковой сложности задачи за разное время (что говорит о разной квалификации) пишут в таймшиты одинаковое время.
Признаюсь, я не знаток agile и scrum — увы, для меня это пока что загадочные иностранные слова.
Но опыт подсказывает, что почасовой учет рабочего времени в более-менее крупном проекте надо вести в любом случае, какую бы методологию мы не использовали.
Но! — чего делать нельзя ни в коем случае (если только мы работаем, а не занимаемся выживанием на рынке) — это переводить проектную команду на почасовую форму оплаты труда; смета трудозатрат со стоимостью часа — это документ для обоснования стоимости проектных работ перед Заказчиком, а не для расчета зарплаты персонала.
Отчеты о выполненной работе/затраченном времени не только полезны, но и необходимы. Именно они позволяют составить статистическую базу для план-фактного анализа корректировки экспертных оценок продолжительности проектных работ.
И заполняться они должны не на бумажках или в таблицах Excel, а в системе управления проектами.
Копировать — незачем, могли бы ссылку дать для незнающих. А то я, например, прочитав осбуждаемый топик, первым делом подумал, что Libre Office — это нечто выросшее из Gnumeric и Abiword.
Парни из Canonical ведь уже выпилили однажды GIMP из стандартной поставки, поставив взамен его какую-то марахайку — прецедент был положен.
Изображенная на иллюстрации карта асимметрична. Возникает вопрос: каким образом при организации игры на такой карте обеспечить начальный паритет игроков?
«Как» или «какую»? Ответ на второй вопрос — синкретическую, основанную на положениях ГОСТов, MSF, PMBoK, OnTarget и собственной многолетней практике работы. Ответ на первый вопрос — достаточно успешно, судя по имеющимся результатам, но предела совершенству нет :)
Вообще, тема интересная и весьма обширная, в ближайшем будущем постараюсь написать по ней несколько топиков.
Ну вот, жестоко заминусовали. Но, уважаемые дамы и господа, согласитесь, интересные вопросы ведь состоят не в том, как будет называться очередная версия хорошо известного продукта, какой будет у нее логотип, сплэш-заставка и т.п.
Интересные вопросы:
— будет ли качество новых версий лучше, или хотя бы не хуже, чем у прежних?
— кто будет далее сопровождать и развивать проект? (старая или новая команда)
— есть ли у проекта спонсоры? кто они? — или это инициатива группы энтузиастов?
Наконец, какую роль в проекте будет играть Canonical? (если планирует ее играть)
Прочитал, зашел по ssh на домашний сервер и запустил dd if=/dev/urandom of=/dev/sda bs=512. Вечером установлю ось и напишу первый хабратопик. Если успею.
> Если вы будете запускать её самостоятельно, имейте в виду: она довольно чувствительна к помехам, вносимым в графики фоновой нагрузкой. Чтобы получить более достоверные результаты, закройте все остальные программы на время замера.
Кроме прикладных программ, в системе осанутся фоновые службы, работа которых также вероятно исказит статистику. Вы не оценивали степень данных искажений, можно ли их считать существенными?
В оригинале стоит explosion — Вы уверен, что Автор имела в виду именно «взрыв», а не «быстрое развитие»? Меня лично смущает слово «взрыв», но я, к сожалению, не знаю статистики использования HTML5 в актуальных проектах.
Final Salute to 2010
Do you agree, disagree, have anything to add? We would love to hear from you.
— это меняет дело!
Заказ Apple?
Далее возможны два типичных варианта:
А) Босс говорит: «Вау, да это круто! Теперь они будут делать то, что раньше мне стоило 40 тысяч за 10 тысяч!»
— после этого timesheet превращается в timeshit и оценки проектов приобретают тенденцию к удлинению даже не на 230%, а на 450%.
Б) Босс говорит: «Вау, да это круто! Эти парни доказали, что они асы, теперь они будут делать более сложные, интересные задачи, оформляй им повышение категории!»
-здесь timesheet будет работать и приносить пользу всем, начиная от джуниоров и заканчивая учредителями компании.
Но опыт подсказывает, что почасовой учет рабочего времени в более-менее крупном проекте надо вести в любом случае, какую бы методологию мы не использовали.
Но! — чего делать нельзя ни в коем случае (если только мы работаем, а не занимаемся выживанием на рынке) — это переводить проектную команду на почасовую форму оплаты труда; смета трудозатрат со стоимостью часа — это документ для обоснования стоимости проектных работ перед Заказчиком, а не для расчета зарплаты персонала.
И заполняться они должны не на бумажках или в таблицах Excel, а в системе управления проектами.
Парни из Canonical ведь уже выпилили однажды GIMP из стандартной поставки, поставив взамен его какую-то марахайку — прецедент был положен.
Вообще, тема интересная и весьма обширная, в ближайшем будущем постараюсь написать по ней несколько топиков.
Интересные вопросы:
— будет ли качество новых версий лучше, или хотя бы не хуже, чем у прежних?
— кто будет далее сопровождать и развивать проект? (старая или новая команда)
— есть ли у проекта спонсоры? кто они? — или это инициатива группы энтузиастов?
Наконец, какую роль в проекте будет играть Canonical? (если планирует ее играть)
К сожалению, топик об этом не говорит ни слова.