Pull to refresh

Comments 10

Какой должна быть команда и какие проекты?
Прежде всего такие команды, которые готовы меняться.

По проектам есть только одно пожелание, что он не закроется в ближайшие месяцы, если есть горизонт работ на год-два или больше. К эксперименту уже подключаются команды с суровым enterprise на аутсорсе, и небольшие команды, которые развивают свои продукты и хотят двигать их дальше.
Честно говоря похоже на очередную попытку изобрести «серебряную пулю». Из недостатков видится стоимость замера по первому пункту. Долго, дорого, метрика «плывет» при каждом изменении команды. Пункты 2, 3 выпадают после настройки автоматизации. Остальные пункты подходят не каждому проекту. К примеру п.5 про технический долг может просто говорить о нехватке/избытке специалистов на проекте. В некоторых случаях фигачат поэтапно — сначала реализуют новую функциональность, потом закрывают баги. Для такого кейса технический долг это просто пилообразный график. На тему п.9 такая холиварная тема. Я видел проекты без тестов, я видел проекты где команда разрабатывает продукт и на замечания что что-то не работает тупо отвечала — «у нас все тесты зелены». К сожалению я ни разу не видел продукт с полным покрытием тестами. В случае когда тестировщики еще и аналитики, квалифицированная команда и код ревью, стоимость покрытия тестами может повышать стоимость владения продуктом. Все это очень индивидуально от проекта к проекту, от компании к компании.
  • Измерить первый пункт очень просто. Достаточно составить простой список с разделением системы по областям или модулям (например, интеграция с API, модуль емейлов, процессинг, система аналитики и т.д.). И у каждого разработчика спросить, нормально ли он, по его мнению, ориентируется в этой области. Такой верхенуровневой оценки будет достаточно, чтобы понять картину.
  • С настройкой автоматизации эти пункты выпадают лишь на время, поскольку система развивается и, например, появляется новая база или файловый сервер, выкладка на который не автоматизирована, сразу будет видно, насколько это страшно для команды в краткосрочной и долгосрочной перспективе
  • В случаях, когда сначала реализуют функционал, потом баги — вот от таких-то подходов и стоит избавляться. В частности потому, что баги имеют приоритеты, возможно, они важнее, нежели разработка нового функционала. Работа над всеми метриками в совокупности приведет к коротким итерациям, быстрым и частым релизам.
  • Полное покрытие тестами часто излишне, при хорошем дизайне достаточно core-логику покрыть модульными тестами, сделать порцию приемочный End-To-End и этого будет достаточно для уверенности в работоспособности продукта
  • То, что метрики подойдут не всем проектам, это факт, поэтому и планируем опробовать их на большом количестве проектов, чтобы получить не только позитивный опыт их применения, но и кейсы, когда они провалятся. Так выводы будут более правильные
  1. просто не значит дешево. На моем текущем проекте порядка 200 Use-Case'ов до 10 до 70 страниц и свыше 1200 Business Rules. Ротация кадров в год свыше 100%. На пике 20+ разработчиков, минимум около 6-7 наверное. Я даже грубо не могу оценить затраты на первый пункт по году.
  2. на мой взгляд это ни разу не метрика а простая калькуляция стоимости владения. Не хочу спорить на эту тему.
  3. это вообще-то классический подход когда в команде полно индийских коллег. Его можно критиковать, но он во первых дешев, во вторых с хорошими шансами дает рабочий продукт на выходе.

почитайте Сергея Андреева (ген. директор ABBYY) http://www.rbc.ru/opinions/business/18/03/2016/56ebda6d9a79472a5a650dfe
Статья интересная, но рассказывает об оценке индивидуального вклада каждого человека в результат. Это из другой области тема и не связана с теми подходами к оценке кода команды, о которых речь вверху.

  1. При таких показателях ротации эта метрика у вас точно будет внизу. Команда за год просто может не успевать изучить все аспекты. Упарываться не нужно.
  2. Хорошо, не дискутировать не будем.
  3. На счет дешивизны такого подхода не согласен. Стоимость разработки + стоимость потерянных денег клиента за то, что продукт мог выйти раньше и начать зарабатывать раньше, может быть выше, чем можно себе представить.
На тему метрик технического долга рекомендую пристально посмотреть в сторону SQALE. Возможно, удастся избежать большого количества велосипедостроения. Ибо, вопросы, это конечно, хорошо, но цифры все же несколько лучше.
SQALE на практике пока не удалось нормально завести ни в одной команде в продакшене. Может, плохо пытались. В большинстве случаев команде хватало навыка определить, откуда появляется технический долг и как с ним справляться, нужна была лишь подсказка, что в эту сторону уже пора инвестировать время.
Было бы невероятно интересно узнать, почему именно не удалось?
У меня лично весьма положительный опыт в проектах на Яве. Сейчас пытаюсь прикрутить к серьезному проекту на плюсах, но результаты, которыми можно поделиться, появятся позже. SQALE, это штука не столько для команды (особенно, квалифицированной), сколько для начальства, плюс для сертификации (если софт нужно сертифицировать) и отвечает не столько на вопрос "когда уже пора", сколько на вопрос "что именно будет, если этого сейчас не делать". Опытный архитектор это, конечно, и так понимает, но вот аргументировать перед начальством с цифрами в руках иногда намого проще :) Хотя, на плюсах и для команды есть, благодаря Сонару, одна маленькая, но весьма приятная мелочь — удобная работа с MISRA. Но это, разумеется, нужно далеко не в каждом проекте...
Сложно сказать, скорее мы чаще сталкиваемся со случаями, когда менеджменту ничего доказывать уже не нужно и он прекрасно понимает ценность внедрения каких-то практик, инвестиций в код и т.д. В нашей практике обычная ситуация выглядит так, что и инженеры хотят, и менеджмент хочет, надо только понять, как.
Sign up to leave a comment.

Articles