Толпа, Kanban или Other для 4 [закрытых] команд разработчиков человека
Шаг 1:
select object_name, s.sid, s.serial#, p.spid
from v$locked_object l, dba_objects o, v$session s, v$process p
where l.object_id = o.object_id and l.session_id = s.sid and s.paddr = p.addr;
Шаг 2:
alter system kill session 'sid,serial#'; --`sid` and `serial#` get from step 1
Дополнительная информация: http://www.oracle-base.com/articles/misc/killing -oracle-sessions.php
6 ответов
И Scrum, и Kanban на самом деле являются «скелетами» процесса. Ни то, ни другое не относится к разработке программного обеспечения. Скрам был популяризирован организациями, занимающимися разработкой программного обеспечения, но позиционируется как общий метод управления, а не как метод управления проектами программного обеспечения. Канбан возник из производства и был адаптирован для разработки программного обеспечения, первоначально командами обслуживания. И Scrum, и Kanban нацелены на управление потоком единиц работы через команду, которая выполняет эту работу, измерение скорости рабочих потоков, чтобы оценки можно было делать все более и более точно, и сделать узкие места хорошо заметными, чтобы их можно было устранить.
Поскольку ни один из них не относится к разработке программного обеспечения, команды, использующие Scrum и Kanban, добавляют в процесс методы разработки программного обеспечения, чтобы помочь им постепенно и итеративно выпускать и улучшать программное обеспечение. Большинство команд, независимо от того, работают ли они в рамках процесса Scrum или Kanban, перенимают технические практики XP и рефлексивные методы Crystal.
XP - это в основном Scrum, применяемый к одной команде, плюс рекомендации о том, что делает код «высококачественным» и как программисты могут добиться этого. Crystal Clear также применим к небольшим группам, расположенным в одном месте, но более гибок в отношении практик программирования, хотя также рекомендует методы XP (книга, описывающая этот процесс, превосходна и полна бесценных советов, независимо от того, какой процесс вы решите использовать). Скрам-команды также обычно перенимают рефлексивные практики Crystal: регулярное «сердцебиение». ретроспективы и более крупные ретроспективы после каждой важной вехи. Канбан требует постоянного размышления и улучшения, но некоторые команды также используют ретроспективы.
Если вы хотите начать применять инкрементный / итеративный процесс в небольшой команде программистов, то я думаю, что XP - хороший процесс для начала, потому что он устанавливает довольно высокую планку. высокий для технических возможностей и очень хорошо задокументирован. Как непрерывный поток и Канбан лучше всего подходят для различных областей индустрии разработки программного обеспечения, все еще обсуждается в списке рассылки kanban-dev и в других местах.
Я бы также рекомендовал проводить регулярные ретроспективы, чтобы улучшить процесс и адаптировать его к вашим конкретным условиям. ситуация.
Если вы хотите начать применять инкрементный / итеративный процесс в небольшой команде программистов, то я думаю, что XP - хороший процесс для начала, потому что он устанавливает довольно высокую планку технических возможностей и очень хорошо документирован. Как непрерывный поток и Канбан лучше всего подходят для различных областей индустрии разработки программного обеспечения, все еще обсуждается в списке рассылки kanban-dev и в других местах.
Я бы также рекомендовал проводить регулярные ретроспективы, чтобы улучшить процесс и адаптировать его к вашим конкретным условиям. ситуация.
Если вы хотите начать применять инкрементный / итеративный процесс в небольшой команде программистов, то я думаю, что XP - хороший процесс для начала, потому что он устанавливает довольно высокую планку технических возможностей и очень хорошо документирован. Как непрерывный поток и Канбан лучше всего подходят для различных областей индустрии разработки программного обеспечения, все еще обсуждается в списке рассылки kanban-dev и в других местах.
Я бы также рекомендовал проводить регулярные ретроспективы, чтобы улучшить процесс и адаптировать его к вашим конкретным условиям. ситуация.
Я думаю Scrum работает для малых и средних команд. По сравнению с XP он не учитывает некоторые детали, так что вы можете позаимствовать у XP или сделать что-нибудь разумное. Какую бы методологию вы ни выбрали, вы должны учитывать роль цыплят (клиентов / менеджеров / заинтересованных сторон / экспертов в предметной области). Иногда вам приходится играть роли самостоятельно, но многие гибкие методологии работают, потому что есть внешний автомобиль для ускорения работы с обоснованным знанием предметной области.
Другими ключевыми аспектами являются уровень общения между вашей командой и некоторая форма механизма обеспечения качества. Трудно заниматься парным программированием, если вы не находитесь в одном здании. Scrum пытается довести функцию до принятия в рамках цикла спринта, а XP пытается интегрировать эту функцию в течение дня с помощью модульных тестов, анализа кода и непрерывной интеграции.
Я работал с такой командой, а то и с двумя командами, у которых были общие библиотеки. Скрам у нас хорошо сработал. Сейчас я работаю с командой из 6 человек, мы используем XP, и я думаю, что это тоже работает. Первая команда разработала продукт, и влияние «космоса» было не таким сильным. Так что более длинные итерации работали нормально. Нет, мы разрабатываем клиентский проект, и поэтому более короткие циклы выпуска лучше для нас.
Но SCRUM и XP - это нечто большее. Теперь мы используем TDD и парное программирование (оба больше из мира XP). У нас также есть ежедневные стендап-встречи, которые больше похожи на SCRUM. Поэтому мы приняли XP и SCRUM для работы в нашем проекте и в нашей ситуации.
Я бы начал с коротких циклов (1 неделя) и обзоров этого цикла.
Какой у вас вопрос? Какая методология будет наиболее подходящей?
Наиболее важной частью является наличие механизма отражения / ретроспективы, который способствует постоянному совершенствованию. Начните с некоторой модели процесса и со временем развивайте ее для ваших потребностей. Прекратите делать то, что не стоит делать. Продолжайте делать то, что приносит большую пользу. Попробуйте новые вещи, которые, по вашему мнению, могут быть полезными или решить конкретные проблемы.
Вы не получите особой выгоды от всех накладных расходов, которые формальная система наложит с таким размером команда. Вместо,