Я имел в виду, что в реальности приходится сталкиваться с такими проектами, когда невозможно внятно разбить его на задачи, оценить сложность, пока сама задача не будет доведена до определённого этапа. Это вполне логично, но попробуйте объяснить это заказчику, к которому вы пришли и рассказываете, что на его деньги занимались исследованием и пришли к отрицательному результату. В результате субъективно под заказчика придётся подстраиваться.
Далее, для оценки трудозатрат приходится пользоваться определёнными моделями. Все эти модели опираются на вполне определённую статистику и подразумевают большое количество участников проекта. Именно тогда субъективные факторы (плохое настроение ведущего инженера в прошлую пятницу, свадьба шурина системного архитектора и т.п.) взаимоуничтожатся, попав под статистическое усреднение. Останутся только объективные факторы.
Но если у вас участников проекта мало (а таких проектов подавляющее большинство), тогда при применении какой-либо модели субъективные факторы буду вполне соизмеримыми с объективными факторами. И приходится уже учитывать их тоже. Например, ведущий инженер по понедельникам и четвергам не может задержаться на работе, потому что у него по этим дням тренировка, но обычно он с радостью задерживается. Или производительность системного архитектора после выходных ниже, чем в среду, но выше, чем в пятницу.
Да опять-таки ни причём здесь Scrum.
Ни одна из существующих методологий не способна это учесть и не возможно это вообще под какие-либо универсальные рамки подогнать.
Это иррационально, субъективно, и ваша роль как руководителя (команды или самого себя) просто пронаблюдать такие вещи и вывести субъективные закономерности.
Если изначально всё детально разбито на операции, то какая к чёрту разница, как вы дальше будете решать эту задачу.
Про жонглирование — это не к вам и не к автору. Я всё-таки с вами не знаком, чтобы делать такие сильные утверждения. Я скорее про наблюдаемую тенденцию, между делом.
Набор практик — это хорошо, хотя именно это и пугает, потому что многие читают не «набор практик», а «всегда удачный и везде применимый набор практик». Но если кто-то утверждает, что эти практики хорошо применились в конкретной компании на конкретном проекте с конкретной командой, то прежде всего встаёт вопрос не в том, удачны практики или нет, а в сопоставлении вашего конкретного проекта с тем самым проектом, где эти практики удачно применились. А с этим как раз проблемы, потому что помимо каких-то субъективных параметров для сопоставления нужны прежде всего объективные параметры. Которые никто не знает как оценивать либо их просто крайне затруднительно оценить для конкретного проекта. Т.е., к примеру, вам привели в пример проект, в котором здорово применяются определённые практики, и параметры проекта вам выданы… в килограммах. Вы пытаете оценить свой проект на применимость этих практик и получаетете оценку… в метрах. Вот и думайте потом, как сопоставить эти килограммы с вашими метрами. Кто-то из авторов, возможно, приведёт вам эмпирически выведенный коэффициент для конвертации килограммов в метры, но этот коэффициент рассчитан по сотням компаний с командами в 30-100 человек. А у вас всего лишь 5 человек в команде. И вы применяете этот коэффициент. И справедливо получаете ошибку в 200%. И проект ваш разлетается в щепки.
Scrum вполне приемлет оценки. Другое дело, что не так часто авторы упоминают о такой необходимости, и читатель как бы подразумевает, что обойдётся безо всяких измерений. Измерить можно что угодно и измерять надо. Вопрос лишь в том, как это сделать. Для получения системы оценок в компании руководства и заказчики должны с пониманием относиться к этому. Потому что главный бонус, который можно получить на выхлопе — это стабильность, повторяемость результата. Но в подавляющем большинстве случаев людям не нужна какая-то повторяемость, стабильность, нужен лишь сиюминутный результат, а там хоть трава не расти. С новым проектом начнём с самого начала. И так по кругу. В результате редкий руководитель владеет такими знаниями и совсем редко такие знания оседают в базах знаний компаний.
Для ИТ в целом это очень больная тема. И Scrum как таковой тут ни причём.
Очень многие авторы предлагают определённые способы, но далеко не все из них применимы в принципе и ни одна не применима в чистом виде. А учитывая то, что все без исключения авторы почему-то не приводят примеров сложнее и реальнее, чем «Hello, World!», то на выходе получается едва ли не бесполезная информация.
Я уже молчу о том, что в очень многих случаях статьи об этом — банальное жонглирование модными терминами с непонятной целью.
Зачастую компании и команды внутри них организованы таким образом, что затруднительно оценивать что-либо — будь то сложность проекта, его сроки, бюджет. И так же сложно осуществлять мониторинг и прогнозирование. Большинство умозаключений, которые можно сделать в ходе наблюдения за проектом, являются довольно хрупкими закономерностями, которые очень сильно зависят от слишком большого количества переменных. Более того, многие проекты или компании малы, так что вообще какие-либо закономерности и тренды выявлять опасно, т.к. для команды из пары тройки разработчиков в проекте на 3-4 месяца ошибка оценки можен переваливать за 200%, что никуда не годится. Я к тому, что всё настолько иднивидуально, что рецепт, успешно применяемый в условном IBM, скорее всего не сработает в фирме «Рога и Копыта» с персоналом 20 человек вместе с уборщицей.
Я не говорю, что этим не надо заниматься. Напротив: следует всегда держать руку на пульсе. Но следует больше пользоваться головой и руководствоваться здравым смыслом, нежели упражняться в склонении новомодных терминов. В данном случае Scrum ни причём совершенно.
На гонконгском Sonystyle сабж вместе с внешним аккумулятором на 4000 MAH и плёнкой для экрана стоит HK$4,398.00. На наши деньги приблизительно 17500 руб. А у нас «голый» 25000 руб. Это что-то немыслимое!
Мда.
Помню, очередной Cube отсутствием некоторых критичных мелочей меня настолько разочаровал, что я им в сердцах целое гневное письмо написал. Ответили, мол, учтём в будущем. Сомневаюсь.
Одним из пунктов письма было как раз отсутствие внутреннего 3G-модуля.
Хвастливо написано, мол, поддерживаются внешние модемы.
Этим можно было хвастаться, если бы эти модемы были размером (с чем бы сравнить) чуть больше сим-карты.
Но вставлять в компактное мобильное устройство модем размером с четверть самого устройства и считать это достоинством — это ни в какие ворота не лезет. И уж точно не лезет в сумку или в бардачок автомобиля. А если и влезет, то есть крайне высокая вероятность достать это потом с отломанным USB-портом.
У них одинаковое только название: планшет.
Всё остальное — разное. Начиная с технических характеристик и заканчивая целевой аудиторией.
И нет смысла здесь сравнивать габариты. Разве что mail.ru решила перейти от метрической системы к измерению всего и вся «айпадами».
Так и представляю навигатор от mail.ru: «Двигайтесь прямо 800 айпадов, затем держитесь левее».
Нет, я понимаю, что писатели mail.ru обожают Apple и продукцию всех остальных производителей сравнивают именно с их продукцией.
Но сравнивать MS Surface Pro с iPad — надо быть полным кретином.
У Lumia 920 2000 мАч — и не кирпич вроде. Толщина такая же — 10,7 мм.
Это примерно на 14% больше ёмкость.
Если верить техническим характеристикам, несложно прикинуть, что время автономной работы в режиме ожидания в сети 2g/3g будет уже не до 300/400 часов, а до 342/456 часов.
Время в режиме разговора уже не до 7, а до 8 часов.
В режиме плеера не до 18 часов, а до 20,5 часов.
Появятся реальные цифры по времени автономной работы в «смешанном» режиме — можно будет и это оценить.
Но даже так видно, что разница ощутимая.
Пусть будет толще на миллиметр-полтора, но дайте больше ёмкости.
И характеристики отличаются от тех, что на сайте. Например, ёмкость аккумулятора, модель стереогарнитуры.
И смущает одинаковое время работы в 2G- и 3G-сетях в режиме разговора.
И снова аккумулятор не айс…
И память в 8 Гб — это как-то маловато, особенно учитывая стоимость девайса.
А сколько реально доступной для пользователя памяти?
Далее, для оценки трудозатрат приходится пользоваться определёнными моделями. Все эти модели опираются на вполне определённую статистику и подразумевают большое количество участников проекта. Именно тогда субъективные факторы (плохое настроение ведущего инженера в прошлую пятницу, свадьба шурина системного архитектора и т.п.) взаимоуничтожатся, попав под статистическое усреднение. Останутся только объективные факторы.
Но если у вас участников проекта мало (а таких проектов подавляющее большинство), тогда при применении какой-либо модели субъективные факторы буду вполне соизмеримыми с объективными факторами. И приходится уже учитывать их тоже. Например, ведущий инженер по понедельникам и четвергам не может задержаться на работе, потому что у него по этим дням тренировка, но обычно он с радостью задерживается. Или производительность системного архитектора после выходных ниже, чем в среду, но выше, чем в пятницу.
Ни одна из существующих методологий не способна это учесть и не возможно это вообще под какие-либо универсальные рамки подогнать.
Это иррационально, субъективно, и ваша роль как руководителя (команды или самого себя) просто пронаблюдать такие вещи и вывести субъективные закономерности.
Если изначально всё детально разбито на операции, то какая к чёрту разница, как вы дальше будете решать эту задачу.
Набор практик — это хорошо, хотя именно это и пугает, потому что многие читают не «набор практик», а «всегда удачный и везде применимый набор практик». Но если кто-то утверждает, что эти практики хорошо применились в конкретной компании на конкретном проекте с конкретной командой, то прежде всего встаёт вопрос не в том, удачны практики или нет, а в сопоставлении вашего конкретного проекта с тем самым проектом, где эти практики удачно применились. А с этим как раз проблемы, потому что помимо каких-то субъективных параметров для сопоставления нужны прежде всего объективные параметры. Которые никто не знает как оценивать либо их просто крайне затруднительно оценить для конкретного проекта. Т.е., к примеру, вам привели в пример проект, в котором здорово применяются определённые практики, и параметры проекта вам выданы… в килограммах. Вы пытаете оценить свой проект на применимость этих практик и получаетете оценку… в метрах. Вот и думайте потом, как сопоставить эти килограммы с вашими метрами. Кто-то из авторов, возможно, приведёт вам эмпирически выведенный коэффициент для конвертации килограммов в метры, но этот коэффициент рассчитан по сотням компаний с командами в 30-100 человек. А у вас всего лишь 5 человек в команде. И вы применяете этот коэффициент. И справедливо получаете ошибку в 200%. И проект ваш разлетается в щепки.
Scrum вполне приемлет оценки. Другое дело, что не так часто авторы упоминают о такой необходимости, и читатель как бы подразумевает, что обойдётся безо всяких измерений. Измерить можно что угодно и измерять надо. Вопрос лишь в том, как это сделать. Для получения системы оценок в компании руководства и заказчики должны с пониманием относиться к этому. Потому что главный бонус, который можно получить на выхлопе — это стабильность, повторяемость результата. Но в подавляющем большинстве случаев людям не нужна какая-то повторяемость, стабильность, нужен лишь сиюминутный результат, а там хоть трава не расти. С новым проектом начнём с самого начала. И так по кругу. В результате редкий руководитель владеет такими знаниями и совсем редко такие знания оседают в базах знаний компаний.
Очень многие авторы предлагают определённые способы, но далеко не все из них применимы в принципе и ни одна не применима в чистом виде. А учитывая то, что все без исключения авторы почему-то не приводят примеров сложнее и реальнее, чем «Hello, World!», то на выходе получается едва ли не бесполезная информация.
Я уже молчу о том, что в очень многих случаях статьи об этом — банальное жонглирование модными терминами с непонятной целью.
Зачастую компании и команды внутри них организованы таким образом, что затруднительно оценивать что-либо — будь то сложность проекта, его сроки, бюджет. И так же сложно осуществлять мониторинг и прогнозирование. Большинство умозаключений, которые можно сделать в ходе наблюдения за проектом, являются довольно хрупкими закономерностями, которые очень сильно зависят от слишком большого количества переменных. Более того, многие проекты или компании малы, так что вообще какие-либо закономерности и тренды выявлять опасно, т.к. для команды из пары тройки разработчиков в проекте на 3-4 месяца ошибка оценки можен переваливать за 200%, что никуда не годится. Я к тому, что всё настолько иднивидуально, что рецепт, успешно применяемый в условном IBM, скорее всего не сработает в фирме «Рога и Копыта» с персоналом 20 человек вместе с уборщицей.
Я не говорю, что этим не надо заниматься. Напротив: следует всегда держать руку на пульсе. Но следует больше пользоваться головой и руководствоваться здравым смыслом, нежели упражняться в склонении новомодных терминов. В данном случае Scrum ни причём совершенно.
Помню, очередной Cube отсутствием некоторых критичных мелочей меня настолько разочаровал, что я им в сердцах целое гневное письмо написал. Ответили, мол, учтём в будущем. Сомневаюсь.
Одним из пунктов письма было как раз отсутствие внутреннего 3G-модуля.
Хвастливо написано, мол, поддерживаются внешние модемы.
Этим можно было хвастаться, если бы эти модемы были размером (с чем бы сравнить) чуть больше сим-карты.
Но вставлять в компактное мобильное устройство модем размером с четверть самого устройства и считать это достоинством — это ни в какие ворота не лезет. И уж точно не лезет в сумку или в бардачок автомобиля. А если и влезет, то есть крайне высокая вероятность достать это потом с отломанным USB-портом.
Всё остальное — разное. Начиная с технических характеристик и заканчивая целевой аудиторией.
И нет смысла здесь сравнивать габариты. Разве что mail.ru решила перейти от метрической системы к измерению всего и вся «айпадами».
Так и представляю навигатор от mail.ru: «Двигайтесь прямо 800 айпадов, затем держитесь левее».
Например, iPad также меньше суперкомпьютера. Сравнили. И что?
Как можно сравнивать принципиально разные устройства? Не знаю, всё равно что подзорную трубу с микроскопом сравнивать.
Я не защищаю Майкрософт. В данном случае лично мне действительно непонятно, на какие задачи ориентировано устройство и для кого предназначено.
Но сравнивать MS Surface Pro с iPad — надо быть полным кретином.
Это самый что ни на есть флагман. Наряду с TX. Очень дорогой флагман.
Это примерно на 14% больше ёмкость.
Если верить техническим характеристикам, несложно прикинуть, что время автономной работы в режиме ожидания в сети 2g/3g будет уже не до 300/400 часов, а до 342/456 часов.
Время в режиме разговора уже не до 7, а до 8 часов.
В режиме плеера не до 18 часов, а до 20,5 часов.
Появятся реальные цифры по времени автономной работы в «смешанном» режиме — можно будет и это оценить.
Но даже так видно, что разница ощутимая.
Пусть будет толще на миллиметр-полтора, но дайте больше ёмкости.
И смущает одинаковое время работы в 2G- и 3G-сетях в режиме разговора.
И память в 8 Гб — это как-то маловато, особенно учитывая стоимость девайса.
А сколько реально доступной для пользователя памяти?