Вы предлагаете, что имеют право голоса только тимлиды/синьеры?
а вы второго сорта поэтому делаете вот то нельзя.
В предложение/приёме не оговорён круг лиц, которые исследуют юзабилити API. Возможно, это часть разработчиков из команды, которая будет использовать разрабатываемое API. По крайней мере, исследование не может учитывать разработчиков, которые придут на проект после внедрения разработанного API.
Поясню, когда возможен данный случай:
В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Допустим, команда, которая будет использовать API не является высоко-компетентной в разработке низкоуровневой работы с устройствами. В то же время, команда, разрабатывающая API и выделяется, так как обладает компетенциями по работе с некоторым набором низкоуровневых API.
Команда разработки API предоставляет высокоуровневый механизм работы с обощенными устройствами.
Или же выделенная команда разрабатывает используя другие языки программирования.
В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Для меньшей стигматизации можно переписать:
В частности, из-за, например, различий в специализации в разработке выделенной команды и основной команды.
Да, создатель API создает API для пользователей API. Но в цитате это не прописано прямым текстом. Создатель API может полагать, что его видение API и есть лучшее видение API. Я обратил ваше внимание на то, что в цитате не определены заинтерсованные лица. И не определено разрешение конфликта «лучшее API». Возможно, вы к радости читателей сможете привес ти цитату, где опеределены криетрии «лучшего API».
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Поэтому в данном случае возникает конфликт интересов того, что понимать под понятием «лучшая реализация API».
Возможно, я давно не перечитавал классиков TDD и не могу сам найти цитату по разрешению именно данного конфликта — взгляд команды разработки внутреннего API на юзабилити API и взгляд команды разработчиков, которые используют внутреннее API.
Вы правомерно, указываете, что данные процессы существуют в индустрии, вы правомерно указываете, что данные процессы вытекают «из математических аксиом». Но смещаете фокус с выделенного в статье предложения для конкретной команды поити по пути фокусирования на потребностях конкретной команды.
Отличный пример утверждения Шрёдингера. Который раскрывается вопросом: типовой процесс разработки внутренних библиотек для внутренних разработчиков каких фирм/компаний? (Этот вопрос является мотивацией написания поста.)
Разработчик API (используя TDD или иные методы) делает предположение об юзабилити внутренего API. Выдвигает гипотезу (разрабатывает макет API). А далее тестирует эту гипотезу. Используя макет API, просит реализовать разработчиков код, который использует гипотезу API. Далее разработчик API оценивает свою гипотезу. Вносит доработки в гипотезу и тестирует вновь.
Альтернативно, группа разработчиков могла бы формулировать свои собственные гипотезы по необходимому им API.
Вопрос в управлением разработки API. И ведение гипотез к формированию конечного внутреннего API.
В процессе данного предлагаемого тестирования макета API, как понимаете, определяется степень легкости использования API данными разработчиками данной команды, а не корректность реализации и корректность функционирование API (чтобы делал TDD). Определается какие места/возможности API вызывают трудности у разработчика. Где разработчик (конкретной команды, конкретного уровня) допускает ошибки, допускает больше всего ошибок.
Это тестирование дизайна API, а не реализации API.
Хотя да. Можно оформлять тестовые куски использования макета API в автоматизированные тесты и проверять насколько точно разработчик решил задачу по использованию макета API. Косвенно опередлять то, насколько разработчик понимает предлагаемое API.
Вы правы можно использовать автоматизированные тесты.
Правда, есть и такой инструмент, как интервью разработчика. В некоторых случаях интервью будет более дешевой альтернативой получения адекватной обратной связи по дизайну API, нежели автоматизированные тесты для которых первоначально нужно определить метрики.
(Если без иронии и серьезно.) Да, идея совершенно не новая. Да, близка по духу TDD. Но акцент в приёме на раннем тестирование нового API будущими пользователями API (разработчиками). Проведение тестов использования API, проведение code review попыток использовать макета API разработчиками.
Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
Спасибо
«Целеустремленная» предполагает наличие цели.
Можно ли это рассматривать с другой стороны также и как:
1) Недостаточное понимание разработчиков целей на данном этапе разработки проекта.
2) Не сформулированность целей работодателя?
3) «Микроскопом забивают гвозди» — разработчик тяготеет к другому стилю разработки и может быть полезен на другом проекте, на этом же он не столь эффективен?
В успешность работников, которые не могут объяснить, над чем и зачем они работают, я не верю.
Вы формулируете «не могут». Но может ли это быть «не умеют», «не требовался ранее навык объяснения», «не наработан (слаб) навык».
Тогда алгоритм по «не могут»:
1) Учим объяснять;
2) Укрепляем навык объяснения;
3) И вуаля «разработчик может».
И работник может сам анализировать свои ошибки и научится навыку «объяснять».
И если в первом случае, когда разработчика нужно научить навыку ваше «не верю» — это блок для дальнейшего развития коммуникации, то во втором случае, когда сотрудник «может анализировать свои ошибки», то ваша вера — это только повод для ваших собственных разочарования — разработчик с навыком анализа своих ошибок рано или поздно научится объяснять, возможно не у вас на работе, а у другого PM.
Точные минусы статьи:
1) Подход только с точки зрения одной стороны конфликта. Что при отсутствии точного таргетинга сильно влияет.
2) На сайтах подобных Хабру в каждой новой статье нужно знакомиться с читателем заново.
3) Приемы художественного текста должны быть дозированными. Все же это техническое чтение.
Вы предлагаете, что имеют право голоса только тимлиды/синьеры?
В предложение/приёме не оговорён круг лиц, которые исследуют юзабилити API. Возможно, это часть разработчиков из команды, которая будет использовать разрабатываемое API. По крайней мере, исследование не может учитывать разработчиков, которые придут на проект после внедрения разработанного API.
Поясню, когда возможен данный случай:
Допустим, команда, которая будет использовать API не является высоко-компетентной в разработке низкоуровневой работы с устройствами. В то же время, команда, разрабатывающая API и выделяется, так как обладает компетенциями по работе с некоторым набором низкоуровневых API.
Команда разработки API предоставляет высокоуровневый механизм работы с обощенными устройствами.
Или же выделенная команда разрабатывает используя другие языки программирования.
Для меньшей стигматизации можно переписать:
В частности, из-за, например, различий в специализации в разработке выделенной команды и основной команды.
Какие у вас возникают вопросы?
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Поэтому в данном случае возникает конфликт интересов того, что понимать под понятием «лучшая реализация API».
Возможно, я давно не перечитавал классиков TDD и не могу сам найти цитату по разрешению именно данного конфликта — взгляд команды разработки внутреннего API на юзабилити API и взгляд команды разработчиков, которые используют внутреннее API.
Летают на самолетах, а не на авиаиндустрии.
Вы правомерно, указываете, что данные процессы существуют в индустрии, вы правомерно указываете, что данные процессы вытекают «из математических аксиом». Но смещаете фокус с выделенного в статье предложения для конкретной команды поити по пути фокусирования на потребностях конкретной команды.
Для кого лучший? Предложение/приём служит для того, чтобы работать с уточнением ответа на этот вопрос.
В приёме важен акцент на следующем процессе.
Разработчик API (используя TDD или иные методы) делает предположение об юзабилити внутренего API. Выдвигает гипотезу (разрабатывает макет API). А далее тестирует эту гипотезу. Используя макет API, просит реализовать разработчиков код, который использует гипотезу API. Далее разработчик API оценивает свою гипотезу. Вносит доработки в гипотезу и тестирует вновь.
Альтернативно, группа разработчиков могла бы формулировать свои собственные гипотезы по необходимому им API.
Вопрос в управлением разработки API. И ведение гипотез к формированию конечного внутреннего API.
Это тестирование дизайна API, а не реализации API.
Хотя да. Можно оформлять тестовые куски использования макета API в автоматизированные тесты и проверять насколько точно разработчик решил задачу по использованию макета API. Косвенно опередлять то, насколько разработчик понимает предлагаемое API.
Вы правы можно использовать автоматизированные тесты.
Правда, есть и такой инструмент, как интервью разработчика. В некоторых случаях интервью будет более дешевой альтернативой получения адекватной обратной связи по дизайну API, нежели автоматизированные тесты для которых первоначально нужно определить метрики.
Есть ирония… или какие возникают вопросы?
Вы правы. Я этот опыт получил только сейчас.
Также, как не войти в стадию конфликта с разработчиком, как лучше использовать разработчика, предпочитающего определённый стиль разработки.
Извинюсь, скорее подразумевал: «В формулировке _проблем_ есть часть решения для этого кейса».
Метафора: Также как в отладке важно опредлить точную исходную проблему. Решение правильной проблемы способтсвует правильному решению.
Спасибо
Можно ли это рассматривать с другой стороны также и как:
1) Недостаточное понимание разработчиков целей на данном этапе разработки проекта.
2) Не сформулированность целей работодателя?
3) «Микроскопом забивают гвозди» — разработчик тяготеет к другому стилю разработки и может быть полезен на другом проекте, на этом же он не столь эффективен?
Названием статьи ставил вопрос над личным предубеждением _художника_ перед мастерством PM-а.
Вы формулируете «не могут». Но может ли это быть «не умеют», «не требовался ранее навык объяснения», «не наработан (слаб) навык».
Тогда алгоритм по «не могут»:
1) Учим объяснять;
2) Укрепляем навык объяснения;
3) И вуаля «разработчик может».
И работник может сам анализировать свои ошибки и научится навыку «объяснять».
И если в первом случае, когда разработчика нужно научить навыку ваше «не верю» — это блок для дальнейшего развития коммуникации, то во втором случае, когда сотрудник «может анализировать свои ошибки», то ваша вера — это только повод для ваших собственных разочарования — разработчик с навыком анализа своих ошибок рано или поздно научится объяснять, возможно не у вас на работе, а у другого PM.
Можете ли вы поделиться кейсами из личного опыта?
1) Подход только с точки зрения одной стороны конфликта. Что при отсутствии точного таргетинга сильно влияет.
2) На сайтах подобных Хабру в каждой новой статье нужно знакомиться с читателем заново.
3) Приемы художественного текста должны быть дозированными. Все же это техническое чтение.
Да.