Что-то вы усложняете. Какая еще средняя температура по больнице? Есть спринт в днях, есть задачи, есть их оценка в идеальных днях. Устанавливаете фокус-фактор, умножаете и отрезаете те задачи, которые не вмещаются в спринт. Если сделали все задачи — угадали с фокус-фактором, не сделали — значит, фокус фактор был ниже и на следующий спринт его надо скорректировать. Сделали больше — круто, значит, фокус-фактор на следующий спринт можно как-то увеличить.
Здесь квалификация отдельного человека не причем, идет оценка работы всей команды как единого целого.
>Ну, если менеджер — обезьяна, то тут и скрам не поможет.
Именно что поможет. Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.
>Что вы знаете про весь проект с этими данными?
Зависит от срока и размера проекта. Если проект мелкий — средний, то всю картину можно разбить на бизнес-задачи. Если он очень большой (как у нас сейчас, например), то берется некоторый актуальный зазор задач, определяемый на встречах с заказчиком — своего рода «мелкий» проект, без особых четко очерченных границ. В любом случае, я хочу сказать, что «знать» про проект — можно. Составление бэклога с последующей приоретизацией и межкомандным согласованием — это очень важная задача. Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.
>когда надо, а что не успели — отрезать.
Вы знаете, получается что в канбане так — ВДРУГ всем стало ясно, что не успели. Работали работали, и не успели.
Итерация дает обратную связь, позволяет изменять процесс и делать его прозрачным.
>Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.
Вот этого я не понимаю. Спринт закончился — если остались задачи, спринт провалился, устраивается разбор полетов. В канбане задача может провисеть мертвой некоторое время, пока кто-нибудь не спохватится — «ой, что это у нас тут».
>и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну
По-моему, это некорректно. Задачи ведь неравномерны по времени своего исполнения!
>Если оно растет — что-то не так.
В статье писалось, что такого аспекта как замеры времени в процессе не существует:)))
Ладно, хватит придирок. Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.
Что вы говорите. Одно из понятий скрама — фокус-фактор, который говорит, как эффективно работает команда и сколько она способна решить задач за квант! Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.
В канбане я этого не вижу. Т.е. с первого взгляда — это такая текучка, очень хорошая для постоянного процесса (как непрерывное производство машин, например), но для производства ПО — это как-то оооооочень гибко.
Раз уж решили сравнивать скрам, то я вот что скажу — скрам хорош тем, что он защищает разработчиков от оголтелого произвола менеджеров, или же наоборот, позволяет менеджерам видеть, кто саботажник или просто плохо работает. Это позволяет скорректировать планы и той, и другой стороне.
В канбане этого нет. Что я менеджеру скажу? Я не могу ему сказать, что ему надо убрать пять задач, потому что мы их тупо не успеем сделать — у нас статистикой доказано, что средний фокус фактор, например, 48%. Менеджер от меня ждет оценку (от менеджера этого требуют заказчики) — мне нужно дать ему оценку, пусть даже вы правы насчет тем, кто решает успех проекта.
В канбане нет фокус фактора, весь процесс производства — постоянная текучка, стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами. Говорить ему при этом «Дядя, че ты ко мне лезешь, неужели ты не знаешь, что от тебя в разработке проекта ничего не зависит?», как было заявлено в статье, это моветон, меня дядя в 24 часа уволит за некомпетентность.
Вот тут все Фаулера рекомендуют, а я порекомендую Макконнела :)
Больше всего мне понравилась методика «чистый идеальный мир» — интерфейс — «ад», где он рекомендует определить интерфейс между грязным кодом и чистым идеальным кодом, и потихоньку переносить грязный код за «барьер».
Ну и вообще, цитата из книжки: Значение слова «рефакторинг» довольно размыто: так называют исправление дефектов, реализацию новой функциональности, модификацию проекта — по сути любое изменение кода. Это неуместно. Целенаправленный процесс изменений может быть эффективной стратегией, обеспечивающей постепенное повышение качества программы при ее сопровождении и предотвращающей всем известную смертельную спираль энтропии ПО, но само по себе изменение достоинств не имеет.
1) Строить объекты доменной логики через фабрику-контейнер — практически моветон, месье. Практически — это потому, что оно моветон за исключением случая, когда доменные объекты строятся и наполняются данными через фабрику (как DTO объекты). В этом случае доменные объекты должны иметь публичные интерфейсы и, по всей видимости, должны быть read-only, чтобы можно было защититься от нарушения целостности данных. Еще минус в том, что вы должны явно следить за жизненным циклом создаваемых доменных объектов — удалять их из контейнера и диспоузить по требованию.
2) У меня в примере класс-модуль не инъецируется. Вы путаете с composite application library, там бутстраппер действительно делает инъекцию в модуль, а я всего лишь создаю это класс и вызываю его метод.
Понимаю ваши опасения в плане явного задания свойств-зависимостей. Для этого их нужно делать пабликами, что не всегда верно с точки зрения инкапсуляции. Делайте микросервисную архитектуру, где сервисы или нужные вам объекты инъектятся через конструктор.
Ну и вообще еще совет — используйте контейнер и инъектор как можно реже и только там, где он действительно нужен. Контейнер сам по себе представляет расшаренный ресурс между всеми участками кода, которые с ним работают. Через это нарушается концептуальная целостность и опять же, инкапсуляция, потому что работающие участки кода должны знать, что лежит в контейнере и в каком состоянии он находится, дабы не нарушить свою работоспособность.
Вот бляха, и правда из-за этой галки пост в ленту не попал.
Дело в том, что тебе каждый умник скажет, что да, разделить на слои это круто. Все аналитики тебе будут писать документы, где система будет разделена на слои, но вот о том, каким образом и как разработчики будут эти слои делать — сие неведомо.
Вот мы на своем проекте все в жопу запороли, хотя да, «слои» есть:)
Да вы знаете, здесь дело не в тех терминах, которые вы написали. Здесь дело в практической применимости. Все вышесказанное можно написать без Unity, на ServiceContainer например. Просто, кода будет немножко больше.
>Вопрос такой, в какой системе IoC контейнер может быть полезен при разработке бизнес приложений и на бою?
самое простое решение — архитектура черных ящиков, или «черных слоев», когда при пуске приложения контейнер проходит по всем слоям и регистрирует задаваемые слоями реализации. При этом в сборке реализацию можно скрыть от лишних глаз, т.е. добиться полной инкапсуляции в слое. А это очень круто.
>Чем IoC лучше?
Да ничем он не лучше. Это просто паттерн автоматического определения зависимостей. Он есть в контейнере Unity. Контейнер Юнити описывается автором только потому, что это типа «модное и современное» решение, хотя, судя по ответам на технические вопросы, автор только-только что-то прочитал. IoC можно вообще убрать, написав свой контейнер или взяв простой существующий. System.ComponentModel.Design.ServiceContainer, например (хотя, если вы джавист, то это вам ничего не скажет).
Фишка удобства тестирования не выходит из концепции Unity, а выходит из концепции построения классов, которые удовлетворяют шаблону определения зависимостей. Ты должен или проставить зависимость в конструкторе или в свойстве класса, причем, желательно определив интерфейс. Значит, очень легко настроить mock зависимостей (мок интерфейса очень легко сделать) и протестировать фукнционал класса. Unity контейнер здесь не причем. Он всего лишь вставляет зависимости.
да сам асп-нет тут не причем. Это тоже черный ящик. Фишка в низкой связности и (что очень важно), поняности этой низкой связности. Микросервисы, контейнер, блаблабла
В книжке рассмотрены приводимые вами ситуации. Вы бы почитали сначала, а потом умничали.
Вам следует прочитать вот эту книгу:
scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf
Там всего 100 страниц и все на русском. Не поленитесь, это очень полезно.
Здесь квалификация отдельного человека не причем, идет оценка работы всей команды как единого целого.
Именно что поможет. Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.
>Что вы знаете про весь проект с этими данными?
Зависит от срока и размера проекта. Если проект мелкий — средний, то всю картину можно разбить на бизнес-задачи. Если он очень большой (как у нас сейчас, например), то берется некоторый актуальный зазор задач, определяемый на встречах с заказчиком — своего рода «мелкий» проект, без особых четко очерченных границ. В любом случае, я хочу сказать, что «знать» про проект — можно. Составление бэклога с последующей приоретизацией и межкомандным согласованием — это очень важная задача. Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.
>когда надо, а что не успели — отрезать.
Вы знаете, получается что в канбане так — ВДРУГ всем стало ясно, что не успели. Работали работали, и не успели.
Итерация дает обратную связь, позволяет изменять процесс и делать его прозрачным.
>Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.
Вот этого я не понимаю. Спринт закончился — если остались задачи, спринт провалился, устраивается разбор полетов. В канбане задача может провисеть мертвой некоторое время, пока кто-нибудь не спохватится — «ой, что это у нас тут».
>и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну
По-моему, это некорректно. Задачи ведь неравномерны по времени своего исполнения!
>Если оно растет — что-то не так.
В статье писалось, что такого аспекта как замеры времени в процессе не существует:)))
Ладно, хватит придирок. Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.
В канбане я этого не вижу. Т.е. с первого взгляда — это такая текучка, очень хорошая для постоянного процесса (как непрерывное производство машин, например), но для производства ПО — это как-то оооооочень гибко.
Раз уж решили сравнивать скрам, то я вот что скажу — скрам хорош тем, что он защищает разработчиков от оголтелого произвола менеджеров, или же наоборот, позволяет менеджерам видеть, кто саботажник или просто плохо работает. Это позволяет скорректировать планы и той, и другой стороне.
В канбане этого нет. Что я менеджеру скажу? Я не могу ему сказать, что ему надо убрать пять задач, потому что мы их тупо не успеем сделать — у нас статистикой доказано, что средний фокус фактор, например, 48%. Менеджер от меня ждет оценку (от менеджера этого требуют заказчики) — мне нужно дать ему оценку, пусть даже вы правы насчет тем, кто решает успех проекта.
В канбане нет фокус фактора, весь процесс производства — постоянная текучка, стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами. Говорить ему при этом «Дядя, че ты ко мне лезешь, неужели ты не знаешь, что от тебя в разработке проекта ничего не зависит?», как было заявлено в статье, это моветон, меня дядя в 24 часа уволит за некомпетентность.
Больше всего мне понравилась методика «чистый идеальный мир» — интерфейс — «ад», где он рекомендует определить интерфейс между грязным кодом и чистым идеальным кодом, и потихоньку переносить грязный код за «барьер».
Ну и вообще, цитата из книжки:
Значение слова «рефакторинг» довольно размыто: так называют исправление дефектов, реализацию новой функциональности, модификацию проекта — по сути любое изменение кода. Это неуместно. Целенаправленный процесс изменений может быть эффективной стратегией, обеспечивающей постепенное повышение качества программы при ее сопровождении и предотвращающей всем известную смертельную спираль энтропии ПО, но само по себе изменение достоинств не имеет.
1) Строить объекты доменной логики через фабрику-контейнер — практически моветон, месье. Практически — это потому, что оно моветон за исключением случая, когда доменные объекты строятся и наполняются данными через фабрику (как DTO объекты). В этом случае доменные объекты должны иметь публичные интерфейсы и, по всей видимости, должны быть read-only, чтобы можно было защититься от нарушения целостности данных. Еще минус в том, что вы должны явно следить за жизненным циклом создаваемых доменных объектов — удалять их из контейнера и диспоузить по требованию.
2) У меня в примере класс-модуль не инъецируется. Вы путаете с composite application library, там бутстраппер действительно делает инъекцию в модуль, а я всего лишь создаю это класс и вызываю его метод.
Понимаю ваши опасения в плане явного задания свойств-зависимостей. Для этого их нужно делать пабликами, что не всегда верно с точки зрения инкапсуляции. Делайте микросервисную архитектуру, где сервисы или нужные вам объекты инъектятся через конструктор.
Ну и вообще еще совет — используйте контейнер и инъектор как можно реже и только там, где он действительно нужен. Контейнер сам по себе представляет расшаренный ресурс между всеми участками кода, которые с ним работают. Через это нарушается концептуальная целостность и опять же, инкапсуляция, потому что работающие участки кода должны знать, что лежит в контейнере и в каком состоянии он находится, дабы не нарушить свою работоспособность.
Дело в том, что тебе каждый умник скажет, что да, разделить на слои это круто. Все аналитики тебе будут писать документы, где система будет разделена на слои, но вот о том, каким образом и как разработчики будут эти слои делать — сие неведомо.
Вот мы на своем проекте все в жопу запороли, хотя да, «слои» есть:)
самое простое решение — архитектура черных ящиков, или «черных слоев», когда при пуске приложения контейнер проходит по всем слоям и регистрирует задаваемые слоями реализации. При этом в сборке реализацию можно скрыть от лишних глаз, т.е. добиться полной инкапсуляции в слое. А это очень круто.
>Чем IoC лучше?
Да ничем он не лучше. Это просто паттерн автоматического определения зависимостей. Он есть в контейнере Unity. Контейнер Юнити описывается автором только потому, что это типа «модное и современное» решение, хотя, судя по ответам на технические вопросы, автор только-только что-то прочитал. IoC можно вообще убрать, написав свой контейнер или взяв простой существующий. System.ComponentModel.Design.ServiceContainer, например (хотя, если вы джавист, то это вам ничего не скажет).
Фишка удобства тестирования не выходит из концепции Unity, а выходит из концепции построения классов, которые удовлетворяют шаблону определения зависимостей. Ты должен или проставить зависимость в конструкторе или в свойстве класса, причем, желательно определив интерфейс. Значит, очень легко настроить mock зависимостей (мок интерфейса очень легко сделать) и протестировать фукнционал класса. Unity контейнер здесь не причем. Он всего лишь вставляет зависимости.
я прям физически ощущаю вброс:)