Здравствуйте, zfima, Вы писали:
SVZ>>Парное программирование полезно только когда надо "срастить" части программы, сделанные разными людьми. Вот тут они садятся вдвоем и быстренько все делают. И все. SVZ>>А то, о чем ты говоришь, решается другими средствами. SVZ>>Ведение документации, комментарии в коде, периодические доклады разработчиков о поддерживаемых ими частях программы.
Z>Станислав, может вы и правы. Z>Никогда не практиковал, хотя очень хотелось бы Z>Не практиковал — потому как в 5-6 фирмах, которых я работал, никто этого не хотел. Так же как TDD и т.д.
Z>Документация — в принципы, если только необходима.
Я с этим сталкивался в нескольких компаниях.
Это получается как необходимость. Документировались алгоритмы, описания конечных автоматов, архитектура серверов.
Самое сложное — поддерживать документацию в актуальном состоянии. Это получается только если состав разработчиков более-менее стабилен, т.е. те, кто принял решение вести документацию, остаются в коллективе. Если разработчики сменяются каждые полгода, то такие соглашения проживут недолго.
Z>Комментарии — после нескольких чисток становятся мусором
Только если никому не нужны. Опять же убедился, что хорошее комментирование кода коллегам нравится и они начинают тоже его применять.
Комментарии правятся одновременно с кодом.
Лучше всего получается, если сперва пишется комментарий (что собираешься сделать/получить) а потом набивается код. Тогда комментарии получаются дополнительным источником информации при CodeReview.
Z>Доклады? Ну было бы хорошо, но нету
На прошлой работе коллегиально решили периодически рассказывать о своих частях программы. Потому что были проблемы с ревью. Формальный ревью результатов не давал, а углубляться в код и выяснять правильность правок было слишком затратно по времени.
Z>Прямо начинаешь сомневаться — а кто то этим вообще пользуется?...
"Жить захочешь, не так раскорячишься" (с)
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, zfima, Вы писали:
Pzz>>1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.
Z>Ну, мы вообще производительность не измеряем никак.
Ну, измерите, а дальше что?
Z>Именно так. И почему то есть предпочтение, чтобы клиент вообще не знал, чем мы занимаемся.
Это — вопрос отношений между вашими sales и клиентом. Тонкая политика. Не лезте в это, это вне вашей компетенции. Целее будете.
Pzz>>3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.
Z>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много. Z>Думаю, что это является проблемой. Так как люди считают, что это лишнее (код, время)
Так их, ошибок, много или немного? У вас bug tracking-то есть? Если нет, заведите немедленно. И source control тоже заведите, если его до сих пор у вас нет.
Типичная норма для индустрии — одна ошибка на 50 строк кода. Если у вас их больше этого показателя, надо что-то делать. Если нет, не парьтесь. Все равно, сильно лучше ваш код не станет.
Pzz>>4 — что это значит?
Z>Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
В смысле, вы сидите надувшись и между собой не разговариваете?
Pzz>>5 — что это значит?
Z>Никто никак не расчитывает сколько времени возьмет что-то большое. Z>В конце не успеваем и выкидываем разную функциональность.
У вас слишком большие этапы. Планируйте разработку циклами размером 1-2 недели.
Pzz>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать. Z>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
Чтобы разработчики были в курсе задач друг друга, вовсе не обязательно делить одну клавиатуру на двоих.
Здравствуйте, zfima, Вы писали:
Z>Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам Z>Должно быть, наверное, по другому
На подхалимстве прочного авторитета не заработаешь.
За все время работы я ни разу не носил любимые майки начальника и не слушал его группы. Собственно, я понятия никогда не имел, какую музыку мое начальство слушало, а мои подчиненные слушали другую музыку чем я. Кроме как если разве я кого из них домой на машине подвозил — тогда у них выбора не было И мне это никогда не мешало.
Z>Кроме того, так, думаю кросс-функциональную команду не построишь
Что такое кросс-компилятор, я понимаю. А что такое кросс-функциональная команда?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Pzz>>>1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.
Z>>Ну, мы вообще производительность не измеряем никак.
Pzz>Ну, измерите, а дальше что?
Ну наверное, чтобы можно было бы пообещать заказчику сколько дров за периуд времени мы можем нарубить. Или наколоть
Когда ты покупаешь вещь, которая имеет некоторый перфоменс, тебе наверное хотелось бы знать сколько-чего она умеет делать за какое то время.
Z>>Именно так. И почему то есть предпочтение, чтобы клиент вообще не знал, чем мы занимаемся.
Pzz>Это — вопрос отношений между вашими sales и клиентом. Тонкая политика. Не лезте в это, это вне вашей компетенции. Целее будете.
Понял
Pzz>>>3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.
Z>>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много. Z>>Думаю, что это является проблемой. Так как люди считают, что это лишнее (код, время)
Pzz>Так их, ошибок, много или немного? У вас bug tracking-то есть? Если нет, заведите немедленно. И source control тоже заведите, если его до сих пор у вас нет.
Pzz>Типичная норма для индустрии — одна ошибка на 50 строк кода. Если у вас их больше этого показателя, надо что-то делать. Если нет, не парьтесь. Все равно, сильно лучше ваш код не станет.
Есть RTC со всеми вытекающими.
Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Pzz>>>4 — что это значит?
Z>>Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
Pzz>В смысле, вы сидите надувшись и между собой не разговариваете?
Да нет. Просто никто никому помогать не хочет. У каждого только своя узкая специализация и другого не хочет.
Pzz>>>5 — что это значит?
Z>>Никто никак не расчитывает сколько времени возьмет что-то большое. Z>>В конце не успеваем и выкидываем разную функциональность.
Pzz>У вас слишком большие этапы. Планируйте разработку циклами размером 1-2 недели.
Pzz>>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать. Z>>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
Pzz>Чтобы разработчики были в курсе задач друг друга, вовсе не обязательно делить одну клавиатуру на двоих.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам Z>>Должно быть, наверное, по другому
Pzz>На подхалимстве прочного авторитета не заработаешь.
Pzz>За все время работы я ни разу не носил любимые майки начальника и не слушал его группы. Собственно, я понятия никогда не имел, какую музыку мое начальство слушало, а мои подчиненные слушали другую музыку чем я. Кроме как если разве я кого из них домой на машине подвозил — тогда у них выбора не было И мне это никогда не мешало.
Z>>Кроме того, так, думаю кросс-функциональную команду не построишь
Pzz>Что такое кросс-компилятор, я понимаю. А что такое кросс-функциональная команда?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, zfima, Вы писали:
Z>>Как быть? Дать им всё завалить?
А>Можешь дать им завалить. А>Судя по всему у вас там программеров раз два и обчелся и потому наверное приходится заниматься мышинной вознейю. А>Можешь сменить работу где программеров побольше и где простора соответственно больш. А>У нас, к примеру, больше десятка команд. Скрам мастерами точно не все хотят быть А>и порой приходится искать кто бы взял на себя эту роль. А>Никакой магии в этом нету. При нормально поставленном скраме обычный девелопер А>имеет ровно столько же позможностей повлиять на процесс, А>как и скрам мастер. скрам мастер — это точно не пуп земли, даже в масштабах одной команды. А>Он ничего решает и никому не приказывает. Роль у него очень четкая и даже странно слышать, А>что об этой роли кто-то может мечтать и за обладание этой ролью приходится конкурировать
Хочу попробовать себя в качестве скрам мастера или другого Agile-мастера, только потому что есть желание улучшить/убыстрить/упорядочить процесс, не увеличивая человеческих ресурсов.
Думаю, у девелопера меньше способов повлиять да и многим из них это не нужно.
Не хочу быть пупом земли, приказывать и т.д.
Здравствуйте, zfima, Вы писали:
Pzz>>Ну, измерите, а дальше что?
Z>Ну наверное, чтобы можно было бы пообещать заказчику сколько дров за периуд времени мы можем нарубить. Или наколоть Z>Когда ты покупаешь вещь, которая имеет некоторый перфоменс, тебе наверное хотелось бы знать сколько-чего она умеет делать за какое то время.
Это не работает даже у Мелкософта. Обратите внимание, что они не выпустили не одного major release в заявленный срок.
Проблема в том, что производительность зависит от сложности задачи, а пока вы не погрузились в задачу с головой, вы не знаете всех проблемных мест. А поэтому, не можете с приемлимой точностью оценить сложность.
Исключение, если вы делаете стандартные, типовые, похожие друг на друга задачи. Например, клепаете веб-сайты по шаблону, пишете драйвера или клепаете формочки, похожие друг на друга. Но и то, предлетная область может подкинуть неожиданную подлянку.
Z>Есть RTC со всеми вытекающими. Z>Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Так сколько у вас ошибок на самом деле? И что такое RTC?
Pzz>>В смысле, вы сидите надувшись и между собой не разговариваете?
Z>Да нет. Просто никто никому помогать не хочет. У каждого только своя узкая специализация и другого не хочет.
Это — вопрос человеческих взаимоотношений. Процессом не лечится.
Здравствуйте, zfima, Вы писали:
Pzz>>Что такое кросс-компилятор, я понимаю. А что такое кросс-функциональная команда?
Z>Это когда все взаимозаменяемые, наверное Z>http://en.wikipedia.org/wiki/Cross-functional_team
Как говорит одим мой очень хороший знакомый, бывший когда-то моим начальником, есть два типа работы: ручку крутить и в высоту прыгать. Все взаимозаменяемы бывают только на работе типа ручку крутить.
Здравствуйте, zfima, Вы писали:
Z>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров. Z>И он ПОНИМАЕТ, что процесс отстой
Это очень много, 30 подчиненных на одного начальника. Должна быть какая-то иерархия. Скажем, у него в подчинении находится несколько старших программистов, а они уже возглавляют свои небольшие командочки.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Pzz>>>Ну, измерите, а дальше что?
Z>>Ну наверное, чтобы можно было бы пообещать заказчику сколько дров за периуд времени мы можем нарубить. Или наколоть Z>>Когда ты покупаешь вещь, которая имеет некоторый перфоменс, тебе наверное хотелось бы знать сколько-чего она умеет делать за какое то время.
Pzz>Это не работает даже у Мелкософта. Обратите внимание, что они не выпустили не одного major release в заявленный срок.
Pzz>Проблема в том, что производительность зависит от сложности задачи, а пока вы не погрузились в задачу с головой, вы не знаете всех проблемных мест. А поэтому, не можете с приемлимой точностью оценить сложность.
Pzz>Исключение, если вы делаете стандартные, типовые, похожие друг на друга задачи. Например, клепаете веб-сайты по шаблону, пишете драйвера или клепаете формочки, похожие друг на друга. Но и то, предлетная область может подкинуть неожиданную подлянку.
Z>>Есть RTC со всеми вытекающими. Z>>Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Pzz>Так сколько у вас ошибок на самом деле? И что такое RTC?
Система фирмы IBM. Чтото типа TFS микрософта.
Там и баг-трекинг, и Source control, и много чего заточенного под Agile — но всем этим мы не пользуемся
Pzz>>>В смысле, вы сидите надувшись и между собой не разговариваете?
Z>>Да нет. Просто никто никому помогать не хочет. У каждого только своя узкая специализация и другого не хочет.
Pzz>Это — вопрос человеческих взаимоотношений. Процессом не лечится.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров. Z>>И он ПОНИМАЕТ, что процесс отстой
Pzz>Это очень много, 30 подчиненных на одного начальника. Должна быть какая-то иерархия. Скажем, у него в подчинении находится несколько старших программистов, а они уже возглавляют свои небольшие командочки.
Да нет никакой особой иерархии. Я больше с ним на прямую работаю чем с кем-то кто типа мой "наставник".
"Наставник" получает задачу от начальника и дает мне. Ничего сам не делит
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Наверное, самая подходящее решение. Z>>У меня только нет опыта в этой отрасли. Z>>Но есть много мотивации
Pzz>Тогда от вас отмахнутся, как от надоедливого комара. Мотивация без опыта никому не нужна.
Блин, в полне возможно.
Наверное, надо изучить досконально чего нибудь, типа канбана, сделать презентацию, объяснить что к чему, показать почему это поможет и сделать симуляцию.
Здравствуйте, zfima, Вы писали:
Z>Система фирмы IBM. Чтото типа TFS микрософта. Z>Там и баг-трекинг, и Source control, и много чего заточенного под Agile — но всем этим мы не пользуемся
У него, небось, такой интерфейс, что проще удавиться, чем научиться им пользоваться.
Поставьте себе простой и понятный source control и простой и простой и понятный bug tracking. И начните уже ими пользоваться. У вас должны ВСЕ исходники проходить через source control (и никаких "пошли мне исходник по почте" или "запиши на флешку"), и абсолютно ВСЕ задания, как "сделать такую-то фичу", так и "починить такую-то багу" проходить через bug tracking. И информация там должна быть исчерпывающей и актуальной. В т.ч., описание задания, на кого оно назначено, логи в source control'е и т.п. Для начала этого более чем достаточно, с точки зрения организации процесса.
Я думаю, необходимость внедрения этих двух инструментов будет гораздо проще обосновать, чем всякие там новомодные слова-методологии.
Здравствуйте, zfima, Вы писали:
Z>Да нет никакой особой иерархии. Я больше с ним на прямую работаю чем с кем-то кто типа мой "наставник". Z>"Наставник" получает задачу от начальника и дает мне. Ничего сам не делит
Невозможно одному человеку иметь 30 человек в непосредственном подчинении. Если с каждым в день надо хоть раз поговорить, это получается по 15 минут на человека, если только этим и заниматься. Прям как у участкового терапевта, то-то они такие вздрюченные.
Разумный вариант организации: проект разбивается на несколько относительно изолированных подзадач, на каждую назначается ответственный, ему в подчинение даются несколько программистов. Главный программистский начальник работает напрямую только с этими ответственными, вопросы взаимодействия между частями проекта утрясаются ответственными за эти части между собой, а вопросы реализации — уже между ответственными и подчиненными ему программистами. В небольших группах сразу и коммуникация людей между собой наладится.
И очень важно, чтобы никто через чью-то голову не пытался работать. Скажем, главный начальник не должен напрямую командовать программистами, через голову ответственного за подзадачу, и программисты не должны к нему лезть со своими повседневными вопросами.
Здравствуйте, zfima, Вы писали:
Z>Блин, в полне возможно. Z>Наверное, надо изучить досконально чего нибудь, типа канбана, сделать презентацию, объяснить что к чему, показать почему это поможет и сделать симуляцию.
Нет. Если бы у меня в группе завелся какой-нибудь птенец неоперившийся, который в бою не бывал, а командира учит, я бы предпринял осмысленные усилия, чтобы направить его энергию в мирное русло, а если бы это не помогло, постарался бы от него избавиться. Это потому, что я добрый, либеральный и демократичный, и вообще, людей расстраивать не люблю. Другой бы на моем месте сразу бы уволил нахрен, чтобы не баламутил команду.
Z>Тогда реально получить эту тему?
Я привержнец той теории, что авторитетом среди людей пользуются граждане, которые могут в мирной жизни дать дельный совет, в нужный момент (а не бегать вокруг и жужжать со своими непрошенными предложениями), а в бою прикрыть спину.
Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Система фирмы IBM. Чтото типа TFS микрософта. Z>>Там и баг-трекинг, и Source control, и много чего заточенного под Agile — но всем этим мы не пользуемся
Pzz>У него, небось, такой интерфейс, что проще удавиться, чем научиться им пользоваться.
Pzz>Поставьте себе простой и понятный source control и простой и простой и понятный bug tracking. И начните уже ими пользоваться. У вас должны ВСЕ исходники проходить через source control (и никаких "пошли мне исходник по почте" или "запиши на флешку"), и абсолютно ВСЕ задания, как "сделать такую-то фичу", так и "починить такую-то багу" проходить через bug tracking. И информация там должна быть исчерпывающей и актуальной. В т.ч., описание задания, на кого оно назначено, логи в source control'е и т.п. Для начала этого более чем достаточно, с точки зрения организации процесса.
Pzz>Я думаю, необходимость внедрения этих двух инструментов будет гораздо проще обосновать, чем всякие там новомодные слова-методологии.
Здравствуйте, zfima, Вы писали:
Z>Думаю, у девелопера меньше способов повлиять да и многим из них это не нужно.
Смотря что это за девелопер и как к нему относится команда. Z>Не хочу быть пупом земли, приказывать и т.д.
Без этого никак.
Здравствуйте, zfima, Вы писали:
Z>Есть RTC со всеми вытекающими. Z>Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Чище было бы. Но вы бы тратили больше времени на разработку и делали бы меньше функциональности. Грубо говоря, за то же время вы бы делали в 1,5-2 раза меньше, чем раньше (зато с меньшим количеством багов).
С большой вероятностью у вас там проблемы в первую очередь в архитектуре (или отсутствии оной). Вот как раз чистка и исправление архитектуры могут кардинально улучшать ситуацию и требовать гораздо меньше времени. Правда в этом случае тесты скорее даже мещают, чем помогают (потому что становятся неактуальны часто).
Что интересно, с большой вероятностью именно документация была бы полезнее в данном случае. Часто причиной регрессии бывает нарушение неявных контрактов метода. Документация делает контракты явными. И при изменении контракта нужно проверять пользователей методов. А еще документация очень хорошо выявляет артефакты архитектуры. Банальный вопрос "а как контракт метода относится к контракту класса" заставляет о многом задуматься.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Блин, в полне возможно. Z>>Наверное, надо изучить досконально чего нибудь, типа канбана, сделать презентацию, объяснить что к чему, показать почему это поможет и сделать симуляцию.
Pzz>Нет. Если бы у меня в группе завелся какой-нибудь птенец неоперившийся, который в бою не бывал, а командира учит, я бы предпринял осмысленные усилия, чтобы направить его энергию в мирное русло, а если бы это не помогло, постарался бы от него избавиться. Это потому, что я добрый, либеральный и демократичный, и вообще, людей расстраивать не люблю. Другой бы на моем месте сразу бы уволил нахрен, чтобы не баламутил команду.
Z>>Тогда реально получить эту тему?
Pzz>Я привержнец той теории, что авторитетом среди людей пользуются граждане, которые могут в мирной жизни дать дельный совет, в нужный момент (а не бегать вокруг и жужжать со своими непрошенными предложениями), а в бою прикрыть спину.
Pzz>Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов.
Кто же тогда становится Ageile-технологом? Менеджеры и т.д?
Помоему, менеджер не захочет им стать, выглядит типа downgrade. Нет?
Или выпускники менеджмента?
И вообще, есть тут Agile-мастеры, которые могут рассказать, как стали таковы?
