среда, 2 июня 2010 г.

Процесс vs Результат

Одни говорят, что менеджмент - это Процесс...
Другие говорят, что менеджмент - это Результат...
Я думаю, менеджмент - это и Процесс и Результат.
Процесс без Результата не имеет смысла.
Результат без Процесса невозможен.

Чуть больше об этих понятиях в книге Масааки Имаи "Кайдзен. Ключ к успеху японских компаний"

понедельник, 29 марта 2010 г.

Почему 9 женщин не могут родить ребёнка за 1 месяц или О применении имитационного моделирования в управлении проектами

Введение

Думаю, многие из вас слышали выражение "9 женщин не могут родить ребёнка за 1 месяц!". Контекст этого выражения очевиден - в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.
image

Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости...
Вот я выше написал "совершенно очевидно...". Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про "9 женщин" никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

понедельник, 11 января 2010 г.

Почему тестирование занимает так много времени?

Наткнулся на интересную статью о тестировании. Особенно понравилось, что это описание можно использовать при оценке (или моделировании) будущих процессов тестирования на проекте. Автор описывает допущения при моделировании и условия, в которых модель справедлива. Предложенная модель больше приближена к жизни, чем оценки линейного (последовательного, монотонного) тестирования, хоть и остаётся при этом только моделью.

Избранные цитаты:
"Если вы работаете в тестировании достаточно давно, вам наверняка задавали этот вопрос — «Почему тестирование занимает так много времени?» Может быть, у вас есть заготовленный ответ на этот вопрос, а может и нет. Здесь я предлагаю модель, которая, я надеюсь, поможет вам справиться с менеджерами, которые задают подобные вопросы."

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

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


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

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


Полностью статья доступна здесь: http://software-testing.ru/library/testing/general-testing/911-why-is-testing-taking-so-long

понедельник, 14 декабря 2009 г.

Учёт рисков при оценке трудоёмкости ПО и планировании проекта

Поговорим о рисках

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

пятница, 27 ноября 2009 г.

Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения

Введение


В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как "перевод". В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив - автор книги "Software Estimation. Demystifying The Black Art" - одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно - милости прошу в комментарии, можно будет меня поправить.


вторник, 10 ноября 2009 г.

Microsoft Customer Care Framework или как Microsoft предлагает заботиться о клиентах

Введение


На фоне того, как Google пытается стать для нас Всем, приятно видеть, что и другие компании не сдаются и продолжают развивать новые сервисы и технологии…

Побывав на прошлой неделе в Microsoft, с удовольствием послушал рассказ о системе Microsoft Customer Care Framework. Более того, удалось побеседовать с одним из ведущих архитекторов этой системы.