1. Глава: «5.2 Velocity – a useful metric for reality checks», а точнее стр. 13. Я не прадлагал «распределять работы», я предлагал распределять дополнительную трудоёмкость. В книге, на которую я ссылаюсь, нет указания поступать именно так. Аналогию я увидел только в том, как учесть неидеальность оцененной трудоёмкости. В моём случае, эта «неидеальность» обуславливается рисками.
2. Статья называется «Учёт рисков при оценке трудоёмкости ПО и планировании проекта». Обратите внимание на выделенные слова.
3. Да, спасибо за определение. Учту.
Не за что извиняться. Негативный отзыв — тоже отзыв. Спасибо.
Насчёт «теоретиков». В статье, скорее, именно чисто практический взгляд. В теории так не должно быть. В теории с рисками нужно всегда бороться, избегать и минимизировать их.
На практике же (по разным причинам) не все риски удаётся победить и минимизировать. Именно поэтому их приходится учитывать.
Методы учёта рисков (помимо их митигации), описанные в этой статье, в течение длительного времени в том или ином виде применялись мной и моими коллегами на очень крупном проекте. Возможно, они не самые правильные, но они позволяли нам защитить как своих коллег-разработчиков, так и себя самих от многих проблем. В этом топике я попытался обобщить опыт и выделить ключевые направления.
Да-да, поднимался. Посмотрите, пожалуйста, внимательно на введение. Там я указал ссылку на эту статью и объяснил, что рассматриваю проблему с другой стороны.
«Запас по времени» — это слишком общая формулировка. Каждый «запас» должен быть обоснован, иначе Вам не удастся защитить свои оценки как перед руководством, так и перед заказчиком. Как минимум, нужно быть честным перед самим с собой. В первую очередь, Вам самому себе надо объяснить, почему Вы закладываете больше времени, чем это нужно в идеальных условиях. Иногда это нужно делать в явном виде (выделение отдельных рисковых задач), иногда сознательно скрывать, распределяя между задачами.
При определённом уровне зрелости команда вполне может и знать о существовании «другого» плана. Это не всегда является проблемой. Проблемой может стать Ваше отношение к команде.
Если люди почувствуют, что Вы искусственно занижаете допустимые сроки, игнорируя объективную потребность времени.
Если поймут, что Вы игнорируете мнение экпертов, тех, кто действительно понимает, сколько нужно усилий.
Если осознают, что Вы фактически «продавливаете» сроки.
В этом случае можно очень быстро потерять доверие команды. И вот тогда уже действительно придётся выкручиваться.
Да, Вы абсолютно правы. Так называемый закон Паркинсона говорит нам о том, что работа стремиться занять всё выделенное на неё время.
Если по каким-либо причинам мы не можем себе позволить прозрачное планирование (политический обстоятельства, внешние факторы и т.п.), то наиболее выгодным является возможность иметь несколько планов в зависимости от потребностей.
Спасибо за отзыв.
Универсального ответа действительно нет.
Но есть методики, которые могут помочь оценить трудоёкость предполагаемой работы: экспертные оценки, групповые оценки, использование исторических данных и т.п.
Чуть позже планирую осветить эти методы в других публикациях.
В данном топике я предполагал, что чистая трудоёмкость уже определена.
Я не к тому, что плёнка позволяет отличить. А к тому, что плёнка часто позволяет сберечь.
Если же нужны отличительные признаки, то их нужно добавлять после того, как багаж будет упакован. Ленточку, например, можно к руче привязать и после упаковки в плёнку.
«Пастернака не читал, но осуждаю!»
Жестковатую рецензию Вы дали для этой книги.
Оне неидеально, как и многие книги по стилистике кодирования, но не настолько, имхо.
Просто немного смутили столь восторженные отзывы. Пока, на мой взгляд, и скорость и удобство использования оставляют желать лучшего. Особенно смущает качество наполнения системы (особенно в сравнении с google maps и yandex maps). Хорошо, если они этот момент не оставять без внимания и действительно будут следить за актуальностью и качеством представленной информации.
Я бы предпочёл видеть такие диграммы в какой-нибудь универсальной нотации. Например, подошёл бы UML. Скриншоты из конструктора выглядят как-то странно.
Отвлекает сильно.
Обычно, когда делаешь какую-то задачу сосредоточенно, то не до «всплывающих окошек» — они сбивают концентрацию.
На занятия иностранным языком лучше выделять определённое время и уж тогда целеустремлённо и концентрированно заниматься.
Дословно «Off-the-Cuff» переводится как «импровизированный, неподготовленный», но в таком виде, на мой взгляд, это звучит криво, не по-русски как-то. Поэтому я избрал синоним «поспешный».
Какой синоним подобрали бы Вы?
Ну наконец… Именно такого комментария я долго ждал. Спасибо.
Согласен с тем, что 3,6 и 10 могут казаться похожими… если не читать пояснения.
Я поясню.
3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — сжатие сроков при сохранении значения трудоёмкости (увеличение команды)
10 — ранние оценки из-за невозможности/нежелания «отойти в сторону» и немного подумать, сравнить и соизмерить.
Да, похожи, но всё-таки разные.
9 — согласился бы с Вами, если бы не тот факт, что продукты бесплатны. Кроме того, никто не заставляет пользовать продуктами автора, даже обычный Excel — уже достаточно мощный инструмент для проведения моделирования.
2 — автор имел в виду проблему «продавливания» оценок теми, кто более уверенно говорит и убеждает. Только это.
5 — здесь автор говорит о том, что инструмент в неумелых руках ещё не гарантирует результата (стамеска в руках мастера — произведение искуства, в «кривых» руках — что угодно, только не то, что нужно)
Риски — это немного другой угол зрения. Риски, как правило (но не всегда), влияют на сроки, а не на оценки трудоёмкости. В общем, это тема другой статьи.
И да, согласен, эти тезисы не спасут от всех ошибок, но, возможно, помогут избежать самых грубых.
2. Статья называется «Учёт рисков при оценке трудоёмкости ПО и планировании проекта». Обратите внимание на выделенные слова.
3. Да, спасибо за определение. Учту.
Насчёт «теоретиков». В статье, скорее, именно чисто практический взгляд. В теории так не должно быть. В теории с рисками нужно всегда бороться, избегать и минимизировать их.
На практике же (по разным причинам) не все риски удаётся победить и минимизировать. Именно поэтому их приходится учитывать.
Методы учёта рисков (помимо их митигации), описанные в этой статье, в течение длительного времени в том или ином виде применялись мной и моими коллегами на очень крупном проекте. Возможно, они не самые правильные, но они позволяли нам защитить как своих коллег-разработчиков, так и себя самих от многих проблем. В этом топике я попытался обобщить опыт и выделить ключевые направления.
«Запас по времени» — это слишком общая формулировка. Каждый «запас» должен быть обоснован, иначе Вам не удастся защитить свои оценки как перед руководством, так и перед заказчиком. Как минимум, нужно быть честным перед самим с собой. В первую очередь, Вам самому себе надо объяснить, почему Вы закладываете больше времени, чем это нужно в идеальных условиях. Иногда это нужно делать в явном виде (выделение отдельных рисковых задач), иногда сознательно скрывать, распределяя между задачами.
Если люди почувствуют, что Вы искусственно занижаете допустимые сроки, игнорируя объективную потребность времени.
Если поймут, что Вы игнорируете мнение экпертов, тех, кто действительно понимает, сколько нужно усилий.
Если осознают, что Вы фактически «продавливаете» сроки.
В этом случае можно очень быстро потерять доверие команды. И вот тогда уже действительно придётся выкручиваться.
Если по каким-либо причинам мы не можем себе позволить прозрачное планирование (политический обстоятельства, внешние факторы и т.п.), то наиболее выгодным является возможность иметь несколько планов в зависимости от потребностей.
Универсального ответа действительно нет.
Но есть методики, которые могут помочь оценить трудоёкость предполагаемой работы: экспертные оценки, групповые оценки, использование исторических данных и т.п.
Чуть позже планирую осветить эти методы в других публикациях.
В данном топике я предполагал, что чистая трудоёмкость уже определена.
Если же нужны отличительные признаки, то их нужно добавлять после того, как багаж будет упакован. Ленточку, например, можно к руче привязать и после упаковки в плёнку.
Жестковатую рецензию Вы дали для этой книги.
Оне неидеально, как и многие книги по стилистике кодирования, но не настолько, имхо.
Про 12 часов Вы явно шутите.
«Request Timeout
The server timed out while waiting for the browser's request.
Reference #2.f9b7b5c.1259827740.2c91fba „
Обычно, когда делаешь какую-то задачу сосредоточенно, то не до «всплывающих окошек» — они сбивают концентрацию.
На занятия иностранным языком лучше выделять определённое время и уж тогда целеустремлённо и концентрированно заниматься.
Какой синоним подобрали бы Вы?
Согласен с тем, что 3,6 и 10 могут казаться похожими… если не читать пояснения.
Я поясню.
3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — сжатие сроков при сохранении значения трудоёмкости (увеличение команды)
10 — ранние оценки из-за невозможности/нежелания «отойти в сторону» и немного подумать, сравнить и соизмерить.
Да, похожи, но всё-таки разные.
9 — согласился бы с Вами, если бы не тот факт, что продукты бесплатны. Кроме того, никто не заставляет пользовать продуктами автора, даже обычный Excel — уже достаточно мощный инструмент для проведения моделирования.
2 — автор имел в виду проблему «продавливания» оценок теми, кто более уверенно говорит и убеждает. Только это.
5 — здесь автор говорит о том, что инструмент в неумелых руках ещё не гарантирует результата (стамеска в руках мастера — произведение искуства, в «кривых» руках — что угодно, только не то, что нужно)
Риски — это немного другой угол зрения. Риски, как правило (но не всегда), влияют на сроки, а не на оценки трудоёмкости. В общем, это тема другой статьи.
И да, согласен, эти тезисы не спасут от всех ошибок, но, возможно, помогут избежать самых грубых.