Первое, с чем необходимо было разобраться – учет и планирование рабочего времени. Заказчики и начальство постоянно заявляли о затягивании сроков по разработке, часто подымались вопросы о том, что программисты ничем не занимаются вовсе. Одним словом, ситуация сложилась более чем критической.
Тем не менее, team leader принял решение о переводе разработки на Scrum/Agile, что, как выяснилось через некоторое время, принесло свои результаты. Вот список изменений, которые были внесены в процесс разработки:
- Спринты наше все. В буквальном смысле все. Все время разработки разделено на равномерные отрезки, которые в нашем случае длятся две недели – наиболее удобный для нас промежуток времени. Время спринта может коррелироваться в соответствии со сложностью и объемом исполняемого проекта. Но в последнее время длительность спринта так и не удавалось сократить на срок менее двух недель. От себя могу добавить, что методика разбиения времени разработчиков на спринты очень удобна и программистам и начальству, поскольку первые получают определенный список задач, ТЗ которых не изменяется на протяжении спринта, а вторые видят определенный результат после окончания итерации разработки.
- Среди разработчиков был назначен Scrum Master – один из разработчиков, на широкие плечи которого был возложен тяжелый груз общения из заказчиком, а также проведения ежедневных Daily Scrum Meeting. Теперь мы смогли более сконцентрироваться на разработке, а не на выяснении отношений со свирепыми пользователями, объясняя им, почему мы не будем решать ту или иную задачу здесь и сейчас.
- Daily Scrum Meeting – очень полезные штуки. Всего за 10 минут рабочего времени каждому нужно рассказать о том, что он сделал вчера, что получилось, а что не получилось и что он будет делать сегодня. В результате у сотрудников возросла мотивация, процесс разработки стал более интересный и качественный, поскольку можно оперативно получить помощь или критику (обоснованную) от более продвинутых коллег. Митинги проводим даже в том случае, когда один из разработчиков опоздал или в командировке (используем Skype в качестве скринкастера или звонилки). Буквально за первую неделю практики Daily Meeting наш коллектив стал более дружественный и сплоченный.
- Следующий пункт – разделение задач по категориям. В каждом проекте наши задачи делятся на категории.
- Идеи. В эту категорию попадают задачи-хотелки пользователей, у которых нету ТЗ и которые мы возможно даже не будем делать(из-за абсурдности самой задачи, или присутствием в той или иной конфигурации стандартного функционала, решающего проблему).
- Кандидаты на реализацию. Задачи, которые точно будут реализованы, но не имеют точно сформулированного ТЗ.
- Необходимо обсудить. Задачи, которые возможно будут реализованы, но хотелка пользователя непонятна для разработчика.
- Технические истории. В этот раздел попадают задачи программистов для программистов, задачи – результат выполнения которых не будет виден конечному пользователю (библиотека, оптимизация запроса).
- Product Backlog. Собственно задачи с четким ТЗ, которые точно нужно выполнить или коммерческие задачи, за которые хорошо платят.
- Каждая задача оценивается в story points (в количестве дней, которые разработчик потратит на выполнении задачи). Если задача занимает пять или больше дней – ее необходимо разбить на более мелкие задачи и желательно распараллелить мелкие задачи между несколькими разработчиками, для увеличения уровня совместного владения кодом. Количество времени, необходимое для решения задачи ставят сами разработчики, после завершения очередного спринта осуществляется переоценка задач в Product Backlog на следующий спринт, чтобы сориентировать заказчика на сроки выполнения проекта.
- Каждый спринт начинается из Planning meeting, на которым мы вместе с Product Owner (иными словами заказчиком) набираем задачи на 36 story points (4 разработчика на 9 дней разработки). Главная задача Planning meeting состоит в том, чтобы заказчик увидел объем работ, который будет выполняться в последующий отрезок времени и продукт, который он получит в результате выполнения намеченных работ.
Следующей проблемой, которую нам предстояло решить – побороть то количество ошибок, которое возникало в следствии увеличения сложности проектов и низкого уровня совместного владения кодом, проще говоря, одному разработчику было сложно разобраться с кодом, написанным другим разработчиком. В результате мы предприняли следующие меры:
- Переход на стандарты написания кода от самой 1С. Кому интересно почитать можно здесь – очень полезная методичка, в которой описано как и что правильно делать, а что делать нельзя. Также там поднимаются вопросы о производительности кода, оптимальности работы запросов, уменьшению количества клиент-серверных вызовов и многое другое, что будет полезно и начинающему программисту и человеку с большим опытом. Каждый наш разработчик потратил определенное количество времени на изучение материала, а сейчас, мы повсеместно применяем его на практике, как во внутренних проектах так и при разработке под заказ.
- Code review. Думаю, это просто необходимость в современных проектах. При написании обработок, где количество строк кода исчисляется тысячами без него не обойтись. Часто удавалось отловить злую ошибку влияющею на производительность работы всей системы еще до внедрения у клиента. В нашей команде это стало стандартом – проверять код написанный коллегой и по возможности проводить рефакторинг или оптимизацию. Да, возможно стоимость разработки возрастает, но взамен мы получаем более стабильный код, меньшее количество ошибок, быстрый тем роста новых сотрудников.
И еще несколько слов о инструментах, которые помогают нам справляться со всеми нововведениями.
http://realtimeboard.com/ — онлайн доска, которая заменяет нам обычную. На ней мы рисуем наш Burn down chart (очень важный элемент в процессе разработки, поскольку позволяет увидеть, успеваем мы с проектом или нет), разные алгоритмы, или просто комиксы, связанные с разработкой :).
http://www.redmine.org/ — опенсорсный дашбоард в котором мы и ведем все наши проекты. Удобно с точки зрения возможности подгона под наши потребности к процессу разработки с помощью разнообразных плагинов и настроек. Здесь есть и проекты, и статусы задач, и чек-листы, и многое другое.
http://www.kayako.com/ — для улучшения работы службы поддержки пользователей. С помощью программы регистрируется каждое обращение в службу поддержки (письмо по электронной почте, звонок или персональный визит).
Вот и все. Но в статье описана только вершина айсберга. А как вы, уважаемые читатели, работаете над повышением качества разработки и жизни самих разработчиков внутри своей команды?
Статья опубликована также на сайте avtomat.biz
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Code review — и как, вы делаете coderewiew? Можно подробней описать инструментарий?
Экстремальное программирование (точнее — его элементы) действует ;). Спасибо за публикацию, ибо реальный опыт всегда интересен
В свое время мне очень помогла давно прочитанная книга 1982 года издания «Искусство тестирования программ» автор Майерс Г. — просто и понятно. Кому интересно — вот ссылка .
автор — ты русский?
(1) Проблема в том, что инструментария подходящего не нашли. Код проверяем «вручную» на соответствие стандартам.
(3) За книгу спасибо!
(5) к redmine есть плагин coderewiew, ну и 8.3 выгрузка конфигурации в файлы + git.
(7) Да, 8.3 ждемс с нетерпением, очень не хватает контроля версий.
(8) я вас разочарую пока еще в 8.3 альтернативного контроля версий нет, судя по последним беткам. Ну а что с учетом зазеркальных обещаний, то вряд ли там что-то для альтернативных систем будет сделанно. Не верю, я в 1С в этом плане.
(4) prog1c8, Ваш вопрос имеет отношение к статье?
(10) pbazelyuk, прямое
оооочень интересно, спасибо
пара вопросов:
— какого рода проекты у вас? можно воспользоваться вот это классификацией 🙂
я почему спрашиваю, agile не заведется под «неподготовленного» заказчика, нежелающего ничего слышать..
(4) коллеги, методики западные. Устоявшего перевода нет и, видимо, не будет. Это не более, чем унификация терминологии. Если бы автор перевел все это по своему усмотрению, то получился бы рассинхрон со всей остальной инфой в инете.
(11) romansun, согласен.
но вот такие фразы (например)
————
…. Тем не менее, team leader принял решение о переводе разработки….
————
говорят что слова из разных языков перемешанные в одном тексте — это не изза их непереводимости, причина в чем то другом…
конечно мы не на уроке русского языка и культуры общения, но все же автор написал статью для общего обозрения, и надо читателей как то уважать — используешь понятие из другого языка, ну возьми ты его в кавычки и дай расшифровку, чтобы читателю ясно было о чем речь.
(11) прочитаю статью на хабрахабр и тогда отвечу точно по классификации (вечером :)).
(13)
А по мне имхо, написание «team leader», а не «тимлид» — гораздо большее уважение к читателям.
(5)
Рефакторинг, надо больше рефакторинга!
Может отдельной статьей поделитесь опытом рефакторинга именно в 1С.
Какие приемы в-основном используются, как они выполняются, учитывая специфику 1С-языка и ее программной модели.
Какие технические средства хотелось бы иметь для его облегчения.
А то кроме «extract method» дело дальше не двигается.
Интересный опыт. Странно как вы до этого работали без таких тривиальных вещей?
(16)
Вам действительно странно, как 99% одинэсников работают или так, потроллить ?
Давно хотел почитать про agile, думаю, пора. Странно, что такой небольшой франь, 4 человека, и все так серьезно) Какого рода проекты у вас? Насколько крупные?
(18) О проектах напишу отдельный комментарий, только вечером 🙂
Спасибо за статью. Почерпнул полезные вещи.
(18) gr0ck, коллега наверное ошибся. У нас такая структура:
1 — ген. директор
1 — ведущий программист
1 — старший программист
1 — программист
3 — внедренца/поддержка
2 — системных администратора
2 — веб-разработчика
Проекты разные. Тот что является основным — пиковая нагрузка 150 пользователей онлайн, 30-40 тыс. документов в месяц.
(21) Статья именно об организации труда людей, которые занимались активной разработкой под 1С (не админы и не консультанты).
Вот уж чего точно на инфостарте не хватает 🙂
Этого хлама навалом на хабре и прочих ресурсах, можно только направление изменить на 1С, а не пхп, ява и т.д.
В вашей статье не обнаружил ничего полезного и интересного.
Выложили бы хоть пару скринов, а то говорите о каких то вещах, которые понятны только вам.
Привели бы пару примеров из жизни, например вы пишете:
Но объяснять то все равно надо. Тем более таким путем — команда теряет навыки общения с людьми. Люди считают что их игнорируют.Этот ваш Scrum Master — не может знать 100% проектов, так что он я так понимаю в любом случае перенаправляет все консультационные звонки программистам. В итоге время уходит на это точно так же.
А не боитесь ли вы все завязывать на одном человеке? А если он заболеет? Уволится?
Как вы ставите приоритеты задачам? На основании каких данных? Что вы делаете в случае не предвиденных авралов?
В целом — статья ни о чем. Очередной обзор софта 🙂 Извините, но этого хлама везде полно.
Расскажите хоть как вы оцениваете время и на сколько в среднем проградываете? Я например беру время, за которое я могу теоретически сделать обработку, умножаю на четыре и говорю клиенту это число дней, с приставкой «от».
У вас нету по ходу бухгалтерии на поддержки, при чем измененной, мы так раз, совсем недавно только тем и занимались, что обновляли бухгатерию всем клиентам, на остальное тупо времени не хватало и ресурсов. Мы уже просто сидели и смеялись. Вот это сюрприз от 1С, после которого, две недели указанные вами — не понятно откуда взяты. А акции вы никогда ночью не делали? Ну просто потому что клиенту захотелось 🙂
Я это все к чему — мы работаем в той сфере бизнеса, где порядок, это роскошь. Тут не реально строить планы и какие то перспективы. Ты не можешь крупному клиенту просто так сказать — «друг иди лесом, у меня план расписан на две недели», ибо он пойдет лесом и найдет другого, который сделает это тут и сейчас.
Поэтому хотелось бы почитать статью о том, как это происходит РЕАЛЬНО, а не эту выдержку из любой книги по тайм мэнэджмэнту или статьи на хабре.
Ух я наваял 🙂 Просто этого «добра» в последнее время — немерянно.
Сори, если что. Ничего личного.
Ну что, ничего нового, все давно известно! Никакой революции в статье нет!
(23)
Единственное, с чем соглашусь — побольше жизни. В принципе про скрам и всё такое прочитать можно везде. А вот про скам и 1С на реальных примерах — нигде.
В остальном — не согласен :). Подразделения it-бухгалтеров не относятся к проектной разработке никаким боком. Это техподдержка, саппорт… Разные направления работ, разные подходы.
В 1С мире есть софтварные фирмы и их заказчики, у которых с порядком более менее вменяемо. Они вполне используют разные вумные методики.
(23) DitriX, для консультационных вопросов есть первая линия поддержки в kayako. Если так случилось, что поддержка не справилась, тогда переводят обращение на программистов.
(26) а как они объясняют не типичные вопросы. Вот напимер у нас есть клиент, который любит акции, но его персонал вечно забывает как их делать. Инструкции не помогают. Они страхуются и звонят программисту (мы тоже аутсорсингом занимаемся). Вот вопрос, как ваша линия консультаций может ответить на такие специфические вопросы? Или их «гоняют» по всем доработкам всех клиентов? 🙂
(25) вот когда вы сможете людям объяснить, что задним числом ничего делать нельзя, тогда можем говорить про порядок в найшей сфере. До того момента, пока делаются костыли в ральных бизнесс процессах (ч/б бухгалтерия, вначале отдам товар, потом сделаю накладную, вначле продам, потом приход), то они отражаются и в нашей работе.
1С решили не плыть против течения и замутили РАУЗ. Почему? Если все было бы отлично и красиво, то обычный партионный вполне себя оправдывал (по большей части).
Я это все к тому, что мы себя тоже так вначале «обманывали», типо у нас все по плану, а этих 10% (потом 20, потом 90%) ситуаций которые не вписываются в график, запланированный ранее, то это всего лишь «ньюансы».
(26) Не возникает ли у вас такого? В общем поделитесь опытом. Нас интересует кухня, а не готовое блюдо.
(27)
Я так понимаю, у вас в основном поддержка? В таком случае, да, эта статья не про вас 🙂 Мы вообще от темы публикции ушли в разговоры за жизнь 1С-ную… Моё мнение — я бы уходил из таких контор. Вот реально. В таких местах вы *всегда* априори it-бухгалтер.
У меня несколько коллег ушли вообще из 1С именно по причине желания работать программистами (архитекторами, РП и пр.), а не бесконечно работать за пользователей бухгалтерами и расчетчиками зп.
В проекте, где работаю я, заднего числа, к счастью, почти нет. Ибо происходит ежедневное «закрытие дня» и править в прошлом просто так нельзя в принципе 🙂
Счетчик, как в такси, включается. 20 минут в месяц (? или в неделю… не помню) бесплатно, остальное — по расценкам разработки. Счета по итогам месяца помогают справляться с неспособностью читать инструкции. Это реальный пример из жизни в работе одной отраслевой «1С:Бла-бла-бла». Но для такой жесткой манеры работы у вас должны быть
железные яй..эээ… очень крутая софтина, на которую клиенты молятся и крутые спецы.Не поверите, но это тоже планируется. В мире разработки софта такое везде и во всех странах. И давно. Ничего нового. Просто мы в 1С (да и в целом, по стране) реально отстали в методиках управления. Как бы пафосно и приторно по-западному это не звучало. Управление программными проектами, управление эффективностью, управление рисками, управление прочей лабудой — это всё описано и сформулировано. Причем именно для разработки софта.
(27) DitriX, поддержка в состоянии решить такие вопросы.
Если у клиента аврал или надо на «вчера», тогда такие задачи оплачиваются с множителем х2-х3 от нормальной стоимости.
(28) та нет, в основном у нас именно разработка, и с бухгалтерией мы вообще практически не работаем. Только тогда, когда выходит пачка обновлений и все фирмы только этим и занимаются.
В основе нашей работы лежит все то, что касается управленческого учета, а не бухгалтерского. Бухгалтер у нас толковый только один. Я же до сих пор путаю дебит и кредит 🙂 Так что не обязательно быть it-бухгалтером, с таким же успехом можно быть it-аналитиком, it-«он знает все, давайте спросим у него, зачем читать инструкции и экономику в 8 классе я прогулял».При этом за это очень не мало платят.
Не поверите — платят, и даже не парятся (хотя мы берем в среднем на 30 — 50% больше чем франчи по городу). Просто люди знают — к нам когда не обратись, мы всегда готовы сделать. Даже в час ночи. И даже не абы как, а вполне нормально.
Так что дело не в оплате, а в подходе и в решении таких случаев, про что мне и интересно узнать.
Т.е. есть план на две недели, и вот такой аврал, надо срочно сделать.
Как в этом случае двигаются сроки, как потом сводятся концы с концами? Или в эту неделю заложено 4 дня резерва?
(30) та что вы с этими ценами заладили. Та пусть хоть х10 будет множитель. Вопрос в том — как это сказывается на вашей структуре? Т.е. понятно что поработав ночью, я уже днем буду спать. А теперь я выспался днем — ночью спать не буду хотеть. Короче, что бы прийти в адекватное состояние, после одной рабочей ночи, надо минимум 3 — 4 дня.
Вот как вы с такой ситуацией разбираетесь?
(31) DitriX, для таких ситуаций закладывается 15-20% рабочего времени, хотя это время еще используется, если задачу оценили не правильно. В том случае, если ничего не случилось и осталось время, выполняются технические или другие приоритетные задачи.
Есть еще дополнительные руки — поддержка, она может обновить конфигурацию и что-то дописать не шибко сложное, если уж все так плохо.
(31) DitriX, на практике, такое случалось 3 раза.
Первый раз, при внедрении УТ в 2010г., месяц работали без сна;
Второй раз, начало лета 2011г., при неудачном обновлении УТ;
Третий раз, начало лета 2012г., так же неудачное обновление УТ.
После этих неудач, мы внедрили методику поэтапной разработки. Начали всегда прорабатывать чек-листы, добавились обязательное совместное владение кодом. Для очень сильно измененных конфигураций использовали статьи: и . Например, чек-лист для УТ11 у нас составляет около 1000 позиций. При обновлении УТ11 в конце лета 2012г., было выявлено всего 3 ошибки, которые не попали в чек-листы, одна из них была зарегистрирована на партнерском форуме, так как являлась ошибкой конфигурации.
Ждите, если найду время, то разрожусь статьей с применением ТОС, почему все должны на проектах работать так же как и автор публикации.
(17) orefkov,
Причем тут троллинг?
Возможно мне повезло больше остальных и мы работаем в более или менее нормальных условиях. Но работать без инструментов управления проектами или баг-трекинга это ужасно особенно для больших команд.
(33) pbazelyuk, покажите реальные примеры чек-листов хотя бы десятую часть.
(0) Скринов не хватает, примеры реальные спринтов, как в redmine происходит распределение, какие фильтры стоят, какие настройки/плагины и т.д. Пользуетесь ли таким понятием в redmine как резолюция для задачи, какой у вас workflow настроен для «фичи»/»задачи»/»ошибки».
можно расшифровать, инструементы, как на практике вы владете кодом и т.д. и т.п.
Как у вас чек-лист обновляется, есть ли связь между закрытой задачей и автоматическим добавлением в чек-лист? Как фильтруете чек-листы по подсистемам, какими средствами формируется справка, где видна история разработки/доработки например для документа/справочника/подсистемы , зависимость доработки на подсистему или документ … ?
(36)Вот например скриншот нашего текущего спринта
Статусы в задачах
Версии —
Чек листы ведутся в google docs (предоставить на всеобщее рассмотрение не могу). Чек лист для каждой задачи подкрепляется через wiki-страницу.
Совместное владение кодом в нас подразумевает следующее, каждый из членов команды должен в любой момент продолжать писать код после своего коллеги. Сначала пробовали достигнуть эффекта парным программированием, но код-ревью + внедрение стандартов написания кода ( намного эффективней. Спец инструментов (которые удобно использовать в 1С так и не нашли).
Версии внешних обработок/отчетов как ведете?
(38)Все обработки хранятся на центральном хранилище (сервер разработки).
Вот пример версии Версия = «2.01.42»;
Первая цифра — количество изменений в ядре обработки (изменение принципа работы или логики обработки).
Вторая цифра — значительные, но не масштабные изменения (например перерисовали форму, или макет отчета).
Третья цифра — количество мелки изменений (вплоть до опечатки в заголовке обработки).
После прохождения всего цикла (планирование, разработка, код-ревью, тестирование) разработчик изменяет версию обработки, а в справку (она обязательна к каждой обработке) вносит информацию о изменениях, которые он внес, например:
2.01.43 — изменил заголовок с «супер обработка» на «супер мего обработка».
После внесения изменений нужно посмотреть изменил ли ты самую свежую версию (обычно Сравнение/Объединение). Если все ок — подключить обработку на продакшен и поместить в файловое хранилище и сказать коллегам что вот, я внес мего изменения.
П.С. Если честно очень не хватает контроля версий. Очень много надежд на 8.3.
(39) спасибо за статью!
на счет троллей сочувствую, их расплодилось много…
(39) попробуйте svn/git/bzr использовать для хранилища внешних обработок очень удобно, для мажорных версий можно использовать тэги , а минорные видны сразу по истории разработки.
Питаете прям нездоровую веру в светлое будущее альтернативного контроля версий и 8.3 :). 1. Вряд ли будет пакетная выгрузка/загрузка для обработок/отчетов.
2. В 8.2 модуль формы выгружался, теперь форма во внутреннем представлении выгружается вся вместе только без напильника от этого никакого толку, считай то же самое что и v8unpack.
3. У вас есть хранилище, попробуйте выгрузите cf в xml, потом обратно из xml в cf и сравните с хранилищем, роли вас удивят…
(31)
Так что дело не в оплате, а в подходе и в решении таких случаев, про что мне и интересно узнать.
Т.е. есть план на две недели, и вот такой аврал, надо срочно сделать.
Как в этом случае двигаются сроки, как потом сводятся концы с концами? Или в эту неделю заложено 4 дня резерва?
Т.е. понятно что поработав ночью, я уже днем буду спать. А теперь я выспался днем — ночью спать не буду хотеть. Короче, что бы прийти в адекватное состояние, после одной рабочей ночи, надо минимум 3 — 4 дня.
Вот как вы с такой ситуацией разбираетесь?
Очень, очень круто, что у вас такой авторитет и кредит доверия!
В целом, считается хорошей практикой, когда разработчик задействован максимум на двух задачах. Причем, одна — основная, вторая — вторым номером.
Понятно, что в этот период разработчик не должен заниматься еще тем, этим, вот тут, вот там, и еще чуть чуть у тети Вали в зарплате.
Разработчик вообще не должен заниматься саппортом. Это работа других подразделений. И да, я прекрасно понимаю, что далеко не везде есть эти подразделения.
И конечно, никой ночной работы быть не должно :D. 8 часов рабочий день, если только он у вас официально НЕ ненормированный. )))
Возможно, имеет смысл расширить чуть штат, особенно учитывая, что вас, как фирму, ценят.
(42) Проблема в том, и наше спасение, что мы закрепляем за фирмой одного человека (минимум) и он работает с этой фирмой. Т.е. мы делим не по проэктам, а именно по фирмам. Таким образом — на все вопросы одной фирмы — способен ответить только этот человек. И эта фирма знает, что при любой проблеме — она звонит ему и он все объяснит (я повторяюсь, что бухгалтерией мы вообще не занимаемся, только редкие обновления, когда уэ очень просят).
И каждый наш программист-аналитик — является чуть ли не советником директора, так как с помощью знания программной логики — он может сказать еще на этапе зачатка идеи о том, как ее можно и нужно реализовать.
Это очень важно, так как вам могут сказать — сделай нам отчет по остаткам с ценами. Не зная ситуации в этой фирме — вы сделаете. Но если бы вы были там и понимали суть проблемы, то вы бы поняли, что этот отчет их никак не спасет. В реалии у них сверка взаиморасчетов с поставщиками, у них партионный учет и расчет, почему-то, они делали не по партиям закупки, а брали какой то левый отчет, который выводил им количество проданых пар и цену по типу цен и расчитывались с поставщиком. В итоге — бешеный перекос себестоимости и как следствие — валовой прибыли.
И они думали что построив отчет по остатками с ценами они смогут понять, где у них перекосы. Ясное дело что они бы не поняли.
Это я к чему:
Если вы говорите про 1С-кодеров, то я согласен с вами, это по сути студенты, начинающие или ежи с ними. Тут да, они могут только кодить под надзором.
Но если вы говорите Разработчик , то тут я с вами не согласен. В этом и принципиальное отличие 1С программистов от программистов других областей, ибо 90% времени мы тратим на понимание и изыски — как лучше, и только потом пишем код (я ни в коем случае не говорю что в других языках на понимание времени не тратится, однако 1С тем и уникален, что разработчик является и дизайнером, и программистом, и аналитиком, и козлом отпущения для тупых тёть). И разработчикам как воздуху необходимо общаться с людьми, иначе они никогда не научатся ничему, кроме кодинга в 1С. В других фирмах (не 1С) есть отделы дизайна и GUI, а вы когда то обращались к дизайнерам, что бы они вам сказали где лучше кнопку разместить и как обозвать вот это поле? Я сомневаюсь.
Я просто столько видел крутых обработок, но мертвых. Идея хорошая, но то как она реализованна — это жесть. Т.е. программист писал для программиста. Почему? Так он других людей в глаза не видел 🙂
ИМХО…
(43)
ну чо, я согласен полностью. Наша 1С-ное подразделение тоже на 75% такое. Человек закреплен за парой фирм. Да так все работают, по сути.
только это называется саппорт
Он не имеет к разработке никакого отношения. Терминология, что 1С-ник на поддержке — это разработчик, а собственно сам разработчик — это просто студент-кодер некорректна.
1С-ник на поддержке это именно саппортный работник. К разработке конфигураций с нуля или подсистем с нуля такая деятельность отношения не имеет. Это другие знания, другие навыки, другой опыт. Общая только платформа 1С.
Просто так вышло, что 80% 1С-ников — это именно саппортеры. Ибо возможность создавать конфы с нуля имеют весьма немногие коллективы.
Те же, кто создает 1С-ные продукты на продажу — очень часто имеют классическую структуру обычной софтварной фиры. Все эти джуниоры, сеньоры, ПМ-ы, аналитики, тестеры и прочие и прочие.
Статья понравилась. Организация процессов разработки конечно не нова, но реальный опыт всегда интересен!
(3) fomix, действительно интересная и полезная книга
В большинстве случаев именно выделение специального сотрудника спасает положение если вдруг что-то пошло не так. Конечных пользователей выводит из себя когда каждую неделю меняется человек, который настраивает им 1с-ку или пишет для них отчет. Еще больше их бесит когда пришедший «новый» программист постоянно звонит в офис и спрашивает: а это куда? а почему здесь сделано так? кто и зачем сделал данную х..ню. В большинстве случаев при разработке средних или сложных систем приходится делать одно ,а получается ,как ни банально, другое «Видите ли бухгалтер представляла себе конечный результат по другому :(((» И неважно что подчас приходится по несколько часов сидеть на их собраниях и доказывать, объяснять, что так будет лучше проще, что нельзя все на свете автоматизировать (до чего же много людей любящих нажать одну кнопку и программа все сама за Них сделает :)))). Поэтому основным критерием при разработке и продвижению программного продукта на самом деле является правильно построенное общение, а его как раз таки проще и нужно налаживать только с постоянным сотрудником, выделенным для этой фирмы.
И не важно, что мы обратились к вам таким уверенным со своей проблемой, да мы знаем, что это трудно, да мы платим деньги за решение этой проблемы, да мы хотим нажать одну кнопку, пускай 2 но не десять и увидеть результат, а в результате высиживаем на дурацких совещаниях, где нам пытаются доказать, что это невозможно и сидишь на этом совещании, тратишь время и все заканчиваеться фразой «а кому сейчас легко», а потом еще берет наш консультант по 10 раз на дню заворачивает ваш код написанный на коленке (о как я ненавижу хранилище), без всяких правил форматирования, с запросами в циклах (при возможности решения задачи одним запросом) и т.д. Результат: горло охрипшее, спать хочеться, но вроде работает все.
p.s.: простите крик души, недавно побывал со стороны консультанта, и теперь на фразы «совещания, так будет проще (для кого главнй вопрос), одну кнопку сделать нельзя» у меня аллергия.
Согласен с prog1c8 по поводу стиля изложения.
Оперировать жаргонами,известными узкому кругу лиц,наверное не айс.
Как говорится-тема сисек не раскрыта
Интересная и достаточно познавательная статья.
(43)
И каждый наш программист-аналитик — является чуть ли не советником директора, так как с помощью знания программной логики — он может сказать еще на этапе зачатка идеи о том, как ее можно и нужно реализовать.
Это очень важно, так как вам могут сказать — сделай нам отчет по остаткам с ценами. Не зная ситуации в этой фирме — вы сделаете. Но если бы вы были там и понимали суть проблемы, то вы бы поняли, что этот отчет их никак не спасет. В реалии у них сверка взаиморасчетов с поставщиками, у них партионный учет и расчет, почему-то, они делали не по партиям закупки, а брали какой то левый отчет, который выводил им количество проданых пар и цену по типу цен и расчитывались с поставщиком. В итоге — бешеный перекос себестоимости и как следствие — валовой прибыли.
И они думали что построив отчет по остатками с ценами они смогут понять, где у них перекосы. Ясное дело что они бы не поняли.
Это тоже верно не зная специфики учета в организации, и очень тонких ньюансов — не возможно не только правильно написать отчет, но доказать бухгалтеру что она не права.
спасибо… новый реальный опыт всегда интересен и полезен
(23) DitriX,
Статейка типа «не для средних умов».
(53) это был камень в чей огород? 🙂
(53) DitriX
автора сего произведения.
есть такое определение СУРЖИК. Надо уважать родной язык. А не писать всякую …..
Надо думать, что автор очень спешил это написать…
не ново
Почему выбрали именно SCRUM, а не Канбан ?
Были ли какие либо доводы за и против данной методологии?
Да уж, как организовать правильно работу — действительно вопрос хороший, спасибо за статью.
(0)
Почему в качестве ХелпДеска выбрали именно kayako, на сколько я понимаю это платное решение.
И если выбирали не из фри софта, почему не воспользовались решениями от 1с, что было бы логично для 1с программистов.
Мне очень нравиться использовать интеллект карты. Создаю их через MindManager.
Есть еще книга классная на эту тему: Бехтерев С. — Майнд-менеджмент. Решение бизнес-задач с помощью интеллект-карт — 2009.
Советую прочитать.
(58)Спасибо за вопрос.
В большинстве своём заказчики хотят результат, быстро и дёшево, поэтому мы выбрали SCRUM, поскольку в конце каждого спринта у нас есть релиз продукта готовый к внедрению. Перед внедрением SCRUM, проекты затягивались, часто бывало, что заказчик изменял требования во время разработки.
По своему опыту скажу, что если делаешь небольшими порциями но результат виден заказчику — он будет доволен и будет продолжать сотрудничать.
По системе, очень похожей на комбан у нас работает служба поддержки (с помощью kayako).
На счет второго вопроса, вначале никто не хотел ни SCRUMа, ни Канбана 🙂
(60)К нам попала демка kayako всем понравилась, потом решили купить. Понравился клиент под софтфон
Интересная статья. Автор, спасибо.
«часто подымались вопросы о том, что программисты ничем не занимаются вовсе» — у меня это постоянное явление, хотя я и обрадовался что на предприятии не ведется учет рабочего времени но мне пришлось самому записывать что и когда я делал, потому что претензии были всегда, тип я сижу ничего не делаю, но когда я начал вести свой учет рабочего времени у начальства сразу все вопросы отпали и сразу все было понятно, чем и когда я занимался и что я сделал.
А как повысить качество работы если я один программист в конторе?
После разработки происходит тестирование 1 раз, в бухгалтерии девчонки проверили если работает то сразу же внедряем, потом лезут косяки и приходится быстро исправлять ошибки в работе.
(65) Уделяйте больше внимания тестированию. Если Вы создаете новую обработку — составьте список пунктов, которые нужно протестировать (так называемый чек-лист) и сохраните этот документ. Составляйте список очень подробно, стараясь учесть каждый нюанс. Внедряйте свою наработку только тогда, когда пройдетесь по всему списку и ошибок не обнаружите.
После внесения изменений нужно опять таки проходить весь список (чек-лист) с самого начала. Конечно, время на разработку возрастет, но при тщательном составлении чек-листа сократится время на последующие исправления багов (постарайтесь донести это начальству и вносите больше времени на тестирование при оценке задачи).
Конечно, здесь еще нужно не ленится и заставлять себе заниматься тестированием такого рода, по себе знаю как хочется иногда забить и закончить задачу.
И еще один нюанс. Тестируйте под правами всех пользователей, которые будут пользоваться Вашей разработкой, даже если вы программируете отчет.
Удачи в новых начинаниях!
(66) У нас так бывает по дурацкому что приходит шеф говорит нам надо срочно сделать выгрузку продаж на андроид(есть свое приложение) пишешь сам пару раз проверяешь и сразу же внедряешь потому что торопят всем все срочно надо, но это уже проблема начальства, может составить какой то регламент по тестированию и показать начальству?
«И еще один нюанс. Тестируйте под правами всех пользователей, которые будут пользоваться Вашей разработкой, даже если вы программируете отчет.» — на днях напоролся на этот нюанс, недели две не могли найти ошибку оказалось что проблема была в правах пользователя, а все тестили под полными.
(67) Поговорите с начальством, расскажите в чем бывают проблемы, хотя к не технарям бывает трудно достучатся 🙂
(67) Этой проблемой страдают практически все — нехваткой времени на тестирование, и непониманием руководства, что работу можно внедрять только после тестирования.. в том числе и под правами пользователя(ей). Сами несколько раз на этом ловили баги..
Взбесило меня пожалуй одно — вы что, русским языком не владеете? Или автор считает, что в русском лексиконе НЕТ ничего того, чем можно было бы заменить англоязычные понятия? Причем это даже не понятия, а просто фразы.
(71) Русский язык в целом. Если владеете дворянским русским языком 19 века, то можете писать и на нем.
Спасибо автору за статью! Сейчас сложилась такая же ситуация. Вроде работа делается, а её не видно. Вспомнить, что кто делал месяц назад — невозможно. Для слежения за выполнением задач использовали самописную конфигурацию на 1С. До спринтов пока не дощли, но задачи расписываются по мере поступления.
На счет русского языка. 10 минут в интернете:
Team Leader — Руководитель группы.
Некоторые должностные обязанности:
Спринт (Sprint) – сфокусированные усилия группы на небольшой участок времени (неделя, 2 недели, но обычно не более месяца)
Скрам-мастер (ScrumMaster) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Резерв проекта (Product Backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации.
Планирование спринта (Sprint Planning Meeting) — Происходит в начале новой итерации Спринта.
Столько много иностранных терминов!!
Ну я вроде все перевел=)
Андрей, спасибо за хорошую и полезную практическую методику работы.
Негативные комментарии вызвали недоумение.
Присоединяюсь к плюсующим тремя плюсами (+++)!
Проекты веду единолично здесь . Но обязательно надо попробовать ваши методы-инструменты.
Спасибо за статью, начали использовать реалтаймбоард.
Мир этому дому!
Прошу прощения, что комментарий запоздалый, но не могу упомянуть про :
«Scrum и XP: заметки с передовой. Как мы делаем SCRUM». Книга имеет практическую направленость ( содержит менее 100 страниц). Ее чтение не отнимет много времени, и в то же время будет полезна тем, кто использует (или собирается использовать) технологии SCRUM и экстримального программирования (XP) в своей практике. Эта книга отображает субъективное мнение и практический опыт автора.
«Эта книга не претендует на звание «единственно правильного» учебного пособия по Scrum’у! Она всего
лишь предлагает вам пример удачного опыта, полученного на протяжении года в результате постоянной
оптимизации процесса. Кстати, у вас запросто может возникнуть ощущение, что мы всё поняли не так.»
Майк Кон.»
Спасибо ребятам за перевод.
Доброе утро.
Сколько времени прошло, а вопрос актуален и по сей день.
Коллеги, сможете вы еще пользуетесь ?
Есть ли в нем возможность указывать плановое время затрат и анализировать итоги спринта в разрезе планового времени/фактического времени/ количества выполненых и не выполненых.
Это важно для подведения итогов. Мы это на «физической» доске считаем и маркером пишем сейчас. Не очень удобно.