Сап, харканы!Случилось Новогоднее Счастье (нет).После сраных праздников я возвращаюсь в свою говноконтору своего мухосранска уже не в качестве быдлокодера, но в качестве "начальника кодеров". Группа, которой мне предстоит руководить - это горстка (3-5) малограмотных кодеров, совсем чуть хуже меня. Никто до меня в этой конторке ничем подобным не занимался (IT, как понимаете, тут далеко не основная деятельность, раньше мы просто входили в состав IT-отдела, теперь решили выделить внутри него группу именно кодеров и меня вынудили согласиться их возглавлять). Просто у нас есть несколько крупных проектов (ПО для внутреннего пользования) и ворох мелочи-текучки (скриптики там, например).Я, конечно, расстроен появившейся ответственностью за которую писю доплатят, а то ещё и урежут чего. Но тред не об этом.Прошу у анона советов годных: чего почитать-поизучать мамкиному тимлидику? Никаких примеров для подражания перед глазами нет и не было. Есть же годная, хорошая литература или статейки? Интересуют все аспекты: как общаться с людьми (ну, по работе), мотивировать их (или вышвыривать на мороз), как организовать трудовой процесс, какие подходы к разработке и сопровождению мелкого ПО нынче "модные"? До сих пор сам использовал git, doxygen и всякую самую разную хуйню в зависимости от задачи в качестве ЯП/фреймворка/платформы, но остальные пидарасы коллеги так к ним и не приучились, а очень хочется приучить, но не знаю как и не уверен что это на сегодняшний день наилучший выбор, а хочется же сделать сразу нормально, да и нужны же ещё инструменты типа багтрекинга или управления проектами и чтобы всё друг к другу подходило.Выручайте, братюни. Кто помоложе может представить, что работает в моей команде. Кто постарше может представить, что заинтересован в успешности моей группы (вышестоящий начальник). Советы? инб4: бочку, хуйца и т.п.
сначала надо пояснить, кароч заходишь в их петушатник и хуяришь с ноги в ебальники со словами: "ЧО ЕБАНУТЫЕ!!!?!??! ЧО ТУТ ДЕЛАЕТЕ!!!??!???" уходишь пока они соображают "КТО ЭТО БЫЛ ТО БЛЯТЬ ВООБЩЕ!!?!?!??!!!???? А!??!??"через 15 минут опять заходишь, отвечаешь на вопросы по архитектуре...
>>904649 (OP)>как общаться с людьми (ну, по работе)Как бы ты сам с собой общался, будучи на их месте. Сам же только недавно был на их месте — главное не доебывайся как тп и не переберщивай с митапами и прочей хуйней.>мотивировать их (или вышвыривать на мороз)Зависит от того, с кем работаешь. Молодые, горячие — любят новые и интересные технологии (если есть прям ну задроты — еще и сложные задачи). Всякий унылый энтерпрайз шит (как правило с семьей и прочим) — таких интересует только зарплата. Ну еще как бы пораньше освободится — этим производительность труда можно поднимать (лол).>коллеги так к ним и не приучилисьТы где работаешь-то? В какой-то мухосранской 1С конторе? Это же везде требуют от джунов, лол.Все "аналоги" — это все то же самое, объединенное в одну большую платформу, так что метод анально-долбровольного принуждения или тряси деньги на всякие teamcity, youtrack и прочее.
>>904678>Ты где работаешь-то?Да большой завод (градообразующее предприятие как бы), который решил, что ему нужно для некоторых задач своё собственное ПО, но вместо аутсорса добрал в айти-отдел (к всяким эникейщикам и техподдержке) несколько кодеров; ну, самого работодателя положение устраивает, а я за него не думаю.В принципе бабла немного есть у конторы, может попробую выбить молодым курсы какие, но тут тоже много вопросов: какие, куда, стоят-то дохуя, а толк далеко не ото всех. Конечно хотелось бы вообще заебатого коллектива со всякими локальными контестами, пятницами для изучения нового и т.п. Но ясно в принципе, что это всё во влажных снах скорее всего останется, но тем не менее очень хочется выжать максимум пользы из нового положения и организовать работу максимально правильно.Пока засел за https://rsdn.org/summary/959.xml .Алсо, пилите кулстори про своих тимлидов и ситуации в коллективе. Интересно же.
> https://rsdn.org/summary/959.xmlПоказалось мне тут всё в принципе разумным, но каким-то старым, прям говно мамонта. Мол, agile наше будущее, но только 5-10 лет назад. Как оно, так и выходит? Чего бы поновее почитать, только не сраную хабру.Пока вот присмотрел халявный ProjeQtOr, выглядит заебато, из очевидных минусов - отсутствие интеграции с Git (и любой другой системой контроля версий), но надеюсь 3.5 разрабам будет норм ручками со ссылками на коммиты работать.Ещё кстати висит угроза выкручивания рук чтоб разработки шли по ГОСТам. Никогда этой хуйни не читал, гугл выдаёт что-то больно дохрена, включая всякий шлак из 60-ых 70-ых годов, хотя я знаю, что есть и нормальные рекомендательные стандарты - переводы из ISO. У кого какой опыт работы по ентим самым гоатсам? Есть в них рациональное что-то, или только лишний геморрой?
>>905676Короче, чувак, слушай сюда. Agile - это не для завода, не для критических для производства приложений, хотя элементы его не помешают (непрерывный девелопмент, баги>фичи, разработка через тестирование и т.п.).Вот практические шаги, которые тебе надо будет сделать как руководителю для организации процесса разработки.0. Вам нужна (хотя бы одна) выделенная машина-сервер, мощнее чем все остальные, которая будет централизованным репозиторием документации, кода, платформой для сервисов вроде постановщика задач/багтрекера (redmine), ci (jenkins), системы контроля версий и ревью (git + gitlab). Всё это должно быть синтегрировано. Выдели чувака, который должен будет это всё настроить, пока вы занимаетесь п.1.1. Все ТЗ, вся матчасть должна быть чётко формуляризована до того, как вы начнёте разработку. Ты знаешь доксиген - превосходно, у вас должна быть общая вики/портал, на котором будут доступны для разработчиков все спецификации и ТЗ. Тестовые кейсы - там же, в приложены к конкретным модулям/пунктам ТЗ (о них позже). То есть на первое время основной твоей работой 24/7 будет наполнение такого портала с документацией, написание подробных ТЗ и спецификаций и согласование их с начальством.Насчёт ГОСТов. Есть ГОСТ на разработку ПО, он описывает "водопадную" модель процесса разработки (сначала документация - потом реализация - потом тестирование), и есть набор ГОСТов на техническую документацию (штук десять их, входят в одну группу с первым). Вот как раз воторе тебе и нужно - вся документация должна быть оформлена по ГОСТу. Также есть ИСО 26001, который описывает процесс контроля качества в разработке ПО. Думаю, что вашему маленькому ИТ отделу он мало применим, хотя знать его необходимо.К созданию документации должны быть привлечены все сотрудники под твоим чётким руководством. Там много рутины, так быстрее успеете, и люди чему-то научатся. Составлять документы надо в doxygen-формате и коммитить их в гит. Как только сервак из п.0 будет готов, все доки должны коммититься туда и там же будет доступен портал с документацией.2. Как только часть спецификаций будет готова, начинай проработку архитектуры. Собирай короткие получасовые митинги со своей командой, где каждый будет делать предложения и давать оценку трудоёмкости. Митинги должны юыть посвящены одной конкретной теме/модулю/части ТЗ.Да, насчёт оценки трудоёмкости. Это самое сложное и тебе придётся сообщать эти оценки руководству. Добавляй примерно треть ко всем оценкам на первых порах, потом этот процент можно будет подкорректировать по результатам работы. Разбивай ТЗ на как можно более мелеие подзадачи, которые легко оценить и дать в работу одному человеку. В багтрекере обязательно используй трекинг времени и заставь всех его использовать, иначе реалистичных оценок вам не видать. Тут тебе пригодится часть методологии "scrum" по части механизма оценивания и планирования итераций разработки (спринтов). Каждый спринт будет планироваться по мере готовности задач в работе и спецификаций из п.1.3. Тестирование. Тест кейсы должны составляться разработчиками по спецификации ДО начала разработки и оцениваться тобой (и другими разработчиками). Лучше иметь некий плагин к багтрекеру/отдельный портал с тесткейсами, хотя можно и вести их в вики/параллельно с документацией. Все тесткейсы должны бть проклассифицированы по пунктам ТЗ и пронумерованы. В дальнейшем, коммиты фич и багфиксов не должны приниматься без юнит- и функциональных тестов. ПРИ ОЦЕНКЕ ТРУДОЁМКОСТИ ФИЧ ОБЯЗАТЕЛЬНО ДОЛЖНА ПРОВОДИТЬСЯ ОЦЕНКА ТРУДОЁМКОСТИ НАПИСАНИЯ ТЕСТОВ и включаться в конечную оценку. Если трудоёмкость тестов неизвестна, то надо использовать коэффициент x2 если фреймворк уже готов и надо только дописать сами тесты, или x3 - x5 если тестов на похожую функциональность ещё нет. перед коммитом фичи должна происходить ручная приёмка фичи другим разработчиком, который делает вывод о качестве автотестов и проверяет рабоспособность фичи в целом. Всё это документируется в багтрекере и затраченное время также трекается. Так как разрабов мало, должность тестировзика должна быть переходящей. Ответственность за последующие баги в сданной фиче ложится на того, кто принимал фичу и тесты.4. Ревью кода. Используй git-flow и пулл-реквесты в гитлабе. Для пулл-реквестов применяется процесс тестриования, описанный выше.5. Процесс сборки должен быть автоматизирован с помощью Jenkins. Гитлаб позволяет триггерить билды по коммиту. Два раза в день должны прогоняться функциональные тесты, юнит-тесты гоняются он-коммит.6. Интеграционные тесты должны быть готовы перед сдачей системы (если она содержит несколько взаимодействующих модулей, например, по клиент-серверной архитектуре). Можно начинать писать их сразу, используя заглушки, но можно и потом, когда большая часть модулей будет готова.7. Стартап-митинги зло, но без них никак. Возьми за правило краткие 20-30 мин митинги в начале дня. За опоздания не еби, но эти митинги должны (и будут) мотивировать приходить вовремя. На митинге каждый участник отчитывается о том, что делал вчера, каких достиг результатов, и что будет делать сегодня. Ты, как руководитель, должен оценить успешность выполнения заданий и заранее выявить проёбы, грамотно перераспределить ресурсы, подсказать с затыками, напомнить о сроках. Результаты митингов можно фиксировать в redmine.Фух, может вспомню ещё что, это пока что навскидку на ум пришло.
>>905682Как организовать разработку после первого релиза.Во-первых, в релиз должны войти только полностью покрытые тестами и протестированные фичи. Используя описанный выше процесс, в "мастере" такое состояние будет поддерживаться практически постоянно, поэтому релиз может состояться в любое время. После релиза и сбора обратной связи/багов на реальной системе, боевых инсталляциях, процесс багфиксинга и запиливания надо начинать с внесения изменений в документацию. Дальше процесс тот же, что и описан выше.НЕ ДАЙ НАЧАЛЬСТВУ ПРОДАВИТЬ СВОИ СРОКИ! Если твоя команда не успевает, выкидывай фичи, но никогда не выкатывай недотестированный продукт на боевую инсталляцию. Используй кодстайл, коммиты не под код-стайлу не принимаются. Для контроля надо использовать линтеры, они доступны для всех мейнстримных языков, который запускаются перед компиляцией. Да, я зыбыл, чтобы органзовать запуск юнит-тестов и линтеров, а также автоматическую сборку, надо использовать систему сборки вроде Maven, Ivy, Grunt, etc. в зависимости от выбранного стека технологий. Maven - дефолтный выбор для Java и C/C++, если не знаешь, с чего начать. Готовые сборки должны заливаться на ftp/паблишиться на сервер артефактов (типа nexus или artifactory), оттуда они будут браться автоматическим деплой скриптами или людьми для установки.
>>905682Проебался с номером ИСО, надо 25001, вообще всё семейство 250ХХ надо знать.
>>905676>>905682О, кстати, наткнулся у себя в закладках на ссылку с книжками для тимлидов.https://habrahabr.ru/company/devrainsolutions/blog/163113/
>>905682 >>905688О, выглядит всё охуенно стройненько, спасибо.Пойду читать доки на всё перечисленное.Так-то выделенный сервер в материальном смысле имеется, сам заводил для гит-репозиториев своих проектов, остаётся поднять и настроить там всё остальное и людей туда перевести из их блокнотиков.Вот с тестированием тоже не везде ясно. У нас, понятно, много кода, связанного с контролем/управлением железом (датчики, движки, видеокамеры и т.п.). Для тестирования всех остальных частей ПО есть (или будут) заглушки-имитаторы реальных устройств; но ведь в таком случае сам код, вместо которого вставляется имитатор, остаётся не протестированным до самого деплоя. Он конечно насколько возможно легковесный и мы конечно стараемся его как-то тестить, приволакивая железяки по отдельности прям в офис, когда это возможно. Но это всё как-то не систематизировано, "по ситуации", и ошибки случаются много чаще, чем хотелось бы. В общем, здесь бы тоже методологию нормальную какую найти.
>>905727Ох, это много чтива. Ну кое-что в электронном виде нашлось сразу, начинаю читать.Сразу вопрос: а это насколько актуально? Просто после двухдневного сёрфа создалось ощущение, что методология разработки ПО как область знания какая-то очень динамичная, постоянно новые инструменты, подходы и т.п. Мне вот в универике только про Водопад да CVS рассказывали, а это было-то всего несколько лет назад, а сейчас читаю, что это всё устаревшая тупиковая херня.
>>905735> Сразу вопрос: а это насколько актуально?Scrum/Kanban и "гибридная водопадная" применяются прямо сейчас в промышленном программировании (в т.ч. у нас в компании). Не целиком как в книжке, а практически применимые части, типа того, что я тебе расписал - в основе, по факту, Скрам. Новых методологий нет, по сути есть только допиливание напильником существующих 4-5 подходов: водопад - уже не применяется нигде, аджайл (спираль), гибридный водопад (итеративный), экстремальное программирование (PoC -> допиливание напильником до продукта, используется в стартапах). Скрамы, канбаны, скрамбаны и прочее такое - это варианты практической реализации аджайла и базовых принципов управления ресурсами (людьми, временем и железом). Всякие TDD, BDD, DDD - это методологии написания кода в рамках выбранной методологии процесса разработки.> Вот с тестированием тоже не везде ясно. У нас, понятно, много кода, связанного с контролем/управлением железом (датчики, движки, видеокамеры и т.п.). Для тестирования всех остальных частей ПО есть (или будут) заглушки-имитаторы реальных устройств; но ведь в таком случае сам код, вместо которого вставляется имитатор, остаётся не протестированным до самого деплоя. Он конечно насколько возможно легковесный и мы конечно стараемся его как-то тестить, приволакивая железяки по отдельности прям в офис, когда это возможно. Но это всё как-то не систематизировано, "по ситуации", и ошибки случаются много чаще, чем хотелось бы. В общем, здесь бы тоже методологию нормальную какую найти.Все ваши датчики/видеокамеры/движки выдают и принимают на вход сигналы определённой формы/формата. Что мешает сделать программные или хардварные аналоги, выдающие такие тестовые сигналы? Протокол-то наверняка известен. Плюс если движком управляет некий сторонний драйвер, то тестировать фактическое управление движком можно будет только в конце, на этапе испытаний, а для автотестирования использовать заглушку с интерфейсом, как у этого драйвера.>>905682-кум
>>905797>Протокол-то наверняка известен.Так точно, и если речь идёт о коробочке с ethernet/com/usb/... интерфейсом, то обычно так и делаем (хотя надо, конечно, делать не "обычно", а всегда).Сложность бывает в случае взаимосвязи разных устройств, ну например в простейшем случае управление охлаждением при обратной связи по термопаре; можно имитировать то и другое, но чтобы полноценно оттестить сам регулятор, нужна модель реального объекта, интегрирование уравнения теплопроводности и, в общем, пиздец зачастую вроде бы превосходящий сложность самой разрабатываемой системы. Наверное, другого пути и нет: либо полноценно всё моделировать, либо отлаживать прям в производственных помещениях с ноутбука (уродство, как по мне, жуткое). Что-то думаю может имеет смысл отдельный проект завести "программная модель сраных цехов", вот только никому кроме кодеров это не нужно напрямую.
>>905928> Что-то думаю может имеет смысл отдельный проект завести "программная модель сраных цехов", вот только никому кроме кодеров это не нужно напрямую.А чо бы и нет, можно кандидатскую замутить.
>>905928>Сложность бывает в случае взаимосвязи разных устройств, ну например в простейшем случае управление охлаждением при обратной связи по термопаре; можно имитировать то и другое, но чтобы полноценно оттестить сам регулятор, нужна модель реального объекта, интегрирование уравнения теплопроводности и, в общем, пиздец зачастую вроде бы превосходящий сложность самой разрабатываемой системы.Система диффуров для уравнения теплопроводности в общем-то хорошо обсосана в литературе, как и многое другео, что у вас используется. А без матановых моделей тут и не обойтись никак, хотя бы теоретические должны быть. Вы же на практике все граничные условия не сможете оттестировать, их проще смоделировать сначала, а потом просто подкорректировать под оборудование. Советую начать с поиска спецификаций на термопары и прочее оборудование, заказа их у производителя, если это не самопал.
>>904649 (OP)Готовь туза, маня.А если серьёзно, то судя по описанию твоей недоконторы ничего внятного не выйдет, так что можешь смело скипать всю хуиту которую тебе тут насоветовали и сделать щи попроще. Тимлид - это не менеджер, не скраммастер (читай лохотронщик), а хуйня застрявшая между двух миров, на которого скинули всю говно, вроде микроменеджмента, которое любому PMу выполнять западло да и не положено. С учётом же описания твоей конторы - ты просто тот на кого будут падать все шишки и кого будут ебать на всех собраниях из-за факапов, которые непременно будут и будут чаще всего не по твоей вине или вине твоей тимы пидаров. Поздравляю с новой должностью мальчика для битья.
>>905956А вот и ванги подъехали.Оп же сказал, что контора расширяется, значит бабло пошло. Руководство правильно делает, что вкладывается в бизнес, заморачивается автоматизацией.
>>905941 >>905944Резонно. Терморегулятор всё-таки очень простой пример, но всеобъемлющее тестирование наверное того стоит.>>905956>Готовь тузаДа как тебе сказать, я примерно это предчувствую, но весьма спокоен: запасные отходы в виде фриланса или уёбывания в ДСы вполне реальны и даже интригуют; но всё-таки ты пойми, хочется попытаться. Ну а вдруг выгорит. Интересно будет, думаю, в любом случае, даже и в туза разок.
