Количество костылей растет когда с самого начала есть попытки создать «идеальную архитектуру». Простой и прямолинейный код легко менять, легко перемещать и легко развивать. Как только появляются паттерны резко код перестает быть простым и любое изменение, не укладывающееся в «идеальную» архитектуру, производит костыль. Потом применяется «паттерн» чтобы исправить костыль, но со временем это порождает еще больше костылей.
В статье «стартап-ловушка» говорится о том что нужно «Do right things» даже в стартапе. Двигаясь в неверном направлении невозможно достигнуть успеха. Невозможно получить качественный продукт, постоянно экономя на качестве. Правда фокус чересчур программерский.
В этой статье написано о том как «Do things right». О том что эволюция прототипов эффективнее, чем Big Design Upfront. О том что частые релизы, важнее вылизывания.
Во-первых планшет на W8 это не телефон, и не телефон-переросток, как iPad. А во-вторых на телефоне тоже отлично работает мобильная версия сайта YouTube. Да и банальная вещь — на YouTube в 99% я перехожу по ссылкам, мне от приложения ни горячо, ни холодно.
Поковырялся ILSpy, есть обратная совместимость. Если не указан polling, то пытается прицепиться к оповещениям, если Polling указан, то запускает таймер.
Это те же самые SqlDependencies, только они в namespace System.Web.Caching и изначально заточены под кеширование в ASP.NET. По сути они все вызывают классы SqlDependency в SqlClient.
Что значит «вылетел из графика» откуда у него график? Velocity падает? Если нет, то не надо заниматься микро-менеджментом.
Такая ситуация была изначально? Или «внезапно» появилась?
Если изначально, то почему это не было видно на daily scrum? Если человек постоянно не укладывается в сроки задач, то это сразу видно — банально нечего сказать на daily scrum… Значит надо его учить\мотивировать\исключать из проекта.
Если появилась внезапно — надо разобраться с причинами. Например у нас есть один парень, который пошел дополнительно учиться, теперь спит мало, работает плохо. Возможно ему просто часть рабочего времени и ЗП срежут, чтобы планирование не ломалось.
Не зная причины предпринимать любые действия неэффективно, можно нарваться на противоположное действие.
Кто-то это кто? Ведь очень легко отслеживается по истории задач кто сколько работы сделал по истории итерации. Задачи кстати оцениваются в часах, так что низкая продуктивность одного человека будет видна сразу же. Но пока проблем нет (velocity не падает), оценивать индивидуальные метрики нельзя. Это кстати не в скраме написано, а в TSP.
Естественно если есть проблемы надо разбираться в причинах, а не просто «пиши быстрее», иначе качество упадет. Я вот в своей жизни ни разу не видел чтобы человек работал хорошо, а потом внезапно начал работать плохо. Скорее всего для этого есть очень явные причины.
1. Дедлайн означает что к сроку нужно сдать работу в полном объеме. В скраме нет такого. В скраме есть release plan, про это пункты 3-4 предыдущего коммента.
3. В книжном описании скрама есть недостаток. Там считается что все баги устраняются в ходе разработки. Acceptance тесты не ловят всех багов, тестеры тоже люди, допускают ошибки. Поэтому перед релизом продукта таки надо тратить время на вылизывание. Чтобы это уложить в скрам и делается вылизывательная итерация, иначе будет попытка увеличить темп разработки, что скажется на качестве.
Хотя если вы пилите публичный сайт, то возможно имеет смысл иметь команду разработки и команду поддержи. Первая струячит фичи, вторая выкладывает результаты итерации в продакшн и фиксит проблемы. Каждый релиз команды меняются.
Да, практика показывает что правильное применение скрама делает работу более равномерной, и в среднем продуктивность растет из-за отсутствия переключений между задачами, персонального commitment_а разработчиков и раннего устранения дефектов. Но изначально все это достигается снижением темпа разработки, а преимущества появляются не сразу и только если менеджмент не мешает.
Если начинает падать velocity, то надо разобраться почему. Чаще всего velocity падает из-за того что есть working to deadline и нету достаточно тестирования в итерации, от этого появляется много багов, которые отъедают часть работы в следующей итерации.
Надо снижать темп в таком случае.
Про считалку — отказ от durable хранилища противоречит «Do right things».
Причем тут эффект Даннига-Крюгера не понял.
В этой статье написано о том как «Do things right». О том что эволюция прототипов эффективнее, чем Big Design Upfront. О том что частые релизы, важнее вылизывания.
Эти вещи не противоречат друг другу.
Думаю обратная совместимость в этом месте есть.
Подробнее тут: msdn.microsoft.com/ru-ru/library/5ecf4420(v=vs.90).aspx
Такая ситуация была изначально? Или «внезапно» появилась?
Если изначально, то почему это не было видно на daily scrum? Если человек постоянно не укладывается в сроки задач, то это сразу видно — банально нечего сказать на daily scrum… Значит надо его учить\мотивировать\исключать из проекта.
Если появилась внезапно — надо разобраться с причинами. Например у нас есть один парень, который пошел дополнительно учиться, теперь спит мало, работает плохо. Возможно ему просто часть рабочего времени и ЗП срежут, чтобы планирование не ломалось.
Не зная причины предпринимать любые действия неэффективно, можно нарваться на противоположное действие.
Естественно если есть проблемы надо разбираться в причинах, а не просто «пиши быстрее», иначе качество упадет. Я вот в своей жизни ни разу не видел чтобы человек работал хорошо, а потом внезапно начал работать плохо. Скорее всего для этого есть очень явные причины.
3. В книжном описании скрама есть недостаток. Там считается что все баги устраняются в ходе разработки. Acceptance тесты не ловят всех багов, тестеры тоже люди, допускают ошибки. Поэтому перед релизом продукта таки надо тратить время на вылизывание. Чтобы это уложить в скрам и делается вылизывательная итерация, иначе будет попытка увеличить темп разработки, что скажется на качестве.
Хотя если вы пилите публичный сайт, то возможно имеет смысл иметь команду разработки и команду поддержи. Первая струячит фичи, вторая выкладывает результаты итерации в продакшн и фиксит проблемы. Каждый релиз команды меняются.
Да, практика показывает что правильное применение скрама делает работу более равномерной, и в среднем продуктивность растет из-за отсутствия переключений между задачами, персонального commitment_а разработчиков и раннего устранения дефектов. Но изначально все это достигается снижением темпа разработки, а преимущества появляются не сразу и только если менеджмент не мешает.
Надо снижать темп в таком случае.