Я, как бы, и не спорю. Гибкие методологии — не панацея. Где-то WF работает. Ничего плохого в этом нет.
Просто у ТС описана ситуация, когда в проекте идут постоянные правки и изменения по инициативе заказчика. И да, в комментариях всплыло, что заказчик оплачивал изменения. А вот ПМ не смог работать в таком режиме.
Да, согласен, agile — не серебряная пуля. Но, он может сильно помочь в описанной ситуации, если уметь им пользоваться.
2.
они никак не помогут при работе с заказчиков вида — а давайте все переделаем.
Они как раз на такое и рассчитаны. Закончили спринт (допустим, здесь и далее у нас Scrum). А дальше — хоть с нуля, хоть переноси с веб на десктоп. Главное, спланировать на следующий спринт.
3.
Вы неделю пилите пачку мелких функциональностей, а на следующем совещании вам говорят — вы ничего из того, о чем мы договаривались не сделали, мы обратимся в другую компанию, а с вами посоветуем никому дел не иметь.
«Гибкая методология» — не равно «отсутствие требований, плана и т.п.». Нельзя работу работать в спринте и в итоге сделать не то, что было поставлено, как цели на спринт, а что-то другое. И договорённости все фиксируются. И закзачик сам принимает участие в определении целей.
4.
В данном случае только метод «каждая работа должна оплачиваться» без попыток «подружиться» с клиентом.
Одно другому не мешает. Работа должна быть оплачена всегда.
Есть такое понятие: управление ожиданиями заказчика. И вот тут вы похоже не справились, как ПМ. Потому как работа ПМ, в том числе, заключается в том, чтобы предложить такой подход, который бы учитывал постоянные правки. Я не зря упомянул гибкие методологии. Они действительно могут помочь. И когда человек, который называет себя ПМ, с одной стороны, спрашивает: что это такое, agile? А с другой стороны, сваливает неудачу проекта на заказчика, который постоянно приносит правки, возникают резонные сомнения в его компетентности.
1. От постоянных правок помогают гибкие методологии. А вы, похоже, решили всё и сразу задизайнить, а потом реализовать.
2. Не совсем понятна ваша роль. За что отвечали в проекте?
public static void Main()
{
double a = 1d;
double b = 0.9999999999999999989d;
Console.WriteLine(a == b);
// Outputs: True
}
В .NET, начиная с первой версии, существует Double.Epsilon, которое используется при сравнении чисел. Но, нет гарантии, что от платформы к платформе он не будет меняться.
Да и в целом, из-за особенностей представления в памяти чисел с плавающей точкой, всегда рекомендуется производить их сравнение с явным определением точности. Это ещё на информатике в школе рассказывали.
Даже будучи посредственным разработчиком можно нанять хорошую команду. Но
1. Нужно отдавать себе отчёт, что ты так себе разработчик.
2. Заниматься организацией, а не разработкой.
Проверено на себе.
Просто у ТС описана ситуация, когда в проекте идут постоянные правки и изменения по инициативе заказчика. И да, в комментариях всплыло, что заказчик оплачивал изменения. А вот ПМ не смог работать в таком режиме.
Да, согласен, agile — не серебряная пуля. Но, он может сильно помочь в описанной ситуации, если уметь им пользоваться.
2.
Они как раз на такое и рассчитаны. Закончили спринт (допустим, здесь и далее у нас Scrum). А дальше — хоть с нуля, хоть переноси с веб на десктоп. Главное, спланировать на следующий спринт.
3.
«Гибкая методология» — не равно «отсутствие требований, плана и т.п.». Нельзя работу работать в спринте и в итоге сделать не то, что было поставлено, как цели на спринт, а что-то другое. И договорённости все фиксируются. И закзачик сам принимает участие в определении целей.
4.
Одно другому не мешает. Работа должна быть оплачена всегда.
Исходя из вопроса, я начинаю догадываться о причинах описанного развития проекта.
2. Не совсем понятна ваша роль. За что отвечали в проекте?
В .NET, начиная с первой версии, существует Double.Epsilon, которое используется при сравнении чисел. Но, нет гарантии, что от платформы к платформе он не будет меняться.
Да и в целом, из-за особенностей представления в памяти чисел с плавающей точкой, всегда рекомендуется производить их сравнение с явным определением точности. Это ещё на информатике в школе рассказывали.
Ты весь такой из себя Java разработчик, а тебе на и Haskell.
1. Нужно отдавать себе отчёт, что ты так себе разработчик.
2. Заниматься организацией, а не разработкой.
Проверено на себе.