в реальной жизни условный Вася может вполне "забить" на ответственность
Я три раза перечиал свое сообщение, и не могу понять, как Вы пришли к выводу о том, что "Вася "забил".
Согласно модели Стивена Кови, у каждого человека есть "круг контроля" и "круг влияния". Если непостредственная зона отвественности ограничена "кругом контроля" (для разработчка - написание кода), то приходится внедрять регламенты, чтобы сделать мосты м-ду "кругами контроля" разных сотрудников и команд.
Странно делать выводы об распределении ответственности, когда у Вас нет ни явных, ни косвенных признаков.
Косвенных признаков, кстати, Вы сами достаточно предоставили в статье и комментариях.
Да, в статье и комментариях я подсветил точки в гибких методологиях, где это проблема проявляется и почему в рамках них мы не смогли найти решения.
Нету таких точек в гибких методологиях. Но есть реальная проблема в понимании масштаба отвественности в Agile - что условный Вася, как часть команды, ответственнен не за кусок кода, который он написал, а за результат бизнеса, который этот код сделал (или не сделал).
Если зону отвественности Васи ограничивать Васиным же кодом - критерии приемки будут, условно, чтобы тесты на этом куске кода прошли. Это удобно для Васи, но это не Agile. Если же мы говорим за ответственность Васи за весь продукт, то сразу возникают вопросы скажем, совместимости модулей. И вопрос с прояснением этих неизвестных возникает сам собой как часть задачи и потребует ответа - в противном случае Вася зафейлится.
Но т.к., по всей видимости, у каждого девелопера на Вашем проекте зона его ответственности - его код, вам пришлось добавить еще одну зону ответственности - документацию. Регламент попробуй оспорь - поэтому и работает.
В идеальном мире, да - все верно. И если Вы работаете с системой такого размера, что весь функционал (даже смежный) всегда однозначно известен всем. Но в реальном мире такое тоже не всегда бывает (пример из жизни про сборки SPA где-то в комментариях я приводил).
Дело совсем не в идельном мире. Навскидку:
Сколько команд работают над продуктом?
Как синхронизируются команды? Используете что-то из SAFe, например?
Как управляете зависимостями м-ду компонентами? Как уменьшаете связанность?
И решение этих проблем мог не закладывать исполнитель (он мог о них и не знать.)
1) В груминге и оценке задач участвует вся команда. Как так получилось, что ВСЯ команда не знала о возможных проблемах? Кто-то же из команды должен был "поднять руку" и такой: "hold on a second..." ?
2) Окей, один раз наступили на эти грабли, с кем не бывает. А ретро как же? Внедрение улучшений в процесс?
разработка комплексной документации противоречит целям заказчика, которые у него есть сейчас и при текущем бюджете
Мне кажется, что вы смотрите на документацию, как на outcome, a ее следует рассматривать как tool. Заказчик, безусловно, платит, чтобы получить ценный и работающий продукт, и документация является той составляющей, которая даст нужный результат.
Вопрос - Ваш менеджмент позволяет себе приходить в команду и "рулить" задачами в спринте? Например, в этом спринте запрещают делать техдолг, т.к. есть более приоритетные бизнес задачи? Если да, то почему так происходит? Насколько бизнес доверяет команде? Насколько команда способна выдерживать цели спринта? И что для Вас есть цели спринта?
По гибким методологиям документация должна быть достаточной для решения конкретной задачи, т.е. вполне может не включать большое количество важного
Если документация не включает в себя "большое количество важного", она априори не может быть достаточной. В Agile Команда (а не Заказчик) определяет и отвечает за то, каким способом она реализует фичу, и если ей нужна документация - окей, это те артефакты, которые будут созданы.
Вы правы, материал в основном про модели для английского языка.
Про русский язык, мне, к сожалению, сложно что-то добавить — заказчики англоязычные.
Но вот коллеги из OpenDataScience говорят, что «все можно сделать» :)
Все-таки упущенный import — это всегда проблема :)
Класс NaiveBayesClassifier является частью библиотеки TextBlob:
from textblob.classifiers import NaiveBayesClassifier
# ... Skipped code ...
class TextBlobWrapper():
# ... Skipped code ...
self.classifier = NaiveBayesClassifier(ds.train)
Bопрос #2
Если имеется ввиду, например, td-idf, то пока не получается подружить его с TextBlob.
Удобство TextBlob как библиотеки имеет обратную сторону в виде меньшей гибкости по сравнению, скажем, с NLTK или sklearn.
Bопрос #3
Опять-таки все упирается в возможности TextBlob.
Если верить документации, то сейчас эта библиотека поддерживает следующие классификаторы:
DecisionTreeClassifier — a classifier based on the decision tree algorithm, as implemented in NLTK;
MaxEntClassifier — а maximum entropy classifier (also known as a “conditional exponential classifier”);
NaiveBayesClassifier — a classifier based on the Naive Bayes algorithm, as implemented in NLTK;
PositiveNaiveBayesClassifier — a variant of the Naive Bayes Classifier that performs binary classification with partially-labeled training sets.
TextBlob хорош тем, что позволяет разработчику быстро начать в ML.
Но в дальнейшем, по ходу погружения в тему, следует переходить к другим решениям.
Я три раза перечиал свое сообщение, и не могу понять, как Вы пришли к выводу о том, что "Вася "забил".
Согласно модели Стивена Кови, у каждого человека есть "круг контроля" и "круг влияния". Если непостредственная зона отвественности ограничена "кругом контроля" (для разработчка - написание кода), то приходится внедрять регламенты, чтобы сделать мосты м-ду "кругами контроля" разных сотрудников и команд.
Косвенных признаков, кстати, Вы сами достаточно предоставили в статье и комментариях.
Нету таких точек в гибких методологиях. Но есть реальная проблема в понимании масштаба отвественности в Agile - что условный Вася, как часть команды, ответственнен не за кусок кода, который он написал, а за результат бизнеса, который этот код сделал (или не сделал).
Если зону отвественности Васи ограничивать Васиным же кодом - критерии приемки будут, условно, чтобы тесты на этом куске кода прошли. Это удобно для Васи, но это не Agile. Если же мы говорим за ответственность Васи за весь продукт, то сразу возникают вопросы скажем, совместимости модулей. И вопрос с прояснением этих неизвестных возникает сам собой как часть задачи и потребует ответа - в противном случае Вася зафейлится.
Но т.к., по всей видимости, у каждого девелопера на Вашем проекте зона его ответственности - его код, вам пришлось добавить еще одну зону ответственности - документацию. Регламент попробуй оспорь - поэтому и работает.
Дело совсем не в идельном мире. Навскидку:
Сколько команд работают над продуктом?
Как синхронизируются команды? Используете что-то из SAFe, например?
Как управляете зависимостями м-ду компонентами? Как уменьшаете связанность?
Насколько развито автоматизированное интеграционное тестирование?
Правильно ли я понимаю, что Ваша статья на самом деле о том, как вы решаете проблему Lack of Knowledge в команде, используя Document First?
1) В груминге и оценке задач участвует вся команда. Как так получилось, что ВСЯ команда не знала о возможных проблемах? Кто-то же из команды должен был "поднять руку" и такой: "hold on a second..." ?
2) Окей, один раз наступили на эти грабли, с кем не бывает. А ретро как же? Внедрение улучшений в процесс?
Мне кажется, что вы смотрите на документацию, как на outcome, a ее следует рассматривать как tool. Заказчик, безусловно, платит, чтобы получить ценный и работающий продукт, и документация является той составляющей, которая даст нужный результат.
Вопрос - Ваш менеджмент позволяет себе приходить в команду и "рулить" задачами в спринте? Например, в этом спринте запрещают делать техдолг, т.к. есть более приоритетные бизнес задачи? Если да, то почему так происходит? Насколько бизнес доверяет команде? Насколько команда способна выдерживать цели спринта? И что для Вас есть цели спринта?
Если документация не включает в себя "большое количество важного", она априори не может быть достаточной. В Agile Команда (а не Заказчик) определяет и отвечает за то, каким способом она реализует фичу, и если ей нужна документация - окей, это те артефакты, которые будут созданы.
И есть мнение, что нужна версия #2 — без TextBlob.
Про русский язык, мне, к сожалению, сложно что-то добавить — заказчики англоязычные.
Но вот коллеги из OpenDataScience говорят, что «все можно сделать» :)
Bопрос #1
Все-таки упущенный import — это всегда проблема :)
Класс NaiveBayesClassifier является частью библиотеки TextBlob:
Bопрос #2
Если имеется ввиду, например, td-idf, то пока не получается подружить его с TextBlob.
Удобство TextBlob как библиотеки имеет обратную сторону в виде меньшей гибкости по сравнению, скажем, с NLTK или sklearn.
Bопрос #3
Опять-таки все упирается в возможности TextBlob.
Если верить документации, то сейчас эта библиотека поддерживает следующие классификаторы:
TextBlob хорош тем, что позволяет разработчику быстро начать в ML.
Но в дальнейшем, по ходу погружения в тему, следует переходить к другим решениям.